TRABAJO PRCTICO

DE

INGENIERIA DE SOFTWARE

TEMA: Ciclos de Vida de Desarrollo de

Software y Reutilizacin de Software

CARRERA: Ingeniera Informatica

AO: 2016
PRIMERA PARTE.
PREGUNTAS TERICAS (25 PUNTOS CADA UNA)

1. Ciclo de vida de Software. Tipos. Describir

2. Fase de diseo. Tipos. Describir
3. REUTILIZACIN DE SOFTWARE.

Resuelva cuanto sigue (25 Puntos)

1. Deduzca y justifique en qu casos es mejor aplicar un ciclo de vida en cascada

respecto a uno en espiral y viceversa.
2. D una breve definicin de la fase de diseo. Describa cules son los objetivos
ltimos que se pretende alcanzar con la descomposicin modular del diseo.
3. Defina la REUTILIZACIN DE SOFTWARE. Justifique la importancia de este
concepto y la necesidad de su utilizacin.

Plazo: mircoles 23/11/2016

CONCEPTO DE CICLO DE VIDA CONCEPTO DE CICLO DE VIDA

Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y

el mantenimiento del software IEEE 1074

Un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definicin de los requisitos hasta la
finalizacin de su uso ISO 12207-1

CASCADA

Las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) de
manera lineal, una nica vez, y el inicio de una fase no comienza hasta que termina la
fase anterior.

Su naturaleza es lineal, tpica de la construccin de productos fsicos (lo comentamos

en dos razones por las que fabricar software no es lo mismo que fabricar coches o
construir casas), y su principal problema viene de que no deja claro cmo responder
cundo el resultado de una fase no es el esperado.

El ciclo de vida ms criticado en los ltimos aos, la mayora de las veces, que no todas,
con razn. En muchos proyectos su implantacin ha sido un fracaso, mientras que hay
otros proyectos que trabajarn perfectamente de esta manera.

Errneamente a este ciclo de vida se le ha hecho sinnimo de la palabra proceso,

como comentamos en mitos del Desarrollo Software: Proceso es sinnimo de ciclo de
vida en cascada.

ESPIRAL

Para resolver los anteriores problemas, en 1984 Boehm presenta el ciclo de vida en
espiral, en el que cada una de las fases del cascada termina con una evaluacin de
riesgos y un prototipo.

Los prototipos permiten a los usuarios determinar si el proyecto continua, debe volver a
fases anteriores, o debe terminar. Sin embargo, las fases son todava lineales, los
requisitos se realizan en la fase de requisitos, el diseo en la fase de diseo, y as
sucesivamente.

INCREMENTAL

Cada iteracin (una iteracin es un periodo de tiempo, no confundir con el ciclo de vida
iterativo, que veremos luego, siendo este uno de los principales los que vienen de
definiciones confusas) contiene las fases del cascada estndar, pero cada iteracin
trabaja sobre un sub conjunto de funcionalidad. La entrega total del proyecto se divide
en subsistemas priorizados.
Desarrollar por partes el producto software, para despus integrarlas a medida que se
completan. Un ejemplo de un desarrollo puramente incremental puede ser la agregacin
de mdulos en diferentes fases. El agregar cada vez ms funcionalidad al sistema.

ITERATIVO

En cada ciclo, iteracin, se revisa y mejora el producto. Un ejemplo de desarrollo

iterativo es aquel basado en refactorizaciones (te dejo el post de introduccin a la
refactorizacin), en el que cada ciclo mejora ms la calidad del producto.

Es importante sealar que este ciclo no implica aadir funcionalidades en el producto,

pero si la revisin y la mejora.

ITERATIVO E INCREMENTAL

Incremental = aadir, iterativo = retrabajo, que deca Cockburn.

Se va liberando partes del producto (prototipos) peridicamente, en cada iteracin, y

cada nueva versin, normalmente, aumenta la funcionalidad y mejora en calidad
respecto a la anterior. Aqu hay un post con ms informacin.

El ciclo de vida iterativo e incremental es una de las buenas prcticas de ingeniera del
software ms antiguas, su primer uso en el software se data en los 50 (te dejo este post
donde hablamos del tema).

Sobre estos dos ciclos de vida te dejo un artculo de Cockburn especialmente

aclaratorio.

Adems, el ciclo de vida iterativo e incremental es una de las bases de un proyecto gil,
ms concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente
un mes y raramente ms de dos.

CICLOS DE VIDA DE LAS METODOLOGAS GILES

Yendo a una definicin de mnimos, sera un ciclo de vida iterativo e incremental, con
iteraciones cortas (semanas) y sin que dentro de cada iteracin tenga porque haber fases
lineales (tipo cascada).

A partir de la anterior, matizaciones, adaptaciones, etc., hay por cada metodologa gil
que existe.

Quiz el caso ms popular es el de Scrum. Hace ya sus aos, en el 85, y en la primera

presentacin oficial de Scrum, Ken Schwaber, uno de sus creadores, hablaba sobre el
ciclo de vida de Scrum, y sus diferencias con los anteriores ciclos de vida

Segn comenta Ken Schwaber, el ciclo de vida en Cascada y el Espiral cierran el

contexto y la entrega al inicio de un proyecto. La principal diferencia entre cascada,
espiral e iterativo y los ciclos de vida giles, concretamente en Scrum, es que estos
ltimos asumen que el anlisis, diseo, etc., de cada iteracin o Sprint son
impredecibles. Los Sprints, o iteraciones cortas, no son (o a priori no tienen porque)
lineales y son flexibles.

Pero, como comentaba, ada metodologa de las llamadas giles, FDD, Crystal, DSDM,
XP, etc., matizar su ciclo de vida.

REUTILIZACION DEL SOFTWARE

Es el proceso de creacin de sistemas de software a partir de un software existente, en

lugar de tener que redisear desde el principio.

En los aos 60, se construyeron bibliotecas de subrutinas cientficas reutilizables con un

dominio de aplicacin limitado, en la actualidad se crean componentes comunes a
varios procesos con el fin de poder utilizarlos en la construccin de software.

Podemos definirla como el empleo de elementos de software u otros de nivel superior,

creados en desarrollo anteriores, para de este modo reducir los tiempos y simplificar el
desarrollo del software, mejorando la calidad y reduciendo su costo.

FASES DEL DISEO

La fase de Plantificacin del Software comprende las etapas de Ingeniera del Sistema o
Anlisis del Sistema, en concreto el establecimiento de los Requisitos del Software o
Plan Software; y el Anlisis de los Requisitos del Software, que se traduce en una
Especificacin de Requisitos.

La fase de Desarrollo emparede las etapas de diseo, calificacin y pruebas. Y la fase de

mantenimiento incorpora solamente la etapa propia de mantenimiento.
1. Ingeniera del Sistema o Anlisis del Sistema: Esta etapa tiene por objeto realizar un
anlisis global del sistema, estableciendo los requisitos de todos los elementos del
sistema y luego asignar al software la parte de los requisitos que le afectan. Este
planteamiento del sistema es esencial cuando el software debe interrelacionarse con
otros elementos, tales como personas, hardware y bases de datos.

Se debe tener tener en cuenta cuando se informatiza un problema que existen tareas
manuales que se deben tratar dentro del sistema. Es decir, el anlisis del sistema
comprende el tratamiento de todas las tareas manuales e informticas que definen el
sistema. Para ello, el ingeniero informtico tendr que estudiar a fondo todo sistema,
especializarse en su terminologa y realizar una interaccin permanente con el cliente, el
experto del sistema u los usuarios de forma que la percepcin que tenga del sistema
coincide con la del cliente, experto y usuario.

El anlisis del sistema es una etapa de la fase de planificacin y en ella se realiza una
descripcin del entorno, software que se quiere obtener y se define los recursos
humanos para su desarrollo, el coste y el calendario estimado.

En concreto, el anlisis del sistema presenta los siguientes objetivos:

Identificar las necesidades del cliente.

Realizar un anlisis tcnico y econmico del sistema.
Establecer restricciones de costo y tiempo.
Evaluar la viabilidad del sistema.
Asignar funciones al software, a la gente, a las bases de datos y otros elementos
del sistema.
Definir el sistema.

2. Anlisis del Sistema: Define los flujos de informacin, las estructuras primarias de
datos, las caractersticas funcionales del sistema, los requerimientos de rendimiento y
las restricciones impuestas por el cliente. Asimismo, se incorporarn los criterios
globales de validacin que se utilizarn para probar que los requisitos sealados han
sido implementados.
3. Diseo: Es el primer paso en la fase de desarrollo de cualquier producto o sistema de
ingeniera. Define como el proceso de aplicar distintas tcnicas y principios con el
propsito de definir un dispositivo, proceso o sistemas con los suficientes detalles como
para permitir su realizacin fsica. El objetivo del diseador es producir un modelo o
representacin de una entidad que ser construida ms adelante. Esta etapa se suele
dividir en dos:

1. Diseo Preliminar
1.1 Diseo de datos.
1.2 Diseo arquitectnico.
1.3 Diseo de la interfaz hombre-mquina.
2. Diseo Detallado
2.1 Diseo Procedimental

4. Calificacin: Esta etapa tiene por fin traducir en una forma legible para la
computadora el diseo desarrollado en la etapa anterior. Esta actividad implica la
creacin de programas informticos aplicar las estructuras de programacin de algn
paradigma y utilizando un lenguaje apropiado de programacin. Como producto de este
proceso se obtiene un listado fuente de los programas que definen el software que se
est desarrollando.

5. Mantenimiento: El software producido en la fase de desarrollo debe ser mantenido,

ya que sufrir cambios despus de que se entreguen al cliente. Los cambios ocurrirn
debido a:

Errores encontrados (mantenimiento correctivo).

Cambios en el entorno externo al que el software debe adaptarse (mantenimiento
adaptativo).
Que el cliente requiere ampliaciones funcionales o desea incrementar su
rendimiento (mantenimiento perfectivo).

Esta fase comporta diferentes actividades: por un lado comprobar que toda la
documentacin est disponible y es adecuada para las tareas de mantenimiento. y por
otro establecer un esquema de acciones para el caso de error o molificacin del software
y comunicar al usuario esas acciones.
 1. Deduzca y justifique en qu casos es mejor aplicar un ciclo de vida en cascada
respecto a uno en espiral y viceversa.

El modelo de desarrollo de software en cascada es el enfoque metodolgico que ordena

rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de
cada etapa debe esperar la finalizacin de la inmediatamente anterior en cambio el
modelo de desarrollo en espiral tiene en cuenta fuertemente el riesgo que aparece a la
hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de
desarrollo, se opta por la de riesgo ms asumible y se hace un ciclo de la espiral. Si el
cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas
nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un
momento en el que el producto software desarrollado sea aceptado y no necesite seguir
mejorndose con otro nuevo ciclo.

2. D una breve definicin de la fase de diseo. Describa cules son los objetivos
ltimos que se pretende alcanzar con la descomposicin modular del diseo.

Descomposicin modular

El diseo modular propone dividir el sistema en partes diferenciadas y definir sus

interfaces.

Sus ventajas: Claridad, reduccin de costos y re utilizacin.

Los pasos a seguir son:

1. Identificar los mdulos

2. Describir cada mdulo
3. Describir las relaciones entre mdulos

Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda
considerar suficiente validad.

1. Independencia funcional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad
Independencia Funcional

Cada mdulo debe realizar una funcin concreta o un conjunto de funciones

afines. Es recomendable reducir las relaciones entre mdulos al mnimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y
cohesin.

Acoplamiento

El acoplamiento es una medida de la interconexin entre mdulos en la estructura del

programa. Se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las
interconexiones entre los distintos mdulos en que se estructure nuestra aplicacin. El
grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de
conexin y la complejidad de la interfaces:

Fuerte

Por contenido, cuando desde un mdulo se puede cambiar datos locales de otro.
Comn, se emplea una zona comn de datos a la que tienen acceso
varios mdulos.

Moderado

De control, la zona comn es un dispositivo externo al que estn ligados

los mdulos, esto implica que un cambio en el formato de datos los afecta a
todos.

Dbil

De datos, viene dado por los datos que intercambian los mdulos. Es el mejor.
Sin acoplamiento directo, es el acoplamiento que no existe

Cohesin

Un mdulo coherente ejecuta una tarea sencilla en un procedimiento y requiere poca

interaccin con procedimientos que se ejecutan en otras partes de un programa.
Podemos decir que un mdulo coherente es aquel que intenta realizar solamente una
cosa.

Comprensibilidad

Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es

necesario que cada uno sea comprensible de forma aislada.
Para ello es bueno que posea independencia funcional, pero adems es deseable:
Identificacin, el nombre debe ser adecuado y descriptivo
Documentacin, debe aclarar todos los detalles de diseo e implementacin que
no queden de manifiesto en el propio cdigo
Adaptabilidad

La adaptacin de un sistema resulta ms difcil cuando no hay independencia funcional,

es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es poco
comprensible. Otros factores para facilitar la adaptabilidad:

Previsin, es necesario prever que aspectos del sistema pueden ser susceptibles de
cambios en el futuro, y poner estos elementos en mdulos independientes, de manera
que su modificacin afecte al menor nmero de mdulos posibles

Accesibilidad, debe resultar sencillo el acceso a los documentos de especificacin,

diseo, e implementacin para obtener un conocimiento suficiente del sistema antes
de proceder a su adaptacin

Consistencia, despus de cualquier adaptacin se debe mantener la consistencia del

sistema, incluidos los documentos afectados.

REUTILIZACIN DEL SOFTWARE. JUSTIFICACIN.

La reutilizacin de software es una alternativa para desarrollar aplicaciones y sistemas

de software de una manera ms eficiente, productiva y rpida.

La idea es que se reutilicen elementos y componentes en lugar de tener que

desarrollarlos desde un principio.

Al reutilizar el software estamos reduciendo el tiempo de desarrollo, reduciendo los

costos y estamos incrementando la productividad.