Descargar la presentación
La descarga está en progreso. Por favor, espere
Publicada porNazario Almonte Modificado hace 9 años
1
Modelando el proceso y el Ciclo de Vida Puntos a tratar
El proceso de desarrollar software (organización y disciplina en las actividades) contribuyen a la calidad del software y a la velocidad con que se desarrolla * Significado del Proceso * Modelos de Proceso de Software * Herramientas y Técnicas * Modelado en la Práctica Ing. de Software CH2-1
2
Significado del Proceso
Conjunto ordenado de tareas como Proceso: serie de pasos con actividades, restricciones y recursos que producen una salida de cierto tipo. Cuando el proceso involucra la construcción de un producto, a veces se menciona como Ciclo de Vida (del producto). Ing. de Software
3
Siguiendo un Proceso Un proceso es un conjunto de procedimientos (receta), organizado para construir productos que satisfacen una seria de objetivos y estándares. Los procesos son importantes porque imponen consistencia y estructura en un conjunto de actividades. Sabemos cómo hacer algo bien y queremos forzar que otros lo hagan de la misma forma. Ing. de Software
4
Escribiendo un Proceso (un “programa” que otros deben seguir)
Prescribir todas las actividades principales Usa recursos sujeto a restricciones Puede estar compuesto de subprocesos Cada actividad tiene un criterio de entrada y otro de salida Las Actividades están organizadas en una secuencia. Establecer los objetivos de cada actividad. Ing. de Software
5
Modelos de Proceso de Software
Prescripciones de la forma en que el desarrollo de software debería llevarse a cabo. Descripciones de la forma en que el desarrollo se lleva a cabo realmente. Cada modelo de desarrollo de software incluye los requerimientos del sistema como entrada y el producto librado al uso como salida. Ing. de Software
6
Modelo Cascada ANALISIS DE REQUERIMIENTOS DISEÑO DEL SISTEMA DISEÑO DE
PROGRAMAS IMPLEMENTACION DE PROGRAMAS PRUEBA UNITARIA Y DE INTEGRACION PRUEBA DEL SISTEMA PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO Ing. de Software
7
(Proceso de desarrollo en la realidad)
ANALISIS DE REQUERIMIENTOS DISEÑO DEL SISTEMA DISEÑO DE PROGRAMAS IMPLEMENTACION DE PROGRAMAS PRUEBA UNITARIA PRUEBA DE INTEGRACION PRUEBA DEL LIBRAR AL USO MANTENIMIENTO Ing. de Software
8
Cascada c/prototipos Validar Verificar PROTOTIPADO ANALISIS DE
REQUERIMIENTOS DISEÑO DEL SISTEMA Validar DISEÑO DE PROGRAMAS Verificar IMPLEMENTACION DE PROGRAMAS PROTOTIPADO PRUEBA UNITARIA Y DE INTEGRACION PRUEBA DEL SISTEMA PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO Ing. de Software
9
Modelo V OPERACION Validar requerimientos Y MANTENIMIENTO ANALISIS DE
DISEÑO DEL SISTEMA DISEÑO DE PROGRAMAS IMPLEMENTACION DE PROGRAMAS PRUEBA UNITARIA Y DE INTEGRACION PRUEBA DEL PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO Verificar diseño Validar requerimientos Ing. de Software
10
Modelo de Prototipación
LISTA DE REVISIONES PROTOTIPAR REQUERIMIENTOS DISEÑO SISTEMA PRUEBA LIBRADO AL USO DEL SISTEMA (a veces informales o incompletos) revisar prototipo revisión de usuario/ cliente Ing. de Software
11
(orientada al problema)
Especificación Operacional: los requerimientos se ejecutan utilizando un producto de software Ejecutar y Revisar ESPECIFICACION OPERACIONAL (orientada al problema) ESPECIFICACION TRANSFORMADA (orientada a la implementación) PRUEBA SISTEMA LIBRADO AL USO REQUERIMIENTOS DEL SISTEMA (a veces informales o incompletos) Ing. de Software
12
Modelo Transformacional
Comparar con requerimientos; actualizar si se necesita REGISTRO FORMAL DEL DESARROLLO Secuencia de transformaciones + sus justificaciones TRANSFORM. N . ESPECIFICACION FORMAL TRANSFORM. 2 PRUEBA TRANSFORM. 1 SISTEMA LIBRADO AL USO REQUERIMIENTOS DEL SISTEMA (a veces informales o incompletos) Ing. de Software
13
Desarrollo en Fases DESARROLLA- Sistemas en Desarrollo DORES USUARIOS
Sistemas en Producción DESARROLLA- DORES USUARIOS Construir liberación 1 Usar Lib. 1 liberación 2 Usar Lib. 2 liberación 3 Usar Lib. 3 Tiempo Ing. de Software
14
Incrementos e Iteraciones
DESARROLLO INCREMENTAL DESARROLLO ITERATIVO Ing. de Software
15
Modelo Espiral Planificar Determinar Objetivos, Alternativas y
Restricciones Evaluar Alternativas y Riesgos start Requirims, plan ciclo/vida Presupto1 Alternativas1 Restriccs1 An. Riesgos1 An.Riesgos2 An.Riesgos3 Análisis de Riesgos4 Restriccs2 Restriccs3 Restriccs4 Prespto2 Prespto3 Prespto4 Alternativas2 Alternativas3 Alternativas4 Prototipo1 Proto- tipo2 tipo3 tipo4 Concepto de operacion Reqs. de Software Requers. Validados Plan de Desarrollo Plan de Integracion y Pruebas Diseño de Software Diseño Validado, y verificado Diseño Detallado Codificación Prueba Unitaria Prueba del Sistema Prueba de Aceptación Implantación Modelo Espiral Ing. de Software
16
RAD - Desarrollo Rápido de Aplicaciones
El Desarrollo rápido de aplicaciones (o RAD) definido por James Martin a principios de la década de 1980, consiste en un ciclo de desarrollo corto basado en tres fases (Requisitos, Diseño y Construcción) con un plazo de entrega ideal de 90 a 120 días como máximo. Ing. de Software
17
DSDM (Método de Desarrollo de Sistema Dinámico)
El se desarrolló para completar lo que le faltaba al método RAD al proporcionar una estructura que tome en cuenta el ciclo de desarrollo completo. Las características principales del método DSDM son las siguientes: Participación del usuario Desarrollo iterativo y creciente Frecuencia de entrega mejorada Pruebas integradas en cada fase La aceptación de los productos entregados depende directamente del cumplimiento de los requisitos. Ing. de Software
18
Método: Proceso Unificado
Es un proceso de desarrollo iterativo y creciente. Esto significa que el proyecto se divide en fases más cortas y que se envía una nueva versión gradual al final de cada fase. Este enfoque está basado en el modelo UML para la descripción de la arquitectura del software (funcional, de aplicación y física) y para el desarrollo del caso del usuario. Dicho modelo describe los requisitos y las demandas del usuario. Ing. de Software
19
RUP. Proceso Unificado Racional
Es un método de desarrollo iterativo promovido por la compañía Rational Software, que fue comprada por IBM. El método RUP especifica, principalmente, la constitución del equipo y las escalas de tiempo, así como un número de modelos de documento. Ing. de Software
20
Método XP El método XP (Programación extrema) define un conjunto de prácticas óptimas para el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo una cercana relación con dicho cliente. La Programación extrema se basa en los siguientes conceptos: Los equipos de desarrollo trabajan directamente con el cliente durante ciclos cortos de una o dos semanas como máximo. La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos para maximizar la interacción con el usuario. Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja en el código. El código se prueba y depura a lo largo del proceso de desarrollo. Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de desarrollo. Ing. de Software
21
Modelo de Proceso y de Ciclo de Vida
La preocupación por el “Proceso” (fin de los ’80) es más reciente que la definición del “Ciclo de Vida” (fin de los ’60) En general se asocia a la noción de modelo de proceso un mayor detalle y precisión Los modelos previos presentan en general poco nivel de detalle y fueron propuestos originalmente como modelos de Ciclo de Vida Ing. de Software
22
Herramientas y Técnicas para el Modelado de Procesos
Elegir un lenguaje o notación Tener claro objetivos del modelo Detalle (granularidad) Describir-prescribir Predecir (requiere agregar relaciones cuantitativas entre elementos) Ejecutar (asistir en el uso) Vamos a ver algunos ejemplos… Ing. de Software
23
Preguntas 1. How does the description of a system relate to the notion of process models? For example, how do you decide what the boundary should be for the system described by a process model? 2. For each of the process models described in this lesson, what are the benefits and drawbacks of using the model? 3. For each of the process models described in this lesson, how does the model handle a significant change in requirements late in development? 4. Should a development organization adopt a single process model for all of its software development? Discuss the pros and cons. 5. Consider the processes introduced in this lesson. Which ones give you the most flexibility to change in reaction to changing requirements? Ing. de Software
24
Modelo ETVX Entry Task Verification eXit
Entry: Condiciones necesarias para poder cumplir una tarea Task: Tarea que se lleva a cabo Quién y con qué responsabilidad Verification: Criterios para verificar que concluyó de forma adecuada (a veces se le menciona como Validation) eXit: Resultados a obtener Ing. de Software
25
Notación de Lai Artefacto, subartefacto, Actividad,subActividad, Rol, Operación, Análisis Tablas de estado muestran información referida a cuán completo está un artefacto en un instante dado Tablas de estado muestran cómo puede operar el proceso sobre los artefactos Diagramas de transición de estado muestran cómo se relacionan unos estados con otros (máquina de estados compuestos) Formularios para definir cada tipo de elemento (en los que se especifican las relaciones) Ing. de Software
26
Lai- relaciones entre elementos
proceso artefacto Sub-actividad Sub-artefacto Ejecuta Manipula Actividad Artefacto Rol Ejecuta Operación cambia Ejecuta Refiere a Análisis compuesto por Estado A(rtefacto) Refiere a controla Estado-P(roceso) Ing. de Software
27
Lai – Formulario para operación
Componente Definición Pre-Condición Predicado en Estado-A para poder realizarla Artefacto El artefacto manipulado por la operación Acción La función a ser relizada por la operación Rol Lista de roles habilitados Post-Condición Predicados sobre Estado-A Ing. de Software
28
Modelo de Factores que inciden en la productividad (Abdel-Hamid 96)
Porción de personal experiente % completado del proyecto Productividad potencial nominal de personal nuevo Productividad potencial nominal de personal experiente Multiplicador de aprendizaje Productividad potencial promedio nominal Productividad potencial Productividad de Desarrollo Porción real de persona-día en el proyecto Pérdidas por motivación y comunicación Esfuerzo adicional de comunicación Tamaño del equipo Presión del Calendario Sobre/bajo Tolerancia del trabajo Ing. de Software
29
Estructura del Desarrollo de Software (Abdel-Hamid 96)
PRODUCCION DE SOFTWARE GESTION DE RRHH Pérdidas del Proceso Productividad potencial Tasa de incorporación de personal Tasa de bajas Detección y Corrección de Errores Tasa de Desarrollo de SW Productividad Real Mezcla de experiencia del personal Esfuerzo de Q A Personal Tasa de Errores Aprendizaje Presión del Calendario Productividad Percibida Nivel de Personal percibido como necesario Tareas percibidas como terminadas Nivel de precisión en medir el avance Fecha Planificada de Terminación Ajustes a Personal y Calendario Esfuerzo faltante percibido Fecha estimada de Terminación Estado percibido del proyecto CONTROL PLANIFICACION Ing. de Software
30
Modelado de Proceso ¿Para qué?
Entender el proceso (real o propuesto) Revelar inconsistencias, problemas (base para la mejora) Simulación del proceso y planificación del proyecto Poco nivel de detalle adicional necesario Factores que afectan la productividad global. Relaciones (cuantificadas) entre los factores. Soportados por sw que simulan el proceso. Guía en la ejecución real del proceso Se precisa agregar múltiples detalles Ing. de Software
Presentaciones similares
© 2024 SlidePlayer.es Inc.
All rights reserved.