2. El Proceso

Ingeniera del SoftwareAntonio Navarro

1

2. El proceso


2

ndice Referencias IS: una tecnologa estratificada

Capas en IS. Una visin general de la IS

El proceso de software Modelos de proceso Modelos de proceso del software clsicos Modelos de proceso del software evolutivos

ndice

Modelos de proceso del software giles Madurez del proceso Conclusiones


3


4

Referencias

Pressman, R.S. Ingeniera del Software. Un Enfoque Prctico. Sexta Edicin. McGraw-Hill, 2005

Sommerville, I. Ingeniera del Software. 7 edicin. Addison-Wesley, 2005

Beck K. Extreme Programming Explained. Embrace change. Addison-Wesley, 1999


5

Referencias

Jacobson I., Booch G., Rumbaugh J., El proceso unificado de desarrollo de software. Addison-Wesley 2001.

Lpez-Cortijo R., Amescua Antonio de, Ingeniera del Software. Aspectos de Gestin. Tomo 1 conceptos bsicos, teora, ejercicios y herramientas. Instituto Ibrico de la Industria del Software, 1998.


6

Referencias

Schmidt, M. Implementing the IEEE Software Engineering Standards. Sams 2000


7

IS: tecnolologa estratificadaIntroduccin

Definiciones ms relevantes de IS: IS trata del establecimiento de los principios y

mtodos de la ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje en mquinas reales, Bauer 1972.


8

IS: Tecnologa estratificadaIntroduccin

IEEE (1993) IS es:1. La aplicacin de un enfoque sistemtico,

disciplinado y cuantificable al desarrollo, operacin (funcionamiento) y mantenimiento del software, es decir, la aplicacin de ingeniera al software.

2. Es estudio de enfoques como en 1.


9

IS: tecnologa estratificadaIntroduccin

Hay mucho que hacer en IS: Principios y metodologas de ingeniera. Software econmico. Software fiable. Software eficiente. Sistematizar, disciplinar y cuantificar. Mantener el software.


10

IS: tecnologa estratificadaIntroduccin

Cmo vamos a ser capaces de hacer tanto? Utilizando un modelo de proceso que

imponga racionalidad en el proceso de desarrollo de software con el fin de satisfacer todas las demandas de la IS


11

IS: tecnologa estratificadaCapas

La IS es una tecnologa multicapa1. Capa de enfoque de calidad2. Capa de proceso3. Capa de mtodos4. Capa de herramientas


12


Capa de calidad Base de cualquier proceso de ingeniera. La IS se basa en calidad mejores tcnicas de

construccin de software. Capa de proceso

Capa que une calidad y mtodos desarrollo racional de la IS.

Conjunto de actividades y resultados asociados que sirven para construir un producto software.


13


Capa de mtodos Un mtodo incluye:

Anlisis de requisitos. Diseo. Construccin de programas. Prueba. Mantenimiento.

Suelen estar bastante ligados al proceso.


14


Capa de herramientas Soporte automtico o semiautomtico para el

proceso y los mtodos. Herramientas CASE: Computer Aided Software

Engineering. Fundamental para la correcta aplicacin de IS.


15

IS: tecnologa estratificadaVisin general de la IS

Ingeniera: anlisis, diseo, construccin y verificacin de entidades tcnicas (o sociales)

La entidad caracteriza a la ingeniera:- Caminos, canales y puertos.- Aeronaves.- Buques.


16


Con independencia de la entidad debemos identificar y solucionar:- Problema a resolver.- Caractersticas de la entidad.- Forma de construir la entidad.- Enfoque para resolver los errores cometidos durante el diseo y construccin de la entidad.- Mantenimiento de la entidad frente a su evolucin.


17


En IS, entidad = software. Soporte para el desarrollo de la

entidad/soporte para la IS: modelo de proceso.

Con independencia del modelo de proceso hay tres fases genricas:- Fase de definicin.- Fase de desarrollo.- Fase de mantenimiento


18


Fase de definicin Centrada en el qu. Se identifican los requisitos del sistema y

software: Informacin a procesar. Funcin y rendimiento deseados. Comportamiento del sistema. Interfaces establecidas. Restricciones de diseo.


19


Tareas principales: Planificacin del proyecto software. Ingeniera de sistemas o de informacin. Anlisis de requisitos.

Fase de desarrollo Centrada en el cmo.


20


Se definen: Cmo han de disearse las bases de datos. Cmo han de implementarse las funciones. Cmo han de caracterizarse las interfaces. Cmo debe traducirse el diseo a un lenguaje de

programacin. Cmo ha de realizarse la prueba.


21


Tareas principales: Diseo del software. Generacin del cdigo. Pruebas del software.

Fase de mantenimiento Centrada en el cambio asociado a:

Correccin de errores. Adaptaciones requeridas por la evolucin del

entorno software. Cambios en los requisitos del cliente.


22


En esta fase se vuelven a aplicar las fases de definicin y desarrollo, pero sobre software ya existente.

Pueden producirse cuatro tipos de cambio: Correccin. Corregir los defectos. Adaptacin. Modificaciones por cambio en el

entorno externo (CPU, SO, etc.). Mejora. Ampliar los requisitos funcionales

originales, a peticin del cliente. Prevencin. Cambio para facilitar el cambio.


23


Estas fases se complementan con las actividades protectoras.- No crean software.- Mejoran su calidad.- Facilitan su desarrollo.


24

El proceso de software

Proceso: conjunto de actividades y resultados asociados que sirven para construir un producto software.

El proceso define un marco de trabajo compuesto por un conjunto de actividades: Actividades del marco de trabajo. Actividades estructurales, A.E.


25


Como los proyectos no son siempre iguales, durante la planificacin temporal el proceso se adapta al proyecto definiendo un conjunto de tareas concreto para cada actividad estructural


26


A un conjunto de tareas relacionadas que produce un producto del trabajo Pressman lo denomina accin de ingeniera del software

As, las acciones descomponen a las actividades estructurales y permiten adaptar un proceso a un proyecto concreto


27


Por ejemplo, para un proyecto concreto la actividad estructural Ingeniera puede descomponerse en las acciones Anlisis y Diseo

Para otro proyecto concreto, la actividad estructural Ingeniera puede descomponerse en las acciones Reingeniera, Anlisis y Diseo


28


A su vez, la accin Anlisis puede descomponerse en las tareas: Realizar diagramas casos de uso, Realizar diagramas actividades, Realizar diagramas clases anlisis, etc.


29


Simultneamente existen una serie de actividades de proteccin.- No crean software.- Mejoran su calidad.- Facilitan su desarrollo.- Es decir, evitan la corrupcin del proceso.- Estn presentes en las AE, por eso no pueden constituir una AE por si mismas.


30


Estas actividades protectoras son: Seguimiento y control del proyecto de software. Revisiones tcnicas formales. Garanta de calidad del software. Gestin de configuracin del software. Preparacin y produccin de documentos. Gestin de reutilizacin. Mediciones. Gestin de riesgos.


31

El proceso de software Podemos representarlo:

Proceso Act. Estructural1

- Accin1.n1

Act. Estructuraln

.................................................

Actividades de

proteccin +

- Accin1.1

Act. Estructural2

- Accin2.n2

- Accin2.1

......................

......................

......................


32


Adems, aunque hay distintos procesos, la mayor parte se ajusta a un marco de trabajo genrico

Dicho marco est formado por una serie de actividades estructurales comunes al proceso


33


Segn Pressman, estas actividades estructurales pueden ser: Comunicacin con el cliente. Planificacin. Anlisis de riesgos. Ingeniera. Construccin y adaptacin. Evaluacin por el cliente.


34


Segn Sommerville, estas actividades estructurales pueden ser: Especificacin del software. Diseo e implementacin del software. Validacin del software. Evolucin del software.


35

Modelos de procesoIntroduccin

Un modelo de proceso, o paradigma de IS, es una plantilla, patrn o marco que define el proceso a travs del cual se crea software

Un modelo de proceso del software es una representacin abstracta de un proceso del software


36


As, los modelos de proceso tienen en cuenta, en mayor o menor medida, las actividades estructurales comunes a todos los procesos de construccin de software

Por tanto, un modelo de proceso define sus actividades estructurales as como su flujo de realizacin


37


Como ya hemos comentado, los modelos de proceso se ajustan a los proyectos concretos variando el conjunto de tareas en el que se dividen las actividades estructurales


Adems, una organizacin podra variar su modelo de proceso para cada proyecto, segn: La naturaleza del proyecto. La naturaleza de la aplicacin. Los mtodos y herramientas a utilizar. Los controles y entregas requeridas.


38


39


Caractersticas de todo modelo de proceso:- Entendibilidad. Grado de definicin y facilidad para entender el proceso.- Visibilidad. Grado en que las actividades del proceso proporcionan resultados.- Soportabilidad. Grado en que las actividades del proceso estn soportadas por herramientas CASE.- Aceptabilidad. Grado en que los desarrolladores aceptan y usan el proceso.


40


- Fiabilidad. Grado en que el proceso permite evitar o detectar errores antes de que sean defectos.- Robustez. Grado en que el proceso puede continuar a pesar de los problemas.- Mantenibilidad. Grado en el que el proceso puede evolucionar para adaptarse.- Rapidez. Grado de velocidad en que el proceso puede proporcionar un sistema a partir de una especificacin

Modelos de proceso clsicosIntroduccin

Los modelos de proceso clsicos surgieron en una primera etapa

Muchos surgen como evolucin frente a modelos de proceso anteriores

Por imitacin o negacin, son la base de los modelos actuales


41

Modelos de proceso clsicosIntroduccin

Entre otros, caben destacar: Modelo en cascada Modelo de construccin de prototipos Modelo de desarrollo rpido de aplicaciones


42


43

Modelos de proceso clsicos Modelo en cascada

Tambin conocido como waterfall Es el modelo de proceso clsico. En general no es muy realista. Es sencillo y fcil de entender. El proyecto pasa a travs de una serie de fases

(AEs). Al final de cada fase se revisan las tareas de

trabajo y productos.


44


Modelo en cascada


45

Fases:- Conceptualizacin. Se determina la arquitectura de la solucin (i.e. divisin del sistema en subsistemas + comunicacin).- Anlisis de requisitos. Bsicamente se definen los requisitos funcionales y de rendimiento.- Diseo. Representacin de la aplicacin que sirve de gua a la implementacin.



46

- Implementacin. Transforma el diseo en cdigo.- Prueba. Prueba e integracin del software y de los sistemas.- Instalacin y comprobacin. Se instala al cliente, el cual comprueba la correccin de la aplicacin.

Se supone que se solo se baja en la cascada...... pero tambin se puede subir...... por lo general malas noticias.



47

Estrictamente no hay solapamientos entre las fases

Se pueden producir solapamientos de una fase

Se pueden producir solapamientos de fases (Modelo Sashimi)



48


Solapamiento de una fase


49


Modelo Sashimi


50

Ventajas: Muy probado. Sencillo.

Inconvenientes: Poco realista. Especificacin de requisitos estable. Baja visibilidad. Un error grave en las ltimas fases puede ser letal. Si no hay solapamientos puede haber bloqueos.



51

Existen diversas variantes: Sommerville. Pressman (lineal secuencial). Modelo en V.



52


Modelo Waterfall (Sommervile)


53


Modelo lineal-secuencial (Pressman)

Anlisis Diseo Codificacin Prueba


54


Modelo en V


55

Caractersticas: Gestionan bien la naturaleza evolutiva del software Son iterativos: construyen software repitiendo una

secuencia de pasos Suelen construir el sistema por incrementos:

productos operacionales de una parte del sistema Incremento vs. prototipo

Modelos de proceso evolutivosIntroduccin


Se adaptan bien: Los cambios de requisitos del producto. Fechas de entrega estrictas poco realistas. Especificaciones parciales del producto.


56


Entre otros cabe destacar: Modelo de desarrollo incremental Modelo en espiral de Boehm Modelo en Boston Modelo unificado de desarrollo de software


57


58

Espiral de Boehm simplificado:

Modelos de proceso evolutivos Espiral Boston

Modelo espiral Boston


59

Comunicacin con el cliente Tareas requeridas para establecer comunicacin

entre el desarrollador y el cliente. Planificacin

Tareas requeridas para definir recursos, tiempo y otras informaciones relacionadas con el proyecto.



60

Anlisis de riesgos Tareas requeridas para evaluar riesgos tcnicos

y de gestin. Ingeniera

Tareas requeridas para construir una o ms representaciones de la aplicacin.



61

Construccin y adaptacin Tareas requeridas para construir, probar,

instalar y proporcionar soporte al usuario. Evaluacin por el cliente

Tareas requeridas para obtener la reaccin del cliente tras su evaluacin.

Actividades de proteccin continuas. Discusin: por qu decimos tareas?



62

Este modelo de proceso caracteriza la vida de un sistema.

Eje de entrada en el proyecto. Tipos de proyecto:

Desarrollo del concepto. Desarrollo de nuevos productos. Mejora de productos. Mantenimiento de productos.



63


Vida de un proyecto


64

Ventajas Enfoque realista. Gestin explcita de riesgos. Adecuado para desarrollos OO.

Inconvenientes Convencer cliente enfoque controlable. Menos probado que el modelo en cascada o

prototipos.


Modelos de proceso giles Introduccin

El desarrollo gil surge a principios del 2001 en respuesta a los modelos de proceso clsicos

Valora: A los individuos sobre los procesos Al software funcionando sobre la documentacin La colaboracin del cliente sobre el negocio La respuesta al cambio sobre seguir un plan


65


La Alianza gil define 12 principios:1. Satisfacer al cliente con entrega temprana y

continua de software valioso2. Bienvenidos los requisitos cambiantes, incluso

en fases tardas del desarrollo3. Entregar con frecuencia (de dos semana a dos

meses) software funcionando, cuanto antes mejor


66


4. El cliente y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto

5. Individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos para obtener el trabajo realizado

6. El mtodo ms eficiente y efectivo de transmitir informacin hacia y dentro del equipo es la conversacin cara a cara


67


7. El software en funcionamiento es la medida principal del progreso

8. Desarrollo sostenible. Los participantes deben ser capaces de mantener un paso constante de manera indefinida

9. Atencin continua a la excelencia tcnica y a un buen diseo

10. La simplicidad (arte de maximizar el trabajo no realizado) es esencial


68


11. Las mejores arquitecturas, los mejores requisitos y los mejores diseos emergen de equipos auto organizados

12. A intervalos regulares el equipo refleja la forma en que se puede volver ms efectivo, entonces su comportamiento se ajusta y adeca en concordancia


69


Tericamente, la agilidad se puede aplicar a cualquier proceso de software

En cualquier caso, surgen modelos de proceso propios del desarrollo gil


70


El proceso gil parte de tres supuestos clave:1. Es difcil predecir qu requisitos software

persistirn y cules cambiarn. Tambin es difcil predecir las prioridades del cliente


71


2. El diseo y el desarrollo de software estn intercalados. Por tanto, se deben realizar de manera conjunta, de forma que el diseo se prueba segn se crea. Es difcil predecir cuanto diseo es necesario antes de construir el cdigo que lo implemente


72


3. El anlisis, el diseo y la construccin no son predecibles desde el punto de vista de la planificacin, lo que sera deseable

Para responder a estos supuestos, el modelo de proceso gil: Es adaptable de forma incremental Necesita retroalimentacin del cliente Se basa en la entrega continua de incrementos


73


El proceso gil requiere una serie de caractersticas sobre el equipo de desarrollo: Competencia tcnica. Enfoque comn: entregar al cliente un

incremento dentro del plazo. Colaboracin entre todos los participantes. Autonoma para la toma de decisiones. Capacidad de resolucin de problemas confusos.


74


Confianza y respeto mutuo en el equipo. Organizacin propia


75


Entre otros cabe destacar: Extreme Programming (XP) Scrum Desarrollo adaptativo de software


76


77

Modelo de proceso de K. Beck XP es un modo ligero, eficiente, de bajo

riesgo, flexible, predecible, cientfico y divertido de producir software.

Caractersticas Alta visibilidad debido a ciclos cortos. Planificacin incremental. Se adapta a cambios de negocio.

Modelos de proceso giles XP


78

Basado en test automatizados escritos por desarrolladores y clientes.

Alta comunicacin. Diseo evolutivo. Colaboracin entre programadores. Busca equilibrio entre las necesidades a corto

plazo de los programadores y las de largo plazo del proyecto.



79

La estructura del proceso, si la hay, es un poco atpica


Actividades en XP

Prueba Evaluacin DiseoCodificacin


80

Las cuatro actividades estn soportadas por doce prcticas:- El juego de planificacin.- Pequeas entregas.- Metfora.- Diseo simple.- Prueba.- Refactoring.



81

- Programacin en pareja.- Propiedad colectiva.- Integracin continua.- Semana de cuarenta horas.- Cliente en el lugar de desarrollo.- Codificacin estndar.



82

Ventajas (extensibles al resto): Bueno para especificaciones cambiantes. Fundamentacin prctica.

Inconvenientes (extensibles al resto): Poco probado. Poco compatible con especificaciones/diseos

totales. Solo funciona con equipos pequeos (hasta diez

personas).



83

Madurez del proceso

Madurez del proceso: correccin en la aplicacin de un proceso de software

El Software Engineering Institute (SEI)* ha identificado una serie de funciones que deberan estar presentes en el proceso

El grado de madurez del proceso se determina con un cuestionario y un esquema de cinco grados

*http://www.sei.cmu.edu


84

Madurez del proceso

El modelo de cinco grados determina la conformidad con un modelo de capacidad de madurez*: Inicial Repetible Definido Gestionado Optimizacin

*CMM: Capability Maturity Model


85

Madurez del proceso

Este modelo define una serie de reas clave de proceso (ACP)

Un rea clave de proceso es, basicamente, una actividad de IS

Los niveles son acumulativos

Madurez del proceso

Nivel 1: Inicial El proceso de software se caracteriza segn el

caso. Se definen poco procesos. El xito depende del esfuerzo individual.


86


87

Madurez del proceso

Nivel 2: Repetible Se incluye seguimiento del coste, de la

planificacin y de la funcionalidad. Se repiten tcnicas de proyectos anteriores con

buenos resultados. Las ACP son:

Planificacin del proyecto de software. Seguimiento y supervisin del proyecto de software. Gestin de requisitos.


88

Madurez del proceso Gestin de la configuracin software (GCS). Garanta de calidad del software (SQA). Gestin de la subcontratacin.

Nivel 3: Definido Nivel 2 Las actividades se documentan, estandarizan e

integran en un proceso a nivel organizacin. Existe un proceso documentado.


89

Madurez del proceso

Las ACP son: Definicin y enfoque del proceso de la

organizacin. Programa de formacin. Revisiones peridicas. Coordinacin entre grupos. Ingeniera de productos software. Gestin de integracin del software.


90

Madurez del proceso

Nivel 4: Gestionado Nivel 3. Se recopilan medidas del proceso del software

y de la calidad del producto. Estas medidas sirven para gestionar el proceso. Las ACP son:

Gestin de la calidad del software. Gestin cuantitativa del software.


91

Madurez del proceso

Nivel 5: Optimizacin Nivel 4 En base a la experiencia y mtricas se optimiza

el proceso. Las ACP son:

Gestin de cambios del proceso. Gestin de cambios de tecnologa. Prevencin de defectos.


92

Madurez del proceso

Un nivel razonable es el definido (nivel 3). Un nivel deseable es optimizacin (nivel 5). Con independencia del CMM, ACPs mnimas:

Planificacin del proyecto. Seguimiento y supervisin del proyecto. Gestin de requisitos. GCS. SQA. Definicin del proceso. Revisiones periodicas. Coordinacin entre grupos.


93

Conclusiones En IS hay mucho que hacer...

... el modelo de proceso es nuestro soporte La IS es una tecnologa multicapa La IS concibe la informtica como una

ingeniera En IS hay tres fases Estas tres fases estn presentes en todos los

modelos de proceso


94

Conclusiones

El proceso va a encaminado a desarrollar software

Presenta unas actividades comunes Los modelos de proceso son

representaciones del proceso de desarrollo As, las actividades comunes estn

presentes en mayor o menor medida en todos los modelos de proceso


95

Conclusiones

El modelo de proceso determina y queda determinado por sus AEs

Las AEs son fijas para cada modelo de proceso

El modelo de proceso se ajusta al proyecto a travs de las acciones y el conjunto de tareas de IS

Disponemos de mltiples modelos de proceso


96

Conclusiones Tambin hay modelos que no son de proceso Modelos clsicos vs giles Al final TODOS, de una forma u otra,

resuelven las fases de IS Tensin entre el producto y el proceso No todos las organizaciones aplican de la

misma forma el mismo proceso Se puede medir la madurez del proceso

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 42Slide 43Slide 44Slide 45Slide 46Slide 47Slide 48Slide 49Slide 50Slide 51Slide 52Slide 53Slide 54Slide 55Slide 56Slide 57Slide 58Slide 59Slide 60Slide 61Slide 62Slide 63Slide 64Slide 65Slide 66Slide 67Slide 68Slide 69Slide 70Slide 71Slide 72Slide 73Slide 74Slide 75Slide 76Slide 77Slide 78Slide 79Slide 80Slide 81Slide 82Slide 83Slide 84Slide 85Slide 86Slide 87Slide 88Slide 89Slide 90Slide 91Slide 92Slide 93Slide 94Slide 95Slide 96

2. El Proceso

Documents

Transcript of 2. El Proceso