Differences

This shows you the differences between two versions of the page.

Link to this comparison view

planificacion_y_especificacion_de_requisitos [2012/06/06 12:15] (current)
Line 1: Line 1:
 +====== Planificación y especificación de requisitos ======
  
 + En esta fase se decidirá si finalmente se va a orientar a objetos o no, la programación. ​
 +
 +===== Actividades =====
 +
 +Es importante destacar que las actividades descritas a continuación no tienen porque seguirse estrictamente en el órden indicado y que se pueden solapar en el tiempo entre ellas.
 +
 +  - Definir el Plan-Borrador.
 +  - Crear el Informe de Investigación Preliminar.
 +  - Definir los Requisitos.
 +  - Registrar Términos en el Glosario. (continuado en posteriores fases)
 +  - Implementar un Prototipo. (opcional)
 +  - Definir Casos de Uso (de alto nivel y esenciales).
 +  - Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior)
 +  - Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior)
 +  - Refinar el Plan.
 +
 + La definición de requisitos sólo se va a ver por encima ya que es en el modelo de casos de usos donde encontraremos el punto de partida de la definición de requisitos.
 +
 +===== Requisitos =====
 +
 + Es aconsejable que un documento de Especificación de Requisitos tenga los siguientes puntos:
 +
 +  - Propósito.
 +  - Ámbito del Sistema, Usuarios.
 +  - Funciones del Sistema.
 +  - Atributos del Sistema.
 +
 + Para refinar los requisitos y mejorar la comprensión de los mismos la técnica de casos de uso constituye una valiosa ayuda.
 +
 +===== Casos de uso =====
 +
 +Un Caso de Uso es un documento narrativo que describe la secuencia de eventos de un actor (un agente externo) que usa un sistema para completar un proceso [Jacobson92].
 +
 +Nótese que UML no define un formato para describir un caso de uso. Tan sólo define la manera de representar la relación entre actores y casos de uso en un diagrama (Diagrama de Casos de Uso).
 +
 +==== Casos de uso de alto nivel ====
 +
 +En un caso de uso descrito a alto nivel la descripción es muy general, normalmente se condensa en dos o tres frases. Es útil para comprender el ámbito y el grado de complejidad del sistema.
 +
 +==== Casos de uso expandidos ====
 +
 +Los casos de uso que se consideren los más importantes y que se considere que son los que más influencian al resto, se describen a un nivel más detallado: en el formato expandido. La principal diferencia con un caso de uso de alto nivel está en que incluye un apartado de Curso Típico de Eventos, pero también incluye otros apartados.
 +
 +==== Identificación de casos de uso ====
 +
 +La identificación de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisión de los documentos de requisitos existentes, y en el uso de la técnica de brainstorming entre los miembros del equipo de desarrollo.
 +
 +  - Basados en actores
 +    - Identificar los actores relacionados con el sistema y/o la organización.
 +    - Para cada actor, identificar los procesos que inicia o en los que participa.
 +  - Basados en eventos
 +    - Identificar los eventos externos a los que el sistema va a tener que responder.
 +    - Relacionar los eventos con actores y casos de uso.
 +
 +==== Identificación de los límites del sistema ====
 +
 +En la descripción de un caso de uso se hace referencia en todo momento al “sistema”. Para que los casos de uso tengan un significado completo es necesario que el sistema esté definido con precisión.
 +
 +Al definir los límites del sistema se establece una diferenciación entre lo que es interno y lo que es externo al sistema. El entorno exterior se representa mediante los actores.
 +
 +==== Tipos de casos de uso ====
 +
 +== Según importancia ==
 +
 +    - **Primarios**:​ Representan los procesos principales,​ los más comunes.
 +    - **Secundarios**:​ Representan casos de uso menores, que van a necesitarse raramente.
 +    - **Opcionales**:​ Representan procesos que pueden no ser abordados en el presente proyecto.
 +== Según el grado de compromiso con el diseño ==
 +
 +En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solución, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnología y de la implementación. Un caso de uso definido a nivel abstracto se denomina **esencial**. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstracción.
 +
 +Por el contrario, un caso de uso real describe concretamente el proceso en términos del diseño **real**, de la solución específica que se va a llevar a cabo. Se ajusta a un tipo de interfaz específica,​ y se baja a detalles como pantallas y objetos en las mismas.
 +
 +En principio, los casos de uso reales deberían ser creados en la fase de Diseño y no antes, puesto que se trata de elementos de diseño. Sin embargo, en algunos proyectos se plantea la definición de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decisiones de diseño muy pronto en el ciclo de vida.
 +
 +No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de compromiso con el Diseño es un continuo, y una descripción específica de un caso de uso estará situada en algún punto de la línea entre Casos de Uso Esenciales y Reales, normalmente más cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros.
 +
 +
 +==== Consejos relativos a casos de uso ====
 +
 +  - **Nombre** acostumbra a ser un verbo
 +  - **Alternativas equiprobables** en caso de que se produzca una bifurcación en un punto del caso de uso se puede poner un punto que nos dirija al final de la sección donde se describirá ese caso en particular.
 +
 +==== Construcción del modelo de casos de uso ====
 +
 +  - Después de listar las funciones del sistema, se definen los límites del sistema y se identifican los actores y los casos de uso.
 +  - Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios, secundarios u opcionales.
 +  - Se dibuja el Diagrama de Casos de Uso.
 +  - Se relacionan los casos de uso y se ilustran las relaciones en el Diagrama de Casos de Uso (<<​extiende>>​ y <<​usa>>​).
 +  - Los casos de uso más críticos, importantes y que conllevan un mayor riesgo, se describen en el formato expandido esencial. Se deja la definición en formato expandido esencial del resto de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la complejidad del problema de una sola vez.
 +  - Se crean casos de uso reales sólo cuando:
 +    - Descripciones más detalladas ayudan significativamente a incrementar la comprensión del problema.
 +    - El cliente pide que los procesos se describan de esta forma.
 +  - Ordenar según prioridad los casos de uso.
 +
 +==== Planificación de casos de uso según ciclos de desarrollo ====
 +
 +Prioridad con la que tratar los casos de uso:
 +
 +  - Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del dominio o requiere persistencia en los datos.
 +  - Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo relativamente bajo.
 +  - Incluye funciones complejas, críticas en el tiempo o de nivel elevado de riesgo.
 +  - Implica bien un trabajo de investigación significante,​ o bien el uso de una tecnología nueva o arriesgada.
 +  - Representa un proceso de gran importancia en la línea de negocio.
 +  - Supone directamente un aumento de beneficios o una disminución de costes.