25/08/2015

Tema Nro. 2 ECONOMIA DEL SOFTWARE

 El software es un producto de consumo con un gran peso en la economía
 El desarrollo del software de las empresas USA

MODELOS DE PROCESO DEL

 2 trillones de dólares en desarrollo
 30.000 millones de dólares anuales en mantenimiento
 Gasto en proyectos software en el año 1995 en USA
 175.000 proyectos / 250.000 millones de dólares

SOFTWARE 



59.000 millones de dólares de desviación de los costes estimados
81.000 millones de dólares en proyectos software cancelados
Contribución del software a la economía USA en 1996 [Minasi, 2000]
Gran superávit en las exportaciones
MATERIA: INGENIERIA DE SOFTWARE

 Se exportó software por un valor de 24.000 millones de dólares, se importó software por valor de 4.000
millones de dólares, se obtuvo una balanza positiva de 20.000 millones de dólares
NOMBRE: LIC. ZARA YUJRA CAMA 


Comparativa
Agricultura: Exportaciones 26.000 millones; Importaciones 14.000 millones; Balance: 12.000 millones
 Industria Aeroespacial: Exportaciones 11.000 millones; Importaciones 3.000 millones; Balance: 8.000
millones
 Química: Exportaciones 26.000 millones; Importaciones 19.000 millones; Balance: 7.000 millones
 Vehículos: Exportaciones 21.000 millones; Importaciones 43.000 millones; Balance: -22.000 millones
LA PAZ - BOLIVIA  Bienes manufacturados: Exportaciones 200.000 millones; Importaciones 265.000 millones; Balance: -
65.000 millones
 Industria del software en USA en el año 2000
 Ventas: 180 billones de dólares
 Trabajadores: 697.000 ingenieros de software –585.000 programadores
 El gobierno USA estima que las empresas han gastado cerca de 3,3 trillones de dólares en tecnologías de la
información en la última década

CARACTERÍSTICAS Y EVOLUCIÓN DEL

REALIDADES DEL SOFTWARE SOFTWARE
 un poco de historia
 El 55% de los sistemas cuestan más de lo esperado, el 68% superan la  primeras décadas:
fecha de entrega y el 88% tuvieron que ser sustancialmente rediseñados  desarrollar el hardware
 reducir costes de procesamiento y almacenamiento
Informe de IBM (1994)
 década de los ochenta:
 desarrollo de la microelectrónica
 La media era 100 dólares por línea de código, se esperaba pagar 500  mayor potencia de cálculo y reducción de costes
 objetivo actual: mejorar la calidad de las soluciones software.
dólares por línea, y se terminó pagando entre 700 y 900 dólares por línea,
6.000 millones de dólares de trabajo fueron descartados
 Orientación
1959 - 1965 1965 - 1975 1975 - 1989 1989 -
Advanced Automation System (FAAm 1982-1994) por lotes  Multiusuario
 Sistemas distribuidos  Potentes sistemas
 Inteligencia Artificial de sobremesa
 Tiempo real
 Hardware de bajo  Tecnología de objetos
 Distribución  Bases de datos
 Software como
coste  Sistemas expertos
 Impacto en el  Redes neuronales
 Cada 6 nuevos sistemas puestos en funcionamiento, 2 son cancelados, la limitada producto
 Mayores gastos
consumo  Cliente/servidor
 Redes area local  Tecnologías de
probabilidad de cancelación está alrededor del 50% para sistemas  Software a de mantenimiento
y global Internet.
 Gran demanda
grandes, la media de proyectos que sobrepasa el calendario es del 50%, 3 medida
de cada 4 sistemas son considerados como fallos de operación AUMENTAN los problemas del desarrollo de software:

Bureau of Labor Statistics (1997)  Subexplotacióndel potencial del hardware

 Incapacidad de atender a la demanda
 Incapacidad de mantener el software existente

NATURALEZA Y PROBLEMAS DEL NATURALEZA Y PROBLEMAS DEL

DESARROLLO DE SOFTWARE DESARROLLO DE SOFTWARE
 El software como elemento lógico.  Causas de la crisis del software
 Se desarrolla, no se fabrica:
Insatisfacción del cliente
 Naturaleza lógica del software
 Calidad del diseño.
 Mala gestión de los proyectos ( ausencia de datos, deficiente
 Costes más importantes en la Planificación y estimaciones
imprecisas comunicación, ...)
ingeniería
 Ausencia de entrenamiento formal en nuevas técnicas
 Gestión especial de los proyectos

 Se “deteriora” con el mantenimiento

Sin tiempo para recoger (programadores vs. ingenieros de software)
datos históricos  Resistencia al cambio
MITOS DE GESTIÓN
 Desarrollo a medida (ausencia de
- Uso de estándares
componentes)  Mitos del software: - Uso de herramientas
- Mala planificación: aumento
 La “crisis” del software: problemas que Calidad de programadores
aparecen en el desarrollo del software al
desarrollar, mantener y atender la demanda de
MITOS DE LOS DESARROLLADORES MITOS DEL CLIENTE
nuevas aplicaciones. Baja productividad
- Programa funcionando = fin del trabajo - Requisitos establecidos como
- Calidad = el programa se ejecuta una declaración general de
sin errores
Dificultad de mantener - Entrega al cliente: programa
objetivos
- Flexibilidad del software ante
el software existente funcionando los cambios

1
 25/08/2015

EL PROCESO: MODELOS DE DESARROLLO

 PROCESO:
 conjunto ordenado de tareas, una serie de pasos que involucran actividades,
restricciones y recursos, que producen una salida determinada
 PROCESO DE SOFTWARE: conjunto de actividades necesarias para transformar

MODELOS DE PROCESO DEL los requisitos de un usuario en un sistema software

 CARACTERÍSTICAS:

 tiene una serie de actividades principales

SOFTWARE  utiliza recursos, está sujeto a restricciones y genera productos intermedios y

finales
 compuesto por subprocesos que se encadenan de alguna forma

 cada actividad tiene sus criterios de entrada y salida, que permiten conocer
cuando comienza y termina dicha actividad
 existen principios orientadores que explican las metas de cada actividad

 cuando implica la construcción de un producto, se suele llamar ciclo de vida

 aportan consistencia y estructura sobre el conjunto de actividades, lo que permite

realizar la misma tarea correctamente de forma repetida
 existen diferentes modelos de proceso

Requisitos
del usuario Sistema software
Proceso de desarrollo
de Software

Comunicación
inicio del proyecto
recabar los
En el desarrollo en cascada, también llamado modelo en cascada (denominado así por la
requerimientos
posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad”
hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las
etapas del procesos para desarrollo de software, de tal forma que el inicio de cada etapa
debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está
diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir
Es importante señalar 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 pudiéndose requerir
nuevos resultados a mitad del proceso de elaboración del software de una manera.
Planeación Realiza un estudio de factibilidad del software así como contemplar los posibles
estimación costos que pueden surgir mediante su implementación.

está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la programación
base de todos los demás modelos de ciclo de vida. seguimiento

Realiza la descripción de la estructura relacional global

CARACTERISTICAS del sistema y la especificación de lo que debe hacer cada
Modelado una de sus partes, así como la manera en que se
combinan unas con otras.
análisis
Es el más utilizado. diseño
Es una visión del proceso de desarrollo de software como una
sucesión de etapas que produce productos intermedios.
Si se cambia el orden de las fases, el producto final será de inferior
calidad. Es la fase en donde se implementa el código fuente, haciendo uso de prototipos
Construcción
así como de pruebas y ensayos para corregir errores. código
pruebas
Despliegue
entrega
Una de las etapas más críticas, es el mantenimiento del Software ya que al asistencia
utilizarlo como usuario final puede ser que no cumpla con todas nuestras
expectativas. retroalimentación

MODELO EN CASCADA VENTAJAS

Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se

requiere de menos capital y herramientas para hacerlo funcionar de manera óptima.
Requerimentos
y Análisis Es un modelo fácil de implementar y entender.
Está orientado a documentos.
Diseño Es un modelo conocido y utilizado con frecuencia.
Promueve una metodología de trabajo efectiva: Definir antes que diseñar, diseñar antes que
Implementación
codificar.
Pruebas
DESVENTAJAS
Mantenimiento
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementación del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso
Resultado de cada fase: uno o más Se retrasa la localización y corrección de de prueba y hasta que el software no esté completo no se opera. Esto es la base para que
documentos aprobados errores funcione bien.
Una fase comienza cuando la anterior Pueden producir sistemas poco útiles Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al
termina para usuarios o mal estructurados rediseño y nueva programación del código afectado, aumentando los costos del desarrollo.
En la práctica, las etapas se solapan Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya
Inflexibilidad del modelo: dificultad para
culminado la etapa anterior.
Iteraciones de coste elevado y responder a cambios en los
reelaboración del trabajo: tendencia a la requerimientos
congelación de partes del desarrollo
(especificaciones,...)

2
 25/08/2015

FASES
Especificación de requerimientos: Se
realizan entrevistas con el usuario
identificando los
Análisis
requerimientos y necesidades del
Modela los requerimientos del usuario.
Los métodos de diseño del software se obtienen del estudio de cada uno de los tres usuario.

dominios del modelo de análisis. El dominio de los datos, el funcional y el de

comportamiento sirven de directriz para la creación del diseño.
Diseño
En el diseño estructurado moderno, partimos de la representación del flujo de la Instalación Se modela la solución del sistema, teniendo en cuenta
información obtenida en la fase de análisis, donde la información puede representarse el ambiente de implementación
como un flujo continuo que sufre una serie de transformaciones conforme va de la entrada a utilizar, por ejemplo, si el sistema es centralizado o
distribuido, la base de datos a utilizar, lenguaje de
a la salida. programación, performance deseada, etc.
Convertir bases de datos
Esto involucra la
CARACTERISTICAS especificación de diseño. Implantar
Implementación: Dado el lenguaje de
programación elegido se implementa el
Los productos de análisis han de ser de mantenimiento muy sencillo. Esto concierne sistema.
concretamente al documento final (Especificación de requisitos del software). Describir procedimientos
Se deben tratar los problemas de gran tamaño mediante algún método efectivo de Elaborar manuales de usuario Generar pruebas
partición. Dado el lenguaje de programación
elegido se implementa el sistema.
Siempre que sea posible, se deben utilizar gráficos.
Tenemos que diferenciar las consideraciones lógicas (esenciales) y las físicas (de
Control de calidad
implementación). Prueba final o prueba de aceptación

VENTAJAS

Adecuado para sistemas pequeños y de complejidad baja. El modelo incremental combina elementos de los
flujos de proceso lineal y paralelo, el modelo
incremental aplica secuencias lineales en forma
DESVENTAJAS escalonada a medida que avanza el calendario de
actividades. Cada secuencia lineal produce
Si se comete un error en alguna fase repercute en la fase “incrementos” de software susceptibles de
subsecuente, pero no se descubre sino hasta que se tiene el entregarse
sistema.
El sistema solo se ve funcionando hasta el final por lo que el usuario CARACTERISTICAS
se desespera por no ver resultados.
Es útil en particular cuando no se dispone de personal para la implementación
Las personas responsables de las fases
completa del proyecto en el plazo establecido por el negocio.
subsecuentes no pueden empezar hasta que terminen las personas
Se evitan proyectos largos y se entregas avances del proyecto a los usuarios con cierta
de la fase antecedente
frecuencia
El usuario se involucra más
Difícil de evaluar costo total
Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar
como un todo.
Requiere gestores experimentados.

DESARROLLO INCREMENTAL FASES

PASOS:
Definición general de
requerimientos identificación y priorización de funciones y servicios
definición de varios requerimientos que proporcionan
Asignación de requerimientos
parte de la funcionalidad, según la prioridad (los más
a incrementos importantes se entregan antes)
definición detallada de requerimientos del incremento y
Diseño de la arquitectura del
desarrollo con el proceso más adecuado
sistema
congelación de requerimientos de incrementos
desarrollados
Desarrollo de incrementos puesta en explotación de los incrementos completados y
del sistema entregados
VENTAJAS:
Validar
incrementos puesta en marcha temprana
los incrementos iniciales permiten refinar requerimientos
Integrar de incrementos posteriores
incrementos
satisfacción del cliente (bajo riesgo de fallo)
Validar sistema final muy probado y con pocos fallos
sistema
PROBLEMAS:
En cada incremento se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario
sistema incompleto
incrementos relativamente pequeños pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema
sistema completo adaptación de requerimientos a incrementos del tamaño y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente. Para guiar el
apropiado proceso de iteración se puede utilizar las etapas de modelo en cascada

Sistema final
identificación de recursos comunes a todos los
incrementos

3
 25/08/2015

VENTAJAS
Cada etapa consiste de requerimientos, diseño, codificaciones prueba y entrega. El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez
La solución se va mejorando de forma progresiva a través de las múltiples iteraciones por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de software. Las
Incrementa el entendimiento del problema y de la solución por medio de los actividades de este modelo se conforman en una espiral, en la que cada bucle
refinamientos sucesivos o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna
Reduce el riesgo de fallas en el proyecto global prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por
Prioriza los requisitos de usuario y los requisitos de más alta prioridad se incluyen en el bucle interior.
los incrementos más tempranos
Este modelo fue propuesto por Boehm en 1998. Básicamente consiste en una serie de ciclos
El usuario se involucra más
que se repiten en forma de espiral, comenzando desde el centro.
Se puede financiar el proyecto por partes
No necesita mucho personal
En cada vuelta o iteración hay que tener en cuenta:
Los Objetivos: qué necesidad debe cubrir el producto.
DESVENTAJAS Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde
diferentes puntos de vista como pueden ser:
Requiere de mucha planeación administrativa y técnica Características: experiencia del personal, requisitos a cumplir, etc.
Requiere de metas claras para conocer el estado del proyecto Desarrollar y Verificar: Programar y probar el software.
Difícil de evaluar el costo total Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:
Los errores en los requisitos se detectan tarde Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral
Las primeras versiones son incompletas pero proporcionan al usuario la tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:
funcionalidad que precisa y una plataforma para su evaluación Angular: Indica el avance del proyecto del software dentro de un ciclo.
Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa
más tiempo desarrollando.

MODELO EN ESPIRAL CARACTERISTICAS

Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente.
PROPUESTO POR BARRY BOEHM Este modelo es el indicado para desarrollar software
Con diferentes versiones actualizadas como se hace con los programas modernos.
ORGANIZACIÓN EN CICLOS PROGRESO

DETERMINAR
A TRAVÉS La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción
DE LAS ITERACIONES
primer ciclo: factibilidad EVALUAR ALTERNATIVAS,
OBJETIVOS,
ALTERNATIVAS Y IDENTIFICAR Y de prototipos.
RESTRICCIONES RESOLVER RIESGOS
segundo ciclo: requerimientos
tercer ciclo: diseño
Análisis de riesgos
FASES
... Análisis de riesgos Comunicación con el cliente: esta es una tarea Requerida para
CADA CICLO SE DIVIDE EN 4 establecer comunicación entre el desarrollador y el cliente.
SECTORES Análisis de riesgos
Prototipo Planificación: esta tarea es necesaria aplicarla para Poder definir los
operativo
definición de objetivos, An.
Riesgo.
Prototipo 3 recursos, el tiempo y otras informaciones relacionadas con el proyecto,
restricciones del producto y REVISIÓN
Proto-
-
tipo 1
Prototipo 2
es decir, son todos los requerimientos.
proceso, plan de
administración,... . Plan de
requerimientos
Simulaciones, modelos, Análisis de riesgos: esta es una de las tareas principales por lo que se
Concepto de pruebas comparativas
Plan de ciclo
de vida
operación
Requerimientos
aplica el modelo en espiral, es requerida para evaluar los riesgos
evaluación y reducción de de software
riesgos (por ejemplo, mejor Diseño del Diseño técnicos y otras informaciones relacionadas con el proyecto.
producto detallado
definición de requerimientos Plan de
desarrollo
Validación de
requerimientos
Ingeniería: esta es una tarea necesaria ya que se requiere construir una
mediante prototipos) Codificar o más representaciones de la aplicación.
Plan de integración
Diseño de validación
desarrollo y validación: y prueba
y verificación Prueba de
unidad
Construcción y adaptación: esta tarea es requerida
elección de un modelo para el PLANIFICAR SIGUIENTE

desarrollo
FASE
Prueba de
en el modelo espiral porque se necesita construir, probar, instalar y
integración
Prueba de
aceptación
proporcionar soporte al usuario.
planificación: el proyecto se -
Explotación
revisa y se decide si se DESARROLLAR, VERIFICAR
PRODUCTO DE SIGUIENTE NIVEL
continúa con el siguiente
ciclo. si es así, se planifica la
siguiente fase

Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la reacción
del cliente según la evaluación de las representaciones del software creadas durante la etapa
de ingeniería y la de implementación creada durante la etapa de instalación
Es un modelo del comportamiento del sistema que puede ser usado para entenderlo
VENTAJAS completamente o ciertos aspectos de él y así clarificar los requerimientos. Un prototipo es
una representación de un sistema, aunque no es un sistema completo, posee las
No requiere una definición completa de los requerimientos del software a desarrollar características del sistema final o parte de ellas”
para comenzar su funcionalidad.
En la terminación de un producto desde el final de la primera iteración es muy factible
aprobar los requisitos. CARACTERISTICAS
Sufrir retrasos corre un riesgo menor, por que se comprueban los conflictos
presentados tempranamente y existe la forma de poder corregirlos a tiempo
Funcionalidad limitada.
DESVENTAJAS Poca fiabilidad.
Existe complicación cuando se evalúa los riesgos. Características de funcionalidad pobres.
Se requiere la participación continua por parte del cliente. Alto grado de participación del usuario el cual evalúa los prototipos, propone mejoras y
Se pierde tiempo al volver producir inicialmente una especificación completa de detalla requisitos.
los requerimientos cuando se modifica o mejora el software Alto grado de participación del analista de sistemas, ya que en muchos casos los
usuarios no pueden indicar los requisitos sin tener experiencia con el sistema.
El prototipo da mayor conocimiento al usuario y analistas ayudando a que el usuario
aprenda a utilizar el sistema.

4
 25/08/2015

FASES
Investigación preliminar. Las metas principales de esta fase
VENTAJAS
son: determinar el problema y su ámbito, la importancia y sus Reducción de la incertidumbre y del riesgo
efectos potenciales sobre la organización por una parte y, por
otro lado, identificar una idea general de la solución para Reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema,
realizar un estudio de factibilidad que determine la Mejoras en la administración de proyectos
factibilidad de una solución software. Mejoras en la comunicación entre desarrolladores y clientes, etc.
Definición de los requerimientos del sistema. El objetivo de
esta etapa es registrar todos los requerimientos y deseos que
los usuarios tienen en relación al proyecto bajo desarrollo.
Esta etapa es la más importante de todo el ciclo de vida, es
aquí donde el desarrollador determina los requisitos DESVENTAJAS
mediante la construcción, demostración y
retroalimentaciones del prototipo. Por lo mismo esta etapa
será revisada con más detalle luego de esta descripción. La dependencia de las herramientas de software para el éxito ya que la necesidad de
Diseño técnico. Durante la construcción del prototipo, el disminución de incertidumbre depende de las iteraciones del prototipo, entre más iteraciones
desarrollador ha obviado el diseño detallado. El sistema debe exista mejor y esto último se logra mediante el uso de mejores herramientas lo que hace a
ser entonces rediseñado y documentado según los este proceso dependiente de las mismas.
estándares de la organización y para ayudar a las
mantenciones futuras. Esta fase de diseño técnico tiene dos También, no es posible aplicar la metodología a todos los proyectos de software y, finalmente,
etapas: por un lado, la producción de una documentación de la mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden confundir
diseño que especifica y describe la estructura del software, el con el sistema terminado.
control de flujo, las interfaces de usuario y las funciones y,
como segunda etapa, la producción de todo lo requerido No se puede desconocer que la fase de definición de requerimientos se ha perfeccionado en
para promover cualquier mantención futura del software. dos aspectos importantes: primero se ha aproximado las visiones del usuario y el
Programación y prueba. Es donde los cambios identificados en el diseño técnico son implementados y desarrollador, lo cual representa el beneficio de establecer una base común de comunicación;
probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos. también, el hacer explícita la posibilidad de iterar sobre estos dominios permitiría que la
Operación y mantención. La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se convergencia de los mismos sea una posibilidad cierta.
supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Además, la mantención también debería ser una
fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual
las mantenciones perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y
se definirá un nuevo conjunto de requerimientos.

FASES

La metodología consta de procesos estos se descomponen en actividades, y éstas a su vez en

Es una metodología de planificación, desarrollo y mantenimiento de sistemas de información, tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones,
promovida por el Ministerio de Hacienda y Administraciones Públicas de España para la productos, técnicas, prácticas y participantes.
sistematización de actividades del ciclo de vida de los proyectos de software
Planificación de
 Definición de la arquitectura tecnológica
CARACTERISTICAS Sistemas de  Definición del plan de acción
Información

Fue creada para el desarrollo de sistemas de Información  Estudio de la viabilidad del sistema (EVS)
Tiene un enfoque orientado al proceso  Análisis del sistema de información (ASI)
Cubre el proceso de desarrollo y mantenimiento de información Desarrollo de  Diseño del Sistema de información (DSI)
 Construcción del sistema de información (CSI)
Facilita el entendimiento de los distintos participantes en la producción del software a lo Sistemas de  Implantación y aceptación del sistema (IAS)
largo del ciclo de vida del proyecto. Información
Ayuda a la planificación de sistemas de información de la organización
Es posible tramitar proyectos OO y proyectos estructurados
Cumple objetivos de calidad, coste y plazos  Análisis de la petición
 Implementación de la modificación
Mantenimiento de  Seguimiento y evaluación de los cambio
Sistemas de  Registro de la petición
 Preparación de la implementación de la
Información modificación

VENTAJAS
Involucra a toda la estructura organizativa, desde la alta dirección que determina las Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los
estrategias que marcaran la planificación de un sistema de información hasta los procesos y se mide la eficiencia de la organización.
programadores que escribirán el código que soporte dicho sistema, analistas, jefes de Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML,
proyecto, consultores, etc. constituye la metodología estándar más utilizada para el análisis, implementación y
A través de su implementación las empresas pueden obtener una visión clara de los documentación de sistemas orientados a objetos.
beneficios técnicos, organizativos y económicos El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada
Optimiza la productividad de los departamentos de sistemas y tecnologías de la organización. Describe como aplicar enfoques para el desarrollo del software, llevando a cabo
información y las comunicaciones unos pasos para su realización. Se centra en la producción de modelos de sistema.
Facilidad de uso desde la perspectiva del programador
CARACTERISTICAS
DESVENTAJAS
Es un sistema demasiado pesado tanto en su implementación, como en sus procesos de
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
mantenimiento.
cuándo y cómo)
Se debe contar con un buen conjunto de métricas y parámetros de calidad, lo cual para
Pretende implementar las mejores prácticas en Ingeniería de Software
algunas organizaciones puede ser difícil definir
Desarrollo iterativo
No existe un estándar generalmente aceptado
Administración de requisitos
No proporcionan información por sí solas y a veces en vez de claridad aportan
Uso de arquitectura basada en componentes
confusión
Control de cambios
Modelado visual del software
Verificación de la calidad del software

5
 25/08/2015

FASES

Elaboración Transición (fin del

LA VIDA DEL PROCESO UNIFICADO
Inicio (Define el Construcción
(Definición, análisis, proyecto y puesta en
alcance del proyecto) (Implementación)
diseño) producción)
Fases
Flujos de trabajo Inicio Elaboración Construcción Transición
Planear las 4 fases incluye:
fundamentales
 Asignación de tiempo
 Hitos Principales Requisitos
 Iteraciones por Fases una iteración en la
 Plan de proyecto.
Análisis
fase de elaboración
RUP define nueve disciplinas a
realizar en cada fase del proyecto:
 Modelado del negocio Diseño
 Análisis de requisitos
 Análisis y diseño
 Implementación
Implementación
 Test
 Distribución
 Gestión de configuración y
Cada fase en RUP puede cambios Prueba
descomponerse en iteraciones. Una  Gestión del proyecto
iteración es un ciclo de desarrollo  Gestión del entorno
completo dando como resultado
una entrega de producto ejecutable iter #1 iter #2 --- --- --- --- --- iter #n-1 iter #n
(interna o externa)
Iteraciones

VENTAJAS
LA VIDA DEL PROCESO UNIFICADO Esta es una metodología completa en sí misma, con un énfasis en la documentación
precisa
 El proceso unificado se repite a lo largo de una serie de ciclos Es capaz de resolver de forma proactiva los riesgos del proyecto asociado a las nuevas
 Cada ciclo concluye con una versión del producto y consta de cuatro fases
necesidades de los clientes que requieren una cuidadosa gestión de solicitud de cambio
 INICIO: descripción del producto final a partir de una idea inicial y análisis de negocio
para el producto Se requiere menos tiempo para la integración en el proceso de integración va a lo largo
 principales funciones del sistema y usuarios más importantes (modelo de casos de del ciclo de vida de desarrollo.
uso) El tiempo de desarrollo menor debido a la reutilización de
 posible arquitectura del sistema
 plan del proyecto, coste, identificación y priorización de riesgos
 ELABORACIÓN:
DESVENTAJAS
 se especifican en detalle los principales casos de uso
 se diseña la arquitectura del sistema: vistas arquitectónicas del modelo de casos
de uso, del modelo de análisis, del modelo de diseño, del modelo de
implementación y modelo de despliegue
 al final se pueden planificar las actividades y estimar recursos necesarios para Los miembros del equipo deben ser expertos en su campo para desarrollar un software
finalizar el proyecto bajo esta Metodología.
 CONSTRUCCIÓN: El proceso de desarrollo es demasiado complejo y desorganizado
 se crea el producto añadiendo el software a la arquitectura
En la reducción de los proyectos de vanguardia que utilizan las nuevas tecnologías, la
 al final se dispone de todos los casos de uso acordados para el desarrollo aunque
puede incorporar defectos reutilización de componentes no será posible.
 TRANSICIÓN: La integración en el proceso de desarrollo de software, en teoría
 periodo durante el cual el producto se convierte en versión beta, en la que usuarios parece una buena cosa. Pero en particular los grandes proyectos de
prueban el producto e informan de defectos y deficiencias
 se corrigen problemas e incorporan sugerencias
desarrollo con flujos múltiples que sólo servirá para aumentar la
 incluye actividades como la formación del usuario, proporcionar una línea de ayuda confusión y causar más problemas durante las etapas de la prueba
y asistencia,...
 Cada fase se divide a su vez en iteraciones

FASES Modelado de gestión: el flujo de información

entre las funciones de gestión se modela de
forma que responda a las siguientes preguntas:
El RAD es un proceso de desarrollo de software, desarrollado ¿Qué información conduce el proceso de
inicialmente por James Martin en 1980. El método gestión? ¿Qué información se genera? ¿Quién la
comprende el desarrollo iterativo, la construcción de genera? ¿A dónde va la información? ¿Quién la
proceso?
prototipos y el uso de utilidades CASE. Tradicionalmente, el
desarrollo rápido de aplicaciones tiende a englobar también Modelado de datos: el flujo de información
la usabilidad, utilidad y la rapidez de ejecución. definido como parte de la fase de modelado de
gestión se refina como un conjunto de objetos de
datos necesarios para apoyar la empresa. Se
CARACTERISTICAS definen las características (llamadas atributos) de
cada uno de los objetos y las relaciones entre
estos objetos.

Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de
tiempo completo del sistema así como aquellas personas involucradas con los requisitos.
Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en
uno.
Se realiza Reuniones JAD (Joint Application Development)
Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
Los clientes prueban el prototipo, depuran los requisitos.
Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y
generar solicitudes de cambios.
Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es
necesario para cumplir el calendario.
Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados
para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del
proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los
objetos.
Generación de aplicaciones: El desarrollo rápido de aplicaciones asume la utilización de técnicas de cuarta
generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA
trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear
componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para
facilitar la construcción del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos
de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben
probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

6
 25/08/2015

VENTAJAS
Comprar puede ahorrar dinero en comparación con construir.
El desarrollo de software basado en componentes (en lo adelante
Los entregables pueden ser fácilmente trasladados a otra DSBC) constituye una aproximación del desarrollo de software que
plataforma. describe, construye y emplea técnicas software para elaborar
El desarrollo se realiza a un nivel de abstracción mayor. sistemas abiertos y distribuidos, mediante el ensamblaje de partes
Visibilidad temprana. software reutilizables.
Mayor flexibilidad. Los componentes software surgen, en cierta medida de la necesidad de desarrollar sistemas mediante el
Menor codificación manual. ensamblaje de módulos independientes ya existentes, se puede afirmar que un componente, en esencia, es
Mayor involucramiento de los usuarios. una unidad reutilizable que puede interoperar con otros módulos de software por medio de sus interfaces, las
Posiblemente menos fallas. cuales define desde donde se puede tener acceso a los servicios que este ofrece a los demás componentes.
Posiblemente menor costo.
Un componente puede presentarse en forma de código fuente o código objeto; puede estar escrito en
Ciclos de desarrollo más pequeños.
lenguaje funcional, procedural u orientado a objetos y puede ser tan simple como un botón GUI o tan
Interfaz gráfica estándar. complejo como un subsistema
DESVENTAJAS CARACTERISTICAS
Comprar puede ser más caro que construir. Es utilizado para reducir los costos, tiempo y esfuerzos de desarrollo del software, y de esta manera
Costo de herramientas integradas y equipo necesario. incrementar el nivel de productividad de los grupos desarrolladores y minimizar los riesgos; a su vez ayuda a
Progreso más difícil de medir. optimizar la fiabilidad, flexibilidad y la reutilización de la aplicación final.
Menos eficiente. La modularidad, la reusabilidad y componibilidad son características muy relevantes de la tecnología de
programación basada en componentes, en las cuales coincide con la tecnología orientada a objetos de la
Menor precisión científica.
que puede considerarse una evolución. No obstante en esta tecnología también se requiere robustez debido
Riesgo de revertirse a las prácticas sin control de antaño. a que los componentes deben operar en entornos muchos más heterogéneos.
Más fallas (por síndrome de “codificar a lo bestia”). El DSBC, se corresponde al paradigma programación de sistemas abiertos, los cuales son extensibles y
Prototipos pueden no escalar, un problema mayúsculo. tienen una interacción con componentes heterogéneos que se integran o abandonan el sistema de
Funciones reducidas (por “timeboxing”). manera dinámica, o sea, que los componentes pueden ser substituidos por otros componentes,
Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales. independientemente de su arquitectura y desarrollo.

FASES VENTAJAS
El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los
espiral. Es de naturaleza evolutiva y demanda un enfoque iterativo para la creación de software. Sin componentes antes de probar el conjunto completo de componentes ensamblados.
embargo, el modelo de desarrollo basado en componentes construye aplicaciones a partir de Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre sus
fragmentos de software prefabricados. Sin importar la tecnología usada para crear los componentes, el desarrollador puede actualizar y/o adicionar componentes según sea
componentes, el modelo de desarrollo basado en componentes incorpora las etapas siguientes: requerido, sin afectar otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego optimizado
Se investigan y evalúan, para el tipo de aplicación de que se trate, continuamente por un experto u organización, la calidad de una aplicación basada en
productos disponibles basados en componentes. componentes mejorará con el paso del tiempo
DESVENTAJAS
Se consideran los aspectos de integración de los Falta de disponibilidad de componentes: La principal dificultad que encuentran las empresas
componentes. que tratan de implantar metodologías basadas en componentes, es la dificultad de encontrar
suministradores de componentes con el estándar industrial requerido y de su dominio de
aplicación específico.
Se diseña una arquitectura del software para que Falta de estándares estables: Un requisito indispensable para conseguir la confianza de los
reciba los componentes. diseñadores de software en la tecnología de componentes y consolidar así el mercado
subyacente, es que el estándar en el que se basa la tecnología permanezca estable a lo largo
del tiempo.
Se integran los componentes en la arquitectura Falta de componentes certificados y organizaciones con autoridad de certificación: La adopción
de una nueva tecnología se lleva a cabo en dos fases: primero se trabaja en demostrar su
viabilidad, e inmediatamente después, se trabaja para garantizar la calidad de los productos.
Se efectúan pruebas exhaustivas para asegurar la Falta de métodos y procesos de ingeniería para desarrollar sistemas con calidad : Actualmente
funcionalidad apropiada. está aceptado que el desarrollo de aplicaciones utilizando tecnologías de componentes
requiere un nuevo proceso de ingeniería, con nuevas fases y nuevos agentes

FASES  Diseños simples.

 Glosarios de términos.
 Riesgos.
El Desarrollo extremo (eXtreme programaming) es una metodología de desarrollo que  Historias de usuario.  Funcionalidad extra.
busca la simplicidad y ligereza en desarrollo de un proyecto de software; por esta razón  Release planning. Tarjetas C.R.C.
esta metodología es apropiada para proyectos en los que durante su desarrollo pueden  Iteraciones
cambiar las necesidades del cliente y así mismo es necesario actualizar todo el proceso  Velocidad del Diseño
de ingeniería desarrollado; esta metodología busca adaptarse rápidamente al cambio proyecto.
 Programación en
disminuyendo todo lo posible los costes de: tiempo, talento humano, equipos, etc.
pareja.
Codificación
 Reuniones diarias.
CARACTERISTICAS
Planificación
se basa en la filosofía de que el mayor valor de negocio es entregado por el
programa más sencillo que cumpla los requerimientos. Programación por parejas
Tiene un código con propiedad compartida. Nadie es el propietario de nada.
Este método difiere en mucho a los métodos tradicionales en los que un
simple programador posee un conjunto de código.
Define la propiedad del código compartido así como las reglas para escribir y Pruebas
documentar el código y la comunicación entre diferentes piezas de código
desarrolladas por diferentes equipos. Los programadores las han de seguir de
tal manera que el código en el sistema se vea como si hubiera estado escrito
por una sola persona.
El uso de los test en X.P es el siguiente.
Test de aceptación.

7
 25/08/2015

VENTAJAS
Programación organizada.
Menor taza de errores. Evo, creado por Tom Gilb, es el método iterativo ágil más antiguo. Se lo llama
Satisfacción del programado también Evolutionary Delivery, Evolutionary Management, Requirements Driven
Presto a cambios Project Management y Competitive Engineering. Fue elaborado inicialmente en
Europa.

DESVENTAJAS CARACTERISTICAS

Es factible solo en proyectos a corto plazo.
La falta de documentación que no se hace, ya que todos saben del proyecto, no
permite recoger la experiencia para próximos proyectos
Metas, Valores y Costos – Cuánto y cuántos recursos. Las Metas y Valores de los
Soluciones Banco de ideas sobre la forma de alcanzar Metas y Valores dentro del
rango de los Costos. Estimación de Impacto – Mapear las Soluciones a Metas y
Costos para averiguar si se tienen ideas adecuadas para lograr las Metas dentro
de los Costos.
Plan Evolutivo – Inicialmente una idea general de la secuencia a desarrollar y
evolucionar hacia las Metas. Los detalles necesarios evolucionan junto con el
resto del plan a medida que se desarrolla el producto/servicio.
Funciones – Describen qué hace el sistema. Son extremadamente secundarias,
más de lo que se piensa, y deben mantenerse al mínimo.

FASES En proyectos evolutivos, las Metas se

desarrollan tratando de comprender de
quiénes vienen (Participantes), qué es lo
que son (medios y fines) y cómo expresarlas
(cuantificables, medibles y verificables). Se
procura pasar el menor tiempo posible en
tareas de documentación. En las formas
más simples y relajadas de Entrega
Evolutiva, a veces llamada Entrega
Incremental, liberar parte de una solución
es un Paso de Entrega Evolutiva. En la
Entrega Evolutiva más pura y más rica, sólo
las mejoras en las Metas de los
Participantes se consideran un Paso de
Entrega Evolutiva

VENTAJAS DESVENTAJAS
Mejora la productividad
Acelera la adopción de Para una mejora en el proceso de desarrollo de
técnicas moderna software que sea significativa se requiere un ataque
Mejora la calidad de balanceado a través de varias dimensiones
software interrelacionadas.