TRABAJO INVESTIGATIVO No.

Alex Andres Morales Roja

20111005068
Jorge Preciado Garcia
20092005102

Universidad Distrital Francisco Jose de Caldas

Facultad de Ingenieria
Ingenieria Electronica

Bogota D.C.
Spetiembre 13 de 2014

1.INGENIERIA DE SOFTWARE

Definicin
La ingeniera de software es e proceso de construir aplicaciones de tamao o alcance
prcticos, en las que predomina el esfuerzo de software y que satisfacen los
requerimientos de funcionalidad y desempeo. La ingeniera de software, ofrece mtodos
y tcnicas para desarrollar, mantener, producir y asegurar software de calidad.
La ingeniera de software es una disciplina que integra procesos, mtodos y herramientas
para el desarrollo de software. Varios son los modelos de procesos que se han propuesto
para la ingeniera de software, cada uno presenta ventajas y desventajas, pero todos
tienen en comn fases genricas que permiten llevar a cabo el proceso de la ingeniera de
software.

La gestin y planificacin de proyectos

La gestin y planificacin de proyectos es una actividad que empieza antes de iniciar
cualquier actividad tcnica y contina a lo largo de la definicin,del desarrollo y del
mantenimiento del software.
La actividad de gestin del proyecto comprende medicin y mtricas, estimacin, anlisis
de riesgos, planificacin, seguimiento y control.
El espectro de la gestin
La gestin de un proyecto de software se centra en las 4 Ps:
Personal: Necesidad de personal para el desarrollo de software
Producto: Objetivos y mbito del software.
Proceso: Estructura que establece un plan detallado para el desarrollo del software
Proyecto: desarrollo de software planificados y controlados.

La garanta de calidad del software es una actividad de proteccin que se aplica a cada
paso del proceso de software y que comprende: procedimientos, mtodos y herramientas,
revisiones tcnicas formales, tcnicas y estrategias de prueba, procedimientos de garanta
de ajustes y mecanismos de medida e informacin.

Mtricas
Las Mtricas Comprenden una gama de mediciones para el software y se aplican al

Proceso del Software y a proyecto de software para ayudar a la estimacin, el control de

calidad, la evaluacin de productividad y el control de proyectos.
La Mtrica es una medida cuantitativa del grado en que el sistema, componente o proceso
posee un atributo dado.
Las razones para medir los procesos del software, los productos y los recursos: son:
Caracterizar: para comprender mejor los procesos, los productos, los recursos y los
entornos
Evaluar: para determinar el estado con respecto al diseo
Predecir: para poder planificar
Mejorar: la calidad del producto y el rendimiento del proceso.

2.LENGUAJE DE MODELAMIENTO UNIFICADO (UML)

Definicin:

Es un lenguaje de modelado visual de propsito general orientado a objetos.

es un lenguaje de modelado visual que sirve para:
visualizar,
especificar
construir
documentar
caractersticas:

UML ofrece vocabulario y reglas:

para crear y leer modelos bien formados
que constituyen los planos de un sistema software.
UML es independiente del Proceso de desarrollo
Un uso ptimo se consigue en procesos dirigidos por casos de uso, centrados en la
arquitectura, iterativos e incrementales.
Proceso Unificado de Desarrollo (RUP)
UML cubre las diferentes vistas de la arquitectura de un sistema mientras
evoluciona a travs del ciclo de vida del desarrollo de software
Vistas Software (estticas, dinmicas, etc..)

Ventajas:
Es estndar => Facilita la comunicacin
Est basado en metamodelo con una semntica bien definida
Se basa en una notacin grfica concisa y fcil de aprender y utilizar.
Se puede utilizar para modelar sistemas software en diversos dominios:
Sistemas de informacin empresariales, Sistemas WEB, sistemas crticos y de tiempo
real, etc.
Incluso en sistemas que no son software
Es fcilmente extensible

Historia y evolucin:

Arquitectura de software UML (vistas)

La arquitectura del sistema es clave para poder manejar estos puntos de vista diferentes:
Se organiza mejor a travs de vistas arquitecturales interrelacionadas.
Proyecciones del modelo del sistema centradas en un aspecto particular.
No se requiere una vista que contenga la semntica completa de la aplicacin. La
semntica reside en el modelo.
Vistas arquitecturales

1.Vista de Casos de Uso (Use Case View)

Captura la funcionalidad del sistema tal y como es percibido por los

usuarios finales, analistas y encargados de pruebas.
Describe la funcionalidad en base a casos de uso.
En esta vista no se especifica la organizacin real del sistema
software.
Los diagramas que le corresponden son:
Aspectos estticos: diagramas de casos de uso.
Aspectos dinmicos: diagramas de interaccin, de estados y de
actividades.
2.Vista de Diseo (Logical View)

Captura las clases, interfaces y colaboraciones que describen el

sistema:
En el dominio del problema
En el dominio de la solucin
Las elementos que la forman dan soporte a los requisitos funcionales
del sistema.
Los diagramas que le corresponden son:
Aspectos estticos: diagramas de clases y de objetos. Tambin son tiles los diagramas de
estructura compuesta de clases.
Aspectos dinmicos: diagramas de interaccin, de estados y de
actividades.
3.Vista de Interaccin (Process view)

Captura el flujo de control entre las diversas partes del sistema,

incluyendo los posibles mecanismos de concurrencia y sincronizacin.
Abarca en especial requisitos no funcionales como el rendimiento,
escalabilidad y capacidad de procesamiento.
Los diagramas que le corresponden son los mismos que la vista de
diseo:
Aspectos estticos: diagramas de clases y de objetos.
Aspectos dinmicos: diagramas de interaccin, de estados y de
actividades.
Pero atendiendo ms las clases activas que controlan el sistema y los
mensajes entre ellas.
4.Vista de Implementacin (Development View)

Captura los artefactos que se utilizan para ensamblar y poner en

produccin el sistema software real.
Define la arquitectura fsica del sistema
Se centra en:
La configuracin de las distintas versiones de los archivos fsicos,
Correspondencia entre clases y ficheros de cdigo fuente,
Correspondencia entre componentes lgicos y artefactos fsicos.
Los diagramas que le corresponden son:
Aspectos estticos: diagramas de componentes (especialmente la versin de artefactos) y
de estructura compuesta.
Aspectos dinmicos: diagramas de interaccin, de estados y de
actividades.
5.Vista de Despliegue (Physical View)
Captura las caractersticas de instalacin y ejecucin del sistema.

Contiene los nodos y enlaces que forman la topologa hardware sobre la que se ejecuta el
sistema software.
Se ocupa principalmente de la distribucin de las partes que forman el sistema software
real.
Los diagramas que le corresponden son:
Aspectos estticos: diagramas de despliegue.
Aspectos dinmicos: diagramas de interaccin, de estados y de
actividades.
Diagramas
Los diagramas estructurales de UML sirven para visualizar, especificar, construir y
documentar los aspectos estticos de un sistema.
Se organizan en base a los principales grupos de elementos que aparecen al modelar
(durante
las diferentes fases del proceso de desarrollo)

Estructurales
De comportamiento
Estructurales:
Clases: Muestran un conjunto de clases, interfaces y colaboraciones, as como
las relaciones entre ellos.Son los diagramas ms comunes en el anlisis y diseo de un
sistema. (con atributos, operaciones y visibilidad)
Objetos: Muestra un conjunto de objetos y sus relaciones. Representan instantneas
estticas de instancias de los elementos existentes en los diagramas de clases.
Componentes: Pueden representar la encapsulacin de un componente con sus interfaces,
puertos y estructura interna (posiblemente formada por otros componentes anidados y
conectores).
Despliegue: Muestran un conjunto de nodos y sus relaciones. Describen la vista de
despliegue esttica de una arquitectura. Mediante iconos especializados se puede precisar
la naturaleza de los nodos como constituyentes fsicos (dispositivos, archivos, bases de
datos, etc.) de un sistema.
Paquetes: Muestran la descomposicin del propio modelo en unidades organizativas
(paquetes) y sus dependencias. Sirven para simplificar los diagramas de clases complejos,
permitiendo el agrupamiento de los clasificadores en paquetes.
Estructura Compuesta: Muestran la estructura interna (incluyendo partes y conectores) de
un clasificador estructurado o una colaboracin. Muy parecidos a los diagramas de
componentes.

De comportamiento:
Casos de uso: Muestran un conjunto de casos de uso y actores (tipo especial de clase) y
sus relaciones. Cubren la vista de casos de uso esttica de un sistema. Son importantes
en el modelado y organizacin del comportamiento de un sistema. Modelan el
comportamiento del sistema desde el punto de vista externo.
Estados: Muestran mquinas de estados, que constan de: estados, transiciones, eventos y
acciones.

Cubren la vista dinmica de un objeto. Son especialmente importantes en el modelado de

una clase o colaboracin con comportamiento significativo.
Resaltan el comportamiento dirigido por eventos de un objeto.
Actividades: Muestran el flujo paso a paso de una computacin (proceso, flujo de control o
flujo de datos). Una actividad muestra un conjunto de acciones, el flujo entre ellas y los
valores producidos o consumidos. Cubren la vista dinmica de un sistema. Resaltan el flujo
de control entre objetos.
Interaccin: Son un grupo especial de diagramas de comportamiento que muestran una
interaccin:
Conjunto de objetos o roles y mensajes que pueden ser enviados entre
ellos.
Cubren la vista dinmica de un sistema. Los objetos interactan para realizar
colectivamente los servicios ofrecidos por las aplicaciones.
Jerarqua de diagramas

3.MODELOS Y METODOLOGAS DE DESARROLLO DE SOFTWARE

3.1 Modelos De Desarrollo de Software:
Es importante incorporar estrategias de desarrollo que acompae al proceso, mtodos y a
las herramientas.
Una estrategia a menudo se llama modelo de proceso o paradigma de ingeniera del
software. Se selecciona un modelo de proceso para la ingeniera del software segn la
naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse, y
los controles y entregas que se requieren.
Sommerville [1] define modelo de proceso de software como "Una representacin
simplificada de un proceso de software, representada desde una perspectiva especfica.
Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del
software es una abstraccin de un proceso real."
Los modelos genricos no son descripciones definitivas de procesos de software; sin
embargo, son abstracciones tiles que pueden ser utilizadas para explicar diferentes
enfoques del desarrollo de software.

El modelo en Cascada (o lineal)

Este modelo, como su nombre lo indica, y requiere terminar una fase completa para pasar
a la siguiente, dejando nula posibilidad de volver atrs, por lo que hay queempezar de
nuevo. Esto implica de que si empezamos a desarrollar un software con este modelo, una
vez terminado, en el caso de tener algn problema en la ultima etapa, no podemos hacer
cambios directamente en la ultima fase, y hay que volver al principio y hacer todo
nuevamente, y dependiendo de la metodologa, quizs esto sea muy engorroso, sobre
todo cuando se pide mucha documentacin. En lo personal, no creo que exista algn
proyecto de software que sea tan riguroso como para no poder modificarlo directamente
en las ultimas etapas del desarrollo, pero en la teora as es la cosa.
El Modelo Iterativo (de Aproximacin o Incremantal)
Este es muy diferente al anterior, ya que iniciamos nuestro desarrollo, pasando por todas
etapas, pero no completamos ninguna, y solo avanzamos un cierto porcentaje. Una ves
terminado, volvemos al principio pero debemos regresar al inici para seguir
desarrollando. En la primera iteracin no hay problemas en que el software no este listo, ni
si quiera en la segunda, ya que cada ves que hacemos una iteracin, implementamos
nuevas funcionalidades del software final, corregimos y vemos como le parece al cliente,
refinando ms nuestro producto final, hasta la ultima iteracin, en donde se realiza la
entrega al cliente, para poder pasarlo a produccin.
De estos dos modelos, decienden todos los submodelos, metodologias y submetodologias
que conocemos.
El modelo evolutivo
es una metodologa de desarrollo de software muy relacionada con, pero claramente
distinta de, desarrollo por prototipos. El nfasis esta puesto sobre la importancia de
obtener un sistema de produccin flexible y expandible. As, si los requerimientos cambian
durante el desarrollo del sistema, entonces con un mnimo de esfuerzo y tiempo se puede
desarrollar un sistema de trabajo flexible.
La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que el
desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendra la
propiedad de satisfacer los nuevos requerimientos lo ms rpido posible. En contraste,
prototipos usa un enfoque iterativo solo para determinar los requerimientos
organizacionales. Por lo tanto el tiempo tomado entre cada iteracin es mucho ms
importante para el desarrollo evolutivo. En la figura 10 se puede ver grficamente esta
diferencia.
El desarrollo evolutivo asume que los requerimientos de un proyecto estn sujetos a
cambios continuos, por lo cual es necesario definir una estrategia de desarrollo que refleje
esta situacin. En cambio, el desarrollo orientado a prototipos, as como los anteriores,
asume que los requerimientos "reales" existen y se vale de las iteraciones del prototipo
para establecerlos y modelarlos.
La idea entonces de la metodologa de desarrollo evolutivo es estar liberando
constantemente una nueva versin del sistema que sea completamente funcional; as,
cada sistema producto de las iteraciones sucesivas del mtodo tendra incorporado los
nuevos requerimientos que ha sido posible identificar y que no estaran considerados en la
anterior versin.

El modelo Espiral
El modelo Espiral de Boehm para Ingeniera de Software agrupa las mejores caractersticas
del modelo del ciclo de vida clsico y de prototipos. Pero tambin agrega nuevas funciones
que no estn incluidas en los otros modelos, como el anlisis de riesgo. El modelo espiral
define cuatro actividades principales para el ciclo de vida.
Planificacin

La determinacin de los objetivos del proyecto, alternativas y restricciones.

Anlisis de Riesgo
El anlisis de alternativas y la identificacin y solucin de riesgos.
Ingeniera
Desarrollo del producto.
Evaluacin del cliente

El modelo es representado por una espiral dividida en cuatro cuadrantes, en que cada uno
describe las actividades mencionadas anteriormente. El modelo espiral utiliza un esquema
de desarrollo iterativo donde la primera iteracin comienza en el centro del crculo e,
incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones sucesivas
son versiones ms completas del software que est siendo construido. Al principio de cada
iteracin del ciclo de vida se hace un anlisis de riesgo, mientras, por el otro extremo, la
revisin del proyecto se realiza al final de la iteracin. As, se puede contrarrestar cualquier
riesgo observado mediante las acciones adecuadas en el tiempo preciso.
El modelo espiral es visto como un enfoque ms realista para el desarrollo de grandes
sistemas de software. Usa un mtodo evolucionario para desarrollo y prototipos como una
tcnica de reduccin de riesgo (pese a que los prototipos pueden ser usados en cualquier
etapa dentro del ciclo de vida). Tambin utiliza el enfoque de sistematizacin y el
'desarrollo en etapas' del ciclo de vida clsico, pero, con la diferencia que todos estn
incorporados dentro del esquema iterativo planteado por el modelo espiral.

El modelo DRA
Es un modelo de proceso de desarrollo del software que enfatiza en un ciclo de desarrollo
corto.El proceso DRA permite al equipo de desarrollo crear un "sistema completamente
funcional" dentro de periodos cortos de tiempo (de 60 a 90 das). El enfoque DRA
comprende las siguientes fases:
Modelado de Gestin: aqu se modela el flujo de informacin entre las funciones de
gestin.
Modelado de datos: se definen las caractersticas (atributos) de cada objeto, formado a
partir del flujo de informacin, y las relaciones entre ellos.
Modelado del proceso: las descripciones del proceso se crean para aadir, modificar,
suprimir o recuperar un objeto de datos.
Generacin de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de
programas ya existentes o crea componentes reutilizables.
Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y
probados, lo cual permite que el tiempo de duracin de las pruebas sea menor. Todo esto
no impide que se tenga que probar cada uno de los nuevos componentes.

3.2 Metodologas de Desarrollo

A diferencia de los modelos, las metodologas definen patrones, de cierta manera estrictos
para cada una de las etapas de desarrollo.
Dentro de las metodologas ms usadas est OMT++ : Metodologa 100% orientada a
objetos y descendiente del modelo lineal, es decir, se maneja muy bien con lenguajes
orientados a objetos, como Java, C++ y la familia de lenguajes .NET y obliga a realizar
cada una de las etapas de desarrollo de la mejor manera, ya que, en teora, no es posible
volver atrs para una nueva captura de requerimientos, por ejemplo. Esta metodologa usa
el patrn MVC (Modelo Vista Controlador) para las faces de anlisis y diseo.
RPU
El Proceso Unificado Rational(Rational Unified Process en ingls, habitualmente resumido
como RUP) 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.
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y
una especificacin ms detallada, el Rational Unified Process, que se vendiera como
producto independiente

PMI ( Project Management Institute)

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.

XP (Extreme Programing Ingenieria de Software)

La programacin extrema o eXtreme Programming (de ahora en adelante, XP) es una
metodologa de desarrollo de la ingeniera de software formulada por Kent Beck, autor del
primer libro sobre la materia,Extreme Programming Explained: Embrace Change (1999). Es
el ms destacado de losprocesos giles de desarrollo de software. Al igual que stos, la
programacin extrema se diferencia de las metodologas tradicionales principalmente en
que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP
consideran que los cambios de requisitos sobre la marcha son un aspecto natural,
inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.

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.

CMMI
Dentro de las Metodologas tradicionales que ms exigencias requieren, podemos
mencionar a CMMI (Capacity Maturity Model Integrated), que es un modelo de referencia
sobre buenas prcticas maduras, consolidadas, y probadas para el desarrollo y
mantenimiento de productos y servicios, cubriendo todo el ciclo de vida, desde la
concepcin a la entrega y mantenimiento. Las compaas que son evaluadas para los
Niveles de Madurez que componen a CMMI, tpicamente son de gran porte o tienen
objetivos de venta de sus servivios de desarrollo o aplicaciones a terceros. Si bien, como
mencionamos, encarar estas Metodologas tiene retornos de inversin positivos,
demandan procesos de largo plazo que puedan tomar entre 12 y 48 meses, dependiendo
del punto de inicio de cada compaa y del Nivel de Madurez a alcanzar. Claramente, CMMI
se ha transformado en el sello de facto de calidad de D esarrollo de Aplicaciones para las
Software Factories, o empresas de Outsourcing.

RMM
La Metodologa RMM [Isa98] para el desarrollo de software hipermediales se ha difundido
con cierto xito en este campo Los Modelos Conceptuales de Datos utilizados en ella han
sido objeto de varias modificaciones desde su presentacin en [Isa95]. Precisamente,
estas modificaciones se fundamentan en la permanente actualizacin del panorama
hipermedial.
El Modelamiento Conceptual de la metodologa RMM consta de dos etapas: el tradicional
Modelo Entidad-Interrelacin (MER), donde se modela el dominio de informacin a
considerar; y el Diseo de M-Slices, estructuras conceptuales que permiten modelar las
unidades de presentacin de la aplicacin.
La Metodologa RMM considera en su etapa de Diseo como primer modelo e datos al
Modelo Entidad-Interrelacin (MER), que permite caracterizar el dominio de informacin y
sus interrelaciones. Tal representacin se realiza mediante un Esquema Entidad
-Interrelacin.

Resumen personal 1:
La ingenieria de software tiene como objetivo principal regullar y supervisar lo procesos de
desarrollo de sofware.
La gestion de proyectos tiene como principales obtetivos la medicin y mtricas,
estimacin, analisis de riesgos, planificacin, seguimiento y control.
El modelamiento UML es un lenguaje de modelado visual que sirve para visualizar,
especificar, construir, documentar.
Los modelos de desarrollo de sofware son abstracciones tiles que pueden ser utilizadas
para explicar diferentes enfoques del desarrollo de software.

las metodologas definen patrones, de cierta manera estrictos para cada una de las etapas
de desarrollo.
Resumen personal 2:
ingenieria de software hace mas practicos aspectos como implementacion de codigo
gestion de proyectos aplicaciones y verificacion de metricas
La gestin y planificacin de proyectos es una actividad que empieza antes de iniciar
cualquier actividad tcnica
el moldeamiento UML Facilita la comunicacin y se puede utilizar para modelar sitemas de
diversos dominios.
Los modelos de desarrollo de sofware son una forma sencilla de hacer entender diferentes
formas de aplicar el desarrollo de software.
Las metodoligias son realmente lenguajes diferentemente parecidos que se carterizan por
sus formas propias de implementar codigo

Referencias Webgrafcas:
http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/unidad_iii_contr
ol_de_calidad_del_software.html
http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/materiales-de-clase1/is1-t02-trans.pdf
http://raulortega.blogspot.com/2006/12/para-los-lectores-de-este-blog-los.html