Trabajo de investigacin No.

01

Ingeniera de software

Presentado por:
Camilo Esteban Rodriguez
Brayan Andres Valero
Andres Mauricio Clavijo
Jhon Alexander Chacon

Presentado a:
Juan Carlos Guevara Bolaos

Universidad Distrital Francisco Jos de Caldas, Facultad Tecnolgica

Bogot D.C.
2016

Contenido
1. Introduccin................................................................................................................ 4
2.

Ingeniera de software ................................................................................................. 4

2.1.

Definicin ............................................................................................................... 4

2.2.

Objetivos ................................................................................................................. 4

2.3.

Caractersticas ......................................................................................................... 5

2.4.

Historia ................................................................................................................... 5

3.

Seis modelos de ciclo de vida de software ................................................................. 10

3.1.

Nombre ................................................................................................................. 10

3.1.1.

Modelo Cascada ................................................................................................ 10

3.1.2.

Modelo De Desarrollo Incremental .................................................................... 10

3.1.3.

Modelo De Desarrollo Evolutivo........................................................................ 10

3.1.4.

Modelo de Prototipado de Requerimientos ......................................................... 10

3.1.5.

Modelo Espiral .................................................................................................. 10

3.1.6.

Modelo Concurrente .......................................................................................... 10

3.2.

Etapas ................................................................................................................... 10

3.3.

Artefacto (diagrama donde se muestra ciclo de vida) ............................................. 15

3.3.1.

Modelo Cascada ................................................................................................ 15

3.3.2.

Modelo De Desarrollo Incremental .................................................................... 15

3.3.3.

Modelo De Desarrollo Evolutivo........................................................................ 16

3.3.4.

Modelo de Prototipado de Requerimientos ......................................................... 16

3.3.5.

Modelo Espiral .................................................................................................. 17

3.3.6.

Modelo Concurrente .......................................................................................... 17

4.

Seis metodologas de desarrollo de software ............................................................. 18

4.1.

Nombre ................................................................................................................. 18

4.3.

Etapas y actividades .............................................................................................. 19

4.4.

Artefactos.............................................................................................................. 26

5.

Cuatro paradigmas del software ................................................................................ 29

5.1.

Nombre ................................................................................................................. 29

5.2.

Descripcin ........................................................................................................... 29

5.3.

Ejemplo de aplicacin del paradigma .................................................................... 34

6.
6.1.

Ocho reas de conocimiento de la ingeniera de software .......................................... 34

Nombre ................................................................................................................. 34
2

6.2.

Descripcin de rea ............................................................................................... 35

7.

Elementos de un proyecto de desarrollo de software ................................................. 37

8.

Conclusiones............................................................................................................. 38

9.

Bibliografa ............................................................................................................... 38

1. Introduccin
El presente trabajo tiene como objetivo identificar, estudiar y conocer los diferentes
conceptos, objetivos, historia, modelos de ciclo de vida, metodologas, mtodos, estndares
y procesos de evaluacin de la calidad de la ingeniera de software.
El trabajo se divide en los diferentes conceptos, objetivos, historia, modelos de ciclo de vida,
metodologas, mtodos, estndares y procesos de evaluacin de la calidad de la ingeniera de
software.

2. Ingeniera de software
2.1.

Definicin

Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los
programas de computadora, procedimientos, reglas, la documentacin asociada y los
datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de
software es un producto diseado para un usuario". En este contexto, la Ingeniera de
Software es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del
software", que en palabras ms llanas, se considera que "la Ingeniera de Software es la
rama de la ingeniera que aplica los principios de la ciencia de la computacin y las
matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a
los problemas de desarrollo de software", es decir, "permite elaborar consistentemente
productos correctos, utilizables y costo-efectivos" [Cota 1994].
El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente
ordenadas con la intencin de logra un objetivo, en este caso, la obtencin de un producto
de software de calidad" [Jacobson 1998].El proceso de desarrollo de software "es aquel
en que las necesidades del usuario son traducidas en requerimientos de software, estos
requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo
es probado, documentado y certificado para su uso operativo". Concretamente "define
quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [Jacobson
1998].

2.2.

Objetivos

En la construccin y desarrollo de proyectos se aplican mtodos y tcnicas para resolver

los problemas, la informtica aporta herramientas y procedimientos sobre los que se
apoya la ingeniera de software.
Disear aplicaciones informticas que se ajusten a las necesidades de las
organizaciones.
Dirigir y coordinar el desarrollo de aplicaciones complejas.
4

Intervenir en todas las fases del ciclo de vida de un producto.

Estimar los costes de un proyecto y determinar los tiempos de desarrollo.
Hacer el seguimiento de costes y plazos.
Dirigir equipos de trabajo de desarrollo software.
Organizar la realizacin de pruebas que verifiquen el correcto funcionamiento de los
programas y que se ajustan a los requisitos de anlisis y diseo.
Disear, construir y administrar bases de datos.
Dirigir y asesorar a los programadores durante el desarrollo de aplicaciones.
Introducir procedimientos de calidad en los sistemas, evaluando mtricas e
indicadores y controlando la calidad del software producido.
Organizar y supervisar el trabajo de su equipo de los tcnicos de mantenimiento y los
ingenieros de sistemas y redes.

2.3.

Caractersticas

2.4.

Historia

Cuando aparecieron las primeras computadoras digitales en la dcada de 1940,8 el

desarrollo de software era algo tan nuevo que era casi imposible hacer predicciones de
las fechas estimadas de finalizacin del proyecto y muchos de ellos sobrepasaban los
presupuestos y tiempo estimados. Los desarrolladores tenan que volver a escribir todos
sus programas para correr en mquinas nuevas que salan cada uno o dos aos, haciendo
obsoletas las ya existentes.

El trmino Ingeniera del software apareci por primera vez en a finales de la dcada de
1950. La Ingeniera de software fue estimulada por la crisis del software de las dcadas
de entre 1960 y 1980. La Ingeniera del software viene a ayudar a identificar y corregir
mediante principios y metodologas los procesos de desarrollo y mantenimiento de
sistemas de software.
Aparte de la crisis del software de las dcadas de entre 1960 y 1980, la ingeniera de
software se ve afectada por accidentes que conllevaron a la muerte de tres personas; esto
sucedi cuando la mquina de radioterapia Therac-25 emite una sobredosis masiva de
radiacin y afecto contra la vida de estas personas.9 Esto remarca los riesgos de control
por software,10 afectando directamente al nombre de la ingeniera de software.
A principios de los 1980,11 la ingeniera del software ya haba surgido como una genuina
profesin, para estar al lado de las ciencias de la computacin y la ingeniera tradicional.
Antes de esto, las tareas eran corridas poniendo tarjetas perforadas como entrada en el
lector de tarjetas de la mquina y se esperaban los resultados devueltos por la impresora.
Debido a la necesidad de traducir frecuentemente el software viejo para atender las
necesidades de las nuevas mquinas, se desarrollaron lenguajes de orden superior. A
medida que apareci el software libre, las organizaciones de usuarios comnmente lo
liberaban.
Durante mucho tiempo, solucionar la crisis del software fue de suma importancia para
investigadores y empresas que se dedicaban a producir herramientas de software.
Para la dcada de 1980, el costo de propiedad y mantenimiento del software fue dos veces
ms caro que el propio desarrollo del software, y durante la dcada de 1990, el costo de
propiedad y mantenimiento aument 30 % con respecto a la dcada anterior. En 1995,
muchos de los proyectos de desarrollo estaban operacionales, pero no eran considerados
exitosos. El proyecto de software medio sobrepasaba en un 50 % la estimacin de tiempo
previamente realizada, adems, el 75 % de todos los grandes productos de software que
eran entregados al cliente tenan fallas tan graves, que no eran usados en lo absoluto o
simplemente no cumplan con los requerimientos del cliente.10
Algunos expertos argumentaron que la crisis del software era debido a la falta de
disciplina de los programadores.
Cada nueva tecnologa y prctica de la dcada de 1970 a la de 1990 fue pregonada como
la nica solucin a todos los problemas y el caos que llev a la crisis del software. Lo
cierto es que la bsqueda de una nica clave para el xito nunca funcion. El campo de
la ingeniera de software parece un campo demasiado complejo y amplio para una nica
solucin que sirva para mejorar la mayora de los problemas, y cada problema representa
slo una pequea porcin de todos los problemas de software.
El auge del uso del Internet llev a un vertiginoso crecimiento en la demanda de sistemas
internacionales de despliegue de informacin en la World Wide Web. Los desarrolladores
se vieron en la tarea de manejar ilustraciones, mapas, fotografas y animaciones, a un
ritmo nunca antes visto, con casi ningn mtodo para optimizar la visualizacin y
6

almacenamiento de imgenes. Tambin fueron necesarios sistemas para traducir el flujo

de informacin en mltiples idiomas extranjeros a lenguaje natural humano, con muchos
sistemas de software diseados para uso multilenguaje, basado en traductores humanos.
La ingeniera de software contribuyo alrededor de 90,000 millones de dlares por ao ya
que entra en juego el Internet; esto hace que los desarrolladores tuviesen que manejar
imgenes mapas y animaciones para optimizar la visualizacin/almacenamiento de
imgenes (como el uso de imgenes en miniatura). El uso de los navegadores y utilizacin
de lenguaje HTM cambia drsticamente la visin y recepcin de la informacin.
La amplia conexin de red crea la proliferacin de virus informticos y la basura en los
correos electrnicos (E-mail) esto pone en una carrera contra el tiempo los
desarrolladores para crear nuevos sistemas de bloqueo o seguridad de estas anomalas en
la informtica ya que se volvan sumamente tediosas y difciles de arreglar10
Despus de una fuerte y creciente demanda surge la necesidad de crear soluciones de
software a bajo costo, esto conlleva al uso de metodologas ms simples y rpidas que
desarrollan software funcional. Cabe sealar que los sistemas ms pequeos tenan un
enfoque ms simple y rpido para poder administrar el desarrollo de clculos y algoritmos
de software.

Su origen se debi a que el entorno de desarrollo de sistemas software careca de:

Retrasos considerables en la planificacin.

Poca productividad.
Elevadas cargas de mantenimiento.
Demandas cada vez ms desfasadas frente a las ofertas.
Baja calidad y fiabilidad del producto.
Dependencia de los realizadores.

1955 a 1965: Los orgenes.

El trmino Ingeniera del software apareci por primera vez en la dcada de 1950 y
principios de los aos 1960. Los programadores siempre haban sabido sobre ingenieros
civiles, elctricos y de computadores y debatan qu podra significar la ingeniera para
el software.
1965 a 1985: La Crisis del Software
La ingeniera de software fue estimulada por la llamada crisis del software de la dcada
de 1960, 1970 y 1980, que identifica muchos de los problemas de desarrollo de software.
7

Muchos proyectos de software sobrepasaron el presupuesto y el tiempo estimados.

Algunos proyectos causaron daos a la propiedad. Algunos proyectos causaron prdidas
de vidas.

Desarrollo inacabable de grandes programas.

Ineficiencia, errores, coste impredecible.
Nada es posible..

1985 a 1989: No hay balas de plata.

Durante dcadas, solucionar la crisis del software fue de suprema importancia para
investigadores y empresas productoras de herramientas de software.
El costo de propiedad y mantenimiento del software en la dcada de 1980 fue dos veces
ms caro que el propio desarrollo del software.
Durante la dcada de 1990, el costo de propiedad y mantenimiento aument en un 30%
con respecto a la dcada anterior.
En 1995, las estadsticas mostraron que la mitad de los proyectos de desarrollo
encuestados estaban operacionales, pero no eran considerado exitoso.
El proyecto de software medio sobrepasa su estimacin en tiempo en el 50%. Las tres
cuartas partes de todos los grandes productos de software son entregados al cliente con
tales fallas que no son usados en absoluto, o no cumplen con los requerimientos del
cliente.

1990 a 1999: Prominencia de Internet.

El auge de la Internet condujo a un rpido crecimiento en la demanda de sistemas

internacionales de despliegue de informacin y e-mail en la World Wide Web.

El crecimiento del uso del navegador, corriendo en el lenguaje HTM, cambi la manera
en que estaba organizada la visualizacin y la recuperacin de la informacin. Las
amplias conexiones de red condujeron al crecimiento y la prevencin de virus
informticos internacionales en computadores con MS Windows, y la gran proliferacin
8

de correo basura se convirti en una cuestin de diseo importante en sistemas de correo

electrnico, inundando canales de comunicacin y requiriendo de precalificacin
semiautomatizada.

2000 al presente: Metodologas ligeras.

Con la creciente demanda de software en muchas organizaciones pequeas, la necesidad

en soluciones de software de bajo costo llev al crecimiento de metodologas ms simples
y rpidas que desarrollan software funcional, de los requisitos de implementacin, ms
rpidos y ms fciles. El uso de prototipos rpidos evolucion a metodologas ligeras
completas como la programacin extrema,(XP), que intent simplificar muchas las reas
de la ingeniera de software, incluyendo la recopilacin de requerimientos y las pruebas
de confiabilidad para el creciente y gran nmero de pequeos sistemas de software.

El software en la actualidad.

Hoy en da el software tiene un doble papel. Es un producto, pero simultneamente es el

vehculo para hacer entrega de un producto. Como producto permite el uso del hardware,
ya sea, por ejemplo, un ordenador personal o un telfono mvil celular. Como vehculo
utilizado para hacer entrega del producto, acta como base de control, por ejemplo un
sistema operativo, o un sistema gestor de redes. El software hace entrega de lo que se
considera como el producto ms importante del siglo veintiuno, la informacin.
Actualmente se considera la Ingeniera del Software como una nueva rea de la
ingeniera, y la profesin de ingeniero informtico es una de las ms demandadas, aunque
en Espaa los salarios suelen ser bajos para la cualificacin de estos profesionales. La
palabra ingeniera tiene una connotacin de prestigio que provoca que muchas ramas del
conocimiento tiendan a autodenominarse as.

3. Seis modelos de ciclo de vida de software

3.1.

Nombre

3.1.1.

Modelo Cascada

3.1.2.

Modelo De Desarrollo Incremental

3.1.3.

Modelo De Desarrollo Evolutivo

3.1.4.

Modelo de Prototipado de Requerimientos

3.1.5.

Modelo Espiral

3.1.6.

Modelo Concurrente

3.2.

Etapas

Modelo Cascada
Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los
dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software
es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia
simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades
dentro de una fase contribuyen a la satisfaccin de metas de esa fase o quizs a una
subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin entre las
fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs representan la
retroalimentacin.

Modelo De Desarrollo Incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una
forma de reducir los riesgos es construir slo una parte del sistema, reservando otros
aspectos para niveles posteriores. El desarrollo incremental es el proceso de construccin
siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un
documento de requerimientos es escrito al capturar todos los requerimientos para el
sistema completo.
10

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El

desarrollo incremental no demanda una forma especfica de observar el desarrollo de
algn otro incremento. As, el modelo cascada puede ser usado para administrar cada
esfuerzo de desarrollo, como se muestra en la figura.

Modelo De Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas
veces denominado como prototipado evolutivo) construye una serie de grandes versiones
sucesivas de un producto. Sin embargo, mientras que la aproximacin incremental
presupone que el conjunto completo de requerimientos es conocido al comenzar, el
modelo evolutivo asume que los requerimientos no son completamente conocidos al
inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos
que son bien comprendidos son seleccionados para el primer incremento. Los
desarrolladores construyen una implementacin parcial del sistema que recibe slo estos
requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a
los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos
es actualizada, y una segunda versin del producto es desarrollada y desplegada. El
proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El
desarrollo evolutivo no demanda una forma especfica de observar el desarrollo de algn
incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de
desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado
tambin.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos
(incremental), y comprender al principio que muchos nuevos requerimientos es probable
que aparezcan cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la
manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas
versiones del software. Cada paso debe ser registrado, la documentacin debe ser
recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.
11

Modelo de Prototipado de Requerimientos

El prototipado de requerimientos es la creacin de una implementacin parcial de un
sistema, para el propsito explcito de aprender sobre los requerimientos del sistema. Un
prototipo es construido de una manera rpida tal como sea posible. Esto es dado a los
usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el
prototipo. Estos individuos luego proveen la retroalimentacin sobre lo que a ellos les
gust y no les gust acerca del prototipo proporcionado, quienes capturan en la
documentacin actual de la especificacin de requerimientos la informacin entregada
por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como
parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede
servir su papel inmediatamente antes de algn o todo el desarrollo incremental en
modelos incremental o evolutivo.
El Prototipado ha sido usado frecuentemente en los 90, porque la especificacin de
requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar.
Muchos usuarios y clientes encuentran que es mucho ms fcil proveer retroalimentacin
convenientemente basada en la manipulacin, leer una especificacin de requerimientos
potencialmente ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos estn
incorporados, un prototipo generalmente se construye con los requerimientos entendidos
ms pobremente.

Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este
modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo
de desarrollo, otro comienza. Adems, en cada desarrollo ejecutado, puedes seguir estos
cuatros pasos:
Determinar qu quieres lograr.
Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una,
analizar los riesgos y resultados finales, y seleccionar la mejor.
Seguir la alternativa seleccionada en el paso 2.
12

Establecer qu tienes terminado.

La dimensin radial en la figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos
a resolver un conjunto particular de problemas del cliente. Durante el primer viaje
alrededor de la espiral, analizamos la situacin y determinamos que los mayores riesgos
son la interfaz del usuario. Despus de un cuidadoso anlisis de las formas alternativas
de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una
especificacin de requerimientos y esperar que el cliente lo entienda, y construir un
prototipo), determinamos que el mejor curso de accin es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con
retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este
tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos
comiencen a aparecer slo despus de que el sistema sea desplegado. Analicemos las
rutas alternativas, y decidimos que la mejor aproximacin es construir un incremento del
sistema que satisfaga slo los requerimientos mejor entendidos. Hagmoslo ya. Despus
del despliegue, el cliente nos provee de retroalimentacin que dir si estamos correctos
con esos requerimientos, pero 50 nuevos requerimientos ahora se originarn en las
cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios bsicos:

Decidir qu problema se quiere resolver antes de viajar a resolverlo.

Examinar tus mltiples alternativas de accin y elegir una de las ms

convenientes.

Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo.

No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL"
sistema que el cliente necesita, y

Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente
compatible.

13

Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso
software. Mientras que la contribucin primaria del modelo espiral es en realidad que
esas actividades del software ocurran repetidamente, la contribucin del modelo
concurrente es su capacidad de describir las mltiples actividades del software ocurriendo
simultneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que
ocurren en algn tiempo del proceso de desarrollo de software. Discutamos un poco tales
casos:
Los requerimientos son usualmente "lneas de base", cuando una mayora de los
requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo
considerable al diseo. Sin embargo, una vez que comienza el diseo, cambios a los
requerimientos son comunes y frecuentes (despus de todo, los problemas reales
cambian, y nuestro entendimiento de los problemas desarrollados tambin). Es
desaconsejado detener el diseo en este camino cuando los requerimientos cambian; en
su lugar, existe una necesidad de modificar y rehacer lneas de base de los requerimientos
mientras progresa el diseo. Por supuesto, dependiendo del impacto de los cambios de
los requerimientos el diseo puede no ser afectado, medianamente afectado o se requerir
comenzar todo de nuevo.
Durante el diseo de arquitectura, es posible que algunos componentes comiencen a ser
bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede
ser posible comenzar el diseo detallado en esos componentes estables. Similarmente,
durante el diseo detallado, puede ser posible proceder con la codificacin y quizs
regular testeando en forma unitaria o realizando testeo de integracin previo a llevar a
cabo el diseo detallado de todos los componentes.
En algunos proyectos, mltiples etapas de un producto se han desarrollado
concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la etapa 1 de
un producto, y al mismo tiempo estar haciendo mantencin sobre un componente 2,
mientras que se est haciendo codificacin sobre un componente 3, mientras se realiza
diseo sobre una etapa 4, y especificacin de requisitos sobre un componente 5.
En todos estos casos, diversas actividades estn ocurriendo simultneamente. Eligiendo
seguir un proyecto usando tcnicas de modelacin concurrente, se posibilita el
conocimiento del estado verdadero en el que se encuentra el proyecto.
14

3.3.

Artefacto (diagrama donde se muestra ciclo de vida)

3.3.1. Modelo Cascada

3.3.2. Modelo De Desarrollo Incremental

15

3.3.3. Modelo De Desarrollo Evolutivo

3.3.4. Modelo de Prototipado de Requerimientos

16

3.3.5. Modelo Espiral

3.3.6. Modelo Concurrente

17

4. Seis metodologas de desarrollo de software

4.1.

Nombre

4.1.1. METODOLOGA RUP

Es una metodologa cuyo fin es entregar un producto de software. Se estructura todos
los procesos y se mide la eficiencia de la organizacin. Es un proceso de desarrollo
de software el cual utiliza el lenguaje unificado de modelado UML, constituye la
metodologa estndar ms utilizada para el anlisis, implementacin y documentacin
de sistemas orientados a objetos.
El RUP es un conjunto de metodologas adaptables al contexto y necesidades de cada
organizacin. Describe cmo aplicar enfoques para el desarrollo del software,
llevando a cabo unos pasos para su realizacin. Se centra en la produccin y
mantenimiento de modelos del sistema.
4.1.2. SCRUM
METODOLOGA SCRUM
Scrum es una metodologa gil de desarrollo, aunque surgi como modelo para el
desarrollo de productos tecnolgicos, tambin se emplea en entornos que trabajan con
requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en
el desarrollo de determinados sistemas de software.
Es una metodologa de desarrollo muy simple, que requiere trabajo duro porque no
se basa en el seguimiento de un plan, sino en la adaptacin continua a las
circunstancias de la evolucin del proyecto.
4.1.3. XP
METODOLOGA XP
Se basa en la filosofa de que el mayor valor de negocio es entregado por el programa
ms sencillo que cumpla los requerimientos. Simple Design se enfoca en
proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni
menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos
obsoletos de forma sencilla.
4.1.4. AUP
METODOLOGIA AUP
El Proceso Unificado gil (Agile UP) es un enfoque al desarrollo de software basado
en el Rational Unified Process (RUP) de IBM. El ciclo de vida de Agile UP es serial
18

en lo grande e iterativo en lo pequeo, liberando entregables incrementales en el

tiempo. Este describe de una manera simple y fcil de entender la forma de
desarrollar aplicaciones de software de negocio usando tcnicas giles y conceptos
que an se mantienen vlidos en RUP. El AUP aplica tcnicas giles incluyendo
Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado gil,
Gestin de Cambios gil, y Refactorizacin de Base de Datos para mejorar la
productividad.

4.1.5. DESARROLLO ADOPTATIVO DE SOFTWARE

METODOLOGIA DESARROLLO ADAPTATIVO DE SOFTWARE (DAS)
El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith 1998 como
una tcnica para construir software y sistemas complejos. Los apoyos filosficos del
DAS se enfocan en la colaboracin humana y la organizacin propia del equipo.
4.1.6. 3P
4.2. Paradigma 3P es una metodologa de desarrollo de software nacida al calor de la
experiencia acumulada del grupo de investigacin y desarrollo Atis debido a
la insuficiente capacidad de respuesta a los clientes utilizando las metodologas
tradicionales. Paradigma 3P es una metodologa de desarrollo de software nacida al
calor de la experiencia acumulada del grupo de investigacin y desarrollo Atis,
debido a la insuficiente capacidad de respuesta a los clientes utilizando las
metodologas tradicionales.

4.3. Etapas y actividades

4.3.1. RUP

Fases del ciclo de vida del RUP:

1. Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados al proyecto,
proponer una visin muy general de la arquitectura de software y producir el plan de
las fases y el de iteraciones posteriores.
2. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso
que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase,
19

se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del

dominio del problema, se disea la solucin preliminar.
3. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del
sistema, para ello se deben clarificar los requerimientos pendientes, administrar los
cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
4. Fase de Cierre: El propsito de esta fase es asegurar que el software est
disponible para los usuarios finales, ajustar los errores y defectos encontrados en las
pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico
necesario. Se debe verificar que el producto cumpla con las especificaciones
entregadas por las personas involucradas en el proyecto.
Ciclo de vida RUP
Artefactos RUP
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie
de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del
sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio:
Documento Visin
Especificacin de Requerimientos
Elaboracin:
Diagramas de caso de uso
Construccin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista lgica:
Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)
Vista de implementacin:
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin
Vista conceptual
Modelo de dominio
20

 Vista fsica
Mapa de comportamiento a nivel de hardware

4.3.2. SCRUM
Fases de scrum
SCRUM comprende las siguientes fases:
1.- Pre-juego
Planificacin: Definicin de una nueva versin basada en la pila actual, junto con una
estimacin de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto
la visin como el anlisis. Si se trata de la mejora de un sistema existente comprende
un anlisis de alcance ms limitado. Arquitectura: Diseo de la implementacin de
las funcionalidades de la pila. Esta fase incluye la modificacin de la arquitectura y
diseo generales.
2.- Juego
Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versin con respeto
contino a las variables de tiempo, requisitos, costo y competencia. La interaccin
con estas variables define el final de esta fase. El sistema va evolucionando a travs
de mltiples iteraciones de desarrollo o sprints.
3.- Post-juego
Preparacin para el lanzamiento de la versin, incluyendo la documentacin final y
pruebas antes del lanzamiento de la versin.
Herramientas y artefactos
Scrum no requiere ni provee prcticas de Ingeniera. En lugar de eso, especifica
prcticas y herramientas de gerencia que se aplican en sus distintas fases para evitar
el caos originado por la complejidad e imposibilidad de realizar predicciones.
Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando
un proyecto comienza es muy difcil tener claro todos los requerimientos sobre el
producto. Sin embargo, suelen surgir los ms importantes que casi siempre son ms
que suficientes para un Sprint.
El objetivo es asegurar que el producto definido al terminar la lista es el ms correcto,
til y competitivo posible y para esto la lista debe acompaar los cambios en el
entorno y el producto.
21

Sprints
Un Sprint es el procedimiento de adaptacin de las cambiantes variables del entorno
(requerimientos, tiempo, recursos, conocimiento, tecnologa). Son ciclos iterativos en
los cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos.
Durante un Sprint el producto es diseado, codificado y probado. Y su arquitectura y
diseo evolucionan durante el desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fcil de
recordar y est siempre presente en el equipo.
Burn down Chart
La burn down chart es una grfica mostrada pblicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.
Dibujando una lnea que conecte los puntos de todos los Sprints completados,
podremos ver el progreso del proyecto. Lo normal es que esta lnea sea descendente
(en casos en que todo va bien en el sentido de que los requisitos estn bien definidos
desde el principio y no varan nunca) hasta llegar al eje horizontal, momento en el
cual el proyecto se ha terminado (no hay ms requisitos pendientes de ser completados
en el Backlog).
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los tems de la Product
Backlog List que van a ser implementados en el siguiente Sprint.
Stabilization Sprints
En estos Sprints el equipo se concentra en encontrar defectos, no en agregar
funcionalidad. Suelen aplicarse cuando se prepara un producto para el release. Son
tiles cuando se estn realizando pruebas beta, se est introduciendo a un equipo en
la metodologa de Scrum o cuando la calidad de un producto no alcanza los lmites
esperados.

4.3.3. XP
Entendimiento
1. Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado
por el programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca
en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms
ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos
obsoletos
de
forma
sencilla.
22

2. Metfora: desarrollada por los programadores al inicio del proyecto, define una
historia de cmo funciona el sistema completo. XP estimula historias, que son breves
descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y
modelos UML (Unified Modeling Language). La metfora expresa la visin evolutiva
del proyecto que define el alcance y propsito del sistema. Las tarjetas CRC (Clase,
Responsabilidad y Colaboracin) tambin ayudarn al equipo a definir actividades
durante el diseo del sistema. Cada tarjeta representa una clase en la programacin
orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las
colaboraciones con las otras clases (cmo se comunica con ellas).
3. Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el
propietario de nada, todos son el propietario de todo. Este mtodo difiere en mucho a
los mtodos tradicionales en los que un simple programador posee un conjunto de
cdigo. Los defensores de XP argumentan que mientras haya ms gente trabajando
en
una
pieza,
menos
errores
aparecern.
4. Estndar de codificacin: define la propiedad del cdigo compartido as como las
reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas
de cdigo desarrolladas por diferentes equipos. Los programadores las han de seguir
de tal manera que el cdigo en el sistema se vea como si hubiera estado escrito por
una sola persona.
4.3.4. AUP

Fases de Agile UP
Las fases son implementadas de una forma serial a lo largo de un proyecto de Agile
UP. Estas fases son:

1. Iniciacin. El objetivo de esta fase es identificar el alcance inicial del proyecto, una
arquitectura potencial para el sistema y obtener, si procede, financiacin para el
proyecto y la aceptacin por parte de los promotores del sistema.
2. Elaboracin. Mediante esta fase se pretende identificar y validar la arquitectura del
sistema.
3. Construccin. El objetivo de esta fase consiste en construir software desde un punto
de vista incremental basado en las prioridades de los participantes.
4. Transicin. En esta fase se valida y despliega el sistema en el entorno de
produccin.

23

Actividades y artefactos

1.

2.
3.

4.
5.

6.
7.

Modelado. Su objeto es entender la lgica de negocio de la aplicacin, el dominio

del problema del proyecto e identificar una solucin viable para el dominio del
problema.
Implementacin. Transformar los modelos en cdigo ejecutable y realizar pruebas
bsicas, en particular pruebas unitarias.
Pruebas. Realizar una evaluacin de los objetivos para asegurar la calidad. Esto
incluye encontrar defectos, validar que el sistema funciona como fue diseado y
verificar que los requisitos se cumplen.
Despliegue. Planear la entrega del sistema y ejecutar el plan para hacer que el
sistema quede disponible para los usuarios finales.
Gestin de la configuracin. Gestionar el acceso a los artefactos del proyecto. Esto
incluye, adems de la traza de versiones de los artefactos, el control de cambios y
la gestin de los mismos.
Gestin del proyecto. Dirige las actividades que tienen lugar dentro del proyecto,
incluyendo gestin de riesgos, direccin del personal y coordinacin.
Entorno. Apoyar el resto del esfuerzo asegurando que los procesos, mtodos y
herramientas estn disponibles para el equipo cuando los necesitan.

4.3.5. DESARROLLO ADOPTATIVO DE SOFTWARE

Fases de desarrollo
Fase de especulacin: Se inicia el desarrollo del proyecto. En ella se utiliza
informacin como la misin del cliente, las restricciones del proyecto y los requisitos
bsicos para definir el conjunto de ciclos en el que se harn los incrementos del
software.
Fase de colaboracin: Se busca que el equipo no solo se comunique o se encuentre
completamente integrados, se desea que exista confianza, donde se puedan realizar
crticas constructivas y ayudar si resentimientos, trabajar tan duro como sea posible,
comunicar de una forma oportuna los problemas que se presenten para tomar acciones
efectivas y poseer un conjunto de actitudes que contribuyan al trabajo que se
encuentran
realizando.
Aprendizaje: Permite mejorar el entendimiento real sobre la tecnologa, los procesos
utilizados y el proyecto. El aprendizaje individual permite al equipo tener mayor
posibilidad de xito.
24

Cada una de estas fases se unen entre s para llevar a cabo diversas funciones, pero
en si estas funciones son para sacar adelante un proyecto de software de manera
rpida, y trabajando en equipo, para que en un futuro, obtengamos un software
eficiente.
El Desarrollo adaptativo del software (ASD) proporciona un marco para el desarrollo
iterativo de sistemas grandes y complejos. El mtodo fomenta el desarrollo iterativo
e incremental con el uso de prototipos.

ASD resalta que las aproximaciones secuenciales en cascada solo funcionan en

entornos bien conocidos. Pero como los cambios ocurren frecuentemente en el
desarrollo software, es importante usar un mtodo tolerante a cambios. El primer ciclo
de un proyecto ASD suele ser corto, asegurando que el cliente est involucrado y
confirmando
la
viabilidad
del
proyecto.
Cada ciclo termina con una revisin en grupo enfocada al cliente. Durante las
reuniones de revisin, se estudia la aplicacin funcionando. El resultado de las
reuniones son peticiones de cambio documentadas.
4.3.6. 3P
Fases

Definicin del problema.

Identificacin de los procesos unitarios.
Diseo del prototipo.
Desarrollo del prototipo.
Prueba del prototipo.
Si <no prueba de Prototipo>ir a Paso 3.
Si <Prototipo difiere Sistema Deseado>ir a Paso 2.
Si <no Necesidades satisfechas>ir a Paso 2.
Implantacin.
Mantenimiento

Actividades
Codificar: Es necesario codificar y plasmar nuestras ideas a travs del cdigo
Hacer pruebas: Las caractersticas del software que no pueden ser demostradas
mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber
si lo implementado es lo que en realidad se tena en mente.

25

Escuchar: Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo

deseado, y tenemos que preguntar a quin necesita la informacin. Tenemos que
escuchar a nuestros clientes cules son los problemas de su negocio, debemos de
tener una escucha activa explicando lo que es fcil y difcil de obtener, y la
realimentacin entre ambos nos ayudan a todos a entender los problemas.
Disear: El diseo crea una estructura que organiza la lgica del sistema, un buen
diseo permite que el sistema crezca con cambios en un solo lugar.

4.4.

Artefactos

4.4.1. RUP

26

4.4.2. SCRUM

4.4.3. XP

27

4.4.4. AUP

4.4.5. DESARROLLO ADOPTATIVO DE SOFTWARE

28

4.4.6. 3P

5. Cuatro paradigmas del software

5.1. Nombre
5.1.1. Enfoque estructurado
5.1.2. Enfoque orientado a objetos
5.1.3. Enfoque orientado a Aspectos
5.1.4. Enfoque orientado a servicios

5.2.

Descripcin

5.2.1. ENFOQUE ESTRUCTURADO

El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o

automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o
para efectuar modificaciones a los ya existentes. El objetivo que persigue el anlisis
estructurado es organizar las tareas asociadas con la determinacin de requerimientos
para obtener la comprensin completa y exacta de una situacin dada.

29

Componentes:

Smbolos grficos: Son los iconos y convenciones para identificar y describir los
componentes de un sistema y las relaciones entre estos.

Diccionarios de datos: Descripciones de todos los datos utilizados en el sistema.

Puede ser manual o automatizado.

Descripciones de procesos y procedimientos: Declaraciones formales que

emplean tcnicas y lenguajes que permiten describir actividades importantes que
forman parte del sistema.

Reglas: Estndares para describir y documentar el sistema en forma correcta y

completa.

Diseo estructurado:

El diseo estructurado es una tcnica especfica que busca crear programas formados
por mdulos independientes unos de otros desde el punto de vista funcional y no
mostrar la lgica de los programas.
La herramienta fundamental del diseo estructurado es el diagrama estructurado, el
cual describe la interaccin entre mdulos independientes junto con los datos que un
mdulo pasa a otro cuando interacciona con l.
5.2.2. ENFOQUE ORIENTADO A OBJETOS

Anlisis y diseo orientado a objetos:

La orientacin a objetos puede describirse como el conjunto de disciplinas que
desarrollan y modelizar software que facilitan la construccin de sistemas complejos
a partir de componentes.
El atractivo intuitivo de la orientacin a objetos es que proporciona conceptos y
herramientas con las cuales se modela y representa el mundo real tan fielmente como
sea posible.
Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para construir
sistemas de software complejos a partir de unidades de software modularizado y
reutilizable. La orientacin a objetos trata de cubrir las necesidades de los usuarios
30

finales, as como las propias de los desarrolladores de productos software. Estas tareas
se realizan mediante la modelizacin del mundo real. El soporte fundamental es el
modelo objeto.
El anlisis orientado a objetos y su diseo se enfoca en los objetos. Los objetos tienen
ciertos comportamientos y atributos que determinan la manera en que interactan y
funcionan. No se intenta proporcionar un orden para las acciones al momento del
diseo debido a que los objetos funcionan basados en la manera en que funcionan
otros objetos.

Caractersticas Principales del Enfoque Orientado a Objetos:

Identidad: Los datos se organizan en entidades discretas y distinguibles llamadas

objetos. Estos objetos pueden ser concretos o abstractos, pero cada objeto tiene
su propia identidad.

Clasificacin: Los objetos que tengan los mismos atributos y comportamiento se

agrupan en clases. Una clase es una abstraccin que describe propiedades
(atributos y comportamiento) relevantes para una aplicacin determinada,
ignorando el resto.

Polimorfismo: El polimorfismo permite que una misma operacin pueda llevarse

a cabo de forma diferente en clases diferentes.

Herencia: El concepto de herencia se refiere al compartir de atributos y

operaciones basadas en una relacin jerrquica entre varias clases. Una clase
puede definirse de forma general y luego refinarse en sucesivas subclases. Cada
clase hereda todas las propiedades (atributos y operaciones) de su superclase y
aade sus propiedades particulares.

5.2.3. ENFOQUE ORIENTADO A ASPECTOS

Consiste en encapsular los conceptos diversos que existen en una aplicacin, en

entidades bien definidas. Al encapsularse logra una mejor razn sobre los conceptos
y as eliminar la dispersin de cdigo.
Las implementaciones resultan ms comprensibles, adaptables y reusables.

31

Busca resolver un problema de la separacin de incumbencias (separation of

concerns).
Objetivos:

Una mayor facilidad para razonar sobre las materias, ya que estn separadas y tienen
dependencia mnima.

Ms facilidad para depurar y hacer modificaciones en el cdigo.

Se tiene un cdigo reusable y que se puede acoplar y desacoplar cuando sea necesario.

Separa conceptos y minimiza las dependencias.

Qu es un aspecto?

Es una unidad definida en trminos de informacin parcial de otras unidades.

Es la unidad modular diseminada por la estructura de otras unidades funcionales.

Existen tanto en la etapa de diseo como en la implementacin.

Aspecto de Diseo:

Es una unidad modular de diseo que se entremezcla en la estructura de otras

partes del diseo.
Aspecto de programacin o de cdigo: Es una unidad modular del programa que
aparece en otras unidades modulares del programa.

Fundamentos de la POA:
Para que ambos (aspectos y componentes) se puedan mezclar, deben tener algunos
puntos comunes, que son los que se conocen como puntos de enlace, y debe haber
algn modo de mezclarlo.

5.2.4. ENFOQUE ORIENTADO A SERVICIOS

Es la utilizacin de servicios para dar soporte a los requerimientos del software
del usuario.

32

La Arquitectura Orientada a Servicios (SOA) es una tendencia creciente que

intenta reconciliar la visin tcnica y de negocios, basndose en estndares
abiertos y promoviendo la interoperabilidad entre diversas organizaciones y
plataformas de manera eficiente y flexible a los cambios.

Actualmente todos los proveedores de tecnologa estn abocados a soportar este

tipo de arquitecturas tanto en empresas pequeas en crecimiento como en grandes
corporaciones.

facilita el desarrollo de servicios comerciales que pueden integrarse y reutilizarse

fcilmente creando una infraestructura de IT verdaderamente flexible y adaptable.

Beneficios:

Reducir los costos y el tiempo de desarrollo: Los servicios SOA pueden

reutilizarse fcilmente y pueden convertirse en nuevas aplicaciones compuestas.

Reducir los costos de mantenimiento: Los servicios reutilizables reducen el

grado de complejidad interna de los servicios de IT.

Aumentar la calidad de los servicios: Una mayor reutilizacin de servicios crea

servicios de mejor calidad en mltiples ciclos de prueba de diferentes
consumidores de servicios.

Reducir los costos de integracin: Los servicios estandarizados pueden trabajar

en conjunto, permitiendo que las aplicaciones dispares se conecten con rapidez y
facilidad.

Reducir el riesgo: Menos servicios reutilizables brindan mayor control sobre las
polticas gubernamentales de IT y corporativas, y reducen el riesgo general
relacionado con el cumplimiento.

Incrementar la agilidad empresarial con la Arquitectura Orientada a Servicios

La Arquitectura Orientada a Servicios (SOA) constituye un enfoque arquitectnico

de TI que permite incrementar la agilidad empresarial mediante la alineacin de los
servicios y tecnologas de TI con los objetivos empresariales. Gracias a SOA, las
organizaciones pueden establecer un entorno que utilice servicios acoplados de forma
33

poco rgida para dar soporte a los requisitos de los negocios altamente competitivos
de hoy en da.

Visualizar la solucin empresarial completa con una SOA basada en modelos

Las soluciones para SOA de Telelogic permiten a los gestores visualizar la solucin
empresarial completa y controlar el desarrollo de servicios SOA. Se ofrece al negocio
y a las TI un workflow SOA, que abarca desde la planificacin empresarial y
arquitectnica hasta el desarrollo de nuevos servicios. Se ha creado una base que
permite a los usuarios empresariales definir las estrategias y los requisitos necesarios
para garantizar en mayor medida que los servicios SOA satisfagan sus necesidades.

Con las soluciones para SOA de Telelogic, puede alinear la estrategia de TI con sus
objetivos empresariales y controlar el desarrollo, la implementacin y el
mantenimiento de aplicaciones basadas en servicios.

5.3.

Ejemplo de aplicacin del paradigma

Web Services como tecnologa para implementar SOA.

Procesos de negocios (orquestacin y coreografa, WS-BPEL).

Bus de servicios (Concepto, Modelos, Patrones).

6. Ocho reas de conocimiento de la ingeniera de software

6.1.
6.1.1.
6.1.2.
6.1.3.
6.1.4.
6.1.5.
6.1.6.
6.1.7.
6.1.8.

Nombre
Diseo
Construccin
Pruebas
Gestin de la configuracin
Gestin de la ingeniera
Proceso de ingeniera
Herramientas y mtodos
Calidad
34

6.2.

Descripcin de rea

6.2.1. DISEO
El proceso de diseo de software consiste en analizar requisitos con el fin de
producir una descripcin de la estructura interna del software que sirva como base
para su construccin.
Un diseo software (resultado) debe describir:

La arquitectura y las interfaces entre dichos componentes.

Los componentes con el nivel de detalle adecuado para poder construirlos.

6.2.2. CONSTRUCCIN
Se refiere a la creacin detallada de software mediante la combinacin de
codificacin, verificacin, pruebas unitarias, pruebas de integracin y depuracin.

6.2.3. PRUEBAS
Sirve para evaluar la calidad de un producto de software o para mejorarlo, mediante
la identificacin de sus defectos y problemas.
Consiste en la verificacin dinmica del comportamiento real de un programa frente
al comportamiento esperado, parte un conjunto finito de casos de prueba.

6.2.4. GESTIN DE LA CONFIGURACIN

Es la disciplina de identificar la configuracin de un sistema en distintos momentos
en el tiempo con el fin de controlar sistemticamente los cambios y mantener la
integridad y trazabilidad.
Una configuracin de un sistema es una coleccin de versiones especficas de sus
elementos combinados de acuerdo a procedimientos de construccin adecuados a
los propsitos buscados.

6.2.5. GESTIN DE LA INGENIERA

Consiste en aplicar actividades de gestin para asegurar que el desarrollo y
mantenimiento de software se realizan de forma sistemtica, disciplinada y
cuantificable.
35

Bsicamente, engloba dos clases de esfuerzos:

Gestin de proyectos
Medicin

6.2.6. PROCESO DE INGENIERA

Se refiere a la definicin, implementacin, evaluacin, medicin, gestin, cambio y
mejora de los propios procesos de ciclo de vida del software.
Engloba aspectos con fuerte impacto en la industria:

Madurez de las organizaciones

Mejora de procesos

Por ello ha surgido la llamada ingeniera de procesos de software.

6.2.7. HERRAMIENTAS Y MTODOS

Las herramientas ayudan a realizar los procesos del ciclo de vida del software.
Los mtodos imponen una manera o estructura para realizar las actividades de
ingeniera del software, de forma que el trabajo sea ms sistemtico y ms exitoso.

6.2.8. CALIDAD
En esta rea se abordan las tcnicas estticas para alcanzar la calidad del software.

Las tcnicas dinmicas son parte de las pruebas.

Este campo tambin ha tenido un fuerte desarrollo de la industria:

Aseguramiento de la calidad.
Verificacin y validacin
Auditora

36

7. Elementos de un proyecto de desarrollo de software

EL PERSONAL
El factor humano siempre ser el ms importante en el desarrollo de soluciones software,
muchos empresarios famosos, lderes de empresas tecnolgicas, coinciden que el xito
que han alcanzado sus empresas no se debe a las herramientas que utilizan, es la gente y
el trabajo en equipo.

EL PRODUCTO
Muchas veces cuando un cliente pide que le construyan una solucin, siempre pregunta
cunto me va a costar? Pues bien, todo producto requiere estimaciones cuantitativas y
una adecuada planificacin. Una adecuada recoleccin de informacin y un anlisis
detallado de los requerimientos proporciona la informacin necesaria para dar una
estimacin del costo del producto. Antes de planear un proyecto, se debe establecer los
objetivos y el alcance que tendr el proyecto, adems de sus restricciones tcnicas y de
gestin. Con una buena planificacin se puede estimar el tiempo que tomar desarrollar
o construir el producto y redimensionar el valor cuantitativo del producto.

EL PROCESO
El proceso del software proporciona un marco de trabajo desde el cual se puede establecer
un plan detallado para la construccin del software. Todas las actividades del marco de
trabajo se las pueden aplicar a la mayora de proyectos de software, sino es a todos. El
equipo de desarrollo debe elegir el proceso adecuado y que le permita obtener una
solucin o producto que satisfaga las necesidades o requerimientos del cliente.

EL PROYECTO
Cuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a
fracasar. Segn John Reel, existen 10 razones por las cuales un proyecto puede fracasar:
1. El personal de software no entiende las necesidades de los clientes.

37

2. El mbito del producto est mal definido.

3. Los cambios se gestionan mal.
4. La tecnologa elegida cambia.
5. Las necesidades comerciales cambian.
6. Los plazos de entrega no son realistas.
7. Los usuarios se resisten a la utilizacin del software.
8. Se pierde el patrocinio.
9. El equipo del proyecto carece de personal con las habilidades apropiadas.
10. Los gestores evitan las mejores prcticas y las lecciones aprendidas.

8. Conclusiones
En el desarrollo del trabajo investigativo se pudo concluir, que se entendieron diferentes
metodologas y conceptos tales como:
Disear aplicaciones informticas que se ajusten a las necesidades de las
organizaciones.
Dirigir y coordinar el desarrollo de aplicaciones complejas.
Intervenir en todas las fases del ciclo de vida de un producto.
Estimar los costes de un proyecto y determinar los tiempos de desarrollo.
Hacer el seguimiento de costes y plazos.
Dirigir equipos de trabajo de desarrollo software.
Organizar la realizacin de pruebas que verifiquen el correcto funcionamiento de los
programas y que se ajustan a los requisitos de anlisis y diseo.
Disear, construir y administrar bases de datos.
Dirigir y asesorar a los programadores durante el desarrollo de aplicaciones.
Introducir procedimientos de calidad en los sistemas, evaluando mtricas e
indicadores y controlando la calidad del software producido.

9. Bibliografa

38

http://helisulbaransistemas.blogspot.com.co/2014/09/paradigmas-en-el-desarrollode-software.html
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html

http://www.etsisi.upm.es/estudios/grados/software/objetivos
http://www.buenastareas.com/ensayos/Metodologia-3P/5885628.html

http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm

https://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARR
OLLO+DE+SOFTWARE

http://www.monografias.com/trabajos60/metodologias-desarrollosoftware/metodologias-desarrollo-software.shtml

http://ingenieriasoftbejarano.blogspot.com.co/2012/10/caracteristicas-y-tipos-desoftware.html

http://www.academia.edu/5767578/INGENIER%C3%8DA_DEL_SOFTWARE_I_
Tema_1_Tema_1_Introducci%C3%B3n_a_la_Ingenier%C3%ADa_del_Software

http://arelyescobar.bligoo.com.mx/paradigmas-de-la-ingenieria-de-software

https://sites.google.com/site/paradigmasdelais/4-1-el-enfoque-estructurado

http://es.slideshare.net/carlossing/paradigmas-de-la-programacion-202983

39