ch2-1 el proceso de desarrollar software (organización y disciplina en las actividades) contribuyen...

CH2-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

* 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

Ing. de Software

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

Ing. de Software

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.

Ing. de Software

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.

Ing. de Software

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.

Ing. de Software

Modelo Cascada

ANALISIS DE REQUERIMIENTOS

DISEÑO DEL SISTEMA

DISEÑO DE PROGRAMAS

IMPLEMENTACION DE PROGRAMAS

PRUEBA UNITARIA Y DE INTEGRACION

PRUEBA DEL SISTEMA

PRUEBA DE ACEPTACION OPERACION

Y MANTENIMIENTO

Ing. de Software

(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

Ing. de Software

Cascada c/prototipos

ANALISIS DE REQUERIMIENTOS

DISEÑO DEL SISTEMA




PRUEBA DEL SISTEMA

PRUEBA DE ACEPTACION

OPERACIONY MANTENIMIENTO

PROTOTIPADO

Validar

Verificar

Ing. de Software

Modelo VANALISIS DE

REQUERIMIENTOS

DISEÑO DEL SISTEMA




PRUEBA DEL SISTEMA

PRUEBA DE ACEPTACION

OPERACIONY MANTENIMIENTO

Verificar diseño

Validar requerimientos

Ing. de Software

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

Ing. de Software

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)



Ing. de Software

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

Ing. de Software

Desarrollo en Fases

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

Ing. de Software

Incrementos e IteracionesDESARROLLO INCREMENTAL

DESARROLLO ITERATIVO

Ing. de Software

Modelo Espiral

Planificar

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ónIng. de Software

RAD - Desarrollo Rápido de Aplicaciones

• El Desarrollo rápido de aplicaciones (o RAD) definido por James Martin a principios de la década de 1980, consiste en un ciclo de desarrollo corto basado en tres fases (Requisitos, Diseño y Construcción) con un plazo de entrega ideal de 90 a 120 días como máximo.

Ing. de Software

DSDM (Método de Desarrollo de Sistema Dinámico)

• El se desarrolló para completar lo que le faltaba al método RAD al proporcionar una estructura que tome en cuenta el ciclo de desarrollo completo.

• Las características principales del método DSDM son las siguientes:

• Participación del usuario• Desarrollo iterativo y creciente• Frecuencia de entrega mejorada• Pruebas integradas en cada fase• La aceptación de los productos entregados depende

directamente del cumplimiento de los requisitos.

Ing. de Software

Método: Proceso Unificado

• Es un proceso de desarrollo iterativo y creciente. Esto significa que el proyecto se divide en fases más cortas y que se envía una nueva versión gradual al final de cada fase.

• Este enfoque está basado en el modelo UML para la descripción de la arquitectura del software (funcional, de aplicación y física) y para el desarrollo del caso del usuario. Dicho modelo describe los requisitos y las demandas del usuario.

Ing. de Software

RUP. Proceso Unificado Racional

• Es un método de desarrollo iterativo promovido por la compañía Rational Software, que fue comprada por IBM.

• El método RUP especifica, principalmente, la constitución del equipo y las escalas de tiempo, así como un número de modelos de documento.

Ing. de Software

Método XP• El método XP (Programación extrema) define un conjunto de

prácticas óptimas para el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo una cercana relación con dicho cliente.

• La Programación extrema se basa en los siguientes conceptos: • Los equipos de desarrollo trabajan directamente con el

cliente durante ciclos cortos de una o dos semanas como máximo.

• La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos para maximizar la interacción con el usuario.

• Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja en el código.

• El código se prueba y depura a lo largo del proceso de desarrollo.

• Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de desarrollo.

Ing. de Software

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

Ing. de Software

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…

Ing. de Software

Preguntas

• 1. How does the description of a system relate to the notion of process models? For example, how do you decide what the boundary should be for the system described by a process model?

• 2. For each of the process models described in this lesson, what • are the benefits and drawbacks of using the model? • 3. For each of the process models described in this lesson, how

does the model handle a significant change in requirements late in development?

• 4. Should a development organization adopt a single process model for all of its software development? Discuss the pros and cons.

• 5. Consider the processes introduced in this lesson. Which ones give you the most flexibility to change in reaction to changing requirements?

Ing. de Software

Modelo 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

Ing. de Software

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)

Ing. de Software

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

Ing. de Software

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

Ing. de Software

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

Ing. de Software

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

Ing. de Software

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

Ing. de Software

ch2-1 el proceso de desarrollar software (organización y disciplina en las actividades) contribuyen...

Documents