ingenierÍa del softwaresiul02.si.ehu.es/~alfredo/iso/tema1.pdf · ingenierÍa del software curso...

1

Ingeniería del Software A. Goñi, J.R. Zubizarreta, J. IturriozDpto. LSI. Facultad de Informática. UPV/EHU

A. Goñi, J.R. Zubizarreta, J. Iturrioz. Dpto. LSI, UPV/EHU

1

INGENIERÍA del SOFTWARECurso 2004/05

Ingeniería en InformáticaFacultad de Informática

UPV/EHU

Departamento de Lenguajes y Sistemas Informáticos


2

Tema 1: Introducción a la Ingeniería del Software

2



3

Índice

• 1. Definición de Ingeniería del Software• 2. Calidad del Software• 3. Proceso de Ingeniería del Producto (Software)• 4. Proceso de Mejora del Proceso de Ingeniería

del Producto⇒ 5. CMM: un modelo para la mejora de

Procesos Software⇒ 6. PSP: Proceso Software Personal

• A modo de conclusión y Bibliografía

Anexo: Proceso Unificado de Desarrollo de Software con UML


4

MotivaciónA las 14:21 de un 15 de enero, hora punta en el tráfico telefónico, el conmutador 4ESS de la red telefónica de Manhattan detectó un pequeño fallo en su hardware. El 4ESS se desconectó de la red tras, amablemente, notificar a los conmutadores vecinos su desconexión. En pocos segundos, el conmutador volvió a funcionar, lo que notificó también a sus vecinos. Pero éstos estaban todavía procesando el primer mensaje cuando recibieron el segundo. Esto les confundió, se dieron cuenta de este desconcierto y se desconectaron de la red para realizar un auto-chequeo y reinicializarse, no sin antes notificar a todos sus vecinos su desconexión. Como una epidemia de gripe, los mensajes se distribuyeron por todo EEEUU. Tan pronto como un conmutador se desconectaba y se recuperaba, recibía un aluvión de mensajes de sus compañeros que le hacían volver a fallar. En el centro de operaciones, los técnicos veían cómo las líneas de comunicaciones del mapa se ponían rojas por todo el país partiendo de Manhattan, mientras que los ingenieros se veían negros siguiendo todos los procedimientos estándar para la solución de problemas, los no estándar y los improvisados. Pero nada funcionó. Un minúsculo error en la versión de diciembre del software del conmutador 4ESS causó el caos. AT&T volvió temporalmente a la versión anterior e instaló la versión corregida cinco días después. Pero el daño ya estaba hecho.

[Arthur, L.J. Improving Software Quality: an Insider’s Guide to TQM. John Wiley & Sons, 1993

3



5

MotivaciónEl 4 de junio de 1996, la lanzadera europea Ariane 5 explotó tras 40 segundos de vuelo, debido a un error de un fragmento de código innecesario. El software culpable pertenecía al sistema de referencia inercial (SRI): antes del despegue, hay que hacer ciertos cálculos para alinear el SRI, aunque estos cálculos pueden finalizar 9 segundos antes del despegue. Pero como existe la posibilidad de que la cuenta atrás se detenga, los ingenieros decidieron mantenerlo hasta 50 segundos después del despegue, puesto que reiniciar el SRI llevaba varias horas. Una vez en vuelo, los cálculos del SRI son inútiles, pero en el Ariane 5 causaron una excepción que no fue interceptada y… ¡boom! La excepción se debió a una conversión de un valor real de 64 bits (inclinación horizontal) a un entero de 16 bits, pero, como no había un manejador por omisión de excepciones, la excepción siguió el destino de todas las excepciones no capturadas, es decir, abortar el software y por tanto los ordenadores de a bordo, y por tanto la misión.

¿Por qué no se controló la excepción? Los análisis habían demostrado que el overflowno podía ocurrir nunca. Lo cual era completamente cierto para las trayectorias del Ariane 4, para el cual había sido diseñado el SRI, no para las nuevas trayectorias del Ariane 5, para el que se había reutilizado el código. Una reutilización que provocó que un error trivial causara la explosión de un cohete de unos 500 millones de dólares.

[Jézéquel, Meyer: “Design by Contract: The Lessons of Ariane”. IEEE Computer 30 (1), 1997]


6

1. Definición de Ingeniería del Software

• Bauer 1972: IS trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales.

• Bohem, 1976: IS es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software.

• Zelkovitz 1978: IS es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software.

4



7


• Mills , 1980: la IS tiene como uno de sus principales objetivos la producción de programas que cumplan las especificaciones, y que se demuestren correctos, producidos en el plazo y coste adecuados.

• Meyer 1988: la IS es la producción de software de calidad. • Ford, 1990: IS es una forma de ingeniería que aplica los

principios de la ciencia de los computadores y matemáticas para conseguir soluciones a los problemas del software de forma efectiva y económica.

• IEEE 1993: IS es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software.



Ingeniería del Software es la INGENIERÍA que trata de construir software de ALTA CALIDAD a BAJO COSTO– INGENIERÍA (IEEE): aplicación de un método sistemático, estructurado y

cuantificable a estructuras, máquinas, productos, sistemas o procesos.– INGENIERÍA (DRAE): conjunto de conocimientos y técnicas que permiten aplicar

el saber científico a la utilización de la materia y fuentes de energía.

A) CALIDAD: definir qué es CALIDAD del SOFTWAREB) INGENIERÍA, PRODUCTO de BAJO COSTO:

definir qué es un buen PROCESO SOFTWARE• PROCESO de INGENIERÍA del PRODUCTO (SOFTWARE):

conjunto de actividades, métodos, prácticas y transformaciones utilizados para desarrollar software y los productos asociados: planes del proyecto, documentos de análisis/diseño, codificación, casos de prueba, manuales de usuario

• Todo es mejorable: MEJORA del PROCESO SOFTWARE

Sección 2

Sección 3

Secciones 4, 5 y 6

5



9

2. Calidad de software

La Calidad de Software se entiende como la combinación de una serie de factores:

– Factores Externos

– Factores Internos: modularidad y legibilidad. Sólo percibidos por los que tienen acceso al código fuente.

⇒ Eficiencia⇒ Portabilidad ⇒ Facilidad de Uso⇒ Funcionalidad⇒ Oportunidad

⇒ Corrección ⇒ Robustez⇒ Extensibilidad⇒ Reusabilidad⇒ Compatibilidad

En principio sólo importan los externos, pero la clave para conseguirlos radica en los factores internos


10

2. Corrección

• Software debe cumplir sus tareas exactamente, debe cumplir su especificación.

• Necesidad de:– realizar especificaciones precisas.– uso de métodos de corrección condicional.

Sistema de Aplicación

Compilador

Sistema Operativo

Hardware

Se supone que estos niveles son correctos

6



11

2. Robustez

– Capacidad de los sistemas software para reaccionar apropiadamente ante condiciones anormales

– Caracteriza el funcionamiento de un sistema fuera de los límites de su especificación

• Caso normal: caso planificado durante el diseño del software (puede ser una entrada errónea)

• Caso excepcional: no previsto en la especificación


12

2. Extensibilidad

• Facilidad de adaptación del software a cambios de especificación, esto es, a nuevos requisitos.

• Las técnicas tradicionales de Ingeniería del Software tendían, en el ciclo de vida del software, a considerar que todos los requisitos se obtenían al principio.

• Principios para conseguir la extensibilidad:– simplicidad en el diseño; una arquitectura

simple es más fácil de adaptar a los cambios– descentralización de módulos; los cambios

afectarán a menos módulos

7



13

2. Reutilización

• Capacidad de los elementos de software de servir para la construcción de muchas aplicaciones diferentes.

• Los sistemas software a menudo siguen patrones similares. Evitar reinventar soluciones a problemas que ya han sido encontrados.– Uso de elementos de software reutilizables– Uso de patrones de diseño

• Se requerirá un menor esfuerzo de programación, que podrá dedicarse a otros factores: corrección, robustez...


14

2. Compatibilidad

• Facilidad para combinar diferentes elementos de software entre sí

• Un sistema software generalmente necesitar interactuar con otros sistemas. – Suelen encontrarse muchos problemas.

• Clave: homogeneidad en el diseño y acordar convenciones estándares de comunicación entre programas:– Usar formatos de archivo estándares– Usar estructuras de datos estándares– Usar interfaces de usuario estándares

8



15

2. Eficiencia

• El software debe aprovechar al máximo los recursos hardware: tiempo del procesador, espacio ocupado de memoria…

Ù La eficiencia no es importante mientras el software no sea correctoÙ Hay que llevar un equilibrio entre eficiencia (necesaria) y

otros factores como extensibilidad y reutilizaciónÙ No se puede infravalorar la eficiencia. Hay que

implementar algoritmos eficientes donde merezca la pena


16

2. Portabilidad

• Facilidad de transportar los productos software a distintos entornos hardware y software

• La portabilidad tiene que ver con variaciones de la máquina hardware-software

(plataforma= hardware + sistema operativo + sistema de ventanas (si se emplea)+ otras herramientas fundamentales)

9



17

2. Facilidad de uso

• Facilidad con la cual otras personas con diferentes formaciones pueden aprender a usar los productos software.– El sistema debe facilitar el manejo para todo tipo

de usuarios: desde usuarios novatos a los que deben proporcionarse explicaciones hasta usuarios expertos que quieren ir al grano.

• Los buenos diseñadores de interfaces siguen la política de no hacer suposiciones sobre los usuarios.– “No suponga que conoce al usuario; realmente no

lo conoce”


18

2. Funcionalidad

• Es el conjunto de posibilidades ofrecidas por el sistema.

• Se debe conocer cuánta funcionalidad es suficiente, pero es difícil...

• Al añadir nueva funcionalidad no se debe perder la consistencia del producto global.

• Al intentar añadir más funcionalidad cuanto antes no hay que olvidar otros factores de calidad.

10



19

2. Oportunidad• Es la capacidad de lanzar a tiempo un sistema

software• Un sistema software debe estar desarrollado

para cuando los usuarios lo necesitan (o antes)• Otros factores:

– Verificabilidad: facilidad para preparar procedimientos de prueba

– Integridad: capacidad para protegerse contra modificaciones y accesos no autorizados

– Reparabilidad: capacidad para facilitar reparación de defectos

– Economía : capacidad de completarse dentro de un presupuesto


20

2. Acerca de la documentación

• La documentación es una consecuencia de los factores de calidad

• Tipos de documentación:– documentación externa facilidad de uso

• Ayuda on-line

– documentación interna extensibilidad• Uso de lenguajes que faciliten la documentación

interna.

– interfaces de los módulosextensibilidad/reusabilidad

• Generación automática de documentación de interfaces.

11



21

2. Acerca del mantenimiento• Etapa que cubre la vida de un sistema software

una vez que este ha sido implantado• Representa el 70 % del coste de desarrollo de

software• ¿Qué es mantenimiento? El software no se

estropea...– Cambios en requerimientos del usuario (42%)– Cambios en los formatos de datos (18 %)– Resto (40%): mejoras eficiencia, documentación,

arreglos de rutinas, cambios hardware,...

La construcción de software extensible y la encapsulación de datos (uso de TADs, clases OO) facilitará el problema del

mantenimiento (al menos en los casos “cambios reqs./formatos”)


22

3. Proceso de ingeniería del producto (software)

• PROCESO DE INGENIERÍA DEL SOFTWARE:– Es un conjunto de actividades junto con unas

restricciones de orden entre ellas que, si se ejecutan apropiadamente, se obtiene como resultado software de alta calidad a bajo costo.

– Un proceso de ingeniería de software es una definición del conjunto completo de actividades necesarias para transformar los requisitos de usuario en un producto. Un proceso es una plantilla para crear proyectos.

• PROYECTO SOFTWARE: Es un elemento organizativo (proyecto) a través del cual se gestiona el desarrollo del software. Es un proyecto de desarrollo donde se APLICA un PROCESO DE INGENIERÍA DEL SOFTWARE

12



23


• PRODUCTO SOFTWARE: Es el RESULTADO de un PROYECTO SOFTWARE. Incluye los modelos de análisis y de diseño, código fuente, ejecutables y documentación.

• PERSONAS: Todas las implicadas tanto en la construcción como en la explotación del software: desarrolladores, arquitectos, ingenieros de prueba, usuarios, clientes...

• HERRAMIENTAS: software que se utiliza para automatizar las actividades definidas en el proceso.


24

PROCESOPlantilla

PERSONAS PROYECTO

PRODUCTO

Resultado

Participan

HERRAMIENTAS

AutomatizadoPor


13



25

• Objetivo del proceso de ingeniería del producto:

conseguir el producto deseado• Dentro del proceso de ingeniería del

producto, se distinguen 3 procesos:– Proceso de desarrollo software– Proceso de gestión del proyecto– Proceso de control de configuraciones



26

3. Proceso de desarrollo software

• Es el responsable de producir el producto deseado (software) y otros productos (manuales de usuario, especificación de los requisitos, …)– Conjunto de actividades que se necesitan para transformar los

requerimientos de un software en un sistema de software.

• Objetivo: desarrollar un producto que satisfaga al cliente

Producto

o Sistema de Software

Requisitos del usuario

PROCESO DE DESARROLLO

Captura de requisitos Análisis Diseño Implementación Pruebas

Actividades a realizar

14



27

• Ofrece un marco de trabajo genérico:– Elementos para representar el diseño de los datos y la

arquitectura del sistema de información

– Elementos para representar los procesos

– Elementos para representar la relación de los usuarios con el sistema

– Modelo de referencia para conseguir construir de manera eficiente el sistema

• Ejemplos de procesos de desarrollo: Merise, SSADM, Métrica, Proceso Unificado de Desarrollo de Software

3. Proceso de desarrollo software

PARTE DINÁMICA

PARTE ESTÁTICA

CICLO DE VIDA

INTERFAZ


28

3. Proceso de gestión del proyecto

• Lleva a cabo el control y la planificación de las actividades de desarrollo para que lleven hacia el objetivo del proyecto

Requisitos del usuario ProductoPROCESO DE

DESARROLLO

Captura de requisitos Análisis Diseño Implementación PruebasActividades

a realizar

Controla y PlanificaPROCESO DE

GESTIÓN DEL PROYECTO

15



29

3. Proceso de gestión del proyecto

• Se trata de realizar una serie de actividades de planificación y control:– del alcance del proyecto– del tiempo– del costo– de recursos humanos– de calidad– de riesgos– …


30

3. Proceso de control de configuraciones• PROBLEMAS:

– Los usuarios cambian los requisitos constantemente– Los desarrolladores quieren cambiar el enfoque técnico– Los gestores quieren modificar el alcance

– Los procesos de DESARROLLO de software no pueden generalmente adaptarse a esos cambios arbitrariamente

• El proceso de control de configuraciones del software trata con dichos cambios para que los objetivos de calidad y costo del software se mantengan, así como la integridad de los productos

Requisitos del usuario ProductoPROCESO DE

DESARROLLO

CAMBIOS CAMBIOS

16



31

3. Proceso de control de configuraciones

• Objetivo: controlar los cambios, sin impedir seriamente cambios justificados

• Elemento de Configuración (EC):

– programa, documento, etc. (artefacto) obtenido durante el proceso de desarrollo y/o gestión, susceptible de sufrir algún cambio

• Línea Base (LB): – Es una especificación o producto que se ha revisado formalmente y

sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior, y que puede cambiarse solamente a través de procedimientos formales de control de cambios. (Estándar IEEE 610.12-1990)

• Los EC pueden convertirse en LB– Antes los cambios pueden realizarse de manera ágil– Pero después, ya no… hay que seguir actividades del proceso de

control de configuraciones


32

3. Proceso de control de configuraciones

• Se trata de realizar una serie de actividades de:– Identificación de elementos de configuración que

probablemente cambien– Control de versiones

• ¿Cómo se controlan los cambios antes y después de que el software se distribuya al cliente?

– Control de cambios• ¿Quién aprueba los cambios y establece prioridades entre ellos?

– Auditoría de la configuración• ¿Cómo se garantiza que los cambios se han llevado a cabo de

manera adecuada?

– Informes de estado• ¿Cómo se comunica a los demás los cambios realizados?

17



33

4. Proceso de Mejora del Proceso de Ingeniería del Producto

• Los procesos de INGENIERÍA DEL PRODUCTO serían suficientes si el PROCESO DE SOFTWARE fuera algo estático

• Pero no lo es ya que ...– cada día se entiende mejor cómo hay que

desarrollar el software– existen nuevas técnicas y herramientas

SE NECESITA UN PROCESO DE GESTIÓN DEL PROCESO DE INGENIERÍA


34

Proceso Software

Procesos de ingeniería del producto

Proceso dedesarrollo

Proceso de gestión del proyecto

Proceso de controlde configuraciones

Proceso de gestión del proceso

CMMSPICEPSP

4. Proceso de Mejora del Proceso de Ingeniería del Producto

18



35

4. Proceso de Mejora del Proceso de Ingeniería del Producto• El PROCESO DE GESTIÓN DEL

PROCESO SOFTWARE tiene como objetivo mejorar dicho proceso, esto es, la capacidad para producir software de alta calidad a bajo costo– Para ello hay que:

• Estudiar el proceso actual, analizando todos los proyectos desarrollados bajo ese proceso.

• Mejorar, basándose en el análisis previo, aquellos aspectos del desarrollo, del control del proyecto y de las configuraciones.


36

5. CMM: un modelo para la mejora de Procesos Software

• CMM (Capability Maturity Model)• Desarrollado por el SEI (Software

Engineering Institute) a partir de 1986• CMM describe una camino de mejora

para que organizaciones que desarrollan software evolucionen desde un proceso software inmaduro a uno más maduro y disciplinado

• Existen otros modelos de mejora: SPICE, BOOTSTRAP, ISO 9000, PSP

19



375. CMM: un modelo para la mejora de Procesos Software

• OBJETIVO: mejorar la calidad de los procesos de desarrollo, gestión y mantenimiento de software.

• Para conseguirlo se aplican las bases de la Gestión de la Calidad Total (Total Quality Management) en la Ingeniería del Software.– Mejorar la gestión de la calidad es, en gran medida, responsabilidad

de la dirección.– La mejora de la calidad debe basarse en mejorar los procesos y no

en las personas.

– Hay que medir la mejora de la calidad.– Se necesitan incentivos para mantener un esfuerzo de mejora.– La mejora de la calidad es un proceso continuo.


38

GESTIÓN TOTAL DE CALIDAD

(TQM)

MEJORA DE PROCESOS SOFTWARE

(CMM)

ORGANIZACIÓN

Proyecto 1 Proyecto 2

Proyecto N SISTEMA

Software

Hardware

20



395. Los 5 niveles de madurez del proceso software

2. Repetible

1. Inicial

3. Definido

4. Gestionado

Proceso disciplinado

Proceso consistente y estándar

Proceso predecible

Proceso de mejora continua

Mal controlado y sin predicción

Se pueden repetir las tareas principales ya realizadas

Los procesos están caracterizados, se entienden superficialmente.

Los procesos están controlados y medidos

El objetivo principal es la mejora del proceso.

5.Optimizado

Gestión de proyectos básica

Proceso de ingeniería

Calidad de procesos y productos

Gestión de cambios

(o Madurez del proceso)

(o Capacidad del proceso)Efectividad del proceso Alto

Bajo


40

Actividad Resultadosda

1. Nivel:Los procesos se realizan.

“Just do it”

Actividad Resultadosda

2. Nivel:Los procesos se piensan antes de realizarlos. Después de realizarlos se verifican que están bien.

Planificar

Evaluar

entrada

mejora

21



41

Estándares

3. Nivel

entrada

entrada

Utilizar lecciones aprendidas

Actividad Resultadosproduce

Planificar

Evaluar

entrada

mejora


42

4. Nivel

Después de predecir los resultados que se esperan hay que crear el entorno para

conseguir los resultados deseados

Estándaresentrada

entrada

Actividad Resultadosproduce

Planificar

Evaluar

entrada

mejora

predice

22



43

5. Nivel

Mejorar las lecciones aprendidas

y utilizar las lecciones aprendidas para crear nuevas lecciones aprendidas

y mejorar más las lecciones aprendidas

y utilizar las lecciones aprendidas para crear nuevas lecciones aprendidas

y..................

Estándaresentrada

entrada

Actividad Resultadosrealiza

Planificar

Evaluar

entrada

mejorar

predice


44

3

6. PSP

• PSP: Personal Software Process– Desarrollado por Watts Humphrey creador a su vez

del CMM– Presenta técnicas y métodos para definir y gestionar

un proceso personal de software• El CMM suministra una infraestructura de

proceso para toda la organización pero no ayudaal ingeniero del software a mejorarindividualmente.

• Una progresión desde el CMM Nivel 3 requiereque los ingenieros apliquen principios de mejorade proceso basados en un enfoque individual.

23



45

6. La medición en un ProcesoDefinido

• Obtener datos históricos es imprescindiblepara una planificación eficiente.

• Las mediciones señalan cuándo y cómo se ejecutan las diferentes tareas del plan.

• Los datos históricos se utilizarán paraevaluar y mejorar el proceso del software.

• PSP utiliza tres tipos de medida:– esfuerzo– tamaño– defectos


46

6

6. PSP Arquitectura Principal

PSP 0Proceso Actual

Registro de Tiemposy Defectos

PSP 1Estimación de Tamaño

Informe de Pruebas

PSP 2Revisión de CódigoRevisión de Diseño

PSP 3Desarrollo Cíclico

PSP 0.1Estandares de CodificaciónMedidas de los Tamaños

Propuestade Mejorade Proceso

PSP 1.1Planificación de Tareas

Planificación de Tiempos

PSP 2.1Diseño de Plantillas

ProcesoCíclico

CalidadPersonal

PlanificaciónPersonal

MediciónPersonal

24



47

Registro deTiempos

Student Date Instructor Program # Date Start Stop Interruption

Time Delta Time

Phase Comments

• Registramos el tiempoutilizado en cada fase del PSP:– Inicio

– Parada– Tiempo de la

interrupción– Fase– Comentarios


48

Registro de Defectos

Student Kim Orihuela Date 10-3-96

Instructor Iraj Program # 3A Date Number Type Inject Remove Fix Time Fix Defect 10-3 1 40 CODE CODE 11 Description: Add variable to structure. Date Number Type Inject Remove Fix Time Fix Defect 10-3 2 20 CODE CODE 1 Description: Misspelled variable. Date Number Type Inject Remove Fix Time Fix Defect 10-3 3 20 CODE COMPILE 1 Description: Missing “ in print statement. Date Number Type Inject Remove Fix Time Fix Defect 10-3 4 10 CODE TEST 39 Description: Align/add print statements - beautify

Defect Types 10 Documentation 60 Checking 20 Syntax 70 Data 30 Build, Package 80 Function 40 Assignment 90 System 50 Interface 100 Environment

• Información de cadadefecto encontradoen la revisión, compilación y prueba.– Número

– Tipo– Fase en la que se

introdujo (Inject)– Fase en la que se

eliminó (Remove)– Tiempo de

búsqueda/fijación– Descripción

25



49

Registro de Defectos (cont.)

• Información de cada defectoencontrado en la revisión, compilación y prueba.– Número– Tipo– Fase en la que

se introdujo

Defect Types10 Documentation 60 Checking20 Syntax 70 Data30 Build, Package 80 Function40 Assignment 90 System50 Interface 100 Environment


50

Resumen del Plan

Student Kim Orihuela Date 9-20-96 Program Standard Deviation Program # 1A Instructor Iraj Hirmanpour Language C Program Size (LOC): Plan Actual Total New&Changed 50 33

Time in Phase (min.) Plan Actual To Date To Date % Planning 2 2 1.6 Design 0 0 0 Code 53 53 44.2 Compile 20 20 16.7 Test 25 25 20.8

Postmortem 20 20 16.7 Total 240 120 120 100.0 Defects Injected Actual To Date To Date % Planning 0 0 0 Design 0 0 0 Code 10 10 100 Compile 0 0 0 Test 0 0 0

Total Development 10 10 100 Defects Removed Actual To Date To Date % Planning 0 0 0 Design 0 0 0 Code 3 3 30 Compile 5 5 50

Test 2 2 20 Total Development 10 10 100 After Development 0 0 0

• El resumen del Plan recoge:– Fechas del Plan de

Proyecto– Resultados

actuales• tamaño• tiempos• defectos

detectados

– Datos acumuladosde los ProyectosPSP

26



51

7. A modo de conclusión

Proceso Software

Procesos de ingeniería del producto

Proceso dedesarrollo

Proceso de gestión del proyecto

Proceso de controlde configuraciones

Proceso de gestión del proceso

•Requisitos

•Análisis •Diseño•Implementación•Pruebas

ADSI

ISO

Para ello, nos apoyaremos en el desarrollo de una práctica. Se entregarán

los requisitos, el análisis y el diseño. Habrá que terminar el diseño y realizar la

implementación y las pruebas.

No pasaremos del nivel 1 de CMM. Hace falta tener un Proceso de Software maduro.

Llevaremos registros de tiempos y defectos.

PyGPI


52

8. Bibliografía

• Libro general sobre Ingeniería del Software:– Ingeniería del Software. Un enfoque práctico.

5ª Edición. Roger S. Pressman. MacGraw-Hill, 2001.• Para la sección 2

– Construcción de Software Orientado a Objetos. 2ª Edición. Bertrand Meyer. Prentice-Hall, 1999. Capítulo 1.

• Para la secciones 5, 6 y 7– The Capability Maturity Model: Guidelines for Improving

the Software Process. M.C.Paulk, C.V.Weber, B.Curtisy M.B.Chrissis. Addison-Wesley

– Introducción al Proceso Software Personal (PSP) Watts S. Humphrey. Addison-Wesley, 2001.

27



53Proceso unificado de desarrollo

CICLO DE VIDA

PARTE DINÁMICA

INTERFAZ

PARTE ESTÁTICA

Debe ofrecer un marco de trabajo

genérico

• Basado en componentes Orientados a Objetos• Utiliza el lenguaje unificado de modelado (UML)• El proceso es:

• Guiado por casos de uso • Centrado en la arquitectura• Con un ciclo de vida iterativo e incremental


54

Persona

Tomar Préstamo

: IU-1 : GestorLibro : Libro elLibro:Libro

1: Introducir Signatura y NumeroDeSocio

2: Aceptar

3: obtenerLibro(signaturaLibro:String)

4: getSignatura()

Se repite hasta que seencuentre un libro

con la signatura queestamos buscando

elLibro

5: getCopias()

6: isCopiaPrestada()

3.- DISEÑO DEL CASO DE USO

4.- IMPLEMENTACIÓN DEL CASO DE USO

5.- PRUEBA DEL CASO DE USO

2.- ANÁLISIS DEL CASO DE USO

1.- CASO DE USO Desarrollo guiado por CASOS DE USO

28



55

1

: IU-1 : Gro

:1:2: 3: 4()

: : Gro

:1:2: 3: 4()

Centrado en la ARQUITECTURA

VISTA DEL MODELO DE CASOS DE USO VISTA DEL MODELO DEL DOMINIO /

VISTA DEL DIAGRAMA DE CLASES

VISTA DEL MODELO DEL ANÁLISISVISTA DEL MODELO DEL DISEÑO

+ VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS

SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS). SÓLO APARECEN LOS QUE CORRESPONDEN A CASOS DE USOS CRÍTICOS

DA UNA IDEA DE LA “FORMA” QUE TIENE EL “SISTEMA COMPLETO”


56Proceso unificado de desarrollo

Requisitos

Diseño

Implementación

Prueba

Análisis

FasesFlujos de trabajo:

Actividades

iter.# 1

iter.# 2

iter.# n

iter.# n+1

ite r.# n+2

iter.#m

ite r.# m +1

Inicio Elaboración Construcción Transición

Iteraciones:

CICLO DE VIDA

29



57

Proceso unificado de desarrollo

ITERACIÓN

REQUISITOS ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEBAS

PLANIFICACIÓN DE LA ITERACIÓN

EVALUACIÓN DE LA ITERACIÓN

ACTIVIDADES DE LOS FLUJOS DE TRABAJO FUNDAMENTALES

Como se puede ver, el Proceso Unificado de Desarrollo

incluye actividades correspondientes a un Proceso

de Gestión de Proyectos


58


FASES:• INICIACIÓN: se desarrolla una descripción del producto

final y se presenta el análisis del negocio; se identifican y priorizan los riesgos más importantes, se planifica la siguiente fase y se estima el proyecto de manera aproximada

• ELABORACIÓN: se especifican en detalle la mayoría de los casos de uso y se diseña la arquitectura del sistema; se planifican las actividades y estiman los recursos para terminar el proyecto

• CONSTRUCCIÓN: se desarrolla/construye el producto• TRANSICION: se proporciona el sistema a los usuarios

finales

30



59


FLUJOS DE TRABAJO:• REQUISITOS: desarrollar un modelo del sistema que se

va a construir; identificar los requisitos de dicho sistema. Se obtiene el Modelo de Casos de Uso (MCU) y el Modelo del Dominio (o del Negocio)

• ANÁLISIS: tener una especificación más precisa de los requisitos obtenidos en REQUISITOS y recogidos en el MCU. Se obtiene el Modelo del Análisis (diagramas de colaboración y paquetes/subpaquetes de análisis)

• DISEÑO: encontrar la forma del sistema que cumpla con todos los requisitos (encontrar la solución). Se obtiene el Modelo del Diseño (diagramas de secuencia, diagrama de clases y sistemas/subsistemas de diseño)


60


FLUJOS DE TRABAJO:

• IMPLEMENTACIÓN: realizar la codificación correspondiente al diseño. Se obtiene el Modelo de la Implementación (componentes: clases y subsistemas implementados)

• PRUEBAS: realizar la verificación de la implementación; diseñar, implementar casos de prueba y ejecutarlos. Hay que obtener los casos y procedimientos de prueba.

31



61Unified Modelling Language (UML)

• Para que tenga éxito, un proceso de desarrollo de software no sólo debe ser bueno, sino que debe utilizar además una buena notación y ofrecer herramientas CASE (Computer Assisted Software Engineering)

• El Proceso Unificado de Desarrollo utiliza UML para representar la parte estática y dinámica del sistema.

UML

RATIONAL ROSE

VISIOPROCESO UNIFICADO DE

DESARROLLO DE RATIONAL

Herramientas Proceso

Notación

PARTE DINÁMICA

PARTE ESTÁTICA

INTERFAZ

ingenierÍa del softwaresiul02.si.ehu.es/~alfredo/iso/tema1.pdf · ingenierÍa del software curso...

Documents