Metodología de desarrollo

Ingeniería del Software.
Tema 2. El proceso de desarrollo.
Modelos

 Los cálculos de costos asociados con el
desarrollo de software excesivamente elevados
 Insatisfactorio comportamiento y
funcionalidad del software desarrollado

Motivación de los ingenieros a desarrollar
nuevos modelos de desarrollo, incluyendo
prototipos, síntesis de software, software
reutilizable,….
Causas para el ESTUDIO de Modelos

 Definir las actividades necesarias en el
desarrollo de un Sistema de Información.
 Mantener una coherencia entre todos los
proyectos de una misma organización.
 Introducir puntos de control para realizar
revisiones y controles de calidad, toma de
decisiones.
 Investigación de paradigmas o modelos de
desarrollo.
Necesidades de las organizaciones

“Marco de referencia que contiene los procesos,
las actividades y las tareas involucradas en el
desarrollo, la explotación y el mantenimiento de
un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta
la finalización de su uso.”
Norma ISO 12207-1
Ciclo de vida del Software

CICLO DE VIDA: Conjunto de etapas que se han de llevar a
cabo para crear, explotar y mantener un Sistema Informático.
METODOS: Son las normativas que marcan las directrices
que se han de seguir para llevar a cabo una tarea. Responde a
la pregunta QUÉ.
TECNICAS: Es un modo de representación para la solución
de un problema concreto. Responde a la pregunta CÓMO.
METODOLOGIA: Es un conjunto coherente de métodos y
técnicas que cubren más de una etapa del ciclo de vida.
HERRAMIENTAS: Proporcionan un soporte automático o
semi-automático para el proceso y para los métodos.
DEFINICIONES

 Los paradigmas o modelos de desarrollo de Software
son estrategias de desarrollo para organizar las diversas
etapas y actividades del ciclo de vida del software.
 Describe las transiciones entre las etapas,
especificando qué actividades desarrollar en cada
momento.
 Selección de un modelo o paradigma específico
dependiendo de la naturaleza del proyecto y/o aplicación,
los métodos, las herramientas a utilizar, los controles y
entregas que se requieren.
Paradigmas o Modelos de desarrollo

El trabajo asociado a la ingeniería del Software
puede dividirse en tres fases fundamentales,
independientemente del área de aplicación:
 FASE DE DEFINICIÓN
 FASE DE DESARROLLO
 FASE DE MANTENIMIENTO

 Qué información que ha de ser procesada,
 Qué función y rendimiento se desea
 Qué comportamiento del sistema
 Qué interfaces van a ser establecidas
 Qué restricciones de diseño existen
 Qué criterios de validación se necesitan para definir
Dependiendo del paradigma o modelo se definen un
conjunto específico de actividades, pero las tareas
principales serán: ingeniería de sistema o de información,
planificación del proyecto del software, y análisis de los
requisitos
Paradigmas o Mod. de desarrollo: Fase de definición

 Cómo han de diseñarse las estructuras de datos,
 Cómo ha de implementarse la función como una
arquitectura del software
 Cómo han de caracterizarse las interfaces
 Cómo ha de traducirse el diseño en un lenguaje de
programación
 Cómo ha de realizarse la prueba
Las tareas principales serán: diseño del software,
generación de código y prueba del software
Paradigmas o Mod. de desarrollo: Fase de desarrollo

Fase centrada en el cambio que va asociado a la corrección de errores,
a las adaptaciones requeridas a medida que evoluciona el entorno del
software, y a cambios producidos por los requisitos cambiantes del
software.
Cuatro tipos de cambio:
Corrección, Adaptación (Cambio de sistema Operativo, reglas de la
empresa,etc.), Mejora, Prevención (reingeniería)
Actividades a realizar:
Gestión de riesgos, revisiones técnicas formales, mediciones, garantia
de calidad del software, seguimiento y gestion del proyecto de
software, gestión de reutilizació….
Paradigmas o Mod. de desarrollo: Fase de
Mantenimiento

Desglosando las fases anteriores, obtendríamos
las principales fases o etapas del ciclo de vida del
software
 Identificación del sistema y definición de requerimientos
 Análisis
 Diseño
 Desarrollo e implementación
 Integración y prueba del software
 Documentación
 Entrenamiento y uso
 Mantenimiento del software

Principales Modelos:
~ Ciclo de vida en cascada o modelo tradicional
(WaterFall)
~ Prototipado
~ Modelo o ciclo de vida en espiral
~ Programación Exploratoria
~ Transformaciones formales
~ Modelos de desarrollo orientados a objetos

• Propuesto por Royce en 1970, popularizado por Boehm en
1981
• Finalidad: Establecer orden en el desarrollo de grandes
productos de software
• Diferentes etapas, las cuales son procesadas de un modo
lineal
• Base de muchos otros modelos, levemente mejorada y
retocada a lo largo del tiempo.
• Aún en nuestros días sigue siendo muy utilizado.
Paradigmas o Modelos de desarrollo:
Ciclo de vida en cascada o mod. tradicional

• Anima a especificar lo que el sistema ha de hacer
(definición de requerimientos) antes de la construcción del
sistema
• Planea los componentes que van a interaccionar
• Gestiona el encuentro de errores
• Genera un conjunto de documentos para más tarde ser
utilizados y permitir un buen testeo y mantenimiento del
sistema
• Reducir los costes de desarrollo y mantenimiento
• Referente a las tareas a realizar: Organización estructurada

1. Definición de requerimientos
Estudio detallado de la situación actual del problema a tratar,
definición de los requerimientos que debe cumplir el nuevo
sistema
2. Análisis y diseño del sistema
Descomposición modular de toda la aplicación, descripción
detallada de cada uno de los módulos y sus inter-relaciones, todo
ello para poder facilitar al máximo la fase de codificación
3. Implementación (codificación)
Cada módulo como resultado de la fase anterior es traducido a la
herramienta o lenguaje apropiado.
Ciclo de vida en cascada: Etapas (1/2)

4. Integración y pruebas
Verificación del correcto funcionamiento de cada módulo y todo el
sistema una vez ha sido integrado, detectar errores en la
codificación, definiciones de requerimientos y de diseño
5. Explotación y mantenimiento
Garantizar el mantenimiento del sistema, corrección de errores
detectados en esta fase, adaptación del sistema a nuevos entornos.
¿Cuál es la etapa que absorbe la mayoría de tiempo?
La fase de explotación y mantenimiento, y es un coste
adicional para el cliente
Ciclo de vida en cascada: Etapas (2/2)

 El establecimiento explícito de todos los requisitos del
sistema al principio del desarrollo.
 Poca flexibilidad para cambios en el sistema. No
muestra interactividad entre fases
 Nada hecho hasta el final. La validación de los
requisitos iniciales no realizada hasta el final
 La implementación del sistema de un modo ascendente
implica primero las pruebas modulares, después la de los
subsistemas, y finalmente la del sistema completo. Los
problemas graves suelen encontrarse en la interficie entre
subsistemas
Ciclo de vida en cascada: CRITICA

Objetivos principales de cada una de las fases:
1. Estudio del sistema actual y viabilidad del nuevo sistema
Identificación de usuarios envueltos, estudio de su puesto de
trabajo, deficiencias actuales, sugerencias de cara al futuro.
Establecer los objetivos del nuevo sistema. Determinar la
viabilidad proponiendo diversas soluciones. Planificación de
desarrollo. 5% o 10 % del tiempo total del desarrollo.
2. Análisis
Especificación estructurada utilizando diferentes técnicas de
diagramas para modelar el sistema nuevo
Ciclo de vida en cascada: MEJORAS
Ciclo de Vida Estructurado (1/3)

3. Diseño
Establecer un conjunto de módulos e interficies entre ellos,
desglosando la especificación obtenida en la fase de análisis,
facilitando la tarea de codificación, transformación de los modelos
lógicos de datos a físicos
4. Implementación
Programación estructurada descendente e integración de los
módulos

5. Generación de pruebas de aceptación
Especificación de un conjunto de pruebas
6. Garantía de calidad.
7. Descripción de los procedimientos
Toda la documentación necesaria para describir tanto los procesos
como el producto resultante
8. Instalación e implantación del nuevo sistema al entorno
Principal característica del modelo: la implantación del sistema
descendente. Abstracción de sistema, de los subsistemas y
finalmente de los módulos

Documentación
Definición
de requerimientos
Análisis y
Diseño del sistema
Implementación
Integración y
Pruebas
Explotación y
Mantenimiento

• Utilizados principalmente en el desarrollo de sistemas donde
existe un pobre conocimiento de los requerimientos de un sistema
o la rápida evolución de los mismos a través del tiempo.
• Captura de requerimientos  “diseño rápido”
• El diseño rápido se centra en una representación de aquellos
aspectos del software que serán visibles al usuario. El prototipo es
evaluado por el cliente y el usuario y utilizado para refinar los
requerimientos del software a ser desarrollado.
Prototipo

1. Preliminar análisis y especificación de los
requerimientos de usuario.
2. Diseño e implementación de un prototipo
Énfasis en la interficie de usuario, equipo pequeño para
minimizar los costes de comunicación. Utilización de
herramientas de ayuda al desarrollo.
3. Ejercicio del prototipo
4. Refinamiento iterativo del prototipo
5. Refinamiento de los requerimientos
6. Diseño e implementación de un sistema.
A partir de la fase 6 se sigue con el estándar del ciclo de vida.
Prototipo : FASES

Prototipado

Prototipo: CRITICAS
El diseño rápido indica muchas de las veces el utilizar
fragmentos de programas ya existentes y herramientas
que faciliten la rápida generación de programas.

 No se tiene en cuenta la calidad del software, ni su
mantenimiento.
 Ineficiencia de los programas, utilización de recursos,
utilización de lenguajes inadecuados

Prototipo: ¿Para QUE nos puede ser útil?
 Cuando el cliente no sabe o no quiere revisar modelos
abstractos de datos (DER o DFD) para la validación de
los resultados que se van obteniendo.
 “No sé lo que quiero , pero lo reconoceré en cuanto lo
vea”
 Sistemas on-line donde la importancia reside más en la
interficie de usuario que en los procesos.

• Descrito por Boehm, mejores características de los dos modelos
anteiromente expuestos
• Incorpora el factor “riego del proyecto” al modelo de ciclo de vida
• Se produce una cadena continua de productos, los cuales están
disponibles para la examinación y evaluación por parte del cliente
• Provee mecanismos para la aseguración de la calidad del software
• La reevaluación después de cada fase permite cambios en las
percepciones de los usuarios, avances tecnológicos o perspectivas
financieras
Modelo o ciclo de vida en espiral

• Planificación
Determinación de objetivos, alternativas, restricciones, y elaboración
del plan de desarrollo para el ciclo actual.
• Análisis de riesgos
Evaluación de las alternativas, identificación y resolución de riesgos.
Se decide si se sigue o no con el proyecto
• Ingeniería
Desarrollo del producto siguiendo un modelo: del ciclo de vida o
cascada, prototipo, etc...
• Evaluación por el cliente
Valoración de resultados
Modelo o ciclo de vida en espiral:
CUADRANTES

Modelo o ciclo de vida en espiral

Modelo o ciclo de vida en espiral: Puntos Fuertes
 Evita las dificultades de los modelos existentes a través de un
acercamiento conducido por el riesgo.
 Intenta eliminar errores en las fases tempranas.
 Es el mismo modelo para el desarrollo y el mantenimiento.
 Provee mecanismos para la aseguración de la calidad del software.
 Trabaja bien en proyectos complejos, dinámicos e innovadores.
 La reevaluación después de cada fase permite cambios en las
percepciones de los usuarios, avances tecnológicos o perspectivas
financieras.
 La focalización en los objetivos y limitaciones ayuda a asegurar la
calidad.

Modelo o ciclo de vida en espiral: Puntos Débiles
 Falta un proceso de guía explícito para determinar
objetivos, limitaciones y alternativas
 Provee más flexibilidad que la conveniente para la
mayoría de las aplicaciones
 La pericia de tasación del riesgo no es una tarea fácil. El
autor declara que es necesaria mucha experiencia en
proyectos de software para realizar esta tarea exitosamente

Modelo o ciclo de vida en espiral: Dominios
Dominio de aplicación
 Proyectos complejos, dinámicos, innovadores,
ambiciosos, llevados a cabo por equipos internos (no
necesariamente de software).
Dominios de aplicación inapropiados
 Dominio de probemas fáciles: si el domino del
problema está bien entendido y no hay mayores riesgos,
es difícil y consume tiempo buscar riesgos donde no los
hay.

• Basado en el desarrollo de una implementación inicial,
exponiéndola a la opinión del usuario y luego refinándola a
través de muchas etapas hasta obtener un sistema adecuado.
• Sistemas en los que es difícil (o imposible) establecer una
detallada especificación. (ejemplo: Inteligencia Artificial)
• Forma de validación no medible, convirtiéndose en una
apreciación subjetiva por parte del cliente. No puede ser
utilizado en el desarrollo de grandes sistemas.
Programación Exploratoria

Programación Exploratoria

• Definición formal de los requerimientos del sistema
(matemáticamente), ir desarrollando metódicamente hasta llegar
al sistema definitivo
• Se puede demostrar la validación de los requerimientos, (ojo!!:
No los requerimientos del cliente)
• Ejemplo de aplicación: desarrollo de nuevos Sistemas
Operativos, dispositivos médicos, desarrollo de aviónica, etc...
• La ambigüedad, lo incompleto y la inconsistencia se descubren
y corrigen más fácilmente, mediante la aplicación del análisis
matemático
Transformaciones Formales

El paradigma orientado a objetos ha sufrido una evolución similar
al paradigma de programación estructurada: primero se
empezaron a utilizar los lenguajes de programación estructurados,
que permiten la descomposición modular de los programas; esto
condujo a la adopción de técnicas de diseño estructuradas y de ahí
se paso al análisis estructurado. El paradigma orientado a objetos
ha seguido el mismo camino: el uso de la Programación Orientada
a Objetos (POO) ha modificado las técnicas de diseño para
adaptarlas a los nuevos lenguajes y ahora se están empezando a
utilizar técnicas de análisis basadas en este nueva forma de
desarrollar software.
Orientación a objetos

 La cultura implícita en los modelos usuales de ciclo de vida está
basada en el “proyecto” ( y “Beneficios”), mientras que en el
desarrollo orientado a objetos está basada en el “producto” (e
“inversión”).
 Términos más importantes en la orientación a objetos:
Reusabilidad: Los nuevos Sistemas OO pueden ser creados
utilizando otros sistemas OO ya existentes
Extensibilidad: Los nuevos sistemas OO son fácilmente
ampliables, sin tener que retocar los módulos empleados en su
construcción

 Basados en el Dominio del Problema: Representar el sistema en términos del mundo
real, favoreciendo la reutilización, al ser un sistema próximo a la realidad es más estable
frente a cambios
 El término dominio del problema o dominio de aplicación es uno de los más usados
en el paradigma orientado a objetos. Se refiere al campo de aplicación del sistema, es
decir, a qué es el sistema, entendido desde su propio campo de aplicación, más que a su
descripción en términos de una implementación en ordenador.
 No tiene sentido empezar a escribir los requisitos funcionales de un sistema de control
de tráfico aéreo, y menos aún diseñarlo o programarlo sin estudiar primero qué es el
tráfico aéreo o qué se espera de un sistema de control de este tipo. La ventaja del AOO
es que se basa en la utilización de objetos como abstracciones del mundo real. Esto nos
permite centrarnos en los aspectos significativos del dominio del problema (en las
características de los objetos y las relaciones que se establecen entre ellos) y este
conocimiento se convierte en la parte fundamental del análisis del sistema software, que
será luego utilizado en el diseño y la implementación.

Las características principales del enfoque orientado a objetos
son, en primer lugar:
Identidad. Los datos se organizan en entidades discretas y
distinguibles llamadas objetos. Estos objetos pueden ser concretos
o abstractos, pero cada objeto tiene su propia identidad. Dicho de
otra forma: dos objetos son distintos incluso aún en el caso de que
los valores de todos sus atributos (p. ej. nombre y tamaño)
coincidan. Dos manzanas pueden ser totalmente idénticas pero no
por eso pierden su identidad: nos podemos comer una u otra.

Clasificación. Los objetos que tengan los mismos atributos y
comportamiento se agrupan en clases. Todas las manzanas tienen
una serie de atributos comunes: tamaño, peso, grado de
maduración, y un comportamiento común: podemos coger una
manzana, moverla o comerla. Los valores de los atributos podrán
ser distintos para cada una de ellas, pero todas comparten los
mismos atributos y comportamiento (las operaciones que se
pueden realizar sobre ellas). Una clase es una abstracción que
describe propiedades (atributos y comportamiento) relevantes para
una aplicación determinada, ignorando el resto. La elección de
clases es arbitraria, y depende del dominio del problema.

Polimorfismo. El polimorfismo permite que una misma operación
pueda llevarse a cabo de forma diferente en clases diferentes. Por
ejemplo, la operación mover, es distinta para una pieza de ajedrez
que para una ficha de parchís, pero ambos objetos pueden ser
movidos. Una operación es una acción o transformación que
realiza o padece un objeto. La implementación específica de una
operación determinada en una clase determinada se denomina
método.
(Según lo dicho, una operación es una abstracción de un comportamiento
similar (pero no idéntico) en diferentes clases de objetos. La semántica de
la operación debe ser la misma para todas las clases. Sin embargo, cada
método concreto seguirá unos pasos procedimentales específicos.)

Herencia. El concepto de herencia se refiere a la compartición de
atributos y operaciones basada en una relación jerárquica entre
varias clases. Una clase puede definirse de forma general y luego
refinarse en sucesivas subclases. Cada clase hereda todas las
propiedades (atributos y operaciones) de su superclase y añade sus
propiedades particulares.
La posibilidad de agrupar las propiedades comunes de una serie
de clases en una superclase y heredar estas propiedades en cada
una de las subclases es lo que permite reducir la repetición de
código en el paradigma OO y es una de sus principales ventajas.

Modelo de agrupamiento (Cluster)
Modelo Fuente ( el más conocido)
Modelo Remolino
Modelo Pinball

Ingeniería Inversa y Reingeniería
La ingeniería inversa consiste en analizar un programa en un
esfuerzo de representarlo en un mayor nivel de abstracción que el
código fuente, de forma que se extraiga información del diseño de
datos, de la arquitectura y del detalle procedimental del mismo,
para poder entenderlo.
La Reingeniería no sólo recupera información sobre el diseño de
un programa existente sino que utiliza esta información para
reestructurar o reconstruir el programa existente, con vistas a
adaptarlo a un cambio, a ampliarlo o a mejorar su calidad general,
con el objetivo de conseguir una mayor facilidad de
mantenimiento en un futuro, es decir, para un mantenimiento
preventivo

 Sommerville. “Software Engineering”, 5th edition, Addison-Wesley, 1996.
 G.Booch.“Object-Oriented Analysis and Design with Applications”. Benjamin
Cummings, 1993.
 P.Coad, E. Yourdon. “Object-Oriented Analysis”. Prentice-Hall, 1991
 K.W.Derr. “Applying OMT”. SIGS Books,1995
 Rational Software Corporation, “UML. Unified Modeling Language.”, 1997.
Http://www.rational.com
Bibliografía

ACM (Asociation for Computing Machinery)
Organización científica y educacional, internacional, dedicada a los avances en ciencias y aplicaciones de
tecnología de la información.
http://www.acm.org
SEI (Software Engineering Institute)
Centro de investigación y desarrollo soportado por el departamento de defensa de los EEUU (localizado en
Carnegie-Mellon University)
http://www.sei.cmu.edu
IEEE
http://www.computer.org
SEL (Software Engineering Laboratory of NASA)
http://sel.gsfc.nasa.gov
Importantes Direcciones

Metodología de desarrollo

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Metodología de desarrollo

Similar a Metodología de desarrollo (20)

Último

Último (6)

Metodología de desarrollo