3-Proceso11

04/12/23 Ing. de Software 1CH2-1

El proceso de desarrollar software (organización y disciplina en las actividades) contribuyen a la calidad del software y a la velocidad con que se desarrolla

* Significado del Proceso - seguir, escribir

* Modelos de Proceso de Software

* Herramientas y Técnicas

* Modelado en la Práctica

Modelando el proceso y el Ciclo de Vida Puntos a tratar

04/12/23 Ing. de Software Modelando el Proceso -2

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 construcción de un producto, a veces se menciona como Ciclo de Vida (del producto).


Siguiendo un Proceso

• Un proceso es un conjunto de procedimientos (receta), organizado para construir productos que satisfacen una seria de objetivos y estándares.

• Los procesos son importantes porque imponen consistencia y estructura en un conjunto de actividades.

• Sabemos cómo hacer algo bien y queremos forzar que otros lo hagan de la misma forma.


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 están organizadas en una

secuencia. • Establecer los objetivos de cada actividad.


Modelos de Proceso de Software

• Prescripciones de la forma en que el desarrollo de software debería 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.


Modelo CascadaANALISIS DE

REQUERIMIENTOS

DISEÑO DEL SISTEMA

DISEÑO DE PROGRAMAS

IMPLEMENTACION DE PROGRAMAS

PRUEBA UNITARIA Y DE INTEGRACION

PRUEBA DEL SISTEMA

PRUEBA DE ACEPTACION

OPERACIONY MANTENIMIENTO


(Proceso de desarrollo en la realidad) ANALISIS DE

REQUERIMIENTOS

DISEÑO DEL SISTEMA



PRUEBA UNITARIA PRUEBA DE

INTEGRACION

PRUEBA DEL SISTEMA

LIBRAR AL USO

MANTENIMIENTO


Espacios del Problema y de la Solución

Problema Solución

ANALISIS DE REQUERIMIENTOS

DISEÑO DEL SISTEMA



Restricciones

Tecnológicas

• Intentar solucionar un problema a menudo aclara el problema

• Evaluar los atributos de calidad externos del software (solución) requiere que exista “comportamiento”


Cascada c/prototipos

ANALISIS DE REQUERIMIENTOS

DISEÑO DEL SISTEMA




PRUEBA DEL SISTEMA



PROTOTIPADO

Validar

Verificar


Modelo VANALISIS DE

REQUERIMIENTOS

DISEÑO DEL SISTEMA




PRUEBA DEL SISTEMA



Verificar diseño

Validar requerimientos


Modelo de PrototipaciónLISTA DE

REVISIONESLISTA DE

REVISIONESLISTA DE

REVISIONES

PROTOTIPARREQUERIMIENTOS

PROTOTIPARDISEÑO

PROTOTIPARSISTEMA

PRUEBA

SISTEMA LIBRADO AL USO

REQUERIMIENTOS DEL SISTEMA

(a veces informales o incompletos)

revisarprototipo

revisión de usuario/cliente


Especificación Operacional: los requerimientos se ejecutan utilizando un producto de software

PRUEBA


Ejecutar yRevisar

ESPECIFICACIONOPERACIONAL

(orientada al problema)

ESPECIFICACION TRANSFORMADA(orientada a la

implementación)




Modelo TransformacionalComparar

con requerimien

tos; actualizar si se necesita

ESPECIFICACIONFORMAL

TRANSFORM. N. .

TRANSFORM. 2

TRANSFORM. 1

REGISTRO FORMAL DEL DESARROLLO

Secuencia de transformaciones+ sus justificaciones




PRUEBA


Desarrollo en Fasescon liberaciones parciales

Sistemas en Desarrollo

Sistemas en Producción

DES

AR

RO

LLA

-D

OR

ES

USU

AR

IOS

Construir liberación 1

Usar Lib. 1


Usar Lib. 2


Usar Lib. 3

Tiempo


Desarrollo en Fasescon evaluaciones parciales

Sistemas en Desarrollo

Sistemas en Evaluación

DES

AR

RO

LLA

-D

OR

ES

USU

AR

IOS


Evaluar Lib. 1


Evaluar Lib. 2


Evaluar Lib. 3

Tiempo


Incrementos e IteracionesDESARROLLO INCREMENTAL

DESARROLLO ITERATIVO


Modelo Espiral

Planificar Desarrollar y Probar

Determinar Objetivos,Alternativas y Restricciones

Evaluar Alternativas y Riesgos

startRequirims,plan ciclo/vida

Presupto1

Alternativas1

Restriccs1

An. Riesgos1

An.Riesgos2

An.Riesgos3

Análisis de Riesgos4

Restriccs2

Restriccs3

Restriccs4

Prespto2Prespto3Prespto4

Altern

ativas 2

Altern

ativ

as3

Altern

ativ

as4

Prototipo1

Proto-tipo2

Proto-tipo3

Proto-tipo4

Concepto deoperacion

Reqs.

de

Softwar

e

Requers.

Validados

Plan de Desarrollo

Plan de Integracion

y Pruebas

Diseñ

o de

So

ftwar

e

Diseño Validado,

y verificado

Diseño Detallado

Codificación

Prueba Unitaria

Prueba del SistemaPrueba de

AceptaciónPlan de

Implantación


Modelo de Proceso y de Ciclo de Vida

• La preocupación por el “Proceso” (fin de los ’80) es más reciente que la definición del “Ciclo de Vida” (fin de los ’60)

• En general se asocia a la noción de modelo de proceso un mayor detalle y precisión

• Los modelos previos presentan en general poco nivel de detalle y fueron propuestos originalmente como modelos de Ciclo de Vida


Herramientas y Técnicas para el Modelado de Procesos• Elegir un lenguaje o notación• Tener claro objetivos del modelo

Detalle (granularidad)Describir-prescribirPredecir (requiere agregar relaciones

cuantitativas entre elementos)Ejecutar (asistir en el uso)

• Vamos a ver algunos ejemplos…


Esquema ETVX

• Entry Task Verification eXit• Entry: Condiciones necesarias para poder

cumplir una tarea• Task: Tarea que se lleva a cabo

Quién y con qué responsabilidad

• Verification: Criterios para verificar que concluyó de forma adecuada (a veces se le menciona como Validation)

• eXit: Resultados a obtener


Notación de Lai

• Artefacto, subartefacto, Actividad,subActividad, Rol, Operación, Análisis

• Tablas de estado muestran información referida a cuán completo está un artefacto en un instante dado

• Tablas de estado muestran cómo puede operar el proceso sobre los artefactos

• Diagramas de transición de estado muestran cómo se relacionan unos estados con otros (máquina de estados compuestos)

• Formularios para definir cada tipo de elemento (en los que se especifican las relaciones)


Lai- relaciones entre elementos

Actividad

Operación

Rol

Artefacto

Estado-P(roceso)

Estado- A(rtefacto)

Análisis

Ejecuta

Ejecuta

Ejecuta Manipula

Sub-actividad

Sub-artefacto

compuesto por controlaRefiere a

cambia

Refiere a

proceso artefacto


Lai – Formulario para operación

Componente Definición

Pre-Condición Predicado en Estado-A para poder realizarla

Artefacto El artefacto manipulado por la operación

Acción La función a ser relizada por la operación

Rol Lista de roles habilitados

Post-Condición Predicados sobre Estado-A


Notaciones y herramientas

• UML - Diagramas de AcitividadEditores UML

• BPMN – Especificación de Procesos (no necesariamente de software)Editores BPMN

• SPEM 2Eclipse Process Framework Composer


Modelos “pesados” y “livianos”

• Modelos pesados (heavyweight)Énfasis en pasos, artefactos, roles,

controles…Ejemplos:

RUP, MUM

• Modelos livianos (lightweight), ágilesManifiesto ÁgilEjemplos:

XP, SCRUM, DSDM, FDD


Manifiesto por el Desarrollo Ágil de Software (2001)

• Hemos aprendido a valorar: Individuos e interacciones sobre procesos y

herramientasSoftware funcionando sobre documentación

extensivaColaboración con el cliente sobre negociación

contractualRespuesta ante el cambio sobre seguir un plan

aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.


Principios del Manifiesto Agil• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los

procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.• Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con

preferencia al periodo de tiempo más corto posible.• Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.• Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno

y el apoyo que necesitan, y confiarles la ejecución del trabajo. • El método más eficiente y efectivo de comunicar información al equipo de desarrollo y

entre sus miembros es la conversación cara a cara.• El software funcionando es la medida principal de progreso.• Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

• La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.• A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a

continuación ajustar y perfeccionar su comportamiento en consecuencia.


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

Porción de personal experiente

Productividad potencial nominalde personal experiente

Productividad potencialpromedio nominal

Productividad potencial nominal de personal nuevo

Productividad potencial

% completadodel proyecto

Multiplicadorde aprendizaje

Sobre/bajo Tolerancia del trabajo

Porción real de persona-díaen el proyecto

Presión del Calendario

Pérdidas por motivación y comunicación

Tamaño del equipo

Esfuerzo adicional de comunicación

Productividad de Desarrollo


Estructura del Desarrollo de Software (Abdel-Hamid 96)

Pérdidas del Proceso

Detección y Corrección de Errores

Productividad potencial

Personal

Tasa deincorporaciónde personal

Mezcla de experienciadel personal

Nivel de Personalpercibido comonecesario

Presión del Calendario

Fecha estimada deTerminación

Estado percibido del proyecto

Productividad Percibida

Esfuerzode Q A

Tasa deErrores

Aprendizaje

PRODUCCION DE SOFTWARE

Tasa debajas

GESTION DE RRHH

CONTROLPLANIFICACION

Ajustes aPersonal yCalendario

Fecha Planificadade Terminación

Tareas percibidascomo terminadas

Nivel de precisiónen medir el avance

Esfuerzo faltante percibido

Productividad Real

Tasa deDesarrollode SW


Modelado de Proceso¿Para qué?

• Entender el proceso (real o propuesto)Revelar inconsistencias, problemas (base para

la mejora)

• Simulación del proceso y planificación del proyectoPoco nivel de detalle adicional necesarioFactores que afectan la productividad global.Relaciones (cuantificadas) entre los factores. Soportados por sw que simulan el proceso.

• Guía en la ejecución real del procesoSe precisa agregar múltiples detalles


Preguntas• ¿Qué ventajas presenta el modelo en cascada?• ¿Qué problemas presenta este modelo para

atacar proyectos de envergadura?• ¿Qué aporta la construcción de prototipos?• ¿Qué agrega el modelo V respecto al modelo en

cascada?• ¿Qué ventajas presenta el desarrollo en Fases

con liberaciones parciales?• ¿Qué diferencias presenta con el desarrollo en

Fases con evaluaciones parciales?• ¿Qué aspecto introduce el Modelo en Espiral?


Preguntas (2)• ¿Para qué sirve el esquema ETVX?• ¿Para qué nos puede interesar modelar un

proceso?• ¿Los modelos de Abdel Hamid son descriptivos o

prescriptivos?

Documents

3-Proceso11