Académique Documents
Professionnel Documents
Culture Documents
PROCESO SOFTWARE
• Inspeccionar el código
• Primero hazlo correcto, después hazlo rápido
• La gente es la clave del éxito
• Introduce las mejoras con cuidado
• Asume tus responsabilidades
• La entropía del software es creciente
Componentes de la Ingeniería del Software
• Métodos:
actividades necesarias para construir el software
• Técnicas:
formas concretas de llevar a cabo los métodos
• Formalismos:
notaciones utilizadas por las técnicas
• Herramientas:
implementan las técnicas
• Procedimientos:
establecen el orden en que se aplican los métodos
Las tres P de la Ingeniería del
Software
Las claves del éxito en un proyecto
El Proceso de Resolución de Problemas
• Identificar el problema
• Definir y representar el problema (qué hacer)
• Explorar las posibles estrategias (cómo hacerlo)
• Aplicar la mejor estrategia (hacerlo)
• Mirar atrás y evaluar los efectos de la actividad
realizada (probar el resultado)
• Se resolvió el problema (usar el resultado)
El Proceso de Construcción de Software
• Es un proceso de resolución de problemas: transformación
de una necesidad en una solución automatizada que
satisface la necesidad:
– Qué: Obtención de requisitos: analizar el problema
– Cómo: Diseñar el sistema
• Diseño de alto nivel o preliminar: descomposición del sistema en
componentes y sus relaciones
• Diseño de bajo nivel o detallado: especificación de la función de cada
componente
– Hacerlo: Implementar
– Probar: Pruebas
– Usar: Implantación y Uso
– Mantenimiento (otro proceso de resolución problemas)
Proceso Software vs. Ciclo de Vida
• El Proceso Software como proceso de transformación:
recibe unas entradas y genera unas salidas
• El Producto Software va pasando por una serie de
estados a medida que se transforma:
– Necesidad
– Especificación de requisitos
– Diseño del sistema
– Código
– Sistema software operativo
• Ciclo de Vida: estados por los que pasa el producto
desde que nace hasta que muere
Proceso Software vs. Ciclo de Vida
Obtención Diseñar
PROCESO DE Codificar Probar
CONSTRUCCIÓN requisitos sistema
Requisitos
Diseño
Codificación
Prueba
Operación
Modelo clásico o en Cascada
• Royce-1970
• Orden lineal en las transiciones entre fases
• Vuelta atrás al detectar Equivocaciones
• Asume que:
– Los requisitos se pueden conocer completamente y sin ambigüedad
al principio del proceso de desarrollo
– Los requisitos no varían
– Cada etapa implica una revisión
– No se pasa a la siguiente etapa hasta que se completa la actual
• Implica que:
– Los requisitos pueden quedarse obsoletos
– No hay un ejecutable que enseñar al usuario hasta el final
– 99% de recursos consumidos - errores irremediables
Coste de cada etapa
• Según Boehm (1975):
Pruebas
unidad
Pruebas
componente
Integración
software
Pruebas
sistema
Integración
sistema
Modelo en V
• Énfasis en:
– Validación de los productos
– Proceso de análisis (descomposición) y síntesis
(composición)
• El producto de cada etapa:
– Es la entrada para la siguiente
– Determina los criterios para validar el resultado de la
composición
• Considera sistemas que engloban componentes
software y otros
Refinamiento Sucesivo o Mejora
Iterativa
• Etapas y orden igual que en el cascada
• Dentro de cada etapa los productos se
generan de forma iterativa, refinándose en
cada ciclo
Emisión Gradual
• Varias versiones sucesivas
• En cada versión se incorporan nuevas funciones
• De las funciones más esenciales a las menos
importantes
• Modelo usual en productos comerciales
• Es una mejora iterativa a nivel global
Estándar MIL-STD-2167 (1987)
• Fuerzas armadas de EEUU
• Como normativa para los contratistas
• Especifica, además de las etapas:
– Los productos a entregar
– Las revisiones a efectuar
– Las técnicas a emplear
– La forma de descomponer el producto para la gestión
de la configuración: CSCI (Computer Software
Configuration Item) - CSC (Component) - CSU (Unit)
• Complejo y detallado
Estándar MIL-STD-2167 (1987)
• Etapas:
– Análisis de Requisitos del Sistema
– Diseño del Sistema
– Análisis de Requisitos del Software
– Diseño Preliminar
– Diseño Detallado
– Codificación y Verificación de CSUs
– Integración y Verificación de CSCs
– Prueba de CSCIs
– Integración y prueba del sistema
Estándar ESA PSS-05-0
• Agencia Espacial Europea
• Como normativa para los contratistas
• Etapas:
– Definición de requisitos del usuario
– Definición de requisitos del software
– Diseño de la arquitectura
– Diseño detallado y producción del software
– Transferencia de la tecnología al usuario
– Operación y mantenimiento
• Simple y de alto nivel
Prototipado
• Cuándo:
– El cliente no sabe bien lo que quiere
– No se comprende bien lo que quiere
– No se está seguro de la viabilidad de la solución
• Objetivo: producir una versión de funcionalidad
reducida en las fases iniciales del proceso de
desarrollo
– En papel, describiendo la interacción
– Ejecutable: tiene su propio ciclo de vida
• El prototipo es evaluado por el usuario y se refina
la especificación de requisitos
Tipos de Prototipos
• Desechable:
– sólo se incorporan los aspectos peor entendidos o
dudosos
– desarrollo ‘quick and dirty’
• Maqueta:
– ejemplo de la interfaz que muestra las entradas y salidas
y la forma de interacción
– con datos y encadenamientos forzados
• Prototipo evolutivo:
– el prototipo se desarrolla rigurosamente
– fácil de ampliar y modificar
– se van incorporando las partes mejor entendidas
Prototipado
• Etapas:
– Análisis preliminar y especificación de
requisitos
– Diseño e implementación del prototipo
– Prueba del prototipo
– Refinamiento iterativo del prototipo
– Refinamiento de la especificación de requisitos
– Diseño e implementación del sistema final
Modelo en Espiral
Costes acumulados
Evaluación de alternativas,
Determinación de objetivos, identificación de riesgos
alternativas, restricciones
Análisis
deriesgo
Análisis
deriesgo
Análisis
deriesgo
Análisis Prototipo Prototipo Prototipo
deriesgo
Revisión Prototipo operativo
• Salidas:
– Modelo de ciclo de vida seleccionado
Iniciación del Proyecto (3)
• Actividades:
– Hacer corresponder las actividades del estándar con el
modelo de ciclo de vida seleccionado
• Asignando un responsable (puesto) de controlar que la
actividad se completa en el plazo y presupuesto planeados, y
de la calidad de los productos de salida.
– Asignar recursos
• Humanos, de equipamiento, de espacio, etc.
– Establecer el entorno del proyecto
• Metodologías, estándares, herramientas, librerías de software,
software comercial, ... a utilizar en el proyecto
– Planificar la gestión del proyecto (iterativa)
Iniciación del Proyecto (3) (ii)
• Planificar la gestión del proyecto:
• Definir la organización del proyecto y asignar responsabilidades
• Seleccionar estándares, metodologías y herramientas de:
– Gestión de configuración
– Garantía de calidad
– Verificación y validación
– Entrenamiento
– Documentación
– Desarrollo
• Definir la programación temporal, el presupuesto y los recursos
humanos del proyecto
• Definir procedimientos para:
– Soporte
– Retiro
– Gestión de problemas
– Seguimiento
Iniciación del Proyecto (3) (iii)
• Salidas:
– Plan de Gestión del Proyecto
– Plan de retirada
– Plan de gestión de problemas
– Plan de actividades de apoyo
– Lista de actividades no aplicables
– Asignación de recursos a actividades
Monitorización y Control del proyecto (3)
• Actividades (iterativas):
– Analizar riesgos:
• Técnicos, económicos, de operación, de soporte, de tiempo, ...
– Elaborar planes de contingencia
• Acciones a tomar en caso de que un riesgo se materialice
– Gestionar el proyecto
• Revisar y medir el progreso del proyecto con respecto a sus hitos y el
gasto con respecto al presupuesto
• Gestión del proyecto día a día
– Mantener registros
• Documentos y registros provenientes de diversos procesos
– Implementar el método de comunicación de problemas
• Según el procedimiento especificado
Monitorización y Control del proyecto (3)
(ii)
• Salidas:
– Análisis de riesgos
– Planes de contingencia
– Informes de gestión del proyecto
– Registros históricos del proyecto
– Información de gestión de problemas
Gestión de la Calidad del Software
(4)
• Actividades:
– Planificación de la Gestión de la Calidad
• Identificar actividades de Garantía de Calidad
• Objetivos de calidad, Metas y estándares
• Organización, herramientas, metodologías y técnicas
– Definición de métricas
• De producto y de proceso
• Métodos de recolección y análisis
– Gestión de la Calidad del Software
• Según el Plan de Gestión de la Calidad
– Identificar necesidades de Mejora de la Calidad
• Partiendo, fundamentalmente, de los resultados de las actividades de
Validación y Verificación
Gestión de la Calidad del Software (4)
(ii)
• Salidas:
– Plan de Gestión de la Calidad
– Definición de métricas y métodos de
recolección y análisis
– Valoraciones de la Calidad del Proyecto
– Recomendaciones de mejora
Verificación y Validación (6)
• Actividades:
– Planificación de la Verificación y Validación
• Para cada proceso y producto del proceso
• Auditorías, revisiones, inspecciones, demostraciones formales,
prototipado, ...
– Ejecución de las tareas de V&V
• Según el plan
– Recolección y análisis de datos de métricas
• Según se especificó en Gestión de la Calidad
– Planificación de las Pruebas
• Actividad de V&V especialmente importante
– Desarrollo de especificaciones de Prueba
– Ejecución de las Pruebas
• Según el plan
Verificación y Validación (6) (ii)
• Salidas:
– Plan de V&V del Software
– Informes de V&V
– Informes de métricas
– Plan de Pruebas
– Informes de las pruebas
– Software probado
Gestión de la Configuración (4)
• Actividades:
– Planificación de la Gestión de la Configuración
– Identificación de la Configuración
• Esquema de etiquetado
• Líneas base
– Control de la Configuración
• Seguimiento de cambios
– Contabilidad del Estado de la Configuración
• Generación de informes
• Salidas:
– Plan de Gestión de la Configuración
– Identificación de la Configuración
– Elementos bajo control
– Información de estado de la configuración
Desarrollo de Documentación (3)
• Actividades:
– Planificación de la Documentación
• responsables, fechas, estándares, fuentes, destinatarios
– Documentar
• Según el plan
– Producir y distribuir Documentación
• Hacer llegar la documentación a sus destinatarios
• Salidas:
– Plan de documentación
– Documentación publicada
Entrenamiento (4)
• Actividades:
– Planificar el Programa de Formación
• Necesidades de formación
• Fechas, recursos, destinatarios
– Desarrollar materiales de formación
– Validar el Programa de Formación
• Por un grupo de evaluadores
– Implementar el Programa de Formación
• Salidas:
– Plan de Formación
– Personal formado
Relación Modelo-Ciclo de Vida-Plan
• Modelo de ciclo de vida:
– abstracción de las fases o estados por los que pasa un producto software a lo
largo de su vida
• Ciclo de vida:
– es la secuencia ordenada de actividades o instancias de actividades que se
deben ejecutar a lo largo de la vida del software, indicando quién tiene la
responsabilidad de ejecutarlas.
– Se obtiene haciendo corresponder las actividades del estándar con un
modelo de ciclo de vida concreto: Mapa de Actividades
– Cada proyecto debe definir su propio ciclo de vida
• Plan del proyecto:
– A la información del ciclo de vida se añade la programación temporal
(schedule) y la asignación de recursos.
Mapa de Actividades
ACTIVIDADES FA RS DP DD CO IN IM OM RE
Identificar posibles modelos de ciclo de vida a aplicar X
Seleccionar el modelo de ciclo de vida del proyecto X
Hacer corresponder las actividades del estándar con el X
modelo de ciclo de vida seleccionado
Asignar recursos X X X X X X X X X
Establecer el entorno del proyecto X X X
Planificar la gestión del proyecto X X
Analizar riesgos: X X X X X X X
Elaborar planes de contingencia X X X X X X
Gestionar el proyecto X X X X X X X X X
Mantener registros X X X X X X X X
Implementar el método de comunicación de problemas X X X X X X X X X
Planificación de la Gestión de la Calidad X X
Definición de métricas X X X
Gestión de la Calidad del Software X X X X X X X X X
Identificar necesidades de Mejora de la Calidad X X X X X X X X X
...