Tema 1 Procesos de software

(1)

María Isabel Alfonso Galipienso. 2004 1

Tema 1 Procesos de software

Proceso y modelos de proceso Actividades fundamentales Modelos de proceso genéricos Soporte automático de procesos

INDICE

z

Proceso y modelos de proceso

z

Actividades fundamentales

z

Modelos de proceso genéricos

z

Soporte automático de procesos

3

Proceso y modelo de proceso

z¿Qué es un proceso sw?

Es un conjunto estructurado de actividades para:

Especificar,

Diseñar,

Implementar, y

Probar sistemas sw

z¿Qué es un modelo de procesosw?

Es una representación abstracta de un proceso.

Representa una

descripción de un

proceso desde una

perspectiva particular

(2)

INDICE

z

Proceso y modelos de proceso

z

Actividades fundamentales

z

Modelos de proceso genéricos

z

Soporte automático de procesos

Actividades fundamentales

z

Especificación del software

z

Desarrollo del software

Diseño

Implementación z

Pruebas del software

Verificación y depuración

Validación

z

Evolución del software

6

Especificación del software (I)

z

Es el proceso de establecer qué servicios se requieren y cuáles son las restricciones sobre las operaciones y el desarrollo

z

Proceso de ingeniería de requerimientos

Estudio de factibilidad

Elicitación y análisis de requerimientos

Especificación de requerimientos

Validación de requerimientos

(3)

Especificación del software (II)

INGENIERÍA DE REQUERIMIENTOS

Feasibility study

Requirements elicitation and analysis

Requirements specification

Requirements validation Feasibility

report

System models

User and system requirements

Requirements document Estudio

factibilidad

Elicitación y Analisis requerim.

Estudio factibilidad

Especific.

requerim.

Validación requerim.

Infome factibilidad

Modelos del sistema

Req. usuario y del sistema

Documento de requerim.

Desarrollo del software

z

Es el proceso de convertir la especificación del software en un sistema ejecutable

z

Diseño del software

Se determina la estructura (arquitectura) del software que implementará la especificación.

z

Implementación

Trasladar la estructura anterior a un programa ejecutable z

Las actividades de diseño e implementación

están estrechamente relacionadas, y pueden entrelazarse

9

El proceso de diseño

Architectural design

Abstract specification

Interface design

Component design

Data structure

design

Algorithm design

System architecture

Software

specification Interface specification

Component specification

Data structure specification

Algorithm specification Requirements

specification

Design activities

Design products Especif.

requerim.

Diseño

arquit. Espec.

abstrac. Diseño

interfaz Diseño compon.

Diseño estruc.

datos

Diseño algorit.

Arquit.

sistema

Especif.

software Especif.

interfaz

Especif.

compon.

Espec.

estruc.

datos

Especif.

algorit.

Actividades de diseño

Productos de diseño

(4)

Programación y depuración

zProgramación: Convertir el diseño en un

programa

La programación es una actividad personal: no hay un proceso genérico de programación

zDepuración: descubrir y eliminar los errores del

programa

Locate error

Design error repair

Repair error

Re-test program Localizar

el error

Diseñar la repar. error

Reparar error

Probar programa

Pruebas

z

Las pruebas y validación pretenden mostrar que un sistema cumple con su especificación y satisface los requerimientos del cliente

z

Implica procesos de comprobación en varios niveles:

Unidades: pruebas de componentes

Subsistemas: pruebas de integración

Sistema: pruebas de usuario (validación) z

Pueden ser estáticas y dinámicas

12

El proceso de prueba

Sub-system testing Module

testing Unit

testing

System testing

Acceptance testing

Component testing

Integration testing User

testing Pruebas

unidad

Pruebas módulo

Pruebas subsistema

Pruebas sistema

Pruebas aceptac.

Pruebas de usuario Pruebas de

integración Pruebas de

componentes

(5)

Fases del proceso de prueba

Requirements specification

System specification

System design

Detailed design

Module and unit code

and tess Sub-system

integration test plan System

integration test plan Acceptance

test plan

Service Acceptance

test

System integration test

Sub-system integration test Especif.

requerim. Especif.

sistema Diseño

sistema

Diseño detallado

Pruebas unidad y módulo

Pr. integr.

subsist.

Pr. integr.

sistema Pruebas

aceptac.

Servicio Plan prueb.

aceptac.

Plan integrac.

sistema

Plan integrac.

subsist.

verificación validación

Evolución del software (I)

z El software es inherentemente flexible y puede cambiar

z Así como cambian los requerimientos según las circustancias del sistema, el software que soporta dicho sistema puede también evolucionar y cambiar

z Si bien hay una diferencia clara entre desarrollo y evolución (mantenimiento), dicha diferencia se convierte en irrelevante desde el momento en que cada vez menos sistemas son completamente nuevos

15

Evolución del software (II)

Assess existing systems Define system

requirements

Propose system changes

Modify systems

New system Existing

systems Definir requer.

sistema Evaluar sist.

actual

Proponer cambios sist.

Modificar sistema

Nuevo sistema Sistemas

existentes

(6)

INDICE

z

Proceso y modelos de proceso

z

Actividades fundamentales

z

Modelos de proceso genéricos

z

Soporte automático de procesos

Modelos de proceso genéricos

z

Modelo en cascada

Separay distingue las distintas fases de especificación y desarrollo z

Desarrollo evolutivo

Intercalalas fases de especificación y desarrollo z

Desarrollo formal de sistemas

Construye un modelomatemáticodel sistema que se transforma formalmente en una implementación

z

Desarrollo basado en reutilización

El sistema se construye ensamblandocomponentesya existentes z

Desarrollo iterativo

Repite las fases en lo que se denominanciclos z

Desarrollo ágil

Adaptativoy orientado a la gente

18

Modelo en cascada

Requirements definition

System and software design

Implementation and unit testing

Integration and system testing

Operation and maintenance Definición de

requerimientos Diseño

Implementación y pr. de unid.

Integración y pr.

del sistema

Puesta en marcha y mantenimiento

(7)

Desarrollo evolutivo (I)

z

Desarrollo explorativo

El objetivo es trabajar con el cliente y hacer evolucionar un sistema final a partir de un esbozo de una especificación inicial.

El desarrollo comienza con aquellaspartes mejor comprendidas del sistema

z

Prototipado

El objetivo es comprender los requerimientos del sistema.

El prototipo se centra en aquellas partes que el cliente tiene "poco claras"

Desarrollo evolutivo (II)

Validation Final

version

Development Intermediate

versions

Specification Initial

version

Outline description

Concurrent activities Actividades concurrentes Especificación

Desarrollo

Validación Esbozo de

descripción

Versión inicial

Versiones intermedias

Versión final

21

Desarrollo formal de sistemas (I)

z Basados en la transformación de unaespecificación matemáticaa través de diferentes representaciones hasta obtener un programa ejecutable

z Las transformaciones preservan la correcciónde las especificaciones. Esto es importante para mostrar que el programa cumple con sus especificaciones

z El desarrollo formal se utiliza en la aproximación de "Sala limpia"(‘Cleanroom’) de desarrollo de sw.

(8)

Desarrollo formal de sistemas (II)

Requirements

definition Formal

specification

Formal transformation

Integration and system testing

Formal R2

specification R3 Executable

program

P2 P3 P4

T1 T2 T3 T4

R1

P1 Def.

requerim.

Especific.

formal

Transform.

formal

Integrac. y prueb. sist.

Especificac.

formal

Programa ejecutable

TRANSFORMACIONES FORMALES

Modelos que usan reutilización

z Basados en la reutilización sistemática. Los sistemas se integran a partir de componentes existentes: COTS(Commercial-off-the-shelf) systems

z

Etapas del proceso

Análisis de componentes

Modificación de requerimientos

Diseño del sistema con reutilización

Desarrollo e integración

24

Desarrollo iterativo

z La palabra "iterativo" significa que implicarepetición

z El resultado de cada iteración (o ciclo) es un ejecutable.

En cada iteración se revisa el trabajo realizado y se realizan cambios para mejorar la iteración anterior

z Los requerimientos del sistema SIEMPRE evolucionan durante un proyecto. La iteración del proceso, en donde se modifican etapas previas son siempre necesarias en sistemas grandes

z Aproximaciones:

Desarrollo incremental

Desarrollo en espiral

(9)

Desarrollo incremental (I)

z En lugar de entregar el sistema de una sola vez, el desarrollo y se divide en incrementos que son entregados al cliente. Cada incremento contiene parte de las funcionalidades requeridas

z Los requerimientos del usuario se priorizan, de forma que los de mayor prioridad se entregan antes

z Una vez que el desarrollo comienza, los requerimientos se "congelan", aunque los requerimientos de posteriores incrementos continuan evolucionando

DESAROLLO ITERATIVO:

Desarrollo incremental (II)

Validate increment Develop system

increment

Design system architecture

Integrate increment

Validate system Define outline

requirements

Assign requirements to increments

System incomplete

Final system Esbozo def.

de requer.

Asig. requer. a

incrementos Diseño arq.

sistema

Desarr.

incremento

Validación incremento

Integrac.

incremento Validación sistema

Sistema incompleto

Sistema final DESAROLLO ITERATIVO:

27

El modelo incremental

Análisis Diseño Código Pruebas

Análisis Análisis

Diseño Código Pruebas Diseño Código Pruebas Ingeniería de

Sistemas/Información

Tiempo de calendario Incremento 1

Incremento 2 Incremento 3 DESAROLLO ITERATIVO:

(10)

Desarrollo en espiral (I)

z

El proceso es representado como una espiral. Cada uno de los bucles representa una fase en el proceso

z

No hay fases fijas (tales como especificación o diseño). Los bucles de la espiral se eligen dependiendo de lo que se vaya necesitando

z

Los riesgos se evalúan explícitamente y se resuelven a lo largo del proceso

Desarrollo en espiral (II)

Risk analysis Risk analysis Risk analysis

Risk analysis Proto-

type 1 Prototype 2

Prototype 3 Opera- tional protoype

Concept of Operation

Simulations, models, benchmarks S/W

requirements Requirement

validation Design V&V

Product design Detailed

design Code Unit test Integration Acceptance test

Service test Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine objectives

alternatives and constraints

Plan next phase

Integration and test plan Development plan Requirements plan

Life-cycle plan REVIEW

Evaluar alternativas.

Identif. y resolver riesgos

Planificar fase siguente

Desarrollar y verificar siguiente nivel

Determinación de objetivos, alternativas y restricciones

30

UP: Unified Process

z UP constituye un marco para el desarrollo de procesos:

puede acomodarse a una amplia variedad de procesos

z RUP (Rational Unified Process) es un refinamiento detallado del proceso unificado (UP)

z El desarrollo se organiza en una serie de mini-proyectos denominados iteraciones

z Es incremental: el sistema crece incrementalmente a lo largo del tiempo

z Es iterativo: se basa en la ampliación y refinamientos sucesivos del sistema (se pueden modificar los incrementos)

EJEMPLO DE MODELO ITERATIVO E INCREMENTAL:

(11)

Conceptos clave de UP

DESAROLLO UNIFICADO: Conceptos clave z

Fases, Iteraciones

z

Disciplinas

Actividades

z

Artefactos

modelos

Informes, documentos z

Roles

¿¿QuéQuéhay hay queque hacer hacer??

¿¿QuéQuése se produce?

produce?

¿

¿QuiénQuiénlo lo hacehace??

¿Cuándo¿Cuándotienentienenlugar?lugar?

Fases e Iteraciones

z Una iteraciónpuede considerarse como un mini- proyecto software. El final de cada iteración es una versión "limitada" del producto final

z Un conjunto de iteraciones forman una fase. Al final de cada fase siempre se asocia un HITO. Hay cuatro fases:

Inicio

Elaboración

Construcción

Transición

z Las cuatro fases anteriores forman un ciclo de desarrollo que termina con el lanzamiento de un sistema a producción

33

Disciplinas

z Formas de describir significativamente la secuencias de actividades que producen unos resultados. Hay 9 tipos de disciplinas

:

Modelado del negocio

Requisitos

Diseño

Implementación

Prueba

Despliegue

Gestión de configuraciones y cambios

Gestión del proyecto

Entorno

(12)

Actividades

z Unidades de trabajo que puede ejecutar un individuo en un rol específico

z Tiene un propósito claro y se expresa en términos de actualizar artefactos

z La granularidad de la actividad es generalmente de horas o pocos días

z Ejemplos de actividades

Planear una iteración (administrador del proyecto)

Encontrar caso de uso y actores (analista del dominio)

Revisión del diseño (probador)

Artefactos

z Piezas de información producida, modificada y utilizada en un proceso

z Productos tangibles del proyecto

z Utilizados por los roles como entrada para la realización de sus actividades

z Resultado de las actividades realizadas por los roles

z Ejemplos: diagrama de casos de uso, diagrama de secuencia, diagrama de clases...

36

Roles

z Definición del comportamiento y responsabilidades de los participantes

z Propietario de una serie de artefactos

Recurso Rol Actividad Artefacto Diseñador Diseño de Objetos DC Analista Definición de CU DCU Dominio

Diseñador Diseño de CU DS Funcional

Patricia Juan Mónica Pedro

(13)

El proceso UP (I)

Inicio Elaboración Construcción Transición ciclo

fase

Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6

hito 1 hito 2 hito 3 hito 4

Hito: punto en el tiempo en donde se evalúan objetivos logrados y se pueden tomar decisiones críticas

El proceso UP (II)

Gestión proyecto Entorno Modelado del sist.

Implementación Pruebas Análisis y Diseño Disciplinas del proceso

Iteraciones Flujos de soporte

Despliegue Gestión Configurac.

Requerimientos

Iteraciones Prelim (s) Iter.

#1 Fases

Iter.

#2 Iter.

#n Iter.

#n+1 Iter.

#n+2 Iter.

#m Iter.

#m+1

Elaboración Transición

Inicio Construcción

39

UP: Fase Inicio

z Objetivo: definir la razón de ser y el alcance del proyecto. Estudio de oportunidad.

Visión = QUÉ + PARA QUÉ + CUÁNTO z Actividades

Especificación de los criterios de éxito del proyecto

Definición de los requerimientos

Estimación de los recursos necesarios

Cronograma inicial de fases z Artefactos

Documento de definición del proyecto

(14)

UP: Fase Elaboración

z Objetivo: establecer un plan de proyecto y una arquitectura correcta del sistema

z Actividades

Análisis del dominio del problema

Definición de la arquitectura básica

Análisis de riesgos

Planificación del proyecto z Artefactos

Modelo del dominio

Modelo de procesos

Modelo funcional de alto nivel

Arquitectura básica

UP: Fase Construcción

z

Objetivo: implementación iterativa del resto de requisitos de menor riesgo y elementos más fáciles

z

Actividades

Análisis

Diseño

Codificación

Pruebas (individuales, de integración)

42

UP: Fase Transición

z

Objetivo: preparación del sistema para su puesta en producción

z

Actividades

Pruebas beta

Despliegue

(15)

Desarrollo ágil (I)

z

Es un conjunto de prácticas que guían el proceso de desarrollo

z

Utiliza iteraciones para controlar la no predecibilidad de los requerimientos

z

Requiere un grupo muy efectivo de desarrolladores, tanto en la calidad de sus individuos como en el trabajo conjunto del grupo

z

Implica revisiones regulares del proceso (típicamente al final de cada iteración)

Desarrollo ágil (II)

z

Características principales:

Captura rápidamente los requerimientos de alto nivel

Se desarrolla un plan para cada iteración

Modifica roles: cliente activo, desarrollador de propósito general

Progreso visible mediante revisiones de calidad del producto frecuentes

Construcciones y pruebas diarias

Realización de diseños simples

45

Programación extrema (XP)

z Extreme programming: es una nueva aproximación basada en el desarrollo y entrega de pequeños incrementos de funcionalidades

z Es un proceso incremental (se entregan nuevas funcionalidades en cada incremento), pero también iterativo (se modifica el trabajo ya realizado utilizando refactoring)

z Se realiza una constante mejora de código, una implicación del usuario en el grupo de trabajo y programación por parejas (pairwise programming) MODELOS ÁGILES:

(16)

Prácticas XP

Test-driven development

Refactoring Simple Design Pair Programming

Planning Game

Small Releases

System Metaphor Continuous

Integration Collective Ownership

Coding Standards On-site

Custome r

40-hour work per week MODELOS ÁGILES:

Importancia del proceso

z Se debe seleccionar el modelo de proceso apropiado para el tipo de proyecto software a desarrollar

z Una mala elección del proceso puede llevar al fracaso del proyecto

48

INDICE

z

Proceso y modelos de proceso

z

Actividades fundamentales

z

Modelos de proceso genéricos

z

Soporte automático de procesos

(17)

Soporte automático del proceso

z La ingeniería del software ayudada por computador (CASE) se refiere al software que soporta el proceso de desarrollo y evolución del software

z

Automatización de actividades

Editores gráficos para modelados de sistemas

Diccionario de datos para gestionar las entidades de diseño

Herramientas visuales para la construcción de la interfaz

Depuradores para soportar la búsqueda de errores

Generadores de código para generar nuevas versiones de los programas

Tecnología CASE

z La tecnología Case ha conseguido mejoras significativas en el proceso de desarrollo de software, aunque no en el orden de magnitud en que fue predicho

La ingeniería del software requierecreatividad, lo cual no es fácilmente automatizable

La ingeniería del software es unaactividad de grupo y en grandes proyectos se consume mucho tiempo en interacciones entre el grupo. La tecnología CASE no soporta realmente este hecho

51

Clasificación CASE

z Nos ayuda a entender los diferentes tipos de herramientas CASE y el soporte que proporcionan a las actividades del proceso de desarrollo de sw

z Perspectiva funcional

Clasificación según su función específica

z Perspectiva del proceso

Clasificación según las actividades del proceso que soportan

z Perspectiva de integración

Clasificación de acuerdo a su organización en unidades integradas

(18)

Clasificación funcional

Tool type Examples

Planning tools PERT tools, estimation tools, spreadsheets

Editing tools Text editors, diagram editors, word processors

Change management tools Requirements traceability tools, change control systems

Configuration management tools Version management systems, system building tools

Prototyping tools Very high-level languages, user interface generators Method-support tools Design editors, data dictionaries, code

generators Language-processing tools Compilers, interpreters Program analysis tools Cross reference generators, static

analysers, dynamic analysers Testing tools Test data generators, file comparators Debugging tools Interactive debugging systems Documentation tools Page layout programs, image editors Re-engineering tools Cross-reference systems, program re-

structuring systems

Clasif. según actividades

Reengineering tools Testing tools Debugging tools Program analysis tools Language-processing tools Method support tools Prototyping tools Configuration management tools Change management tools Documentation tools Editing tools Planning tools

Specification Design Implementation Verification and Validation

54

Clasif. según integración (I)

z Herramientas

Soportan tareas individuales del proceso, tales como comprobación de consistencia del diseño, edición de textos, etc.

z Bancos de trabajo (Workbenches)

Soportan una fase del proceso, como especificación o diseño.

Normalmente incluyen varias herramientas integradas

z Entornos

Soportan todo o una parte sustancial del proceso software.

Normalmente incluyen varios bancos de trabajo

(19)

Clasif. según integración (II)

Single-method workbenches

General-purpose workbenches Multi-method

workbenches

Language-specific workbenches Programming Testing Analysis and

design

Integrated environments

Process-centred environments File

comparators Compilers Editors

Environments Workbenches

Tools

CASE technology

Puntos clave

z Los procesos sw son actividades relacionadas con la producción y evolución de un sistema software. Dichos procesos se representan en un modelo de procesos sw

z Las actividades generales son especificación, diseño e implementación, pruebas y evolución

z Los modelos de procesos sw describen la organización de los procesos sw

z Las herramientas CASE asisten automáticamente al proceso de desarrollo del software