Disciplina de Construcción

del Software
Clase # 1
Ing. Christian Vega
 Administración de la
construcción del Software
Clase # 1
Ing. Christian Vega
 Propósito de la Clase

• Planifica la construcción del software siguiendo un modelo de ciclo de

vida del software y los estándares de construcción.
Recordando nuestra anterior clase
 Recordando nuestra anterior clase

• Estándares en la construcción
• Los estándares que afectan directamente a elementos de la construcción
incluyen:
• Metodos de comunicación Estándares
• Programación de lenguajes
• Plataformas Estándares Estándares
• Herramientas Externos Internos

Los estándares tambien

• Grupo de Gestion pueden crearse partiendo
de Objetos de una base organizacional
• ISO a un nivel corporativo o
• IEEE para su uso en proyectos
internos.
 Recordando nuestra anterior clase

• El estándar contiene un conjunto de procesos, actividades y tareas

diseñadas para ser utilizadas en los proyectos de desarrollo software,
alineadas en todos los casos con la metodología normalizada.
• Se ha tomado como referencia el estándar para los procesos de ciclo de
vida del software de la organización ISO, “ISO/IEC 12207 Information
Technology / Software Life Cycle Processes”.
• Este estándar tiene como objetivo principal proporcionar una estructura
común para que compradores, proveedores, desarrolladores, personal
de mantenimiento, operadores, gestores y técnicos involucrados en el
desarrollo de software usen un lenguaje común.
Recordando nuestra anterior clase
 Motivación

• “He visitado decenas de tiendas comerciales, tanto buenas como

malas, y he observado tableros de datos que procesan los
administradores, de nuevo, buenos y malos. Con mucha frecuencia,
observé con horror cómo estos administradores luchan
infructuosamente a través de proyectos de pesadilla, se retuercen
bajo fechas límite imposibles o sistemas entregados que contrarían a
sus usuarios y que se dedican a devorar enormes trozos de tiempo de
mantenimiento”

(Meiler Page-Jones)
 Índice

• Administración de la construcción del Software

• Modelos del ciclo de vida del software
• ¿Qué modelo utilizar?
• Planificación de la contrucción
• Métricas de contrucción
 Administración de la construccion del
Software

• La “administración”, sigue siendo una actividad necesaria cuando se

construyen sistemas y productos.
• La administración del proyecto involucra planificación, monitoreo y
control del personal, procesos y acciones que ocurren conforme el
software evoluciona desde un concepto preliminar hasta su
despliegue operativo completo.
 Administración de la construccion del
Software

• La administración de un proyecto de software se enfoca en las cuatro P:

personal, producto, proceso y proyecto.
• Personal:
• Desde la década de 1960 se estudia la formación de personal de software
motivado y enormemente calificado. De hecho, el “factor humano” es tan
importante que el Software Engineering Institute desarrolló un Modelo de
madurez de capacidades del personal.
• El People-CMM define las siguientes áreas prácticas clave para el personal de
software: plantilla, comunicación y coordinación, ambiente de trabajo,
desempeño administrativo, capacitación, compensación, análisis y desarrollo de
competencias, desarrollo profesional, desarrollo de grupo de trabajo y
desarrollo de equipo/cultura, entre otros.
 Administración de la construccion del
Software

• Producto:
• Como desarrolladores de software, todos los participantes deben reunirse
para definir los objetivos y el ámbito del producto.
• Los objetivos identifican las metas globales para el producto (desde el punto
de vista de los participantes) sin considerar cómo se lograrán estas metas. El
ámbito identifica los datos, funciones y comportamientos principales que
caracterizan al producto y, más importante, intenta ligar dichas características
en forma cuantitativa.
• Una vez comprendidos los objetivos y el ámbito del producto, se consideran
soluciones alternativas.
 Administración de la construccion del
Software

• Proceso:
• Un proceso de software proporciona el marco conceptual desde el cual puede
establecerse un plan completo para el desarrollo de software.
• Un pequeño número de actividades de marco conceptual se aplica a todos los
proyectos de software, sin importar su tamaño o complejidad.
• Las actividades sombrilla son independientes de cualquier actividad del
marco conceptual y ocurren a lo largo del proceso.
 Administración de la construccion del
Software

• Proyecto:
• Los proyectos de software se planean y controlan debido a una razón
principal: es la única forma conocida para manejar la complejidad. E incluso
así, los equipos de software todavía batallan.
• En un estudio de 250 grandes proyectos de software desarrollados entre 1998
y 2004.
• Para evitar el fracaso del proyecto, un gerente de proyecto de software y los
ingenieros de software que construyan el producto deben evitar un conjunto
de señales de advertencia comunes, entender los factores de éxito cruciales
que conducen a una buena administración del proyecto y desarrollar un
enfoque de sentido común para planificar, monitorear y controlar el proyecto.
 Modelos del ciclo de vida del software

• Un modelo de proceso, es una plantilla, patrón o marco que define el

proceso a través del cual se crea software.
• Una organización podría variar su modelo de proceso para cada
proyecto, según:
• La naturaleza del proyecto
• La naturaleza de la aplicación
• Los métodos y herramientas a utilizar
• Los controles y entregas requeridas
 Modelos del ciclo de vida del software

• Modelos Genéricos de Desarrollo de Software:

• Modelo de Cascada
• Prototipado
• Desarrollo Evolutivo
• En espiral
• Desarrollo basado en componentes
• Métodos Formales
 Modelos del ciclo de vida del software
Modelo de Cascada (waterfall)

• Modelo de proceso clásico (desde los 70)

• Basado en la mentalidad de línea de ensamblaje (cartesiano)
• Es sencillo y fácil de entender
• El proyecto pasa a través de una serie de fases
• Al final de cada fase se revisan las tareas de trabajo y productos trabajo y
productos
• Para poder pasar a la siguiente fase se tiene que haber conseguido todos los objetivos de
la fase anterior
• No hay apenas comunicación entre las fases
Modelos del ciclo de vida del software
Modelo de Cascada (waterfall)
 Modelos del ciclo de vida del software
Modelo de Cascada (waterfall)

• Fases:
• Conceptualización: Se determina la arquitectura de la solución (división del
sistema en subsistemas)
• Análisis de requisitos: Básicamente se definen los requisitos funcionales y de
rendimiento
• Diseño: Representación de la aplicación que sirve de guía a la implementacón
• Implementación: Transforma el diseño en código
• Prueba: Validación e integración de software y sistemas
• Instalación y comprobación: Se instala el software al cliente, el cual
comprueba la corrección de la aplicación
 Modelos del ciclo de vida del software
Modelo de Cascada (waterfall)

• Ventajas:
• Sencillo: Sirve cuando el personal está poco cualificado
• Aplicable cuando el problema es estable y cuando se trabaja con técnicas
conocidas
• Críticas:
• No se ve un producto hasta muy tarde en el proceso
• Un error grave detectado en las últimas fases puede ser letal
• Especificación de requisitos estable
• Impone una estructura de gestión de proyectos
• Fases muy rígidas
• Las revisiones de proyectos de gran complejidad son muy difíciles
 Modelos del ciclo de vida del software
Modelo Prototipado

• Se usa un prototipo para dar al usuario una idea concreta de lo que va

a hacer el sistema
• Se aplica cada vez más cuando la rapidez de desarrollo es esencial
• Prototipado evolutivo: el prototipo inicial se refina progresivamente
hasta convertirse en versión final
• Prototipado desechable: de cada prototipo se extraen ideas buenas
que se usan para hacer el siguiente, pero cada prototipo se desecha
completamente
Modelos del ciclo de vida del software
Modelo Prototipado
 Modelos del ciclo de vida del software
Modelo Prototipado

• Ventajas:
• Permite identificar los requisitos incrementalmente
• Permite probar alternativas a los desarrolladores
• Tiene una alta visibilidad -> tanto clientes como desarrolladores ven resultados
rápidamente
• Inconvenientes:
• El cliente no entiende por qué hay que desechar el prototipo
• Si simplemente ha pedido unos ajustes...(¿?)
• Riesgo de software de baja calidad
• Compromisos de implementación para que el prototipo funcione rápidamente y que al final
son parte integral del sistema
• Utilizar un SO o lenguaje de programación inadecuado pero conocido
 Modelos del ciclo de vida del software
Modelo Desarrollo Evolutivo

• Gestionan bien la naturaleza evolutiva del software

• Son iterativos: construyen versiones de software cada vez más
completas
• Se adaptan bien:
• Los cambios de requisitos del producto
• Fechas de entrega estrictas poco realistas
• Especificaciones parciales del producto
 Modelos del ciclo de vida del software
Modelo Desarrollo Evolutivo

• Fusiona el modelo lineal secuencial con el de construcción de

prototipos
 Modelos del ciclo de vida del software
Modelo Desarrollo Evolutivo

• Ventajas:
• Es interactivo
• Con cada incremento se entrega al cliente un producto operacional, que puede evaluarlo
• Personal
• Permite variar el personal asignado a cada iteración
• Gestión riesgos técnicos
• Por ejemplo, disponibilidad de hardware específico
• Inconvenientes
• La primera iteración puede plantear los mismos problemas que en un modelo
lineal secuencial
 Modelos del ciclo de vida del software
Modelo Espiral

• Original: Boehm, 1988

• IEEE Std. 1490-1998
• Tratar primero las áreas de mayor riesgo
• Múltiples iteraciones sobre varias regiones de tareas
• Vuelta a la espiral: ciclo
• Número de iteraciones predeterminadas o calculadas dinámicamente
• Se pueden variar las actividades de desarrollo: familia de modelos de
procesos
Modelos del ciclo de vida del software
Modelo Espiral
 Modelos del ciclo de vida del software
Modelo Espiral

• Ventajas:
• Enfoque realista
• Gestión explícita de riesgos
• Centra su atención en la reutilización de componentes y eliminación de errores
en información descubierta en fases iniciales
• Los objetivos de calidad son el primer objetivo
• Integra desarrollo con mantenimiento
• Inconvenientes
• Convencer cliente enfoque controlable
• Requiere de experiencia en la identificación de riesgos
• Requiere refinamiento para uso generalizado
 Modelos del ciclo de vida del software
Modelo desarrollo basado en componentes

• Desarrollo de sistemas en poco tiempo

• Adaptación a “alta velocidad” de la cascada
• Equipos trabajando en paralelo
• Aplicando tecnología de componentes
 Modelos del ciclo de vida del software
Modelo desarrollo basado en componentes
 Modelos del ciclo de vida del software
Modelo desarrollo basado en componentes

• Ventajas
• Rapidez
• Válido para aplicaciones modularizables
• Inconvenientes
• Exige conocer bien los requisitos y delimitar el ámbito del proyecto
• Número de personas
• Clientes y desarrolladores comprometidos
• Gestión riesgos técnicos altos
• Uso de nueva tecnología
• Alto grado de interoperabilidad con sistemas existentes
 Modelos del ciclo de vida del software
Modelo métodos formales

• Se basa en la transformación de una especificación formal a lo largo

de varias representaciones hasta llegar a un programa ejecutable
• Las transformaciones preservan la corrección
• Permiten comprobar fácilmente que el programa es conforme a la
especificación
 Modelos del ciclo de vida del software
Modelo métodos formales

• Problemas
• Hace falta una formación especializada para aplicar la técnica
• Muchos aspectos de los sistemas reales son difíciles de especificar
formalmente
• Interfaz de usuario
• Requisitos no funcionales
• Aplicabilidad
• Sistemas críticos en los que la seguridad y fiabilidad debe poder asegurarse
antes de poner el sistema en operación
 Modelos del ciclo de vida del software

• ¿Qué modelo utilizar?

• Para sistemas bien conocidos se puede utilizar el Modelo de Cascada. La fase
de análisis de riesgos es relativamente fácil
• Con requisitos estables y sistemas de seguridad críticos, se recomienda
utilizar modelos formales
• Con especificaciones incompletas, el modelo de prototipado ayuda a
identificarlos y va produciendo un sistema funcional
• Pueden utilizarse modelos híbridos en distintas partes del desarrollo
 Planificación de la construcción

• La planificación requiere adoptar un compromiso inicial, aun cuando

es probable que este “compromiso” resulte erróneo. Siempre que se
hacen estimaciones se mira hacia el futuro y se acepta cierto grado de
incertidumbre habitual.

“... nuestras técnicas de estimación están pobremente desarrolladas.

Más seriamente, reflejan una suposición no expresada que es muy
falsa: que todo irá bien [...] ”
(Frederick Brooks,1995)
 Planificación de la construcción

• El objetivo de la planificación del proyecto de software es

proporcionar un marco conceptual que permita al gerente hacer
estimaciones razonables de recursos, costo y calendario.
• Las estimaciones deben intentar definir los escenarios de mejor caso
y peor caso, de modo que los resultados del proyecto puedan
acotarse.
• Por tanto, el plan debe adaptarse y actualizarse conforme avanza el
proyecto.
 Planificación de la construcción

• Acciones asociadas con la planificación del proyecto de software

• Ámbito y factibilidad del Software
• Recursos
• Estimación
• Técnicas de descomposición
• Ámbito y factibilidad del Software
• El ámbito del software describe las funciones y características que se
entregan a los usuarios finales; los datos que son entrada y salida; el
“contenido” que se presenta a los usuarios como consecuencia de usar el
software y el desempeño, las restricciones, las interfaces y la confiabilidad
que se ligan al sistema.
 Planificación de la construcción

• Ámbito y factibilidad del Software

• El ámbito se define usando una de dos técnicas:
1. Una descripción narrativa del ámbito del software se desarrolla después de la
comunicación con todos los participantes.
2. Los usuarios finales desarrollan un conjunto de casos de uso.
• Estimación
• La estimación de costo y esfuerzo del software nunca será una ciencia exacta.
Demasiadas variables (humanas, técnicas, ambientales, políticas) pueden
afectar el costo final del software y el esfuerzo aplicado para su desarrollo.
 Planificación de la construcción

• Recursos
 Planificación de la construcción

• Técnicas de descomposición
• Desarrollar una estimación de costo y esfuerzo para un proyecto de software
es muy complejo como para considerarse en una sola pieza. Por esta razón,
debe descomponerse el problema y volver a caracterizarlo como un conjunto
de problemas más pequeños (y, esperanzadoramente, más manejables).
• Dimensionamiento del software
• Estimación basada en problema
 Métricas de la construcción

• Las métricas de proceso y proyecto de software son medidas

cuantitativas que permiten obtener comprensión acerca de la eficacia
del proceso del software y de los proyectos que se realizan, usando el
proceso como marco conceptual.
• Se recopilan datos básicos de calidad y productividad.
• Luego, se analizan, se comparan con promedios anteriores y se
valoran para determinar si han ocurrido mejoras en calidad y
productividad.
 Métricas de la construcción

• Las métricas de proceso se recopilan a través de todos los proyectos y

durante largos espacios de tiempo. Su intención es proporcionar un
conjunto de indicadores de proceso que conduzca a mejorar el proceso de
software a largo plazo.
• Las métricas de proyecto permiten al gerente de un proyecto de software:
1. Valorar el estado de un proyecto en marcha
2. Rastrear riesgos potenciales
3. Descubrir áreas problema antes de que se vuelvan “críticas”
4. Ajustar el flujo de trabajo o las tareas
5. Evaluar la habilidad del equipo del proyecto para controlar la calidad de los
productos operativos del software.
Métricas de la construcción
Métricas de la construcción