"Rediseño del desarrollo de Software"
En este capítulo se presenta el marco teórico utilizado para mejorar las actividades pertenecientes al proceso de desarrollo de software, previamente identificadas estas actividades, a través del patrón Gestión, producción y provisión bien o servicio (macro1).
El punto 4.1 presenta las normas CMM, que permiten confirmar las falencias en el proceso de desarrollo de software, que fueron identificadas a través del patrón, además de proporcionar las directrices a seguir para mejorar estas falencias.
4.1. CMM
4.1.1. Introducción
En noviembre de 1986, The Software Ingineering Institute (SEI), con la asistencia de MITRE corporation, comenzó a desarrollar un proceso de madurez por niveles, que ayudaría a las organizaciones a mejorar sus procesos de desarrollo de software. En septiembre de 1987, el SEI publicó una breve descripción de los niveles de madurez de los procesos de software, el cual fue desarrollado en el libro de Humphrey "Managing the Software Process".
Después de cuatro años de experiencia con la madurez del proceso de software, el SEI evolucionó la madurez y publicó Capability Maturity Model for Software (CMM).
La primera publicación de las CMM fue revisada y usada por la comunidad de software durante 1991 y 1992. La versión 1.1 fue publicada en 1993. Y en 1996 fue liberada la versión 2 del CMM, que evolucionó integrando diferentes métodos en la mejora de los procesos, como los estándares ISO.
EL Modelo de Madurez de Capacidades ("Capability Maturity Model") es un marco de trabajo que describe los elementos claves de un proceso de software eficaz. Describe un camino de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado, basado en conocimientos adquiridos de evaluaciones de los procesos de software y extensos feedback con industrias y el gobierno.
Por lo tanto, las disposiciones del CMM son definitivamente aplicables a todo aquello que esté directamente relacionado con el desarrollo y mantenimiento de sistemas informáticos.
4.1.2. Niveles de Madurez y Áreas Clave de CMM
El CMM proporciona un marco para evolucionar la organización en cinco niveles de madurez (ver esquema en Figura 4-1). El nombre que acompaña a las flechas de la figura indica el tipo de proceso capaz de ser institucionalizado por la organización.
Los cinco niveles pueden ser descritos brevemente como:
1._Inicial: El proceso de software se caracteriza como ad hoc, y ocasionalmente caótico. Pocas actividades están definidas y el éxito de los proyectos depende del esfuerzo individual. Carencia de procedimientos formales, estimaciones de costo, planes del proyecto, mecanismo de administración para asegurar que los procedimientos se siguen.
2._Repetible: Son establecidas las actividades básicas para la administración de proyectos de software para el seguimiento de costos, programación y funcionalidad. El éxito está en repetir prácticas que hicieron posible el éxito de proyectos anteriores. Por lo tanto hay fortalezas cuando se desarrollan proyectos similares y gran riesgo cuando se enfrentan nuevos desafíos.
3._Definido: Las actividades del proceso de software para la administración e ingeniería están documentadas, estandarizadas e integradas en un proceso de software estándar para la organización.
4._Administrado: Medidas detalladas de las actividades del proceso y calidad del producto son registradas. El proceso de software y el producto entregado son cuantitativamente entendidos y controlados.
5._Optimizado: Existe una mejora continua de las actividades, la que se logra, a través, de un feedback con estas mismas y también a partir de innovadoras ideas y tecnologías. La recolección de datos es automatizada y usada para identificar elementos más débiles del proceso, se hacen rigurosos análisis de causas y prevención de defectos.
Synapsis S.A. se encuentra ubicada en el nivel 1 de madurez, y con el objetivo de visualizar hacia dónde se enfocarán las propuestas que se harán en este proyecto, se describirá con mayor detalle las características de madurez del nivel 2.
Figura 4-1: Los cinco niveles del proceso de maduración
4.1.2.1. Caracterización del Nivel 2. Repetible
En este nivel las políticas para la administración de proyectos de software y procedimientos para implementar dichas políticas están establecidas. La planificación y administración de nuevos proyectos, están basadas en experiencia con similares proyectos y se mejora estableciendo disciplinas básicas.
Un proceso efectivo puede ser caracterizado como un proceso donde se tienen experiencias anteriores de proyectos similares, existe documentación, es especializado, medido y capaz de ser mejorado.
Las organizaciones que se encuentran en el nivel 2, tienen instalado un sistema básico de control para la administración de sus proyectos. Por esto los problemas en el cumplimiento de acuerdos son identificados a medida que ellos surgen.
Estándares y planes para los proyectos de software son definidos, y la organización garantiza que ellos sean seguidos fielmente.
La organización en este nivel puede definirse como disciplinada, porque la planificación y seguimiento de proyectos de software es estable y los anteriores éxitos pueden ser repetidos.
4.1.2.2. Áreas claves de proceso para el Nivel 2. Repetible
Cada nivel de madurez (excepto el nivel 1) se descompone en áreas claves de proceso (KPA), prácticas claves e indicadores claves.3
El nivel de madurez se establece como aquél en que se satisfacen todas las áreas claves en forma continua. Estas áreas claves priorizan los esfuerzos para mejorar el proceso de desarrollo de software en la organización.
Las áreas claves correspondientes al nivel 2 son:
Administración de requerimientos
El propósito de la administración de requerimientos es establecer un común entendimiento de las necesidades del usuario, las que deben estar documentadas.
El entendimiento de los requerimientos es fundamental para la construcción de software que será realizado al cliente. Revisar los requerimientos e interactuar con el cliente es parte de establecer este entendimiento. Los requerimientos del cliente están cambiando frecuentemente, por lo que la documentación y el control de éstos es prerrequisito para usarlos como base para la estimación, planificación, desarrollo y seguimiento de las actividades del proyecto de software, a través de su ciclo de vida.
Planificación de proyectos de software
El propósito de la planificación es establecer un plan razonable para el desarrollo y administración del proyecto de software. Los planes razonables están basados en estimaciones realistas del trabajo que permitan establecer los compromisos necesarios para desarrollar el proyecto. La planificación incluye pasos para estimar la cantidad de trabajo y los recursos necesarios.
Supervisión y seguimiento de proyectos de software
El propósito del seguimiento y supervisión de proyectos de software es establecer una visibilidad adecuada del progreso real del proyecto, para que la gestión pueda tomar acciones efectivas cuando el proyecto se desvía significativamente de la planificación realizada.
Gestión de subcontratos de software
El propósito de la administración de subcontrato de software es seleccionar subcontratistas calificados y administrarlos efectivamente.
Aseguramiento de calidad de software
El propósito del aseguramiento de la calidad de software involucra una revisión y análisis del producto de software y las actividades, para verificar que cumplen con los procedimientos y estándares aplicados.
Administración de la configuración de software
El propósito de la administración de la configuración de software es establecer y mantener la integridad de los productos de software, a través de su ciclo de vida. Esto significa controlar los cambios de los productos, registrar y mantener las bibliotecas de programas.
El rediseño se centrará en las primeras tres áreas claves.
En este proyecto las mejoras más significativas se refieren a la Planificación de Proyectos de Software, ya que es debido a esta falencia que se producen costos no considerados en los proyectos y entregas del producto en fechas fuera del plazo comprometidas con el cliente. Para que esta mejora tenga sentido es necesario que los requisitos del usuario se relacionen con la métrica utilizada para realizar la planificación, es por esta razón que se tratará también en este proyecto la Administración de Requerimientos. Y finalmente, a raíz de los cambios que se propondrán al enfocarse en las dos primeras áreas claves, es que se justifica realizar Supervisión y Seguimiento del Proyecto para tomar medidas cuando éste se aleje de la planificación inicial.
En Synapsis S.A. no se subcontratan servicios de software, por esto el área clave de Gestión de subcontratos de software no será tratada en este proyecto. Tampoco el Aseguramiento de calidad de software y la Administración de la configuración.
En el siguiente punto se describe la métrica "Puntos de Función", elegida para desarrollar el área clave Planificación de Proyectos de Software.
La métrica tradicional para estimar el esfuerzo de desarrollo y productividad ha sido LOC (Lines of Code) o SLOC (Source Lines of Code). Sin embargo fueron elegidos los puntos de función porque:
En resumen, los puntos de función aparecen con ventajas substanciales por sobre las líneas de código, para fines de estimación temprana del tamaño del software, y por ende, del esfuerzo de desarrollo. Además es una medida ampliamente utilizada, y con éxito, en muchas organizaciones que desarrollan software en forma masiva [Varas95].
4.2. Puntos de Función
Todo proyecto de ingeniería de software debe partir con un buen plan, pero lamentablemente, la planificación es una tarea nada de trivial. Uno de los aspectos que dificulta la labor de administradores y jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y plazos realistas.
El manejador principal de los costo de un proyecto de desarrollo de software es sin duda el tamaño del producto. La medida del tamaño debe ser tal que esté en relación directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de considerar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos y complejidad.
Al contar con una estimación temprana del tamaño de lo que se desea desarrollar, se puede realizar una estimación del esfuerzo en etapas tempranas del desarrollo. Esto debido a que el tamaño del software es la variable manejadora de costo principal del desarrollo.
La métrica Puntos de Función (PFs), desarrollada por A. J. Albrecht [Albrecht79], fue la primera métrica orientada a la función y sugiere un acercamiento a la medida de productividad. Los puntos de función se obtienen utilizando una relación empírica basada en medidas cuantitativas del dominio de información de software y valorizaciones subjetivas de la complejidad del software.
Esta técnica aporta una medida estándar del tamaño de los sistemas de información, y sirve de base para la estimación del esfuerzo requerido para el desarrollo de los proyectos.
La medida de los sistemas de información mediante los puntos de función proporciona una estimación del tamaño del software independiente de la tecnología utilizada en su desarrollo y dependiente únicamente de la funcionalidad que el sistema proporciona al usuario. Esto quiere decir que la estimación se refiere a los resultados que se obtienen de un sistema de información y no cómo se producen internamente estos resultados.4
4.2.1. Componentes de la Evaluación
Para calcular los PF se deben realizar dos conteos:
Las Funciones Transaccionales representan la funcionalidad provista al usuario de los procesos de datos de una aplicación. El conteo de tipos de funciones transaccionales determina la cantidad de Entradas Externas, Salidas Externas y Consultas Externas.
Entradas Externas (EI): Cada entrada de usuario que proporciona al software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas de las peticiones, que se contabilizan por separado. En general cada archivo lógico requerirá de tres tipos de entradas: agregar, cambiar y borrar.
También se define como datos o información de control que llega desde fuera de los límites de la aplicación o proyecto que está siendo medido.
Salidas Externas (EO): Cada salida que proporciona al usuario información orientada a la aplicación. La salida se refiere a reportes, datos a pantalla, mensajes de error, etc. Los elementos de datos individuales dentro de un informe no se cuentan por separado.
También se define como datos o información de control que se envía desde fuera de los límites de la aplicación.
Consultas Externas (EQ): Es una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. Se cuenta cada petición por separado.
También se define como una combinación de entradas (requerimientos) y salidas (recuperación) de información desde la aplicación.
El conteo de Funciones de Datos determina la cantidad de Archivos Lógicos Internos y de Archivos de Interfaz Externa perteneciente a la aplicación que está siendo contabilizada.
Archivos Lógicos Internos (ILF): Cada maestro lógico (o sea, una agrupación lógica de datos que puede ser una parte de una gran base de datos o un archivo independiente).
También se define como datos relacionados lógicamente o información de control que se encuentra dentro de los límites de la aplicación.
Archivos Interfaz Externos (EIF): Todas las interfaces legibles por la máquina (por ejemplo, archivos de datos en cinta o disco) que son utilizados para transmitir información a otro sistema.
También se define como datos relacionados lógicamente o información de control que se encuentran fuera de los límites de la aplicación.
4.2.2. Complejidad para cada Función
Para cada función de datos o transaccionales identificada se debe determinar su complejidad. La complejidad para los ILF e EIF es la misma y se obtiene basándose en la cantidad de DETs y RETs contenidos en cada función. En cambio la complejidad de las EI, EO y EQ se obtiene basándose en la cantidad de DETs y FTRs involucrados. A continuación se describen estos elementos.
Tipo Elemental de Dato (DET) es una campo no recursivo perteneciente a un archivo lógico interno o a un archivo de interfaz externa y que es reconocible por el usuario.
Tipo Elemental de Registro (RET) es subgrupo de elementos de datos reconocibles por el usuario y que están dentro de un archivo lógico interno o dentro de un archivo de interfaz externa.
Tipo de Archivo Referenciado (FTR) es un archivo lógico interno que es leído o mantenido por una función o un archivo de interfaz externa que es leído por una función de transacción (EI, EO o EQ).
A continuación se muestran las tablas que determinan la complejidad de las funciones de datos y transaccionales, a partir de la relación que exista entre DET/RET o DET/FTR.
Tabla que permite obtener la complejidad para un ILF e EIF.
1 a 19 DETs |
20 a 50 DETs |
51 o más DETs |
|
1 RET |
Baja |
Baja |
Media |
2 a 3 RETs |
Baja |
Media |
Alta |
4 o más RETs |
Media |
Alta |
Alta |
Tabla 4-1: Complejidad de ILFs e EIFs [IFPUG]
Tabla que permite obtener la complejidad para un EI.
| 1 a 4 DETs | 5 a 15 DETs | 16 o más DETs | |
| 0 a 1 FTR | Baja |
Baja |
Media |
| 2 FTRs | Baja |
Media |
Alta |
| 3 o más FTR s | Media |
Alta |
Alta |
Tabla 4-2: Complejidad de EI [IFPUG]
Tabla que permite obtener la complejidad para un EO.
1 a 5 DETs |
6 a 19 DETs |
20 o más DETs |
|
0 a 1 FTR |
Baja |
Baja |
Media |
2 a 3 FTRs |
Baja |
Media |
Alta |
4 o más FTR s |
Media |
Alta |
Alta |
Tabla 4-3: Complejidad de EO [IFPUG]
Tabla que permite obtener la complejidad para un EQ en el lado Input.
| 1 a 4 DETs | 5 a 15 DETs | 16 o más DETs | |
| 0 a 1 FTR | Baja |
Baja |
Media |
| 2 FTRs | Baja |
Media |
Alta |
| 3 o más FTR s |
Media |
Alta |
Alta |
Tabla 4-4: Complejidad de EQ - lado Input [IFPUG]
Tabla que permite obtener la complejidad para un EQ en el lado Output.
| 1 a 5 DETs | 6 a 19 DETs | 20 o más DETs | |
0 a 1 FTR |
Baja |
Baja |
Media |
2 a 3 FTRs |
Baja |
Media |
Alta |
4 o más FTR s |
Media |
Alta |
Alta |
Tabla 4-5: Complejidad de EQ - lado Output [IFPUG]La complejidad total de la EQ se obtiene comparando las complejidades determinadas para el lado Input y para el lado Output, prevaleciendo la complejidad mayor.
4.2.3. Cálculo de PFs
4.2.3.1. Fórmula para medir una Aplicación
Para cada tipo de función y de acuerdo a su complejidad, se determinó un factor de peso, el cual se utiliza para obtener el cálculo de puntos de función bruto o no ajustados. Este cálculo consiste en sumar, para cada tipo de función, la cantidad de elementos de cada complejidad multiplicada por el factor de peso correspondiente.
Tipo de Función |
Simple |
Medio |
Complejo |
Total |
N° Entradas Externas |
___*3 | ___*4 | ___*6 | |
N° Salidas Externas |
___*4 | ___*5 | ___*7 | |
N° Consultas Externas |
___*3 | ___*4 | ___*6 | |
N° Archivos Lógicos Internos |
___*7 | ___*10 | ___*15 | |
N° Archivos de Interfaz Externa |
___*5 | ___*7 | ___*10 | |
Puntos de Función Bruto (PFB): |
||||
Tabla 4-6: Cálculo Punto de Función Bruto
Para obtener el punto de función, el punto de función bruto se ajusta multiplicándolo por un factor, como lo indica la siguiente relación:
PF: Punto de Función
PFB: Punto de Función Bruto
Fa: Factor de ajuste
Este factor se denomina factor de ajuste y representa los valores de ajuste de la complejidad considerando características técnicas y operacionales del sistema. Este factor se basa en la respuesta a un cuestionario de 14 ítemes. Se evalúa cada ítem en una escala de 0 a 5 según el grado de influencia que posean en el sistema.
El factor de ajuste está dado por:
Gi: Grado de influencia, valor que va de 0 a 5.
Significado de la escala:
0 = La característica no está presente o no influye si está presente
1 = La característica tiene una influencia Incidental
2 = La característica tiene una influencia moderada
3 = La característica tiene una influencia promedio
4 = La característica tiene una influencia significativa
5 = La característica tiene una influencia fuerte, es esencial
Cuestionario de 14 ítemes:
1. Comunicación de datos
2. Proceso de datos distribuido
3. Rendimiento (Performance)
4. Alta utilización del entorno operativo
5. Volumen de transacciones
6. Entrada de datos interactiva
7. Eficiencia de uso por parte del usuario
8. Actualización interactiva
9. Procesamiento complejo
10. Reusabilidad del código
11. Facilidad de conversión e instalación
12. Operatibilidad en cuanto al manejo de seguridad y recuperación de errores
13. Facilidad de soportar múltiples instalaciones en diferentes organizaciones
14. Facilidad para permitir cambios o modificaciones
Significado de cada ítem:
1. Comunicación de datos
Los datos e información de control usados en la aplicación son enviados o recibidos por las facilidades de comunicación. Los terminales conectados localmente a la unidad de control son considerados para usar estas facilidades de comunicación. El protocolo es un conjunto de convenciones que permiten la transferencia o intercambio de información entre dos sistemas o dispositivos. Todas las conexiones de datos requieren algún tipo de protocolo.
2. Proceso de datos distribuido
El proceso distribuido de datos o funciones es una característica de la aplicación, dentro de los límites de la misma. El procesamiento distribuido se refiere a la utilización de llamadas a procedimientos remotos para operar con datos o funciones que se encuentran en máquinas distintas de donde se encuentra instalada la aplicación.
3. Rendimiento (Performance)
Se mide los objetivos de rendimiento (performance) iniciales o probados por el usuario, en relación a la influencia de los tiempos de respuesta (throughput) en el desarrollo, instalación y mantención de la aplicación.
4. Alta utilización del entorno operativo
La configuración para un entorno operativo fuertemente utilizado requiere consideraciones especiales de diseño, lo que hace de ésta una característica propia de la aplicación. Se refiere a si la aplicación requerirá de un procesador especial, si hay consideraciones de seguridad o si se aplican restricciones en los distintos componentes de un sistema.
5. Volumen de transacciones
Esta característica tiene una alta influencia en el diseño, desarrollo, instalación y mantención de una aplicación. Se refiere a la periodicidad con que se requiere generar gran cantidad de transacciones. Por ejemplo, un proceso de facturación genera una gran cantidad de transacciones al término de cada mes.
6. Entrada de datos interactiva
Se determina la cantidad de entrada de datos en línea y funciones de control que son provistas en la aplicación.
7. Eficiencia de uso por parte del usuario
Son las facilidades incluidas en el diseño de una aplicación para ayudar a obtener una mayor eficiencia de uso por parte del usuario. Por ejemplo, ayudas de navegación, menús, ayuda y documentos en línea, impresión remota, etc.
8. Actualización interactiva
Se verifica si la aplicación permite hacer una actualización en línea de los archivos lógicos internos.
9. Procesamiento complejo
Se determina qué componentes están en el procesamiento que hace la aplicación:
10. Reusabilidad del código
Se verifica si el código de la aplicación ha sido específicamente diseñado, desarrollado y mantenido para ser usado en otras aplicaciones.
11. Facilidad de conversión e instalación
Una fácil conversión e instalación son características de una aplicación. Se determina si existe un plan de conversión e instalación y/o herramientas de conversión que han sido provistas y probadas durante la fase de prueba del sistema.
12. Operatibilidad en cuanto al manejo de seguridad y recuperación de errores
Se determina si la aplicación provee una partida, respaldo y recuperación de errores efectiva, lo que es estudiado en la fase de prueba del sistema. Se verifica si la aplicación minimiza la necesidad de actividades manuales, tales como, montar cintas, manipulación de papel, intervención directa de un operador, etc.
13. Facilidad de soportar múltiples instalaciones en diferentes organizaciones
Se verifica si la aplicación ha sido diseñada y desarrollada para ser instalada en múltiples sitios y para múltiples instalaciones de la misma.
14. Facilidad para permitir cambios o modificaciones
Se refiere a si la aplicación ha sido específicamente diseñada y desarrollada para facilitar el cambio. Características como las siguientes pueden aplicarse:
4.2.3.2. Fórmula para Medir un Proyecto de Mejoramiento
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)
Donde:
EFP : Cuenta de puntos de función para proyecto de mejoramiento
ADD : Cuenta no ajustada de PF para funciones que fueron agregadas con el mejoramiento
CHGA : Cuenta no ajustada de PF para funciones que fueron modificadas con el mejoramiento
CFP : Cuenta no ajustada de PF sumados por la conversión de funcionalidad
VAFA : Valor del factor de ajuste después del mejoramiento
DEL : Cuenta no ajustada de PF para funciones que fueron eliminadas con el mejoramiento
VAFB : Valor del factor de ajuste antes del mejoramiento
En el punto 4.3. se da el marco teórico de la metodología utilizada para desarrollar el área clave Administración de Requerimientos. Esta metodología para la capturar y definición de los requerimientos, denominada Casos de Uso, fue elegida porque permite relacionar fácilmente los requerimientos solicitados por el cliente con las funciones transaccionales y de datos, necesarias para el cálculo de los puntos de función y la consecuente planificación del proyecto.
4.3. Caso de Uso 5
Los casos de uso fueron introducidos por Ivar Jacobson en 1994 y permiten realizar la especificación de un sistema centrada en el usuario. En esencia un caso de uso representa una interacción típica entre un usuario y un sistema o aplicación computacional. Para ilustrar lo anterior, supongamos un usuario utilizando un procesador de texto. Dos casos de uso típicos podrían ser "asignar negrita a una palabra" o "crear un índice". Con los ejemplos anteriores se pueden identificar algunas de las propiedades de los casos de uso:
En su forma más simple, los casos de uso son identificados mediante conversaciones con el usuario y discutiendo las distintas operaciones que el sistema debe proveer. Cada funcionalidad u objetivo discreto debe ser documentado asignándole un nombre y una breve descripción.
La funcionalidad que describe un caso de uso determinado puede ser interpretada como una Interacción de Sistema u Objetivo de Usuario. La interacción de sistema permite describir las operaciones que el usuario realiza para satisfacer un objetivo. El objetivo del usuario, como su nombre lo indica, refleja un objetivo que el usuario desea satisfacer. Por ejemplo, siguiendo con el ejemplo del procesador de texto, algunas interacciones de sistema podrían ser "asignar formato a un párrafo", "definir un nuevo estilo" o "modificar un estilo". Sin embargo, éstas no reflejan el objetivo del usuario que podría ser "mantener un formato consistente para todos los documentos". Es necesario tomar en cuenta esta diferencia al momento de modelar los casos de uso.
Los casos de uso incluyen, además, Actores. Un actor representa una entidad externa que se relaciona directamente con el sistema. Los actores representan humanos, máquinas u otros sistemas. En definitiva, un actor corresponde al rol que juega alguna de las entidades anteriores frente al sistema. Puede haber muchos usuarios con un mismo rol. Un usuario también puede poseer distintos roles. Por esta razón, al considerar los actores del sistema se debe centrar el análisis en los roles y no en las personas.
Los actores son los que realizan los casos de uso. Un actor puede realizar varios casos de uso; alternativamente, un caso de uso puede ser realizado por varios actores.
Los actores apoyan la identificación de los casos de uso. Enfrentado a un sistema muy grande, intentar identificar la lista de casos de uso puede ser una tarea muy compleja. La alternativa adecuada es identificar la lista de actores del sistema y luego intentar identificar los casos de uso de cada actor.
Como se mencionó anteriormente, los actores no necesariamente deben ser humanos. Un actor también puede ser un sistema externo que requiere información del sistema actual. La interacción con sistemas externos produce confusión en la definición de los actores que representan a los sistemas externos. Es recomendable que se incluyan actores para reflejar sistemas externos sólo cuando el actor (externo) requiere del caso de uso modelado. De esta forma, las entidades que están indirectamente relacionadas con el sistema no son consideradas actores debido a que sus necesidades deben ser comunicadas al sistema mediante un actor. Cada actor utiliza el sistema de distintas maneras; de lo contrario los actores no serían distintos.
Cada caso de uso describe la secuencia posible de interacciones entre el sistema y uno o más actores como consecuencia de un estímulo inicial de alguno de los actores. Para definir los casos de uso se deben agrupar todas aquellas transacciones "similares"; aquellas que el usuario vería como variaciones de algún tema. Por ejemplo, un caso de uso para un banco podría ser "realizar una transacción en la caja". Los casos de uso que se pueden desprender del anterior podrían ser realizar un depósito, efectuar un retiro, transferencias, etc.
Las excepciones corresponden a situaciones anormales e incluye las medidas que es necesario realizar para poder completar el caso de uso.
Las precondiciones corresponden a las condiciones que se deben cumplir para que se pueda realizar el caso de uso.
Las postcondiciones corresponden a condiciones que se deben cumplir una vez que el caso de uso ha terminado exitosamente.
3 Fuente: http://www.sei.cmu.edu
4 Fuente: http://www.centrisa.es
5 Para entender con más claridad este punto ver Anexo N°6 - Aplicación de Caso de Uso.