Las cinco etapas de ingeniera del software

Es necesaria la ingeniera del software ?

Desafortunadamente he visto muchos proyectos de software fallar estrepitosamente por
no seguir ninguna metodologa. Con muy buenas intenciones se empieza rpidamente a
construir con slo una idea aproximada de lo que se quiere desarrollar y con un plan an
ms impreciso de cmo hacerlo. Aplicar las etapas de la ingeniera del software
acostumbra ser una buena idea que te permite estructurar el producto y enfocar su
construccin con xito.
La ingeniera del software es el proceso formal de desarrollo de software en el que las
necesidades del usuario se traducen en requerimientos, estos se transforman en diseo
que se implementa en cdigo que se prueba, documenta y se certifica para su uso
operativo. Segn la definicin del IEEE la ingeniera del software se define como (1) la
aplicacin de un mtodo sistemtico, disciplinado y cuantificable al desarrollo, operacin y
mantenimiento de software, esto es, la aplicacin de la ingeniera al software y (2) el
estudio de los mtodos de (1)
1.

2.
3.

4.

5.

6.

El proceso requiere una metodologa con 5 etapas:

Anlisis de requerimientos: Se extraen los requisitos del producto de software. En
esta etapa la habilidad y experiencia en la ingeniera del software es crtica para
reconocer requisitos incompletos, ambiguos o contradictorios. Usualmente el
cliente/usuario tiene una visin incompleta/inexacta de lo que necesita y es necesario
ayudarle para obtener la visin completa de los requerimientos. El contenido de
comunicacin en esta etapa es muy intenso ya que el objetivo es eliminar la ambigedad
en la medida de lo posible.
Especificacin: Es la tarea de describir detalladamente el software a ser escrito, de
una forma rigurosa. Se describe el comportamiento esperado del software y su interaccin
con los usuarios y/o otros sistemas.
Diseo y arquitectura: Determinar como funcionar de forma general sin entrar en
detalles incorporando consideraciones de la implementacin tecnolgica, como el
hardware, la red, etc. Consiste en el diseo de los componentes del sistema que dan
respuesta a las funcionalidades descritas en la segunda etapa tambin conocidas como
las entidades de negocio. Generalmente se realiza en base a diagramas que permitan
describir las interacciones entre las entidades y su secuenciado.
Programacin: Se traduce el diseo a cdigo. Es la parte ms obvia del trabajo de
ingeniera de software y la primera en que se obtienen resultados tangibles. No
necesariamente es la etapa ms larga ni la ms compleja aunque una especificacin o
diseo incompletos/ambiguos pueden exigir que, tareas propias de las etapas anteriores
se tengan que realizarse en esta.
Prueba: Consiste en comprobar que el software responda/realice correctamente
las tareas indicadas en la especificacin. Es una buena praxis realizar pruebas a distintos
niveles (por ejemplo primero a nivel unitario y despus de forma integrada de cada
componente) y por equipos diferenciados del de desarrollo (pruebas cruzadas entre los
programadores o realizadas por un rea de test independiente).
Documentacin: Realizacin del manual de usuario, y posiblemente un manual
tcnico con el propsito de mantenimiento futuro y ampliaciones al sistema. Las tareas de
esta etapa se inician ya en el primera fase pero slo finalizan una vez terminadas las
pruebas.

7.

Mantenimiento: En esta etapa se realizan un mantenimiento correctivo (resolver

errores) y un mantenimiento evolutivo (mejorar la funcionalidades y/o dar respuesta a
nuevos requisitos).
Los ms atentos habis contado 7 en lugar de 5. No es un error. La sexta etapa,
documentar, se tiene que llevar a cabo absolutamente en todas y aunque no es una etapa
propiamente dicha pero es tan importante que debe ser mencionada explcitamente.
Por ltimo la etapa del mantenimiento, sobretodo para ampliar el sistema con nuevas
funciones, debe tener las sub-etapas 1 a 5 si se quiere abordar con garantas.

Qu es el software?
El software es la parte lgica e intangible de una computadora. Es decir es el conjunto de
los programas de cmputo, procedimientos, reglas, documentacin y datos asociados que
forman parte de las operaciones de un sistema de computacin como nos menciona el
IEEE.
Que tipos de software hay y como se clasifican?
Podemos encontrar distintos tipos de software, hay desde una clasificacin bsica hasta
una avanzada, por el momento veremos la bsica para no entrar demasiado en el tema e
ir a lo que queremos.
Software de sistema: Es el software que nos permite tener una interaccin con nuestro
hardware, es decir, es el sistema operativo. Dicho sistema es un conjunto de programas
que administran los recursos del hardware y proporciona una interfaz al usuario. Es el
software esencial para una computadora, sin el no podra funcionar, como ejemplo
tenemos a Windows, Linux, Mac OS X. Se clasifica en:

Sistemas operativos

Controladores de dispositivo

Herramientas de diagnstico

Herramientas de Correccin y Optimizacin

Servidores

Utilidades
Software de Programacin: Es un conjunto de aplicaciones que permiten a un
programador desarrollar sus propios programas informticos haciendo uso de sus
conocimientos lgicos y lenguajes de programacin. Algunos ejemplos:

Editores de texto

Compiladores

Intrpretes

Enlazadores

Depuradores

Entornos de Desarrollo Integrados (IDE)

Software de Aplicacin: Son los programas que nos permiten realizar tareas especificas
en nuestro sistema. A diferencia del software de sistema, el software de aplicacin esta
enfocada en un rea especifica para su utilizacin. La mayora de los programas que
utilizamos diariamente pertenecen a este tipo de software, ya que nos permiten realizar
diversos tipos de tareas en nuestro sistema.
Ejemplos:

>
Procesadores
de
texto.
(Bloc
de
Notas)
>
Editores.
(Photoshop
para
el
Diseo
Grfico)
>
Hojas
de
Clculo.
(MS
Excel)
>
Sistemas
gestores
de
bases
de
datos.
(MySQL)
>
Programas
de
comunicaciones.
(MSN
Messenger)
>
Paquetes
integrados.
(Ofimtica:
Word,
Excel,
PowerPoint)
> Programas de diseo asistido por computador. (AutoCAD)
Los clasificamos en:

Aplicaciones de Sistema de control y automatizacin industrial

Aplicaciones ofimticas

Software educativo

Software mdico

Software de Clculo Numrico

Software de Diseo Asistido (CAD)

Software de Control Numrico (CAM)

Evolucin del Software

El contexto en que se ha desarrollado el software est fuertemente ligado a las casi cinco
dcadas de evolucin de los sistemas informticos. Un mejor rendimiento del hardware,
una reduccin del tamao y un coste ms bajo, han dado lugar a sistemas informticos
ms sofisticados.
A continuacin se describire la evolucin del Software dentro del contexto de las reas de
aplicacin de los sistemas basados en computadoras.
Los primeros aos (1950 - 1965):
El software estaba en su infancia
El software era un aadido
Existan pocos mtodos para la programacin
No se tenia una planificacin para el desarrollo del software
Los programadores trataban de hacer las cosas bien
El software se diseaba a medida
El software era desarrollado y utilizado por la misma persona u organizacin
(entorno perzonalizado)
El diseo de software era realizado en la mente de alguien y no exista
documentacin
La segunda era (1965 - 1975):
Multiprogramacin y sistemas multiusuarios introducen nuevos conceptos de
interaccin hombre-mquina.
Sistemas de tiempo real que podan recoger, analizar y transformar datos de
mltiples fuentes.
Avances en los dispositivos de almacenamiento en lnea condujeron a la primera
generacin de sistemas de gestin de Base de Datos.
Software como producto y la llegada de las "casas de software" producindose as
una amplia distribucin en el mercado.
El software se desarrollaba para ser comercializado

Se empez a distribuir software para grandes computadoras y minicomputadores

El mantenimiento de software comenz a absorber recursos en una gran medida.

Comenz una crisis del software porque la naturaleza personalizada de los programas
hizo imposible su mantenimiento.
Conforme creca el nmero de sistemas informticos, comenzaron a extenderse las
bibliotecas de software de computadora. Las casas desarrollaban proyectos en que se
producan programas de decenas de miles de sentencias fuente. Los productos de
software comprados en el exterior incorporaban cientos de miles de nuevas sentencias.
Una nube negra apareci en el horizonte. Todos estos programas tenan que ser
corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos de
los usuarios o adaptados a nuevos dispositivos de hardware que se hubiera adquirido.
Estas actividades se llamaron colectivamente mantenimiento del software.
La tercera era (1975 - 1985):
Procesamiento Distribuido. Mltiple computadoras, cada una ejecutando funciones
concurrentes y comunicndose con alguna otra.
Redes de rea local y de rea global. Comunicaciones digitales de alto ancho de
banda y la creciente demanda de acceso "instantneo" a los datos.
Amplio uso de microprocesadores y computadoras personales (hardware de bajo
costo). Incorporacin de "inteligencia" (autos, hornos de microondas, robots
industriales y equipos de diagnstico de suero sanguneo). Impacto en el
consumo.
Planificacin en el proceso del desarrollo de software.
La cuarta era (1985 -2000):
Tecnologa orientada a objetos
Los sistemas expertos y la inteligencia artificial se han trasladado del laboratorio a
las aplicaciones prcticas.
Software para redes neuronales artificiales (simulacin de procesamiento de
informacin al estilo de como lo hacen los humanos).
Impacto colectivo del software
Sistemas operativos operativos sofisticados , en redes globales y locales
Aplicaciones de software avanzadas
Entorno cliente/cliente servidor
Superautopista de informacin y una conexin del ciberespacio
La industria del software es la cuna de la economa
Tcnicas de cuarta generacin para el desarrollo de software
Programacin de realidad virtual y sistemas multimedia
Algoritmos genticos
Adopcin de prcticas de Ingeniera del software

El Software
Software:
La descripcin de software en un libro de texto podra tomar la forma siguiente:

(1) instrucciones que cuando se ejecutan proporcionan la funcin y el rendimiento

deseados,
(2) estructuras de datos que permiten a los programas manipular adecuadamente la
informacin, y
(3) documentos que describen la operacin y el uso de programas.
Pero, el software se ha convertido en el elemento clave de la evolucin de los sistemas y
productos informticos, y por tal razn no se puede tomar como slo el conjunto de
programas, instrucciones y estructuras de datos.
El software se ha convertido en algo fundamental para la sociedad. Es el motor que
conduce a la toma de decisiones comerciales. Sirve como la base de investigacin
cientfica moderna y de resolucin de problemas de ingeniera. Es el factor clave que
diferencia los productos y servicios modernos. Est inmerso en sistemas de todo tipo: de
transportes, mdicos, de telecomunicaciones, militares, procesos industriales,
entretenimiento, productos de oficina, etc. El software ser el que nos lleve de la mano en
los avances en todo desde la educacin elemental a la Ingeniera Gentica.

Caractersticas del software

Para poder comprender lo que es el software y consecuentemente la ingeniera del
software, es importante examinar las caractersticas del software que lo diferencian de
otras cosas que los hombres pueden construir. El software es un elemento del sistema
que es lgico, en lugar de fsico. Por tanto, el software tiene unas caractersticas
considerablemente distintas a las del hardware:

El software se desarrolla, no se fabrica en un sentido clsico: se utiliza un modelo

de proceso de desarrollo que comprende anlisis, diseo, desarrollo,
implementacin y evaluacin para obtener un producto de calidad.

El software no se "estropea", pero se deteriora: El software durante su vida sufre

cambios por lo que es probable que surjan fallos y defectos que si no se corrigen
permiten que el software se vaya deteriorando.

La mayora del software se construye a medida, en vez de ensamblar

componentes existentes: a medida que el software evoluciona se crean estdares
de diseo.

La reusabilidad es una caracterstica importante para un componente de software

de alta calidad. Es decir, el componente debe disearse e implementarse para que
pueda volver a usarse en muchos programas diferentes

Aplicaciones del software

Para determinar la naturaleza de una aplicacin de software, hay dos factores importantes
que se deben considerar: el contenido y el determinstico de la informacin.
El contenido se refiere al significado y a la forma de la informacin de entrada y salida.
El determinstico de la informacin se refiere a la predecibilidad del orden y del tiempo de
llegada de los datos.

Las siguientes reas del software indican una amplitud de las posibilidades de aplicacin.

Software de sistemas. Es un conjunto de programas que han sido escritos para

servir a otros programas. Por ejemplo, compiladores, sistemas operativos.

Software de tiempo real. Es el software que mide/analiza/controla sucesos del

mundo real conforme ocurren.

Software de gestin. Gestin de grandes cantidades de informacin almacenadas,

para facilitar la toma de decisiones. Constituye la mayor rea de aplicacin del
software. Los sistemas "discretos" (ejemplo: nminas, cuentas de haberes/dbitos,
inventarios, etc.) han evolucionado hacia el software de sistemas de informacin
de gestin (SIG), que acceden a una o ms bases de datos grande que contienen
informacin comercial.

Software de ingeniera y cientfico. Utiliza algoritmos de manejo de nmeros,

simulacin de sistemas, utiliza software en tiempo real. Por ejemplo: aplicaciones
de astronoma, vulcanologa, fabricacin automtica.

Software empotrado. Reside en la memoria de slo lectura y se utiliza para

controlar productos y sistemas de los mercados industriales y de consumo. Por
ejemplo, el control de las teclas de un horno de microondas, funciones digitales en
un automvil.

Software de computadoras personales. Aplicaciones orientadas a usuarios

individuales o multiusuarios. Por ejemplo: procesadores de texto, hojas de clculo,
juegos, aplicaciones financieras, gestores de bases de datos.

Software de inteligencia artificial. Hace uso de algoritmos no numricos para

resolver problemas complejos para los que no son adecuados el clculo o el
anlisis directo. Actualmente el rea ms activa es la de los sistemas expertos o
sistemas basados en el conocimiento.

Los sistemas de informacin son de gran importancia para el soporte de los procesos de
una organizacin. El disponer de un sistema que ayude a mejorar su desempeo, reducir
errores, automatizar tareas y que adems, proporcione en tiempo y forma la informacin
necesaria para la correcta toma de decisiones, se convierte en una estrategia til para
que las organizaciones hagan frente a sus diversos competidores. Sin embargo, para que
un sistema funcione eficientemente, en la mayora de los casos debe ser un desarrollo a
la medida que cubra con todas las necesidades de la organizacin en la cual ser usado,
o pasar por un proceso de adaptacin de algn producto previamente liberado, tarea que
nunca resulta sencilla o econmica.
Para desarrollar un sistema, se requiere llevar a cabo el anlisis de los requisitos (que
corresponde a la primera etapa del proceso de desarrollo de software), para definir las
actividades que se desempean dentro de la organizacin y obtener las funcionalidades
de software que el sistema debe cubrir. El anlisis de requisitos es probablemente la
etapa ms importante del proceso de desarrollo, puesto que de las decisiones tomadas en
esta etapa dependern las funcionalidades que el sistema a desarrollar deber cumplir o
no. Su objetivo es obtener un conjunto de requisitos de sistema que sean completos,
consistentes, relevantes y que refleje lo que la organizacin realmente necesita. Una
correcta definicin de los requisitos permite que el sistema llegue finalmente a ser exitoso
desde los puntos de vista de los objetivos de la organizacin, costos, funcionalidad,
sencillez y capacidad de soporte.
El anlisis de requisitos se puede llevar a cabo mediante tcnicas tradicionales como
entrevistas, talleres, prototipos etc. Sin embargo, existen un sin nmero de dificultades
que se pueden presentar en este proceso, ocasionando que a pesar de los esfuerzos
realizados por los analistas un alto porcentaje de los sistemas no llegan a cubrir al 100 por
ciento las necesidades de la organizacin. En primera instancia se requiere de
la habilidad de los analistas para especificar correctamente los requisitos de un sistema,
puesto que las metas de la organizacin pueden no ser explcitas, difciles de comprender
y presentar contradicciones o ambigedades. Asimismo, el analista tiene la tarea de
involucrar en el anlisis a todas las partes interesadas (la organizacin en s, directivos y

usuarios finales por ejemplo) y sus necesidades para que se obtengan y depuren sus
requisitos de la forma ms fidedigna posible. De manera general la baja eficiencia del
sistema final es causado ya sea por no llevar a cabo el anlisis de requisitos
adecuadamente, o porque las tcnicas tradicionales no permiten profundizar lo suficiente
para determinar las funcionalidades que el sistema debe cubrir.
Esta situacin aunada al constante aumento de la complejidad de los sistemas de
software conlleva a la necesidad de evolucionar las tcnicas del anlisis de requisitos y
del desarrollo de software en s.
Grupos de investigacin en el rea de la ingeniera de software han propuesto dividir la
etapa de anlisis de requisitos en dos subetapas: la etapa de requisitos tempranos
(requisitos relacionados con la organizacin) y la etapa de requisitos tardos (requisitos
relacionados con el sistema). La etapa de requisitos tardos tiene el objetivo de producir el
documento de especificacin de requisitos que se entrega a los desarrolladores para que
el sistema entre en produccin. Por otro lado, la etapa de requisitos tempranos tiene como
objetivo entender el contexto organizacional (entendimiento profundo de la organizacin) y
fundamentar los por qu? que conducen a los requisitos del sistema, antes que contar
con una especificacin detallada de lo que el sistema deber hacer. Se basa en
actividades que consideran cmo el sistema a desarrollar podr satisfacer las metas de
la organizacin?, por qu se necesita el sistema?, qu alternativas existen?, cules
son las implicaciones de las alternativas para las partes interesadas? y cmo pueden
abordarse los intereses de las partes interesadas? El estudio del contexto organizacional
en el que se implantar el sistema ha sido reconocido como una parte fundamental de la
ingeniera de requisitos debido a que se buscan mecanismos que permitan establecer la
relacin entre la funcionalidad esperada de un sistema de software y los procesos
organizacionales a los que ste dar soporte.
Mediante la puesta en marcha de esta etapa, se reduce la brecha conceptual entre lo que
el sistema debe hacer y por qu, y lo que los usuarios que interactan con el sistema
deben hacer y por qu, proporcionando as (en parte) la flexibilidad adicional necesaria
para hacer frente a la complejidad de los sistemas de software actuales. El conocimiento
obtenido de la etapa de anlisis de requisitos tempranos puede ser representado
mediante el uso de tcnicas de modelo organizacional. El Framework i* [1] (i estrella) es
una de las tcnicas de modelado organizacional mejor fundamentada y utilizada que
utiliza relaciones estratgicas para modelar el contexto social e intencional de una
organizacin y proporciona un lenguaje que soporta la descripcin de redes
organizacionales formadas de actores sociales con libertad de accin, pero que tambin
dependen de otros actores para alcanzar sus objetivos y metas. Adems de tcnicas de
modelado, se han propuesto metodologas que ofrecen enfoques para relacionar los
conceptos del dominio de la organizacin (modelos organizacionales) a los

correspondientes conceptos del dominio de la solucin (modelos conceptuales, como

diagramas de clases de UML, ontologas) de manera que se mapee correctamente las
necesidades de la organizacin con las funcionalidades a cubrir por el sistema. Estas
metodologas propician la unin del modelado organizacional con las especificaciones de
software mejorando el proceso de desarrollo. Por ejemplo:

Tropos [2] es una metodologa para el desarrollo de sistemas orientados a agentes

basada en i*. Se enfoca particularmente al anlisis del ambiente en el que operar
el sistema a desarrollar, apoyndose en la idea de construir un modelo del
ambiente organizacional y del sistema. La metodologa gua la construccin de un
modelo conceptual, mismo que es refinado y extendido durante las distintas
etapas de desarrollo, desde la etapa de requisitos tempranos hasta la
implementacin.

Conceptual Schemas Generation from Organizational Models in an Automatic

Software Production Process [3] es una metodologa para la construccin de
modelos conceptuales (casos de uso y diagramas de clases UML) a partir de
modelos organizacionales representados con Tropos. Presenta un proceso de
desarrollo de software automtico mediante el uso del OO-Method (un mtodo de
produccin de software que genera automticamente un sistema orientado a
objetos completo a partir de modelos de casos de uso y diagramas de clases
UML).

TAGOOn [4] es una metodologa basada en una herramienta de software que

permite la transformacin automtica de modelos organizacionales en ontologas
organizacionales mismas que pueden ser adaptadas a plataformas de desarrollo
de software automtico como SemanticWebBuilder [5], una plataforma para la
generacin automtica de aplicaciones y portales web semnticos a partir de
modelos ontolgicos desarrollada en INFOTEC (Centro de Investigacin en TICs
del CONACYT).

En conclusin, el desarrollo de software ha pasado de ser una actividad solamente de los

analistas de requisitos de sistemas, a ser un trabajo en conjunto con los analistas
organizacionales y los usuarios y operadores de los sistemas mismos. Esta prctica se
encuentra en aumento, gracias a las ventajas que ofrece en el mbito de anlisis de
requisitos, como la generacin de especificaciones coherentes y sin ambigedades o
contradicciones que reflejan las necesidades de la organizacin. Adems de
proporcionar una descripcin formal de la organizacin y de los requisitos de software que
propician la generacin automtica de software mediante modelos conceptuales.

Beneficios del Desarrollo de Software basado en Componentes

En esencia, un componente es una pieza de cdigo preelaborado que encapsula alguna
funcionalidad expuesta a travs de interfaces estndar (1) . Los componentes son los
"ingredientes de las aplicaciones", que se juntan y combinan para llevar a cabo una
tarea (2) . Es algo muy similar a lo que podemos observar en el equipo de msica que
tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseado para
acoplarse perfectamente con sus pares, las conexiones son estndar y el protocolo de
comunicacin est ya preestablecido. Al unirse las partes, obtenemos msica para
nuestros odos.
El paradigma de ensamblar componentes y escribir cdigo para hacer que estos
componentes funcionen se conoce como Desarrollo de Software Basado en
Componentes. El uso de este paradigma posee algunas ventajas:
1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de
software.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada
uno de los componentes antes de probar el conjunto completo de componentes
ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento
entre componentes, el desarrollador es libre de actualizar y/o agregar
componentes segn sea necesario, sin afectar otras partes del sistema.
4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organizacin, la calidad de una aplicacin basada
en componentes mejorar con el paso del tiempo.
De la misma manera, el optar por comprar componentes de terceros en lugar de
desarrollarlos, posee algunas ventajas:
1. Ciclos de desarrollo ms cortos. La adicin de una pieza dada de funcionalidad
tomar das en lugar de meses aos.
2. Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversin
puede ser ms favorable que desarrollando los componentes uno mismo.
3. Funcionalidad mejorada. Para usar un componente que contenga una pieza de
funcionalidad, solo se necesita entender su naturaleza, ms no sus detalles
internos. As, una funcionalidad que sera imprctica de implementar en la
empresa, se vuelve ahora completamente asequible.

Modelos de Desarrollo de Software[editar]

Los modelos de desarrollo de software son una representacin abstracta de una manera
en particular. Realmente no representa cmo se debe desarrollar el software, sino de un
enfoque comn. Puede ser modificado y adaptado de acuerdo a las necesidades del
software en proceso de desarrollo. 1 Hay varios modelos para perfilar el proceso de
desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debera escoger
el ms apropiado para sus necesidades. En ocasiones puede que una combinacin de
varios modelos sea apropiado. Existen tres paradigmas de los modelos de desarrollo de
software:
1. Paradigma Tradicional:
Es uno de los paradigmas ms antiguo, se invent durante la creacin del mtodo
estructurado. Si se elige un proyecto, el mtodo varia en etapas. Como todo modelo,
existen sus pros y contras al usar este paradigmas:

Si se aplica este paradigma, unos de los principales problemas , es que las etapas
realizadas no son autnomas de las siguientes, creando una dependencia estructural y en
el acaso de un error atrasara todo el proyecto. Se tiene que tener pautas bien definidas, y
que no se incurra a modificacin porque implicara en que el software no cumpla con su
ciclo de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia.
2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programacin orientada
a objetos; por lo tanto, se refiere al concepto de clase, el anlisis de requisitos y el diseo.
El modelo o paradigma orientado a objetos posee dos caractersticas principales, las
cuales son:

Permite la re-utilizacin de software.

Facilita el desarrollo de herramientas informticas de apoyo al desarrollo, el cual
es simple al implementarla en una notacin orientado a objetos llamadoUML.

3. Paradigma de Desarrollo gil: Es un paradigma de las Metodologas De

Desarrollo basado en procesos giles. Estos intentan evitar los tediosos caminos de las
metodologas tradicionales enfocndose en las personas y los resultados. Usa un enfoque
basado en el Valor para construir software, colaborando con el cliente e incorporando los
cambios continuamente.
Modelo de cascada
Artculo principal: Desarrollo en cascada
El modelo de cascada define las siguientes etapas que deben cumplirse de forma
sucesiva:
1. Especificacin de requisitos
2. Diseo del software
3. Construccin o Implementacin del software
4. Integracin
5. Pruebas (o validacin)
6. Despliegue (o instalacin)
7. Mantenimiento
Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase,
comienza la otra. En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo
que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal
de cambio). Las revisiones tambin se utilizan para asegurar que la fase anterior ha sido
totalmente finalizada; los criterios para completar una fase se conocen frecuentemente
con el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar y revisar fases
que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha
sido fuente de crtica de los defensores de modelos ms flexibles.
Modelo de espiral[editar]
Artculo principal: Desarrollo en espiral

La principal caracterstica del modelo en espiral es la gestin de riesgos de forma

peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 porBarry Boehm,
combinando algunos aspectos clave de las metodologas del modelo de cascada y
del desarrollo rpido de aplicaciones, pero dando nfasis en un rea que para muchos no
jug el papel que requiere en otros modelos: un anlisis iterativo y concienzudo de los
riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a travs de algunas interaciones con el
diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
1. crear planes con el propsito de identificar los objetivos del software,
seleccionados para implementar el programa y clarificar las restricciones en el
desarrollo del software;
2. Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para
evaluar como identificar y eliminar el riesgo;
3. la implementacin del proyecto: implementacin del desarrollo del software y su
pertinente verificacin;
Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las
opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software
puede ayudar como una meta propia en la integracin en el desarrollo del producto. Sin
embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
1. El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que
acepten este anlisis y acten en consecuencia. Para ello es necesaria confianza
en los desarrolladores as como la predisposicin a gastar ms para solventar los
temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de
software a gran escala.
2. Si la implementacin del riesgo de anlisis afectar de forma esencial los
beneficios del proyecto, no debera utilizarse este modelo.
3. Los desarrolladores de software han de buscar de forma explcita riesgos y
analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la bsqueda de un plan para conseguir los objetivos con las
limitaciones del proyecto para as buscar y eliminar todos los riesgos potenciales por
medio de un cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un
prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es
conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por ltimo, se
evalan los resultados y se inicia el diseo de la siguiente fase.

Desarrollo iterativo e incremental

Artculo principal: Desarrollo iterativo e incremental
El desarrollo iterativo recomienda la construccin de secciones reducidas de software que
irn ganando en tamao para facilitar as la deteccin de problemas de importancia antes
de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del
diseo en el caso de clientes que no saben cmo definir lo que quieren
Desarrollo gil[editar]
Artculo principal: Desarrollo gil de software
El desarrollo gil de software utiliza un desarrollo iterativo como base para abogar por un
punto de vista ms ligero y ms centrado en las personas que en el caso de las
soluciones tradicionales. Los procesos giles utilizan retroalimentacin en lugar de
planificacin, como principal mecanismo de control. La retroalimentacin se canaliza por
medio de pruebas peridicas y frecuentes versiones del software.
Hay muchas variantes de los procesos giles:
En el caso de la programacin extrema (XP), las fases se realizan en pasos muy cortos (o
"continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los
pasos puede ocurrir en un da o en una semana, en lugar de los meses o aos de cada
paso completo en el modelo en cascada. En primer lugar, se crean pruebas
automatizadas para proveer metas concretas al desarrollo. Despus se programa el
cdigo, que ser completo cuando todas las pruebas se superan sin errores, y los
desarrolladores ya no sabran como mejorar el conjunto de pruebas necesario. El diseo y
la arquitectura emergen a partir de la refactorizacin del cdigo, y se da despus de
programar. El diseo lo realizan los propios desarrolladores del cdigo. El sistema,
incompleto, pero funcional se despliega para su demostracin a los usuarios (al menos
uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los
profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de ms
importancia.
Codificacin y correccin
El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms que una
estrategia predeterminada, el resultado de una falta de experiencia o presin que se
ejerce sobre los desarrolladores para cumplir con una fecha de entrega. 7 Sin dedicar
tiempo de forma explcita para el diseo, los programadores comienzan de forma
inmediata a producir cdigo. Antes o despus comienza la fase de pruebas de software (a
menudo de forma tarda) y los inevitables errores que se encuentran han de eliminarse
antes de poder entregar el software.

Orientado a la Reutilizacin
La reutilizacin de software es un proceso donde se recurre al uso de activos de software
en las especificaciones de anlisis, diseos, implementacin y pruebas de una aplicacin
o sistemas de software.8

La reutilizacin tiene ciertos Indicadores por ejemplo:

1. Entre el 40% y 60% de una aplicacin es re-utilizable en otra.
2. Aproximadamente el 60% de una aplicacin administrativa es re-utilizable.
3. Aproximadamente el 75% de las funciones son comunes a ms de un programa.
4. Solo el 15% del cdigo encontrado en muchos sistemas es nico y novedoso a una
aplicacin especifica.
El rango general de uso recurrente esta entre el 15% y 85%.
La reutilizacin tiene Principios como la existencia de parecidos en distintos sistemas de
un mismo dominio, donde el software puede representarse como una combinacin de
mdulos y los sistemas nuevos se puede caracterizar por diferencias respecto a los
antiguos sistemas.

http://es.slideshare.net/anyermil/como-ha-ido-evolucionando-el-software
http://es.slideshare.net/kellypt1/modelos-de-desarrollo-de-software
https://www.youtube.com/watch?v=olbePnesRPM