Sesión 3 : ESCUELA ACADEMICO PROFESIONAL DE INGENIERIA DE SISTEMAS

Presentación del tema: "Sesión 3 : ESCUELA ACADEMICO PROFESIONAL DE INGENIERIA DE SISTEMAS"— Transcripción de la presentación:

1 Sesión 3 : ESCUELA ACADEMICO PROFESIONAL DE INGENIERIA DE SISTEMAS
Curso : Ingeniería de Software Sesión 3 : PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE

2 PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE
Sesión 3 : PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE Temario ... El Proceso Unificado (RUP) Definiciones Generales. Fases de RUP e Iteraciones. Componentes del Proceso. Características del Proceso Unificado. El Proyecto de Software

3 SESION 3: PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE
1.0 Producción de SW: problemática, origen de los problemas, panorama contemporáneo. 1.1 ¿ Qué es el RUP? Características 1.2 Definiciones Generales Los puntos clave en el proceso de desarrollo SW (las 4 P) Las 5 expectativas de la Ingeniería de Software contemporánea y el papel de las 4 P. 1.3 Estructura del RUP: fases e iteraciones Fase de Incepción Fase de Elaboración Fase de Construcción Fase de Transición 1.4 Componentes del Proceso 1.5 Características del Proceso Unificado 1.6 El Proyecto de Software

4 1.0 Producción de software: Problemática
PROBLEMAS: perspectiva del cliente Excesiva duración para terminar los programas Costos elevados del desarrollo del software Los programas no cumplen con lo requerido PROBLEMAS: perspectiva de los desarrolladores El usuario no transmite bien sus necesidades Los requerimientos son cambiados constantemente Muy poco trabajo en equipo Se trabaja sin estándares

5 Producción de software: Orígen de los problemas
Excesiva complejidad Comunicaciones ambiguas e imprecisas Pruebas insuficientes No se detectan las inconsistencias en los requerimientos, el diseño y en la implementación Fallas en identificar y mitigar los riesgos Propagación de los cambios no controlada Automatización insuficiente

6 Producción de software: Panorama contemporáneo
¿Cuáles son los retos que afronta la ingeniería de software en el siglo XXI ? El reto de la heterogeneidad. Integrar software con sistemas heredados Desarrollar técnicas para construir software confiable con alto grado de integración ante la heterogeneidad El reto de la entrega. Reducir los tiempos de entrega sin comprometer la calidad Implementar marcos de trabajo (modelos de calidad, metodologías reconocidas como buenas prácticas, estándares) El reto de la confianza. El software tiene relación con todos los aspectos de nuestra vida. Desarrollar y aplicar técnicas con alto grado de confiabilidad

7 SESION 3: PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE
1.0 Producción de SW: problemática, origen de los problemas, panorama contemporáneo. 1.1 ¿ Qué es el RUP? Características 1.2 Definiciones Generales Los puntos clave en el proceso de desarrollo SW (las 4 P) Las 5 expectativas de la Ingeniería de Software contemporánea y el papel de las 4 P. 1.3 Estructura del RUP: fases e iteraciones Fase de Incepción Fase de Elaboración Fase de Construcción Fase de Transición 1.4 Componentes del Proceso 1.5 Características del Proceso Unificado 1.6 El Proyecto de Software

8 El Proceso Unificado (RUP) ...

9 Proceso de Desarrollo de Software
1.1 ¿Qué es el RUP? Concepto: “Un proceso define Quién está haciendo Qué, Cuándo y Cómo logrará una meta trazada” El RUP es un conjunto de actividades necesarias para transformar los requisitos de un usuario a un sistema de software Requisitos del Usuario Proceso de Desarrollo de Software Sistema Software

10 1.1 ¿Qué es el RUP? El “Proceso Unificado” es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones y diferentes tamaños de proyectos. El “Proceso Unificado” está basado en Componentes, interconectados a través de Interfaces bien definidas. El “RUP” se resume en tres fases: Conducido por Diagramas de Caso de Uso Centrado en Arquitecturas Desarrollo iterativo e incremental

11 1.1 ¿Qué es el RUP? Conducido por Diagramas de Caso de Uso
Un Caso de Uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Todos los casos de uso juntos constituyen el Modelo de Caso de Uso el cual describe la funcionalidad total del Sistema.

12 1.1 ¿Qué es el RUP? Centrado en Arquitecturas
El papel de la Arquitectura de Software es parecido al papel de la Arquitectura de la construcción. Arquitectura de Software: Plataforma en la que funciona el Software (arquitectura software, sistema operativo, sistema de gestión de base de datos, protocolo para comunicaciones en red) El valor de una arquitectura depende de las personas que se hayan responsabilizado de su creación.

13 1.1 ¿Qué es el RUP? Desarrollo Iterativo e Incremental
Es practico dividir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos al crecimiento del producto.

14 para construir un Sistema
Los Equipos necesitan Procesos para construir un Sistema Desarrollo basado en Equipos Lenguaje de Modelado Procesos Unificados

15 Los puntos clave en el desarrollo SW:
Las 4 P Las 4 P de la Ingeniería de Software: La meta de todo proyecto de software es producir un producto de software. Los productos de un esfuerzo de desarrollo de software consisten en mucho más que el código fuente y el ejecutable. Incluye documentación, resultado de las pruebas y medidas de productividad. Estos productos se llamarán “artefactos” Es clave el proceso mediante el cual los proyectos producen productos de manera efectiva. Otro factor de éxito, son las personas porque la dinámica interpersonal del equipo influye en los logros del proyecto.

16 Los puntos clave en el desarrollo SW:
Las 4 P

17 Las Personas son decisivas

18 Las Personas son decisivas

19 Las Personas son decisivas

20 ¿Qué es un Sistema de Software?

21 ¿Qué es un Sistema de Software?

22 Artefacto

23 1.5 Las 5 expectativas de la Ingeniería de SW
La Ingeniería de Software contemporánea tiene 5 expectativas importantes: Predeterminar metas de calidad cuantitativas, que se aplicarán al proyecto y al producto. Ejm. “No más de 2% de reprocesos mensuales por aplicación” 2. Reunir datos para usarlos en proyectos subsecuentes, a fin de realizar estimaciones de recursos y tiempos. Ejm. “base de datos de conocimientos, Relatorio del Pyto.” Mantener todo el trabajo visible, para que el Team pueda disponer de todos los requisitos, diseños, códigos y pruebas. Todos los miembros del Team deben seguir el proceso: a) Diseñar sólo contra requisitos b) Programar sólo contra diseño c) Probar sólo contra requisitos y diseños 5. Medir y lograr las metas de calidad.

24 SESION 3: PROCESOS DE DESARROLLO SOFTWARE
1.0 Producción de SW: problemática, origen de los problemas, panorama contemporáneo. 1.1 ¿ Qué es el RUP? Características 1.2 Definiciones Generales Los puntos clave en el proceso de desarrollo SW (las 4 P) Las 5 expectativas de la Ingeniería de Software contemporánea y el papel de las 4 P. 1.3 Estructura del RUP: fases e iteraciones Fase de Incepción Fase de Elaboración Fase de Construcción Fase de Transición 1.4 Componentes del Proceso 1.5 Características del Proceso Unificado 1.6 El Proyecto de Software

25 Puntos de decisión planeados
1.3 Estructura del Proceso de Desarrollo Unificado: fases e iteraciones Puntos de decisión planeados (enfoque del negocio) Comprometer recursos para la fase de Elaboración Comprometer recursos para Construcción Producto suficiente maduro para usuarios-cliente Aceptación o fin de ciclo Incepcion Elaboracion Construccion Transicion Iteración preliminar arquitectura desarrollo transición Puntos de visibilidad planeados (enfoque técnico)

26 Una iteración En una iteración se puede desplazar por todas los workflows

27 Fases del Ciclo de Vida INCEPCION: Definir el objetivo del proyecto y elaborar el modelo del negocio ELABORACION: Planificar el proyecto, especificar los Modelos y sentar las bases para las Arquitecturas CONSTRUCCION: Construir el Producto TRANSICION: Transición de los usuarios al nuevo sistema.

28 Fases del Ciclo de Vida: INCEPCION
INCEPCION: Definir el objetivo del proyecto y elaborar el modelo del negocio Output de la Etapa: Visión documentada, donde se define los requisitos principales del proyecto, principales características y restricciones. Un inicial modelo Use-Case de negocio (10% a 20%) Un glosario de conceptos y términos del proyecto Un inicial Modelo del negocio, que incluya el contexto de la empresa y factores de éxito (Costo-Beneficio) Un inicial inventario y costeo de riesgos El Plan del Proyecto, indicando las etapas e iteraciones Si es posible, un prototipo inicial.

29 Fases del Ciclo de Vida: ELABORACION
ELABORACION: Planificar el proyecto, especificar los Modelos y sentar las bases para las Arquitecturas Output de la Etapa: Modelo del Use-Case (100% completado), todos los CdU y actores identificados y las descripciones de los CdU. Requerimientos suplementarios (generalmente son no funcionales) son recolectados y asociados a un CdU Descripción de la Arquitectura del Software Prototipo del software Lista de riesgos y Casos del negocio validados Plan del Proyecto completo y aprobado por el Usuario Manual del usuario preliminar.

30 Fases Ciclo de Vida: CONSTRUCCION
CONSTRUCCION: Construir el Producto Output de la Etapa: Primera versión del Producto (versión Beta) Pruebas del Producto Los Manuales del usuario Validación de los costos incurridos vrs. los costos estimados.

31 Fases Ciclo de Vida: TRANSICION
TRANSICION: Transición de los usuarios al nuevo sistema. Output de la Etapa: Testeo de la versión Beta para validar el nuevo sistema comparándolas con las expectativas del usuario. Plan de puesta en producción Tareas de migración y conversión de datos Capacitación y Entrenamiento del Usuario y del Área de Sistemas Instalación del producto en todos los ambientes del usuario, previamente definidos.

32 SESION 3: PROCESOS DE DESARROLLO SOFTWARE
1.0 Producción de SW: problemática, origen de los problemas, panorama contemporáneo. 1.1 ¿ Qué es el RUP? Características 1.2 Definiciones Generales 1.3 Estructura del RUP: fases e iteraciones Fase de Incepción Fase de Elaboración Fase de Construcción Fase de Transición 1.4 Componentes del Proceso 1.5 Características del Proceso Unificado 1.6 El Proyecto de Software

33 1.4 Componentes del proceso
El worker desarrolla una actividad que genera o consume un artefacto Una unidad de trabajo Define un rol y responsabilidades de un individuo o equipo Actividad Worker Describir un CdU Analista Una pieza de información que puede ser producida, modificada o usada por un proceso responsible de Artefacto Paquete de CdU Caso de Uso

34 1.5 Características del Proceso Unificado
I ) Arquitectura basada en componentes II ) Modelado visual en UML III) Administración de requerimientos IV) Desarrollo iterativo e incremental V ) Control del cambio VI) Verificación de la calidad

35 I ) Arquitectura basada en Componentes
Estructura la arquitectura del sistema en componentes. Los componentes pueden ser acoplados unos con otros, para soportar las funciones que se requiere del sistema. En el enfoque de desarrollo de software basado en componentes, se aplica mucho la reutilización. Ventajas: Al reducirse la cantidad de software a desarrollar, se logra la reducción de costos y de riesgos, con entregas más rápidas del SW La modularidad permite una separación clara de los elementos del sistema, facilitando el manejo de los cambios.

36 II ) Modelado visual Modele visualmente con UML, reconocido hoy en día como el estándar de la industria para la modelación de sistemas complejos. Desarrollar modelos para sistemas antes de su desarrollo es tan esencial como crear planos antes de construir un edificio. El lenguaje unificado de modelación (UML - Unified Modeling Language), nos permite visualizar y razonar sobre los modelos abstractos del software y, pasar al diseño con esquemas o diagramas de las ideas centrales. “Un porcentaje muy importante del cerebro de las personas está implicado en el procesamiento visual, que es una de las motivaciones que hay detrás de la presentación visual o gráfica de la información” (Edward Tufte-1992)

37 Modelado visual Ventajas: El uso de modelos que reflejan tanto la estructura como el comportamiento del sistema a desarrollar es un factor indispensable para una buena comunicación entre los miembros del equipo de desarrollo, usuarios finales y toda entidad involucrada con el sistema. Los modelos presentan en forma clara el diseño del sistema y facilitan la identificación de inconsistencias. Proporciona un elemento importante en la documentación ayudan a mantener la consistencia entre requerimientos, diseño e implementación.

38 Modelado Visual usando diagramas UML
Diagrama de Casos de Uso Diagrama de Clases Diagrama de Estado Use Case 1 GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) close( ) sortFileList( ) fillDocument( ) fList 1 FileList File read() fill the code.. Actor A Actor B Use Case 2 Use Case 3 Diagrama de Despliegue Diagrama de Colaboración 9: sortByName ( ) Document FileManager GraphicFile File Repository DocumentList FileList mainWnd : MainWnd Window95 Windows95 1: Doc view request ( ) Windows95 L 2: fetchDoc( ) 4: create ( ) gFile : GrpFile ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE ¹®¼­°ü¸® ¾ÖÇø´ 8: fillFile ( ) Windows user : Clerk NT Solaris fileMgr : FileMgr 3: create ( ) ¹®¼­°ü¸® ¿£Áø.EXE 6: fillDocument ( ) Alpha Windows UNIX NT ÀÀ¿ë¼­¹ö.EXE 7: readFile ( ) 5: readDoc ( ) Mainframe IBM repository : Repository document : Document µ¥ÀÌŸº£À̽º¼­¹ö Diagrama de Componentes mainWnd fileMgr : FileMgr document : Document gFile repository user ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. ¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­ È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) Construyendo un modelo visual de un sistema, diferentes diagramas son necesarios para representar diferentes vistas del sistema Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡ È­¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î º¸¿©ÁØ´Ù. 9: sortByName ( ) Diagrama de Secuencia

39 Evaluar los cambios a los requerimientos y medir su impacto.
III) Gestión de requerimientos La gestión de requerimientos se encarga de identificar, documentar, organizar y dar seguimiento a los requerimientos del sistema y a los cambios que puedan tener a lo largo del ciclo de vida. Un requerimiento es una condición o capacidad que el sistema debe satisfacer. Actividades: Documentar explícitamente los requerimientos del cliente y las funcionalidades y restricciones del sistema. Evaluar los cambios a los requerimientos y medir su impacto. Realizar el seguimiento de las trazas y actualizar documentación. “Los requerimientos son los cimientos sobre los cuáles se construye un producto software y, sin embargo, la incapacidad de gestionar sus cambios es una de las principales causas de entregas fuera de tiempo, exceder los presupuestos y no cumplir con la calidad esperada por el cliente” (Ian Sommerville et al )

40 Gestión de los requerimientos
Ventajas: Los requerimientos son administrados bajo un enfoque disciplinado Los requerimientos pueden ser priorizados, filtrados y rastreados Facilita una evaluación objetiva de la funcionalidad y desempeño Permite un detección oportuna de las inconsistencias entre los requisitos, los productos y los planes del proyecto.

41 IV) Desarrollo iterativo e incremental
Cada iteración del proceso produce un nuevo incremento del software, generándose una nueva versión. Ventajas: Centrado en lo importante Se captan requerimientos reales por la retroalimentación de los usuarios Mejor conocimiento del negocio en cada iteración Los usuarios disponen de evidencias del avance del desarrollo SW Los errores se evidencian temprano, corrigiéndose sin altos costos.

42 Desarrollo iterativo e incremental
Planeamiento inicial Requerimientos Análisis y Diseño Implementacion Prueba Despliegue Evaluacion Una versión ejecutable resulta de cada iteración

43 V) Control de cambios Las necesidades del negocio y los requerimientos cambian durante el ciclo de vida de los sistemas de software grandes. Gestionar los cambios del software usando un sistema de gestión de cambios y herramientas de soporte a los procedimientos de gestión de cambios. La gestión de las versiones y entregas es el proceso de identificar y mantener los registros de las diferentes versiones y entregas de un sistema (matriz de entregables) Ventajas: El requerimiento de cambios facilita la comunicación con los usuarios. Mantener la documentación actualizada. Las estadísticas de los cambios facilita evaluar el estado del proyecto

44 VI) Verificación de la calidad
Asegurar que el software cumple los estándares de calidad organizacionales La verificación de la calidad del software es parte del proceso, en todas las actividades e involucrando a los interesados (stakeholders). Aspectos a considerar: desviaciones de lo planeado, confiabilidad (resistencia a fallas al ejecutarse), validación (funcionamiento de acuerdo al uso esperado), desempeño (tiempo de respuesta aceptable en condiciones reales) Ventajas: Detección de inconsistencias en los requerimientos, diseño o implementaciones, como resultado de las pruebas. Las verificaciones y pruebas se centran en los puntos de mayor riesgo, asegurando su calidad. Detección temprana de errores, reduciendo el costo de su corrección.

45 Diagramas de UML Diagrama de Clases Diagrama de Casos de Uso
Diagramas de Comportamiento - Diagrama de Estados - Diagrama de Actividad Diagramas de Interacción - Diagrama de Secuencia - Diagrama de Colaboración Diagramas de Implementación - Diagrama de Componentes - Diagrama de Despliegue

46 Actividades de Gestión del Proyecto Software
Planificación del Proyecto Calendarización del Proyecto Gestión de Riesgos

47 PRACTICAS EN LABORATORIO
Uso del software BizAgi Process Modeler El BizAgi Process Modeler  permite diagramar y documentar los procesos en el estándar BPMN (Business Process Modelling Notacion).

48 BizAgi Process Modeler
Ejemplo

49 Preguntas ...

50 Gracias ...

51 FIN DE LA SESION 3