Ingeniería de Software

Universidad Distrital Francisco Jos de Caldas. Ruz B. , Cuervo S. Trabajo investigativo Ingeniera de Software.

Trabajo Investigativo, Programacin aplicada

1

I. INGENIERA DE SOFTWARE

Definicin 1: Ingeniera del Software es el estudio de los principios y metodologas para el diseo, construccin,

desarrollo y mantenimiento de sistemas de software, los cuales se apoyan en una documentacin asociada requerida

para desarrollarlos, operarlos y mantenerlos.

Utilidad: La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin

(funcionamiento) y mantenimiento del software; es decir, la aplicacin de ingeniera al software.

Objetivos:

Mejorar la calidad del software

Acortar los tiempos de desarrollo

Aumentar la productividad

Incrementar la reutilizacin del software

Facilitar el control del proceso de desarrollo del software

Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.

La ingeniera de software es muy importante ya que con ella se puede analizar, disear, programar y aplicar un

software de manera correcta y organizada, para satisfacer todas las especificaciones del cliente y el usuario final ,

tambin cumpliendo requerimientos externos al software (tiempo de entrega , costo estimado, entre otras).

Gestin de proyectos Informticos: La gestin de proyectos de software es una parte esencial de la ingeniera del

software. La buena gestin no puede garantizar el xito del proyecto. Sin embargo, la mala gestin usualmente lleva

al fracaso del proyecto. Como por ejemplo el software es entregado tarde, los costes son mayores que los estimados

y los requerimientos no se cumplen.

En efecto gestionar con xito proyectos en general, y los informticos en particular, es cada vez ms difcil porque

supone mayores niveles de exigencia (en trminos de tiempo, coste y calidad), pero tambin de riesgo y complejidad,

derivados del tamao, la multidisciplinariedad y el cambio tecnolgico acelerado. Al mismo tiempo, requiere no slo

habilidades tcnicas, sino de gestin de las personas. Los proyectos informticos son cada vez ms proyectos

mixtos, que involucran cambios en la organizacin, los procesos de trabajo y las actitudes y habilidades de las

personas.

La gestin de proyectos es la disciplina de conocimiento y experiencia que permite planificar, organizar y gestionar

proyectos. Esto quiere decir principalmente dos cosas:

Asegurar que los proyectos se completan satisfactoriamente, consiguiendo los resultados y el producto final.

Hacerlo de manera que se pueda predecir y controlar su evolucin y explicarlo satisfactoriamente al equipo

de trabajo y al cliente.

Los gestores de software son responsables de la planificacin y temporalizacin del desarrollo de los proyectos.

Supervisan el trabajo para asegurar que se lleva a cabo conforme a los estndares requeridos y supervisan el progreso

para comprobar que el desarrollo se ajusta al tiempo previsto y al presupuesto. La administracin de proyectos de

Trabajo Investigativo INGENIERA DE SOFTWARE

Ruz Brayan - Cuervo Santiago. Universidad Distrital Francisco Jos de Caldas. Facultad de Ingeniera, Ingeniera Electrnica



2

software es necesaria debido a que la ingeniera de software profesional siempre est sujeta a restricciones

organizacionales de tiempo y presupuesto. El trabajo del gestor de proyecto de software es asegurar que estos

cumplan dichas restricciones y entregar software que contribuya a las metas de la compaa.

Procesos en la gestin de proyectos de software:

Planificacin: La gestin efectiva de un proyecto de software depende de planificar completamente el progreso del

proyecto. El gestor del proyecto debe anticiparse a los problemas que puedan surgir, as como preparar soluciones a

estos problemas. Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para el proyecto.

Este plan inicial debe ser el mejor posible de acuerdo con la informacin disponible. Este evolucionar conforme el

proyecto progrese y la informacin sea mejor.

Organizacin.

Para hacer cambios en el proyecto hay que evitar que todo cambio sea malo, existen tcnicas para realizar los

cambios. Los cambios pueden ser de dos tipos:

Origen externo: el cliente o el director lo sugieren, es hacer un reformado.

Origen interno: suelen aparecer debido a fallos en la planificacin, a nuevas situaciones percibidas.

1. Adaptaciones: consiste en adecuarse a las nuevas caractersticas del entorno de aplicacin.

2. Mejoras: consiste en ampliar las funcionalidades o prestaciones del proyecto.

3. Correcciones: cambios sobre lo planificado, que demuestran que la solucin tomada en tiempo de planificacin no

fue la ptima.

Los de origen interno producen un cambio en el trabajo planificado. Pero nos podemos hacer la pregunta de si el

cambio debe llevarse a la prctica, para responder a esta pregunta, el cambio debe pasar primero por tres fases:

Plantear la nueva planificacin.

Valorarla.

Recibir la autorizacin, tanto interna como externa.

Control.

Simultneamente a la asignacin de las tareas del proyecto, debern activarse los mecanismos de control. Estos

mecanismos implicarn las acciones necesarias para supervisar la tarea de los colaboradores y el avance del proyecto,

pudiendo utilizarse mtodos, tcnicas e instrumentos diversos, mediante los cuales se conocer si el proyecto se est

llevando a cabo como se plane.

El control proporciona informacin completa, precisa y oportuna sobre lo que se est realizando, adems detectar

ms exactamente sobre los obstculos que impiden el alcance los objetivos. Actuar en forma temprana sobre esos

problemas mejorando los procesos y garantizando eficiencia

Mtricas del Software: Hay varios modelos de mtricas del software aqu introducimos dos de ellas las cuales son:

El modelo ISO 9126

El modelo de Mccall.

El modelo ISO 9126:

Se reconocen seis factores de calidad que se pueden considerar tanto internos como externos:

Funcionalidad: conjunto de atributos que relacionan la existencia de un conjunto de funciones con sus

propiedades especificadas. Las funciones satisfacen necesidades especificadas o implcitas. Los parmetros

para medir la funcionalidad son:

Adecuacin: atributos que determinan si el conjunto de funciones son apropiadas para las tareas

especificadas.

Exactitud: atributos que determinan que los efectos sean los correctos o los esperados



3

Seguridad: atributos que miden la habilidad para prevenir accesos no autorizados, ya sea accidentales

o deliberados, tanto a programas como a datos.

Interoperabilidad: atributos que miden la habilidad de interactuar con sistemas especificados.

Cumplimiento: atributos que hacen que el software adhiera a estndares relacionados con la

aplicacin, y convenciones o regulaciones legales.

Confiabilidad: conjunto de atributos que se relacionan con la capacidad del software de mantener su nivel de

desempeo bajo las condiciones establecidas por un perodo de tiempo. Los parmetros que influyen en esta

mtrica son:

Madurez: atributos que se relacionan con la frecuencia de fallas por defectos en el software.

Tolerancia a las fallas: atributos que miden la habilidad de mantener el nivel especificado de

performance en caso de fallas del software.

Recuperacin: atributos que miden la capacidad de restablecer el nivel de desempeo y recuperar

datos en caso de falla, y el tiempo y esfuerzo necesario para ello

Eficiencia: conjunto de atributos que se relacionan con el nivel de performance del software y la cantidad de

recursos usados, bajo las condiciones establecidas. En esta mtrica se consideran:

Eficiencia en tiempo: atributos que miden la respuesta y tiempos de procesamiento de las funciones.

Eficiencia en recursos: atributos que miden la cantidad de recursos usados y la duracin de tal uso en

la ejecucin de las funciones.

Usabilidad: conjunto de atributos que se relacionan con el esfuerzo necesario para usar, y en la evaluacin

individual de tal uso, por parte de un conjunto especificado o implcito de usuarios. En esta mtrica se

consideran:

Entendimiento: atributos que miden el esfuerzo del usuario en reconocer el concepto lgico del

software y su aplicabilidad.

Aprendizaje: atributos que miden el esfuerzo del usuario en aprender la aplicacin (control,

operacin, entrada, salida).

Operabilidad: atributos que miden el esfuerzo del usuario en operar y controlar el sistema.

Mantenibilidad: conjunto de atributos que se relacionan con el esfuerzo en realizar modificaciones. En esta

mtrica se consideran:

Analizabilidad: atributos que miden el esfuerzo necesario para el diagnstico de deficiencias o

causas de fallas, o para identificacin de las partes que deben ser modificadas.

Facilidad para el cambio: atributos que miden el esfuerzo necesario para realizar modificaciones,

remocin de fallas o cambios en el contexto

Estabilidad: atributos que se relacionan con el riesgo de efectos no esperados en las modificaciones.

Testeabilidad: atributos que miden el esfuerzo necesario para validar el software modificado.

Portabilidad: conjunto de atributos que se relacionan con la habilidad del software para ser transferido de un

ambiente a otro. Esta mtrica considera:

Adaptabilidad: atributos que miden la oportunidad de adaptacin a diferentes ambientes sin aplicar

otras acciones que no sean las previstas para el propsito del software. Instalabilidad: atributos que

miden el esfuerzo necesario para instalar el software en el ambiente especificado.

Conformidad: atributos que miden si el software se adhiere a estndares o convenciones relacionados

con portabilidad.



4

Modelo de McCall

Puntos De Vista O Ejes

Factor Criterios

OPERACIN DEL

PRODUCTO

Facilidad de uso

- Facilidad de operacin: Atributos del software que determinan la facilidad

de operacin del software.

- Facilidad de comunicacin: Atributos del software que proporcionan

entradas y salidas fcilmente asimilables.

- Facilidad de aprendizaje: Atributos del software que facilitan la

familiarizacin inicial del usuario con el software y la transicin del modo

actual de operacin.

- Formacin: El grado en que el software ayuda para permitir que nuevos

usuarios apliquen el sistema.

Integridad

- Control de accesos. Atributos del software que proporcionan control de

acceso al software y los datos que maneja.

- Facilidad de auditora: Atributos del software que facilitan la auditora de

los accesos al software.

- Seguridad: La disponibilidad de mecanismos que controlen o protejan los

programas o los datos.

Correccin

- Completitud: Atributos del software que proporcionan la implementacin

completa de todas las funciones requeridas.

- Consistencia: Atributos del software que proporcionan uniformidad en las

tcnicas y notaciones de diseo e implementacin.

- Trazabilidad o rastreabilidad: Atributos del software que proporcionan una

traza desde los requisitos a la implementacin con respecto a un entorno

operativo concreto.

OPERACIN DEL

PRODUCTO

Fiabilidad

- Precisin: Atributos del software que proporcionan el grado de precisin

requerido en los clculos y los resultados.

- Consistencia.

- Tolerancia a fallos: Atributos del software que posibilitan la continuidad del

funcionamiento bajo condiciones no usuales.

- Modularidad: Atributos del software que proporcionan una estructura de

mdulos altamente independientes.

- Simplicidad: Atributos del software que posibilitan la implementacin de

funciones de la forma ms comprensible posible.

- Exactitud: La precisin de los clculos y del control

Eficiencia

- Eficiencia en ejecucin: Atributos del software que minimizan el tiempo de

procesamiento.

- Eficiencia en almacenamiento: Atributos del software que minimizan el

espacio de almacenamiento necesario.

REVISION DEL

PRODUCTO

Facilidad de mantenimiento

- Modularidad.

- Simplicidad.

- Consistencia.

- Concisin: Atributos del software que posibilitan la implementacin de una

funcin con la menor cantidad de cdigos posible.

- Auto descripcin: Atributos del software que proporcionan explicaciones

sobre la implementacin de las funciones.



5

Facilidad de prueba

- Modularidad.

- Simplicidad.

- Auto descripcin.

- Instrumentacin: Atributos del software que posibilitan

la observacin del comportamiento del software durante su ejecucin para facilitar las

mediciones del uso o la identificacin de errores.

Flexibilidad

- Auto descripcin.

- Capacidad de expansin: Atributos del software que posibilitan la expansin del

software en cuanto a capacidades funcionales y datos.

- Generalidad: Atributos del software que proporcionan amplitud a las funciones

implementadas.

- Modularidad.

Reusabilidad

- Auto descripcin.

- Generalidad.

- Modularidad.

-Independencia entre sistema y software: Atributos del software que determinan su

dependencia del entorno operativo.

- Independencia del hardware: Atributos del software que determinan su dependencia del

hardware.

Interoperabilidad

- Modularidad.

- Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso

de protocolos de comunicacin e interfaces estndar.

- Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones

de datos estndar.

- Estandarizacin en los datos: El uso de estructuras de datos y de tipos estndar a lo

largo de todo el programa.

Portabilidad

- Auto descripcin.

- Modularidad.

-Independencia entre sistema y software.

- Independencia del hardware.



6

II. LENGUAJE DE MODELAMIENTO UNIFICADO (UML)

Definicin y descripcin:

Es un estndar diseado para visualizar, especificar, construir y documentar software orientado a objetos, es ante

todo un lenguaje que proporciona un vocabulario y unas reglas para permitir una comunicacin. En este caso, este

lenguaje se centra en la representacin grfica de un sistema y nos indica cmo crear y leer los modelos, pero no dice

cmo crearlos. Esto ltimo es el objetivo de las metodologas de desarrollo.

Es un gran apoyo en los procesos de anlisis de un problema y una herramienta bastante til para determinar el

diseo de los diagramas de clases u objetos y los casos de uso, adems de la implementacin y configuracin con los

diagramas de despliegue.

Un modelo UML est compuesto por tres clases de bloques de construccin:

Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)

Relaciones: relacionan los elementos entre s.

Diagramas: Son colecciones de elementos con sus relaciones.

Ventajas

Mayor rigor en la especificacin.

Permite realizar una verificacin y validacin del modelo realizado.

Se pueden automatizar determinados procesos y permite generar cdigo a partir de los modelos y a la inversa (a

partir del cdigo fuente generar los modelos). Esto permite que el modelo y el cdigo estn actualizados, con lo que

siempre se puede mantener la visin en el diseo, de ms alto nivel, de la estructura de un proyecto.

Arquitectura de Software UML

La arquitectura del software es a grandes rasgos, una vista del sistema que incluye los componentes principales del

mismo, la conducta de esos componentes segn se percibe desde el resto del sistema y las formas en que los

componentes interactan y se coordinan para alcanzar la misin del sistema.

La arquitectura del software de un programa o sistema de computacin es la estructura o las estructuras del sistema,

que contienen componentes de software, las propiedades externamente visibles de dichos componentes y las

relaciones entre ellos.

La arquitectura del software es la organizacin fundamental de un sistema encarnada en sus componentes, las

relaciones entre ellos y con el entorno, y los principios que orientan su diseo y evolucin.

Uno de los desarrollos ms importantes dentro de la construccin del software ha sido el desarrollo de la arquitectura

de software, que permite representar la estructura de un sistema a un nivel mayor que el dado por la programacin o

incluso el diseo.

Para representar adecuadamente la arquitectura de un sistema es necesario contar con varios diagramas o vistas.

Evolucin

El lenguaje UML comenz a gestarse en octubre de 1994, con la

participacin de Grady Booch y Jim Rumbaugh. Cuando Rumbaugh se uni

a la compaa Rational fundada por Booch (dos reputados investigadores en

el rea de metodologa del software). El objetivo de ambos era unificar dos

mtodos que haban desarrollado: el mtodo Booch y el OMT (Object

Modelling Tool ). El primer borrador apareci en octubre de 1995.

En esa misma poca otro reputado investigador, Jacobson, se uni a

conocidas como los tres amigos. Adems, este lenguaje se abri a la

colaboracin de otras empresas para que aportaran sus ideas y as con esas

colaboraciones llegaron a la definicin de la primera versin de UML.

La primera versin se ofreci a un grupo de trabajo para convertirlo en 1997

en un estndar del OMG (Object Management Group), este grupo, que

gestiona estndares relacionados con la tecnologa orientada a objetos

Figura. Evolucin UML



7

(metodologas, bases de datos objetuales, CORBA, etc.), propuso una serie de modificaciones y una nueva versin de

UML (la 1.1 de la figura), que fue adoptada por el OMG como estndar en noviembre de 1997. Desde aquella

versin ha habido varias revisiones que gestiona la OMG Revision Task Force.

b) Vistas

Un UML se compone de muchos elementos de esquematizacin que representan las diferentes partes de un sistema

de software. Los elementos UML se utilizan para crear diagramas, que representa alguna parte o punto de vista del

sistema y existen los siguientes:

1. Vista de Casos de uso: muestra la funcionalidad del sistemas desde el punto de vista de un actor externo que

interacta con l, es til para clientes, diseadores, desarrolladores y unificadores.

Diagrama de casos de uso: muestra a los actores (otros usuarios del sistema), los casos de uso (las

situaciones que se producen cuando utilizan el sistema) y sus relaciones. EJEMPLO:

Diagrama de actividad: muestra actividades, as como los cambios de una a otra actividad junto con los

eventos que ocurren en ciertas partes del sistema. EJEMPLO:



8

2. Vista de Diseo: muestra la funcionalidad del diseo dentro del sistema en trminos de la estructura esttica

y comportamiento dinmico del sistema, es til para diseadores y desarrolladores.

Diagrama de clases: que muestra las clases y la relaciones entre ellas. EJEMPLO:

Diagrama de secuencia: muestra los objetos y sus mltiples relaciones entre ellos. EJEMPLO:

Diagrama de colaboracin: que muestra objetos y sus relaciones, destacando los objetos que

participan en el intercambio de mensajes. EJEMPLO:



9

Diagrama de estado: muestra estados, cambios de estado y eventos en un objeto o en parte del

sistema. EJEMPLO:

3. Vista de implementacin: muestra la especificacin de los componentes de cdigo, descripcin de los

mdulos de implementacin y sus dependencias, Vista til para desarrolladores.

Diagrama de componentes: que muestra los componentes de mayor nivel de la programacin.

Diagrama de implementacin: que muestra las instancias de los componentes y sus relaciones.

4. Vista de procesos: concurrencia del sistema, comunicacin y sincronizacin, divisin del sistema en procesos

y procesadores, vista til para desarrolladores e integradores.

Diagrama de secuencia: muestra los objetos y sus mltiples relaciones entre ellos.

Diagrama de colaboracin: que muestra objetos y sus relaciones, destacando los objetos que

participan en el intercambio de mensajes.

Diagrama de estado: muestra estados, cambios de estado y eventos en un objeto o en parte del

sistema.

Diagrama de actividad: muestra actividades, as como los cambios de una a otra actividad junto con

los eventos que ocurren en ciertas partes del sistema.

Diagrama de componentes: que muestra los componentes de mayor nivel de la programacin.



10

Diagrama de implementacin: que muestra las instancias de los componentes y sus relaciones.

5. Vista de desarrollo: muestra la implementacin del sistema en la arquitectura fsica, vista til para

desarrolladores, integradores y verificadores

Diagrama de relaciones de entidad: que muestra los datos y las relaciones y restricciones entre ellos.

Diagramas de Despliegue: representan la configuracin de los nodos de procesamiento en tiempo de

ejecucin y los componentes que residen en ellos.

III. MODELOS Y METODOLOGAS DE DESARROLLO DE SOFTWARE

3.1 MODELOS DE DESARROLLO DE SOFTWARE:

1. Modelo cascada Propuesto por Winston Royce en 1970 . el desarrollo en cascada, tambin llamado

modelo en cascada, es el enfoque metodolgico que ordena las etapas del proceso para el desarrollo

de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa

anterior. Caractersticas: Conocido como modelo secuencial lineal

Encadenamiento secuencial de las actividades

Cada etapa produce documentos que son la entrada a la siguiente

Para desarrollar una etapa debe concluirse la anterior

Popular en la dcada 70

Permite retroalimentacin y solapamiento entre fases.

Es un modelo iterativo y no lineal.

Para facilitar la terminacin de metas y tareas, es normal congelar partes del desarrollo despus de cierto

punto en la iteracin.

Ventajas:

Planificacin sencilla.



11

Una plantilla estructurada para ingeniera de software.

Desventajas:

Evolucin de los Requisitos.

Resultados al final.

Retrasos innecesarios.

til en proyectos donde:

Todas las especificaciones claras inicialmente.

Producto no novedoso.

Complejos que se entienden bien desde el principio.

En el modelo El proyecto pasa a travs de una serie de fases Al final de cada fase se revisan las tareas de

trabajo y productos . Para poder pasar a la siguiente fase se tiene que haber conseguido todos los objetivos de

la fase anterior. En este modelo es escasa la comunicacin entre las fases.

Fases:

Conceptualizacin: Se determina la arquitectura de la : Se determina la arquitectura de la solucin (divisin del sistema en subsistemas)

Anlisis de requisitos: Bsicamente se definen los requisitos funcionales y de rendimiento Diseo: Representacin de la aplicacin que sirve de gua a la implementacin n Implementacin: Transforma el diseo en cdigo Prueba: Validacin e integracin de software y sistemas Instalacin y comprobacin: se instala el software al cliente, el cual comprueba la correccin de la

aplicacin.

2. RAD: Rapid Application Development.

Caractersitcas:

Modelo secuencial lineal con tiempos cortos de desarrollo

Varios equipos participando en el desarrollo

Cada equipo maneja una parte del sistema

Uso de herramientas de pruebas automatizadas

En cada etapa de liberacin, los productos parciales son integrados, probados y liberados

El desarrollo rpido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de

software, desarrollado inicialmente por James Martin en 1980. El mtodo comprende el desarrollo iterativo,

la construccin de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rpido de

aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin. El Desarrollo Rpido



12

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. Cuando se utiliza principalmente para aplicaciones de sistemas de informacin, el enfoque DRA

comprende las siguientes fases:

Modelado de gestin: el flujo de informacin entre las funciones de gestin se modela de forma que

responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se

genera? Quin la genera? A dnde va la informacin? Quin la proceso?

Modelado de datos: el flujo de informacin definido como parte de la fase de modelado de gestin se refina

como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas

(llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados

para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del

proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin entre

los objetos.

Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta generacin. En lugar de

crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a

utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables

(cuando sea necesario). En todos los casos se utilizan herramientas automticas para facilitar la construccin

del software.

Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los

componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los

componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Ventajas de RAD

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



13

Mayor flexibilidad.

Menor codificacin manual.

Mayor involucramiento de los usuarios.

Posiblemente menos fallas.

Posiblemente menor costo.

Ciclos de desarrollo ms pequeos.

Interfaz grfica estndar.

Desventajas de RAD

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 (por sndrome de "codificar a lo bestia").

Prototipos pueden no escalar, un problema maysculo.

Funciones reducidas (por "timeboxing").

Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales.

3. Modelo 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.
http://4.bp.blogspot.com/-JPTk7lFWqJM/UE9ej0ONpvI/AAAAAAAAADk/OaATIcjpm-Y/s1600/ModeloIterativol_grafica.jpg



14

Este modelo se suele utilizar en proyectos en los que los requisitos no estn claros por parte del usuario, por

lo que se hace necesaria la creacin de distintos prototipos para presentarlos y conseguir la conformidad 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, puede verse tambin como un inconveniente ya que pueden surgir problemas relacionados con la

arquitectura.

4. 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.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El sistema evoluciona conforme

se aaden nuevas caractersticas propuestas por el usuario.



15

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que

no estn claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a

terminar de definir estos requisitos.

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.

5. Incremental:

Fusiona el modelo lineal secuencial con el de construccin de prototipos, cada secuencia lineal secuencial

produce un incremento del software.

Caractersticas: El primer incremento suele ser el ncleo (requisitos bsicos), se evala el producto entregado

y se itera. Algunas ventajas son: que es interactivo y con cada incremento se entrega al cliente un producto

operacional, adicionalmente cada incremento es diseado, codificado, probado, integrado y entregado por

separado que puede evaluarlo, permite variar el personal asignado en cada iteracin, existe una

disponibilidad limitada de recursos de desarrollo; su restriccin es que en la primera iteracin puede plantear

los mismos problemas que en un modelo lineal secuencial adems s los requerimientos crecen, la

arquitectura y el diseo puede cambiar drsticamente.

6. Espiral:

Propuesto por Barry Boehm en 1988, plantea un desarrollo en ciclos, y en cada ciclo: se define el objetivo

identificando las restricciones del proceso y el producto, e identificando los riesgos y estrategias alternativas;

se analizan los riesgos y se gestiona su reduccin, se desarrolla y/o se verifica la solucin objetiva, eligiendo

un modelo de desarrollo (metamodelo o modelo paramtrico) y por ltimo se realiza una revisin del

proyecto. Es til principalmente para prcticas de manejo y control de riesgos, orientacin al cliente y

desarrollo iterativo. Algunas ventajas son que responden rpidamente a riesgos, define muy bien la

arquitectura en sus fases iniciales, tiene un enfoque realista, se basa en un proceso continuo de verificacin

de calidad eliminando errores en la informacin descubierta, es ideal para productos con un nivel alto de

inestabilidad de los requerimientos, pero an as no es recomendable para proyectos simples.



16

Figura. Modelo de desarrollo de software en espiral - Sistemas Uniandes.

7. En V: Describe las actividades y los resultados que se producen durante el desarrollo del software. El

Mtodo-V es una representacin grfica del ciclo de vida del desarrollo del sistema. Resume los pasos

principales que hay que tomar en conjuncin con las correspondientes entregas de los sistemas de validacin.

La parte izquierda de la V representa la corriente donde se definen las especificaciones del sistema y la parte

derecha de la V representa la corriente donde se comprueba el sistema (contra las especificaciones definidas

en la parte izquierda). La parte de abajo, donde se encuentran ambas partes, representa la corriente de

desarrollo.

3.2. METODLOGAS DE DESARROLLO DE SOFTWARE

RUP(METODOLOGIA RATIONAL UNIFIED PROCESS): Forma disciplinada de asignar tareas y

responsabilidades en una empresa de desarrollo (quin hace qu, cundo y cmo). Requiere un grupo grande de

programadores para trabajar con esta metodologa. RUP es un marco del proyecto que describe una clase de los

procesos que son iterativos e incrementales, define un manojo entero de las actividades y de los artefactos que

usted necesita elegir para construir el propio, proceso individual. Es el proceso de desarrollo ms general de los



17

existentes actualmente. Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de

iteraciones concerniente a sus estimaciones originales. Las iteraciones tempranas de proyectos conducidos se

enfocan fuertemente sobre arquitectura del software; la puesta en prctica rpida de caractersticas se retrasa

hasta que se ha identificado y se ha probado una

arquitectura firme.

La ventaja principal de RUP es que se basa todo en las

mejores prcticas que se han intentado y se han probado en el

campo.

Se divide en cuatro fases:

1. Inicio (Define el alcance del proyecto)

2. Elaboracin (definicin, anlisis, diseo)

3. Construccin (implementacin)

4. Transicin (fin del proyecto y puesta en

produccin)

RUP realiza un levantamiento exhaustivo de requerimientos. Busca detectar defectos en las fases iniciales.

Intenta reducir al nmero de cambios tanto como sea posible. Realiza el Anlisis y diseo, tan completo como

sea posible. Diseo genrico, intenta anticiparse a futuras necesidades. Las necesidades de clientes no son

fciles de discernir. Existe un contrato prefijado con los clientes. El cliente interacta con el equipo de desarrollo

mediante reuniones a diferencia de la metodologa XP que el cliente es parte del equipo (in situ).

XP(METODOLOGIA EXTREME PROGRAMMING): Nace en busca de simplificar el desarrollo

del software y que se lograra reducir el costo del proyecto. Se requiere un grupo pequeo de programadores

para trabajar con esta metodologa entre 2 15 personas y estas irn aumentando conforme sea necesario.

Sus programadores pueden ser ordinarios. Combina las que han demostrado ser las mejores prcticas de

desarrollo de software, y las lleva al extremo. El desarrollo de software es riesgoso y difcil de controlar. Se

redisear todo el tiempo (refactoring), dejando el cdigo siempre en el estado ms simple posible. Se harn

pruebas todo el tiempo, no slo de cada nueva clase (pruebas unitarias) sino que tambin los clientes

comprobarn que el proyecto va satisfaciendo los requisitos (pruebas funcionales). Las pruebas de

integracin se efectuarn siempre, antes de aadir cualquier nueva clase al proyecto, o despus de modificar

cualquiera existente (integracin continua). Las iteraciones sern radicalmente ms cortas de lo que es usual

en otros mtodos, esto permite beneficiarse de la retroalimentacin tan a menudo como sea posible.

XP define 4 variables para el proyecto de software:

1. Coste

2. Tiempo

3. Calidad

4. Alcance.

XP tiene como valores lo siguiente:

1. Comunicacin

2. Simplicidad

3. Realimentacin

4. Coraje

Este es un conjunto mnimo y consistente de valores que permitirn hacer la vida ms fcil del grupo, la

gerencia y los clientes. Sirve tanto a los fines humanos como a los comerciales.

XP desarrolla 4 actividades que guiarn el desarrollo:

1. Codificar



18

2. Testear

3. Atender

4. Disear.

XP intenta reducir la complejidad del sw por medio de un trabajo

orientado directamente al objetivo, basado en las relaciones

interpersonales y la velocidad de reaccin. XP tiene una debilidad

cuando se utiliza en dominios de aplicaciones complejas o situaciones

difciles en la organizacin: el rol del cliente no refleja los diferentes

intereses, habilidades y fuerzas a las que enfrentan los programadores

durante el desarrollo de proyectos.

CMM(Capability Maturity Model): En principio fue

creado para evaluar y mejorar la capacidad de los contratistas de

software del Departamento de Defensa de los Estados Unidos, el

modelo CMM se convirti a travs de los aos en el ms alto estndar de ingeniera en el mundo para todo

tipo de compaas. Est fundamentado en prcticas reales de las compaas ms avanzadas, y refleja lo mejor

en procesos de desarrollo de software. El CMM est compuesto de 316 prcticas claves agrupadas en 18

reas y distribuidas en una jerarqua de cinco niveles, a travs de los cuales una organizacin

progresivamente alcanza mayor calidad, productividad y menores costos en el desarrollo de software. Los

niveles progresan desde el 1, que representa el estado catico, hasta el nivel 5, que representa el estado de

optimizacin continua. Un modelo posterior es el CMMI, siglas de Modelo de Madurez de Capacidad

Integrado.

FIGURA. Practicas de CMMI.

1. Inicial. La empresa no dispone de procesos y controles definidos. Se trabaja con procedimientos que no estn normalizados, es decir, procedimientos tanto del propio desarrollo de software como de su

planificacin y control, que no estn establecidos explcitamente antes de su uso. Por otro lado las

tcnicas y/o herramientas que se emplean para el desarrollo del software carecen de una integracin entre

las mismas y nicamente son empleadas en algunas fases del ciclo de vida del software. La caracterstica

de las empresas que se encuentran en este nivel es que no hay un control de la gestin de proyectos

software efectivo, porque puede suceder que la empresa disponga de procedimientos y tcnicas formales,

tanto de gestin como del proceso, y de herramientas, pero no se utilizan de manera estndar en todos los

proyectos

2. Repetible. La empresa tiene mtodos estandarizados facilitando procesos repetibles. Las empresas que se encuentran en este nivel son las que disponen de un control bsico de la gestin de proyectos,

gestin de calidad y gestin de la configuracin.



19

El problema en este tipo de organizacin es que introducir cualquier cambio tiene un alto grado de riesgo

de fracaso.

3. Definido. La empresa monitoriza y mejora sus procesos. Las empresas que se encuentran en este nivel se caracterizan por disponer de:

o Un grupo de proceso, cuyo objetivo es el de mejorar el proceso software. o Una metodologa de desarrollo software que describa las actividades tcnicas y de gestin requeridas para la adecuada ejecucin del proceso.

4. Gestionado. La empresa posee controles avanzados, mtricas y retroalimentacin. Las empresas que han alcanzado este nivel disponen de un control de los costes y calidad de las principales etapas del

proceso. Es pre-requisito que exista una metodologa de desarrollo software para realizar una medicin

efectiva.

5. Optimizacin. La empresa emplea mtricas con propsitos de optimizacin. En este nivel, las organizaciones se encuentran en un proceso de mejora continua. Se usan todos los procesos y tcnicas

modernas, lo mismo que la administracin cuantitativa. Las organizaciones se enfocan en la mejora a

travs de tcnicas y procesos de prevencin de defectos, cambios en tecnologa y cambios en procesos.

Menos del 0.1% de las organizaciones en el mundo se encuentran en este nivel de madurez.

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.

La metodologa fue creada por Isakowitz, Stohr y Balasubramanian. Esta metodologa es apropiada para

dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones

entre esas clases). Por ejemplo, catlogos o "frentes" de bases de datos tradicionales. Segn sus autores, est

orientada a problemas con datos dinmicos que cambian con mucha frecuencia, ms que a entornos estticos.

El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los

mecanismos de navegacin hipermedia de la aplicacin. Los objetos del dominio se definen con la ayuda de

entidades, atributos y relaciones asociativas. El modelo introduce el concepto de slice (trozo) con el fin de

modelar 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. La navegacin se modela

con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y bidireccional) que permiten

especificar la navegacin entre slices, y visita guiada condicional, ndice condicional y agrupacin, que

permiten especificar la navegacin entre entidades. El esquema completo del dominio y de la navegacin de

la aplicacin se denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del

mtodo. Las etapas son:

Primera etapa: representar los objetos del dominio con la ayuda del modelo Entidad-Relacin ampliado

con relaciones asociativas (aqullas que permiten representar caminos navegables entre entidades puestos en

evidencia en la fase de anlisis).

Segunda etapa: determinar la presentacin del contenido de las entidades de la aplicacin as como su

modo de acceso. El esquema obtenido como resultado de esta etapa se denomina esquema E.R+. Se trata de

un esquema Entidad-Relacin en el que cada entidad ha sido reemplazada por su esquema de entidad. Un

esquema de entidad est constituido por nodos (los trozos o slides) unidos por relaciones estructurales.

Tercera etapa: definir los caminos de navegacin inducidos por las relaciones asociativas del esquema E-

R+. A continuacin, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite

dotar a la aplicacin de accesos jerrquicos a niveles diferentes de los trozos de informacin. El esquema

RMDM resultante se obtiene aadiendo al esquema E-R+ las agrupaciones y caminos navegables definidos

en esta etapa.



20

Las cuatro etapas restantes consisten en:

Definicin del protocolo de conversin de elementos del diagrama RMDM en objetos de la plataforma de

desarrollo.

1. Concepcin del interfaz usuario. 2. Concepcin del comportamiento en ejecucin. 3. Construccin del sistema y test. 4. Muestra de un diagrama entidad-relacin.

REFERENCIAS

1. Metodologas de desarrollo de software. ESCUELA DE INGENIERA DE SISTEMAS, MIRIAN MILAGROS DAZ FLORES.

2. http://es.slideshare.net/mveces/metodologas-cmmi-y-pmi 3. Metodologa relacional de desarrollo de sistemas. CONTENIDOS EDUCATIVOS DIGITALES PARA EDUCACION

SUPERIOR

4. CMMI o metodologas Agiles de desarrollo. ESTRATEGA- CONSULTORIA EN ESTRATEGIAS Y PROCESOS. 5. RMM Metodologa de Administracin de Relaciones. MUNDO INFORMTICO, ABDEL RIVAS. 6. http://www.wolnm.org/apa/articulos/ingenieria_software.pdf 7. http://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf 8. http://zeus.inf.ucv.cl/~bcrawford/Modelado%20UML/Ingenieria%20del%20Software%207ma.%20Ed.%20-

%20Ian%20Sommerville.pdf

9. http://www.infor.uva.es/~mlaguna/is1/apuntes/1-intro.pdf 10. http://zeus.inf.ucv.cl/~bcrawford/Modelado%20UML/Ingenieria%20del%20Software%207ma.%20Ed.%20-

%20Ian%20Sommerville.pdf

11. http://www.wolnm.org/apa/articulos/ingenieria_software.pdf 12. http://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf 13. http://books.google.com.co/books?id=I22YPj6iBisC&printsec=frontcover&hl=es&source=gbs_ge_summary_r&cad=0#

v=onepage&q&f=true

14. http://www.monografias.com/trabajos5/call/call.shtml 15. http://www.cs.uns.edu.ar/~prf/teaching/SQ07/clase3.pdf 16. https://curiosisimos.files.wordpress.com/2009/12/modelo-de-desarrollo-rapido-de-aplicaciones.pdf 17. http://ldc.usb.ve/~mgoncalves/IS2/sd07/clase1.pdf 18. http://isw-udistrital.blogspot.com/2012/09/ingenieria-de-software-continuacion.html 19. http://ingenieriadesoftware.mex.tl/61885_Modelo-V.html 20. http://ldc.usb.ve/~mgoncalves/IS2/sd07/clase1.pdf 21. Ingeniera de software. Sommerville, I. Sptima edicin. Addison Wesley 2005 22. La importancia del desarrollo para el buen diseo del software. N.L. Gonzalez Morales
http://www.wolnm.org/apa/articulos/ingenieria_software.pdfhttp://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdfhttp://zeus.inf.ucv.cl/~bcrawford/Modelado%20UML/Ingenieria%20del%20Software%207ma.%20Ed.%20-%20Ian%20Sommerville.pdfhttp://zeus.inf.ucv.cl/~bcrawford/Modelado%20UML/Ingenieria%20del%20Software%207ma.%20Ed.%20-%20Ian%20Sommerville.pdfhttp://www.infor.uva.es/~mlaguna/is1/apuntes/1-intro.pdfhttp://zeus.inf.ucv.cl/~bcrawford/Modelado%20UML/Ingenieria%20del%20Software%207ma.%20Ed.%20-%20Ian%20Sommerville.pdfhttp://zeus.inf.ucv.cl/~bcrawford/Modelado%20UML/Ingenieria%20del%20Software%207ma.%20Ed.%20-%20Ian%20Sommerville.pdfhttp://www.wolnm.org/apa/articulos/ingenieria_software.pdfhttp://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdfhttp://books.google.com.co/books?id=I22YPj6iBisC&printsec=frontcover&hl=es&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=truehttp://books.google.com.co/books?id=I22YPj6iBisC&printsec=frontcover&hl=es&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=truehttp://www.monografias.com/trabajos5/call/call.shtmlhttp://www.cs.uns.edu.ar/~prf/teaching/SQ07/clase3.pdfhttps://curiosisimos.files.wordpress.com/2009/12/modelo-de-desarrollo-rapido-de-aplicaciones.pdfhttp://ldc.usb.ve/~mgoncalves/IS2/sd07/clase1.pdfhttp://isw-udistrital.blogspot.com/2012/09/ingenieria-de-software-continuacion.htmlhttp://ingenieriadesoftware.mex.tl/61885_Modelo-V.htmlhttp://ldc.usb.ve/~mgoncalves/IS2/sd07/clase1.pdf

Ingeniería de Software

Documents

Transcript of Ingeniería de Software