ELECTIVA III. Entregables Minimos

Transcripción

1 ELECTIVA III Entregables Minimos Entregable Descripción Sugerencias Requerido El software de trabajo, el hardware y la documentación para ser Hay más en su sistema que sólo el software que se Sistema liberada a producción. escribe. Código fuente El código de programa para su sistemas Siga las directrices de codificación común. Suite de Pruebas de Regresión Una colección de casos de prueba, y el código para correrlas en una orden adecuado. El suite de pruebas de regresión incluirá un gran rango de pruebas, tomando en cuentaapruebas de aceptación, unidad de pruebas, Automatice sus pruebas. Ejecútelas tan frecuentemente como sea posible, sobre todo cuando ocurre algún cambio. Necesitará un script, o scripts, para instalarlo en un ambiente de pre- producción tan exacto como el de producción. Scripts de Instalación Código para instalar su sistema su ambiente de pre- producción. Documentación del Sistema Notas La documentación liberada como una parte del sistema para ayudar al usuario al trabajar con él, y a los desarrolladores para mantenerlo actualizado. Integra potencialmente lasoperaciones, soporte, usuarios, y una documentación general del sistema. Sus notas deben resumir "las buenas cosas a saber" acerca de las versiones actuales que se están construyendo. Probablemente deba desinstalar los scripts si su instalación falla. Mantenga su documentación tan liviana como sea posible. Una lista puntual es a menudo suficiente. Su objetivo es entender y luego construir lo que sus usuarios quieren, no escribir montículos de documentación. Describe los requisitos que su sistema debe cumplir. Consta de una variedad de productos de trabajo, incluyendo No necesita mantener todos los aspectos para su modelo de requerimientos, sólo la porción que resuma el alcance de su sistema.

2 Modelado de requerimientos variedad de productos de trabajo, incluyendo potencialmente apruebas de aceptación, oportunidades de automatización, modelos de procesos del negocio, reglas del negocio, modelo del dominio, modelo de la organización, glosario del proyecto, requerimientos técnicos, modelo de casos de uso, y el modelo de interface de usuario. Considere mantener: Diagramas de Procesos del Negocio(s) el cual resume qué es su sistema. El glosario del proyecto. Cualquier otro requisito de productos, como puntos de forma de los casos de uso, que todavía no han sido implementados. Pruebas de aceptación para requerimientos implementados (que son parte de su suite de pruebas de regresión). Mantenga su modelo tan simple como sea posible, y descarte en cuanto le sea posible una vez que haya extraído el valor de ellos. Modelo de Diseño Describe el diseño de su sistema. Consta de una variedad de productos de trabajo, incluye potencialmente un modelo de despliegue, un modelo de objetos, un modelo de datos físico (PDM), un modelo de seguridad de amenazas, un documento de resumen del sistema, y un modelo de interface de usuario. El mejor lugar para documentar es en su unidad de pruebas y código fuente. Mantenga el documento de resumen del sistema y el modelo físico de datos para documentación permanente. Debe también mantener unos pocos diagramas de diseño detallados, tales como diagramas de secuencia o diagramas de las máquinas de estado. Entregables Sugeridos Entregable Descripción Sugerencias Requerido Pruebas de Aceptación Pruebas de aceptación que describen los requerimientos Ver Introductión a los Casos de Prueba de de caja- negra, identificados por sususuarios del proyecto, Aceptación a los cuales su sistema se debe ajustar. AUP El Proceso Unificado Ágil.

3 Oportunidades de Automatización Presupuesto Una indicación de actividades manuales en las que potencialmente podrían ser automatizados. Una indicación del monto del presupuesto, cuando será recibido y el criterio (si fuera el caso) que su equipo debe cumplir para recibir el fondo para soportar el esfuerzo del proyecto. Esto podría fácilmente ser un simple punto de la lista. Modelado de Procesos del Negocio Una descripción de las actividades del negocio, la información de flujo a través de ella, y los orígenes y destinos de la información. Diagramas de Flujo de Datos (DFDs), Diagramas de Actividad de UML, y los diagramas del flujo de trabajo que son una excelente opción para visualizar la descripción de los procesos del negocio. Especificaciones de las Reglas del Negocio Esquema de Datos Reporte de Defectos Una especificación de reglas del negocio captura la colección de reglas del negocio implementadas por el sistema. Una regla del negocio define o limita un aspecto de su negocio que pretende hacer valer la estructura o influencia del comportamiento del negocio. Las reglas del negocio se concentran frecuentemente los problemas de controles de acceso, cálculos del negocio o políticas de su organización. Si se nombran bien los elementos del negocio probablemente no necesitará escribir alguna documentación de soporte. Use herramientas que describen las reglas del negocio en una forma humanamente legible y eso genera código de trabajo desde la definición de reglas del negocio. El esquema de sus almacenes de datos. En el caso de las bases de datos relacionales, es descrito por el lenguaje de definición de datos Su esquema(s) de datos debe evolucionar de (DDL), para los almacenes de datos XML se usa un esquema de XML o acuerdo al código de la aplicación. XML DTDs. Podría ser tan simple como un o una lista en una hoja de cálculo. Un tipo de solicitudes de cambio que definen problemas relacionados al sistema; es decir, el sistema no está funcionando de la forma en que tiene que hacerlo. Considerar la utilización de programas informáticos específicos para el seguimiento de defectos durante la fase de Transición cuando el sistema está desplegado en producción.

4 Manténgalo simple. Modelado de Despliegue Describe cómo se va a organizar los aspectos de hardware y software del sistema. Frecuentemente diagramado usando un Diagrama de Despliegue UML, un diagrama de red, o un boceto de formato libre. Enfocarse en las dependencias de otros grupos. Identifica su liberación temprana de ventanas en el proyecto. Trabaje cerca con las personas de operación y Plan de Despliegue Describe el acercamiento del despliegue del sistema en producción. soporte. Debe indicar los esfuerzos de capacitación y educación. Los detalles técnicos serán capturados por su script de (des)instalación. Inicie creando un Modelo de dominio liviano Modelado de Dominio Describe las principales entidades empresariales, las relaciones entre ellas y, potencialmente, sus responsabilidades. Debe controlar el desarrollo de su modelo de objetos y el esquema de datos(s) Considere identificar responsabilidades (datos y comportamiento) en vez de sólo sus datos. Presente la estimación en un rango. Estimación Los costos de proyecto para completar el proyecto. Actualice su estimación a lo largo del proyecto. Estimaciones Individuales Una estimación hecha por un individuo del tiempo y costo para ejecutar la tarea. Sugerencias de Estimación Ágiles. La mejor persona para realizar la estimación es aquella quien es responsable de ejecutar la tarea.

5 Individuales ejecutar la tarea. Las cosas más pequeñas son más fáciles de estimar. Modelado de Objetos Describe su esquema de objetos, el código que comprende su software. Frecuentemente comprendido por varias vistas por una estructura estática y los aspectos dinámicos del esquema. Para las estructuras estáticas, considere el diagrama de clases de UML, diagramas de componentes de UML, y diagramas de paquetes de UML. Para los aspectos dinámicos, considere el diagrama de secuencia de UML, diagrama de comunicación de UML, y diagramas de máquinas de estado de UML. Operaciones de Documentación Captura la información de apoyo y los procedimientos para operar el sistema una vez que estén en producción. Evaluación de la Organización Describe la organización (tal vez una división de su empresa) en el que su sistema se desplegará, con una indicación de la capacidad de la organización a adoptar y utilizar el nuevo sistema. Modelo de la Organización Indica a las personas que participan en su proyecto y la estructura de información entre ellos. Debe indicar tanto los miembros del equipo del proyecto, como los principales interesados y sus funciones. Su modelo de dominio debe conducir el desarrollo de su PDM Modelo de Datos Físico (PDM) Describe el esquema físico de un almacén de datos, tales como una base de datos relacional o archivo XML. Evolucione su PDM y su modelado de objetos en paralelo Considere usar una notación UML Vea las facilidades de Introducción al Glosario Glosario del Proyecto Describe los términos críticos y técnicos del negocio en su proyecto. Reutilice las definiciones del glosario existente del negocio Considere usar un Wiki para su proyecto. Descripción General del Resume los objetivos, plan, y la misión del proyecto. Potencialmente compuesta de una declaración de las Debe ser concisa

6 Descripción General del Proyecto Plan del Proyecto Recursos del Proyecto Resume los objetivos, plan, y la misión del proyecto. Potencialmente compuesta de una declaración de las metas del proyecto, estatutos de la visión del proyecto, y Comprende el plan de iteraciones, el cronograma del proyecto, lista de riesgo, estimación, ypresupuesto. Compuesto de financiación, de hardware / software, y las facilidades (como las habitaciones). Lista de puntos debe ser suficiente. Un diagrama de Gantt, o tal vez un gráfico pert, es el método más común para hacer un cronograma del proyecto. Cronograma del Proyecto Indica las actividades, las dependencias entre ellos, y los hitos del proyecto. Observe las sugerencias de cronograma de proyecto ágil. Calendario de actividades a largo plazo a un alto nivel, a corto plazo y actividades en más detalle. Prueba del Concepto Prototipo Código de trabajo que demuestra un enfoque técnico de trabajo. La gente debe planificar su propio trabajo y, como máximo, asistida por el gerente del proyecto. Durante la fase de Elaboración debe crearse una prueba del concepto del prototipo, la cual muestre la arquitectura de extremo a extremo. Registro de Revisión Los resultados, incluidos los puntos de acción, de una revisión. Lista de Riesgos Una lista de los riesgos identificados, y las estrategias de mitigación (si procede). Actualiza tu lista de riesgo a lo largo de su proyecto. Mitigar los riesgos tan pronto como sea posible. Ver Introducción a Modelado de Amenazas de Seguridad. Modelado de Amenazas

7 Modelado de Amenazas de Seguridad Documentación de Soporte Un modelo que analiza las amenazas de la seguridad de su sistema. La documentación requerida por el personal de apoyo, solución de problemas tales como guías, información de contacto para el equipo de desarrollo, que les permite apoyar a los usuarios finales. Las amenazas de seguridad son frecuentemente representadas en un diagrama de despliegue UML o un diagrama de arquitectura de libre formato, por lo que podrían no tener un esquema para ello. La concisión es fundamental Documento de la Descripción General de Sistema Documentación técnica de las personas responsables de mantenimiento y evolución del sistema. Típicamente incluye diagramas de arquitectura de forma libre, una visión general de los procesos del negocio respaldada por el sistema, una indicación de que elcódigo fuente se almacena, y una lista de decisiones de diseño. Si el equipo de desarrollo original, o una porción de él, es responsable de mantener el sistema, entonces se necesitará mucho menos documentación Procesos ajustados Comprende AUP, orientación, y plantillas ajustadas a sus (adopción) necesidades del equipo del proyecto. No describe los problemas de comportamiento tales como los de Requerimientos Técnicos usabilidad, seguridad y rendimiento a menudo se define como requerimientos no funcionales. Plantillas Una "forma electrónica" que contiene información común a llenar los campos para un determinado tipo de producto de trabajo. Ver Introducción a los Requerimientos Técnicos Manténgalas simples. Plantillas que contiene cada item posible que usted quiera para motivar las personas para hacer más información que ellos necesitan. Pruebas Modelado Comprende un Suite de Pruebas de Regresión y cualquier Reporte de Defectos. Estrategia de Pruebas Una descripción de su enfoque general de prueba. Reutilice lo de otros proyectos. Herramientas Los paquetes de software utilizados para desarrollar el sistema

8 Materiales de Capacitación Casos de Uso Las notas de cursos, documentación general, tareas y mucho más utilizado para ayudar el entrenamiento de usuarios, personal de soporte y operaciones de soporte que funcionan con el sistema. Casos de uso describe algo de valor a los usuarios y son un requerimiento primario del producto de trabajo del Agile UP. Los casos de usos de forma puntual son frecuentemente suficientes. La parte más importante de un caso de uso es la descripciones del modelo de caso de uso Modelado de Casos de Uso Documentación de Usuario Un modelo de caso de uso está compuesto por cero o más diagramas de casos de uso, descripciones de casos d uso y descripciones de actores. Los manuales, documentación de ayuda, etc; que los usuarios finales utilizan para ayudarles a entender el sistema. Los casos de uso de forma puntual a veces son suficientes. Diagramas de casos de uso son usados con frecuencia para administrar presentaciones, diagramas de procesos de alto nivel. Recuerde que debe indicar cómo ponerse en contacto con personal de apoyo. Propiedades escritas en papel y bocetos de pizarra de pantallas son suficientes para obtener el punto para conocer qué es lo que se desea construir. Modelo de Interface de Usuario Describe las interfeces de usuario de su sistema. Las interfaces de Usuario son útiles durante las Iniciación y quizás la Elaboración, pero durante la Construcción se debe escribir el código actual de trabajo y no el código del prototipo. La navegación de los Diagramas de Interfaces de Usuario UI es utilizada para ver la vista general de sus interfaces de usuario y explorar los problemas de usabilidad.

9