PROCESO INGENIERÍA DE SOFTWARE I. Francisco José García Peñalvo / Alicia García Holgado /

Transcripción

1 PROCESO INGENIERÍA DE SOFTWARE I 2º DE GRADO EN INGENIERÍA INFORMÁTICA CURSO 2017/2018 Fracisco José García Peñalvo / fgarcia@usal.es Alicia García Holgado / aliciagh@usal.es Departameto de Iformática y Automática Uiversidad de Salamaca

2 CONCEPTOS Proyecto Actividad Producto producido por Tarea cosume Recursos Sistema Participate Modelo Documeto Tiempo Equipamieto 2

3 CONCEPTOS Proceso Defie el marco de trabajo y permite u desarrollo racioal y oportuo de la Igeiería del Software Método Idica cómo costruir técicamete el software. Se icluye técicas de modelado y otras técicas descriptivas Herramietas Proporcioa el soporte automático o semiautomático para el proceso y para los métodos Notació Cojuto de reglas gráficas o textuales para la represetació de u modelo Metodología Colecció de métodos para resolver u tipo de problemas Descompoe el proceso de desarrollo e actividades y proporcioa los métodos adecuados para llevar a cabo dichas actividades 3

4 CONCEPTOS Recapitulació del desarrollo de software Proceso Cojuto de actividades (Flujos de trabajo) platilla Domiio Aplicació requisitos usuario Proyecto resultado Producto Clietes Usuarios Igeieros software Persoas. participate Artefactos modelos código mauales. 4

5 DEFINICIÓN DE PROCESO Cojuto ordeado de actividades; ua serie de pasos que ivolucra tareas, restriccioes y recursos que produce ua determiada salida esperada (Pfleeger, 2002) Marco de trabajo de las tareas que se requiere para costruir software de alta calidad (Pressma, 2010) 5

6 UN PROCESO SOFTWARE DEBE ESPECIFICAR La secuecia de actividades a realizar por el equipo de desarrollo Flujo de actividades Los productos que debe crearse Resultados del trabajo (modelos, documetos, datos iformes...) Qué y cuádo La asigació de tareas a cada miembro del equipo y al equipo como u todo Los criterios para cotrolar el proceso Se establece el cotrol de gestió de los proyectos software Establecimieto de hitos Las posibles heurísticas 6

7 IMPORTANCIA DEL PROCESO Facilita la gestió del proyecto Establece ua divisió del trabajo Facilita la comuicació de los miembros del equipo Permite la reasigació y la reutilizació de persoal especializado Trasferecia etre proyectos Mejora la productividad y el desarrollo El desarrollo es reproducible Establece el cotexto e el que se aplica los métodos técicos Gestioa el cambio adecuadamete Asegura la calidad 7

8 CICLO DE VIDA DEL SOFTWARE Cuado u proceso implica la costrucció de algú producto, suele referirse al proceso como u ciclo de vida El proceso de desarrollo de software suele deomiarse ciclo de vida del software La evolució del software represeta el ciclo de actividades ivolucradas e el desarrollo, uso y mateimieto de sistemas software (Scacchi, 1987) Los proyectos software se desarrolla e ua serie de fases Va desde la cocepció del software y su desarrollo iicial hasta su puesta e fucioamieto y posterior retirada por otra ueva geeració de software Estas fases puede ser Temporales Forma ua secuecia e el tiempo Lógicas Cuado represeta pasos o etapas que o costituye ua secuecia temporal 8

9 CICLO DE VIDA DEL SOFTWARE Ciclo de vida Las distitas fases por las que pasa el software desde que ace ua ecesidad de mecaizar u proceso hasta que deja de utilizarse el software que sirvió para ese objetivo, pasado por las fases de desarrollo y explotació (Frakes et al., 1991) Ciclo de desarrollo El período de tiempo que comieza co la decisió de desarrollar u producto software y fializa cuado se ha etregado este. Este ciclo icluye, e geeral, ua fase de requisitos, ua fase de diseño, ua fase de implatació, ua fase de pruebas, y a veces, ua fase de istalació y aceptació (AECC, 1986) 9

10 MODELO DE PROCESO U modelo de proceso software es ua represetació abstracta de u proceso software (Sommerville, 2005) Hay varios modelos de procesos defiidos e la bibliografía de Igeiería del Software Cada modelo de proceso represeta u proceso desde ua perspectiva particular, por lo que sólo ofrece ua iformació parcial sobre dicho proceso Los modelos de proceso geéricos, tambié llamados paradigmas de proceso Preseta u proceso desde ua perspectiva arquitectóica, es decir, ofrece u marco de defiició para el proceso, pero o detalla las actividades específicas No so descripcioes defiitivas de los procesos software, más bie so abstraccioes útiles que se utiliza para explicar diferetes aproximacioes al desarrollo del software 10

11 MODELO GENERAL DE PROCESO EN INGENIERÍA Especificació Formulació de los requisitos y restriccioes del sistema Diseño Elaboració de u documeto co el modelo del sistema Fabricació Costrucció del sistema Prueba Comprobació de que el sistema cumple las especificacioes requeridas Istalació Etrega del sistema al cliete y garatía de que es operativo Mateimieto Reparació de los fallos que aparece e el sistema 11

12 MODELO GENERAL DE PROCESO EN INGENIERÍA DE SOFTWARE E el proceso de costrucció de sistemas iformáticos se puede distiguir tres fases geéricas La defiició (Aálisis de Sistemas; Aálisis de Requisitos) El desarrollo (Diseño; Codificació; Prueba) El mateimieto (Correctivo; Adaptativo; Perfectivo; Prevetivo) 12

13 ESTÁNDAR ISO/IEC/IEEE 12207:2017 El estádar ISO/IEC/IEEE 12207:2017 (ISO/IEC/IEEE, 2017) relativo a los procesos del ciclo de vida del software Se aplica a la adquisició de sistemas de software, productos y servicios, al sumiistro, desarrollo, operació, mateimieto y elimiació de productos de software o compoetes de software de cualquier sistema, ya sea que se realice itera o exteramete a ua orgaizació Se icluye aquellos aspectos de la defiició del sistema ecesarios para proporcioar el cotexto de los productos y servicios de software Tambié proporcioa procesos que puede emplearse para defiir, cotrolar y mejorar los procesos del ciclo de vida del software detro de ua orgaizació o de u proyecto 13

14 ESTÁNDAR ISO/IEC/IEEE 12207:2017 Esta orma o fometa o especifica igú modelo cocreto de ciclo de vida, gestió del software o método de igeiería, i prescribe cómo realizar igua de las actividades 14

15 ESTÁNDAR ISO/IEC/IEEE 12207:

16 MODELO PRIMITIVO Se le cooce tambié co el ombre de Modelo Prueba y Error o Modelo Codifica y Mejora Proceso de desarrollo aplicado e las primeras experiecias de programació Supoe ua iteració de fases codificació-depuració si igua plaificació i diseños previos Codificació Prueba Empezar a codificar Cotiuar codificado Fial Comieza el proyecto Tiempo 16

17 MODELO PRIMITIVO Icoveietes Código pobremete estructurado tras varias iteracioes Código espagueti / Código pizza Caro de desarrollar por las umerosas recodificacioes Posible rechazo del usuario al o existir aálisis de requisitos Caro de depurar por la falta de plaificació Caro de mateer por la falta de estructura y documetació 17

18 MODELO CLÁSICO Coocido tambié como modelo lieal o e cascada Versió origial se debe a W. Royce (Royce, 1970), pero aparece después umerosos refiamietos Características Ivestigació prelimiar Está compuesto por ua serie de fases que se ejecuta secuecialmete Paso de fase al coseguir los objetivos Obteció de documetos como criterio de fializació de fase El fial de ua fase puede supoer u puto de revisió Se ecuetra defiido e la orma estádar 2167-A del DoD de EEUU Aálisis Diseño Codificació Ciclo de vida clásico Prueba Mateimieto 18

19 MODELO CLÁSICO Apoyo a los gestores Distitas cofiguracioes Muchos modelos más complejos so variacioes del modelo e cascada que icorpora lazos de realimetació y fases adicioales Modelo satisfactorio solo e desarrollos coocidos y estables El descoocimieto y el riesgo suele ser alto e el desarrollo del software Descoocimieto de las ecesidades por parte del cliete Icompresió de las ecesidades por parte del proveedor Iestabilidad de las ecesidades Opcioes tecológicas Movimietos de persoal La liealidad o se correspode co la realidad Los retoros de iformació etre las fases se hace ecesarios para icorporar correccioes hacia arriba, e fució de los descubrimietos realizados hacia abajo 19

20 MODELO CLÁSICO Ivestigació prelimiar Aálisis Especificació de requisitos Diseño Especificació de diseño Codificació Módulos implemetados Prueba Módulos probados Mateimieto Ciclo de vida clásico co realimetació Sistema fucioado y actualizado 20

21 MODELO CLÁSICO Icoveietes Su progresió secuecial o lieal o refleja la maera e que realmete se desarrolla el software (Pfleeger, 2002; Pressma, 2006) Es u modelo que adolece de rigidez (Pressma, 2010) Exige al usuario que expoga explícitamete todos los requisitos al pricipio, presetado problemas para gestioar la icertidumbre atural propia del comiezo de la mayoría de los proyectos Se tarda mucho tiempo e pasar por todo el ciclo (Piattii et al., 2004) Es u modelo moolítico (Pressma, 2010) Hasta llegar a las etapas fiales del desarrollo o habrá ua versió operativa del programa, lo que ifluye egativamete e el descubrimieto a tiempo de errores o icogruecias e los requisitos Impoe ua estructura de gestió de proyecto al desarrollo del sistema (McCracke y Jackso, 1981) No trata al software como u proceso de resolució de problemas (Curtis et al., 1987) 21

22 MODELO CLÁSICO Cosideracioes fiales Tiee u lugar destacado e la Igeiería del Software Proporcioa ua platilla para adecuar los métodos Es muy utilizado Tiee problemas pero es mejor que desarrollar si guías 22

23 MODELOS BASADOS EN PROTOTIPOS U prototipo es u modelo experimetal de u sistema o de u compoete de u sistema que tiee los suficietes elemetos que permite su uso Objetivos So u medio eficaz para aclarar los requisitos de los usuarios e idetificar las características de u sistema que debe cambiarse o añadirse Mediate el prototipo se puede verificar la viabilidad del diseño de u sistema Características Es ua aplicació que fucioa Su fialidad es probar varias suposicioes co respecto a las características requeridas por el sistema Se crea co rapidez Evolucioa a través de u proceso iterativo Tiee u costo bajo de desarrollo 23

24 MODELOS BASADOS EN PROTOTIPOS Efoques de desarrollo Desechable: El prototipo es ua versió rudimetaria del sistema que posteriormete es desechada Evolutivo: El prototipo debe covertirse, evetualmete, e el sistema fial usado (alterativa al ciclo de vida) (Basili y Turer, 1975) Mixto (prototipado operativo) (Davis, 1992) Se aplica técicas covecioales para los requisitos bie coocidos Combiació de prototipos desechables y evolutivos para los requisitos poco coocidos DESECHABLE EVOLUTIVO Efoque de desarrollo Qué costruir Directrices del diseño Rápido y si rigor Sólo las partes problemáticas Optimizar el tiempo de desarrollo Riguroso Primero las partes bie etedidas. Sobre ua base sólida. Optimizar la modificabilidad Objetivo último Desecharlo Icluirlo e el sistema Diferecias etre los prototipos desechables y evolutivos 24

25 PROTOTIPOS DESECHABLES Características Se desarrolla código para explorar factores críticos para el éxito del sistema La implemetació usa leguajes y/o métodos de desarrollo más rápidos que los defiitivos Se usa como herramieta auxiliar de la especificació de requisitos y el diseño Determiar la viabilidad de los requisitos Validar la fucioalidad del sistema Ecotrar requisitos ocultos Determiar la viabilidad de la iterfaz de usuario Examiar alterativas de diseño Validar ua arquitectura de diseño particular Este efoque suele derivar e u modelo lieal ua vez que el prototipo ha cumplido su misió 25

26 PROTOTIPOS DESECHABLES Características Idea del software e líeas geerales desde el puto de vista del usuario Idealmete sirve para idetificar los requisitos del software Obteció de requisitos Diseño rápido Itroduce cierta flexibilidad e la itroducció de requisitos Proceso iterativo Costrucció del prototipo Refiamieto del prototipo La iteració ocurre cuado el prototipo se poe a puto para satisfacer las ecesidades del cliete, permitiedo a la vez que el desarrollador compreda mejor lo que ecesita hacer Evaluació del prototipo Producto fial Modelo de prototipos 26

27 PROTOTIPADO EVOLUTIVO (CICLO DE VIDA ITERATIVO) Características Efoque de desarrollo que se utiliza cuado o se cooce co seguridad lo que se quiere costruir Se comieza diseñado e implemetado las partes más destacadas del sistema La evaluació del prototipo proporcioa la realimetació ecesaria para aumetar y refiar el prototipo El prototipo evolucioa y se trasforma e el sistema fial Cocepto iicial Diseño e implemetació del prototipo iicial Refiar el prototipo hasta que sea aceptable Completar y etregar el prototipo Modelo de prototipado evolutivo 27

28 VENTAJAS DEL PROTOTIPADO Permite solvetar objecioes del usuario Sirve para formalizar la aceptació previa Itroduce flexibilidad e la captura de requisitos Es útil cuado el área de aplicació o está defiida, cuado el riesgo de rechazo el alto, o como forma de evaluar el impacto de ua aplicació El prototipado es u subproceso que puede icluirse como parte de otros modelos de proceso Por ejemplo puede combiarse co u ciclo e cascada para itetar solvetar ciertas carecias de este Modelo e cascada co prototipado (Pfleeger, 2002) 28

29 INCONVENIENTES DEL PROTOTIPADO El sistema se puede llegar a deteriorar tediedo hacia el modelo primitivo Se suele refiar el prototipo hacia el sistema fial e lugar de desecharlo y empezar desde el pricipio El cliete puede ecotrar atractivo el prototipo y quedarse co el prototipo como sistema fial Relajació de los desarrolladores No dismiuye el tiempo etre la defiició de los requisitos y la etrega del producto Al usuario le desagrada que se deseche código 29

30 MODELOS EVOLUTIVOS El software, al igual que todos los sistemas complejos, evolucioa co el tiempo (Gilb, 1988) Se caracteriza porque permite desarrollar versioes cada vez más completas del software, teiedo e cueta la aturaleza evolutiva del software Preseta la filosofía de poer u producto e explotació cuato ates Está muy ligados a la idea de prototipado evolutivo Existe muchos modelos de proceso evolutivos Los modelos evolutivos so iterativos (Pressma, 2010) Se caracteriza por la forma e que permite a los igeieros de software desarrollar versioes cada vez más completas del producto software, que puede ir etregádose al cliete e forma de icremetos 30

31 MODELOS EVOLUTIVOS Los desarrollos orietados a objetos se ajusta a u modelo de proceso iterativo e icremetal Se puede argumetar lo mismo para los desarrollos basados e compoetes Esto es así porque Las tareas de cada fase se lleva a cabo de ua forma iterativa A la vez que existe u ciclo de desarrollo aálisis-diseñoimplemetació-aálisis que permite hacer evolucioar al sistema E el desarrollo icremetal el sistema se divide e u cojuto de particioes Cada ua se desarrolla de forma completa hasta que se fializa el sistema Esta idea de iteratividad máxima propia de la orietació a objetos ha sido equiparada por autores como James Rumbaugh (1992) o L. B. S. Raccoo (1995) a las fractales o la teoría del caos 31

32 DIMENSIÓN INCREMENTAL Icremeto 1 Aálisis Diseño Código Prueba Etrega del primer icremeto Icremeto 2 Aálisis Diseño Código Prueba Etrega del segudo icremeto Icremeto 3 Aálisis Diseño Código Prueba Etrega del tercer icremeto... Tiempo de caledario Modelo icremetal (Pressma, 2010) 32

33 DIMENSIÓN ITERATIVA Aálisis Plaificació Diseño Aálisis Diseño N veces Fases Codificació Itegració Trasició progresiva Codificació Evaluació Etrega 33

34 MODELO EN ESPIRAL Fue propuesto iicialmete por B. Boehm (Boehm, 1986, 1988) Es u modelo de proceso de software evolutivo, que proporcioa el potecial para el desarrollo rápido de versioes icremetales del software Características Puede cosiderarse como u metamodelo de proceso Reúe características del modelo clásico y de prototipos Aparece el aálisis de riesgo Se divide e u úmero de actividades estructurales, tambié deomiadas regioes de tareas. E el modelo origial de Boehm aparece cuatro regioes de tareas Plaificació, Aálisis de riesgos, Igeiería, Evaluació del cliete El avace se realiza desde el cetro de la espiral hacia el exterior 34

35 MODELO EN ESPIRAL Plaificació Determiar objetivos, alterativas y restriccioes Pla para la próxima fase Evaluació del cliete Pla de requisitos y del ciclo de vida Pla de desarrollo Pla de itegració y prueba Aálisis de riesgo Aálisis de riesgo Aálisis de riesgo Aálisis de riesgo Prototipo 1 Operació Validació requisitos V & V diseño Servicio. Prototipo 2 Espec. requisitos Evaluar alterativas Idetificar y resolver riesgos Prototipo 3 Simulacioes Pruebas uidad Pruebas aceptació. Diseño Codificació Aálisis de riesgo Prototipo operativo Diseño detallado Desarrollo, verificació del siguiete ivel del producto Igeiería Ciclo de vida e espiral (Boehm, 1988) 35

36 MODELO EN ESPIRAL Variate del modelo de Boehm co 6 regioes de tareas (Pressma, 2002) Se defie u eje co diferetes putos de etrada para diferetes tipos de proyectos Comuicació co el cliete Plaificació Aálisis de riesgos Putos de etrada al proyecto Proyecto de mateimieto de productos Proyecto de mejora de productos igeiería Proyecto de desarrollo de productos uevos Proyecto de desarrollo de coceptos Evaluació del cliete Costrucció y adaptació Modelo e espiral de Pressma 36

37 MODELO EN ESPIRAL Vetajas Refleja de forma más realista la idiosicrasia del desarrollo de software Toma lo mejor y evita lo peor de los demás modelos, segú la situació e cada mometo Las opcioes de reutilizació se tiee e cueta desde el primer mometo Proporcioa ua preparació para la evolució, crecimieto y cambio Proporcioa u mecaismo para icorporar objetivos de calidad e el desarrollo Se cetra e la elimiació de errores y opcioes o atractivas desde el pricipio Determia el ivel de esfuerzo de cada fase e cada proyecto Se sigue el mismo procedimieto para el desarrollo que para el mateimieto, co lo que se evita los problemas de las mejoras rutiarias de alto riesgo Permite ua gra flexibilidad Se adapta bie al diseño y programació orietado a objetos 37

38 BIBLIOGRAFÍA F. J. García-Peñalvo y A. García-Holgado, "Itroducció a la Igeiería del Software," Recursos docetes de la asigatura Igeiería de Software I. Grado e Igeiería Iformática. Curso , F. J. García-Peñalvo y A. García-Holgado, Eds., Salamaca, España: Grupo GRIAL, Uiversidad de Salamaca, [Olie]. Dispoible e: doi: /zeodo (pp ) F. J. García-Peñalvo y A. García-Holgado, "Modelos de proceso," Recursos docetes de la asigatura Igeiería de Software I. Grado e Igeiería Iformática. Curso , F. J. García- Peñalvo y A. García-Holgado, Eds., Salamaca, España: Grupo GRIAL, Uiversidad de Salamaca, [Olie]. Dispoible e: doi: /zeodo Igeiería de Software I - Igeiería del Software 38

39 PROCESO INGENIERÍA DE SOFTWARE I 2º DE GRADO EN INGENIERÍA INFORMÁTICA CURSO 2017/2018 Fracisco José García Peñalvo / fgarcia@usal.es Alicia García Holgado / aliciagh@usal.es Departameto de Iformática y Automática Uiversidad de Salamaca