Repblica Bolivariana de Venezuela

Instituto Universitario Politcnico

Santiago Mario
Ingeniera de Sistemas
Sistemas I
Lapso 1

INTRODUCCIN A LA
INGENIERA DE SOFTWARE,
PROCESOS ALTERNATIVOS

Alumnos:
Arroyo Jos C.I 10.555.148
Flores Jos C.I 16.976.126
Salazar Edgar C.I: 14.550.306
Zambrano Jhoann C.I 16.637.319
Seccin :S6

Barinas, Abril de 2011

INDICE

INTRODUCCION
INTRODUCCIN A LA INGENIERA DE SOFTWARE
1. Definir Ingeniera de Software
2. Conocer el campo de aplicacin de la Ingeniera de Software.
3. Explicar las actividades de la Ingeniera de Software
PROCESOS ALTERNATIVOS
1. Breve introduccin de los enfoques: estructurado, orientado a objeto,
aplicaciones Web y UML.
2. Tipos Modelo: Espiral, Cascada, Cascada con Prototpico, Por
Incremento, de Desarrollo de Software Unificado (USDP), Cluster y
Grady Booch.
CONCLUSION
BIBLIOGRAFIA

INTRODUCCION

Es la ciencia que ayuda a elaborar sistemas con el fin de que sea

econmico, fiable y funcione eficientemente sobre las maquinas reales.
La ingeniera de software surge de la ingeniera de sistemas y de
hardware. Abarca un conjunto de 3 elementos clave: mtodos, herramientas y
procedimientos, estos facilitan al gestor a controlar el proceso de desarrollo de
software y suministra a los que practique dicha ingeniera las bases para
construir software de alta calidad. Es una disciplina o rea de la informacin o
ciencias de la computacin, que ofrece mtodos o tcnicas para desarrollar y
mantener software de calidad que resuelven problemas de todo tipo. Hoy da
es cada vez ms frecuente la consideracin de la Ingeniera del Software como
una nueva rea de la Ingeniera y el Ingeniero de Software comienza a ser una
profesin implantada en el mundo natural, laboral, internacional con derechos.
La Ingeniera del Software trata de reas muy diversas de la informtica
y de las ciencias computacionales, tales como constantes de compiladores,
sistemas operativos o desarrollos de Internet.

INTRODUCCIN A LA INGENIERA DE SOFTWARE

1.- DEFINIR INGENIERA DE SOFTWARE

La ingeniera del software es una disciplina de la ingeniera que
comprende todos los aspectos de la produccin de software desde las etapas
iniciales de la especificacin del sistema, hasta el mantenimiento de ste
despus de que se utiliza. En esta definicin, existen dos frases clave:
1. Disciplina de la ingeniera. Los ingenieros hacen que las cosas
funcionen. Aplican teoras, mtodos y herramientas donde sean
convenientes, pero las utilizan de forma selectiva y siempre tratando de
descubrir soluciones a los problemas, aun cuando no existan teoras y
mtodos aplicables para resolverlos. Los ingenieros tambin saben que
deben trabajar con restricciones financieras y organizacionales, por lo
que buscan soluciones tomando en cuenta estas restricciones.
2. Todos los aspectos de produccin de software. La ingeniera del
software no slo comprende los procesos tcnicos del desarrollo de
software, sino tambin con actividades tales como la gestin de
proyectos de software y el desarrollo de herramientas, mtodos y teoras
de apoyo a la produccin de software. En general, los ingenieros de
software adoptan un enfoque sistemtico y organizado en su trabajo, ya
que es la forma ms efectiva de producir software de alta calidad. Sin
embargo, aunque la ingeniera consiste en seleccionar el mtodo ms
apropiado para un conjunto de circunstancias, un enfoque ms informal
y creativo de desarrollo podra ser efectivo en algunas circunstancias. El
desarrollo informal es apropiado para el desarrollo de sistemas basados
en Web, los cuales requieren una mezcla de tcnicas de software y de
diseo grfico.
(IEEE, 1990)1: La aplicacin de un enfoque sistemtico, disciplinado y
cuantificable al desarrollo, la operacin y el mantenimiento del software; esto
es, la aplicacin de la ingeniera al software.
Es la aplicacin prctica del conocimiento cientfico en el diseo y
construccin de programas de computadora y la documentacin asociada
requerida para desarrollar y operar (funcionar) y mantenerlos. As como
tambin desarrollo de software o produccin de software.
La Ingeniera del Software es una disciplina o rea de la informtica o
ciencias de la computacin, que ofrece mtodo y tcnicas para desarrollar y
mantener software de calidad que resuelven problemas de todo tipo.
Hoy da es cada vez mas frecuente la consideracin de la Ingeniera del
Software como un nueva rea de la ingeniera, y el Ingeniero del Software
comienza a ser una profesin implantada en el mundo laboral internacional,
con derechos, deberes y responsabilidades que cumplir, junto a una, y
reconocida consideracin social en el mundo empresarial y, por suerte, para
esas personas con brillante futuro.

2.- CONOCER EL CAMPO DE APLICACIN DE LA INGENIERA DE

SOFTWARE
Un campo de accin claro del ingeniero de software es el de contribuir
en las organizaciones a mejorar la gestin de los proyectos, y en particular los
procesos de construccin de soluciones. Esta iniciativa de las empresas puede
estar motivada por la consecucin de un certificado estilo ISO 9001 o algn
nivel de CMM, pero sobre todo, estar motivada por la necesidad de organizar la
forma de trabajar para que sea ms eficiente, se mejore la productividad y la
calidad de lo que se produce.
Los campos de accin de la ingeniera de software incluyen el diseo,
implementacin, mantenimiento y/o administracin de:

Sistemas de software desarrollados internamente: sistemas construidos

integralmente por la organizacin, ya sea para consumo interno o como
productos de disponibilidad general a terceros interesados.
Sistemas adquiridos: sistemas provistos por suplidores de la
organizacin, que permiten y/o exigen distintos niveles de gestin y
adaptacin por parte del personal de la organizacin experto en
software.
Sistemas de software especializados: sistemas no convencionales que
conjugan el software con dispositivos muy especficos, tales como
computadores empotrados, dispositivos mviles, maquinaria industrial
altamente automatizada, etc.

Para cualquiera de los sistemas anteriores, la industria o mercado

particular en que ejerce el ingeniero de software es altamente variable,
pudiendo laborar en organizaciones tan diversas como financieras, educativas,
de telecomunicaciones, de servicios, industriales, etc.; atendiendo a su
formacin integral y al grado de especializacin en las tareas que ejecuta en su
organizacin.
3.- EXPLICAR LAS ACTIVIDADES DE LA INGENIERA DE SOFTWARE

Extraccin: Esta fase representa el comienzo de cada ciclo. Extraccin

es el nombre comnmente dado a las actividades involucradas en el
descubrimiento de los requerimientos del sistema.
Anlisis: Sobre la base de la extraccin realizada previamente,
comienza esta fase en la cual se enfoca en descubrir problemas con los
requerimientos del sistema identificados hasta el momento.

Especificacin: En esta fase se documentan los requerimientos

acordados con el cliente, en un nivel apropiado de detalle.

Validacin: La validacin es la etapa final de la IR. Su objetivo es,

ratificar los requerimientos, es decir, verificar todos los requerimientos
que aparecen en el documento especificado para asegurarse que
representan una descripcin, por lo menos, aceptable del sistema que

se debe implementar. Esto implica verificar que los requerimientos sean

consistentes y que estn completos.
Tcnicas y Herramientas utilizadas en las actividades de Ingenieria de
Software:

Entrevistas y cuestionarios
Sistemas existentes

Grabaciones de video y de audio

Brainstorming (tormenta de ideas)

Arqueologa de documentos

Aprendiz.

Observacin

Run Use Case WorkShop (talleres de trabajo basados en los Casos de

Uso)

Prototipos

Anlisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas)

Cadena de valor

Modelo de clase conceptual, Diagrama Conceptual, Diagrama de Clases

Conceptual

Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone

Diagram)

Glosario

Diagrama de actividad

Documento ESRE, Casos de uso

Lista de requerimientos

Casos de uso

Casa de calidad o QFD (Quality Function Deployment)

Checklist (lista de verificacin)

Definicin del proceso de desarrollo de software que se usar.

Administracin del proyecto de desarrollo.

Descripcin del producto que se desea.

Diseo del producto.

Implementacin del producto.

Pruebas de las partes del producto.

Integracin de las partes del producto y pruebas del producto completo.

Mantenimiento del producto.

PROCESOS ALTERNATIVOS
1.- BREVE INTRODUCCIN DE LOS ENFOQUES: ESTRUCTURADO,
ORIENTADO A OBJETO, APLICACIONES WEB Y UML
El Enfoque Estructurado.
Se podra denominar enfoque estructurado a la forma particular de
pensar el software en trminos de funciones de transformacin de datos. El
universo de discurso se disocia en funciones y datos, y cualquier tarea se
interpreta como una transformacin de datos.
Enfoques estructurados para el desarrollo de software que incluye:

Descripciones del modelo, descripciones de modelos grficos que deben

ser producidos
Reglas, restricciones aplicadas a los modelos de sistemas
Recomendaciones, para realizar un diseo efectivo
Administracin del proceso, que actividades deben realizarse y en qu
orden

Enfoque Orienta a Objetos

Las tecnologas de objetos llevan a reutilizar, y la reutilizacin (de
componente de software) lleva a un desarrollo de software ms rpido y a
programas de mejor calidad. El software orientado a objetos es ms fcil de
mantener debido a que su estructura es inherentemente poco acoplada. Esto
lleva a menores efectos colaterales cuando se deben hacer cambios. Los
sistemas orientados a objetos son ms fciles de adaptar y ms fcilmente

escalables (pueden crearse grandes sistemas ensamblando subsistemas

reutilizables).
Hacia mediados de los 80, los beneficios de la programacin orientada a
objetos empezaron a obtener reconocimiento, y el diseo de objetos pareci
ser un enfoque sensato para la gente que deseaba utilizar el lenguaje de
programacin orientada a objetos. Un enfoque orientado a objetos para
programar ofrece muchos beneficios sobre un enfoque estructurado.
El anlisis orientado a objetos y su diseo se enfoca en los objetos. Los
objetos tienen ciertos comportamientos y atributos que determinan la manera
en que interactan y funcionan. No se intenta proporcionar un orden para las
acciones al momento del diseo debido a que los objetos funcionan basados
en la manera en que funcionan otros objetos. La programacin orientada a
objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del
mundo real.
Las implementaciones orientadas a objetos ocultan datos, lo cual
significa que muestran nicamente los comportamientos a los usuarios y
ocultan el cdigo subyacente de un objeto. Los comportamientos que el
programador expone son nicamente aquellos elementos que el usuario de un
objeto puede afectar.
El enfoque orientado a objetos permite que los objetos estn auto
contenidos. Los objetos existen por s mismos, con una funcionalidad para
invocar comportamientos de otros objetos. Al utilizar un enfoque orientado a
objetos, los desarrolladores pueden crear aplicaciones que reflejan objetos del
mundo real, como rectngulos, elipses y tringulos, adems de dinero,
nmeros de partes y elementos en un inventario.
En un enfoque orientado a objetos, los objetos, por definicin, son
modulares en su construccin. Esto quiere decir que son entidades completas
y, por lo tanto, tienden a ser altamente reutilizables. Las aplicaciones
orientadas a objetos se construyen sobre el paradigma de los mensajes o de
los eventos en donde los objetos envan mensajes a otros objetos, como el
sistema operativo Microsoft Windows.
El Paradigma Orientado a Objetos.
Durante muchos aos el trmino Orientado a Objetos (OO) se us para
referirse a un enfoque de desarrollo de software que usaba uno de los
lenguajes orientados a objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). En el libro
The Structure of Scientific Revolutions, el historiador Thomas K describa un
paradigma como un conjunto de teoras, estndar y mtodos que juntos
representan un medio de organizacin del conocimiento: es decir, un medio de
visualizar el mundo. En este sentido, la programacin orientada a objetos es un
nuevo paradigma. La orientacin a objetos fuerza a reconsiderar nuestro
pensamiento sobre la computacin, sobre lo que significa realizar computacin
y sobre cmo se estructura la informacin dentro de la computadora.

Jenkins y Glasgow observan que la mayora de los programadores

trabajan en un lenguaje y utilizan slo un estilo de programacin. Ellos
programan en un paradigma forzado por el lenguaje que utilizan. Con
frecuencia, no se enfrentan a mtodos alternativos de resolucin de un
problema, y por consiguiente tienen dificultad en ver la ventaja de elegir un
estilo ms apropiado al problema a manejar. Bobrow y Stefik sugieren que
existen cuatro clases de estilos de programacin:

Orientados a procedimientos: Algoritmos.

Orientados a objetos: Clases y Objetos.
Orientados a lgica: Expresado en clculo de predicados.
Orientados a reglas: Reglas if-then.

No existe ningn estilo de programacin idneo para todas las clases de

programacin. La orientacin a objetos se acopla a la simulacin de situaciones
del mundo real.

Aplicaciones WEB
(web application, webapp). Una aplicacin web es cualquier aplicacin
que es accedida va web por una red como internet o una intranet.
En general, el trmino tambin se utiliza para designar aquellos
programas informticos que son ejecutados en el entorno del navegador (por
ejemplo, un applet de Java) o codificado con algn lenguaje soportado por el
navegador (como JavaScript, combinado con HTML); confindose en el
navegador web para que reproduzca (renderice) la aplicacin.
Una de las ventajas de las aplicaciones web cargadas desde internet (u
otra red) es la facilidad de mantener y actualizar dichas aplicaciones sin la
necesidad de distribuir e instalar un software en, potencialmente, miles de
clientes. Tambin la posibilidad de ser ejecutadas en mltiples plataformas.
Ejemplos de aplicaciones web
Las aplicaciones web son utilizadas para implementar webmail, ventas
online, subastas online, wikis, foros de discusin, weblogs, MMORPGs, redes
sociales, juegos, etc.
Caractersticas de las aplicaciones web
* El usuario puede acceder fcilmente a estas aplicaciones empleando un
navegador web (cliente) o similar.
* Si es por internet, el usuario puede entrar desde cualquier lugar del mundo
donde tenga un acceso a internet.
* Pueden existir miles de usuarios pero una nica aplicacin instalada en un

servidor, por lo tanto se puede actualizar y mantener una nica aplicacin y

todos sus usuarios vern los resultados inmediatamente.
* Emplean tecnologas como Java, JavaFX, JavaScript, DHTML, Flash, Ajax...
que dan gran potencia a la interfaz de usuario.
* Emplean tecnologas que permiten una gran portabilidad entre diferentes
plataformas. Por ejemplo, una aplicacin web flash podra ejecutarse en un
dispositivo mvil, en una computadora con Windows, Linux u otro sistema, en
una consola de videojuegos, etc.
Interfaz grfica de las aplicaciones web
La interfaz grfica de una aplicacin web puede ser sumamente
completa y funcional, gracias a las variadas tecnologas web que existen: Java,
JavaScript, DHTML, Flash, Silverlight, Ajax, entre otras.
Prcticamente no hay limitaciones, las aplicaciones web pueden hacer
casi todo lo que est disponible para aplicaciones tradicionales: acceder al
mouse, al teclado, ejecutar audio o video, mostrar animaciones, soporte para
arrastrar y soltar, y otros tipos de tecnologas de interaccin usuario-aplicacin.
Ajax es un ejemplo de una tecnologa de desarrollo web que le da gran
poder de interactividad a las aplicaciones web.
Aplicacin UML
Unified Modeling Language "UML", se ha convertido en la notacin
estndar para definir, organizar y visualizar los elementos que configuran la
arquitectura de un sistema.
Un sistema es algo "compuesto", una construccin realizada por manos
y herramientas siguiendo las directrices de un propsito. La palabra se aplica
casi exclusivamente a abstracciones con el fin de captar la totalidad de una
realidad.
A travs de la notacin UML podemos comunicar y compartir el
conocimiento de una arquitectura gracias a la combinacin simultnea de cinco
perspectivas:
1. Definir: Fijar, determinar, decidir, explicar un concepto a travs de
sus atributos distintivos. Sealar sus lmites y dar una idea exacta
de lo que es esencial y de lo que es circunstancial.
2. Organizar: Establecer unos recursos, disponer un orden de
responsabilidades y formalizar unas reglas de relacin y
actuacin; todo ello orientado a conseguir un propsito.
3. Visualizar: Representar mediante imgenes y/o smbolos el
contenido y la organizacin de los conceptos que configuran un
sistema. Hacer visible su naturaleza y su complejidad.

4. Actuar: Pensar y tomar decisiones de manera gil y sistemtica,

siguiendo un mtodo; ste a su vez, define el modo de actuar en
base a la relacin de un conjunto de actores, actividades,
entregables y certificaciones posibles en un escenario concreto.
5. Certificar: Comprobar de manera fehaciente que un entregable es
completo, coherente y usable para el propsito que ha sido
creado.
El resultado, es una mayor comprensin y claridad sobre la naturaleza
de los objetos, eventos y hechos que tienen consecuencias dentro de un
dominio.

2.- TIPOS MODELO: ESPIRAL, CASCADA, CASCADA CON PROTOTPICO,

POR INCREMENTO, DE DESARROLLO DE SOFTWARE UNIFICADO
(USDP), CLUSTER Y GRADY BOOCH.

Ciclo de vida del software

Al igual que en otros sistemas de ingeniera, los sistemas de software requieren
un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por
un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se
detecta la necesidad de construir un sistema de software hasta que este es retirado,
se identifican varias etapas que en conjunto se denominan el ciclo de vida del software
y en cada caso, en funcin de cuales sean las caractersticas del proyecto, se
configurar el ciclo de vida de forma diferente. Usualmente se consideran las etapas:
especificacin y anlisis de requisitos, diseo del sistema, implementacin del
software, aplicacin y pruebas, entrega y mantenimiento. Un aspecto esencial dentro
de las tareas del desarrollo del software es la documentacin de todos los elementos y
especificaciones en cada fase. Dado que esta tarea siempre estar influida por la fase
del desarrollo en curso, se explicar de forma distribuida a lo largo de las diferentes
fases como un apartado especial para recalcar su importancia en el conjunto del
desarrollo del software.
Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo
de vida son:
1. Anlisis: Construye un modelo de los requisitos
2. Diseo: A partir del modelo de anlisis se deducen las estructuras de datos, la
estructura en la que descompone el sistema y la interfaz de usuario.
3. Codificacin: Construye el sistema. La salida de esta fase es cdigo
ejecutable.
4. Pruebas: Se comprueba que se cumplen criterios de correccin y calidad.

5. Mantenimiento: En esta fase, que tiene lugar despus de la entrega se

asegura que el sistema siga funcionando y adaptndose a nuevos requisitos.
Las etapas constan de tareas. La documentacin es una tarea importante que se
realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos
procedentes de las etapas anteriores y produce otros documentos de salida segn se
muestra en la figura

Etapa genrica
Algunos autores dividen la fase del diseo en dos partes: Diseo global o
arquitectnico y diseo detallado. En el primero se transforman los requisitos en una
arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su
conjunto, se esboza la documentacin y se planifica la integracin. En el detallado
para cada mdulo se refina el diseo, se definen los requisitos del mdulo y su
documentacin.
Las formas de organizar y estructurar la secuencia de ejecucin de las tareas
en las diferentes fases de cada uno de los mtodos puede dar lugar a un tipo de ciclo
de vida diferente. Los principales ciclos de vida que se van a presentar a continuacin
realizan estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.
Ciclos de vida en cascada
El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el
software a partir de ciclos de vida de otras ramas de la ingeniera. Es el primero de los
propuestos y el ms ampliamente seguido por las organizaciones (se estima que el
90% de los sistemas han sido desarrollados as). La estructura se muestra en la figura

Ciclo de vida en cascada

Descripcin
Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las
modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la
necesidad de cambiar algo en el diseo, lo cual significa que se harn los cambios
necesarios en la codificacin y se tendrn que realizar de nuevo las pruebas, es decir,
si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer
de nuevo el resto de las etapas.
Despus de cada etapa se realiza una revisin para comprobar si se puede
pasar a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es
un tipo de documento especfico. Idealmente, cada fase podra hacerla un equipo
diferente gracias a la documentacin generada entre las fases. Los documentos son:

Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que

quiere el cliente. Produce el S.R.D. (Software Requirements Document).
Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design
Document)

Codificacin: A partir del S.D.D. produce mdulos. En esta fase se hacen

tambin pruebas de unidad.

Pruebas: A partir de los mdulos probados se realiza la integracin y pruebas

de todo el sistema. El resultado de las pruebas es el producto final listo para
entregar.

Ventajas

La planificacin es sencilla.
La calidad del producto resultante es alta.

Permite trabajar con personal poco cualificado.

Inconvenientes

Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es

que el cliente no tenga perfectamente definidas las especificaciones del
sistema, o puede ser que surjan necesidades imprevistas.
Si se han cometido errores en una fase es difcil volver atrs.

No se tiene el producto hasta el final, esto quiere decir que:

o

Si se comete un error en la fase de anlisis no lo descubrimos hasta la

entrega, con el consiguiente gasto intil de recursos.

El cliente no ver resultados hasta el final, con lo que puede

impacientarse .

No se tienen indicadores fiables del progreso del trabajo (sndrome del 90%).

Es comparativamente ms lento que los dems y el coste es mayor tambin.

Tipos de proyectos para los que es adecuado

Aquellos para los que se dispone de todas las especificaciones desde el

principio, por ejemplo, los de reingeniera.
Se est desarrollando un tipo de producto que no es novedoso.

Proyectos complejos que se entienden bien desde el principio.

Como el modelo en cascada ha sido muy popular ha generado algunas

variantes. Ahora veremos algunas.

Ciclo de vida en V
Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se
considera el nivel de abstraccin de cada una. Una fase adems de utilizarse como
entrada para la siguiente, sirve para validar o verificar otras fases posteriores. Su
estructura est representada en la figura.

Ciclo de vida en V
Ciclo de vida tipo sashimi

Segn el modelo en cascada puro una fase solo puede empezar cuando ha
terminado la anterior. En este caso sin embargo, se permite un solapamiento entre
fases. Por ejemplo, sin tener terminado del todo el diseo se comienza a implementar.
El nombre ``sashimi'' deriva del modo del estilo de presentacin de rodajas de
pescado crudo en Japn. Una ventaja de este modelo es que no necesita generar
tanta documentacin como el ciclo de vida en cascada puro debido a la continuidad
del mismo personal entre fases. Los problemas planteados son:

Es an ms difcil controlar el progreso del proyecto debido a que los finales de

fase ya no son un punto de referencia claro.
Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir
inconsistencias.

El diseo arquitectnico es el de alto nivel, el detallado el de bajo nivel. En la

figura se ha representado la estructura del ciclo de vida sashimi.

Ciclo de vida sashimi

Ciclo de vida en cascada con subproyectos
Si una vez que se ha llegado al diseo arquitectnico, se comprueba que el
sistema se divide en varios subsistemas independientes entre s, sera razonable
suponer que a partir de ese punto cada uno se puede desarrollar por separado y en
consecuencia en paralelo con los dems. Cada uno tendr seguramente fechas de
terminacin distintas. Una vez que han terminado todos se integran y se prueba el
sistema en su conjunto. La ventaja es que se puede tener a ms gente trabajando en
paralelo de forma eficiente. El riesgo es que existan interdependencias entre los
subproyectos.
Ciclo de vida en cascada incremental
En este caso se va creando el sistema aadiendo pequeas funcionalidades.
Cada uno de los pequeos incrementos es parecido a lo que ocurre dentro de la fase
de mantenimiento. La ventaja de este mtodo es que no es necesario tener todos los
requisitos en un principio. El inconveniente es que los errores en la deteccin de
requisitos se encuentran tarde.
Hay dos partes en el ciclo de vida, similares al anterior. Por un lado est el
anlisis y el diseo global. Por otra parte estn los pequeos incrementos, con las
fases de diseo detallado, codificacin y mantenimiento. En la figura se puede ver su
estructura.

Cascada incremental

Ciclo de vida en cascada con reduccin de riesgos

Como se ha comentado anteriormente, uno de los problemas del ciclo de vida
en cascada es que si se entienden mal los requisitos esto slo se descubrir cuando
se entregue el producto. Para evitar este problema se puede hacer un desarrollo
iterativo durante las fases de anlisis y diseo global. Esto consistira en:
1. Preguntar al usuario.
2. Hacer el diseo global que se desprende del punto 1.
3. Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y
volver con ello al punto 1 para identificar ms requisitos o corregir
malentendidos.
El resto es igual al ciclo de vida en cascada.
Modelo de ciclo de vida en espiral
Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos
que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto
ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo
incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un
riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseo, errores en la
implementacin, etc. Un representacin tpica de esta estructura se muestra en la
figura

Ciclo de vida en espiral

En cada iteracin Boehm recomienda recopilar la siguiente lista de
informaciones:

Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar

cuestionarios, etc.
Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se
consideran desde dos puntos de vista
o

Caractersticas del producto.

Formas de gestionar el proyecto.

Restricciones:
o

Desde el punto de vista del producto: Interfaces de tal o cual manera,

rendimiento, etc.

Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

Riesgos: Lista de riesgos identificados.

Resolucin de riesgos: La tcnica ms usada es la construccin de

prototipos.

Resultados: Son lo que realmente ha ocurrido despus de la resolucin de

riesgos.

Planes: Lo que se va a hacer en la siguiente fase.

Compromiso: Decisiones de gestin sobre como continuar.

Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente

cumple con los requisitos establecidos, tambin se verifica que funciona
correctamente. El propio cliente evala el producto. No existe una diferencia muy clara
entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando
hay que hacer un cambio, este puede consistir en un nuevo ciclo.
Ventajas

No necesita una definicin completa de los requisitos para empezar a

funcionar.
Al entregar productos desde el final de la primera iteracin es ms fcil validar
los requisitos.

El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido

el tiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn
bien).

El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en

etapas tempranas hay tiempo de subsanarlos.

Inconvenientes

Es difcil evaluar los riesgos.

Necesita de la participacin continua por parte del cliente.

Cuando se subcontrata hay que producir previamente una especificacin

completa de lo que se necesita, y esto lleva tiempo.

Dnde es adecuado

Sistemas de gran tamao.

Proyectos donde sea importante el factor riesgo.

Cuando no sea posible definir al principio todos los requisitos.

Ciclos de vida orientados a objetos

Los tipos de ciclos de vida que se han visto hasta ahora son relativos al anlisis
y diseo estructurados, pero los objetos tienen una particularidad, y es que estn
basados en componentes que se relacionan entre ellos a travs de interfaces, o lo que
es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un
conjunto de miniproyectos. Adems, hoy en da la tendencia es a reducir los riesgos, y
en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades.

Debido a todo esto, el ciclo de vida tpico en una metodologa de diseo orientado a
objetos es iterativo e incremental.
En este texto slo veremos un tipo de ciclo de vida orientado a objetos, que es
adems el ms representativo, el modelo fuente.
Modelo fuente
Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de
vida pensado para la orientacin a objetos y posiblemente el ms seguido. Un
proyecto se divide en las fases:
1. Planificacin del negocio
2. Construccin: Es la ms importante y se divide a su vez en otras cinco
actividades
o

Planificacin

Investigacin

Especificacin

Implementacin

Revisin

3. Entrega
La primera y la tercera fase son independientes de la metodologa de desarrollo
orientado a objetos. Adems de las tres fases, existen dos periodos:
1. Crecimiento: Es el tiempo durante el cual se construye el sistema
2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se
planifica igual que el periodo anterior, es decir, con las fases de Planificacin
del negocio, Construccin y Entrega.
Cada clase puede tener un ciclo de vida slo para ella debido a que cada una
puede estar en una fase diferente en un momento cualquiera. La ventaja es que
permite un desarrollo solapado e iterativo. En la figura se muestra un esquema de
este tipo de ciclo de vida.

Ciclo de vida fuente

CONCLUSIN
Los mtodos de la ingeniera de software suministran el cmo construir
tcnicamente el software. Los mtodos abarcan un amplio espectro de tareas
que incluyen: planificacin y estimacin de proyectos, anlisis de los
requerimientos del sistema y del software, diseo de procedimientos
algortmicos, codificacin, prueba y mantenimiento. Los mtodos de la
ingeniera de software introducen frecuentemente una notacin especial
orientada al lenguaje o grfica y a un conjunto de criterios para la calidad del
software.
Las herramientas de ingeniera de software Suministran un soporte
automtico o semiautomtico para los mtodos. Cuando se integran las
herramientas de forma que la informacin creada por una herramienta pueda
ser usada por otra, se establece un sistema para el soporte del desarrollo del
software llamado ingeniera de software asistido por computadora, por
mencionar alguna de estas herramientas existen las herramientas CASE.
CASE[(Ingeniera de software asistida por computadora) computer aided
software engineering]. Combina del software, hardware y base de datos para
crear un entorno de la ingeniera de software. Las herramientas son como voy
a aplicar los mtodos para tener un desarrollo. Las herramientas de ingeniera
de software son los mtodos necesarios para desarrollar el sistema.

BIBLIOGRAFA

INTRODUCCIN A LA INGENIERA DE SOFTWARE

1. Definir Ingeniera de Software
http://www.buenastareas.com/ensayos/Ingenieria-DeSoftwqare/297859.html
http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-desoftware.php
2. Conocer el campo de aplicacin de la Ingeniera de Software.
http://www.intec.edu.do/carreras/ingenieria_grado/ingenieria_softwar
e.html
3. Explicar las actividades de la Ingeniera de Software
http://www.buenastareas.com/ensayos/Proceso-De-Ingenieria-DeSoftware/868654.html
http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-derequerimientos.php
PROCESOS ALTERNATIVOS
1. Breve introduccin de los enfoques: estructurado, orientado a objeto,
aplicaciones Web y UML.
http://www.mitecnologico.com/Main/ElEnfoqueOrientadoAObjetos
http://www.vico.org/TRAD_obert/TRAD_UML_abierto.html
http://www.alegsa.com.ar/Dic/aplicacion%20web.php
2. Tipos Modelo: Espiral, Cascada, Cascada con Prototpico, Por
Incremento, de Desarrollo de Software Unificado (USDP), Cluster y
Grady Booch.
http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.ht
ml