sesión 02 estructura, modelos y procesos

Ing. Lenin Huayta Flores

Sesin 02:Estructura, Modelos y Procesos

Ingeniera de Software


Planeacin de una estructura organizacional

1. Factores a considerar

2. Paradigmas organizacionales

3. Los actores en proyecto

4. Los trabajadores

2


1. Factores a considerar



Factores a considerar para formar Equipos de Software

Los siguientes factores deben ser considerados

cuando se selecciona la estructura del equipo del

proyecto de software...

Dificultad del problemas a ser resuelto

El tamao de las lneas de cdigo de los programas

resultantes o puntos funcin

El tiempo en que el equipo estar junto (tiempo de vida del

equipo)

El grado de modularidad del problema

La calidad y confiabilidad requeridas del sistema a ser

construido

La rigidez de la fecha de entrega

El grado de sociabilidad (comunicacin) requerida para el

proyecto.

4


Riesgos Asociados a las Personas

Cuestionamientos que deben ser resueltos:

Est disponible el mejor personal?

El staff tiene las habilidades adecuadas?

Hay suficiente personal disponible?

Existe el compromiso completo?

Habr gente que trabaje parcialmente?

El staff tiene las expectativas adecuadas?

El staff tiene el suficiente entrenamiento?

Podra la respuesta del staff ser baja?

5


2. Paradigmas organizacionales



Paradigmas Organizacionales

Paradigma cerrado estructura al equipo a travs de una

jerarqua de autoridad tradicional

Paradigma aleatorio estructura a un equipo de manera

dispersa y depende de la iniciativa individual de los

miembros del equipo

Paradigma abierto estructura al equipo de una manera en

la que se llevan a cabo algunos de los controles asociados

con el paradigma cerrado pero tambin mucha de la

innovacin ocurre cuando se usa el paradigma aleatorio

Paradigma sncrono depende de la fragmentacin natural

de un problema y organiza a los miembros del equipo para

trabajar en piezas del problema con poca comunicacin

activa entre ellos.

7


Distribucin del Esfuerzo

8

Actividades Front-end Comunicacin con el cliente

Anlisis

Diseo

Revisin y modificacin

Actividades de construccin

Codificacin o generacin de cdigo

Prueba e instalacin

Unitarias, integracin

Caja-blanca, caja-negra

Regresin

40 50%

15 20%

30 40%


3. Los actores



Los Actores

10

Lder de Proyecto

(gestor tcnico) SQA

Productores

(trabajadores)

Clientes

(requisitos)

Gestor superior

(aspectos de negocio)

Representante de usuario

(coordinador de usuarios)

Usuario final

(pruebas)


4. Los trabajadores



Trabajadores (Workers)

Personas que participan en el proceso

Tienen competencias especficas

En cada flujo de trabajo

Worker

12


Trabajadores

1. Analista de Sistemas

2. Especificador de Casos de Uso

3. Arquitecto

4. Ingeniero de Casos de Uso

5. Ingeniero de Componentes

6. Integrador de Sistemas

7. Diseador de Pruebas

8. Ingeniero de Pruebas de Integracin

9. Ingeniero de Pruebas del Sistema

13


Analista de Sistemas

Responsable del conjunto de requisitos

modelados en los casos de uso Requisitos funcionales y no funcionales

Delimitar el sistema

Encontrar actores y casos de uso

Asegurar modelos de casos de uso completos

y consistentes

Elaborar un glosario para mantener la

consistencia semntica

Dirigir el modelado

Coordinar la captura de requisitos

14

Analista de

Sistemas

Flujos de Trabajo

Requerimientos


Especificador de Casos de Uso

15

Responsable de la descripcin detallada de

un caso de uso

Establecer una comunicacin estrecha y

eficaz con los usuarios (directos)

Especificador

de C.U.

Flujos de Trabajo

Requerimientos


Diseador de Interfaces

16

Disear las interfaces de usuario Aspecto visual

Desarrollar prototipos de interfaces de

usuario para algunos casos de uso

Diseador de

Interfaces

Flujos de Trabajo

Requerimientos


Arquitecto

17

Requerimientos Describir la arquitectura y prioridades del modelo de

casos de uso

Anlisis Garantizar la integridad del modelo de anlisis

Correcto, consistente y legible

Diseo Garantizar la integridad de los modelos de diseo y

despliegue

Implantacin Garantizar la integridad del modelo de implantacin

Asignar componentes a nodos

Arquitecto

Flujos de Trabajo

Requerimientos Anlisis Diseo Implantacin


Ingeniero de Casos de Uso

18

Anlisis Mantener la integridad de las realizaciones de casos

de uso

Diseo Detallar las realizaciones de casos de uso

Verificar la correspondencia entre anlisis y diseo

Ingeniero

de C.U.

Flujos de Trabajo

Anlisis Diseo


Ingeniero de Componentes

19

Anlisis Definir y mantener las responsabilidades, atributos,

relaciones y requisitos especiales de una o varias

clases del anlisis

Diseo Definir y mantener las operaciones, mtodos,

atributos, relaciones y requisitos de implantacin de

una o ms clases del diseo

Implantacin Definir y mantener el cdigo fuente de uno o varios

componentes

Pruebas Desarrollar componentes de prueba que automatizan

algunos de los procedimientos de prueba

Ingeniero de

Componentes

Flujos de Trabajo

Anlisis Diseo Implantacin Pruebas


Integrador de Sistemas

20

Planificar la secuencia de construcciones

necesarias en cada iteracin

Integrar cada construccin a partir de sus

partes implementadas

Integrador de

Sistemas

Flujos de Trabajo

Implantacin


Diseador de Pruebas

21

Garantizar la integridad del modelo de

pruebas

Planear las pruebas Establecer objetivos de prueba apropiados

Seleccionar y describir casos de prueba y los

procedimientos de pruebaDiseador

de Pruebas

Flujos de Trabajo

Pruebas


Ingeniero de Pruebas de Integracin

22

Ejecutar las pruebas de integracin

Verificar el correcto funcionamiento de

componentes

Documentar los defectos

Ing. de Pruebas

de Integracin

Flujos de Trabajo

Pruebas


Ingeniero de Pruebas del Sistema

23

Ejecutar las pruebas del sistema para cada

iteracin completa

Verificar los resultados en conjunto con los

usuarios finales

Documentar los defectos

Facilidad para tener familiaridad con el

comportamiento observable del sistemaIng. de Pruebas

del Sistema

Flujos de Trabajo

Pruebas


Modelos y Procesos



Significado del proceso

Conjunto ordenado de tareas como Proceso: serie

de pasos con actividades, restricciones y recursos

que producen una salida de cierto tipo.

Cuando el proceso involucra la construccin de un

producto, a veces se menciona como Ciclo de Vida

(del producto).

25


Siguiendo un Proceso

Un proceso es un conjunto de procedimientos

(receta), organizado para construir productos que

satisfacen una seria de objetivos y estndares.

Los procesos son importantes porque imponen

consistencia y estructura en un conjunto de

actividades.

Sabemos cmo hacer algo bien y queremos forzar

que otros lo hagan de la misma forma.

26


Escribiendo un Proceso(un programa que otros deben seguir)

Prescribir todas las actividades principales

Usa recursos sujeto a restricciones

Puede estar compuesto de subprocesos

Cada actividad tiene un criterio de entrada y otro de

salida

Las Actividades estn organizadas en una

secuencia.

Establecer los objetivos de cada actividad.

27


Modelos de Procesos de Software

Prescripciones de la forma en que el desarrollo de

software debera llevarse a cabo.

Descripciones de la forma en que el desarrollo se

lleva a cabo realmente.

Cada modelo de desarrollo de software incluye los

requerimientos del sistema como entrada y el

producto librado al uso como salida.

28


Modelo Cascada

29

Definicin de Requerimientos

Diseo del Sistema y Software

Implementacin y Pruebas de Unidad

Integracin y Prueba

Operacin y Mantenimiento


(Proceso de desarrollo en la realidad)

30

ANLISIS DE REQUERIMIENTOS

DISEO DEL SISTEMA

DISEO DE PROGRAMAS

IMPLEMENTACIN DE PROGRAMAS

PRUEBA UNITARIAPRUEBA DE

INTEGRACIN

PRUEBA DEL SISTEMA

LIBRAR AL USO

MANTENIMIENTO


Cascada c/prototipos

31

ANALISIS DE REQUERIMIENTOS

DISEO DEL SISTEMA

DISEO DE PROGRAMAS

IMPLEMENTACION DE PROGRAMAS

PRUEBA UNITARIA Y DE INTEGRACION

PRUEBA DEL SISTEMA

PRUEBA DE ACEPTACION

OPERACION Y MANTENIMIENTO

PROTOTIPADO


Modelo V

32


Diseo del Sistema

Desarrollo de Sub-sistemas

Integracin de Sistemas

Instalacin de Sistemas

Evolucin del Sistema

Desincorporacin del Sistema


Modelo de Prototipacin

33

LISTA DEREVISIONES

PROTOTIPARREQUERIMIENTOS

revisarprototipo

LISTA DEREVISIONES

PROTOTIPARDISEO

LISTA DEREVISIONES

PROTOTIPARSISTEMA

REQUERIMIENTOSDEL SISTEMA

(a veces informales o incompletos)

PRUEBA

SISTEMALIBRADOAL USO


Especificacin Operacional:

34

Los requerimientos se ejecutan utilizando

un producto de software

EJECUTAR YREVISAR

ESPECIFICACIONOPERACIONAL(orientada al

problema)

ESPECIFICACIONTRANSFORMADA

(orientada a la implementacin)

PRUEBA





Modelo Transformacional

35

TRANSFORM. N..

Comparar con requerimientos; actualizar si se

necesita

ESPECIFICACIONFORMAL

TRANSFORM. 2 PRUEBA




TRANSFORM. 1

REGISTRO FORMAL DEL DESARROLLO

Secuencia de transformaciones + sus justificaciones


Desarrollo en Fases

36

Usarliberacin 1

Usarliberacin 2

Usarliberacin 3

Construirliberacin 1



Tiempo

DES

AR

RO

LLA

DO

RES

USU

AR

IOS

Sistemas en Desarrollo

Sistemas en Produccin


Incrementos e Iteraciones

37

DESARROLLO INCREMENTAL

DESARROLLO ITERATIVO


Modelo Espiral

38


Modelo Espiral

39


Modelo de Proceso y de Ciclo de Vida

La preocupacin por el Proceso (fin de los 80) es

ms reciente que la definicin del Ciclo de Vida

(fin de los 60)

En general se asocia a la nocin de modelo de

proceso un mayor detalle y precisin

Los modelos previos presentan en general poco nivel

de detalle y fueron propuestos originalmente como

modelos de Ciclo de Vida

40


Herramientas y Tcnicas para el Modelado de Procesos

Elegir un lenguaje o notacin

Tener claro objetivos del modelo

Detalle (granularidad)

Describir-prescribir

Predecir (requiere agregar relaciones cuantitativas entre

elementos)

Ejecutar (asistir en el uso)

Vamos a ver algunos ejemplos

41


Modelo de Factores que inciden en la productividad (Abdel-Hamid 96)

Porcin de personal experiente

Productividad potencial nominal

de personal experiente

Productividad potencial

nominal de personal nuevo

Productividad potencial

promedio nominal

Productividad

potencial

% completado del

proyecto

Multiplicador de

aprendizaje

Productividad de Desarrollo

Porcin real de persona-da

en el proyecto

Sobre/bajo Tolerancia

del trabajo

Prdidas por motivacin y

comunicacin

Presin del Calendario

Esfuerzo adicional de

omunicaciones

Tamao del equipo

42


Estructura del Desarrollo de Software (Abdel-Hamid 96)

43

PRODUCCION DE SOFTWARE GESTION DE RRHH

PLANIFICACION CONTROL

Prdidas del Proceso

Deteccin yCorreccin de Errores

Esfuerzo de Q A

Tasa deDesarrollode SW

Tasa deErrores

ProductividadPotencial

ProductividadReal

Aprendizaje

Tasa deIncorporacinDe personal

Tasa debajas

Personal

Mezcla de experiencia del personal

Nivel de Personal percibido como necesario

Presin del Calendario

Ajustes aPersonal yCalendario

Fecha Planificada de Terminacin

Fecha estimada de Terminacin

Productividad Percibida

Tareas percibidascomo terminadas

Esfuerzo faltantepercibido

Nivel de precisinen medir el avance

Estado percibido del proyecto


Modelado de Proceso Para que?

Entender el proceso (real o propuesto)

Revelar inconsistencias, problemas (base para la mejora)

Simulacin del proceso y planificacin del proyecto

Poco nivel de detalle adicional necesario

Factores que afectan la productividad global.

Relaciones (cuantificadas) entre los factores.

Soportados por software que simulan el proceso.

Gua en la ejecucin real del proceso

Se precisa agregar mltiples detalles

44


Modelo de Ingeniera del Proceso

Especificacin - establecer los requerimientos y

restricciones del sistema

Diseo - Producir un modelo en papel del sistema

Manufactura - construir el sistema

Prueba - verificar que el sistema cumpla con las

especificaciones requeridas

Instalacin - entregar el sistema al usuario y

asegurar su operacionalidad

Mantenimiento - reparar fallos en el sistema cundo

sea descubiertos

45


Problemas en el Modelo del Proceso

Normalmente, las especificaciones son incompletas

o anmalas

No existe una distincin precisa entre la

especificacin, el diseo y la manufactura

Solo hasta que el sistema se ha producido se puede

probar

El software no se puede remplazar siempre durante

el mantenimiento

46


Modelos Genricos del Desarrollo de Software

Modelo de Cascada

Separar en distintas fases de especificacin y desarrollo.

Desarrollo Evolutivo

La especificacin y el desarrollo estn intercalados.

Prototipado

Un modelo sirve de prototipo para la construccin del

sistema final.

Transformacin Formal

Un modelo matemtico del sistema se transforma

formalmente en la implementacin.

Desarrollo basado en Reutilizacin

El sistema es ensamblado a partir de componentes

existentes.

47


Modelo Cascada (grfica)

48


Diseo del Sistema y Software

Implementacin y Pruebas de Unidad

Integracin y Prueba

Operacin y Mantenimiento


Fases del Modelo de Cascada

Anlisis de requerimientos y definicin.

Diseo del sistema y del software.

Implementacin y prueba de unidades

Integracin y prueba del sistema.

Operacin y mantenimiento.

La dificultad en esta modelo reside, en la dificultad

de hacer cambios entre etapas.

49



50

DesarrolloDesarrollo

Especificacin

Desarrollo

Validacin

Versin Inicial

VersionesIntermedias

VersinFinal

Descripcin



Problemas

Poca visibilidad en el proceso

Los sistemas estn pobremente especificados

Se requieren habilidades especiales.

Aplicabilidad

Para sistemas interactivos pequeos o medianos.

Para partes de sistemas grandes (p.ej. la interfaz de

usuario).

Para sistemas de corta vida.

51


Prototipado

Prototipado exploratorio

El objetivo es trabajar con clientes hasta evolucionar a un

sistema final, a partir de una especificacin inicial. Se debe

comenzar con unas especificaciones bien entendidas.

Prototipado de throw-away.

El objetivo es entender los requerimientos del sistema. Se

puede comenzar con especificaciones poco entendidas.

52


Problemas y Riesgos con los Modelos

Cascada.

Alto riesgo en sistemas nuevos debido a problemas en las

especificaciones y en el diseo.

Bajo riesgo para desarrollos bien comprendidos utilizando

tecnologa conocida.

Prototipado.

Bajo riesgo para nuevas aplicaciones debido a que las

especificaciones y el diseo se llevan a cabo paso a paso.

Alto riesgo debido a falta de visibilidad

Evolutivo.

Alto riesgo debido a la necesidad de tecnologa avanzada y

habilidades del grupo desarrollador.

53


Manejo de Riesgos

La tarea principal del administrador consiste en

minimizar riesgos.

El riesgo inherente en una actividad es se mide en

base a la incertidumbre que presenta el resultado

de esa actividad.

Las actividades con alto riesgo causan sobre-costes

en cuanto a planeacin y costos

El riesgo es proporcional al monto de la calidad de

la informacin disponible. Cuanto menos

informacin, mayor el riesgo.

54


Modelos de Procesos Hbridos

Los sistemas grandes estn hechos usualmente de

varios subsistemas.

No es necesario utilizar el mismo modelo de proceso

para todos los subsistemas.

El prototipado es recomendado cuando existen

especificaciones de alto riesgo.

El modelo de cascada es utilizado en desarrollos

bien comprendidos.

55


Modelo de Proceso de Espiral

56


Fases del Modelo de Espiral

Planteamiento de Objetivos

Se identifican los objetivos especficos para cada fase del

proyecto.

Identificacin y reduccin de riesgos.

Los riesgos clave se identifican y analizan, y la informacin

sirve para minimizar los riesgos.

Desarrollo y Validacin.

Se elige un modelo apropiado para la siguiente fase del

desarrollo.

Planeacin.

Se revisa el proyecto y se trazan planes para la siguiente

ronda del espiral.

57


Plantilla para una ronda del espiral

Objetivos.

Restricciones.

Alternativas.

Riesgos.

Resolucin de riesgos.

Resultados.

Planes.

Garantas (commitments).

58


Mejoramiento de la Calidad en el Modelo de Espiral

Objetivos

Mejorar significativamente la calidad del software.

Restricciones.

Dentro de los 3 primeros anos.

Sin que se produzcan grandes inversiones de capital.

Sin que se lleven a cabo grandes cambios organizacionales.

Alternativas.

Reutilizar software certificado existente.

Introducir especificaciones formales y verificacin.

Invertir en herramientas de prueba y validacin.

59


Mejoramiento de la Calidad

Riesgos.

No existen mejoras en el software baratas.

Las mejoras en la calidad pueden incrementar costes

excesivamente

Los nuevos mtodos pueden causar bajas en el personal.

Solucin de riesgos.

Estudio de la literatura existente.

Proyecto piloto.

Bsqueda de todos los componentes reutilizables

potenciales.

Identificacin del soporte disponible de herramientas

Entrenamiento al personal y seminarios motivacionales.

60



Resultados.

La experiencia en mtodos formales es limitada - es muy

difcil cuantificar las mejoras.

Limitado el soporte en herramientas para sistemas de

desarrollo de la compaa.

Existencia de componentes reutilizables, pero poco soporte

de herramientas de reuso.

Planes.

Explorar la opcin de la reutilizacin a mas detalle.

Desarrollar herramientas prototipo para reutilizacin.

Explorar el esquema de certificacin de componentes.

Garantas.

Explorar los siguientes 18 meses.

61


Modelo de Espiral para la elaboracin de un catlogo

Objetivos

Desarrollar un catlogo de componentes de software

Restricciones.

A un ano.

Debe soportar los tipos de componentes existentes.

Costo total menor de $100,000.

Alternativas.

Comprar software de captura de informacin.

Comprar bases de datos y desarrollar el catlogo utilizando

la BD.

Desarrollar catlogo de propsito especial.

62



Riesgos.

Puede ser imposible satisfacer las restricciones.

La funcionalidad del catlogo puede ser inapropiada.

Solucin de riesgos.

Desarrolla un prototipo del catlogo (utilizando lenguajes de

cuarta generacin 4GL y una BD existente) para clarificar

los requerimientos.

Relaja restricciones de tiempo.

63



Resultados.

Los sistemas de captura de informacin son inflexibles. Los

requerimientos no pueden cumplirse.

El prototipo que utiliza la BD puede mejorarse para

completar el sistema.

El desarrollo de un catlogo de propsito especfico no es

costeable.

Planes.

Desarrolla el catlogo utilizando una BD existente

mejorando el prototipo y la interfaz de usuario.

Garantas.

Explorar los siguientes 12 meses.

64


Flexibilidad en el modelo de Espiral

Para sistemas bien comprendidos utiliza el Modelo

de Cascada. La fase de anlisis de riesgos es

relativamente fcil.

Con requerimientos estables y sistemas de

seguridad crticos, utiliza modelos formales.

Con especificaciones incompletas, utiliza el modelo

de prototipado.

Pueden utilizarse modelos hbridos en distintas

partes del desarrollo.

65


Ventajas del Modelo de Espiral

Centra su atencin en la reutilizacin de

componentes y eliminacin de errores en

informacin descubierta en fases iniciales.

Los objetivos de calidad son el primer objetivo.

Integra desarrollo con mantenimiento.

Provee un marco de desarrollo de hardware/

software.

66


Problemas con el Modelo de Espiral

El desarrollo contractual especifica el modelo del

proceso y los resultados a entregar por adelantado.

Requiere de experiencia en la identificacin de

riesgos.

Requiere refinamiento para uso generalizado.

67


Visibilidad de Procesos

Los sistemas de software son intangibles por lo que

los administradores necesitan documentacin para

identificar el progreso en el desarrollo.

Esto puede causar problemas..

El tiempo planeado para entrega de resultados puede no

coincidir con el tiempo necesario para completar una

actividad.

La necesidad de producir documentos restringe la iteracin

entre procesos.

El tiempo para revisar y aprobar documentos es

significativo.

El modelo de cascada es an el modelo basado en

resultados mas utilizado.

68


Documentos del Modelo de Cascada

Actividad Documentos Producidos

Anlisis de Requerimientos Documento de Requerimientos

Definicin de Requerimientos Documento de Requerimientos

Especificacin del Sistema Especificacin Funcional, Plan de Pruebas de Aceptacin

Diseo Arquitectural Especificacin de la Arquitectura, y Plan de Pruebas del

Sistema

Diseo de Interfaces Especificacin de las Interfaces y Plan dePpruebas de

Integracin

Diseo Detallado Especificacin del diseo y Plan de prueba de Unidades

Codificacin Cdigo de Programa

Prueba de Unidades Reporte de prueba de unidades

Prueba de Mdulos Reporte de prueba de mdulos

Prueba de Integracin Reporte de prueba de integracin y Manual de usuario

final

Prueba del Sistema Reporte de prueba del sistema

Prueba de Aceptacin Sistema final mas la documentacin

69


Visibilidad del Modelo

Modelo de Proceso Visibilidad del Proceso

Modelo de Cascada Buena visibilidad, cada actividad produce un documento o

resultado.

Desarrollo Evolutivo Visibilidad pobre, muy caro al producir documentos en

cada iteracin.

Modelos Formales Buena visibilidad, en cada fase deben producirse

documentos.

Desarrollo orientado a la reutilizacin Visibilidad moderada. Importante contar con

documentacin de componentes reutilizables.

Modelo de Espiral Buena visibilidad, cada segmento y cada anillo del espiral

debe producir un documento.

70


Responsabilidad profesional

Los Ingenieros de software no solo deben considerar

aspectos tcnicos. Deben tener una visin mas

amplia, en lo tico, social y profesional.

No existe estatutos para ninguno de estos aspectos.

Desarrollo de sistemas militares.

Piratera.

Que es mejor para la profesin de Ingeniero de Software.

71


Aspectos ticos

Confidencialidad.

Competencia.

Derechos de propiedad intelectual.

Mal uso de la computadora.

72


Resumen

La Ingeniera de software concierne a las teoras,

mtodos y herramientas para el desarrollo,

administracin y evolucin de productos de

software.

Los productos de software consisten de programas y

documentacin. Los atributos de los productos son,

mantenabilidad, dependabilidad, eficiencia y

usabilidad.

El proceso de software consiste en aquellas

actividades involucradas en el desarrollo de

software.

73


Resumen

El modelo de cascada considera cada actividad del

proceso como una actividad discreta.

El modelo de desarrollo evolutivo considera

actividades del proceso en forma concurrente.

El modelo de espiral se basa en anlisis de riesgos.

La visibilidad del proceso involucra la creacin de

documentos o resultados de las actividades.

Los Ingenieros de software deben tener

responsabilidades ticas, sociales y profesionales.

74


OtrosIEEE-Std1074-1991

Standard for Developing Software Life Cycle

Processes

Alcance

Indica un conjunto de actividades que constituyen los

procesos que son obligatorios para el desarrollo y

mantenimiento del software, tanto por si slo, como

formando parte de un sistema.

No incluye actividades para el desarrollo del hardware,

realizacin de compras, ...

No recomienda un ciclo de vida especfico

Aplicabilidad

Proyectos de desarrollo y mantenimiento de software

Descomponer proyectos grandes en subproyectos,

75


Estndar ESA para el Ciclo de Vida

76

sesión 02 estructura, modelos y procesos

Documents