INGENIERIA DE SOFTWARE

Qu es la Ingeniera del Software?

La Ingeniera del software es una disciplina o rea de la Informtica o Ciencias de la Computacin, que ofrece
mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo.
La ingeniera de software tambin se puede ver como el campo de la tecnologa que est relacionada con la
aplicacin de unos enfoques tericos para el desarrollo, operacin y mantenimiento de software. No slo se
refiere al conocimiento simple y estereotipado de tan slo escribir cdigo para los programas, pero tambin es el
estudio de cmo estos enfoques funcionan realmente en el mundo real en base a diferentes factores y la
ingeniera en consecuencia para alcanzar los objetivos deseados. Ingeniera de Software es generalmente
considerada como un campo secundario de Informtica, ya que muchos de sus fundamentos proceden de la
informtica. En trminos simples, la ingeniera de software es el software de creacin que es de mayor calidad,
ms asequible, fcil de mantener, y ms rpido de construir.
Hoy da es cada vez ms frecuente la consideracin de la Ingeniera del Software como una 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, ya, reconocida consideracin
social en el mundo empresarial y, por suerte, para esas personas con brillante futuro.
La ingeniera del software trata con reas muy diversas de la Informtica y de las Ciencias de la Computacin,
tales como construccin de compiladores, sistemas operativos o desarrollos de Intranet/Internet, abordando
todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de informacin y aplicables a una
infinidad de reas tales como: negocios, investigacin cientfica, medicina, produccin, logstica, banca, Control
de trfico, meteorologa, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc. [12]

Definicin del termino Ingeniera del Software

El trmino Ingeniera se define en el Diccionario de la Real Academia Espaola de la Lengua como:

"1. Conjunto de conocimientos y tcnicas que permiten aplicar el saber cientfico a la utilizacin de la materia y
de las fuentes de energa.
2. Profesin y ejercicio del Ingeniero" y el termino Ingeniero se define como: Persona que profesa o ejerce la
Ingeniera. De igual modo la Real Academia de Ciencias Exactas, Fsicas y Naturales de Espaa define el
termino Ingeniera como: " Un conjunto de conocimientos y tcnicas cuya aplicacin permite la utilizacin
racional de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras
realizaciones provechosas para el hombre".
Evidentemente, si la Ingeniera del Software es una nueva Ingeniera, parece lgico que rena las propiedades
citadas en las definiciones anteriores. Sin embargo ni el DRAE(Diccionario de la Real Academia Espaola de la
Lengua), ni la Real Academia Espaola de Ciencias han incluido todava el termino en sus ltimas ediciones; en
consecuencia vamos a recurrir para su definicin ms precisa a algunos de los autores ms acreditados que
comenzaron en su momento a utilizar el trmino o bien en las definiciones dadas por organismos
internacionales profesionales de prestigio tales como IEEE o ACM, de los cuales se han seleccionado las
siguientes definiciones de Ingeniera del Software.

Definicin 1: Zelkovitz. Principles of Software Engineering and Design.

Ingeniera del software es el estudio de los principios y metodologas para desarrollo y mantenimiento de
sistemas de software.

Definicin 2: Boehm. Software Engineering.

Ingeniera del software es la aplicacin prctica del conocimiento cientfico en el diseo y construccin de
programas de computadora y la documentacin asociada requerida para desarrollar, operar y mantenerlos.

Definicin 3: Bauer. Software Engineering.

Ingeniera del software trata del establecimiento de los principios y mtodos de la ingeniera a fin de
obtener software de modo rentable que sea fiable y trabaje en mquinas reales.

Definicin 4: Pressman. Ingeniera del Software.

La Ingeniera de/l software es una disciplina o rea de la informtica o Ciencias de la Computacin, que
ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo
tipo.

Definicin 5: Braude. Ingeniera de Software.

La ingeniera de software es el proceso de construir aplicaciones de tamao o alcance prcticos, en las que
predomina el esfuerzo del software y que satisfacen los requerimientos de funcionalidad y desempeo.

Definicin 6: IEEE.

La aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y

mantenimiento del software; es decir, la aplicacin de ingeniera al software.

Para qu sirve?

Los ingenieros de software se aplican los principios y tcnicas de la informtica, la ingeniera y el anlisis
matemtico para el diseo, desarrollo, prueba y evaluacin del software y los sistemas que permiten a las
computadoras para realizar sus muchas aplicaciones.
Los ingenieros de software estn involucrados en el diseo y desarrollo de muchos tipos de software,
incluyendo software para sistemas operativos y distribucin de la red, y software para los compiladores (que
convierten los programas para su ejecucin en un ordenador). En la programacin, o la codificacin, los
ingenieros de software indican a un ordenador, lnea por lnea, cmo realizar una funcin deseada. Los
ingenieros de software deben poseer habilidades de programacin fuertes, pero son a menudo ms preocupados
por el desarrollo de algoritmos y anlisis y solucin de problemas de programacin que con escribir cdigo.
Normalmente, los ingenieros de software, trabajando en el desarrollo de aplicaciones o sistemas, analizar en
primer lugar las necesidades del usuario. A continuacin, disear, construir, probar y mantener el software de las
aplicaciones informticas o sistemas para satisfacer estas necesidades.

Cul es su importancia?

La ingeniera de software y la informtica han jugado un papel importante en las innovaciones ms recientes
que han cambiado la forma en que vivimos: la cohetera, el Internet, los celulares, los motores de bsqueda, las

aerolneas, etc. De hecho, el 92 por ciento de las compaas de software ms grandes basadas en los Estados
Unidos desde el 2013 tenan un co-fundador tcnico. Cualquier pas que espera seguir siendo competitivo debe
tener grandes ingenieros de software.
Por lo tanto, la ingeniera de software es un aspecto importante de la tecnologa y que traer cambios
significativos y, al mismo tiempo, ser un factor importante en perodos de desarrollo futuro del mundo.
GESTIN DE PROYECTOS INFORMTICOS
Antes de comenzar el desarrollo de un proyecto hay que tener en cuenta y estudiar todas y cada una de las fases
por las que pasa. Segn el PMBOK, Las fases del proyecto son divisiones dentro del mismo proyecto, donde
es necesario ejercer un control adicional para gestionar eficazmente la conclusin de un entregable mayor
En este captulo vamos a redactar una descripcin bsica de las diferentes fases de un proyecto. Sin entrar en
discusin con las diferentes metodologas que existen actualmente, nosotros preferimos simplificar la
explicacin al lector diciendo que en la mayora de los proyectos se pueden distinguir tres grandes secciones de
trabajo: planeacin, ejecucin y mantenimiento. [13]

Tal como se muestra en la figura, la planeacin es donde est la fase de definicin del proyecto y donde entra la
planificacin del proyecto.

Planeacin Definicin del problema.

Planificacin del proyecto.

La ejecucin es donde se trata la puesta en marcha, la fase productiva y la conclusin del proyecto.

Ejecucin del proyecto

Puesta en marcha.
Fase productiva.
Conclusin del proyecto.

Una vez realizado y entregado el proyecto, se inicializa la fase de Mantenimiento, que trae caractersticas
propias del proyecto y el entorno en el que fue implantado.

Planeacin

En la planeacin de un proyecto es importante tener claro tanto el problema que se pretende solucionar, el
producto que se quiere obtener, como el servicio que se pretende proporcionar. A su vez es necesario evaluar
tanto los costes econmicos como los recursos humanos.
Fases de la planeacin:
Inicio y Definicin del Problema, es decir, clarificar el producto o servicio a obtener.
Planificacin del Proyecto; atender a las necesidades que aparecern a lo largo del desarrollo, anticipando el
curso de las tareas a realizar, la secuencia en que se llevarn a cabo, los recursos y el momento en que sern
necesarios.

Inicio y Definicin del problema

El origen de un proyecto suele surgir a partir de una necesidad que se convierte en un problema. En este
punto hay que trabajar con los usuarios, directores de empresa y clientes, ya que ser de ellos de quien
tendremos que obtener la informacin para saber donde reside el problema y donde est la oportunidad.
A la definicin del problema muchas veces no se le da la importancia que se merece.
Hay que tener en cuenta que todo el proyecto se basar en esta definicin y es mejor que quede clara.
Debe ser revisada por todos los usuarios, directores de empresa y clientes. En esta fase se definen, entre
otras cosas, los lmites del proyecto.

Planificacin del Proyecto

En esta fase se debern identificar todas las cosas necesarias para poder alcanzar el objetivo marcado,
considerando las tres dimensiones sobre los que se apoyar el desarrollo de todo el proyecto:

Calidad: viene dada por las especificaciones.

Coste, valorado en el presupuesto.
Duracin: asignada en el calendario de trabajo.

Hay quien separa el anlisis de la aplicacin de la

propia planificacin, por entenderse que la
primera es una tarea tcnica, mientras que la
planificacin es una tarea de gestin. Aun siendo
as, tienen que realizarse de forma simultnea.
Hay que planificar el trabajo antes de llevarlo a
cabo, antes de realizar el anlisis de los trabajos
asociados a ste, pero difcilmente se podr realizar la planificacin de todo el proyecto.

Tareas a realizar en la etapa definicin del problema:

Estimar el tamao de la aplicacin a desarrollar. Estudiar el sistema actual.

Discutir y analizar lo que se desea obtener.

Identificar las tareas a realizar.

Asignar recursos a cada tarea.
Crear un calendario de las tareas.
Realizar un estudio econmico.

Ejecucin

En la ejecucin de un proyecto, se trata de llevar a cabo el plan previo. La ejecucin se ver fuertemente
influida por la planificacin, es decir, una mala planificacin supondr una mala ejecucin.
Fases de la ejecucin:
Puesta en marcha.
Fase productiva.
Conclusin del proyecto. Esta fase es explicada detalladamente en el captulo IV del libro.

Puesta en marcha

En esta fase se ha de organizar el equipo de desarrollo, los mecanismos de comunicacin, la asignacin de roles
y de responsabilidades a cada persona.
Las principales tareas son:
Ajustar a las disponibilidades actuales las necesidades de personal de la fase de planificacin.
Establecimiento de la estructura organizativa.
Definir responsabilidades y autoridad.
Organizar el lugar de trabajo. En muchas ocasiones el comienzo de un proyecto tiene tareas como
instalacin de equipamientos, acondicionamiento de locales, etc.
Puesta en funcionamiento del equipo. Organizar reuniones ms o menos informales para que se
conozcan las personas del equipo en el caso de que esto no sea as; esto evitar malentendidos y
conflictos durante la ejecucin del proyecto.
Divulgacin de los estndares de trabajo y sistemas de informes. Al comenzar el proyecto, las personas
estn ms receptivas y esta es una razn para introducir los nuevos mtodos de trabajo.

Ajustar Proyecto

Es estratgico ajustar los requisitos, recursos y personas a las disponibilidades actuales para evitar
inconvenientes y desperdicios de recurso en la Fase Productiva.

Fase productiva

En esta fase se realiza la actividad gruesa del proyecto. En la misma se realizarn actividades de anlisis,
diseo, implementacin y pruebas. Todo el equipo de trabajo asignado al proyecto estar abocado a las
diferentes actividades designadas.
En esta fase productiva ya no debera existir alguna duda respecto a las especificaciones, recursos y personas en
situacin de trabajo. stas deben llevar a cabo cada una de las tareas que se les ha asignado. Aunque esta ltima

frase es correcta, tambin lo es saber que existen riesgos en todos los proyectos, por lo tanto, es muy importante
hacer un seguimiento del mismo y actuar rpidamente ante cada evento que pueda alterar el curso normal del
proyecto.
El responsable del proyecto debe tomar medidas de rendimiento, revisar los informes de los empleados,
mantener reuniones para identificar los problemas antes de que aparezcan y en este caso poner en prctica las
acciones correctivas y preventivas necesarias.

Conclusin del Proyecto

En esta fase se trata de dar por finalizado el proyecto y entregar el producto definitivamente al cliente.
Las principales actividades a realizar son stas:

Revisar las desviaciones del proyecto e identificarlas para evitarlas en futuros proyectos.
Reasignar el personal a los nuevos proyectos o reintegrarlos en los departamentos de partida.
Es interesante documentar las relaciones entre los empleados para futuros proyectos.

Fase de Mantenimiento

Es el proceso de mejora y optimizacin del software despus de su entrega al usuario final (es decir; revisin
del programa), as como tambin la correccin y prevencin de los defectos.

Mtricas de software

Los factores que perturban la calidad del software se pueden categorizar en dos grandes grupos: (1) factores que
se pueden medir directamente (por ejemplo: defectos por puntos de funcin) y (2) factores que se pueden medir
slo indirectamente (por ejemplo: facilidad de uso o de mantenimiento).
McCall y sus colegas plantearon una categorizacin de factores que afectan a la calidad de software, que se
muestran en la figura 4.1 en donde se centralizan con tres aspectos importantes de un producto de software: sus
caractersticas operativas, su capacidad de cambio y su adaptabilidad a nuevos entornos.
Refirindose a los factores de la figura 4.1, McCall proporciona las siguientes descripciones: [14]
-Correccin: Hasta dnde satisface un programa su especificacin y consigue los objetivos de la misin del
cliente.
-Fiabilidad: Hasta dnde puede quedarse un programa que lleve a cabo su funcin pretendida con la exactitud
solicitada. Cabe hacer notar que se han propuesto otras definiciones de fiabilidad ms completas.

,
Correccin Fiabilidad Usabilidad (facilidad Integridad Eficiencia de manejo)

Figura 4.1 Factores que afectan a la calidad del software [Pressman98]

-Eficiencia: El conjunto de recursos informticos y de cdigo necesarios para que un programa realice su
funcin.
-Integridad: Hasta dnde se puede controlar el acceso al software o a los datos por individuos no autorizados.

Usabilidad (facilidad de manejo): El esfuerzo necesario para aprender, operar, y preparar datos de entrada e
interpretar las salidas (resultados) de un programa.
Facilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar un error en un programa.
Flexibilidad: El esfuerzo necesario para modificar un programa operativo.
Facilidad de prueba: El esfuerzo necesario para aprobar un programa para asegurarse de que realiza su
funcin pretendida.
Portabilidad: El esfuerzo necesario para trasladar el programa de un entorno de sistema hardware y/o
software a otro.
Reusabilidad: (capacidad de reutilizacin): Hasta dnde se puede volver a utilizar un programa (o
partes) en otras aplicaciones con relacin al empaquetamiento y alcance de las funciones que ejecuta el
programa.
Interoperabilidad: El esfuerzo necesario para acoplar un sistema con otro.

Es difcil y en algunos casos improbables, desarrollar medidas directas de los factores de calidad anteriores. Es
por eso, que se definen y emplean un conjunto de mtricas para desarrollar expresiones para todos los factores
de acuerdo con la siguiente relacin:
Fq = c1 * m1 + c2 * m2 + + cn * mn

(4.6)

Donde Fq es un factor de calidad del software, cn son coeficientes de regresin y mn son las mtricas que
afectan al factor de calidad. Lo malo es que las mtricas definidas por McCall slo pueden medirse de manera
subjetiva. Las mtricas van en lista de comprobacin que se emplean para apuntar atributos especficos del
software. El esquema de puntuacin presentado por McCall es una escala del 0 (bajo) al 10 (alto) En donde se
emplean las siguientes mtricas en el esquema de puntuacin:
Facilidad de auditoria: La facilidad con la que se puede justificar el cumplimiento de los estndares.

 Exactitud: La exactitud de los clculos y del control.

Estandarizacin de comunicaciones: El nivel de empleo de estndares de interfaces, protocolos y anchos
de banda.
Complexin: El grado con que s a logrado la implementacin total de una funcin.
Concisin: Lo compacto que resulta ser el programa en trminos de lneas de cdigo.
Consistencia: El uso de un diseo uniforme y de tcnicas de documentacin a travs del proyecto de
desarrollo del software.
Estandarizacin de datos: El empleo de estructuras y tipos de datos estndares a lo largo del programa.
Tolerancia al error: El deterioro causado cuando un programa descubre un error.
Eficiencia de ejecucin: El rendimiento del funcionamiento de un programa.
Capacidad de expansin. El grado con que se pueden aumentar el diseo arquitectnico, de datos o
procedimental.
Generalidad: La extensin de aplicacin potencial de los componentes del programa.
Independencia del hardware: El grado con que se desacopla el software del hardware donde opera.
Instrumentacin: El grado con que el programa vigila su propio funcionamiento e identifica los errores
que suceden.

Figura 4.2 Relacin entre Factores de calidad y mtricas de la calidad de software

-Modularidad: La independencia funcional de componentes de programa.
-Operatividad: La facilidad de operacin de un programa.
Trazabilidad: La capacidad de alcanzar una representacin del diseo o un componente real del programa hasta
los requisitos.
Formacin: El grado en que el software ayuda a los nuevos usuarios a manejar el sistema.

La relacin entre los factores de calidad del software y las mtricas de la lista anterior se muestra en la figura
4.2. Convendra decirse que el peso que se asigna a cada mtrica depende de los productos y negocios locales.
[15]
2.1 Modelos de desarrollo de software
MODELO EN CASCADA

Este es el ms bsico de todos los modelos y ha servido como bloque de construccin para los dems
paradigmas de ciclo de vida. Est basado en el ciclo convencional de una ingeniera y su visin es muy simple:
el desarrollo de software se debe realizar siguiendo una secuencia de fases. Cada etapa tiene un conjunto de
metas bien definidas y las actividades dentro de cada una contribuyen a la satisfaccin de metas de esa fase o
quizs a una sub-secuencia de metas de la misma, 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: 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.

http://web.archive.org/web/20121125080820/http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node1
0.html#SECTION00332000000000000000
http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html
MODELOS ITERATIVO

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las
necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos.
Consiste en la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le entrega al cliente una
versin mejorada o con mayores funcionalidades del producto. El cliente es quien despus de cada iteracin
evala el producto y lo corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un producto que
satisfaga las necesidades del cliente.
Ventajas
- Una de las principales ventajas que ofrece este modelo es que no hace falta que los requisitos estn totalmente
definidos al inicio del desarrollo, sino que se pueden ir refinando en cada una de las iteraciones.

- Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo en pequeos ciclos, lo que
permite gestionar mejor los riesgos, gestionar mejor las entregas
Inconvenientes
- La primera de las ventajas que ofrece este modelo, el no ser necesario tener los requisitos definidos desde el
principio, pero puede verse tambin como un inconveniente ya que pueden surgir problemas relacionados con la
arquitectura.
http://isw-udistrital.blogspot.com.co/2012/09/ingenieria-de-software-continuacion.html
http://fernandosoriano.com.ar/?p=13
MODELO EVOLUTIVO

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas,
hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin. Los modelos
Iterativo Incremental y Espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo. La
idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los comentarios
del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. Una ventaja de este modelo es
que se obtiene una rpida realimentacin del usuario, ya que las actividades de especificacin, desarrollo y
pruebas se ejecutan en cada iteracin.
Ventajas
- La especificacin puede desarrollarse de forma creciente.
- Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la
calidad del software.
- Es ms efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
Desventajas

- Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita
desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del sistema.
- Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del
software haciendo costoso el mantenimiento.
- Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan herramientas que pueden ser
incompatibles con otras o que poca gente sabe utilizar.
http://jorgetrejos.blogspot.com.co/2010/08/modelo-evolutivo.html
MODELO INCREMENTAL

En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para
la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras
formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en
cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se
adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Ventajas
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la
funcionalidad parcial.
- Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del
software.
- El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas
slo al mbito de cada incremento.
- Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.
Inconvenientes

- El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad,
de procesamiento distribuido y/o de alto ndice de riesgos.
- Requiere de mucha planeacin, tanto administrativa como tcnica.
- Requiere de metas claras para conocer el estado del proyecto.
https://procesosoftware.wikispaces.com/Modelo+Incremental
http://ingenieraupoliana.blogspot.com.co/2010/10/modelo-incremental.html
MODELO EN ESPIRAL

Es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construccin de prototipos

con los aspectos controlados y sistemticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial
para el desarrollo rpido de versiones incrementales del software que no se basa en fases claramente definidas y
separadas para crear un sistema.
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras
iteraciones la versin incremental podra ser un modelo en papel o un prototipo, durante las ltimas iteraciones
se producen versiones cada vez ms completas del sistema diseado.
EL modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas REGIONES
DE TAREAS , Cada una de las regiones estn compuestas por un conjunto de tareas del trabajo llamado
CONJUNTO DE TAREAS que se adaptan a las caractersticas del proyecto que va a emprenderse en todos los
casos se aplican actividades de proteccin.
Ventajas
- No requiere una definicin completa de los requerimientos del software a desarrollar para comenzar su
funcionalidad.
- En la terminacin de un producto desde el final de la primera iteracin es muy factible aprobar los requisitos.Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe
la forma de poder corregirlos a tiempo.
Inconvenientes
- Existe complicacin cuando se evala los riesgos.
- Se requiere la participacin continua por parte del cliente.
- Se pierde tiempo al volver producir inicialmente una especificacin completa de los requerimientos cuando se
modifica o mejora el software.

http://www.ojovisual.net/galofarino/modeloespiral.pdf
http://modeloespiral.blogspot.com.co/
MODELO DRA

El Desarrollo Rpido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso
del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es
una adaptacin a "Alta velocidad" en el que se logra el desarrollo rpido utilizando un enfoque de construccin
basado en componentes. Si se comprenden bien los requisitos y se limita el mbito del proyecto, el proceso
DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de
tiempo
Ventajas
- Comprar puede ahorrar dinero en comparacin con construir.
- Los entregables pueden ser fcilmente trasladados a otra plataforma.
- El desarrollo se realiza a un nivel de abstraccin mayor.
- Visibilidad temprana. Ingeniera de Software
- Mayor flexibilidad.
- Menor codificacin manual.
- Mayor involucramiento de los usuarios.
- Posiblemente menos fallas.
- Posiblemente menor costo.
- Ciclos de desarrollo ms pequeos.
- Interfaz grfica estndar.
Inconvenientes

- Comprar puede ser ms caro que construir.

- Costo de herramientas integradas y equipo necesario.
- Progreso ms difcil de medir.
- Menos eficiente.
- Menor precisin cientfica.
- Riesgo de revertirse a las prcticas sin control de antao.
- Ms fallas
- Prototipos pueden no escalar, un problema maysculo.
- Funciones reducidas (por "timeboxing").
- Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales
https://curiosisimos.files.wordpress.com/2009/12/modelo-de-desarrollo-rapido-de-aplicaciones.pdf
MODELO V

El modelo-V deriva directamente del modelo en cascada, y se usa como base de los procesos dentro del ciclo
de vida de software. El modelo considera el testing como una actividad paralela al SDLC (Software
Development Life Cycle) y no como una actividad aislada que se realiza al final del desarrollo
Ventajas
-

Es un modelo sencillo y de fcil aprendizaje

La relacin entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localizacin de
fallos
-

Especifica bien los roles de los distintos tipos de pruebas a realizar

Involucra al usuario en las pruebas

Inconvenientes

Las pruebas pueden ser caras y a veces no lo suficientemente efectivas

El producto final obtenido puede que no refleje todos los requisitos

No se puede repetir secuencia de pasos si este no sale bien; Se debe realizar nuevamente todo el proceso
de validacin y verificacin
2.2 Metodologas de desarrollo de software
RUP
El Proceso Racional Unificado o RUP (Rational Unified Process) es un proceso de desarrollo de software
desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje
Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo,
implementacin y documentacin de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al
contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software, tambin
desarrollado por Rational, que incluye informacin entrelazada de diversos artefactos y descripciones de las
diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de
acuerdo con las necesidades. [1]
Es una metodologa de desarrollo iterativo que es enfocada hacia diagramas de los casos de uso, y manejo de
los riesgos y el manejo de la arquitectura como tal. El RUP mejora la productividad del equipo ya que permite
que cada miembro del grupo sin importar su responsabilidad especfica pueda acceder a la misma base de datos
incluyendo sus conocimientos. Esto hace que todos compartan el mismo lenguaje, la misma visin y el mismo
proceso acerca de cmo desarrollar un software. [3]
Es un proceso de ingeniera de software, que hace una propuesta orientada por disciplinas para lograr las tareas
y responsabilidades de una organizacin que desarrolla software. Su meta principal es asegurar la produccin de
software de alta calidad que cumpla con las necesidades de los usuarios, con una planeacin y presupuesto
predecible.
Para quin es RUP?
Diseado para profesionales en el desarrollo de software, interesados en productos de software y profesionales
en la ingeniera y administracin de procesos de software.
Por qu usar RUP?

Provee un entorno de proceso de desarrollo configurable, basado en estndares.

Permite tener claro y accesible el proceso de desarrollo que se sigue.
Permite ser configurado a las necesidades de la organizacin y del proyecto.
Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto.

Entre sus caractersticas principales estn:

Como ya se haba mencionado, se refiere a loa casos de Uso: Estos son los artefactos primarios para
establecer el comportamiento deseado del sistema
Ahora bien tambin se centra en la Arquitectura: Es utilizada para conceptualizar, construir, administrar
y evolucionar el sistema en desarrollo.
El RUP es Iterativo e Incremental: Por esto se entiende que maneja una serie de entregas ejecutables e
integra continuamente la arquitectura para producir nuevas versiones mejoradas

Es conceptualmente amplio y diverso, tiene un enfoque orientado a objetos, presenta una evolucin
continua, es adaptable y repetible.
Permite mediciones: Es decir, estimacin de costos y tiempo y nivel de avance.

Ciclo de vida
En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con
un producto intermedio. Al terminar cada fase se realiza una evaluacin para determinar si se ha cumplido o no
con los objetivos de la misma.
Las fases son:
1.
2.
3.
4.

Inicio
Elaboracin
Construccin
Transicin

1. Inicio
El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del
proyecto. Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de
identificar los riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de software
existente, esta fase es ms breve y se centra en asegurar la viabilidad de desarrollar el proyecto.
2. Elaboracin
El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el
esfuerzo de diseo e implementacin en la siguiente fase. La arquitectura debe abarcar todas las consideraciones
de mayor importancia de los requerimientos y una evaluacin del riesgo.
3. Construccin
El objetivo de la fase de construccin es clarificar los requerimientos faltantes y completar el desarrollo del
sistema basados en la arquitectura base. Vista de cierta forma esta fase es un proceso de manufactura, en el cual
el nfasis se torna hacia la administracin de recursos y control de las operaciones para optimizar costos, tiempo
y calidad.
4. Transicin
Esta fase se enfoca en asegurar que el software est disponible para sus usuarios. Se puede subdividir en varias
iteraciones, adems incluye pruebas del producto para poder hacer el entregable del mismo, as como realizar
ajuste menores de acuerdo a ajuste menores propuestos por el usuario. En este punto, la retroalimentacin de los
usuarios se centra en depurar el producto, configuraciones, instalacin y aspectos sobre utilizacin. [2]

Imagen 1. Diagrama General del RUP

PMI
Project Management Institute (PMI) es la asociacin profesional sin fines de lucro ms importante y de mayor
crecimiento a nivel mundial que tiene como misin convertir a la gerencia de proyectos como la actividad
indispensable para obtener resultados en cualquier actividad de negocios. En la prctica es un grupo de
profesionales de la gerencia de proyectos que se dedican a promover el desarrollo del conocimiento y
competencias bsicas para el ejercicio profesional. A la fecha tiene ms de medio milln de asociados
acreditados y certificados en ms de 178 pases y se ha convertido en la acreditacin ms requerida por las
empresas para la contratacin de profesionales en el rea de la gerencia de proyectos.
El PMI ofrece a sus afiliados una serie de recursos para el avance del conocimiento del profesional de la
gerencia de proyectos tales como el desarrollo de estndares, un programa amplio investigacin, programas
educativos para entrenamiento y adquisicin de nuevos conocimientos, oportunidades para establecer redes de
pares profesionales locales para la discusin de asuntos de inters, conferencias y la emisin de certificaciones
para el ejercicio profesional reconocidas internacionalmente. Tales credenciales son

Certified Associate in Project Management (CAPM)

Project Management Professional (PMP)

PMI Scheduling Professional (PMI-SP)

PMI Risk Management Professional (PMI-RMP)

Program Management Professional (PgMP)

El Project Management Institute define la gestin de proyectos como la aplicacin de conocimientos,

habilidades, herramientas y tcnicas a las actividades de un proyecto para satisfacer sus requisitos. Para que la

gestin de proyectos sea satisfactoria es imprescindible partir de una planificacin coherente y que permita
alcanzar los objetivos del proyecto optimizando la asignacin y coste de recursos. [4]

Imagen 2. Logo de PMI

El Project Management Institute (PMI) es una de las asociaciones profesionales de miembros ms grandes del
mundo que cuenta con medio milln de miembros e individuos titulares de sus certificaciones en 180 pases. Es
una organizacin sin fines de lucro que avanza la profesin de la direccin de proyectos a travs de estndares y
certificaciones reconocidas mundialmente, a travs de comunidades de colaboracin, de un extenso programa
de investigacin y de oportunidades de desarrollo profesional. [5]
XP
El mtodo XP (Programacin extrema) define un conjunto de prcticas ptimas para el desarrollo de
aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo
una cercana relacin con dicho cliente.
La Programacin extrema se basa en los siguientes conceptos:

Los equipos de desarrollo trabajan directamente con el cliente durante ciclos cortos de una o dos
semanas como mximo.
La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos para
maximizar la interaccin con el usuario.
Existe una fuerte colaboracin entre el equipo de desarrollo mientras trabaja en el cdigo.
El cdigo se prueba y depura a lo largo del proceso de desarrollo.
Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de desarrollo [6]

Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de
acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de
vida del software.
Roles dentro de XP son:
1. Programador: Escribe las pruebas unitarias y produce el cdigo del sistema. Es el elemento ms
importante del equipo
2. Cliente: Escribe las historias de usuario y las pruebas funcionales para validar su implementacin.
Asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin
centrndose en aportar el mayor valor de negocio.
3. Tester: Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los
resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
4. Tracker: Es el encargado de seguimiento. Proporciona realimentacin al equipo. Debe verificar el grado
de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para
mejorar futuras estimaciones.

5. Entrenador (coach): Responsable del proceso global. Gua a los miembros del equipo para seguir el
proceso correctamente.
6. Consultor: Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario
para el proyecto. Ayuda al equipo a resolver un problema especfico.
7. Gestor (Big boss): Es el dueo de la tienda y el vnculo entre clientes y programadores. Su labor
esencial es la coordinacin. [7]
CMMI
El modelo CMMI vio la luz en 1987 como Capability Maturity Model (CMM), un proyecto del Software
Engineering Institute, que es un centro de investigacin de la Universidad Carnegie-Mellon. Este centro lo
fund y lo financia el Departamento de Defensa de los Estados Unidos. En 1991, se public por primera vez el
modelo CMM for Software, que est basado en una lista de comprobacin de los principales factores de xito
de los proyectos de desarrollo de software realizados a finales de los aos setenta y principios de los aos
ochenta. [8]
CMMI es un modelo para la administracin de riesgos y que indica la capacidad de una organizacin para
administrar los riesgos. Esta indicacin es un indicio de la probabilidad con la que una organizacin puede
cumplir sus promesas o proporcionar productos de alta calidad que sean atractivos para el mercado. Otro
enfoque es que el modelo proporciona un buen indicador de cmo actuar una organizacin en situaciones de
estrs. Una organizacin de gran madurez y altas capacidades afrontar con calma las situaciones inesperadas y
de estrs, reaccionar, realizar cambios y seguir adelante. Una organizacin con un reducido nivel de madurez
y pocas capacidades tender a dejarse llevar por el pnico en situaciones de estrs, seguir a ciegas los
procedimientos obviados, o bien, desbaratar todos los procesos y volver al caos.
El modelo CMMI no es un buen indicador del rendimiento econmico de una organizacin. Si bien las
organizaciones de gran madurez pueden administrar mejor el riesgo y ser ms predecibles, est demostrada la
aversin de estas organizaciones hacia el riesgo. Esta aversin puede conducir a una falta de innovacin o un
mayor grado de burocracia que da lugar a plazos de produccin significativos y una falta de competitividad. Las
empresas con un reducido nivel de madurez suelen ser ms innovadoras y creativas pero caticas e
impredecibles. Cuando se logran resultados, suelen ser el fruto del esfuerzo heroico de algunas personas
individuales o administradores.
Cul es la mejor forma de usar el modelo CMMI?
El modelo se dise para que se use como base de las iniciativas enfocadas a mejorar los procesos y, en el
mbito de la evaluacin, nicamente como ayuda para medir las mejoras. Este enfoque ha dado lugar a
resultados mixtos. Resulta demasiado fcil confundir el modelo con una definicin de proceso e intentar
seguirlo en lugar de considerarlo como un mapa que identifica las lagunas en los procesos existentes que habra
que rellenar. El bloque de creacin fundamental del modelo CMMI es un rea de proceso que define los
objetivos y varias de las actividades que se suelen realizar para lograr dichos objetivos. Un ejemplo de un rea
de proceso es el control de calidad de los procesos y productos. Otro ejemplo es la administracin de las
configuraciones. Es importante entender que un rea de proceso no es un proceso. Un solo proceso puede
atravesar varias reas de proceso y una sola rea de proceso puede abarcar varios procesos.
En realidad, CMMI-DEV representa dos modelos que comparten los mismos elementos subyacentes. El primero
y el ms conocido es el modelo de la representacin por etapas, que presenta 22 reas de proceso asignadas a
uno de los cinco niveles de madurez organizativa. Al valorar una organizacin, se evaluara su nivel de
funcionamiento y este nivel sera un indicador de su capacidad para administrar los riesgos y, por consiguiente,
cumplir con sus promesas.
Elementos del modelo CMMI

El modelo CMMI se divide en las 22 reas de proceso que se muestran en la siguiente tabla:
Acrnimo

rea de procesos

CAR

Anlisis y resolucin causal

CM

Administracin de configuracin

DAR

Anlisis y resolucin de decisiones

IPM

Administracin integrada de proyectos

MA

Medida y anlisis

OID

Innovacin e implementacin organizativas

OPD

Definicin de procesos organizativos

OPF

Enfoque de los procesos organizativos

OPP

Rendimiento de los procesos organizativos

OT

Aprendizaje organizativo

PI

Integracin de productos

PMC

Control y supervisin de proyectos

PP

Planeacin de proyectos

PPQA

Control de calidad de procesos y productos

QPM

Administracin cuantitativa de proyectos

RD

Definicin de requisitos

REQM

Administracin de requisitos

RSKM

Administracin de riesgos

SAM

Administracin de acuerdos con proveedores

TS

Solucin tcnica

VER

Comprobacin

VAL

Validacin

Imagen 3. Elementos del modelo CMMI [9]

RMM
La RMM o Relationship Management Methodology se define como un proceso de anlisis, diseo y desarrollo
de aplicaciones hipermedia. Los elementos principales de este mtodo son el modelo E-R (Entidad-Relacin) y
el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. Esta metodologa es
apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras
relaciones entre esas clases).
El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los
mecanismos de navegacin hipermedia de la aplicacin. El modelo introduce el concepto de slice (trozo) con el
fin de modelizar los aspectos unidos a la presentacin de las entidades. Un slice corresponde a un subconjunto
de atributos de una misma entidad destinados a ser presentados de forma agrupada.
El esquema completo del dominio y de la navegacin de la aplicacin se denomina esquema RMDM. En RMM,
el modelo hipermedia retoma los elementos enlace, ndice y visitas guiadas de HDM. La metodologa RMM
permite hacer explcita la navegacin al hacer el anlisis, lo que permite, tericamente, obtener una navegacin
ms estructurada e intuitiva, y lo hace de una forma muy sencilla.
RMM representa el primer caso en el que se crea una metodologa completa definiendo las distintas fases y no
nicamente un modelo de datos. Adems, se basa en un modelo de datos relacional, ajustndose as a la gran
mayora de las aplicaciones existentes. [10]
La Metodologa RMM considera en su etapa de Diseo como primer modelo de datos al Modelo EntidadInterrelacin (MER), que permite caracterizar el dominio de informacin y sus interrelaciones. Tal
representacin se realiza mediante un Esquem Entidad -Interrelacin.
Los tres elementos bsicos del modelo a utilizar son: entidades, atributos e interrelaciones.

Una entidad es un elemento conceptual del dominio de aplicacin, caracterizado por un set de
atributos.
Un atributo representa una unidad de informacin. Los atributos poseen un nombre, un tipo
(texto, imagen u otro medio) y estn siempre asociados a una nica entidad.
Una interrelacin es una unin conceptual entre dos o ms entidades. Su cardinalidad puede ser
uno-uno o uno-muchos. Las interrelaciones con cardinalidad muchos-muchos son divididas en
dos uno-muchos. [11]

El lenguaje de modelamiento unificado (UML)

El lenguaje unificado de modelamiento (UML) es un lenguaje de modelamiento de propsito general que se usa
para especificar, visualizar, construir, y documentar los artefactos de un sistema de software [16].
Captura decisiones y entendimiento de sistemas que deben ser construidos. Es usado para entender, disear,
configurar, buscar, mantener, y controlar informacin sobre dichos sistemas. Est diseado para trabajar con
todos los mtodos de desarrollo, etapas del ciclo de vida, dominios de aplicacin y multimedia. El lenguaje
unificado de modelamiento tiende a unificar las experiencias pasadas acerca del modelamiento de software para
incorporar las tcnicas actuales en un estndar.

Arquitectura de Software (Modelo 4+1)

El modelo 4+1 de Kruchten, es un modelo de vistas diseado por el profesor Philippe Kruchten y que encaja
con el estndar IEEE 1471-2000 (Recommended Practice for Architecture Description of Software-Intensive
Systems) que se utiliza para describir la arquitectura de un sistema software intensivo basado en el uso de
mltiples puntos de vista. [17]
Vale, si por ahora no te has enterado de nada y no ests en 3 o 4 de carrera de Ingeniera del Software (o
derivados) no te preocupes es normal, y si estas en 3 o 4 de carrera y aun as no te has enterado de nada, Ponte
las pilas YA! Porque estas cosas te deberan (por lo menos) sonar.
Bueno, vamos por pasos. Antes de entrar a explicar ms en detalle el modelo de kruchten vamos a explicar e
intentar dejar claro algunos conceptos como por ejemplo qu es un sistema software, qu es una vista y qu es
un punto de vista.
Lo primero es saber qu es eso de un sistema software, el cual lo definimos con la siguiente ecuacin.
Efectivamente, a grandes rasgos un sistema software es un software (ms o menos complejo) que corre en un
determinado hardware (ms o menos complejo). Por ejemplo, todo el rollo de los cajeros automticos es un
sistema software ya que en un hardware que llamamos cajero, se ejecuta algn tipo de programa (software)
el cual nos permite realizar determinadas gestiones.
Otra cosa de la que habla este modelo de Kruchten es sobre los conceptos de vista y puntos de vista, pues
bien una vista no es ms que una representacin de todo el sistema software desde una determinada
perspectiva, y un punto de vista se define como un conjunto de reglas (o normas) para realizar y entender las
vistas.
Bien, sino te ha quedado muy claro que es esto de las vistas y los puntos de vista, vamos a explicarlo con una
sencilla analoga del mundo de la arquitectura (de la arquitectura de las casas, edificios y esas cosas):
Si un arquitecto nos muestra un plano de una casa (como la de la siguiente imagen), nos est mostrando una
vista de la casa y como no tenemos ni idea de arquitectura, cuando nos explique o nos d un documento en el
que explique que un determinado smbolo del plano representa a una puerta u otro smbolo representa una mesa,
nos estar dado un punto de vista para que podamos entender el plano de la casa. Si ms tarde nos mostrase
otro plano (o maqueta) de la casa, nos estara dando otra vista de la casa y nos tendr que explicar el nuevo
punto de vista, es decir, que nos tendr que explicar que significa cada smbolo u objeto de esa nueva vista.

Bueno pues vistos los conceptos de lo que son las vistas y los puntos de vista, y habiendo explicado que es un
sistema software, uno ya se puede hacer a la idea de que va el modelo 4+1 vistas de Kruchten para la
descripcin de arquitecturas de sistemas software NO?
Pues s, lo que propone Ruchen es que un sistema software se ha de documentar y mostrar (tal y como se
propone en el estndar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4 vistas se han de relacionar
entre s con una vista ms, que es la denominada vista +1. Estas 4 vista las denomin Kruchten como: vista
lgica, vista de procesos, vista de despliegue y vista fsica y la vista +1 que tiene la funcin de relacionar las
4 vistas citadas, la denomin vista de escenario.
Cada una de estas vistas ha de mostrar toda la arquitectura del sistema software que se est documentando, pero
cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del sistema
software. A continuacin, pasamos a explicar que informacin ha de haber en la documentacin de cada una de
estas vistas.

Vista Lgica: En esta vista se representa la funcionalidad que el sistema proporcionara a los usuarios
finales. Es decir, se ha de representar lo que el sistema debe hacer, y las funciones y servicios que ofrece. Para
completar la documentacin de esta vista se pueden incluir los diagramas de clases, de comunicacin o de
secuencia de UML.

Vista de Despliegue: En esta vista se muestra el sistema desde la perspectiva de un programador y se ocupa de
la gestin del software; o en otras palabras, se va a mostrar como est dividido el sistema software en
componentes y las dependencias que hay entre esos componentes. Para completar la documentacin de esta
vista se pueden incluir los diagramas de componentes y de paquetes de UML.

Vista de Procesos: En esta vista se muestran los procesos que hay en el sistema y la forma en la que se
comunican estos procesos; es decir, se representa desde la perspectiva de un integrador de sistemas, el flujo de
trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. Para completar la
documentacin de esta vista se puede incluir el diagrama de actividad de UML.

Vista Fsica: En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los componentes
fsicos del sistema as como las conexiones fsicas entre esos componentes que conforman la solucin
(incluyendo los servicios). Para completar la documentacin de esta vista se puede incluir el diagrama de
despliegue de UML.

+1 Vista de Escenarios: Esta vista va a ser representada por los casos de uso software y va a tener la funcin
de unir y relacionar las otras 4 vistas, esto quiere decir que desde un caso de uso podemos ver cmo se van
ligando las otras 4 vistas, con lo que tendremos una trazabilidad de componentes, clases, equipos, paquetes, etc.,
para realizar cada caso de uso. Para completar la documentacin de esta vista se pueden incluir los diagramas de
casos de uso de UML.

NOTA MUY IMPORTANTE: Hay que dejar claro que Kruchten no dice de que manera se ha de
documentar cada vista; sino que es lo que hay que documentar en cada vista, es decir que cuando se diga que
la vista lgica se puede documentar de forma grfica con un diagrama de clases de UML, no quiere decir que
esa vista se tenga que documentar con ese diagrama, sino que ese diagrama (por sus caractersticas) puede
documentar esa vista.

Kruchten no define en ningn sitio puntos de vista para hacer vistas, solo define la info que ha de tener
cada vista. Lo que pasa que a da de hoy mucho software se hace bajo el paradigma de la programacin
orientada a objetos. Y casualmente existe una cosa que se llama UML (Lenguaje de Modelado Unificado), que
mira t por donde, representa vistas con diagramas que estn formados por smbolos, que pertenecen a un
LENGUAJE llamado UML (UML es un Lenguaje no una metodologa) que conoce (o ha de conocer) todo
ingeniero software. Y eso qu quiere decir, pues que un diagrama es una vista, con un punto de vista que ya est
muy bien definido en UML. A qu ahora las cosas empiezan a cuadrar!! Pues eso, que con UML nos
ahorramos el tener que documentar los puntos de vista al estar ya documentadas.
Y otra cosa tambin muy importante, es que cada uno puede representar la vista como le d la gana
siempre y cuando estn reflejadas en el punto de vista como ocurrir en muchos casos en la vista fsica.
Una vez explicadas las vistas que propone Kruchten y la forma de documentarlas, se puede apreciar que es un
modelo bastante bueno para documentar la arquitectura de un sistema software complejo, ya que todos los
Stakeholders (personas interesadas en el proyecto, desde el usuario del sistema hasta el manda ms de la
empresa) pueden entender el sistema software que se est desarrollando desde diferentes perspectivas.
Para terminar, solo recomendar la utilizacin de este modelo 4+1 vistas de Kruchten para la documentacin
de arquitecturas de sistemas software siguiendo el estndar IEEE 1471-2000.
Tipos de Diagramas en UML
1. Revisin de los tipos de diagramas
Existen varios tipos de diagramas que usted puede crear. Revisar con rapidez los tipos de diagramas
que puede crear y los tipos de informacin que se pretende transmitir con cada uno de estos diagramas.
2. Diagramas de casos de uso
Los diagramas de casos de uso son el equivalente del arte rupestre moderno. Los smbolos principales
de un caso de uso son el actor (nuestro amigo Esaw) y el valo del caso de uso.
Los diagramas de casos de uso son responsables principalmente de documentar los macrorrequisitos del
sistema. Piense en los diagramas de casos de uso como la lista de las capacidades que debe proporcionar
el sistema.
3. Diagramas de actividades
Un diagrama de actividades es la versin uml de un diagrama de flujo. Los diagramas de actividades se
usan para analizar los procesos y, si es necesario, volver a realizar la ingeniera de los procesos.
Un diagrama de actividades es una herramienta excelente para analizar problemas que, al final el sistema
deber resolver. Como una herramienta de anlisis, no queremos empezar resolviendo el problema en un
nivel tcnico mediante la asignacin de clases, pero podemos usar los diagramas de actividades para
entender el problema e incluso refinar los procesos que comprenden el problema.
4. Diagramas de clases

Los diagramas de clases se usan para mostrar las clases de un sistema y las relaciones entre ellas (figura
1-4). Una sola clase puede mostrarse en ms de un diagrama de clases y no es necesario mostrar todas
las clases en un solo diagrama monoltico de clases. El mayor valor es mostrar las clases y sus relaciones
desde varias perspectivas, de una manera que ayudar a transmitir la comprensin ms til.
5. Una imagen vale ms que mil lneas de cdigo 9
Los diagramas de clases muestran una vista esttica del sistema; no describen los comportamientos o
cmo interactan los ejemplos de las clases. Para describir los comportamientos y las interacciones entre
los objetos de un sistema, podemos revisar los diagramas de interaccin.
6. Diagramas de interaccin
Existen dos tipos de diagramas de interaccin: la secuencia y la colaboracin. Ambos transmiten la
misma informacin, empleando una perspectiva un poco diferente.
Los diagramas de secuencia muestran las clases a lo largo de la parte superior y los mensajes enviados
entre esas clases, modelando un solo flujo a travs de los objetos del sistema.
Los diagramas de colaboracin usan las mismas clases y mensajes, pero organizados en una disposicin
espacial.
Un diagrama de secuencia implica un ordenamiento en el tiempo al seguir la secuencia de mensajes
desde arriba a la izquierda hasta abajo a la derecha. Debido a que en el diagrama de colaboracin no se
indica en forma visual un ordenamiento en el tiempo, numeramos los mensajes para indicar el orden en
el cual se presentan.
Algunas herramientas convertirn de manera automtica los diagramas de interaccin entre secuencia y
colaboracin, pero no es necesario crear los dos tipos de diagramas. En general, se percibe que un
diagrama de secuencia es ms fcil de leer y ms comn.
7. Diagramas de estado
Mientras que los diagramas de interaccin muestran los objetos y los mensajes que se pasan entre ellos,
un diagrama de estado muestra el estado cambiante de un solo objeto, conforme ste pasa por un
sistema.
8. RECUERDE Desmitificado: el UML es un lenguaje. Como programar o hablar idiomas, si no se usan
con frecuencia, se pueden olvidar un poco. Es perfectamente aceptable mejorar un idioma particular.
La meta del modelado es captar la esencia del mismo y disear con pericia y, finalmente, con tanta
exactitud como sea posible, sin quedarse atascado decidiendo acerca de los elementos del lenguaje.
Desafortunadamente, las herramientas del UML no son tan exactas como los compiladores en la
descripcin de los errores del lenguaje.
9. 11
10. Diagramas de componentes
El uml define varios tipos de modelos, incluyendo modelos para anlisis, para diseo y para
implementacin. Sin embargo, nada hay que le fuerce a crear o mantener tres modelos para una
aplicacin. Un ejemplo de un diagrama que podra encontrar en un modelo de implementacin es de
componentes. En un diagrama de componentes, stos se muestran piense en subsistemas en el
producto final. [18]
Especificacin de los casos de uso
Hace unas semanas hablbamos en este mismo blog de los tipos de relaciones en diagramas de casos de uso que
nos ofrece UML, hoy nos vamos a centrar en las especificaciones detalladas de casos de uso o representaciones
textuales, que aunque UML no las especifica directamente, se utilizan de forma habitual.[19]

Partimos de la base de que los casos de uso son requisitos y ms an podramos decir que son requisitos
funcionales que nos indican que va a hacer el sistema. Muchas veces solemos caer en el error de vincular el
modelo de casos de uso exclusivamente al diagrama, es decir a la representacin grfica (al dibujo) pues
bien, los casos de uso son sobre todo documentos de texto. Con todo esto podemos decir que la especificacin
de casos de uso se centra en la escritura en vez del dibujo.

Los casos de uso se escriben con formatos diferentes dependiendo del nivel de detalle que queramos
alcanzar. Los grados de formalidad con los que podemos escribir un caso de uso son:
Breve: Descripcin en unas pocas lneas.
Informal: Varios prrafos en un estilo informal que cubren varios escenarios, entendiendo por escenario
a una instancia de un caso de uso, una historia particular de uso del sistema.
o
Completo: El ms elaborado, se trata de una descripcin detallada con una plantilla.
o
o

En este artculo nos vamos a centrar en estos ltimos, los casos de uso completos muestran ms detalles y estn
estructurados, para ello vamos a seguir el formato de usescases.org que propone Craig Larman, a travs de
la siguiente plantilla:

Tambin podramos aadir otros aspectos como:

Con todas estas secciones podemos especificar detalladamente los casos de uso de cualquier sistema, que nos
pueden servir como fichas de especificacin de requisitos funcionales del mismo, puesto que como hemos
comentado anteriormente los casos de uso no dejan de ser requisitos funcionales (aunque no todos requisitos
funcionales tienen por qu ser casos de uso).
Por ltimo a modo de recomendacin, es aconsejable escribir los casos de uso de una manera independiente
de la interfaz o de otros detalles relacionados con la implementacin, hay que escribirlos a nivel esencial para
ello es bueno que nos centremos en el qu no en el cmo.
Webgrafa
https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational [1]
https://softwarerecopilation.wordpress.com/modelo-rup/ [2]
http://rupmetodologia.blogspot.com.co/2012/07/metodologia-rup-y-ciclo-de-vida.html [3]
https://addkw.com/2012/06/08/pmi-una-definicion-y-una-aplicion-real-al-desarrollo-de-un-sistema-logistico/ [4]
https://americalatina.pmi.org/latam/AboutUS/WhatisPMI.aspx [5]
http://es.ccm.net/contents/227-metodos-rapidos-rad-xp [6]
https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema#Roles [7]
http://www.allsoft.mx/recursos/ElModeloCMMI.pdf [8]
https://msdn.microsoft.com/es-co/library/ee461556.aspx [9]
http://ingsoftwareresumenjaz.blogspot.com.co/2014/10/modelo-rmm.html [10]
http://sistemashipermediales.blogspot.com.co/p/metodologia-rmm.html [11]
http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/leccin_6__definicin_de_ingeniera_d
e_software.html [12]
http://tryengineering.org/ask-expert/what-does-computer-software-engineer-do-could-you-give-me-descriptionfield [13]
http://www.contrib.andrew.cmu.edu/~fahadi/sw.html [14]

http://www.edutecne.utn.edu.ar/proyectos_informaticos/buenas_practicas_proyectos_informaticos.pdf [15]
http://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/ [17]
http://www.seas.es/blog/informatica/especificacion-detallada-de-los-casos-de-uso-uml/ [19]
Bibliografa
Paul Kimmel, Manual de UML, Revisin de los tipos de diagramas, Pgina 7. [18]
James Rumbaugh, The Unified Modeling Language Reference Manual, Background, Pgina 3. [16]