INGENIERIA DE SOFTWARE

TRABAJO INVESTIGATIVO # 1

Presentado por:

JULIAN DAVID MARQUEZ FUENTES

SEBASTIAN GAMBOA BAUTISTA
FREDY ENRIQUE GALINDO OSMA
DAMIAN SAMAEL TOVAR BOHORQUEZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLOGICA
TECNOLOGIA EN SISTEMATIZACION DE DATOS
INGENIERIA DE SOFTWARE
SEPTIEMBREDE 2016

INGENIERIA DE SOFTWARE
TRABAJO INVESTIGATIVO # 1

Presentado por:
DAMIAN SAMAEL TOVAR BOHRQUEZ 20132578120
SEBASTIN GAMBOA BAUTISTA 20131078091
FREDY ENRIQUE GALINDO OSMA 20132578018
JULIAN DAVID MRQUEZ FUENTES - 20122078213
Presentado a:
JUAN CARLOS GUEVARA BOLAOS

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLOGICA
TECNOLOGIA EN SISTEMATIZACION DE DATOS
INGENIERIA DE SOFTWARE
SEPTIEMBRE DE 2016

Introduccin
Hoy en da, el software es una parte integral de la mayora de los sistemas. Para
ejecutar proyectos software de forma satisfactoria y construir productos de alta
calidad, los profesionales del software necesitan entender las caractersticas nicas
del software y el enfoque usado para desarrollar y mantener software. Este curso
permitir entender qu es el software y cules son los objetivos y componentes de la
ingeniera del software, as como entender los conceptos de ciclo de vida del software
y metodologa. Adems, se vern los principales modelos de ciclo de vida del software
y la diferenciacin entre metodologas tradicionales y giles.

Ingeniera de Software

Definicin
La ingeniera del software es una disciplina de la ingeniera que comprende los
aspectos de la produccin del software desde el inicio hasta el mantenimiento,
existen dos frases claves:
1. Disciplina de la ingeniera: Todo ingeniero aplica teoras, mtodos y
herramientas, que utilizan de una forma selectiva para poder solucionar
el problema, tambin tienen restricciones en su trabajo, restricciones
financieras y organizacionales.
2. Todos los aspectos de la produccin de software: Esta rama no solo
comprende los procesos tcnicos de un desarrollo de software, sino que
tambin actividades de gestin de proyectos y desarrollo de
herramientas.
En conclusin, los ingenieros de software tienen un enfoque sistemtico y
organizado, ya que esta es la forma ms efectiva de crear un software de alta
calidad.
Ingeniera del Software es la aplicacin prctica del conocimiento cientfico en el
diseo y construccin de programas de computadora y la documentacin asociada
requerida para desarrollar, operar y mantenerlos. Se conoce tambin como
desarrollo de software o produccin de software.

Objetivos

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.
Organizar y supervisar el trabajo de su equipo de los tcnicos de
mantenimiento y los ingenieros de sistemas y redes.

Caractersticas

El software se desarrolla, no se fabrica.

El software no se descompone, se echa a perder.
Aunque la industria tiende a ensamblar componentes, la mayora del
software es hecho a la medida.

Ilustracin 1 Caractersticas del software

http://ingenieriasoftbejarano.blogspot.com.co/2012/10/caracteristicas-y-tiposde-software.html

Historia
Durante los primeros aos de la informtica, el software era un aadido. La
programacin se consideraba un "arte", para el que no existan metodologas, era
un proceso que se realizaba sin planificacin alguna, la programacin se
desarrollaba a medida para cada necesidad concreta, y en consecuencia tena
muy poca difusin.
En una segunda poca se estableci el software como producto y aparecieron las
empresas dedicadas al desarrollo y distribucin masiva del mismo. El origen del

trmino Ingeniera del Software, como se ha visto previamente se atribuye a dos

conferencias organizadas por la OTAN en 1967 y 1968
La tercera era comenz a mediados de la dcada de 1970, poca en la que los
sistemas informticos aumentaron mucho en su complejidad, y nacieron las redes
de ordenadores. Esto supuso mucha presin para los desarrolladores, aunque los
ordenadores para uso personal, apenas estaban difundidos. Esta poca acab
con la aparicin de los microprocesadores.
La cuarta era de la evolucin de los sistemas informticos, comienza hacia 1990 y
se dirige al impacto colectivo de los ordenadores y el software, en todos los
entornos. Aparecen las tcnicas de redes neuronales, junto con la lgica difusa, de
inters en el campo de la Inteligencia Artificial.
En una segunda poca (a partir de mitad de la dcada de 1960) se estableci el
software como producto y aparecieron las empresas dedicadas al desarrollo y
distribucin masiva del mismo. El origen del trmino Ingeniera del Software, como
se ha visto previamente se atribuye a dos conferencias organizadas por la OTAN
en 1967 y 1968.

Ilustracin 2 Historia del Software:

http://gestionrrhhusm.blogspot.com.co/2011/05/modelo-rup-rational-unifiedprocess-o.html

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. El
software hace entrega de lo que se considera como el producto ms importante del
siglo veintiuno, la informacin. Este transforma datos personales para que sean ms
tiles en un entorno local, gestiona informacin comercial para mejorar la
competitividad, proporciona el acceso a redes a nivel mundial, y ofrece el medio de
adquirir informacin en todas sus formas.

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.
Actualmente existe sobredemanda de profesionales altamente cualificados,
sucede principalmente en las grandes industrias, como Google, Facebook, Twitter
y otras grandes compaas que ms que competir, combaten entre s para captar
a los valiosos egresados de las principales universidades. La ingeniera del
software trata reas muy diversas de la informtica y de las Ciencias de la
Computacin, aplicables a un amplio espectro de campos, tales como negocios,
investigacin cientfica, medicina, produccin, logstica, banca, meteorologa,
derecho, redes, entre otras muchas.
Ciclos de vida del Software
Los modelos de ciclo de vida de software son una lista de las actividades que ocurren
durante el desarrollo de software, en el cual se intenta determinar el orden de las
etapas involucradas y los criterios de transicin asociadas entre estas etapas.

Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se
desarrolla un proyecto de desarrollo de software.
Modelo Cascada
Es el modelo ms bsico y ha servido como bloque de construccin para los
dems paradigmas de ciclo de vida. Est basado en el ciclo convencional de una
ingeniera y su visin es muy simple: el desarrollo de software se debe realizar
siguiendo una secuencia de fases. Cada etapa tiene un conjunto de metas bien
definidas y las actividades dentro de cada una contribuyen a la satisfaccin de
metas de esa fase o quizs a una sub secuencia de metas de la misma. El
arquetipo del ciclo de vida abarca las siguientes actividades:

1.
2.
3.
4.
5.
6.
7.

Anlisis de requisitos.
Diseo del Sistema.
Diseo del Programa.
Codificacin.
Pruebas.
Implantacin.
Mantenimiento.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce

necesariamente al rediseo y nueva programacin del cdigo afectado,
aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la
metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un
cambio en las fases ms avanzadas de un proyecto.
Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria,
sigue siendo el paradigma ms seguido al da de hoy.

Funcionamiento

Anlisis de requerimientos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada
SRD (documento de especificacin de requisitos), que contiene la especificacin
completa de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante sealar que en esta etapa se debe consensuar todo lo que se
requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no
pudindose requerir nuevos resultados a mitad del proceso de elaboracin del
software.

Diseo del Sistema

Descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseo del Software), que contiene la descripcin de
la estructura relacional global del sistema y la especificacin de lo que debe hacer
cada una de sus partes, as como la manera en que se combinan unas con otras.
Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo
detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin
(una vez que la fase de anlisis ha descrito el problema) identificando grandes
mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con
ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos
empleados y la organizacin del cdigo para comenzar la implementacin.

Diseo del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de
los requerimientos del usuario, as como tambin los anlisis necesarios para
saber que herramientas usar en la etapa de Codificacin.

Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos,
as como de pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y

componentes reutilizables dentro del mismo proyecto para hacer que la
programacin sea un proceso mucho ms rpido.

Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de
ser entregado al usuario final.
Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema
no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de
investigacin y pruebas del mismo
Mantenimiento
Una de las etapas ms crticas, ya que se destina un 75% de los recursos, es el
mantenimiento del Software ya que al utilizarlo como usuario final puede ser que
no cumpla con todas nuestras expectativas.

Modelo Espiral
El desarrollo en espiral es un modelo de ciclo de vida del software definido por
primera vez por Barry Boehm en 1986 dndole la direccin nueva al modelo en el
cual fue incorporar los puntos fuertes y evitar las dificultades de otros modelos
desplazando el nfasis de administracin hacia la evaluacin y resolucin del
riesgo. De esta manera se permite tanto a los desarrolladores como a los clientes
detener el proceso cuando se lo considere conveniente, utilizado generalmente en
la Ingeniera de software.
Las actividades de este modelo se conforman en una espiral, en la que cada
bucle o iteracin representa un conjunto de actividades. Las actividades no estn
fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis
de riesgo, comenzando por el bucle interior.

Funcionamiento

En cada vuelta o iteracin hay que tener en cuenta:

Los Objetivos: qu necesidad debe cubrir el producto.

Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa,
desde
diferentes puntos de vista como pueden ser:

1. Caractersticas: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestin del sistema.
3. Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o
funcionalidades:

Se planificarn los siguientes pasos y se comienza un nuevo ciclo de la espiral.

La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la
radial y la angular:
1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva
iteracin se pasa ms tiempo desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser,
por ejemplo, la creacin de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno
de los aspectos fundamentales de su xito radica en que el equipo que lo aplique
tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente
los riesgos.

Modelo de desarrollo concurrente

El Modelo de Desarrollo Concurrente conocido adems como Ingeniera
Concurrente dado por Davis Sitaram, se puede representar en forma de esquema
como una serie de actividades tcnicas importantes, tareas y estados asociados a
ellas.
Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor.
Provee una meta-descripcin del proceso del software. El modelo concurrente
tiene la capacidad de describir las mltiples actividades del software ocurriendo
simultneamente.
La mayora de los modelos de procesos de desarrollo del software son dirigidos
por el tiempo; cuanto ms tarde sea, ms atrs se encontrar en el proceso de
desarrollo. Un modelo de proceso concurrente est dirigido por las necesidades
del usuario, las decisiones de la gestin y los resultados de las revisiones.

Funcionamiento

El modelo de proceso concurrente define una serie de acontecimientos que

dispararn transiciones de estado a estado para cada una de las actividades de la
ingeniera del software. Durante las primeras etapas del diseo, no se contempla
una inconsistencia del modelo de anlisis. Esto genera la correccin del modelo
de anlisis de sucesos, que disparar la actividad de anlisis del estado hecho al
estado cambios en espera.

Esto genera la correccin del modelo de anlisis de sucesos, que disparar la

actividad de anlisis del estado hecho al estado cambios en espera. Es un modelo de
tipo de red donde todas las personas actan simultneamente o al mismo tiempo.

Un sistema cliente/servidor se compone de un conjunto de componentes

funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso
concurrente define actividades en dos dimensiones:
1 Dimensin de sistemas.
2 Dimensin de componentes.
Los aspectos de nivel del sistema se afrontan mediante tres actividades: diseo,
ensamblaje y uso. En realidad, el modelo de proceso concurrente es aplicable a
todo tipo de desarrollo de software y proporciona una imagen exacta del estado
actual de un proyecto.
La concurrencia se logra de dos formas:
1 Las actividades de sistemas y de componentes ocurren simultneamente y
pueden modelarse con el enfoque orientado a objetos.
2 Una aplicacin cliente/servidor tpico se implementa con muchos
componentes, cada uno de los cuales se pueden disear y realizar
concurrentemente.
Modelo incremental
El Modelo Incremental combina elementos del MLS con la filosofa interactiva de
construccin de prototipos. En una visin genrica, el proceso se divide en 4
partes: Anlisis, Diseo, Cdigo y Prueba.
Sin embargo, para la produccin del Software, se usa el principio de trabajo en
cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto
se mantiene al cliente en constante contacto con los resultados obtenidos en cada
incremento.
Es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades reales. El
proceso se repite hasta que se elabore el producto completo. De esta forma el
tiempo de entrega se reduce considerablemente.

Al igual que los otros mtodos de modelado, el Modelo Incremental es de

naturaleza interactiva, pero se diferencia de aquellos en que al final de cada
incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente til cuando no se cuenta con una
dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo
reducido de personas y en cada incremento se aadir personal, de ser necesario.
Por otro lado, los incrementos se pueden planear para gestionar riesgos tcnicos.
Funcionamiento

- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.
- El usuario se involucra ms.
- Difcil de evaluar el coste total.
- Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.

Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo
de datos en un proceso comprendido por varias fases secuenciales, siendo la
entrada de cada una la salida de la anterior.
Esta arquitectura es muy comn en el desarrollo de programas para el intrprete
de comandos, ya que se pueden concatenar comandos fcilmente con tuberas
(pipe). Tambin es una arquitectura muy natural en el paradigma de programacin
funcional, ya que equivale a la composicin de funciones matemticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos
obtenidos del usuario por medio de una interfaz alfanumrica.
Caractersticas
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.
- El usuario se involucre ms.
- Difcil de evaluar el costo total.
- Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Modelo Prototipo
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se
construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en
los que se aseguren que el desarrollador, el usuario, el cliente estn de acuerdo en lo
que se necesita as como tambin la solucin que se propone para dicha necesidad y
de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se
encarga del desarrollo de diseos para que estos sean analizados y prescindir de
ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el
alcance del producto ,pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de
objetivos generales para el software a desarrollarse sin delimitar detalladamente los
requisitos de entrada procesamiento y salida, es decir cuando el responsable no

est seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la

forma en que interacta el hombre y la mquina. Este modelo se encarga
principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor
manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos.
Funcionamiento

Una maqueta o prototipo de pantallas muestra la interfaz de la aplicacin, su cara

externa, pero dicha interfaz est fija, esttica, no procesa datos. El prototipo no
tiene desarrollada una lgica interna, slo muestra las pantallas por las que ir
pasando la futura aplicacin.
Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que
satisface los requisitos y necesidades que se han entendido claramente. Realiza,
por tanto, un proceso real de datos, para contrastarlo con el usuario. Se va
modificando y desarrollando sobre la marcha, segn las apreciaciones del cliente.
Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el
software est constantemente variando, pero, a la larga, genera un producto ms
seguro, en cuanto a la satisfaccin de las necesidades del cliente.
Cuando un prototipo se desarrolla con el slo propsito de precisar mejor las
necesidades del cliente y despus no se va a aprovechar ni total ni parcialmente
en la implementacin del sistema final se habla de un prototipo desechable.

Para que la construccin de prototipos sea posible se debe contar con la

participacin activa del cliente.
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.
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.

Funcionamiento

Planeacin: En esta etapa evala la funcin y el rendimiento que se asignaron al

Software durante la Ingeniera del Sistema de Computadora para establecer un
mbito de proyecto que no sea ambiguo, e incomprensible.
Anlisis de riesgos: en esta etapa, el analista se encarga de analizar los riesgos
que el software a crear estar expuesto y as encontrar la manera de corregirlos.
Construccin y adaptacin de la ingeniera: en esta etapa se construye el
software, se prueba si no tiene algn problema o para detectar errores, se instala,
y luego se le brinda soporte al cliente.
Evaluacin del cliente: el cliente tiene la tarea de evaluar el software para verificar
si este cumple con los requisitos que este proporciono y est en toda la tarea de
aprobar o rechazar el software.

Metodologas de desarrollo del software

Antes de iniciar con la descripcin y fases de cada una de las metodologas
propuestas en este documento, debemos saber que existen metodologas de
desarrollo agiles y tradicionales que son usadas para cada tipo de proyecto,
teniendo estas caractersticas distintas que se acoplaran a cada necesidad. A
continuacin, analizaremos las diferencias existentes entre estos dos tipos de
metodologas a travs del siguiente cuadro, con el fin de entender terminologas
que pueden nombrarse en la especificacin de las metodologas de las cuales
hablaremos ms adelante:

Metodologa RUP
Qu es?
La metodologa RUP o Proceso Unificado Racional (Rational Unified Process), es
un proceso de ingeniera de software que est orientado a la asignacin de tareas
y roles dentro de un proyecto de desarrollo. Esta metodologa tiene como objetivo
principal asegurar un desarrollo de software ptimo para as poder cumplir todas
las necesidades que tiene el usuario previsto en un lmite de tiempo acordado y
con un presupuesto manejable o previsible.
Por qu usarla?
La metodologa RUP es una metodologa que es muy completa y extensa que al
estar orientada a la asignacin de roles y tareas permite una mejor organizacin
en cualquier proyecto pequeo de software que dure algunos meses hasta a un
proyecto de software de gran escala que dure aos.
Qu caractersticas tiene esta metodologa?
La metodologa RUP consta de las siguientes caractersticas:
- Es dirigida por casos de uso: Los casos de uso son implementados para capturar
los requisitos de importancia que tiene el usuario, no solo desde el punto de vista
de funcionalidad del sistema que vayamos a realizar, sino tambin de los actores
que se vern identificados en el uso del mismo. Adems, la implementacin de los
casos de uso nos ayuda en la gua del diseo que le dar al sistema, en su
implementacin y en la verificacin de pruebas que se le hagan al mismo.
En la siguiente figura podemos ver el papel fundamental que cumplen los casos de
uso en la metodologa RUP:

En la anterior imagen podemos ver que los casos de uso no solo inician el proceso de
desarrollo, sino que se une o encadena a otros procesos, como lo son su anlisis,
diseo, su implementacin y respectivas pruebas segn el sistema a desarrollar.

- Tiene un proceso centrado en la arquitectura: Entendiendo arquitectura como el

proceso donde se organiza o se extrae las partes ms relevantes en el desarrollo
de un sistema en el que estn involucradas ambas partes (desarrolladores y
usuarios). Esto se hace con el fin de tener una perspectiva clara del sistema a
desarrollar y tener un completo control del mismo.
La arquitectura tiene una estrecha relacin con los casos de uso que vemos
anteriormente puesto que cuando se realizan los casos de uso, all tambin se ve
reflejada su arquitectura, llevando esto a que exista una iteracin entre la
arquitectura del sistema y los casos de uso realizados; con esto se quiere decir
que, al existir dicha relacin, los casos de uso y la arquitectura deben evolucionar
paralelamente. Para esto, la estrategia que se propone en RUP es tener un
proceso iterativo e incremental en donde el trabajo se divide en partes ms
pequeas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y
arquitectura se vaya logrando durante cada mini proyecto, as durante todo el
proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin (un
recorrido ms o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un crecimiento en
el producto. Para entenderlo un poco mejor, analizaremos el siguiente grfico:

El proceso iterativo consta de varias secuencias o pasos que anteriormente lo

denominbamos como "mini proyectos", que abordan una parte pequea de la
funcionalidad total del sistema. Cada iteracin se analiza cuando termina, buscando
con esto si hay alteraciones o modificaciones en la siguiente iteracin. Las ventajas
que tiene el desarrollo por iteraciones es que permite analizar los posibles riesgos que
existen en el desarrollo y la bsqueda de una solucin ms rpida y efectiva.

Qu fases tiene?
La metodologa RUP consta de las siguientes fases:

Fase de Inicio
Fase de Elaboracin
Fase de desarrollo
Fase de cierre.

Fase de Inicio: Durante esta fase se define el modelo del negocio y el alcance que
le queremos dar a nuestro proyecto. Es aqu donde hacemos los diferentes casos
de uno e identificamos los actores que intervienen y los roles que realizan en el
mismo, adems de realizar el desarrollo del plan de negocio donde se va a
determinar el uso y asignacin de recursos para el desarrollo del proyecto.
Esta fase tiene como objetivos finales los siguientes:
- Establecer el mbito del proyecto, as como sus lmites.
- Realizar los casos de uso fundamentales para el sistema adems de definir los
escenarios bsicos de funcionalidad.
- Mostrar arquitecturas candidatas para el desarrollo de los escenarios principales.

- Estimar coste de recursos y tiempo de desarrollo para el proyecto, asi mismo

como los posibles riesgos implcitos en el mismo.

Los resultados de esta fase son:

-

Un documento general donde estn establecidos los requerimientos del

proyecto as como sus caractersticas claves y sus restricciones principales.
Modelo inicial de los casos de uso (Un promedio del 20% de estos
diagramas).
Glosario que me determina la terminologa clave del dominio del sistema.

El caso del negocio

Una lista que tenga los riesgos y el plan de contingencia del proyecto a
desarrollar.
Una arquitectura candidata a emplear.

Fase de elaboracin: El propsito de la fase de elaboracin es analizar el dominio

del problema, establecer los cimientos de la arquitectura, desarrollar el plan del
proyecto y eliminar los mayores riesgos. En esta fase se construye un prototipo de
la arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse
en el sistema final. Este prototipo debe contener los Casos de Uso crticos
identificados en la fase de inicio. Tambin debe demostrarse que se han evitado
los riesgos ms graves.
Los objetivos de esta fase son:
-

Definir, validar y cimentar la arquitectura.

Completar la visin.
Crear un plan fiable para la fase de construccin. Este plan puede
evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.
Demostrar que la arquitectura propuesta soportar la visin con un coste
razonable y en un tiempo razonable.

Al terminar deben obtenerse los siguientes resultados:

-

Un modelo de Casos de Uso completa al menos hasta el 80%: todos los

casos y actores identificados, la mayora de los casos desarrollados.
Requisitos adicionales que capturan los requisitos no funcionales y
cualquier requisito no asociado con un Caso de Uso especfico.
Descripcin de la arquitectura software.
Un prototipo ejecutable de la arquitectura.
Lista de riesgos y caso de negocio revisados.
Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especifica el proceso a seguir.
Un manual de usuario preliminar (opcional).

Fase de desarrollo: La finalidad principal de esta fase es alcanzar la capacidad

operacional del producto de forma incremental a travs de las sucesivas
iteraciones. Durante esta fase todos los componentes, caractersticas y requisitos
deben ser implementados, integrados y probados en su totalidad, obteniendo una
versin aceptable del producto.

Los objetivos de desarrollo son:

-

Minimizar los costes de desarrollo mediante la optimizacin de recursos y

evitando el tener que rehacer un trabajo o incluso desecharlo.
Conseguir una calidad adecuada tan rpido como sea prctico.

Los resultados de la fase de construccin deben ser:

-

Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e

Implementacin)
Arquitectura ntegra (mantenida y mnimamente actualizada)
Riesgos Presentados Mitigados
Plan del Proyecto para la fase de Transicin.
Manual Inicial de Usuario (con suficiente detalle)
Prototipo Operacional beta
Caso del Negocio Actualizado

Fase de Cierre: La finalidad de la fase de cierre es poner el producto en manos de

los usuarios finales, para lo que se requiere desarrollar nuevas versiones
actualizadas del producto, completar la documentacin, entrenar al usuario en el
manejo del producto, y en general tareas relacionadas con el ajuste, configuracin,
instalacin y facilidad de uso del producto.
Los principales objetivos de esta fase son:
-

Conseguir que el usuario se valga por s mismo.

Un producto final que cumpla los requisitos esperados, que funcione y
satisfaga suficientemente al usuario.

Los resultados de la fase de cierre son:

-

Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Lnea de Base del Producto completa y corregida que incluye todos los
modelos del sistema
Descripcin de la Arquitectura completa y corregida
Las iteraciones de esta fase irn dirigidas normalmente a conseguir una
nueva versin

Metodologa XP
Qu es?
La metodologa XP o Programacin Extrema (Extreme Programming) es una
metodologa gil centrada en las relaciones interpersonales, el trabajo en equipo,
el continuo aprendizaje de los integrantes de trabajo, dar soluciones sencillas a los
problemas planteados pero que estas cumplan con la solucin completa de los
mismos.
Por qu usarla?
Es conveniente usar la metodologa XP porque es una metodologa liviana,
queriendo decir esto que es muy fcil de manejar y dar rpidos resultados,
adems de manejar un conjunto de prcticas para el desarrollo de software
tambin est basada en diferentes ideas acerca de cmo enfrentar un problema
en ambientes cambiantes y, para terminar es una metodologa que en vez de
planificar y analizar todo el diseo, arquitectura y lgica de desarrollo, lo va
haciendo un poco cada vez mientras se va avanzando en el proyecto siendo agiles
en el manejo de riesgos que pongan en peligro el proyecto.
Qu caractersticas tiene esta metodologa?
La metodologa XP tiene las siguientes caractersticas:
- Es una metodologa basada en prueba y error para obtener un software que
realmente funcione: Es decir, consiste en probar una alternativa y verificar si
funciona; si esta funciona entonces, ya se tiene una solucin. En caso contrario es
necesario probar una nueva alternativa. Se usa este mtodo porque es un mtodo
orientado a soluciones, es decir, que no se intenta descubrir porque funciona la
alternativa, simplemente solo se busca alcanzar la solucin; se busca la solucin a
un problema especfico y no a problemas externos o adicionales, pero es costoso
debido a que se necesitan varios medios para poder llegar a una solucin que
quizs es posible no encontrarla.
-

Est orientada hacia quien produce y usa el software: Es decir, que se tiene
mucho en cuenta al cliente y/o usuario, haciendo ellos parte del equipo de
trabajo que colaborara con la solucin del problema.
Combina las mejores prcticas de desarrollo de software llevndolas al
extremo, de ah el nombre de la metodologa.

Los requisitos del sistema pueden cambiar sin que exista un alto riesgo de
prdida de recursos puesto que no se analiza a futuro como habamos
dicho anteriormente, sino que se va haciendo a medida que le damos
avance al proyecto.
Es una excelente metodologa para pequeos proyectos y se suele trabajar
de a pares teniendo un mximo de 12 integrantes de trabajo.
El equipo de trabajo tiene la oportunidad de ampliar sus conocimientos
continuamente.

Qu fases tiene?
La metodologa XP consta de 4 fases principales que son:

Fase de planificacin de proyecto

Fase de diseo
Fase de codificacin
Fase de pruebas

Fase de planificacin del proyecto: Esta fase est delimitada por las siguientes
prcticas:
- Historias de usuario: El primer paso a realizar en cualquier proyecto de
software que se desarrolle con esta metodologa debe empezar en definir la
historia del usuario con el cliente. Estas historias tienen la misma finalidad que
los casos de uso pero con la diferencia de que no se toman en cuenta los
detalles y se toma desde el punto de vista del cliente, es decir, en un lenguaje
que no es tcnico. Esto se hace con el fin de estimar tiempos de desarrollo con
lo que el cliente describe en su escrito.
- Release Planning: es una planificacin donde los desarrolladores y clientes
establecen tiempo de implementacin ideales en base a la historia del usuario,
la prioridad con que ser implementada y el tiempo en que tardara en
publicarse las diferentes versiones del programa y se especifica de qu
manera ser evaluado el trabajo desarrollado.
- Iteraciones: La metodologa XP suele desarrollarse en iteraciones de 3
semanas aproximadamente. En cada iteracin los clientes seleccionan las
historias de usuario definidas en el punto anterior.
- Velocidad del proyecto: Es una medida que representa la rapidez con que se
desarrolla un proyecto. Calcularla es muy fcil porque se cuenta el nmero de
historias de usuario que pueden ser implementadas, as sabiendo el nmero de
historias que podrn ser desarrolladas en cada iteracin. Esta etapa se
reevala cada 3 o 4 iteraciones puesto que estn sujetas al cambio.

Programacin en pareja: Se usa debido a que incrementa la productividad y

calidad del software desarrollado. Es ventajoso debido a que es un grupo
compacto, que es fcil de manejar, y que existe ms probabilidad de que se
consiga un cdigo y diseo de alta calidad.
Reuniones diarias: Con el fin de exponer problemas, soluciones e ideas de
forma conjunta para hacer una lluvia de ideas y colaborarse entre s.

Fase de diseo: Esta fase est delimitada por las siguientes prcticas:
- Diseos simples: Se busca hacer todo lo menos complicado posible para
conseguir un diseo fcilmente entendible e implementarle que necesite menos
tiempo y esfuerzo para desarrollarlo.
- Glosario de trminos: Usar glosarios de trminos y una correcta especificacin
de los nombres de mtodos y clases ayudar a comprender el diseo y
facilitar sus posteriores ampliaciones y la reutilizacin del cdigo.
- Riesgos: Se sugiere que unas pajeras de desarrolladores estn dedicadas
solamente a investigar y reducir lo mximo posible el o los riesgos que se
puedan presentar en la solucin del problema.
- Funcionalidad extra: No se toma en cuenta una funcionalidad extra debido a
que segn esta metodologa, el desarrollo de esta funcionalidad requiere un
desperdicio de tiempo y recursos en una funcionalidad que probablemente no
vaya a ser tomada en cuenta.
- Refactorizar: Esto se realiza con el fin de modificar y mejorar la estructura y
codificacin de cdigos ya creados sin alterar su funcionalidad. En pocas
palabras, es volverlos a revisar para poderlos optimizar dado el caso.
- Tarjetas C.R.C: El uso de tarjetas de clases, responsabilidades y colaboracin
permiten al programador centrarse y apreciar el desarrollo orientado a objetos
olvidndose as de la programacin clsica.
Fase de codificacin: Como ya habamos comentado en la fase de planificacin
del proyecto, el cliente es una parte ms del equipo de desarrollo; su presencia es
indispensable en las distintas fases de XP. A la hora de codificar una historia de
usuario su presencia es an ms necesaria. No olvidemos que los clientes son los
que crean las historias de usuario y negocian los tiempos en los que sern
implementadas. Antes del desarrollo de cada historia de usuario el cliente debe
especificar detalladamente lo que sta har y tambin tendr que estar presente
cuando se realicen los test que verifiquen que la historia implementada cumple la
funcionalidad especificada.

La codificacin debe hacerse ateniendo a estndares de codificacin ya creados.

Programar bajo estndares mantiene el cdigo consistente y facilita su
comprensin y escalabilidad.
Crear test que prueben el funcionamiento de los distintos cdigos implementados
nos ayudar a desarrollar dicho cdigo. Crear estos test antes nos ayuda a saber
qu es exactamente lo que tiene que hacer el cdigo a implementar y sabremos
que una vez implementado pasar dichos test sin problemas ya que dicho cdigo
ha sido diseado para ese fin. Se puede dividir la funcionalidad que debe cumplir
una tarea a programar en pequeas unidades, de esta forma se crearn primero
los test para cada unidad y a continuacin se desarrollar dicha unidad, as poco a
poco conseguiremos un desarrollo que cumpla todos los requisitos especificados.
Fase de Pruebas: Uno de los pilares de la metodologa XP es el uso de test para
comprobar el funcionamiento de los cdigos que vayamos implementando.
El uso de los test en X.P debe cumplir las siguientes condiciones:
-

Se deben crear las aplicaciones que realizarn los test con un entorno de
desarrollo especfico para test.
Hay que someter a test las distintas clases del sistema omitiendo los mtodos
ms triviales.
Se deben crear los test que pasarn los cdigos antes de implementarlos.
Un punto importante es crear test que no tengan ninguna dependencia del
cdigo que en un futuro evaluar. Hay que crear los test abstrayndose del
futuro cdigo, de esta forma aseguraremos la independencia del test respecto
al cdigo que evala.
El uso de los test es adecuado para observar la refactorizacin. Los test
permiten verificar que un cambio en la estructura de un cdigo no tiene por qu
cambiar su funcionamiento.
Test de aceptacin: Los test mencionados anteriormente sirven para evaluar
las distintas tareas en las que ha sido dividida una historia de usuario.
Para asegurar el funcionamiento final de una determinada historia de usuario
se deben crear "Test de aceptacin"; estos test son creados y usados por los
clientes para comprobar que las distintas historias de usuario cumplen su
cometido.
Al ser las distintas funcionalidades de nuestra aplicacin no demasiado
extensas, no se harn test que analicen partes de las mismas, sino que las
pruebas se realizarn para las funcionalidades generales que debe cumplir el
programa especificado en la descripcin de requisitos.

Metodologa MSF
Qu es?
Microsoft Solutions Framework (MSF) es un enfoque personalizable para entregar
con xito soluciones tecnolgicas de manera ms rpida, con menos recursos
humanos y menos riesgos, pero con resultados de ms calidad. MSF ayuda a los
equipos de trabajo a enfrentarse directamente a las causas ms habituales de
fracaso de los proyectos de software y tecnolgicos en general, con el fin de
mejorar las tasas de xito de las empresas y as como su calidad en las
soluciones planteadas.
Por qu usarla?
Es viable usar la metodologa MSF porque tiene como objetivos principales alinear los
objetivos del negocio por medio del uso de la tecnologa, adems de establecer de
manera clara los objetivos, roles y responsabilidades a cada uno de los integrantes
del equipo de trabajo. Tambin implementa un proceso iterativo controlados por hitos
(puntos de control), gestionar los riesgos de manera proactiva y, por ultimo responder
con eficacia ante los cambios que puedan presentarse.

Qu caractersticas tiene?
La metodologa MSF consta de las siguientes caractersticas:
-

Fomentar una comunicacin abierta. Para que el equipo sea eficaz y eficiente,
tanto usted como su equipo deben compartir niveles de informacin apropiados
entre los miembros del equipo y en toda la empresa. El equipo debe comprender
la naturaleza de lo que se debe hacer y el modo en que se comunican los
miembros del equipo y los contactos externos. Lo difcil es determinar un nivel
apropiado para cada relacin y qu informacin se debe compartir.
Intentar lograr una visin compartida. El hecho de tener una visin compartida
empodera a los miembros del equipo y les permite actuar con agilidad para
poder tomar decisiones rpidas pero bien fundadas con el objetivo de lograr
una visin. Al tener una visin compartida, los miembros del equipo pueden ir
satisfaciendo los requisitos a medida que se vayan detectando.
Empodere a los miembros del equipo. Empoderar a los miembros del equipo no
solo es una de las muchas maneras de sobrevivir en un entorno en constante
cambio, sino que los miembros del equipo tambin aprenden a encontrar modos
de alcanzar el xito de manera creativa y a ayudarse unos a otros. Si no se

permite a los miembros del equipo dar lo mejor de s mismos, no solo

disminuye su creatividad, sino que tambin pueden sufrir de baja moral y ser
incapaces de contribuir a crear un equipo de alto rendimiento.
Establecer responsabilidades claras y compartidas. A menudo, los miembros del
equipo empoderados se sienten ms responsables de sus decisiones y estn
dispuestos a ser corresponsables de un proyecto. A mayor responsabilidad de los
miembros del equipo, mayor calidad. Por ejemplo, si un miembro del equipo afirma
que ha completado una tarea pero se detecta que no tiene el nivel de calidad
adecuado, ese miembro del equipo es responsable de resolver este problema de
manera que la tarea completada tenga los niveles de calidad indicados. Si se
fomenta el crecimiento positivo y la responsabilidad en lugar de castigar tales
deslices, el miembro del equipo comparte la responsabilidad de la solucin general
y sus entregas. Esto fomenta la motivacin entre los miembros ms slidos del
equipo para ayudarse mutuamente a dar lo mejor de s mismos.
Ofrecer valor incremental. Este principio tiene dos facetas:
* Asegurarse de que lo que se entrega tiene un valor ptimo para las partes
interesadas.
* Determinar los incrementos ptimos en los que se entregar valor (o la
"frecuencia de entrega").

Mantenerse gil, esperar cambios y adaptarse a ellos. Como los cambios

pueden darse a menudo y en el peor momento posible, disponer de una
manera gil de manejarlos ayuda a minimizar los trastornos habituales que
provocan. Mantenerse gil significa que una organizacin est preparada para
los cambios y puede adaptarse y ajustarse sin contratiempos.
Invertir en la calidad. Muchas organizaciones adoptan el principio de calidad, a
menudo con una definicin bastante difusa, pero no saben cmo cuantificarla.
La calidad es algo que se debe incorporar de manera proactiva al ciclo de vida
de entrega de la solucin y no es algo que aparezca de la nada.
Aprender de todas las experiencias. Si todos los niveles de una organizacin
no aprenden de lo que funcion y lo que no funcion anteriormente, cmo se
puede esperar que mejoren la prxima vez? Los miembros del equipo deben
comprender y darse cuenta de que el aprendizaje se da en todos los niveles:
- A nivel de proyecto, como por ejemplo, al perfeccionar un proceso vlido
para todo el proyecto
- A nivel individual, como por ejemplo, al buscar la manera de interactuar
mejor con otros miembros del equipo
- A nivel de la organizacin, como por ejemplo, al ajustar las mtricas de
calidad que se recopilan para cada proyecto

Colaborar con clientes internos y externos. Las probabilidades de xito del

proyecto aumentan cuando el cliente trabaja con el equipo del proyecto. Eso no
quiere decir que los clientes tengan que hacer el trabajo de un equipo. Sin
embargo, cuando los clientes colaboran estrechamente y de manera
incremental con un equipo de entrega, la solucin satisface mejor sus
expectativas. Colaborar con los clientes es ventajoso para ambas partes, ya
que ayuda a reducirla incertidumbre, reduce el tiempo necesario para resolver
requisitos y aumenta la comprensin por parte de los equipos de trabajo acerca
del problema a solucionar

Qu fases tiene?
A continuacin, tomaremos el siguiente cuadro para visualizar y entender cada una de
las fases y procesos realizados en la metodologa MSF, as como sus resultados.

Metodologa SCRUM
Qu es?
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prcticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas

por el beneficio que aportan al receptor del proyecto. Por ello, Scrum est
especialmente indicado para proyectos en entornos complejos, donde se necesita
obtener resultados pronto, donde los requisitos son cambiantes o poco definidos,
donde la innovacin, la competitividad, la flexibilidad y la productividad son
fundamentales.
Por qu usarla?
Esta metodologa de trabajo permite mejorar la eficiencia en la produccin y la
calidad de los productos finales, adems de tener la capacidad de respuesta al
cambio en los productos y sus definiciones, y brindar la mayor satisfaccin posible
al cliente, a travs de la entrega temprana y la retroalimentacin continua durante
la construccin del producto.
Esta metodologa trae consigo diversos beneficios, pues permite una mayor
flexibilidad que las metodologas tradicionales (en cascada e interactivas), debido
a que stas son menos capaces a ajustarse a las cambiantes necesidades de los
clientes, del mercado, y de los nuevos desafos que plantea la tecnologa.

Qu caractersticas tiene?
La metodologa SCRUM consta de las siguientes caractersticas generales:
-

gil: La divisin del trabajo en pequeas unidades funcionales (sprints)

permite mantener una poltica de entregas frecuentes de software que
ofrecen una visin clara del estado del proceso y permite la introduccin de
modificaciones.
Simple: Se centra especialmente en facilitar el desarrollo rpido, por lo que su
complejidad (por ejemplo desde el punto de vista de la documentacin a
generar o de la organizacin de equipos) se ha tratado de reducir al mximo.
Flexible: Todo el desarrollo se contempla como un ciclo de iteraciones
continuas de desarrollo, lo que facilita la introduccin de modificaciones
sobre la marcha, mejorando continuamente el proceso.
Colaborativa: El planteamiento, desde el punto de vista de la organizacin del
equipo, resulta bastante horizontal (en contraposicin a una organizacin
jerrquica frrea), otorgando a los miembros del equipo de desarrollo una
elevado grado de autonoma y auto-organizacin de su trabajo.

Qu fases tiene?
La metodologa SCRUM consta de las siguientes fases:
- Planificacin o pre - juego
- Desarrollo de Sprints o juego
- Cierre o Post - Juego
Pre Juego: 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.
En esta fase se obtienen los siguientes resultados:
- Desarrollo de un backlog completo.
- Determinacin de la fecha de entrega y la funcionalidad de una o ms versiones.
- Seleccin de la versin ms adecuada para desarrollo inmediato.

- Trazado de los paquetes del producto (objetos) sobre los elementos del backlog
de la versin elegida.
- Seleccin del equipo o equipos para desarrollar la nueva versin.
- Evaluacin y control adecuado de los riesgos.
- Estimacin del coste de la versin, incluyendo desarrollo, material, marketing,
formacin y despliegue.
- Conformidad de la direccin y financiacin del proyecto.

Juego: 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.
La fase de juego es un ciclo de trabajo repetitivo. La gestin determina el
cumplimiento de los tiempos, funcionalidad y calidad. Este enfoque es conocido
tambin como ingeniera concurrente.
El desarrollo consiste en los siguientes macro-procesos:
- Reunin con los equipos para revisar los planes de lanzamiento de versin.

- Distribucin, revisin y ajuste de los estndares de conformidad para el

producto.
- Sprints iterativos hasta que el producto se considera listo para su
distribucin teniendo en cuenta que un sprint es un conjunto de actividades
de desarrollo llevado a cabo durante un periodo predefinido, por lo general
entre una y cuatro semanas. Duracin basada en la complejidad del
producto, evaluacin de riesgos y grado de supervisin deseado.
Los resultados obtenidos en esta fase son los siguientes:
- Revisin de los elementos del backlog incluidos en la versin.
- Identificacin de los cambios necesarios para implementar el backlog.
- Anlisis del dominio para incluir los requisitos que incluye el desarrollo
mejora o actualizacin.
- Acotar la arquitectura del sistema para apoyar el nuevo contexto y
necesidades.
- Identificar problemas del desarrollo o modificaciones.

- Reunin de revisin de diseo. Cada equipo presenta los cambios para

implementar los elementos del backlog, e identificar posibles reasignaciones.

Post Juego: Cuando el equipo de gestin siente que las variables de tiempo,
parte completada, requisitos, coste y calidad estn alineadas para producir una
nueva versin, declaran cerrada la versin, dando paso a esta fase. En esta fase
se prepara el producto generado para producir una nueva versin. Entre las tareas
de cierre se encuentran: integracin, pruebas del sistema, documentacin de
usuario, preparacin del material de formacin y marketing.
Metodologa FDD
Qu es?
La metodologa FDD o Desarrollo impulsado por la Funcin (Feature Driven
Development), es una metodologa gil para el desarrollo de sistemas, basado en
la calidad del software, que incluye un monitoreo constante del sistema. Como las
otras metodologas adaptables, se enfoca en iteraciones cortas que entregan
funcionalidad tangible Dicho enfoque no hace nfasis en la obtencin de los
requerimientos sino en cmo se realizan las fases de diseo y construccin. Sin
embargo, fue diseado para trabajar con otras actividades de desarrollo de
software y no requiere la utilizacin de ningn modelo de proceso especfico.
Adems, hace nfasis en aspectos de calidad durante todo el proceso e incluye un
monitoreo permanente del avance del proyecto. Al contrario de otras
metodologas, FDD afirma ser conveniente para el desarrollo de sistemas crticos.
Por qu usarla?
Es pertinente usar la metodologa FDD porque el equipo de desarrollo no malgasta
el tiempo y dinero del cliente desarrollando soluciones innecesariamente
generales y complejas que en realidad no son un requisito del mismo, adems que
cada componente final que est en el desarrollo ha sido probado y tambin
satisface los requerimientos dados por el cliente. Al ser una metodologa gil, esta
permite el continuo cambio de requisitos (si as se requiere); tambin minimiza los
costos y una de sus ventajas ms grandes es que involucran al cliente dentro del
proceso junto con el equipo de desarrollo.

Qu caractersticas tiene?
La metodologa FDD consta de las siguientes caractersticas:
-

No hace nfasis en la obtencin de los requerimientos sino en cmo se

realizan las fases de diseo y construccin.
Se preocupa por la calidad, por lo que incluye un monitoreo constante del
proyecto.
Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas
en el programa o el hecho de entregar menos de lo deseado.
Propone tener etapas de cierre cada dos semanas.
Se obtienen resultados peridicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que producen un
software funcional que el cliente y la direccin de la empresa pueden ver y
monitorear.
Define claramente entregas tangibles y formas de evaluacin del progreso
del proyecto.

Qu fases tiene?
La metodologa FDD cuenta con 4 fases secuenciales que nombraremos a
continuacin:

Desarrollo del modelo general

Construccin de lista de rasgos
Planeacin por rasgos
Diseo y construccin por rasgos

Desarrollo del modelo general: Cuando esta fase comienza, los expertos del
dominio ya tienen una idea del contexto y los requerimientos del sistema. Es
probable que el documento de especificacin de requerimientos ya exista. Sin
embargo, FDD no hace nfasis en la recoleccin y administracin de los
requerimientos. Los expertos del dominio presentan un informe llamado
walkthrough en el cual los miembros del equipo son informados a travs de una
descripcin de alto nivel del sistema.
Construccin de lista de rasgos: Los walkthroughs, el modelo de objetos y los
requerimientos existentes ofrecen una buena base para construir una construccin
de lista de rasgos que resuma la funcionalidad del sistema a ser desarrollado. En
dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades
evaluadas por el cliente.

Planeacin por rasgos: En esta etapa se incluye la creacin de un plan de alto

nivel, en el cual las listas de rasgos son ordenada en base a la prioridad y a la
dependencia entre cada lista. Adems, las clases identificadas en la primera etapa
son asignadas a cada programador.
Diseo y construccin por rasgos: El diseo y construccin de la funcionalidad es
un proceso iterativo durante el cual las listas seleccionadas son producidas. Una
iteracin puede llevar desde unos pocos das a un mximo de dos semanas. Este
proceso iterativo incluye tareas como inspeccin del diseo, codificacin, testing
unitario, integracin e inspeccin del cdigo. Luego que la iteracin llega a su fin
se realiza una construccin principal de la funcionalidad en el cual se integra la
funcionalidad. Dicha construccin principal se realiza mientras la siguiente
iteracin comienza.

Metodologa DSDM
Qu es?
El DSDM o Mtodo de Desarrollo de Sistemas Dinmicos (Dinamic Systems
Deveploment Method) es una metodologa de desarrollo de software originalmente
basado en la metodologa de Desarrollo de Aplicacin Rpida. DSDM es un
acercamiento reiterativo e incremental que acenta el envolvimiento del usuario
continuo. Su meta es entregar los sistemas del software a tiempo y en el
presupuesto mientras ajustando para los requisitos cambiantes a lo largo del
proceso de desarrollo.
Por qu usarla?
Es pertinente usar esta metodologa porque la calidad del producto es mejorada a
travs de la participacin de los usuarios a lo largo del ciclo de vida del proyecto y
la naturaleza iterativa del desarrollo, adems de asegurar desarrollos rpidos.
Tambin reduce los costos de proyectos a travs de las ventajas mencionadas
anteriormente y, por ltimo, permite realizar cambios de forma muy sencilla.
Qu caractersticas tiene?
La metodologa DSDM cuenta con las siguientes caractersticas generales:
-

Tiene una gran rapidez de desarrollo atendiendo a las demandas de

tecnologa de forma eficaz y eficiente previendo que el sistema desarrollado
funcione a pesar del transcurrir del tiempo y del cambio de la tecnologa.
Es ideal para trabajar en proyectos en donde el presupuesto y el tiempo de
desarrollo es muy reducido.

Todos los cambios pueden ser reversibles, es decir que se puede volver a
un punto base pre definido si las cosas no salen bien. Esto con el fin de
manejar los riesgos presentes en proyectos de este tipo.
Se realiza una verificacin de calidad a lo largo del proceso de desarrollo y
no solo al final.
En esta metodologa no existen contra tiempos

Qu fases tiene?
La metodologa DSDM cuenta con 3 fases principales que son las siguientes:

Fase del pre - proyecto

Fase de vida - ciclo de proyecto
Fase del post - proyecto.

Fase de pre proyecto: En los pre-proyecto fase candidato proyectos se

identifica, el fondo del proyecto se comprende y se proyecta el compromiso se
asegura. Ocupndose de estos problemas en una fase temprana evita los
problemas en las fases ms tarde del proyecto.
Fase de vida-ciclo de proyecto: La apreciacin global del proceso en la figura
sobre las muestras el vida-ciclo del proyecto de esta fase de DSDM. Pinta las 5
fases un proyecto tendr que ir a travs de crear un ES. Las primeras dos
fases, el Estudio de Viabilidad y Estudio Comercial son fases secuenciales que
complementan a nosotros. Despus de que estas fases se han concluido, el
sistema se desarrolla incrementalmente en la Iteracin Ejemplar Funcional, el
diseo y construccin de la Iteracin y fases de Aplicacin. Se dirigir la
naturaleza reiterativa e incremental de DSDM ms all en una seccin ms
tarde.
Fase del post proyecto: La fase del poste-proyecto asegura el sistema que
opera eficazmente y eficazmente. Esto se comprende por el mantenimiento,
mejoras y apuros segn los principios de DSDM. El mantenimiento puede
verse como continuar desarrollo basado en la naturaleza reiterativa e
incremental de DSDM. En lugar de normalmente terminar el proyecto en un
ciclo el proyecto puede devolver a las fases anteriores o fases para que
puedan refinarse el paso anterior y los productos entregables.

PARADIGMAS DE PROGRAMACIN
Definicin
-Ejemplo o ejemplar.
Teora o conjunto de teoras cuyo ncleo centralse acepta sin cuestionar y que
suministra la base ymodelo para resolver problemas y avanzar en elconocimien
to. El paradigma newtoniano.
Un paradigma de programacin indica un mtodo de realizar cmputos y la
manera en que se deben estructurar y organizar las tareas que debe llevar a cabo
un programa. Un paradigma de programacin provee (y determina) la visin y
mtodos de un programador en la construccin de un programa o subprograma.
Los paradigmas fundamentales estn asociados a determinados modelos de
cmputo. Tambin se asocian a un determinado estilo de programacin.
Los lenguajes de programacin suelen implementar, a menudo de forma parcial,
varios paradigmas.
TIPOS DE PARADIGMAS
Los paradigmas fundamentales estn basados en diferentes modelos de cmputo
y por lo tanto afectan a las construcciones ms bsicas de un programa.
La divisin principal reside en el enfoque imperativo (indicar el cmo se debe
calcular) y el enfoque declarativo (indicar el qu se debe calcular).
El enfoque declarativo tiene varias ramas diferenciadas: el paradigma funcional, el
paradigma lgico, la programacin reactiva y los lenguajes descriptivos.
Otros paradigmas se centran en la estructura y organizacin de los programas, y
son compatibles con los fundamentales:
Ejemplos: Programacin estructurada, modular, orientada a objetos,
orientada a eventos, programacin genrica.
Por ltimo, existen paradigmas asociados a la concurrencia y a los sistemas de
tipado.
Habitualmente se mezclan todos los tipos de paradigmas a la hora de hacer la
programacin. De esa manera se origina la programacin multiparadigma, pero el
que actualmente es ms usado de todos esos paradigmas es el de la
programacin orientada a objetos.

6.1 POO (Programacin orientada a objetos)

6.2 La programacin Orientada a objetos (POO) es una forma especial de
programar, ms cercana a como expresaramos las cosas en la vida real que otros
tipos de programacin.
Un objeto es una unidad que contiene datos y las funciones que operan sobre
esos datos. A los elementos de un objeto se les conoce como miembros; las
funciones que operan sobre los objetos se denominan mtodos y los datos se
denominan miembros datos.
La POO representa una metodologa de programacin que se basa en las
siguientes caractersticas:
1) Los diseadores definen nuevas clases (o tipos) de objetos.
2) Los objetos poseen una serie de operaciones asociadas a ellos.
3) Las operaciones tienden a ser genricas, es decir, operan sobre mltiples tipos
de datos.
4) Las clases o tipos de objetos comparten componentes comunes mediante
mecanismos de herencia.
Objeto: Una estructura de datos y conjunto de procedimientos que operan sobre
dicha estructura. Una definicin ms completa de objeto es: una entidad de
programa que consiste en datos y todos aquellos procedimientos que pueden
manipular aquellos datos; el acceso a los datos de un objeto es solamente a
travs de estos procedimientos, nicamente estos procedimientos pueden
manipular, referenciar y/o modificar estos datos.

Para poder describir todos los objetos de un programa, conviene agrupar stos en
clases.
Clase: Podemos considerar una clase como una coleccin de objetos que poseen
caractersticas y operaciones comunes. Una clase contiene toda la informacin
necesaria para crear nuevos objetos.
Encapsulacin: Es una tcnica que permite localizar y ocultar los detalles de un
objeto. La encapsulacin previene que un objeto sea manipulado por operaciones
distintas de las definidas. La encapsulacin es como una caja negra que esconde
los datos y solamente permite acceder a ellos de forma controlada.
Las principales razones tcnicas para la utilizacin de la encapsulacin son:
1) Mantener a salvo los detalles de representacin, si solamente nos interesa el
comportamiento del objeto.
2) Modificar y ajustar la representacin a mejores soluciones algortmicas o a
nuevas tecnologas de software.
Abstraccin: En el sentido ms general, una abstraccin es una representacin
concisa de una idea o de un objeto complicado. En un sentido ms especfico, la
abstraccin localiza y oculta los detalles de un modelo o diseo para generar y
manipular objetos. Una abstraccin tiene un significado ms general que la
encapsulacin, pudiendo hablar de abstraccin de datos en lugar de
encapsulacin de datos.
Objetos: Un objeto es una entidad lgica que contiene datos y un cdigo que
manipula estos datos; el enlazado de cdigo y de datos, de esta manera suele
denominarse encapsulacin. Cuando se define un objeto, se est creando
implcitamente un nuevo tipo de datos.
Polimorfismo: Significa que un nombre se puede utilizar para especificar una clase
genrica de acciones.
Herencia: La herencia es un proceso mediante el cual un objeto puede adquirir las
propiedades de otro objeto.
Clase: Las clases son declaraciones de objetos, tambin se podran definir como
abstracciones de objetos. Esto quiere decir que la definicin de un objeto es la
clase. Cuando programamos un objeto y definimos sus caractersticas y
funcionalidades en realidad lo que estamos haciendo es programar una clase. En
los ejemplos anteriores en realidad hablbamos de las clases coche o fraccin
porque slo estuvimos definiendo, aunque por encima, sus formas.
Propiedades en clases
Las propiedades o atributos son las caractersticas de los objetos. Cuando
definimos una propiedad normalmente especificamos su nombre y su tipo. Nos
podemos hacer a la idea de que las propiedades son algo as como variables
donde almacenamos datos relacionados con los objetos.
Mtodos en las clases
Son las funcionalidades asociadas a los objetos. Cuando estamos programando
las clases las llamamos mtodos. Los mtodos son como funciones que estn
asociadas a un objeto.
6.3 Ejemplo 1

Ejemplo 2
Un perro es un objeto.
Los objetos tienen dos caractersticas: Un estado y un comportamiento. Podemos
fijarnos que por ejemplo un perro tiene un estado: nombre, color, raza, altura, etc.
y un comportamiento: ladrar, cavar pozo, llorar, dormir, comer, etc.
Podramos tener la clase Perro, una instancia de esta clase podra ser el objeto
perro llamado "Chicho". La clase Perro especificara que todos los perros tendran
un nombre, color de pelo, una altura. Mientras que la instancia "Chicho" contendr
valores especficos para cada uno de estos atributos.
6.1 Programacin orientada a eventos
6.2 La programacin dirigida por eventos es un paradigma de programacin en el
que tanto la estructura como la ejecucin de los programas van determinados por
los sucesos que ocurran en el sistema, definidos por el usuario o que ellos mismos
provoquen.
Para entender la programacin dirigida por eventos, podemos oponerla a lo que
no es: mientras en la programacin secuencial (o estructurada) es el programador
el que define cul va a ser el flujo del programa, en la programacin dirigida por
eventos ser el propio usuario o lo que sea que est accionando el programa
el que dirija el flujo del programa. Aunque en la programacin secuencial puede
haber intervencin de un agente externo al programa, estas intervenciones
ocurrirn cuando el programador lo haya determinado, y no en cualquier momento
como puede ser en el caso de la programacin dirigida por eventos.
El creador de un programa dirigido por eventos debe defi- nir los eventos que
manejarn su programa y las acciones que se realizarn al producirse cada uno
de ellos, lo que se conoce como el administrador de evento. Los eventos
soportados estarn determinados por el lenguaje de programacin utilizado, por el
sistema operativo e incluso por eventos creados por el mismo programador. En la
programacin dirigida por eventos, al comenzar la ejecucin del programa se
llevarn a cabo las inicializaciones y dems cdigo inicial y a continuacin el

programa quedar bloqueado hasta que se produzca algn evento. Cuando

alguno de los eventos esperados por el programa tenga lugar, el programa pasar
a ejecutar el cdigo del correspondiente administrador de evento. Por ejemplo, si
el evento consiste en que el usuario ha hecho clic en el botn de play de un
reproductor de pelculas, se ejecutar el cdigo del administrador de evento, que
ser el que haga que la pelcula se muestre por pantalla.
La programacin dirigida por eventos es la base de lo que llamamos interfaz de
usuario, aunque puede emplearse tambin para desarrollar interfaces entre
componentes de Software o mdulos del ncleo.
Deteccin de eventos
En contraposicin al modelo clsico, la programacin orientada a eventos permite
interactuar con el usuario en cualquier momento de la ejecucin. Esto se consigue
debido a que los programas creados bajo esta arquitectura se componen por un
bucle exterior permanente encargado de recoger los eventos, y distintos procesos
que se encargan de tratarlos. Habitualmente, este bucle externo permanece oculto
al programador que simplemente se encarga de tratar los eventos, aunque en
algunos entornos de desarrollo (IDE) ser necesaria su construccin.
Problemtica
La programacin orientada a eventos supone una complicacin aadida con
respecto a otros paradigmas de programacin, debido a que el flujo de ejecucin
del software escapa al control del programador. En cierta manera podramos decir
que en la programacin clsica el flujo estaba en poder del programador y era este
quien decida el orden de ejecucin de los procesos, mientras que, en
programacin orientada a eventos, es el usuario el que controla el flujo y decide.
GUIs / Interfaces Grficas de Usuarios
Con la evolucin de los lenguajes orientados a eventos, la interaccin del software
con el usuario ha mejorado enormemente permitiendo la aparicin de interfaces
que, aparte de ser la va de comunicacin del programa con el usuario, son la
propia apariencia del mismo. Estas interfaces, tambin llamadas GUI (Graphical
User Interface), han sido la herramienta imprescindible para acercar la informtica
a los usuarios, permitiendo en muchos casos, a principiantes utilizar de manera
intuitiva y sin necesidad de grandes conocimientos, el software que ha colaborado
a mejorar la productividad en muchas tareas. Uno de los perifricos que ha
cobrado mayor importancia tras la aparicin de los programas orientados a
eventos ha sido el ratn, gracias tambin en parte a la aparicin de los sistemas
operativos modernos con sus interfaces grficas. Estas suelen dirigir directamente.
Lenguajes
Web
Javascript
Escritorio Windows
Visual Basic
Visual C++
.NET Framework (Escritorio Windows y Web)
Visual Basic
C#
J#
Lexico

Otros
AS3
Bibliotecas
C y C++
Qt
GTK+
Java
AWT
Swing
SWT
Web
ASP.NET (Mediante Javascript con el Modelo Code-behind)
6.3 Ejemplo
Ejemplo de programa orientado a eventos en pseudo lenguaje:
While (true) {
Switch (event) {
case mousse_button_down:
case mouse_click:
case keypressed:
case Else:
}
}
Ejemplo 2

6.1 Programacin orientada a aspectos

6.2 La Programacin Orientada a Aspectos o POA (en ingls: aspect-oriented

programming) es un paradigma de programacin relativamente reciente cuya
intencin es permitir una adecuada modularizacin de las aplicaciones y posibilitar
una mejor separacin de responsabilidades (Obligacin o correspondencia de
hacer algo).
Gracias a la POA se pueden encapsular los diferentes conceptos que componen
una aplicacin en entidades bien definidas, eliminando las dependencias entre
cada uno de los mdulos. De esta forma se consigue razonar mejor sobre los
conceptos, se elimina la dispersin del cdigo y las implementaciones resultan
ms comprensibles, adaptables y reusables. Varias tecnologas con nombres
diferentes se encaminan a la consecucin de los mismos objetivos y as, el
trmino POA es usado para referirse a varias tecnologas relacionadas como los
mtodos adaptativos, los filtros de composicin, la programacin orientada a
sujetos o la separacin multidimensional de competencias.
Objetivo
El principal objetivo de la POA es la separacin de las funcionalidades dentro del
sistema:
Por un lado, funcionalidades comunes utilizadas a lo largo de la aplicacin.
Por otro lado, las funcionalidades propias de cada mdulo.
Cada funcionalidad comn se encapsular en una entidad.
Conceptos Bsicos
Aspecto (en ingls Aspect) es una funcionalidad transversal (cross-cutting) que se
va a implementar de forma modular y separada del resto del sistema. El ejemplo
ms comn y simple de un aspecto es el logging (registro de sucesos) dentro del
sistema, ya que necesariamente afecta a todas las partes del sistema que generan
un suceso.
Punto de Cruce o de Unin (en ingls Join point) es un punto de ejecucin dentro
del sistema donde un aspecto puede ser conectado, como una llamada a un
mtodo, el lanzamiento de una excepcin o la modificacin de un campo. El
cdigo del aspecto ser insertado en el flujo de ejecucin de la aplicacin para
aadir su funcionalidad.
Consejo (en ingls Advice) es la implementacin del aspecto, es decir, contiene el
cdigo que implementa la nueva funcionalidad. Se insertan en la aplicacin en los
Puntos de Cruce.
Puntos de Corte (en ingls Pointcut) define los Consejos que se aplicarn a cada
Punto de Cruce. Se especifica mediante Expresiones Regulares o mediante
patrones de nombres (de clases, mtodos o campos), e incluso dinmicamente en
tiempo de ejecucin segn el valor de ciertos parmetros.
Introduccin (en ingls Introduction) permite aadir mtodos o atributos a clases
ya existentes. Un ejemplo en el que resultara til es la creacin de un Consejo de
Auditora que mantenga la fecha de la ltima modificacin de un objeto, mediante
una variable y un mtodo setUltimaModificacion(fecha), que podran ser
introducidos en todas las clases (o slo en algunas) para proporcionarles esta
nueva funcionalidad.

Destinatario (en ingls Target) es la clase aconsejada, la clase que es objeto de

un consejo. Sin AOP, esta clase debera contener su lgica, adems de la lgica
del aspecto.
Resultante (en ingls Proxy) es el objeto creado despus de aplicar el Consejo al
Objeto Destinatario. El resto de la aplicacin nicamente tendr que soportar al
Objeto Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP).
Tejido (en ingls Weaving) es el proceso de aplicar Aspectos a los Objetos
Destinatarios para crear los nuevos Objetos Resultantes en los especificados
Puntos de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto
Destinatario:
Aspectos en Tiempo de Compilacin, que necesita un compilador especial.
Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el
Objeto Destinatario es cargado. Requiere un ClassLoader especial.
Aspectos en Tiempo de Ejecucin.
Desarrollo en POA[editar]
AspectC++ es un compilador que permite desarrollar aspectos en C++.
AspectJ es una extensin Java del proyecto Eclipse para ayudar en el desarrollo
orientado a aspectos.
Aspect, un mdulo Perl disponible en CPAN para la Programacin Orientada a
Aspectos (en ingls).
PHP-AOP (AOP.io) es una lib que proporciona todo el paradigma de la POA en
PHP.
phpAspect es una extensin PHP para implementar el paradigma de la POA, que,
mediante rboles de decisin XML, realiza el weaving del software para ser
ejecutado como PHP estndar.
FLOW3 es un framework MVC de PHP incluye un mdulo para poder realizar
Programacin orientada a Aspectos en nuevos desarrollos.
AOP con SpringFramework 2.5 es un Framework de Java que permite programar
en el paradigma de Aspectos utilizando Anotacin Java.
Aspyct AOP es un mdulo de Python que permite incluir Programacin orientada a
Aspectos a programas ya existentes escritos en Python o a nuevos desarrollos.
6.3 Ejemplo

Ejemplo 2

6.1 Programacin estructurada

6.2 La programacin estructurada es un paradigma de programacin orientado a
mejorar la claridad, calidad y tiempo de desarrollo de un programa de

computadora, utilizando nicamente subrutinas y tres estructuras: secuencia,

seleccin (if y switch) e iteracin (bucles for y while), considerando innecesario y
contraproducente el uso de la instruccin de transferencia incondicional (GOTO),
que podra conducir a "cdigo espagueti", que es mucho ms difcil de seguir y de
mantener, y era la causa de muchos errores de programacin.
Esta forma de programar se basa en un famoso teorema, desarrollado por Edsger
Dijkstra, que demuestra que todo programa puede escribirse utilizando
nicamente las tres estructuras bsicas de control siguientes:
Secuencia: el bloque secuencial de instrucciones, instrucciones ejecutadas
sucesivamente, una detrs de otra.
Seleccin: la instruccin condicional con doble alternativa, de la forma "if
condicin then instruccin-1 else instruccin-2".
Iteracin: el bucle condicional "while condicin do instruccin", que ejecuta la
instruccin repetidamente mientras la condicin se cumpla.
Los programas que utilizan slo estas tres instrucciones de control bsicas o sus
variantes (como los bucles for, repeat o la instruccin condicional switch-case),
pero no la instruccin goto, se llaman estructurados.
sta es la nocin clsica de lo que se entiende por programacin estructurada
(llamada tambin programacin sin goto) que hasta la aparicin de la
programacin orientada a objetos se convirti en la forma de programar ms
extendida. Esta ltima se enfoca hacia la reduccin de la cantidad de estructuras
de control para reemplazarlas por otros elementos que hacen uso del concepto de
polimorfismo. Aun as los programadores todava utilizan las estructuras de control
(if, while, for, etc.) para implementar sus algoritmos porque en muchos casos es la
forma ms natural de hacerlo.
Esta tcnica de programacin conlleva las siguientes ventajas:
a) El coste de resolver varios subproblemas de forma aislada es con frecuencia
menor que el de abordar el problema global
b) Facilita el trabajo simultneo en paralelo de distintos grupos de programadores.
c) Posibilita en mayor grado la reutilizacin del cdigo (especialmente de alguno
de los mdulos) en futuras aplicaciones.
Fundamentacin terica
El teorema del programa estructurado proporciona la base terica de la
programacin estructurada. Seala que la combinacin de las tres estructuras
bsicas, secuencia, seleccin e iteracin, son suficientes para expresar cualquier
funcin computable. Esta observacin no se origin con el movimiento de la
programacin estructurada. Estas estructuras son suficientes para describir el ciclo
de instruccin de una unidad central de procesamiento, as como el
funcionamiento de una mquina de Turing. Por lo tanto un procesador siempre
est ejecutando un "programa estructurado" en este sentido, incluso si las
instrucciones que lee de la memoria no son parte de un programa estructurado.
Sin embargo, los autores usualmente acreditan el resultado a un documento
escrito en 1966 por Bhm y Jacopini, posiblemente porque Dijkstra haba citado
este escrito. El teorema del programa estructurado no responde a cmo escribir y
analizar un programa estructurado de manera til. Estos temas fueron abordados
durante la dcada de 1960 y principio de los aos 1970, con importantes
contribuciones de Dijkstra, Robert W. Floyd, Tony Hoarey y David Gries.

Ventajas de la programacin estructurada

Ventajas de la programacin estructurada comparada con el modelo anterior (hoy
llamado despectivamente cdigo espagueti).
Los programas son ms fciles de entender, pueden ser ledos de forma
secuencial y no hay necesidad de hacer engorrosos seguimientos en saltos
de lneas (GOTO) dentro de los bloques de cdigo para intentar entender la
lgica.

La estructura de los programas es clara, puesto que las instrucciones estn

ms ligadas o relacionadas entre s.

Reduccin del esfuerzo en las pruebas y depuracin. El seguimiento de los

fallos o errores del programa (debugging) se facilita debido a su estructura
ms sencilla y comprensible, por lo que los errores se pueden detectar y
corregir ms fcilmente.

Reduccin de los costos de mantenimiento. Anlogamente a la depuracin,

durante la fase de mantenimiento, modificar o extender los programas
resulta ms fcil.

Los programas son ms sencillos y ms rpidos de confeccionar.

Se incrementa el rendimiento de los programadores.

Lenguajes de programacin estructurada

Es posible hacer la programacin estructurada en cualquier lenguaje de
programacin, aunque es preferible usar algo como un lenguaje de programacin
procedimental. Algunos de los lenguajes utilizados inicialmente para programacin
estructurada incluyen: ALGOL, Pascal, PL/I y Ada pero la mayora de los nuevos
lenguajes de programacin procedimentales desde entonces han incluido
caractersticas para fomentar la programacin estructurada y a veces
deliberadamente omiten caractersticas,4 en un esfuerzo para hacer ms difcil la
programacin no estructurada.
6.3 Supongamos que queremos desarrollar una aplicacin para que dos usuarios
jueguen al ajedrez. En primer lugar, necesitamos una serie de funciones
asociadas al tablero: una que coloque todas las piezas de ambos jugadores en las
posiciones iniciales, otra que determine si se ha producido el final de la partida,
otra que confirme la presencia de una pieza del jugador en juego en una
determinada casilla, otra que confirme que el movimiento no se sale del tablero, o
que ese tipo de pieza puede realizarlo, y una ltima que lleve a efecto el
movimiento de una pieza del jugador en juego (eliminando del tablero a otra pieza
del jugador contrario si procede). Para estas ltimas puede ser preciso utilizar a su
vez otro mdulo que represente las funciones de movimiento asociadas a cada
tipo de pieza.
La descomposicin en mdulos del programa quedara:

Fig. 5.2. Descomposicin del programa en mdulos.

As, el contenido del fichero de libreratablero.h sera:
enum columnas { a, b, c, d, e, f, g, h };
struct tablero {
int posx;
enum columnas posy;
struct pieza mipieza;
struct tablero *siguiente;
}
int Final(struct tablero *mitablero);
void Inicio(struct tablero *mitablero);
int Pertenece(struct tablero *mitablero, int posx, enum columnas posy);
void Dibuja(struct tablero *mitablero);
int FueraTablero(struct tablero *mitablero, int x1, enum columnas y1, int x2,
enumcolumnas y2);
int Valido_T(struct tablero *mitablero, int x1, enum columnas y1, int x2, enum
columnas y2);
void Mover(struct tablero *mitablero, int x1, enum columnas y1, int x2, enum
columnas y2);
As, el fichero de declaracin pieza.h incluira el siguiente cdigo:
enum color { blanco, negro };
enum tipo { peon, torre, caballo, alfil, reina, rey }
struct pieza {
enum color micolor;
enum tipo mitipo;
}
int Valido_P(struct pieza *mipieza, int x1, int y1, int x2, int y2);
De esta forma, con el conocimiento pblico de ambos ficheros de declaracin
(tablero.h, pieza.h) podremos hacer uso de las funciones de los mdulos tablero y
pieza declaradas en estos ficheros, a pesar de nuestra ignorancia completa de
cmo fueron implementadas. Lo ignoramos, ya que no tenemos acceso a los
ficheros de implementacin o cdigo fuente (tablero.c, pieza.c); nicamente
disponemos del cdigo objeto (ablero.o, pieza.o) para su ejecucin posterior.
8. 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.
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.

Conclusiones
-

Es importante ver la utilizacin de la ingeniera de software como mecanismo

de aplicacin y evaluacin de la calidad de un sistema, visto como la definicin
de criterios de operacin bajo condiciones y lmites establecidos por el sistema
y por las caractersticas externas del medio externo.

Es importante saber leer, escribir y plantear un problema para desarrollar

un proyecto, eso me lo da a entender la ingeniera, me permite aprender a
tener todo claro y a saber escribir y saber leerlo para que no se me
presenten serios problemas por no tener todo claro.

El modelo incremental es una unin de las mejores funcionalidades del

modelo de cascada y del modelo de prototipos. A medida que se presenta
un prototipo se produce un incremento, que es una iteracin del proceso
anterior pero aplicando las experiencias aprendidas del proceso anterior. A
diferencia del modelo de prototipos, los prototipos de este modelo estn
orientados a ser operacionales en cada incremento y no ser solo una previa
de cmo sera el sistema en su versin final.

El modelo Cascada tiene un alto riesgo en sistemas nuevos debido a

problemas en las especificaciones y en el diseo por el cual provoca con
ello un bajo riesgo para desarrollos bien comprendidos utilizando tecnologa
conocida. Siendo este modelo el nico que considera cada actividad del
proceso como una actividad discreta.

El modelo Espiral toma en consideracin explcitamente el riesgo, esta es

una actividad importante en la administracin del proyecto. Por lo que este
modelo requiere de mucha experiencia y habilidad para la evaluacin de los
riesgos, lo cual es requisito para el xito del proyecto; dando con ello a que
en este modelo es difcil convencer a los grandes clientes que se podr
controlar este enfoque evolutivo.

En el modelo prototipo podemos darnos cuenta de que lo esencial esta en

definir las reglas desde el principio es decir el usuario y el desarrollador se
deben poner de acuerdo en que el prototipo se construya y sirva como un
mecanismo para la definicin de requerimientos y que despus de esto se
desarrolle el software real con un enfoque hacia la calidad.

En el modelo evolutivo no es tan usado por lo que no se tiene clara la

medida de eficiencia de este modelo en un sistema de informacin, pero
este modelo podemos ver que apto para el desarrollo de sistemas
operativos complejos, este modelo evolutivo tiene aspectos buenos ya que
todo lo que hace este modelo es controlar y sistematizar las actividades

Existen diversas metodologas que pueden ser aplicadas a proyectos de

software y/o sistemas de informacin, que cuentan con caractersticas
diferentes, teniendo como la general la siguiente: Metodologas agiles y
tradicionales o pesadas donde, la primera me brinda una forma ms fcil y
rpida de trabajar y la segunda me permite tener una profundizacin y
anlisis del problema a solucionar pero, cabe resaltar que el resultado de
cualquiera de stas metodologas est en pro a mantener la ptima calidad
del trabajo realizado, as como el cumplimiento de los requerimientos que el
usuario necesite dependiendo del caso. El xito de desarrollo de un
proyecto de software claramente est relacionado con la correcta eleccin
de la metodologa a trabajar.

As para lograr el xito en la generacin de software se exige hacerlo con

calidad y para esto se involucran estndares y modelos de evaluacin como
uno de los muchos temas importantes en la Ingeniera de Software.

Bibliografa
-

Ian Sommerville. (2005). Ingeniera del Software. Sptima edicin. Madrid

(Espaa): PEARSON EDUCACIN, S.A.

5
ciclos
de
vida
del
Software.
Extrado
http://es.slideshare.net/rockrlos/5-ciclos-de-vida-del-softwarefixed

- Sistemas
de
Software.
http://aposta.uv.es/givaro/modulo/Ciclo.htm

Extrado

de:

de:

Ciclo de Vida del Software NTP 12207 [en lnea]. 11 febrero 2016. Disponible
en:https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=
8&cad=rja&uact=8&ved=0ahUKEwi4g4vxgfnKAhXIWSYKHTt_DCUQFghK
MAc&url=http%3A%2F%2Fwww.ongei.gob.pe%2Feventos%2FProgramas_
docu%2F135%2FPrograma_1264.ppt&usg=AFQjCNHfFxUmQCAkHET3nro
zolEKcFPxtg

Ciclo de vida del Software. Extrado de: http://es.ccm.net/contents/223-ciclode-vida-del-software

Modelos de ciclos de vida en el Software.

http://www.hanantek.com/es/modelos-ciclo-vida-software

Metodologas giles para el desarrollo de software: eXtreme Programming

(XP). Extrado de: http://www.cyta.com.ar/ta0502/v5n2a1.htm

Rational
Unified
Process
(RUP).Extrado
de:
http://ima.udg.edu/~sellares/EINFES2/Present1011/MetodoPesadesRUP.pd
f

Metodologa
XP.
Extrada
http://es.slideshare.net/Piskamen/metodologa-xp

Fases
de
la
Programacin
Extrema:
http://programacionextrema.tripod.com/fases.htm

Descripcin general de Microsoft Solutions Framework (MSF). Extrado de:

https://msdn.microsoft.com/es-es/library/jj161047(v=vs.120).aspx

Extrado

de:

de:

Extrado

de:

SCRUM: La metodologa de desarrollo gil por excelencia. Extrado de:

http://vassdigital.com/blog/scrum-la-metodologia-de-desarrollo-agil-porexcelencia/

Modelo original de Scrum para desarrollo de software. Extrado de:

http://www.scrummanager.net/bok/index.php?title=Modelo_original_de_Scru
m_para_desarrollo_de_software

FDD:
Feature
Driven
Depveloment.
http://ingenieriadesoftware.mex.tl/61162_FDD.html

Dynamic
Systems
Development
Method.
Extrado
de:
http://ingenieriadesoftware.mex.tl/images/18149/DSDM%20documento.pdf

Anlisis orientado a objetos: Ingeniera de Software. Extrado de:

http://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf

Objetivos
de
la
Ingeniera
de
Software.
Extrado
http://www.etsisi.upm.es/estudios/grados/software/objetivos

Caractersticas y Tipos de Software. Extrado de:

http://ingenieriasoftbejarano.blogspot.com.co/2012/10/caracteristicas-ytipos-de-software.html

Qu son los sitemas informticos? Extrado de:

http://www.um.es/docencia/barzana/IAGP/IAGP2-Ingenieria-softwareintroduccion.html

Proyectos
de
desarrollo
de
Software.
Extrado
de:
http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarroll
o%20software.pdf

Extrado

de:

de: