1

EL PROCESO DE DESARROLLO

Winnie Quito

Liana Perez

Brandon Hilas

Computacion e Informatica,Carlos Cueto Fernandini

Analisis y Diseño de Sistema

Beltran Fuentes Rivera

20 de Abril de 2021
 2
AGRADECIMIENTO

Al Instituto Cueto Fernandini por el interés de contribuir en la transformación de nuestro

pensamiento, al Profesor Beltrán por su valioso apoyo y mediación en la construcción del

conocimiento en los estudiantes cuetinos.

 3

INDICE

I. PROCESO DE DESARROLLO DEL SOFTWARE..........................................................6

I.1. GENERALIDADES:.....................................................................................................7

I.2. FASES DEL PROCESO DE DESARROLLO DE SOFTWARE:..............................8

I.3. PRÁCTICAS DEL PROCESO DE DESARROLLO DE SOFTWARE:.................18

I.4. METODOLOGÍAS PARA EL DESARROLLO DE SOFTWARE:........................25

I.4.1. METODOLOGÍA XP (Programación Extrema).................................................26

I.4.2. METODOLOGÍA SCRUM...................................................................................27

I.4.3. METODOLOGÍA RUP.........................................................................................29

II. MODELOS DEL PROCESO DE DESARROLLO DE SOFTWARE:........................35

II.1. MODELO EN CASCADA O CONVENCIONAL.................................................37

II.2. MODELOS DE PROCESO INCREMENTAL......................................................38

II.3. MODELO EVOLUTIVO........................................................................................40

II.4. MODELO TRANSFORMACIONAL....................................................................41

II.5. MODELO EN ESPIRAL.........................................................................................42

II.6. • MODELO DE PROTOTIPOS..............................................................................46

II.7. DESARROLLO POR ETAPAS..............................................................................47

III. LENGUAJE UNIFICADO DE MODELADO (UML)..................................................51

III.1. UNIFICADO............................................................................................................53
 4
III.2. MODELADO...........................................................................................................55

III.3. DIAGRAMAS DE CLASE......................................................................................56

III.4. DIAGRAMAS DE IMPLEMENTACIÓN.............................................................61

III.5. DIAGRAMAS DE USO DE CASO.........................................................................62

III.6. DIAGRAMAS DE SECUENCIA............................................................................62

III.7. DIAGRAMAS DE COMUNICACIÓN..................................................................64

III.8. DIAGRAMAS DE ACTIVIDAD............................................................................65

III.9. DIAGRAMAS DE ESTADO...................................................................................67

IV. PROCESO UNIFICADO DE DESARROLLO.............................................................68

IV.1. INTRODUCCIÓN...................................................................................................68

IV.2. CARACTERÍSTICAS PRINCIPALES.................................................................68

IV.3. FASES.......................................................................................................................69

IV.4. COMPONENTES Y SERVICIOS..........................................................................72

IV.5. CASOS DE USO......................................................................................................72

IV.6. VENTAJAS Y RECOMENDACIONES DE USO.................................................73

IV.7. CONCLUSIONES....................................................................................................75

INTRODUCCION
 5
Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se

realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente

definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina

construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido

históricamente cuestionados debido a los problemas asociados. Según el Centro Experimental de

Ingeniería de Software (CEIS), el estudio de mercado The Chaos Report realizado por Standish Group

Internactional en 1996, concluyó que sólo un 16% de los proyectos de software son exitosos (terminan

dentro de plazos y costos y cumplen los requerimientos acordados). Otro 53% sobrepasa costos y plazos y

cumple parcialmente los requerimientos. El resto ni siquiera llega al término. El primer reconocimiento

público de la existencia de problemas en la producción de software tuvo lugar en la conferencia

organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch (Alemania), dicha situación

problemática se denominó crisis del software. En esta conferencia, así como en la siguiente realizada en

Roma en 1969, se estipuló el interés hacia los aspectos técnicos y administrativos en el desarrollo y

mantenimiento de productos software. Se pretendía acordar las bases para una ingeniería de construcción

de software. Según Fritz Bauer lo que se necesitaba era "establecer y usar principios de ingeniería

orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre

máquinas reales".
 6

I. PROCESO DE DESARROLLO DEL SOFTWARE

En ingeniería del software, un proceso de desarrollo del software es el proceso de dividir

el trabajo de desarrollo del software en distintas fases para mejorar el diseño, la gestión del

producto, y la gestión de proyecto. Es también conocido como el ciclo de vida del desarrollo de

software. La metodología puede incluir la predefinición de entregas concretas y artefactos que

son creados y completados por un equipo del proyecto para desarrollar o mantener una

aplicación. La mayoría de procesos de desarrollo modernos pueden ser vagamente descritos

como ágiles. Otras metodologías incluyen desarrollo en cascada, prototipado, desarrollo iterativo

e incremental, desarrollo de espiral, desarrollo de aplicación rápida, y programación extrema.

Algunas personas consideran el "modelo" del ciclo de vida un término más general para

una categoría de las metodologías y el "proceso" de desarrollo de software un término más

concreto para referirse a un proceso concreto escogido por una organización específica. Por

ejemplo, hay muchos procesos de desarrollo de software concretos que encajan en la espiral del

modelo del ciclo de vida. Este campo es a menudo considerado un subconjunto del ciclo de vida

del desarrollo de sistemas. Cuando se va desarrollar un software intervienen muchas personas

como lo es el cliente que es el que tiene el problema en su empresa y desea que sea solucionado,

para esto existe el Analista de Sistema que es el encargado de hacerle llegar todos los

requerimientos y necesidades que tiene el cliente a los programadores que son las personas

encargadas de realizar lo que es la codificación y diseño del sistema para después probarlo y lo

instalan al cliente.
 7
I.1. GENERALIDADES:

La gran cantidad de organizaciones de desarrollo de software implementan metodologías

para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria

armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de

procesos para poder obtener un contrato. El estándar internacional que regula el método de

selección, implementación y monitoreo del ciclo de vida del software es ISO 12207.

Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y

predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan

sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software. Otros

aplican técnicas de gestión de proyectos para la creación del software. Sin una gestión del

proyecto, los proyectos de software corren el riesgo de demorarse o consumir un presupuesto

mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen sus metas en

términos de funcionalidad, costes o tiempo de entrega, una gestión de proyectos efectiva es algo

imprescindible.

Algunas organizaciones crean un grupo propio (Software Engineering Process Group,

abreviado SEPG) encargado de mejorar los procesos para el desarrollo de software en la

organización.
 8
I.2. FASES DEL PROCESO DE DESARROLLO DE SOFTWARE:

• Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Es la primera

de las etapas de desarrollo, corresponde a escuchar las peticiones para el sistema. Se planifica la

forma de llevar las ideas a un software, acá no debe ser un impedimento el lenguaje de

programación ni la infraestructura. Desde el consultor de sistemas se proponen mejoras que a

veces el usuario ignora para mejorar el programa. Se puede utilizar prototipos para que el usuario

tenga una vista previa y realice modificaciones antes de cualquier otra fase. Al final de esta fase

se verifica si existe un ambiente de sistemas previamente instalado o si es un desarrollo

totalmente nuevo. No olvidar incluir presupuesto de servidores, licencias, bases de datos entre lo

más destacado. Mientras que los clientes piensan que ellos saben lo que el software tiene que

hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer

requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el

cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya

 9
estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define

un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán

en el desarrollo del software. La captura, análisis y especificación de requisitos (incluso pruebas

de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos

finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no

está formalizada, ya se habla de la Ingeniería de Requisitos.

• Diseño y arquitectura

Se refiere a determinar cómo funcionará de forma general sin entrar en detalles. Consiste en

incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se

definen los casos de uso para cubrir las funciones que realizará el sistema, y se transforman las

entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo

cercano a la programación orientada a objetos. En esta fase es cuando se realiza toda la

infraestructura que va a sostener el proyecto. Normalmente hablamos de objetos de base de

datos, especialmente las tablas y las relaciones entre ellas. Se preparan todas las funcionalidades

necesarias para suplir los requerimientos detectados en el análisis. Se presenta un segundo

prototipo ya que el primero solo incluye funcionalidades, esta muestra algo de diseño. El usuario

siempre quiere incluir más cosas y se debe dejar en claro que esto influye en el tiempo y el costo

del proyecto. Tras aprobar el prototipo se presenta la propuesta y se llega a un acuerdo. El

problema principal está en calcular el tiempo para las etapas de desarrollo, para esto es mejor dar
 10
un tiempo previsto pero que se pague sobre las funcionalidades. Si el proyecto es muy complejo

es mejor realizarlo por etapas para evitar desbordar el tiempo y el costo de todo el programa.
 11

 Implementación

En esta fase hay que elegir las herramientas adecuadas, un entorno de desarrollo

que facilite el trabajo y un lenguaje de programación apropiado para el tipo de

software a construir. Esta elección dependerá tanto de las decisiones de diseño

tomadas como del entorno en el que el software deba funcionar. Al programar,

hay que intentar que el código no sea indescifrable siguiendo distintas pautas

como las siguientes:

- Evitar bloques de control no estructurados.

- Identificar correctamente las variables y su alcance.

- Elegir algoritmos y estructuras de datos adecuadas para el problema.

- Mantener la lógica de la aplicación lo más sencilla posible.

- Documentar y comentar adecuadamente el código de los programas.

- Facilitar la interpretación visual del código utilizando reglas de formato de código

previamente consensuadas en el equipo de desarrollo. También hay que tener en cuenta la

adquisición de recursos necesarios para que el software funcione, además de desarrollar casos de

prueba para comprobar el funcionamiento del mismo según se vaya programando.

 Programación y Desarrollo

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería

de software, pero no es necesariamente la porción más larga. La complejidad y la

 12
duración de esta etapa está íntimamente ligada al o a los lenguajes de

programación utilizados.

Es el momento del código es independiente del lenguaje de programación, de las

metodologías, del estilo del programador, etc. Se pueden presentar mejoras u objeciones sobre el

rendimiento del programa. Dentro de las etapas de desarrollo es la más delicada porque cada

modificación puede cambiar toda la planificación. Esta fase tiene en si sub-fases a implementar:

análisis y diseño, la codificación, pruebas ingenieriles y ajustes. El avance del software se suele

presentar aquí sobre el número de funcionalidades totales sobre las completadas.

 Pruebas ingenieriles

Estas son las pruebas de cada funcionalidad en cada pantalla o reporte. Se debe probar la

creación, modificación, consulta y eliminación en cada caso. Algunos ingenieros suelen

automatizar este proceso, pero yo prefiero hacerlo por lo menos híbrido. Ya que en el camino se

van presentando ajustes y pruebas sobre los mismos. Es preferible anotar todos los ajustes para

adaptarlos después sino esta fase se podría alargar demasiado. Estas pruebas son diferentes a las

pruebas principales ya que estas son realizadas por los programadores y las otras por usuarios

que normalmente no saben de programación.

 13

 Ajustes

Algunos incluyen esta fase con la anterior ya que apenas finaliza hay que realizar de

nuevo las pruebas. Puede haber varios ciclos que retrasan los proyectos, pero es inevitable en

algunos casos. Por otra parte, si los programadores son muy novatos se presentan demasiados

bugs (fallas del sistema). Entonces los equipos de desarrollo deberían tener una combinación

entre novatos y experimentados para la totalidad de las etapas de desarrollo.

 14

 Pruebas

Consiste en comprobar que el software realice correctamente las tareas indicadas en la

especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego

probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las

pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área

de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En

general hay dos grandes formas de organizar un área de pruebas, la primera es que esté

compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa

que la documentación entregada sea de calidad, que los procesos descritos son tan claros que

cualquiera puede entenderlos y el software hace las cosas tal y como están descritas.
 15
El segundo enfoque es tener un área de pruebas conformada por programadores con

experiencia, personas que saben sin mayores indicaciones en que condiciones puede fallar una

aplicación y que pueden poner atención en detalles que personal inexperto no consideraría. Estas

son pruebas realizadas por usuarios finales, los cuales debe estar disponibles. Es recomendable

tener varios usuarios ya que uno solo no encontraría todas las posibles fallas. Se puede presentar

una lista de pruebas a realizar para evitar que se salten módulos o pantallas. De acá se genera una

gran lista de bugs detectados que pasan a ajustarse en una serie de ciclos. Es muy importante

dejar en claro que no se van a desarrollar nuevas funcionalidades.

 Documentación
 16
La documentación del diseño interno del software con el objetivo de facilitar su mejora y

su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un

API, tanto interior como exterior. Todo lo concerniente a la documentación del propio desarrollo

del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas,

manuales de usuario, manuales técnicos, etc.; todo con el propósito de eventuales correcciones,

usabilidad, mantenimiento futuro y ampliaciones al sistema.

 Mantenimiento
 17
El mantenimiento o mejora de un software con problemas recientemente desplegado,

puede requerir más tiempo que el desarrollo inicial del software. Es posible que haya que

incorporar código que no se ajusta al diseño original con el objetivo de solucionar un problema o

ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede

que sea oportuno rediseñar el sistema para poder contener los costes de mantenimiento.

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto

puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda

la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo

consiste en arreglar errores, o bugs.

La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera

similar, alrededor de 2/3 de toda la Ingeniería civil, Arquitectura y trabajo de construcción es dar

mantenimiento. Se puede decir que con la mejora continua garantiza la calidad del producto, ya

que el estarla aplicando día con día es la mejor decisión que puede llegar a tener cualquier

empresa, porque de esta manera evita grandes problemas en la elaboración o desarrollo de los

productos. Esto es fundamental para todas las empresas ya que se vuelven competitivas, con

mayor productividad y eficiencia. No hay que olvidar que la mejora se da porque el cliente es el

rey y hay que satisfacer todas y cada una de sus necesidades siempre garantizando la calidad.
 18

I.3. PRÁCTICAS DEL PROCESO DE DESARROLLO DE SOFTWARE:

Varias aproximaciones del desarrollo del software han sido utilizadas desde el origen de

tecnología de la información, en dos categorías principales .[cita requerida] Normalmente una

aproximación o una combinación de aproximaciones es escogida por un equipo de gestión o de

desarrollo . Las metodologías "tradicionales" como la de cascada, que tiene distintas fases, son a

veces conocidas como metodologías del ciclo de vida de desarrollo de software (SDLC), aunque

este término también podría ser utilizado de manera más general para referirse a cualquier

metodología.[cita requerida] Un enfoque del "ciclo de vida" con distintas fases contrasta con los

enfoques de las ágiles que definen el proceso de iteración, pero donde el diseño, la construcción,

y el despliegue de partes diferentes pueden ocurrir simultáneamente .

 Integración continua

La integración continua es la práctica de juntar todas las copias del trabajo de los

desarrolladores en una rama principal compartida varias veces al día. Grady Booch primero

denominó y propuso el CI en su método de 1991, a pesar de que no defienda hacer la integración

varias veces al día.[5] La programación extrema (XP) adoptó el concepto de CI y defendió que

se hiciera la integración más de una vez al día – quizás tantas veces como decenas de muchos

como decenas de veces al día.

 19

 Prototipado

El prototipado de software consiste en la creación prototipos, p.e. las versiones

incompletas del software de un programa siendo desarrollado.

Los principios básicos son:

- El prototipado no es una metodología de desarrollo completa e independiente, sino más bien un

enfoque para probar características particulares en el contexto de una metodología completa

(como el desarrollo incremental, espiral o rápido de aplicaciones (RAD)).

 20
- Intentos de reducir los riesgos inherentes del proyecto a base de dividir un proyecto en

pequeños segmentos proporcionando facilidad de cambio durante el proceso de desarrollo.

- El cliente está implicado durante el proceso de desarrollo, lo cual aumenta la

probabilidad de que el cliente acepte la implementación final.

- Mientras algunos prototipos están desarrollados con la expectativa de que serán

descartados, es posible que en algunos casos evolucionen de prototipo a sistema operativo.

- Una comprensión básica del problema fundamental del negocio es necesaria para evitar

resolver los problemas equivocados, pero esto se cumple para todas las metodologías del

software.
 21
 Desarrollo incremental

Varios métodos son aceptables para combinar metodologías de desarrollo de sistemas

lineales e iterativos, con el objetivo principal de reducir el riesgo inherente del proyecto al dividir

un proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el

proceso de desarrollo.

Hay tres variantes principales de desarrollo incremental:

- Se realiza una serie de mini cascadas, donde todas las fases de la cascada se completan

para una pequeña parte de un sistema, antes de pasar al siguiente incremento, o

- Los requisitos generales se definen antes de proceder al desarrollo evolutivo de mini

cascadas de incrementos individuales de un sistema, o

- El concepto inicial de software, el análisis de requisitos y el diseño de la arquitectura y

el núcleo del sistema se definen a través del método cascada, seguido de una implementación

incremental, que culmina con la instalación de la versión final, un sistema operativo.

 22

 Desarrollo rápido de aplicaciones

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo del

software, que favorece desarrollo iterativo y la construcción rápida de prototipos en lugar de

grandes cantidades de planificación inicial. La "planificación" del software desarrollado

utilizando RAD se intercala con la escritura del propio software. La falta de una planificación

previa extensa generalmente permite que el software se escriba mucho más rápido, y hace que

sea más fácil cambiar los requisitos. El proceso de rápido desarrollo comienza con el desarrollo

de modelos de datos preliminares y modelos de procesos de negocios utilizan técnicas

estructuradas. En la siguiente etapa, los requisitos se verifican mediante el prototipado para

eventualmente refinar los modelos de datos y procesos. Estas etapas se repiten iterativamente; un

mayor desarrollo da como resultado "una declaración de requisitos técnicos y diseño técnico

combinados que se utilizará para construir nuevos sistemas".

El término se utilizó por primera vez para describir un proceso de desarrollo de software

introducido por James Martin en 1991. Según Whitten (2003), es una fusión de varias técnicas

estructuradas, especialmente ingeniería de tecnología de la información basada en datos, con

técnicas de creación de prototipos para acelerar el desarrollo de sistemas de software. Los

principios básicos del desarrollo rápido de aplicaciones son:

 23
- El objetivo clave es el rápido desarrollo y la entrega de un sistema de alta calidad a un

costo de inversión relativamente bajo.

- Intenta reducir el riesgo inherente del proyecto dividiendo un proyecto en segmentos

más pequeños y proporcionando más facilidad de cambio durante el proceso de desarrollo.

- Tiene como objetivo producir sistemas de alta calidad rápidamente, principalmente a

través de prototipos iterativos (en cualquier etapa de desarrollo), participación activa del usuario

y herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de

Interfaces Gráficas de Usuario (GUI), herramientas de Ingeniería de Software Asistida por

Ordenador (CASO), Sistemas de Administración de Bases de Datos (SGBD), lenguajes de

programación de cuarta generación, generadores de código y técnicas orientadas a objetos.

- El control del proyecto implica priorizar el desarrollo y definir plazos de entrega o "cajas de

tiempo". Si el proyecto comienza a decaer, hay que hacer énfasis en reducir los requisitos para

adaptarse a la caja de tiempo, no en aumentar el plazo.

- Control de proyecto implica priorizar desarrollo y definiendo fechas límite de entrega o

“timeboxes”. Si los inicios de proyecto para resbalar, el énfasis encima está reduciendo

requisitos para caber el timebox, no en crecientes la fecha límite.

 24
- Generalmente incluye el diseño de aplicaciones conjuntas (JAD), donde los usuarios participan

intensamente en el diseño del sistema, a través de construir ya sea en talleres estructurados, o en

una interacción facilitada electrónicamente.

- La participación activa del usuario es imprescindible.

- Produce iterativamente software de producción, a diferencia de un prototipo desechable.

- Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.

- Los métodos estándar de análisis y diseño de sistemas pueden incluirse en este marco.

I.4.

METODOLOGÍAS PARA EL DESARROLLO DE SOFTWARE:

Un proceso de software detallado y completo suele denominarse "Metodología". Las

metodologías se basan en una combinación de los modelos de proceso genéricos (cascada,

evolutivo, incremental, etc.). Adicionalmente una metodología debería definir con precisión los
 25
artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías

de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc.

Habitualmente se utiliza el término "método" para referirse a técnicas, notaciones y guías

asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por

ejemplo, suele hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la

diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance

de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para

especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las

metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos.

Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis

en la planificación y control del proyecto, en especificación precisa de requisitos y modelado,

reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada

Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles,

están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a

equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al

trabajo en equipo e involucran activamente al cliente en el proceso.

I.4.1. METODOLOGÍA XP (Programación Extrema)

De todas las metodologías ágiles, ésta es la que ha recibido más atención. Esto se debe en

parte a la notable habilidad de los líderes XP, en particular Kent Beck, para llamar la atención.
 26
También se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento, y

tomar un papel principal en él. De algunas maneras, sin embargo, la popularidad de XP se ha

vuelto un problema, pues ha acaparado la atención fuera de las otras metodologías y sus valiosas

ideas. La XP empieza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y

Coraje. Construye sobre ellos una docena de prácticas que los proyectos XP deben seguir.

Muchas de estas prácticas son técnicas antiguas, tratadas y probadas, aunque a menudo

olvidadas por muchos, incluyendo la mayoría de los procesos planeados. Además de resucitar

estas técnicas, la XP las teje en un todo sinérgico dónde cada una refuerza a las demás. Una de

las más llamativas, así como inicialmente atractiva para mí, es su fuerte énfasis en las pruebas.

Mientras todos los procesos mencionan la comprobación, la mayoría lo hace con muy poco

énfasis. Sin embargo la XP pone la comprobación como el fundamento del desarrollo, con cada

programador escribiendo pruebas cuando escriben su código de producción.

Las pruebas se integran en el proceso de integración continua y construcción lo que rinde

una plataforma altamente estable para el desarrollo futuro. En esta plataforma XP construye un

proceso de diseño evolutivo que se basa en refacturar un sistema simple en cada iteración. Todo

el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades

futuras. El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina

con la adaptabilidad de una manera que indiscutiblemente la hace la más desarrollada entre todas

las metodologías adaptables.

I.4.2. METODOLOGÍA SCRUM

 27
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo

principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en

construir primero la funcionalidad de mayor valor para el cliente y en los principios de

inspección continua, adaptación, auto-gestión e innovación. Con Scrum el cliente se entusiasma

y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo, le

permite en cualquier momento realinear el software con los objetivos de negocio de su empresa,

ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración.

Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que

forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para

desarrollar sus capacidades.

Beneficios

- Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor

que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el

Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product

Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al

equipo. Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos

generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada

para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.

- Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades

más importantes del proyecto antes de que esté finalizado por completo.
 28
- Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una

versión funcional después de cada iteración, ayuda a la obtención de un software de calidad

superior.

- Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la

burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para

organizarse.

- Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las

prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de

inversión.

- Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del

equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar

fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el

Backlog.

- Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en

primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar

riesgos eficazmente de manera anticipada.

I.4.3. METODOLOGÍA RUP

 29
El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de la

Rational como el proceso complementario al UML. El RUP es un armazón de proceso y como

tal puede acomodar una gran variedad de procesos. De hecho, ésta es mi crítica principal al RUP

- como puede ser cualquier cosa acaba siendo nada. Yo prefiero un proceso que dice qué hacer

en lugar de dar opciones infinitas. Como resultado de esta mentalidad de armazón de procesos, el

RUP puede usarse en un estilo muy tradicional de cascada o de una manera ágil. Como resultado

usted puede usar el RUP como un proceso ágil, o como un proceso pesado - todo depende de

cómo lo adapte a su ambiente. Craig Larman es un fuerte defensor de usar el RUP de una manera

ágil. Su excelente libro introductorio sobre desarrollo OO contiene un proceso que está muy

basado en su pensamiento ligero del RUP. Su visión es que mucho del reciente empujón hacia

los métodos ágiles no es nada más que aceptar desarrollo OO de la corriente principal que ha

sido capturada como RUP.

Una de las cosas que hace Craig es pasarse los primeros dos o tres días de una iteración

mensual con todo el equipo usando el UML para perfilar el diseño del trabajo a hacerse durante

la iteración. Esto no es un cianotipo del que no se pueda desviarse, sino un boceto que da una

perspectiva sobre cómo pueden hacerse las cosas en la iteración. Otra tachuela en el RUP ágil es

el proceso dX de Robert Martin. El proceso dx es una versión totalmente dócil del RUP que

simplemente es idéntico a la XP (voltear dX al revés para ver la broma). El dX está diseñado

para gente que tiene que usar el RUP, pero quiere usar XP. Como tal es a la vez XP y RUP y por

tanto un buen ejemplo del uso ágil del RUP. El proceso de ciclo de vida de RUP se divide en

cuatro fases bien conocidas llamadas Incepción, Elaboración, Construcción y Transición. Esas

fases se dividen en iteraciones, cada una de las cuales produce una pieza de software
 30
demostrable. La duración de cada iteración puede extenderse desde dos semanas hasta seis

meses.

Las fases son:

1. Incepción.- Significa "comienzo", pero la palabra original (de origen latino y casi en

desuso como sustantivo) es sugestiva y por ello la traducimos así. Se especifican los objetivos

del ciclo de vida del proyecto y las necesidades de cada participante. Esto entraña establecer el

alcance y las condiciones de límite y los criterios de aceptabilidad. Se identifican los casos de

uso que orientarán la funcionalidad. Se diseñan las arquitecturas candidatas y se estima la agenda

y el presupuesto de todo el proyecto, en particular para la siguiente fase de elaboración.

Típicamente es una fase breve que puede durar unos pocos días o unas pocas semanas.

2. Elaboración.- Se analiza el dominio del problema y se define el plan del proyecto. RUP

presupone que la fase de elaboración brinda una arquitectura suficientemente sólida junto con

requerimientos y planes bastante estables. Se describen en detalle la infraestructura y el ambiente

de desarrollo, así como el soporte de herramientas de automatización. Al cabo de esta fase, debe

estar identificada la mayoría de los casos de uso y los actores, debe quedar descripta la

arquitectura de software y se debe crear un prototipo de ella. Al final de la fase se realiza un

análisis para determinar los riesgos y se evalúan los gastos hechos contra los originalmente

planeados.
 31
3. Construcción. - Se desarrollan, integran y verifican todos los componentes y rasgos de

la aplicación. RUP considera que esta fase es un proceso de manufactura, en el que se debe poner

énfasis en la administración de los recursos y el control de costos, agenda y calidad. Los

resultados de esta fase (las versiones alfa, beta y otras versiones de prueba) se crean tan rápido

como sea posible. Se debe compilar también una versión de entrega. Es la fase más prolongada

de todas.

4. Transición. - Comienza cuando el producto está suficientemente maduro para ser

entregado. Se corrigen los últimos errores y se agregan los rasgos pospuestos. La fase consiste en

prueba beta, piloto, entrenamiento a usuarios y despacho del producto a mercadeo, distribución y

ventas. Se produce también la documentación. Se llama transición porque se transfiere a las

manos del usuario, pasando del entorno de desarrollo al de producción.

A través de las fases se desarrollan en paralelo nueve flujos de trabajo o disciplinas:

Modelado de Negocios, Requerimientos, Análisis y Diseño, Implementación, Prueba, Gestión de

Configuración y Cambio, Gestión del Proyecto y Entorno. Además de estos flujos de trabajo,

RUP define algunas prácticas comunes:

- Desarrollo iterativo de software. Las iteraciones deben ser breves y proceder por

incrementos pequeños. Esto permite identificar riesgos y problemas tempranamente y reaccionar

frente a ellos en consecuencia.

 32
- Administración de requerimientos. Identifica requerimientos cambiantes y postula una

estrategia disciplinada para administrarlos.

- Uso de arquitecturas basadas en componentes. La reutilización de componentes permite

asimismo ahorros sustanciales en tiempo, recursos y esfuerzo.

- Modelado visual del software. Se deben construir modelos visuales, porque los sistemas

complejos no podrían comprenderse de otra manera. Utilizando una herramienta como UML, la

arquitectura y el diseño se pueden especificar sin ambigüedad y comunicar a todas las partes

involucradas.

- Prueba de calidad del software. RUP pone bastante énfasis en la calidad del producto

entregado.

- Control de cambios y trazabilidad. La madurez del software se puede medir por la

frecuencia y tipos de cambios realizados.

Aunque RUP es extremadamente locuaz en muchos respectos, no proporciona

lineamientos claros de implementación que puedan compararse, por ejemplo, a los métodos

Crystal, en los que se detalla la documentación requerida y los roles según diversas escalas de

proyecto. En RUP esas importantes decisiones de dejan a criterio del usuario. Se asegura que

RUP puede implementarse "sacándolo de la caja", pero dado que el número de sus artefactos y

herramientas es inmenso, siempre se dice que hay que recortarlo y adaptarlo a cada caso. El
 33
proceso de implementación mismo es complejo, dividiéndose en seis fases cíclicas también

existe una versión recortada de RUP, dX de Robert MartinIV.

PRINCIPALES ROLES:

Un Rol se define como una “Función que alguien o algo cumple” (Abstracta Academy, 2016).

Cada uno de los roles aportará al grupo parte del total necesario para tener éxito en el desarrollo.

Los roles son necesarios para cubrir todas las especificaciones necesarias para cumplir un

proceso ya que no todos tenemos las mismas cualidades y experiencias. Además, al asignar roles,

se definen objetivos y actividades para cada uno; lo anterior evitando que alguna actividad no sea

asignada o que dos personas realicen el mismo trabajo.

Descripción de roles en el Proceso de Desarrollo de Software

El software se construye en equipo y hay muchas metodologías diferentes. Los roles se

asignan de acuerdo a las capacidades de cada persona, así como también su especialización,

experiencia e interés. Los roles más comunes son:

Gerente de proyecto

Tiene por función presentar informes sobre las litigaciones de riesgos, hacer cumplir los

plazos y lleva el control de los costos. También organiza el equipo, realiza planificación y estima

el tiempo de las actividades. En conclusión, resuelve problemas.

 34
Analista de requerimientos

Se encarga del revelamiento de los requerimientos esenciales para el desarrollo del Software, la

documentación de los requerimientos para así el resto del equipo lo pueda consultar en cualquier

momento. Debe ser una persona con capacidad de abstracción y análisis.

Desarrollador de software o programador

Encargado de la concepción y el diseño, escribe el código, prueba lo que construye y se encarga

de hacer el mantenimiento del código.

Testador

Diseña y ejecuta las pruebas, para ello requiere conocer el producto a probar claro esta, estudiar

funcionalidad del producto y desarrollar las pruebas que revelen incidentes críticos. Reporta los

incidentes y provee información sobre la calidad del sistema.

Arquitecto de software

Determina las estructuras de la aplicación y las tecnologías con las que se construirá la

aplicación. Está encargado del aseguramiento de la calidad, mejorar continuamente la

arquitectura. Gestiona los requerimientos no funcionales, asume la dirección técnica para

asegurar que todos los aspectos de la arquitectura se estén desarrollando de manera correcta.

Debe ser una persona con un innato sentido de liderazgo, dispuesto a formar a los integrantes del

equipo, dispuesto a recibir y aplicar abiertamente recomendaciones.

 35
II. MODELOS DEL PROCESO DE DESARROLLO DE SOFTWARE:

No existe consenso sobre cuál es el mejor modelo del proceso software. Distintos equipos

de desarrollo pueden utilizar diferentes modelos de proceso software para producir el mismo tipo

de sistema software. Sin embargo, algunos modelos son más apropiados para producir ciertos

tipos de sistemas, de forma que si no se utiliza un modelo adecuado puede ocurrir que el sistema

software resultante sea de menor calidad.

El reparto de costes entre las distintas fases del proceso de desarrollo es difícil de

determinar dado los distintos modelos de proceso existentes. Sin embargo, en dependencia del

modelo que se adopte, al menos el 60% del coste total se emplea en la actividad de evolución del

sistema. La estimación de este porcentaje es pesimista, ya que la tasa de crecimiento de nuevos

productos software es mucho mayor que la tasa de productos software que quedan en desuso (no

tienen que ser mantenidos), por lo que el número de operaciones de mantenimiento que se

realizan sigue aumentando. El proceso de diseño software debería, por tanto, tener en cuenta la

posterior evolución del sistema. Las características deseables de un proceso de desarrollo

software son:

- Claridad: El proceso de desarrollo es claro cuando se entiende con facilidad.

- Visibilidad: Un proceso de desarrollo es visible cuando sus actividades producen

resultados claros identificables externamente.

 36
- Facilidad de soporte: Exige disponer de herramientas CASE (Computer-Aided Software

Engineering) que den soporte a todas o alguna de las actividades del proceso de desarrollo.

- Fiabilidad: Un proceso de desarrollo es fiable cuando es capaz de detectar posibles errores.

- Facilidad de mantenimiento: Requiere capacidad para incorporar nuevos requisitos o modificar

alguno o algunos de los existentes.

- Rapidez: Un proceso software es rápido cuando se puede obtener, a partir de la especificación,

una implementación del sistema en un tiempo reducido.

II.1.MODELO EN CASCADA O CONVENCIONAL

El modelo en cascada es un enfoque de desarrollo secuencial, en el que se considera que

el desarrollo fluye constantemente hacia abajo (como una cascada) a través de varias fases,

típicamente: Análisis de requisitos que resulta en una especificación de requisitos de software,

Diseño del software, Implementación, Testeo, Integración, si hay múltiples subsistemas,

Despliegue (o Instalación) y el Mantenimiento. La primera descripción formal del método se cita

a menudo como un artículo publicado por Winston W. Royce en 1970, aunque Royce no usó el

término "cascada" en este artículo. Royce presentó este modelo como un ejemplo de un modelo

defectuoso, que no funciona. Los principios básicos son:

- El proyecto se divide en fases secuenciales, con algunas superposiciones y salpicaduras

aceptables entre fases.

 37
- El énfasis está en la planificación, los horarios, las fechas objetivo, los presupuestos y la

implementación de todo un sistema a la vez.

- Se mantiene un estricto control a lo largo de la vida del proyecto a través de una extensa

documentación escrita, revisiones formales y aprobación por parte del usuario, y la

administración de la tecnología de la información que se realiza al final de la mayoría de las

fases antes de comenzar la siguiente fase. La documentación escrita es un entregable explícito de

cada fase.

El modelo de cascada es un enfoque de ingeniería tradicional aplicado a la ingeniería de

software, es el primer modelo de desarrollo software propuesto. Es ampliamente usado en la

industria por su facilidad de gestión y visibilidad. Sin embargo, su principal problema reside en

su poca flexibilidad al separar el proceso de desarrollo en etapas totalmente distintas. En la

práctica estas etapas no tienen fronteras tan bien definidas, lo que hace que, en no pocas

ocasiones, se solapen y compartan información. Los principales problemas de este modelo son:

dificultad para realizar prototipos, reutilizar software y realizar pruebas sin disponer de una

implementación del sistema. Un enfoque de cascada estricto desalienta la revisión de cualquier

fase previa una vez que esté completa.

Esta "inflexibilidad" en un modelo de cascada pura ha sido una fuente de críticas por parte de los

partidarios de otros modelos más "flexibles". Se le ha culpado ampliamente a varios proyectos

gubernamentales a gran escala que superan el presupuesto, a lo largo del tiempo y en ocasiones

no cumplen con los requisitos debido al enfoque de Big Design Up Front . Excepto cuando se

requiere por contrato, el modelo de cascada ha sido ampliamente reemplazado por metodologías

más flexibles y versátiles desarrolladas específicamente para el desarrollo de software.

 38
II.2.MODELOS DE PROCESO INCREMENTAL

El enfoque incremental de desarrollo se ve como una forma de reducir la repetición del

trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los

requisitos hasta adquirir experiencia con el sistema. Es una combinación del Modelo de Cascada

y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad

para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada

incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento

que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar

por cascada, si es dudoso, evolutivo. Hay muchas situaciones en las que los requerimientos

iniciales del software están razonablemente bien definidos, pero el alcance general del esfuerzo

de desarrollo imposibilita un proceso lineal. Además, tal vez haya una necesidad imperiosa de

dar rápidamente cierta funcionalidad limitada de software a los usuarios y aumentarla en las

entregas posteriores de software. En tales casos, se elige un modelo de proceso diseñado para

producir el software en incrementos.

Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el

producto fundamental. Es decir, se abordan los requerimientos básicos, pero no se proporcionan

muchas características suplementarias (algunas conocidas y otras no). El cliente usa el producto

fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación, se

desarrolla un plan para el incremento que sigue. El plan incluye la modificación del producto

fundamental para cumplir mejor las necesidades del cliente, así como la entrega de
 39
características adicionales y más funcionalidad. Este proceso se repite después de entregar cada

incremento, hasta terminar el producto final

II.3.MODELO EVOLUTIVO

Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten

desarrollar versiones cada vez más completas del software. El software, como todos los sistemas

complejos, evoluciona en el tiempo. Es frecuente que los requerimientos del negocio y del

producto cambien conforme avanza el desarrollo, lo que hace que no sea realista trazar una

trayectoria rectilínea hacia el producto final; los plazos apretados del mercado hacen que sea

imposible la terminación de un software perfecto, pero debe lanzarse una versión limitada a fin

de aliviar la presión de la competencia o del negocio; se comprende bien el conjunto de

requerimientos o el producto básico, pero los detalles del producto o extensiones del sistema aún

están por definirse.

En estas situaciones y otras parecidas se necesita un modelo de proceso diseñado

explícitamente para adaptarse a un producto que evoluciona con el tiempo. En este modelo se

entrelazan las actividades de especificación, desarrollo y validación. Inicialmente, se desarrolla

rápidamente un sistema inicial a partir de una especificación muy abstracta. El sistema se va

refinando con la información que van suministrando los clientes y/o usuarios hasta que se

obtiene un sistema final que satisfaga todas las necesidades previstas. El sistema final obtenido

puede rediseñarse para producir otro más robusto y más fácil de mantener.
 40
Existen dos tipos de procesos de desarrollo evolutivos:

- 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 más claras. El

sistema evoluciona conforme se añaden nuevas características propuestas por el usuario. Es

decir, se debe trabajar con el cliente para identificar y construir el sistema final a partir de una

especificación informal. El resultado del proceso es el sistema final.

- Prototipado desechable: 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 están claros para el usuario y se utiliza un prototipo para

experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. El resultado del

proceso es la especificación del sistema (el prototipo se deshecha).

Los principales problemas de este modelo son: escasa visibilidad; los continuos cambios

que hacen que los sistemas desarrollados estén deficientemente estructurados; y la necesidad de

disponer, en muchos casos, de un equipo de desarrollo altamente calificado. Estos problemas

hacen que la aplicación de este modelo se suela limitar a sistemas interactivos de tamaño

pequeño o mediano. La deficiente estructura dificulta las tareas de mantenimiento de ahí que se

suela aplicar a sistemas con una vida corta y a partes de grandes sistemas, especialmente a

sistemas de inteligencia artificial y a interfaces de usuario.

II.4.MODELO TRANSFORMACIONAL
 41
Se basa en disponer de una especificación formal del sistema y en transformar, con

métodos matemáticos, esta especificación en una implementación. Si las transformaciones que se

aplican son correctas es posible asegurar que el sistema construido satisface la especificación, es

decir, es posible obtener programas correctos por construcción.

Otra de sus ventajas es la posibilidad de realizar el mantenimiento a nivel de

especificación. Por lo que es necesario disponer de una especificación inicial correcta y de

diseñadores altamente calificados. Además, no existe apenas experiencia en la aplicación de este

modelo a grandes proyectos.

Modelo basado en reutilización: En este modelo se supone que alguno de los

componentes del sistema final ya existe. El proceso de desarrollo se centra en integrar las partes

ya existentes más que en construir todo el sistema desde el principio. Las ventajas que desde un

punto de vista económico puede producir este modelo actualmente empiezan a ser estudiadas en

profundidad. Prácticamente no existe experiencia sobre el empleo de este modelo, si bien, se

están haciendo numerosos estudios e investigaciones para posibilitar su uso.

II.5.MODELO EN ESPIRAL

En 1988, Barry Boehm publicó un "modelo espiral" de desarrollo de software formal, que

combina algunos aspectos clave del metodologías de creación rápida de prototipos, modelo de

cascada y las metodologías de creación rápida de prototipos, en un esfuerzo por combinar las
 42
ventajas de los conceptos de arriba había abajo y de abajo hacia arriba. Se incluye el análisis de

riesgo como una parte importante del proceso de desarrollo software.

Proporcionó énfasis en un área clave que muchos consideraron que había sido descuidada

por otras metodologías: análisis del riesgo iterativo deliberado, particularmente adecuado para

sistemas complejos a gran escala. El modelo tiene la forma de una espiral en la que cada vuelta

representa cada una de las fases en las que se estructura el proceso software y está organizada en

cuatro sectores:

1. Definición de objetivos, alternativas y restricciones de cada fase del proyecto.

2. Evaluación de alternativas y análisis de riesgos.

3. Desarrollo y validación. Se elige el modelo de proceso de desarrollo que se considere

más adecuado.

4. Planificación de las siguientes fases del proyecto.

Modelo Espiral Durante la primera vuelta alrededor de la espiral se definen los objetivos,

las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo

indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el

cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente. El

cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere

modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de

planificación y de análisis de riesgo.

 43
En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una

decisión de "seguir o no seguir". Con cada iteración alrededor de la espiral (comenzando en el

centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez

más completa y, al final, al propio sistema operacional. El paradigma del modelo en espiral para

la ingeniería de software es actualmente el enfoque más realista para el desarrollo de software y

de sistemas a gran escala.

Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador

y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de

prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a

quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la

evolución de prototipos.

Los principios básicos son:

- Se centra la atención en la evaluación de riesgos y en minimizar el riesgo del proyecto

al dividir un proyecto en segmentos más pequeños y brindar mayor facilidad de cambio durante

el proceso de desarrollo, así como brindar la oportunidad de evaluar los riesgos y evaluar la

continuación del proyecto a lo largo del ciclo de vida.

- "Cada ciclo implica una progresión a través de la misma secuencia de pasos, para cada

parte del producto y para cada uno de sus niveles de elaboración, desde un documento de

concepto de operación general hasta la codificación de cada programa individual".

 44
- Cada viaje alrededor de la espiral pasa por cuatro cuadrantes básicos: determinar

objetivos, alternativas, y limitaciones de la iteración; evaluar alternativas; Identificar y resolver

riesgos; desarrollar y verificar entregables de la iteración; y planear la iteración próxima.

- Empieza cada ciclo con una identificación de las partes interesadas y sus "condiciones

de victoria", y finaliza cada ciclo con una revisión y compromiso.

 45
• MODELO EN CASCADA

Este es el modelo en el cual se ordenan rigurosamente las etapas del desarrollo del

software, de esto se obtiene que el inicio de una etapa de desarrollo deba de esperar el fin de la

etapa anterior. De esto se obtiene que cualquier error detectado lleve al rediseño del área de

código afectado, lo cual aumenta de costo el desarrollo del proyecto.

II.6.• MODELO DE PROTOTIPOS

Pertenece a los modelos evolutivos, en el cual el prototipo debe de ser construido

rápidamente y con la utilización escasa de recursos. El prototipo es construido para mostrárselo

al cliente, obtener críticas y retroalimentación, con lo cual se obtendrán los requisitos específicos

para la aplicación a partir de las metas graficas que son mostradas. Las etapas de este modelo

son:

1. Plan rápido

2. Modelo

3. Construcción del prototipo

4. Entrega y retroalimentación

5. Comunicación

6. Entrega del desarrollo final

Entre sus ventajas se encuentra que, es apto para el cliente que conoce a grandes rasgos el
 46
objetivo del software y a su vez, al equipo de desarrollo le ofrece una mejor visibilidad de

la interacción del cliente con el software y el ambiente en el cual debe de realizarse.

II.7. DESARROLLO POR ETAPAS

Es similar al modelo por etapas, sin embargo, se diferencia en que, al momento de la

crítica o bien retro alimentación por parte del usuario final, no se obtendrán completamente las

características del software. Estas se irán descubriendo en el proceso del avance del software,

mediante la creación de las diferentes versiones del código. En este modelo, se distinguen las

siguientes fases:

1. Especificación conceptual

2. Análisis de requisitos

3. Diseño inicial

4. Codificación y depuración.

• DESARROLLO ITERATIVO Y CRECIENTE

Resuelve los problemas encontrados en el modelo en cascada, en cual ofrece entornos de

trabajo con técnicas para su correcta utilización. Este tipo de modelo es esencial para el método

de programación extrema. Este tipo de programación consiste en la realización de programas de

manera incremental, la cual sirve para obtener ventaja de lo que se ha realizado a lo largo del

proyecto. En este se entran a varias iteraciones con las cuales se obtendrá el software final y a su
 47
vez, se le agregaran nuevas funcionalidades a cada etapa. Se puede dividir en los siguientes

procesos:

1. Etapa de inicialización

La meta de esta etapa es la construcción de un producto en el cual se pueda obtener

retroalimentación de parte del usuario final.

2. Etapa de iteración

Consiste en el análisis, rediseño e implementación del producto de las iteraciones

anteriores.

3. Lista de control del proyecto.

Son las tareas que se crean que describen las partes que conforman el proyecto, son

implementadas y rediseñadas en cada etapa de iteración del producto.

• RAD o desarrollo de aplicaciones rápidas

Como su nombre lo indica permite la construcción rápida de sistemas utilizables. Está

compuesto por un grupo reducido de personas incluyendo desarrolladores y testes del sistema.

También se debe de hacer énfasis al desarrollo de la aplicación cumpliendo correctamente las

funcionalidades principales, dejando a un lado a las implementaciones secundarias. Este modelo

toma principalmente en cuenta las características de usabilidad, utilidad y rapidez de la ejecución

de la aplicación.
 48
• Desarrollo concurrente

Se conoce como ingeniería concurrente y es utilizado en su mayoría para aplicaciones

cliente servidor, en el cual se describen los múltiples procesos que ocurren simultáneamente en

la aplicación. Una de las características de este proceso es que está orientado a las necesidades

del usuario, las decisiones de la gestión y los resultados de las revisiones. Las ventajas que se

pueden mencionar es que está orientado a grupos de trabajo independientes, proporcionando una

visión exacta de lo que se lleva desarrollado del proyecto. Las desventajas se tienen que se

necesitan de grupos de trabajo y de las condiciones necesarias para su implementación.

• Proceso unificado

Este proceso se distingue por la utilización de casos de uso, el cual está centrado en la

arquitectura y la utilización de iteraciones incrementales. Este es un marco de trabajo extensible,

el cual puede ser implementado hacia otros proyectos de distintas organizaciones. Este proceso

es utilizado para evitar problemas legales con el método RUB dado que este otro método es una

marca registrada de IBM.En cada iteración, se busca el avance e iteración en determinadas áreas,

con la cual se obtendrán resultados en los cuales se puede constatar el tiempo que se ha dedicado

a las distintas áreas en el desarrollo de software. Sus principales características son: es iterativo e

incremental, dirigido por casos de uso, centrado en la arquitectura y enfocado en los riesgos.

• RUP o proceso unificado relacional

 49
Es propiedad de IBM desarrollado por la empresa Rational Software, es conocido como

RUP y llamado Proceso Unificado Rational, por el nombre de la empresa. Es uno de los modelos

más utilizado en el análisis, diseño e implementación de la documentación de sistemas

orientados a objetos. Los principios básicos de este método son: adaptar el proceso, equilibrar

prioridades, demostrar valor iterativamente, colaboración entre equipos, elevar el nivel de

abstracción y enfocarse a la calidad.

 
 50

III. LENGUAJE UNIFICADO DE MODELADO (UML)

El “Lenguaje de Modelado Unificado” – del inglés Unified Modeling Language (UML) –

es un lenguaje basado en diagramas para la especificación, visualización, construcción y

documentación de cualquier sistema complejo, sobre todo en el caso específico de sistemas

software.

UML es independiente de las metodologías de análisis y diseño y de los lenguajes de

programación que se utilicen en la construcción de los sistemas software, es importante destacar

que se basa en el paradigma de la orientación a objetos. Por tanto, es especialmente adecuado

cuando se ataca la construcción de sistemas software desde la perspectiva de la orientación a

objetos. La especificación, visualización, construcción y documentación de cualquier sistema

software requiere que el sistema pueda ser estudiado desde diferentes puntos de vista, ya que un

usuario final necesita una visión diferente del sistema de la que necesita un analista o un

programador. UML incorpora toda una serie de diagramas y notaciones gráficas y textuales

destinadas a mostrar el sistema desde las diferentes perspectivas, que pueden utilizarse en las

diferentes fases del ciclo de desarrollo del software.

Grady Booch, Jim Rumbaugh e Ivar Jacobson desarrollaron el UML a mediados de los

años noventa del siglo pasado con mucha realimentación de la comunidad de desarrollo de

software. El UML fusionó algunas notaciones de modelado que competían entre sí y que se

usaban en la industria del software en la época. En 1997, UML 1.0 se envió al Object
 51
Management Group, un consorcio sin fines de lucro involucrado en especificaciones de

mantenimiento para su empleo en la industria de la computación. El UML 1.0 se revisó y dio

como resultado la adopción del UML 1.1 ese mismo año. El estándar actual es UML 2.0 y ahora

es un estándar ISO. Puesto que este estándar es tan nuevo, muchas antiguas referencias, como

[Gam95], no usan notación de UML.

Sin embargo, desde el punto de vista puramente tecnológico, UMI tiene una gran

cantidad de propiedades que han sido las que, realmente, han contribuido a hacer de UML el

estándar de facto de la industria que es en realidad. Algunas de las propiedades de UML como

lenguaje de modelado estándar son:

 Concurrencia, es un lenguaje distribuido y adecuado a las necesidades de

conectividad actuales y futuras

 Ampliamente utilizado por industria desde su adopción por OMG.

 Reemplaza a decenas de notaciones empleadas con otros lenguajes.

 Modela estructuras complejas.

 Las estructures más portantes que soportan tienen su fundamento en las

tecnologías orientadas a objetos, tales como objetos, clase, componentes y nodos.

 Emplea operaciones abstractas como guía para variaciones futuras, añadiendo

variables si es necesario.

 Comportamiento del sistema: casos de uso, diagramas de secuencia y de

colaboraciones, que sirven para evaluar el estado de las máquinas.

III.1. UNIFICADO
 52
La palabra unificado tiene los siguientes significados relevantes para UML.

A través de los métodos históricos y notaciones. UML combina conceptos comúnmente

aceptados por muchos métodos orientados a objetos, seleccionando una definición clara para

cada concepto, así como una notación y una terminología. UML puede representar la mayoría de

los modelos existentes tan bien o mejor que como lo hacían los métodos originales.

A través del ciclo de vida de desarrollo. UML no tiene saltos ni discontinuidades

desde los requisitos a la implantación. Se puede utilizar el mismo conjunto de conceptos y

notación en las diferentes etapas del desarrollo, incluso mezcladas en un solo modelo. No es

necesario traducir de una etapa a otra. Esta continuidad es crítica para un desarrollo iterativo e

incremental.

A través de los dominios de aplicación. UML está pensado para modelar la mayoría de

los dominios de aplicación, incluyendo aquellos que implican sistemas grandes, complejos, de

tiempo real, distribuidos, con tratamiento intensivo de datos o con cálculo intensivo, entre otras

propiedades. Puede haber áreas especializadas en las cuales un lenguaje especial para ese

propósito resulte más útil, pero UML pretende ser tan bueno o mejor que cualquier otro lenguaje

de modelado de propósito general para la mayoría de las áreas de aplicación.

A través de los lenguajes de implementación y plataformas. UML está pensado para

ser usado en sistemas desarrollados en varios lenguajes de implementación y plataformas,

incluyendo lenguajes de programación, bases de datos, 4GLs, documentos de organización,

 53
firmware, y otros. El trabajo de la capa superior debería ser idéntico o similar, mientras que el

trabajo de la capa inferior diferirá en algo para cada medio.

A través de procesos de desarrollo. El UML es un lenguaje, no una descripción de un

proceso de desarrollo detallado. Se pretende que sea usado como lenguaje de modelado

subyacente a la mayoría de los procesos de desarrollo existentes o de nueva creación, de la

misma forma que un lenguaje de programación de propósito general puede ser usado en varios

estilos de programación. Está especialmente pensado para apoyar un estilo de desarrollo iterativo

e incremental.

A través de los conceptos internos. En la construcción del metamodelo de UML,

hicimos un esfuerzo deliberado para descubrir y representar las relaciones subyacentes entre

varios conceptos, intentando captar conceptos de modelado de manera abierta, aplicable a

muchas situaciones conocidas y desconocidas. Este proceso permitió comprender mejor los

conceptos y hacerlos más aplicables. Este no fue el propósito original de la unificación, pero sí

uno de los resultados más importantes.

III.2. MODELADO
 54
El modelado es una parte esencial de los grandes proyectos de software y también es útil

para proyectos medianos e incluso pequeños. Un modelo juega el papel análogo en el desarrollo

de software que los planos y otros planos (mapas del sitio, elevaciones, modelos físicos) juegan

en la construcción de un rascacielos. Mediante el uso de un modelo, los responsables del éxito de

un proyecto de desarrollo de software pueden asegurarse de que la funcionalidad empresarial sea

completa y correcta, que se satisfagan las necesidades del usuario final y que el diseño del

programa respalde los requisitos de escalabilidad, solidez, seguridad, extensibilidad y otras

características.

Sus funciones específicas son:

 Captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento,

de forma que todo los implicados pueda entenderlos y estar de acuerdo con ellos.

 Pensar del diseño de un sistema.

 Capturar decisiones del diseño en una forma mutable a partir de los requisitos.

 Generar productos aprovechables para el trabajo.

 Organizar, encontrar, filtrar, recuperar, examinar y corregir la información en

grandes sistemas.

 Explotar económicamente múltiples soluciones.

 Domesticar los sistemas complejos.

Diagramas
 55

III.3. DIAGRAMAS DE CLASE

Para modelar clases, incluidos sus atributos, operaciones, relaciones y asociaciones con

otras clases,2 el UML proporciona un diagrama de clase, que aporta una visión estática o de

estructura de un sistema, sin mostrar la naturaleza dinámica de las comunicaciones entre los

objetos de las clases.

Los elementos principales de un diagrama de clase son cajas, que son los íconos

utilizados para representar clases e interfaces.

 56
Cada caja se divide en partes horizontales.

 La parte superior contiene el nombre de la clase.

 La sección media menciona sus atributos. Un atributo es algo que un objeto de

dicha clase conoce o puede proporcionar todo el tiempo. Por lo general, los

atributos se implementan como campos de la clase, pero no necesitan serlo.

Podrían ser valores que la clase puede calcular a partir de sus variables o valores

instancia y que puede obtener de otros objetos de los cuales está compuesto.

 La tercera sección del diagrama de clase contiene las operaciones o

comportamientos de la clase. Una operación es lo que pueden hacer los objetos de

la clase. Por lo general, se implementa como un método de la clase.

Los diagramas de clase también pueden mostrar relaciones entre clases. Una clase que

sea una subclase de otra clase se conecta con ella mediante una flecha con una línea sólida y con

una punta triangular hueca. La flecha apunta de la subclase a la superclase. Una asociación entre

dos clases significa que existe una relación estructural entre ellas.
 57
En relación con el nombre de la clase, es importante destacar las siguientes

recomendaciones (convenciones de nombrado):

 El nombre de una clase debería ser un sustantivo en singular y debería comenzar

con mayúsculas.

 El nombre de una clase debe de estar de acuerdo a su semántica o intención, en

otras palabras, debe ser significativo a la vez que simple. De no ser así, se

dificultará la posible reutilización posterior de esa clase.

El nombre de cada atributo debe ser también significativo, pero a diferencia de los

nombres de clase, suelen comenzar en minúscula. El tipo de cada atributo puede ser cualquier

clase o bien puede ser un tipo de datos básico. El nombre de cada atributo y su tipo quedan

separados mediante dos puntos (‘:’). Finalmente, la visibilidad de cada atributo nos indica hasta

qué punto las operaciones de otras clases pueden acceder al atributo. Tenemos tres posibilidades:

 Público: El atributo puede ser accedido desde otras clases. Para indicar en UML

que un atributo es de acceso público, es necesario anteponer al nombre del

atributo el símbolo ‘+’.

 Protegido: El atributo puede ser accedido desde las clases descendientes. Para

indicar en UML que un atributo es de acceso protegido, es necesario anteponer el

símbolo ‘#’ al nombre del atributo.

 58
 Privado: el atributo no puede ser accedido desde otras clases. Para indicar en

UML que un atributo es de acceso privado, es necesario anteponer al nombre del

atributo el símbolo ‘-’

Finalmente, en el tercer compartimento se indica el comportamiento de la clase, que

queda representado mediante una lista de operaciones. Para cada operación es necesario

especificar su signatura, que tiene la siguiente sintaxis: visibilidad nombreMetodo (Parámetro,

Parámetro, ...)[: tipo de retorno]

Tal y como figura en la especificación de la signatura, hay que indicar la visibilidad de

las operaciones de la clase, anteponiendo los símbolos ‘+’ (operación pública), ‘#’ (operación

protegida) o ‘-‘ (operación privada) al nombre de la operación. La semántica de estos símbolos

es idéntica a la de los atributos. Los parámetros (se pueden especificar cero, uno o más) responde

a la sintaxis:

{[dirección] nombre: tipo [=valor por defecto]}

donde la dirección puede tomar uno de estos valores:

 in, para especificar que se trata de un parámetro de entrada que no se puede

modificar.

 out, para especificar los parámetros de salida, que pueden modificarse para

comunicar información al invocador.

 59
 inout, que especifica un parámetro de entrada que puede modificarse

III.4. DIAGR

A MAS DE

IMPLEMENTACIÓN

Un diagrama de implementación UML se enfoca en la estructura de un sistema de

software y es útil para mostrar la distribución física de un sistema de software entre plataformas

de hardware y entornos de ejecución.

Los diagramas de implementación también pueden mostrar nodos de entorno de

ejecución, que se dibujan como cajas que contienen la etiqueta “<>”. Dichos nodos representan

sistemas, como sistemas operativos, que pueden albergar otro software.

 60

III.5. DIAGRAMAS DE USO DE CASO

El diagrama de uso de caso UML ayudan a determinar la funcionalidad y características

del software desde la perspectiva del usuario.

Un caso de uso describe la manera en la que un usuario interactúa con el sistema, definiendo los

pasos requeridos para lograr una meta. Un diagrama UML de uso de caso es un panorama de

todos los casos de uso y sus relaciones. El mismo proporciona un gran cuadro de la

funcionalidad del sistema. En el diagrama de uso de caso, los casos de uso se muestran como

óvalos. Los actores se conectan mediante líneas a los casos de uso que realizan.

III.6. DIAGRAMAS DE SECUENCIA

Un diagrama de secuencia se usa para mostrar las comunicaciones dinámicas entre

objetos durante la ejecución de una tarea. Este tipo de diagrama muestra el orden temporal en el

que los mensajes se envían entre los objetos para lograr dicha tarea. Puede usarse un diagrama de

secuencia para mostrar las interacciones en un caso de uso o en un escenario de un sistema de

software.
 61
Existen muchas características especiales que pueden incluirse en un diagrama de

secuencia. Por ejemplo:

Se puede distinguir entre mensajes sincrónicos y asíncronos. Los primeros se muestran con

puntas de flecha sólidas mientras que los asíncronos lo hacen con puntas de flecha huecas.

Se puede mostrar un objeto que envía él mismo un mensaje con una flecha que parte del objeto,

gira hacia abajo y luego apunta de vuelta hacia el mismo objeto. Se puede mostrar la creación de

objeto dibujando una flecha etiquetada de manera adecuada (por ejemplo, con una etiqueta <>)

hacia una caja de objeto. En este caso, la caja aparecerá en el diagrama más abajo que las cajas

correspondientes a objetos que ya existen cuando comienza la acción.

Se puede mostrar destrucción de objeto mediante una gran X al final de la línea de vida

del objeto. Otros objetos pueden destruir un objeto, en cuyo caso una flecha apunta desde el otro

objeto hacia la X. Una X también es útil para indicar que un objeto ya no se usa y que, por tanto,

está listo para la colección de basura.

 62

III.7. DIAGRAMAS DE COMUNICACIÓN

El diagrama de comunicación UML (llamado “diagrama de colaboración” en UML 1.X)

proporciona otro indicio del orden temporal de las comunicaciones, pero enfatiza las relaciones

entre los objetos y clases en lugar del orden temporal.

En un diagrama de comunicación, los objetos interactuantes se representan mediante

rectángulos. Las asociaciones entre objetos lo hacen mediante líneas que conectan los

rectángulos. Por lo general, en el diagrama existe una flecha entrante hacia un objeto que

comienza la secuencia de pase de mensaje. Esa flecha se etiqueta con un número y un nombre de

mensaje. Si el mensaje entrante se etiqueta con el número 1 y si hace que el objeto receptor

invoque otros mensajes en otros objetos, entonces los mencionados mensajes se representan

mediante flechas desde el emisor hacia el receptor a lo largo de una línea de asociación y reciben

números 1.1, 1.2, etc., en el orden en el que se llaman. Si tales mensajes a su vez invocan otros

mensajes, se agrega otro punto decimal y otro número al número que etiqueta dichos mensajes

para indicar un anidado posterior del pase de mensaje.

III.8. DIAGRAMAS DE ACTIVIDAD

Un diagrama de actividad UML muestra el comportamiento dinámico de un sistema o de

parte de un sistema a través del flujo de control entre acciones que realiza el sistema. Es similar a
 63
un diagrama de flujo, excepto porque un diagrama de actividad puede mostrar flujos

concurrentes. El componente principal de un diagrama de actividad es un nodo acción,

representado mediante un rectángulo redondeado, que corresponde a una tarea realizada por el

sistema de software. Las flechas desde un nodo acción hasta otro indican el flujo de control; es

decir, una flecha entre dos nodos acción significa que, después de completar la primera acción,

comienza la segunda acción. Un punto negro sólido forma el nodo inicial que indica el punto de

inicio de la actividad. Un punto negro rodeado por un círculo negro es el nodo final que indica el

fin de la actividad.

Un tenedor (fork) representa la separación de actividades en dos o más actividades

concurrentes. Se dibuja como una barra negra horizontal con una flecha apuntando hacia ella y

dos o más flechas apuntando en sentido opuesto. Cada flecha continua representa un flujo de

control que puede ejecutarse de manera concurrente con los flujos correspondientes a las otras

flechas continuas. Dichas actividades concurrentes pueden realizarse en una computadora,

usando diferentes hebras o incluso diferentes computadoras.

III.9. DIAGRAMAS DE

ESTADO
 64
El comportamiento de un objeto en un punto particular en el tiempo con frecuencia

depende del estado del objeto; es decir, de los valores de sus variables en dicho momento.

Un diagrama de estado UML modela los estados de un objeto, las acciones que se

realizan dependiendo de dichos estados y las transiciones entre los estados del objeto.
 65

IV. PROCESO UNIFICADO DE DESARROLLO

IV.1. INTRODUCCIÓN

El objetivo del llamado Rational Unified Process® (RUP) de IBM, la implementación

más popular del Proceso Unificado de Desarrollo, es establecer un modelo de proceso (un marco

de trabajo, digamos) en el que desarrollar software de calidad y con rigor.

Este modelo de proceso se asienta en un conjunto subyacente de filosofías y principios

para conseguir un desarrollo de software correcto, proporciona una infraestructura de bloques de

construcción del proceso y de contenidos reutilizables, y presenta un método con un lenguaje

preciso con el que definir todas las partes del proceso.

IV.2. CARACTERÍSTICAS PRINCIPALES

Se trata de un modelo de proceso de desarrollo de software "pesado" o tradicional, con

estas características principales:

 Está dirigido por los llamados "casos de uso"

 Es centrado en la "arquitectura", como espina dorsal del software

 Es iterativo e incremental

 Algunas de las metas que se buscan al usar este modelo de proceso son:

 Adaptar el proceso a las necesidades de la organización

 66
 Mantener un equilibrio entre las distintas prioridades

 Permitir colaborar entre equipos

 Demostrar valor iterativamente (una iteración es una secuencia de actividades,

con un plan de línea base y unos criterios de evaluación, que resulta en una

entrega)

 Elevar el valor de la abstracción que se realiza al diseñar software

 Enfocarse continuamente en la calidad (algo muy habitual en las metodologías

más "pesadas" o tradicionales)

IV.3. FASES

Estas son las fases en que se divide cada uno de los ciclos de vida por los que pasa un

proyecto software:

 Concepción: El alcance de un acuerdo entre todos los interesados respecto a los

objetivos (de este ciclo) del proyecto. Los objetivos en esta fase son:

o Establecer el ámbito de software y las condiciones de los límites del

proyecto.

o Discriminar los casos de uso más importantes del sistema.

o Estimar el costo global y la planificación de todo el proyecto.

o Estimar los riesgos potenciales.

o Preparar el entorno de soporte para el proyecto.

 Elaboración: El establecimiento de una línea base para la arquitectura del sistema.

Los objetivos en esta fase son:

 67
o Garantizar que la arquitectura, los requisitos y los planes son lo bastante

estables, y que los riesgos están suficientemente mitigados.

o Tratar todos los riesgos arquitectónicamente significativos del proyecto.

o Producir un prototipo de componentes de calidad de producción.

o Establecer un entorno de soporte.

 Construcción: La finalización del desarrollo del sistema basado en la arquitectura

de línea base anterior. Los objetivos en esta fase son:

o Minimizar los costos de desarrollo optimizando los recursos y evitando las

reconstrucciones y los fragmentos innecesarios.

o Conseguir la calidad adecuada de forma rápida y práctica.

o Conseguir versiones útiles (alfa, beta y otros releases de prueba) de forma

rápida y práctica.

o Completar el análisis, diseño, desarrollo y prueba de toda la funcionalidad

necesaria.

o Desarrollar de forma iterativa e incremental un producto.

 Transición: La garantía de que el software está operativo y es de utilidad para los

usuarios. Los objetivos en esta fase son:

o Ejecutar el despliegue.

o Prueba de versión beta para validar el nuevo sistema contra las

expectativas del usuario.

o Convertir bases de datos operativas.

o Formación de usuarios y mantenedores.

 68
o Despliegue de la fuerza de marketing, distribución y ventas.

o Alcanzar la capacidad de soporte propio del usuario.

 69

IV.4. COMPONENTES Y SERVICIOS

El Proceso Unificado es un modelo basado en componentes, y también podemos decir

que tiene una configuración modular cuando el proyecto cuenta con una arquitectura orientada a

servicios (Service Oriented Architecture o SOA).

Cuando trabajamos con SOA:

 El proceso se enfoca en el Análisis y Diseño de Servicios

 Todas las actividades del RUP deben ser reestructuradas para soportar SOA

(aunque hay muchos elementos en común ya)

SOA define un conjunto de técnicas y productos de trabajo, tal como aparece en la figura

de esta sección, para definir modelos de solución de extremo a extremo.

IV.5. CASOS DE USO

Los casos de uso son una técnica, muy característica de este modelo de proceso, con la

que especificar el comportamiento del sistema.

Si vemos el software como un sistema que ofrece a su entorno una serie de servicios, un caso de

uso es una forma de expresar la manera en que un usuario o un sistema externo (llamado 'actor')

lo utiliza.
 70
Los casos de uso no describen ninguna funcionalidad interna (oculta al exterior) del

sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue

para realizar una tarea.

La técnica de caso de uso es muy útil en el desarrollo de sistemas interactivos, ya que

expresa la intención que tiene el actor al hacer uso del sistema. Como técnica de extracción de

requisitos permite que el analista se centre en las necesidades del usuario (¿qué espera éste lograr

al utilizar el sistema?), evitando que los desarrolladores dirijan la funcionalidad del nuevo

sistema basándose solamente en criterios tecnológicos. A su vez, mientras se obtienen los

requisitos, el analista se concentra en las tareas centrales del usuario, las más importantes,

describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego

la priorización de estos requisitos.

Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no

establecen completamente los requisitos funcionales ni permiten determinar los requisitos no

funcionales. Los casos de uso deben complementarse con información adicional como reglas de

negocio, requisitos no funcionales, diccionario de datos, etc. que complementa los requisitos

formales del sistema. De hecho cada caso de uso considerado 'crítico' debería tener una serie de

requisitos no funcionales que especifiquen a fondo el comportamiento asociado.

IV.6. VENTAJAS Y RECOMENDACIONES DE USO

 71
Cualquier Proceso Unificado, y concretamente RUP, proporciona un entorno de proceso

bastante configurable y basado en fuertes estándares. Este entorno de proceso permite establecer

un método personalizado para cada organización, configurándolo para satisfacer las necesidades

exclusivas de cada proyecto.

El Proceso Unificado es una recopilación de buenas prácticas de Ingeniería del Software

que se están mejorando continuamente de forma regular para reflejar los cambios que sufre la

industria. Además, pretende obtener productos de muy alta calidad, si bien sus diferentes

características como el estar formado por varias fases, con múltiples iteraciones por fase, etc.

pueden provocar que el proceso sea costoso y no sea adaptable para proyectos de pequeña escala.

Aún así, el hecho de que este modelo siga un esquema iterativo e incremental permite bastante

flexibilidad y adaptación a proyectos menores, en caso de que quisiéramos usarlo.

Este modelo de proceso está pensado para usarse desde el principio de un nuevo proyecto, y

puede seguir utilizándose en todos los ciclos de desarrollo siguientes, mucho tiempo después de

que el proyecto inicial haya terminado.

El modelo tiene en cuenta:

 Los propósitos empresariales, la visión, el ámbito y los riesgos del proyecto

 La cantidad de esfuerzo requerida para el desarrollo de software

 La estructura del ciclo vital del proyecto (número de iteraciones, duración total

del proyecto y de cada una de sus fases)

IV.7. CONCLUSIONES
 72
En resumidas cuentas, podemos decir que el Proceso Unificado es un importante marco

de referencia en Ingeniería de Software con el que definir, implementar y distribuir aplicaciones

de software.

Presenta un modelo dividido en 4 fases:

 Concepción: Sobretodo define el alcance del proyecto

 Elaboración: Especificación formal, análisis y diseño

 Construcción: Implementación

 Transición: Cierre del proyecto y paso a producción

Las ventajas de este modelo son la reducción de riesgos en el proyecto, la garantía de

calidad, y la integración entre lo que es propiamente desarrollo con mantenimiento de software

(a base de ir iterando en cada fase, combinando actividades de uno y otro tipo).

Como desventajas, podemos señalar que requiere una gran previsión sobre lo que va a

ocurrir (para poder controlarlo) y que genera abundante trabajo adicional (y costes asociados) de

documentación y comunicación, con lo que no suele resultar práctico para proyectos pequeños.
 73

Bibliografía

DanielRamos. (s.f.). Desarrollo de Software: Requisitos, Estimaciones y Análisis. 2 Edición - Daniel Ramos

Cardozzo - Google Libros.

Ecured. (s.f.). Desarrollo de software - EcuRed.

GoogleLibros. (s.f.). El Proceso de Desarrollo de Software: 2ª Edición - Raúl Noriega Martínez - Google

Libros.

Informaticos. (s.f.). Modelos del proceso del software - Monografias.com.

Libros, G. (s.f.). Introducción a la Ingeniería del software - Google Libros.

Ortizvivas. (s.f.). Etapas de desarrollo de un software | ortizvivas.com.

software, D. d. (s.f.). Proceso del desarrollo del software - Wikipedia, la enciclopedia libre.

VD, S. (s.f.). Fases del Proceso de Desarrollo del Software | Sistemas VD (wordpress.com).

vida, C. d. (s.f.). Ciclo de vida del software: todo lo que necesitas saber (intelequia.com).

wordpress. (s.f.). MODELOS DE PROCESO – INGENIERÍA DEL SOFTWARE (wordpress.com).