00 PROCESOS DE SOFTWARE.ppt

(1)

Ing. Iván Soria Solís Ing. Iván Soria Solís Rev. 1.04 Abril 2014 Rev. 1.04 Abril 2014

(2)

1.- El proceso del Software

(3)

Proceso

(4)

El Proceso del Software

Principales estándares y modelos

La Ingeniería del Software es una ingeniería muy joven que necesita:



Definirse a sí misma: ¿Cuáles son las áreas de conocimiento que la comprenden?



Definirse a sí misma: ¿Cuáles son las áreas de conocimiento que la

comprenden?



Definir los procesos que intervienen en el desarrollo, mantenimiento y operación del software



Definir los procesos que intervienen en el desarrollo, mantenimiento y

operación del software



De las mejores prácticas, extraer modelos de cómo ejecutar esos procesos para evitar los problemas de la “crisis del software”



De las mejores prácticas, extraer modelos de cómo ejecutar esos

procesos para evitar los problemas de la “crisis del software”



Definir estándares menores para dibujar criterios unificadores en requisitos, pruebas, gestión de la configuración, etc.



Definir estándares menores para dibujar criterios unificadores en

requisitos, pruebas, gestión de la configuración, etc.

SWEBOK: Software Engineering Body of knowledge

ISO/IEC 12207: Procesos del ciclo de vida del software

CMM / CMMI

ISO/IEC TR 15504

(5)

ISO 12207: Propósito

El estándar no prescribe:

 Que deba emplearse ningún tipo de documentación específica.  Que deba emplearse un tipo específico de ciclo de desarrollo.

 Métodos concretos para el desarrollo, mantenimiento u operación del software.

Define el QUÉ, no el CÓMO.

Dice cuáles son los procesos, actividades y tareas implicados en el desarrollo, mantenimiento y operación de los sistemas de software,

asentando un marco estándar de referencia internacional, pero no se ocupa ni prescribe técnicas específicas.

Define el QUÉ, no el CÓMO.

Dice cuáles son los procesos, actividades y tareas implicados en el desarrollo, mantenimiento y operación de los sistemas de software,

asentando un marco estándar de referencia internacional, pero no se ocupa ni prescribe técnicas específicas.

El estándar sirve de referencia desde dos perspectivas diferentes:

•Para la adquisición de sistemas y servicios de software.

•Para el suministro, desarrollo, mantenimiento y operación de productos de software. El estándar no cubre el desarrollo de productos de software para distribución comercial masiva (productos “en caja”).

No se trata de un estándar de certificación, tipo ISO 9000, sino de un estándar para la normalización.

(6)

ISO 12207: Propósito

Establece un marco común para el ciclo de vida del software en los procesos de:

 Adquisición, suministro, desarrollo, operación y mantenimiento del software  Gestionar, controlar y mejorar el marco

 Como base de referencia para el trabajo e intercambio entre organizaciones de software Establecer un estándar para evitar una situación de Torre de Babel en la

gestión e ingeniería del software, proporcionando un marco y un lenguaje común en la disciplina del software

Establecer un estándar para evitar una situación de Torre de Babel en la gestión e ingeniería del software, proporcionando un marco y un lenguaje común en la disciplina del software

Periodo de tiempo que comienza al concebir la idea de un nuevo sistema de software, y termina cuando este se retira y deja de funcionar.

Ciclo de vida del software

El Proceso del Software

(7)

ISO 12207



ISO 12207 define los procesos que componen el ciclo de vida del software

Ciclo de vida

Concepto

Retirada

Proceso 1

… Proceso N

Actividad 1

Tarea 1 Tarea 2 … Tarea n

…

Actividad n

Tarea 1 Tarea 2 … Tarea n

(8)

ISO 12207



ISO 12207 establece un nexo con la Ingeniería de sistemas al considerar al

software como parte de un sistema.



Desde esta perspectiva se establece a la Ingeniería de sistemas como fundamento de la Ingeniería del Software.

¿Qué es un sistema?

“Colección de componentes organizados para cumplir una función o conjunto de funciones específicas”.

IEEE Standard 610.12-1990

Elemento del sistema Elemento del

sistema

sistema Elemento del

sistema

Sistema de Entrada

Sistema de Salida Sistema

“Colección de elementos relacionados de forma que puedan realizar un objetivo

(9)

ISO 12207: Procesos

Procesos primarios

Procesos de soporte

Procesos organizacionales

Adquisición Adquisición Suministro Suministro Desarrollo Desarrollo Operación Operación Mantenimiento Mantenimiento Documentación Documentación

Gestión de configuración

Control de calidad

Verificación Verificación Validación Validación Reuniones Reuniones Auditoría Auditoría

Resolución de problemas

Gestión Gestión Mejora Mejora Infraestructura Infraestructura Formación Formación

(10)

Ciclo de vida del software

VISIÓN GENERAL DE LOS PROCESOS, RELACIONES Y ROLES

Adquiriente

PROCESO DE ADQUISICIÓN

PROCESO DE SUMINISTRO

PROCESO DE OPERACIÓN

PROCESO DE MANTENIMIENTO

PROCESO DE

MANTENIMIENTO PROCESO DE

DESARROLLO PROCESO DE DESARROLLO Suministrador Suministrador Operador Usuario Operador Usuario Desarrollador Mantenedor Desarrollador Mantenedor Usuario del proceso de soporte Usuario del proceso de soporte Gestor Gestor P R O C E S O S D E S O P O R T E  Documentación  Gestión de la

configuración

 Aseguramiento calidad  Verificación

 Validación

 Reuniones de seguimiento  Auditoría

 Resolución de problemas

(11)

Ciclo de vida del software

Modelos de ciclo de vida para el desarrollo

La aplicación de los procesos, tanto en el desarrollo como en el posterior

mantenimiento y operación del software, se dibuja a través de unos “patrones fijos” que configuran el esquema de mapa de situación, relación y continuidad entre los diferentes procesos, actividades y tareas.

En la etapa de desarrollo los patrones básicos son:



Desarrollo en cascada. (o variante secuencial)



Desarrollo en espiral.

Una vez desarrollada la primera versión, el ciclo de vida del sistema discurre en cada momento según uno de los siguientes patrones.



Desarrollo incremental del sistema.



Desarrollo evolutivo del sistema.

Sobre estos patrones básicos, en las diferentes etapas del ciclo de vida pueden intervenir como modificadores los siguientes factores:



Prototipado.



Concurrencia.



Componentes comerciales y reutilización.

(12)

Ciclo de vida del software

Modelos de ciclos de vida

CASCADA

ESPIRAL

ESPIRAL MODELOS

CICLOS DESARROLLO MODELOS CICLOS DEVIDA DE SISTEMAS

INCREMENTAL INCREMENTAL EVOLUTIVO EVOLUTIVO CASCADA CASCADA CONCURRENCIA CONCURRENCIA

COMPONENTES COMERCIALES Y REUTILIZAZIÓN

(13)

Ciclo de vida del software

Modelos de ciclos de desarrollo

Cascada

Requisitos

Diseño

Codificación

Pruebas

Integración

(14)

Ciclo de vida del software

Modelos de ciclo de desarrollo

Cascada

[1]

Cascada

[1]

El modelo en cascada refleja la necesidad impuesta por la realidad de retornar con frecuencia desde una fase hacia las anteriores con la información generada al

avanzar el desarrollo.

Este modelo, como el anterior, reconoce la importancia de disponer de unos

requisitos y un diseño previo antes de comenzar con la codificación del sistema, pero al mismo tiempo se enfrenta al hecho de que en la realidad la dificultad que supone disponer de documentación elaborada de requisitos y diseño antes de empezar a codificar puede actuar como una barrera que bloquee el comienzo de la siguiente fase.

Por estas razones el modelo no se ha hecho muy popular, y los equipos que lo aplican pueden caer en la tentación de comenzar con el diseño o incluso con la codificación, sin tener un conocimiento suficiente de los requisitos.

Resulta apropiado para:



Desarrollar nuevas versiones de sistemas ya veteranos en los que el desconocimiento de las necesidades de los usuarios, o del entorno de operación no plantean riesgos.



Sistemas pequeños, sin previsión de evolución a corto plazo.

(15)

Ciclo de vida del software

Modelos de ciclo de desarrollo

(16)

Ciclo de vida del software

Modelos de ciclo de desarrollo

Espiral

El ciclo de iteración de este modelo evolutivo se convierte en una espiral, que al

representarse sobre ejes cartesianos muestra en cada cuadrante una clase particular de actividad: Planificación, Análisis de riesgo, Ingeniería y Evaluación, que se

suceden de forma consecutiva a lo largo del ciclo de vida del desarrollo

•En la planificación de cada vuelta se establece el contexto del desarrollo y se decide qué parte del mismo se abordará en el ciclo siguiente.

•Las actividades de análisis de riesgo evalúan las alternativas posibles para la ejecución de la siguiente parte del desarrollo, seleccionando la más ventajosa y previendo los riesgos posibles.

•Las actividades de ingeniería corresponden a las indicadas en los modelos lineales (secuencial y cascada): análisis, diseño, codificación, etc.

•Las actividades de evaluación analizan los resultados de la fase de ingeniería, tomando el resultado de la evaluación como punto de partida para el análisis de la siguiente fase.

(17)

Ciclo de vida del software

Modelos de ciclos de evolución

Incremental

R E Q U IS IT O S R E Q U IS IT O

S DiseñoDiseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración Mantenim.Operación

Operación

Mantenim. Sub-sistema

Diseño

Diseño CodificaciónCodificación PruebasPruebas IntegraciónIntegración Operación Mantenim.

Operación

Mantenim. Sub-sistema

Diseño

Diseño CodificaciónCodificación PruebasPruebas ……

SISTEMA

El modelo incremental mitiga la rigidez del modelo en cascada, descomponiendo el desarrollo de un sistema en partes; para cada una de las cuales se aplica un ciclo de desarrollo (en cascada en la representación gráfica siguiente).

Las ventajas que ofrece son:



El usuario dispone de pequeños subsistemas operativos que ayudan a perfilar mejor las necesidades reales del sistema en su conjunto.



El modelo produce entregas parciales en periodos cortos de tiempo,

(18)

Ciclo de vida del software

Modelos de ciclos de evolución

Incremental

Aunque en la representación gráfica de la figura anterior, los desarrollos de cada subsistema se solapan en el tiempo, en su aplicación real, el segundo y siguientes subsistemas pueden comenzar una vez concluido el anterior.

Resulta apropiado:

•Desarrollo de sistemas en los que el cliente necesita disponer de parte de la funcionalidad antes de lo que costaría desarrollar el sistema completo.

(19)

Ciclo de vida del software

Modelos de ciclos de evolución

Evolutivo

Diseño

Operación

Mantenim. Sistema

Este modelo está compuesto por varios ciclos de desarrollo. Cada uno de ellos produce un sistema completo con el que se operará en el entorno de operación. La información acumulada en el desarrollo de cada sistema, y durante su fase de operación sirve para mejorar o ampliar los requisitos y el diseño del siguiente. En realidad es un ciclo de vida común a todos los sistemas desarrollados que se mejoran a través de versiones sucesivas.

Requisitos

Diseño

Operación

Mantenim. Sistema

Requisitos

Diseño

Diseño …… Requisitos

(20)

Ciclo de vida del software

Modelos de ciclos de evolución

Evolutivo

Las circunstancias en las que este modelo puede resultar apropiado son



Desconocimiento inicial de todas las necesidades operativas que serán

precisas, generalmente por tratarse del desarrollo de un sistema que operará en un entorno nuevo sin experiencia previa.



Necesidad de que el sistema entre en operación en tiempos inferiores a los que serían necesarios para diseñarlo y elaborarlo de forma exhaustiva.



Necesidad de desarrollar sistemas en entornos cambiantes (sujetos a normas legislativas, mejora continua del producto para hacer frente a desarrollos de la competencia, etc.).

(21)

Ciclo de vida del software

Creación del modelo de ciclo de vida

Al iniciar el proyecto, el responsable de la arquitectura de procesos debe realizar los siguientes pasos:



Análisis de las circunstancias ambientales del proyecto.



Diseño del modelo específico de ciclo de vida para el proyecto (sobre las bases de los diseños más apropiados, para el desarrollo y la evolución del sistema de software.



Mapeo de las actividades sobre el modelo.



Desarrollo del plan para la gestión del ciclo de vida del proyecto. Debe considerar aspectos como:



Posibilidad de descomposición del sistema en subsistemas de software



Estabilidad esperada de los requisitos.



Novedad del proceso o procesos gestionados por el sistema en el entorno del cliente.



Criticidad de las agendas y presupuestos.



Grado de complejidad del interfaz de operación, criticidad de la usuabilidad.

(22)

Suponga que va desarrollar una aplicación relativa a la gestión de pedidos de una empresa. En este caso el cliente no tiene todavía muy claro qué es lo que quiere. Además, el personal informático va a utilizar una tecnología que le resulta completamente nueva. Discútase qué modelo de ciclo de vida es más apropiado para desarrollar esta solución y sustente su respuesta.