Procesos de Desarrollo de

Software
Ingeniería de Sw según PRESSMAN

 Es una tecnología multicapa que

contempla:
 Herramientas
 Métodos
 Proceso (FUNDAMENTAL)
 Basado en un enfoque de calidad
 Proceso: Marco de trabajo aplicable a un
conjunto de áreas clave del proceso para
entregar software de calidad. Las ACP
establecen el contexto donde se aplican los
métodos, se pruducen documentos, se
asegura calidad y se gestiona el cambio.
 Métodos: Indican “COMO” construir
técnicamente el software, incluyen
actividades de modelado y otras técnicas
descriptivas.
 Herramientas: Proporcionan un enfoque
automático para el proceso y para los
métodos.
¿Qué es un proceso de desarrollo?

Deseos, Software
necesidades,
Especificaciones,
…
Proceso de desarrollo de SW

 Propósito del proceso de desarrollo de

Software
 La producción eficaz y eficiente de un
producto software que reúna los requisitos del
cliente.
 Este proceso es intensamente intelectual,
afectado por la creatividad y juicio de las
personas involucradas.

Requisitos nuevos Sistema nuevo

o modificados o modificado
Proceso de Desarrollo
de Software
Características del desarrollo de SW

 El SW en sí es complejo, es prácticamente
inviable conseguir un 100% de
confiabilidad de un programa por pequeño
que sea.
 El SW es intangible y por lo general muy
abstracto, esto dificulta la definición del
producto y sus requisitos, sobre todo
cuando no se tiene precedentes en
productos software similares.
 Los cambios en los requisitos son inevitables…
Características del desarrollo de SW

 El proceso de desarrollo de software no es

único, lo que hace muy difícil su
automatización.
 La IS es todavía una actividad inmadura.
Actividades Fundamentales

 Existe un conjunto de actividades fundamentales

que se encuentran presentes en todos proceso de
desarrollo:
 Especificación de software: Se define la
funcionalidad y restricciones operacionales que debe
cumplir el software.
 Diseño e Implementación: Se diseña y construye el
software de acuerdo a la especificación.
 Validación: El software debe validarse, para asegurar
que cumpla con lo que quiere el cliente.
 Evolución: El software debe evolucionar, para
adaptarse a las necesidades del cliente.
Actividades Protectoras

 Seguimiento y control de proyectos.

 Revisiones técnicas formales.
 Garantía de calidad del software.
 Gestión de configuración del software.
 Preparación y producción de documentos.
 Mediciones.
 Gestión de riesgos
El Proceso según Pressman
 Un marco común del proceso, son las
actividades del marco de trabajo que son
aplicables a todos los proyectos de software,
con independencia del tamaño o
complejidad.
 Un conjunto de tareas, cada actividad es
una colección de tareas de IS, hitos de
proyectos, entregas y productos de trabajo
del software que permiten que las
actividades del marco de trabajo se adapten
a las características del proyecto de software
y los requisitos del equipo del proyecto.
 Actividades de protección, tales como
garantía de calidad del software, gestión de
configuración del software y medición,
abarcan el modelo del proceso. Son
independientes de cualquier actividad del
marco de trabajo y aparecen durante todo el
proceso.
El Proceso de Software
 Marco de Trabajo Común  Se define un Framework
del proceso. del proceso con un
 Actividades del Marco de conjunto de actividades
Trabajo. aplicables a todos los
 Conuntos de Tareas. proyectos de SW.
 Tareas.  El conjunto de tareas
 Hitos, Entregas. permiten que las
 Puntos de actividades se adapten a
aseguramiento de las caracterísiticas del
la calidad SQA. proyecto y los requisitos
 Actividades de del equipo.
protección.  Las actividades de
 Garantía de calidad,
gestión de
protección aparecen
configuración y durante todo el proceso.
medición.
Elementos del proceso de desarrollo

 Quién debe hacer Qué, Cuándo y Cómo

debe hacerlo.
Actividades

Personas Herramientas

Proceso
SW

Roles Artefactos Notación

Elementos del proceso de desarrollo
 Quién: Las Personas participantes que
desempeñan uno o más Roles específicos.
 Qué: Un Artefacto es producido por un Rol en una
de sus Actividades. Estos se especifican utilizando
Notaciones específicas. Las Herramientas apoyan
la elaboración de los Artefactos.
 Cómo y Cuándo: Las Actividades son una serie
de pasos que lleva a cabo un Rol durante el
proceso de desarrollo. El avance del proyecto está
controlado mediante hitos que establecen un
determinado estado de terminación de ciertos
Artefactos.
Artefacto

 Un artefacto es una pieza de información

que:
 (1) es producida, modificada o usada por el
proceso,
 (2) define un área de responsabilidad para un
rol y
 (3) está sujeta a control de versiones.
 Un artefacto puede ser un modelo, un
elemento de modelo o un documento.
Principios y Prácticas

 Forman la base para componer y

sincronizar las actividades del proceso.
 Las Prácticas y Principios enfatizan ciertas
actividades y/o la forma como deben
realizarse, por ejemplo:
 desarrollar iterativamente, gestionar
requisitos, desarrollo basado en componentes,
modelar visualmente, verificar continuamente
la calidad, gestionar los cambios, etc.
Modelo de Proceso de Software

 “Representación simplificada de un proceso

de software, representada desde una
perspectiva específica. Por su naturaleza
los modelos son simplificados, por lo tanto
un modelo de procesos del software es una
abstracción de un proceso real.” [Ian
Sommerville]
Algunos modelos de proceso

 El modelo es una representación

simplificada de un proceso de software que
conlleva una estrategia global para abordar
el desarrollo de software
 Codificar y corregir
 Modelo en cascada
 Desarrollo evolutivo
 Desarrollo basado en reutilización
 Desarrollo incremental
 Desarrollo en espiral
Codificar y corregir

 Este es el modelo básico

utilizado en los inicios del
desarrollo de software.
Contiene dos pasos:
 Escribir código.
 Corregir problemas en el
código.
 Primero implementar algo
de código y luego pensar
acerca de requisitos,
diseño, validación, y
mantenimiento
Desarrollo en cascada
 La Versión Ideal
(Perfecta)
 El Modelo en V
 El Helado de
Cucurucho
 El Modelo Real
 Propuesta de
Yourdon
Modelo en V

Identificación
de Necesidades Explotación

Especificación
Esencial Validación

Especificación
Física Empaquetado

Diseño Integración

Codificación
Helado de Cucurucho

USUARIOS
Identificación
de Necesidades Explotación

Especificación CLIENTES
Esencial Validación

Especificación ANALISTA
Física Empaquetado

Diseño Integración

DISEÑADORES Y Codificación
CODIFICADORES
Modelo Real

de Necesidades Explotación

Especificación
Esencial Validación

Especificación
Física Empaquetado

Diseño Integración

Codificación
Propuesta de Yourdon
Requerimientos del Usuario
Sistema
Probado
Encuesta
Prueba de
Sistema
Subsistemas
Análisis Probados
Especificación
Funcional
Prueba de
Necesidades de subsistema
diseño Rendimiento Estudio
Preliminar del HW
Módulos
Configuración Probados
Especificación
del Sistema Diseño Final Prueba de
Detallado Unidad

Especificación Módulos
de los Codificados
Codificación
Programas
 Construcción de Prototipos

Aceptado
Obtención Construcción Ciclo de
Evaluación
Especificación Prototipo Vida
Cliente
Clásico
Mejora de la
Especificación NO Aceptado
Clases de prototipos

 De INTERFACE.
 Usualmente un modelo de papel o sobre PC en
el que se muestran pantallas y listados.
 De COMPORTAMIENTO:
 En anchura. Ofrece todos los menús del
sistema y simula débilmente los procesos.
 En profundidad. Cubre funciones que
presentan ambigüedades al cliente o a los
informáticos.
 Completo pero de baja calidad y rendimiento.
Incremental

Requeri Diseño Impleme Pruebas

Bloque 1 mientos ntación

Requeri Diseño Impleme Pruebas

Bloque N mientos ntación

o
Requerimientos Permite el
Diseño Impleme Pruebas
desarrollo
Bloque 1 ntación concurrente

Diseño Impleme Pruebas

Bloque N ntación
Incremental
Modelo de Madurez de Capacidades

 CMM por sus siglas en inglés.

 Desarrollado por el Instituto de Ingeniería de
Software (SEI).
 Basado en un conjunto de funciones de ISw
que deberían estar presentes conforme se
alcanzan diferentes grados de madurez del
proceso del SW.
 Proporciona una medida de la efectividad
global de las prácticas de ISw de una
compañía.
 Establece 5 niveles de madurez del proceso
 Nivel 1 – Inicial. Proceso caótico, existen
pocos procesos y el éxito depende del
esfuerzo individual.
 Situación sin ningún esfuerzo en la garantía de
calidad y gestión del proyecto.
 Cada equipo del proyecto desarrolla el
software a a su manera.
 Nivel 2 – Repetible. Se establecen
procesos de gestión de proyectos para
hacer seguimiento del costo, planificación
y funcionalidad. Para repetir exitos
anteriores con proyectos similares se
aplica la disciplina necesaria para el
proceso.
 Se han definido algunas actividades tales
como:
Informe de esfuerzo y tiempo empleado.
Informe de tareas realizadas.
 Nivel 3 – Definido. El proceso de las
actividades de gestión y de ingeniería se
documenta, se estandariza y se integra
dentro de un todo. Todos lo proyectos
utilizan una versión documentada y
aprobada del proceso.
 Se han definido tanto procesos técnicos como
de gestión.
 Ejemplo: se definen estándares de
programación y se hacen cumplir mediante
auditorías.
 Pocos empresas han superado este nivel.
 Nivel 4 – Gestionado. Se recopilan medidas
detalladas del proceso del software y de la
calidad del producto.
 Comprende el concepto de medición y
métrica.
 Una métrica es una cantidad insignificante que
se puede extraer de algún documento o
código.
 Ejemplo: # de condicionales en una sección de
código, la cual proporciona alguna indicación
acerca del esfuerzo necesario para probar el
código.
 Nivel 5 – Optimización. Se utiliza la
retroalimentación para mejorar el proceso.
 Representa la analogía del software con otros
procesos de control de calidad que existen en
otras industrias.
 Se pueden predecir resultados tales como el #
de errores latentes en función de las
mediciones tomadas durante la ejecución de
un proyecto.