1 PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE.

1

ESCUELA ACADEMICO PROFESIONAL DE

INGENIERIA DE SISTEMAS

PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE

Curso : Ingeniería de Software

Sesión 3 :

2 EAP INGENIERIA DE SISTEMAS Curso Ingeniería de Software

Temario ...

El Proceso Unificado (RUP)

Definiciones Generales.

Fases de RUP e Iteraciones.

Componentes del Proceso.

Características del Proceso Unificado.

El Proyecto de Software

PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE

Sesión 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ísticas1.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 Proceso1.5 Características del Proceso Unificado1.6 El Proyecto de Software


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

1.0 Producción de software: Problemática


• 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

Producción de software: Orígen de los problemas


¿Cuáles son los retos que afronta la ingeniería de software en el siglo XXI ?

1. 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

2. 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)

3. 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

Producción de software: Panorama contemporáneo


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ísticas1.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




El Proceso Unificado (RUP) ...


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

Sistema Software

Proceso de Desarrollo de Software



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



Conducido por Diagramas de Caso de UsoUn 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.



Centrado en ArquitecturasEl 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.



Desarrollo Iterativo e IncrementalEs 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.


Los Equipos necesitan Procesos

para construir un Sistema

Lenguaje de Modelado

Procesos Unificados

Desarrollo basado en Equipos


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.


Los puntos clave en el desarrollo SW:

Las 4 P


Las Personas son decisivas


¿Qué es un Sistema de Software?


Artefacto


1.5 Las 5 expectativas de la Ingeniería de SW

La Ingeniería de Software contemporánea tiene 5 expectativas importantes:

1. 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.”3. Mantener todo el trabajo visible, para que el Team pueda

disponer de todos los requisitos, diseños, códigos y pruebas.

4. 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ños5. Medir y lograr las metas de calidad.


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ísticas1.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




1.3 Estructura del Proceso de Desarrollo Unificado: fases e iteraciones

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

Puntos de decisión planeados (enfoque del negocio)

Iteración preliminar

Iteraciónarquitectura

Iteración arquitectura

Iteración desarrollo

Iteracióndesarrollo

Iteración desarrollo

Iteración transición

Iteracióntransición

Puntos de visibilidad planeados (enfoque técnico)

Incepcion Elaboracion Construccion Transicion


Una iteración

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


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.


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.


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.


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.


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.


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ísticas1.2 Definiciones Generales1.3 Estructura del RUP: fases e iteraciones




1.4 Componentes del proceso

Worker

Actividad

Artefacto

Paquete de CdUCaso de Uso

responsible de

Analista

Una unidad de trabajo

Una pieza de información que puede ser producida, modificada o usada por un proceso

Define un rol y responsabilidades de un individuo o equipo

Describir un CdU

El worker desarrolla una actividad que genera o consume un artefacto


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


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.


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)


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.

PO

SG

RA

DO

- F

IIS -

UN

IF

acu

ltad

de

Ing

enie

ría

Ind

ust

rial

y d

e S

iste

mas

38

Modelado Visual usando diagramas UML

Actor A

Use Case 1

Use Case 2

Actor B

user : Clerk

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

9: sortByName ( )

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fillDocument ( )

4: create ( )

8: fillFile ( )

Window95

¹®¼ °ü¸®

Å¬¶óÀÌ¾ðÆ®.EXE

Windows

NT

¹®¼ °ü¸® ¿£Áø.EXE

WindowsNT

Windows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

AlphaUNIX

IBM

Mainframe

µ¥ÀÌÅ¸º£ÀÌ½º¼ ¹ö

Windows95

¹®¼ °ü¸® ¾ÖÇÃ¸´Document

FileManager

GraphicFile

File

Repository DocumentList

FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

Æ¯Á¤¹®¼ ¿¡ ́ ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù.

È ÀÏ°ü̧ ®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼

°´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù.

È ̧é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ̧ §º°·Î

Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close fileUse Case 3

Diagrama de Casos de Uso

Diagrama de Clases

Diagrama de Colaboración

Diagrama de Secuencia

Diagrama de Componentes

Diagrama deEstado

Diagrama de Despliegue

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

Construyendo un modelo visual de un sistema,diferentes diagramas son necesarios para representar diferentes vistas del sistema


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. -1997)


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.


IV) Desarrollo iterativo e incrementalCada 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.


Desarrollo iterativo e incremental

Planeamiento inicial

Planeamiento

Requerimientos

Análisis y Diseño

Implementacion

Prueba

Despliegue

Evaluacion

Una versión ejecutable resulta de cada iteración


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


VI) Verificación de la calidadAsegurar que el software cumple los estándares

de calidad organizacionalesLa 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.


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


1.6 Gestión del Proyecto Software

Actividades de Gestión del Proyecto Software

Planificación del Proyecto

Calendarización del Proyecto

Gestión de Riesgos


PRACTICAS EN LABORATORIO

Uso del software BizAgi Process Modeler

http://www.bizagi.com

El BizAgi Process Modeler permite diagramar y documentar los procesos en el estándar BPMN(Business Process Modelling Notacion).

http://www.bizagi.com/







Ejemplo

BizAgi Process Modeler







Preguntas ...


Gracias ...


FIN DE LA SESION 3

1 PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE.

Documents

Transcript of 1 PROCESO DE SOFTWARE Y GESTION DE PROYECTOS DE SOFWARE.