Metodología de Desarrollo de

Software

Versión 1.0.0

Elaborado por:
 Tabla de Contenido
1. Resumen Ejecutivo............................................................................................................... 3
2. Introducción........................................................................................................................... 3
3. Normatividad y Estándares................................................................................................... 3
4. Marco de Referencia............................................................................................................. 3
4.1. Proceso de Desarrollo de Software................................................................................3
4.1.1. Modelo de Proceso software...................................................................................6
4.1.2. Metodologías para desarrollo de software..............................................................7
4.2. NTP-ISO/IEC 12207 Tecnología de la Información. Procesos del Ciclo de Vida del
Software.................................................................................................................................... 8
4.2.1. Limitaciones del NTP-ISO/IEC 12207.....................................................................8
4.2.2. Procesos Principales del Ciclo de Vida del NTP-ISO/IEC 12207............................8
4.3. RUP (Rational Unified Process)...................................................................................10
4.3.1. Metodología de Implementación de Software basada en BPM / RUP / SOA / CDM.
10
4.3.2. Características de RUP......................................................................................... 13
4.3.3. Fases en RUP....................................................................................................... 14
4.3.4. Disciplinas............................................................................................................. 17
4.3.5. Organización y elementos RUP............................................................................19
4.3.6. Resultado obtenido al evaluar las metodologías...................................................24
5. Ciclo de Vida de Software del XXXXXXX............................................................................24
6. Procesos de la Metodología de Desarrollo de Software del XXXXXXX..............................24
7. Entregables de la Metodología de Desarrollo de Software.................................................25
8. Plantilla de Cronograma de Trabajo....................................................................................28
9. Plantillas de Entregables..................................................................................................... 28
10. Anexo “A” Plantilla de cronograma de trabajo.....................................................................29
11. Anexo “B” Plantillas de entregables de la Metodología de Desarrollo de software del
XXXXXXX.......................................................................................................................................
30
11.1. Diagnóstico Situacional............................................................................................ 30
11.2. Alcance de Alto Nivel................................................................................................ 30
11.3. Diseño Funcional (DF).............................................................................................. 30
11.4. Diseño Técnico (DT)................................................................................................. 31
11.5. Versión de Código Fuente y Objetos de Base de Datos..........................................31
11.6. Diagrama de Componentes......................................................................................32
11.7. Informe de Pruebas.................................................................................................. 32
11.8. Acta de Aprobación.................................................................................................. 32
11.9. Manual de Usuario................................................................................................... 32
11.10. Manual de Instalación y Sistema..............................................................................32
11.11. Informe de Capacitación........................................................................................... 32
11.12. Versión Final de Código Fuente y Objetos de Base de Datos..................................32
11.13. Documento de Alcance............................................................................................ 32
11.14. Informe de Cambio de Alcance................................................................................32

2
1. Resumen Ejecutivo
El propósito de este documento es convertirse en el marco metodológico único en el
XXXXXXX para el desarrollo de software con terceros o con personal de la entidad.
Debido a ello se realiza la revisión de la normativa legal y estándares existentes en la
industria del software, a través de la revisión literaria de los diversos procesos de
desarrollo de software (modelo y metodologías) y normativa peruana que ayudan a
encontrar limitaciones e identificar las actividades a seguir en ciclo de vida de
desarrollo de software.
Por esta razón el XXXXXXX, identifica que es necesario desarrollar software con una
metodología basada en RUP (Rational Unified Process) con una tendencia al
desarrollo rápido sin salir de la formalidad requerida por el XXXXXXX, empleando un
modelo incremental iterativo.

2. Introducción
Para un apropiado ciclo de desarrollo de software es necesario utilizar una
metodología basada en estándares de desarrollo de software como guía de trabajo
para ayudar alcanzar el objetivo de implementación de software con calidad y
eficiencia.
La elección de metodologías y herramientas adecuadas, constituirán en la base
fundamental para lograr el éxito del proyecto. El XXXXXXX con su experiencia en
proyectos y lecciones aprendidas en la gestión de proyectos selecciona las mejores
prácticas y metodologías disponibles con el fin de intervenir efectivamente en todas las
etapas del ciclo de vida del software, y plantea la cadena de valor de la metodología
de software, vea Figura 1.

Cadena de Valor de la Metodología de Desarrollo de Software del OSCE

Modelo de Requisitos Análisis y Diseño Implementación Pruebas Despliegue
Negocio

Figura 1. Cadena de Valor de la Metodología de Desarrollo de Software del XXXXXXX.

Fuente: Basada en RUP.

3. Normatividad y Estándares
Para la elaboración de esta metodología se ha realizado la revisión de la siguiente
normatividad:
 NTP-ISO/IEC 12207 Tecnología de la Información. Procesos del Ciclo de Vida del
Software.
 El Proceso Relacional Unificado (RUP: Rational Unified Process).
 Método de desarrollo adaptable (CDM: Custom Development Method).
 Modelo Integrado de Mejora de Capacidades (CMMI: Capability Maturity Model
Integration).
 Proceso de Administración de Modelado de Negocio (BPM: Business Process
Management).

4. Marco de Referencia

4.1. Proceso de Desarrollo de Software

Según Pressman (2003), la construcción y resultado de un software ha sido
históricamente cuestionado debido a los problemas asociados a estos, entre ellos
podemos destacar los siguientes:
 Los sistemas no responden a las expectativas de los usuarios.
 Los programas “fallan” con cierta frecuencia.
 Los costes del software son difíciles de prever y normalmente superan las
estimaciones.

3
  La modificación del software es una tarea difícil y costosa.
 El software se suele presentar fuera del plazo establecido y con menos prestaciones de
las consideradas inicialmente.
 Normalmente, es difícil cambiar de entorno hardware usando el mismo software.
 El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas,
etc.) no suele cumplirse.
Asimismo, Pressman (2003), caracteriza la Ingeniería de Software como “una
tecnología multicapa”, como se ilustra en la siguiente figura.

Figura 2. Capas de la Ingeniería de Software. Fuente: Pressman (2003).

A continuación describiremos las capas de la ingeniería de software:

 Calidad: Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe
descansar sobre un esfuerzo de la organización para alcanzar la calidad. La gestión
total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de
procesos que conduce al desarrollo de enfoques cada vez más robustos para la
ingeniería del software.
 Proceso: El fundamento de la ingeniería de software es la capa de proceso. El proceso
define un marco de trabajo para un conjunto de áreas clave, las cuales forman la base
del control de gestión de proyectos de software y establecen el contexto en el cual: se
aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos,
se asegura la calidad y el cambio se gestiona adecuadamente.
 Métodos: Los métodos de ingeniería de software indican cómo construir técnicamente
el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de
requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos
métodos dependen de un conjunto de principios básicos que gobiernan cada área de
la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.
 Herramientas: Las herramientas de ingeniería de software proporcionan un soporte
automático o semi-automático para el proceso y los métodos, a estas herramientas se
les llama herramientas CASE (Computer-Aided Software Engineering).

Una característica importante de un proceso de desarrollo de software son los

elementos involucrados, a continuación describiremos estos elementos:
 Un marco común del proceso: Se define como un pequeño número de actividades
del marco de trabajo que son aplicables a todos los proyectos de software, con
independencia del tamaño o complejidad.
 Un conjunto de tareas: Cada conjunto de tareas es una colección de tareas de
ingeniería del software, hitos de proyectos, entregas y productos de trabajo del
software, y puntos de garantía de calidad, que permiten que las actividades del marco
de trabajo se adapten a las características del proyecto de software y los requisitos
definidos por el equipo del proyecto.
 Las actividades de protección: Estas son la garantía de calidad del software, gestión
de configuración del software y medición, que abarcan el modelo del proceso de
software. Las actividades de protección son independientes de cualquier actividad del
marco de trabajo y aparecen durante todo el proceso.

4
 Figura 3. Elementos del proceso del software. Fuente: Pressman (2003).

Estos elementos del proceso del software tienen una perspectiva mayor que establece
relaciones entre los elementos que ayudan a determinar y responder “Quién” debe
hacer “Qué”, “Cuándo” y “Cómo” debe hacerlo.

Figura 4. Relación entre elementos del proceso del software. Fuente: Letelier, P.,
Proyecto Docente e Investigador, DSIC, 2003.

La perspectiva mostrada de los elementos de un proceso de desarrollo se describe a

continuación:
 “Quién”: Son las “Personas” participantes del proyecto de desarrollo de software que
desempeñan uno o más “Roles” específicos.
 “Qué”: Es un “Artefacto” producido por un Rol en una de sus Actividades. Los
“Artefactos” se especifican utilizando “Notaciones” específicas. Las “Herramientas”
apoyan la elaboración de “Artefactos” soportando ciertas “Notaciones”.
 “Cómo” y “Cuándo”: Las “Actividades” son una serie de pasos que lleva a cabo un
“Rol” durante el proceso de desarrollo. El avance del proyecto está controlado
mediante hitos que establecen un determinado estado de terminación de ciertos
“Artefactos”.

5
4.1.1. Modelo de Proceso software
Sommerville (2004), define a un Modelo de Proceso de Software como:
“Una representación simplificada de un proceso de software, representada desde una
perspectiva específica”. Por su naturaleza, los modelos son simplificados por lo tanto,
un modelo de procesos del software es una abstracción de un proceso real”.

Los modelos genéricos no son descripciones definitivas de procesos de software; sin

embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes
enfoques del desarrollo de software. Algunos modelos establecidos son los siguientes:
 Codificar y corregir.
 Modelo en cascada.
 Desarrollo evolutivo.
 Desarrollo formal de sistemas.
 Desarrollo basado en reutilización.
 Desarrollo incremental.
 Desarrollo en espiral.

No se pretende explicar cada modelo, sin embargo es importante resaltar que estos
modelos tienen ventajas y desventajas de acuerdo al contexto interno y/o externo de la
organización.

4.1.1.1. Comparación entre modelos de software

Cada proyecto de software requiere una forma particular de abordar el problema
solucionar. Las propuestas comerciales y académicas actuales promueven procesos
iterativos, donde cada iteración puede utilizarse uno u otro modelo de proceso,
considerando un conjunto de criterios (Por ejemplo: grado de definición de requisitos,
tamaño del proyecto, riesgos identificados, entre otros).
En la siguiente tabla se expone un cuadro comparativo con algunos criterios básicos
para la selección de un modelo de proceso, la medida utilizada indica el nivel de
efectividad del modelo de proceso de acuerdo al criterio. Por ejemplo, el modelo
“Cascada” responde con un nivel de efectividad “Bajo” cuando los “Requisitos” y
“Arquitectura” no están predefinidos.

Tabla 1. Comparación entre modelos de proceso de software.

Visión del
Funciona con Produce
Permite progreso por
Modelo de requisitos y software Gestión de
correcciones el Cliente y el
proceso arquitectura no altamente riesgos
sobre la marcha Jefe del
predefinidos fiable
proyecto

Codificar y
Bajo Bajo Bajo Alto Medio
corregir
Cascada Bajo Alto Bajo Bajo Bajo
Evolutivo
Medio o Alto Medio o Alto Medio Medio o Alto Medio o Alto
exploratorio
Evolutivo
Alto Medio Medio Alto Alto
prototipado
Desarrollo formal
Bajo Alto Bajo a Medio Bajo Bajo
de sistemas
Desarrollo
orientado a Medio Bajo a Alto Bajo a Medio Alto Alto
reutilización
Incremental Bajo Alto Medio Bajo Bajo

Espiral Alto Alto Alto Medio Medio

6
4.1.2. Metodologías para 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 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.
 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 tenemos:
 Metodologías Tradicionales.
 Metodologías Ágiles.

4.1.2.1. Metodologías Estructuradas

Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el
Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el
Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son
particularmente apropiadas en proyectos que utilizan para la implementación lenguajes
de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito
gubernamental: MERISE (Francia), MÉTRICA (España), SSADM (Reino Unido).
Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane &
Sarson , Ward & Mellor , Yourdon & DeMarco e Information Engineering .

4.1.2.2. Metodologías Orientadas a Objetos

Su historia va unida a la evolución de los lenguajes de programación orientada a
objeto, los más representativos a fines de los 60’s SIMULA, a fines de los 70’s
Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente
Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos
métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de
conseguir una unificación de sus métodos y notaciones, que posteriormente se
reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language
(UML), la notación OO más popular en la actualidad.
Algunos métodos OO con notaciones predecesoras de UML son OOAD (Booch),
OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational
Unified Process (RUP), OPEN, MÉTRICA (que también soporta la notación
estructurada).

4.1.2.3. Metodologías Tradicionales (No Ágiles)

Las metodologías no ágiles son aquellas que están guiadas por una fuerte
planificación durante todo el proceso de desarrollo; llamadas también metodologías

7
tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes
de la construcción del sistema.
En el caso particular de RUP, por el especial énfasis que presenta en cuanto a su
adaptación a las condiciones del proyecto (mediante su configuración previa a
aplicarse), realizando una configuración adecuada, podría considerarse Ágil.

4.1.2.4. Metodologías Ágiles

Un proceso es ágil cuando el desarrollo de software es incremental (entregas
pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores
trabajan juntos constantemente con una cercana comunicación), sencillo (el método en
sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite
realizar cambios de último momento). Entre las metodologías ágiles identificadas en:
 Extreme Programming.
 Scrum.
 Familia de Metodologías Crystal.
 Feature Driven Development.
 Proceso Unificado Rational, una configuración ágil.
 Dynamic Systems Development Method.
 Adaptive Software Development.
 Open Source Software Development.

4.2. NTP-ISO/IEC 12207 Tecnología de la Información. Procesos del Ciclo

de Vida del Software
Esta Norma Técnica Peruana (NTP) establece un marco de referencia común para los
procesos del ciclo de vida del software, con una terminología bien definida a la que
puede hacer referencia la industria del software. Contiene procesos, actividades y
tareas para aplicar durante la adquisición de un sistema que contiene software, un
producto software puro o un servicio software y durante el suministro, desarrollo,
operación y mantenimiento de productos software.

4.2.1. Limitaciones del NTP-ISO/IEC 12207.

Esta Norma Técnica Peruana (NTP) tiene las siguientes limitaciones:
 La NTP describe la arquitectura de los procesos del ciclo de vida del software, pero no
especifica los detalles de cómo implementar o llevar a cabo las actividades y tareas
incluidas en los procesos.
 Esta NTP no pretende establecer el nombre, el formato o el contenido explícito de la
documentación que se genere.
 La NTP no establece un modelo de ciclo de vida concreto para el desarrollo del
software. En esta NTP las partes son los responsables de seleccionar un modelo de
ciclo de vida para el proyecto software y de elaborar una correspondencia entre los
procesos, actividades y tareas de esta NTP y los de dicho modelo. Las partes son
también responsables de seleccionar y aplicar los métodos de desarrollo de software y
de llevar a cabo las actividades y tareas adecuadas para el proyecto de software.
 Esta NTP no pretende entrar en conflicto con las políticas, normas o procedimientos en
vigor en alguna organización. Sin embargo, es necesario resolver cualquier conflicto
que surja, documentando por escrito en forma de excepción cualquier incumplimiento
de esta NTP autorizado por las partes.

4.2.2. Procesos Principales del Ciclo de Vida del NTP-ISO/IEC 12207.

Esta NTP agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida
del software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos
organizativos. Cada proceso del ciclo de vida está dividido en un conjunto de
actividades; cada actividad se subdivide a su vez en un conjunto de tareas tal como se
muestra en la siguiente figura.

8
Figura 5. Estructura de la Norma Técnica Peruana NTP-ISO/IEC 12207. Fuente: Basada en
la NTP-ISO/IEC 12207.

4.2.2.1. Procesos Principales del NTP-ISO/IEC 12207

Los procesos principales del ciclo de vida son cinco, que dan servicio a las partes
principales durante el ciclo de vida del software. Una parte principal es aquella que
inicia o lleva a cabo el desarrollo, operación, o mantenimiento de los productos
software. Estas partes principales son el adquiriente, el proveedor, el desarrollador, el
operador y el responsable del mantenimiento del producto software. Los procesos son:
 Proceso de adquisición. Define las actividades del adquiriente, la organización que
adquiere un sistema, producto software o servicio software.
 Proceso de suministro. Define las actividades del proveedor, organización que
proporciona un sistema, producto software o servicio software al adquiriente.
 Proceso de desarrollo. Define las actividades del desarrollador, organización que
define y desarrolla el producto software.
 Proceso de operación. Define las actividades del operador, organización que
proporciona el servicio de operar un sistema informático en su entorno real, para sus
usuarios.
 Proceso de mantenimiento. Define las actividades del responsable de mantenimiento,
organización que proporciona el servicio de mantenimiento del producto software; esto
es, la gestión de las modificaciones al producto software actualizada y operativa. Este
proceso incluye la migración y retirada del producto software.

9
4.2.2.2. Procesos de Desarrollo de la NTP-ISO/IEC 12207
El proceso de desarrollo contiene las actividades y tareas del desarrollador. El proceso
contiene las actividades para el análisis de los requerimientos, diseño, codificación,
integración, pruebas e instalación y aceptación relacionadas con los productos
software. Puede contener actividades a nivel de sistema si se estipula en el contrato.
El desarrollador lleva a cabo o soporta las actividades de este proceso de acuerdo con
el contrato.
El desarrollador gestiona el proceso de desarrollo al nivel de proyecto siguiendo el
proceso de gestión, que se emplea en este proceso; establece una infraestructura
basado en el proceso que se sigue en el proceso de infraestructura, adapta el proceso
al proyecto siguiendo el proceso de adaptación; y gestiona el proceso a nivel de
organización siguiendo el proceso de mejora de proceso y el proceso de recursos
humanos. Cuando el desarrollador es el proveedor del producto software desarrollado,
el desarrollador lleva a cabo el proceso de suministro.

Este proceso consta de la siguiente lista de actividades:

 Implementación del proceso
 Análisis de los requerimientos del sistema
 Diseño de la arquitectura del sistema
 Análisis de los requerimientos software
 Diseño de la arquitectura del software
 Diseño detallado del software
 Codificación y pruebas del software
 Integración del software
 Pruebas de calificación del software
 Integración del sistema
 Pruebas de calificación del sistema
 Instalación del software
 Apoyo a la aceptación del software

4.3. RUP (Rational Unified Process).

El proceso RUP se divide en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el tipo de proyecto y haciendo mayor o menor
hincapié en las distintas actividades del proceso. El ciclo de vida RUP es un modelo de
desarrollo en espiral y junto con el lenguaje UML constituye una metodología estándar
muy utilizada para el análisis, implementación y documentación de sistemas
orientados a objetos.

4.3.1. Metodología de Implementación de Software basada en BPM / RUP /

SOA / CDM.
Para la fase de implementación de software de un proyecto, se puede utilizar crear y
utilizar una metodología basada en RUP, el cual proporcionará un enfoque disciplinado
para asignar tareas y responsabilidades (quién hace qué, cómo y cuándo), el
desarrollo en esta metodología puede ser iterativo buscando una correcta
administración de requisitos.
La definición de esta metodología requiere del uso de arquitecturas basadas en
componentes, en modelamiento visual del software, verificación de la calidad del
software. Esta metodología (CDM: Custom Development Method) puede ser
complementada o personalizada por el XXXXXXX, con el objetivo de robustecer la
calidad y cantidad de entregables para contar con la información requerida durante la
implantación del software.
Esta metodología de desarrollo de software a medida, basa sus conceptos en CMMI
(Capability Maturity Model Integration) y la Norma ISO 15504 con el objetivo de
mejorar constantemente sus prácticas de desarrollo de software.

10
Tanto RUP como CDM, se basan en principios similares y persiguen los mismos
objetivos, tales como:
 Ser una metodología ágil de gestión y desarrollo de proyectos, que optimice el
costo/beneficio de cada actividad que se desarrolla a lo largo de un proyecto.
 Basadas en los modelos PMMI y CMMI.
 Ser una metodología ágil basada en releases o iteraciones.
 Enfocadas a entregables.
 Con soporte en la gestión y organización de la implantación acompañando al proyecto
en todas sus fases, asumiendo el control de riesgos, planes y presupuestos.
 Adaptable a distintos tipos de proyecto.
 Basada en el concepto de arquitectura de componentes reutilizables y desarrollo
iterativo.
 Importancia de la función de control de calidad.

Por otro lado, para el modelamiento de procesos, se prevé complementarlo con una
metodología especificada por la Oficina de Planeamiento y Desarrollo, a través de la
Unidad de Mejora de Procesos. En este sentido, se espera una metodología BPM
(Business Process Management) el cual tiene por objetivo mejorar la eficiencia a
través de la gestión sistemática de los procesos de negocio, que se deben modelar,
automatizar, integrar, monitorizar y optimizar de forma continua.

Por otro lado, debido a la importancia que tiene una correcta migración de la
información, ya que esta facilita a que los usuarios confíen en el nuevo sistema
utilizará el método de migración de la metodología CDM de manera de otorgar a
XXXXXXX y los usuarios, seguridad y confianza en la integridad de los datos de los
nuevos sistemas.

Finalmente, para asegurar que se realice una implementación basada en servicios,

utilizaremos un enfoque SOA que nos lleve a definir una arquitectura tal, que permita
soportar de manera orquestada la secuencia definida para realizar los procesos de
negocio. El paradigma SOA (Service Oriented Architecture) está basado en la
definición de servicios (implementación que provee lógica de negocio y datos)
reutilizables con interfaces públicas bien definidas, donde proveedores y consumidores
de servicios interactúan en forma desacoplada para realizar los procesos del negocio.

Esta metodología según las necesidades de los proyectos, plantea utilizar un enfoque
metodológico robusto basado en las mejores prácticas de las metodologías BPM /
RUP / SOA complementada por la metodología de implantaciones de desarrollos a
medida CDM.

Metodología RUP, metodología ágil para desarrollo de software centrado en la

arquitectura, ágil e iterativo, que permite realizar un seguimiento detallado y realizar
entregables parciales e incrementales logrando un grado de flexibilidad requerido para
el proyecto.

Metodología de desarrollo de software (desarrollo a medida) CDM, que complementa a

la metodología RUP principalmente por la calidad y cantidad de sus entregables y
además, dado que por su filosofía, contempla las iteraciones y versiones necesarias
para el proyecto.

Metodología de diseño de procesos BPM, metodología que involucra la articulación de

la estrategia, los procesos y la tecnología de una organización para generar valor
agregado al negocio. Este se concentra en la articulación de las iniciativas estratégicas
con los procesos de negocio, apalancados en estándares tecnológicos que facilitan su
despliegue alineado en las operaciones diarias de la organización. Principalmente

11
considera la definición, diseño, ejecución, operación y administración de los procesos
de negocio en orden a conseguir un mejoramiento continuo.

Metodología SOA, concepto de arquitectura de software que define la utilización de

servicios para dar soporte a los requisitos del negocio. SOA por sus características de
modularidad, encapsulamiento, bajo acoplamiento, separación de niveles de
abstracción, re-uso y composición orientada al ensamblaje de servicios, con
orquestación, monitoreo y administración.

Basada en la experiencia del Proyecto SEACE Versión 3.0, se considera relevante

construir un cuadro comparativo con las mejores prácticas de una metodología RUP y
CDM, para identificar similitudes y diferencias a tomar en cuenta en el desarrollo de
software.

Tabla 2. Cuadro Comparativo de Metodologías Bases del SEACE Versión 3.0, RUP y
CDM.
Bases del SEACE Versión 3.0 Metodología RUP Metodología CDM

Planificación de la ejecución Modelado del negocio Estrategia del proyecto

Análisis de requerimientos Requisitos Gestión de requisitos
funcionales
Diseño orientado a la construcción Análisis y Diseño Diseño funcional
Implementación Construcción
Pruebas de usuario Pruebas Pruebas
Entrenamiento al usuario Despliegue Despliegue
Implantación

Cada una de las metodologías escogidas, proporcionan explicaciones detalladas de

cómo los especialistas involucrados deben proceder, ayudando a definir claramente el
modo más simple de realizar y maximizar la eficiencia de la implantación.

La creciente incorporación de la metodología RUP en el desarrollo de sistemas

orientados a la integración de procesos e interoperabilidad ha supuesto impactos en
las metodologías tradicionales de implantación. Si bien no se trata de cambios
estructurales, sí se requieren nuevos modelos que los desafíos que trae consigo esta
nueva visión de los sistemas y las tecnologías asociadas.

RUP es el resultado del proceso de ingeniería de software que proporciona un enfoque

disciplinado para asignar tareas y responsabilidades (quién hace qué, cómo y cuándo)
dentro de una organización del desarrollo. Su meta es asegurar, en base a un conjunto
de mejores prácticas, la producción del software de alta calidad que resuelve las
necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.
Estas mejores prácticas se resumen en:
 Desarrollo iterativo del software:
o Permite comprender los requerimientos que hacen crecer el sistema.
o Sigue un modelo que busca las tareas más riesgosas, con el fin de reducir los
riesgos del proyecto.
 Administración de requisitos:
o Describe como se obtienen, organizan, documentan los requerimientos.
o Captar y comunicar los requerimientos de la organización.
o Documentar las decisiones.
 Uso de arquitecturas basadas en componentes:
o Se basa en diseñar una arquitectura con orientación a objetos, resistente, que
sea flexible, fácil de modificar, comprensible y que se fundamenta en la
reutilización de sus componentes.
 Modelamiento visual del software:
o Modela visualmente la organización.

12
 o Permite analizar la consistencia entre los componentes, el diseño y su
implementación.
 Verificación de la calidad del software durante todo el ciclo de vida.
 Control de cambios.

La estructura de RUP contempla dos dimensiones:

 Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del
proceso (fases) a lo largo de su desenvolvimiento.
 Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una
manera lógica de acuerdo a su naturaleza (flujos de trabajo).

La primera dimensión representa el aspecto dinámico del proceso conforme se va

desarrollando, se expresa en términos de fases, iteraciones y la finalización de las
fases o hitos.
La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en
términos de componentes del proceso, disciplinas, actividades, flujos de trabajo,
artefactos y roles.
En la siguiente figura, es posible visualizar como varía el énfasis de cada disciplina en
el tiempo y durante cada una de las fases.

Figura 6. Flujos de Trabajo del Proceso. Fuente: Metodología de Desarrollo del Software,
Universidad Politécnica de Valencia - España.

4.3.2. Características de RUP

Las principales características de RUP son:
 Proceso dirigido por los casos de uso: Con esto se refiere a la utilización de los
casos de uso para el de las disciplinas con los artefactos, roles y actividades
necesarias. Los casos de uso son la base para la implementación de las fases y
disciplinas del RUP. Se define un caso de uso como un fragmento de funcionalidad del
sistema que proporciona al usuario un valor añadido. Los casos de uso entonces
representan los requisitos funcionales del sistema, es decir, una secuencia de pasos

13
 que conlleva la realización e implementación de un requerimiento planteado por el
cliente.
 Proceso centrado en la arquitectura: Define la arquitectura de un sistema, y una
arquitectura ejecutable construida como un prototipo evolutivo. La arquitectura de un
sistema es la organización o estructura de sus partes más relevantes, lo que permite
tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una
perspectiva clara del sistema completo, necesaria para controlar el desarrollo. Además
la definición de la arquitectura debe tomar en consideración elementos de calidad del
sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible
durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la
plataforma software, sistema operativo, gestor de bases de datos, protocolos,
consideraciones de desarrollo como sistemas heredados. Muchas de estas
restricciones constituyen requisitos no funcionales del sistema. Una arquitectura
ejecutable es una implementación parcial del sistema, construida para demostrar
algunas funciones y propiedades.
RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida
como un prototipo evolutivo. Al final de la fase de elaboración se obtiene una línea
base de la arquitectura donde fueron seleccionados una serie de casos de uso
arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más
importantes, aquellos que son los más importantes para el usuario y aquellos que
cubran las funcionalidades significativas).
 Proceso iterativo e incremental: Es el modelo utilizado por RUP para el desarrollo de
un proyecto de software. La estrategia que se propone en RUP es tener un proceso
iterativo e incremental en donde el trabajo se divide en partes más pequeñas o
subproyectos. Permitiendo que el equilibrio entre casos de uso y arquitectura se vaya
logrando durante cada subproyecto, así durante todo el proceso de desarrollo. Cada
subproyecto puede verse como una iteración (un recorrido más o menos completo a lo
largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento
que produce un crecimiento en el producto.
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada
iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando
termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los
existentes, afectando a las iteraciones siguientes. Durante la planificación de los
detalles de la siguiente iteración, el equipo también examina cómo afectarán los
riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración
pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con
esta dinámica hasta que se haya finalizado por completo con la versión actual del
producto.

Figura 7. Desarrollo Iterativo de un Proceso RUP. Fuente: RUP.

4.3.3. Fases en RUP

El ciclo de vida del software bajo la metodología RUP se descompone en cuatro fases
secuenciales. Al finalizar cada una de ellas se realiza una revisión y evaluación para

14
determinar si los objetivos de la fase se han cumplido. Una evaluación satisfactoria
permite que el proyecto continúe a la siguiente fase.
El ciclo de vida engloba un subconjunto de ciclos en el que cada uno de ellos produce
una nueva versión del producto, cada ciclo está compuesto por fases y cada una de
estas fases está compuesta por un número de iteraciones. La siguiente tabla explica
cada una de las fases de RUP:

Tabla 3. Descripción de las Fases de RUP.

Fase Objetivos Artefactos

Inicio.  Establecer el alcance del proyecto y  Un documento con la visión

El objetivo es determinar la visión las condiciones límites. del proyecto
del proyecto y definir lo que se  Discriminar los casos de uso del  El modelo de casos de uso
desea realizar. sistema. con una lista de todos los
 Estimar costos y tiempos de casos de uso y los actores
Criterios de Evaluación. proyectos. que puedan ser
 Consenso de las partes  Estimar riesgos potenciales. identificados.
interesadas en la definición del  Un glosario inicial del
alcance y la estimación de proyecto.
costos y tiempos.  Un caso inicial del negocio
 Fidelidad en los casos de uso el cual incluye: contexto del
primarios. negocio, criterios de éxito y
 Credibilidad en los costos y planificación financiera.
tiempos estimados en el  Un estudio inicial de riesgos.
proceso de desarrollo.  Requerimientos
 Alcance de prototipo de complementarios.
arquitectura desarrollado.  Un plan del proyecto el cual
 Gastos reales contra gastos muestre las fases y las
planificados. iteraciones.
 Un análisis del diseño de
instrucción a utilizar.

Elaboración.  Definir, validar y delinear la  Un modelo de casos de uso

Etapa en la que se determina la arquitectura tan rápido como sea (completo en al menos un
arquitectura óptima del proyecto. posible. 80%), con todos los actores
 Refinar la visión. identificados y la mayor
Criterios de Evaluación.  Delinear un plan de alta fidelidad para parte de las descripciones
 Estabilidad en la visión del la fase de construcción. de casos de uso.
producto.  Demostrar que la arquitectura  Requerimientos
 Estabilidad de la arquitectura delineada soportará la visión del complementarios: los no
 Nivel de detalle y exactitud del producto educativo deseado, por un funcionales o no asociados
plan de la fase de construcción. costo y tiempo razonable. con ningún caso de uso.
Respaldos de las estimaciones.  Descripción de la
 Acuerdos de las partes Actividades Esenciales. arquitectura del software.
interesadas acerca de que el  Elaborar la visión y establecer un  Prototipo ejecutable de la
plan logre que se pueda sólido entendimiento de los casos de arquitectura.
alcanzar la visión al desarrollar uso más críticos que conducen las  Una lista revisada de
el sistema con la arquitectura decisiones de arquitectura y riesgos
seleccionada. planificación  Plan de proyecto incluyendo
 Elaborar la arquitectura y seleccionar iteraciones y criterios de
los componentes. evaluación para cada
iteración.

Construcción.  Minimizar los costos de desarrollo.  El producto de software

Se obtiene la capacidad operacional  Lograr la calidad adecuada. Integrado sobre plataforma
inicial.  Lograr versiones que puedan ser adecuada.
usadas.  Una descripción de la
Criterios de Evaluación. versión actual.
 Estabilidad y madurez de la Actividades Esenciales.
versión del producto, capacidad  Gerencia de recursos, control de
para ser enviada a los usuarios. recursos y optimización de procesos.
 Los gastos reales de recursos  Desarrollo completo de componentes
comparados con los gastos y pruebas contra criterios de
planificados. evaluación definidos.
  Desarrollo de versiones del producto.
 Manual preliminar del usuario.
 Manual preliminar del docente.

Transición.  Lograr que el usuario apruebe el  Producto final

15
 Fase Objetivos Artefactos

Obtener el producto acabado y producto de software.  Manual de usuario final.

definido.  Lograr un producto final tan  Manual de instalación y
rápidamente y costo efectivo como configuración.
Criterios de Evaluación. sea posible.  Capacitación a usuario.
 Usuarios satisfechos.  Soporte y mantenimiento.
 Gastos de recursos actuales Actividades Esenciales.
contra gastos planificados.  Ajustes, incluyendo corrección de
errores y mejoramiento para el
desempeño y usabilidad.

Fuente: Kruchten, P.(2000) “The Rational Unified Process: an introduction”. Cuarta Edición. Addison-
Wesley Publishers.

Cada fase en RUP puede descomponerse en iteraciones, entonces el producto se

desarrollará repitiendo la misma secuencia de las fases de inicio, elaboración,
construcción y transición, pero con diversos énfasis cada fase. Cada paso de las fases
produce una generación del software y estos ciclos subsecuentes se denominan ciclos
de la evolución. Mientras que el producto pasa durante varios ciclos, se producen las
nuevas generaciones.

Evolución 0
Inicio Elaboración Construcción Transición Evolución 1

Generación 1
Tiempo
Evolución 1
Inicio Elaboración Construcción Transición Evolución 2

Generación 2
Tiempo
Evolución 2
Inicio Elaboración Construcción Transición Evolución 3

Generación 3
Tiempo
Figura 8. Ciclo evolutivo en la elaboración de software basado en RUP.

Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas por el usuario,
cambios en el contexto del usuario, cambios en la tecnología subyacente, reacción a la
competición, etc. Usualmente tienen fases de concepción y elaboración mucho más
cortas, puesto que la definición y la arquitectura básicas del producto son
determinadas por los ciclos de desarrollo predecesores. Las excepciones a esta regla
son los ciclos evolutivos en los cuales ocurre o surge un producto significativo o una
redefinición arquitectónica.
Finalmente, cada fase se concluye con un hito bien definido, un punto en el tiempo en
el cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de
pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores
que podrían ser los criterios aplicables a cada iteración. Los hitos para cada una de las
fases son: Inicio - Objetivos, Elaboración - Arquitectura, Construcción - Capacidad
Operacional Inicial, Transición - Release del producto. Las fases y sus respectivos
hitos se ilustran a continuación:

16
 Inicio Elaboración Construcción Transición

Objetivos Arquitectura Capacidad Release del

Operacional Producto
Inicial
Tiempo

Figura 9. Fases e hitos en RUP.

4.3.4. Disciplinas
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos
para la culminación de cada una de ellas. Estas disciplinas se dividen en dos grupos:
las primarias y las de apoyo.
Las primarias son las necesarias para la realización de un proyecto de software. Entre
las disciplinas primarias o fundamentales se tienen: modelado del negocio,
requerimientos, análisis y diseño, implementación, pruebas y despliegue.
Las de apoyo son las que, como su nombre lo indica, sirven de soporte y/o
complemento a las primarias y especifican otras características en la realización de un
proyecto de software; entre estas se tienen: entorno, gestión del proyecto, gestión de
configuración y cambios.
A continuación se describe brevemente cada una de las disciplinas (flujos trabajo)
primarias y las de apoyo:

Tabla 4. Descripción de cada una de las disciplinas Primarias y de Apoyo de RUP.

Flujo de trabajo Descripción Objetivos

Modelado del Con este flujo de trabajo se espera llegar a un  Entender la estructura y la dinámica de la
negocio mejor entendimiento de la organización donde organización para la cual el sistema va ser
se va a implantar el producto. desarrollado (organización objetivo).
 Entender el problema actual en la
organización objetivo e identificar
potenciales mejoras.
 Asegurar que clientes, usuarios finales y
desarrolladores tengan un entendimiento
común de la organización objetivo.
 Derivar los requisitos del sistema
necesarios para apoyar a la organización
objetivo.

Requisitos Este es uno de los flujos de trabajo más  Establecer y mantener un acuerdo entre
importantes, ya que en él se establece la clientes y otros stakeholders sobre lo que
funcionalidad exacta del sistema a implantar el sistema podría hacer.
(administración de requisitos). En esta línea  Proveer a los desarrolladores un mejor
los requisitos son el contrato que se debe entendimiento de los requisitos del
cumplir, de modo que los usuarios finales sistema.
tienen que comprender y aceptar los  Definir el ámbito del sistema.
requisitos especificados.  Proveer una base para la planeación de
los contenidos técnicos de las iteraciones.
 Proveer una base para estimar costos y
tiempo de desarrollo del sistema.
 Definir una interfaz de usuarios para el
sistema, enfocada a las necesidades y
metas del usuario.

Análisis y Corresponde a la traducción de los requisitos  Transformar los requisitos al diseño del
Diseño a una especificación que describe cómo futuro sistema.
implementar el sistema.  Desarrollar una arquitectura para el
El análisis consiste en obtener una visión del sistema.
sistema que se preocupa de ver qué hace, de  Adaptar el diseño para que sea
modo que sólo se interesa por los requisitos consistente con el entorno de
funcionales. Por otro lado el diseño es un

17
Flujo de trabajo Descripción Objetivos

refinamiento del análisis que tiene en cuenta implementación, diseñando para el

los requisitos no funcionales, en definitiva rendimiento.
cómo cumple el sistema sus objetivos.
Implementación En este flujo de trabajo se implementan las  Planificar qué subsistemas deben ser
clases y objetos en ficheros fuente, binarios, implementados y en qué orden deben ser
ejecutables y otros. Además se deben hacer integrados, formando el Plan de
las pruebas unitarias: cada implementador es Integración.
responsable de probar las unidades que  Cada implementador decide en qué orden
produzca. El resultado final de este flujo de implementa los elementos del subsistema.
trabajo será un producto ejecutable.  Si encuentra errores de diseño, los
notifica.
 Se prueban los subsistemas
individualmente.

Pruebas Este flujo de trabajo es el encargado de  Encontrar y documentar defectos en la

evaluar la calidad del producto que se está calidad del software.
desarrollando, pero no para aceptar o  Generalmente asesora sobre la calidad
rechazar el producto al final del proceso de del software percibida.
desarrollo, sino que debe ir integrado en todo  Provee la validación de los supuestos
el ciclo de vida. realizados en el diseño y especificación
de requisitos por medio de
demostraciones concretas.
 Verificar las funciones del producto de
software según lo diseñado.
 Verificar que los requisitos tengan su
apropiada implementación.

Despliegue Este flujo de trabajo describe las actividades  Probar el producto en su entorno de
asociadas con el aseguramiento de la entrega ejecución final.
y disponibilidad del producto de software hacia  Empaquetar el software para su
el usuario final. distribución.
 Distribuir el software.
 Instalar el software.
 Proveer asistencia y ayuda a los usuarios.
 Formar a los usuarios y al cuerpo de
ventas.
 Migrar el software existente o convertir
bases de datos.

Gestión del La finalidad de este flujo de trabajo es  Identificar los elementos configurables.
Cambio y mantener la integridad de todos los artefactos  Restringir los cambios en los elementos
Configuraciones que se crean en el proceso, así como de configurables.
mantener información del proceso evolutivo  Auditar los cambios hechos a estos
que han seguido. elementos.
 Definir y mantener las configuraciones de
estos elementos.

Gestión del Corresponde a la gestión equilibrada de  Proveer un marco de trabajo para la

Proyecto objetivos, riesgos y restricciones para gestión de proyectos de software
desarrollar un producto que sea acorde a los intensivos.
requisitos planteados.  Proveer guías prácticas realizar
planeación, contratar personal, ejecutar y
monitorear el proyecto.
 Proveer un marco de trabajo para
gestionar riesgos.

Entorno La finalidad de este flujo de trabajo es dar  Selección y adquisición de herramientas.

soporte al proyecto con las adecuadas  Establecer y configurar las herramientas
herramientas, procesos y métodos. Brinda una para que se ajusten a la organización.
especificación de las herramientas que se van  Configuración del proceso.
a necesitar en cada momento, así como  Mejora del proceso.
definir la instancia concreta del proceso que  Servicios técnicos.
se va a seguir.

4.3.5. Organización y elementos RUP

En RUP un proceso de desarrollo de software define en forma disciplinada la
asignación de tareas y responsabilidades, es decir, quién hace qué, cuándo y cómo.
RUP define cuatro elementos: los roles, que responden a la pregunta ¿Quién?; las

18
actividades que responden a la pregunta ¿Cómo?; los productos, que responden a la
pregunta ¿Qué? y los flujos de trabajo de las disciplinas, que responde a la pregunta
¿Cuándo?.

Quién Cómo Cuándo

Rol Actividad

Diseñador Análisis Casos Diseño Casos

de Uso de Uso
Qué
Artefacto Responsable

Realización de
Caso de uso

Figura 10. Organización y elementos del RUP.

4.3.5.1. Actores o Roles

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de
individuos trabajando juntos como un equipo. Una persona puede desempeñar
diversos roles, así como un mismo rol puede ser representado por varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades
como el ser el dueño de un conjunto de artefactos.
RUP define grupos de roles, agrupados por participación en actividades relacionadas
tal como se muestra en la tabla adjunta:

Tabla 5. Grupo de Roles de RUP.

Grupo o categoría Rol

Analistas, representados en el plan de trabajo por el analista  Analista de procesos de negocio.

funcional senior, analistas programadores, analista de pruebas,  Diseñador del negocio.
ayudante ofimático.  Analista de sistema.
 Especificador de requisitos.

Desarrolladores, representado en el plan de trabajo por el  Arquitecto de software.

arquitecto de software, diseñador web, líder tecnológico,  Diseñador
administrador de base datos.  Diseñador de interfaz de usuario
 Diseñador de cápsulas.
 Diseñador de base de datos.
 Implementador.
 Integrador.

Gestores, representado en el plan de trabajo por el gerente de  Jefe de proyecto.

proyecto, jefe de proyecto, analista funcional senior, líder  Jefe de control de cambios.
tecnológico.  Jefe de configuración.
 Jefe de pruebas.
 Jefe de despliegue.
 Ingeniero de procesos.
 Revisor de gestión del proyecto.
 Gestor de pruebas.

Apoyo, representado en el plan de trabajo por el ayudante  Documentador técnico.

ofimático, analistas programadores, diseñador web, especialista  Administrador de sistema.
en capacitación, líder tecnológico.  Especialista en herramientas.
 Desarrollador de cursos.
 Artista gráfico.

19
 Grupo o categoría Rol

Especialista en pruebas, representado en el plan de trabajo por  Especialista en Pruebas (tester).

el analista funcional senior, analista de pruebas  Analista de pruebas.
 Diseñador de pruebas.

Otros roles  Stakeholders.

 Revisor.
 Coordinación de revisiones.
 Revisor técnico.
 Cualquier rol o trabajador.

4.3.5.2. Actividades
Una actividad en concreto es una unidad de trabajo que una persona que desempeñe
un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto,
normalmente expresado en términos de crear o actualizar algún producto.

4.3.5.3. Arquitectura Centrada

La arquitectura de un sistema software se describe mediante diferentes vistas del
sistema en construcción. El concepto de arquitectura software incluye los aspectos
estáticos y dinámicos más significativos del sistema. La arquitectura es una vista del
diseño completo con las características más importantes resaltadas, dejando los
detalles de lado.
Los casos de uso y la arquitectura están profundamente relacionados. Los casos de
uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el
desarrollo de todos los casos de uso requeridos, actualmente y a futuro.
El arquitecto desarrolla la forma o arquitectura a partir de la comprensión de un
conjunto reducido de casos de uso fundamentales o críticos (usualmente no más del
10 % del total). En forma resumida, podemos decir que el arquitecto:
 Crea un esquema en borrador de la arquitectura comenzando por la parte no específica
de los casos de uso (por ejemplo la plataforma) pero con una comprensión general de
los casos de uso fundamentales.
 A continuación, trabaja con un conjunto de casos de uso clave o fundamental. Cada
caso de uso es especificado en detalle y realizado en términos de subsistemas, clases,
y componentes.
 A medida que los casos de uso se especifican y maduran, se descubre más de la
arquitectura, y esto a su vez lleva a la maduración de más casos de uso.

Este proceso continúa hasta que se considere que la arquitectura es estable. A

continuación una breve descripción de las vistas de la arquitectura:
 Vista de Casos de Uso: Lista los casos de uso o escenarios del modelo de casos de
uso que representen funcionalidades centrales del sistema final, que requieran una
gran cobertura arquitectónica o aquellos que impliquen algún punto especialmente
delicado de la arquitectura.
 Vista Lógica: Describe las partes arquitectónicamente significativas del modelo de
diseño, como ser la descomposición en capas, subsistemas o paquetes. Una vez
presentadas estas unidades lógicas principales, se profundiza en ellas hasta el nivel
que se considere adecuado.
 Vista de Procesos: Describe la descomposición del sistema en threads y procesos
pesados. Indica que procesos o grupos de procesos se comunican o interactúan entre
sí y los modos en que estos se comunican.
 Vista de Deployment: Describe uno o más escenarios de distribución física del
sistema sobre los cuales se ejecutará y hará el deploy del mismo. Muestra la
comunicación entre los diferentes nodos que componen los escenarios antes
mencionados, así como el mapeo de los elementos de la Vista de Procesos en dichos
nodos.

20
  Vista de Implementación: Describe la estructura general del Modelo de
Implementación y el mapeo de los subsistemas, paquetes y clases de la Vista Lógica a
subsistemas y componentes de implementación.
 Vista de Datos: Describe los elementos principales del Modelo de Datos, brindando un
panorama general de dicho modelo en términos de tablas, vistas, índices, etc.

Vista Lógica Vista de

Implementación
Analistas/Diseñadores
Programadores
Estructura
Gestión del Software

Vista de Casos
de Uso

Usuario Final
Funcionalidad

Integradores de Sistemas Ingeniería de Sistemas

Desempeño Topología del Sistema
Escalabilidad Entrega, Instalación
Rendimiento Comunicaciones
Vista de Vista de
Proceso Implantación

Figura 11. Arquitectura Centrada.

4.3.5.4. Artefactos
Un producto o artefacto es un trozo de información que es producido, modificado o
usado durante el proceso de desarrollo de software. Los productos son los resultados
tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto
final.
Un artefacto puede ser cualquiera de los siguientes:
 Un documento, como el documento de la arquitectura del software.
 Un modelo, como el modelo de casos de uso o el modelo de diseño.
 Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un
caso de uso o un subsistema.

21
Figura 12. Algunos Artefactos de RUP.

22
 Diagrama de
Clases

Diagrama de
Componentes

Diagramas de Diagrama de
Estructura Despliegue

Diagrama de
Objetos

Diagrama de
Paquetes
Diagramas

Diagrama de
Actividades

Diagrama de
Casos de Uso
Diagramas de Diagrama de
Comportamiento Secuencia
Diagrama de
Maquina de
Estados
Diagrama de
Comunicación
Diagrama de
Interacción
Diagrama de
Interacción
General

Diagrama de
Tiempos

Figura 13. Estructura de Diagramas de RUP.

RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una
serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño
del sistema estos artefactos son los siguientes:
 Inicio:
o Documento Visión
o Especificación de Requerimientos
 Elaboración:
o Diagramas de caso de uso
 Construcción:
o Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica:
o Diagrama de Clases
o Modelo E-R (si el sistema así lo requiere)

Vista de Implementación:
o Diagrama de Secuencia
o Diagrama de Estados

23
 o Diagrama de Colaboración

Vista Conceptual:
o Modelo de Dominio

Vista física:
o Mapa de comportamiento a nivel de hardware.

4.3.6. Resultado obtenido al evaluar las metodologías

La identificación de las variables tomadas en cuenta para evaluar metodologías
desarrollo de software fueron tomadas del estudio realizado por Rafael Barzanallana
(2006), con las cuales Méndez Nava (2006) plantea un modelo de evaluación de
metodologías para el desarrollo de software, concluyendo en su investigación lo
siguiente:
 Se obtuvo una mayor ponderación en los procesos de desarrollo de ágil. Esto obedece
a que estas metodologías son la mejora continua de las metodologías ya existentes
como las convencionales y prescriptivas. Las metodologías de desarrollo de software
continúan evolucionando y cada vez se adecuan o cubren en mejor medida las
necesidades y requerimientos de los proyectos.
 Dentro de las metodologías de desarrollo ágil, los procesos que obtuvieron la mayor
ponderación son las de Proceso Unificado Relacional y Programación Extrema, sin
embargo estas dos metodologías son aplicadas para proyectos con diferencias en la
duración es decir la Programación Extrema es para proyectos cortos y que se desean
con rapidez y el Proceso Unificado es para un desarrollo de software más complejo y
de mayor duración.
 Dentro de las metodologías convencionales o prescriptivas la que obtuvo la mayor
ponderación es el modelo en espiral, ya que permite que el sistema evolucione, posee
gran interacción con el usuario, entre otros.

4.3.6.1. ¿Metodologías ágiles o metodologías tradicionales?

Según Hugo Arboleda Jiménez (docente de la Universidad de San Buenaventura Cali,
1999) en su estudio Modelos de Ciclo de Vida de Desarrollo de Software en el
Contexto de la Industria Colombiana de Software, menciona que en las metodologías
tradicionales el principal problema es que nunca se logra planear bien el esfuerzo
requerido para seguir la metodología. Pero entonces, si logramos definir métricas que
apoyen la estimación de las actividades de desarrollo, muchas prácticas de
metodologías tradicionales podrían ser apropiadas. El no poder predecir siempre los
resultados de cada proceso no significa que estamos frente a una disciplina de azar.
Lo que significa es que estamos frente a la necesidad de adaptación de los procesos
de desarrollo que son llevados por parte de los equipos que desarrollan software.
Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se
desarrolle resulta una idea interesante. Estas metodologías pueden involucrar
prácticas tanto de metodologías ágiles como de metodologías tradicionales. De esta
manera podríamos tener una metodología por cada proyecto, la problemática sería
definir cada una de las prácticas, y en el momento preciso definir parámetros para
saber cuál usar.

5. Ciclo de Vida de Software del XXXXXXX

Después de la revisión bibliográfica y de los estudios realizados a los procesos de
desarrollo complejo y ágiles se determina como conveniente utilizar un modelo
incremental iterativo basado en RUP, con orientación ágil para tipos proyectos de baja
complejidad.

24
6. Procesos de la Metodología de Desarrollo de Software del XXXXXXX
La cadena de valor (basado en RUP) de la metodología de software del XXXXXXX
abarcará los procesos Modelo de negocio, Requisitos, Análisis y Diseño,
Implementación, Pruebas y Despliegue. Los cuales de acuerdo al modelo elegido
“incremental iterativo” permitirá realizar las “n” iteraciones necesarias hasta conseguir
la aprobación del usuario.

Cadena de Valor de la Metodología de Desarrollo de Software del OSCE

Modelo de Requisitos Análisis y Diseño Implementación Pruebas Despliegue
Negocio

Inicio Elaboración Construcción Transición

Tiempo

Figura 14. Proceso de la Metodología de Desarrollo de Software del XXXXXXX.

7. Entregables de la Metodología de Desarrollo de Software

La siguiente tabla muestra los entregables identificados y definidos en la Metodología
de Desarrollo de Software del XXXXXXX, el cual se encuentra alineado a los objetivos
y contenido de RUP de acuerdo a su orientación y modelo.

Tabla 6. Lista de Entregables de la Metodología de Desarrollo de Software del XXXXXXX.

Procesos Entregable Descripción del Contenido del Entregable Tipo de
Entregable
Modelado del Diagnóstico Situacional  Contiene la situación actual del negocio que  Word
negocio se requiere optimizar y/o rediseñar. En el
documento se hace referencia a los
documentos elaborados por la Unidad de
Métodos y que se encuentren vigentes.
Alcance de Alto Nivel  Contiene los módulos y funcionalidades que  Word
se van a contemplar en el nuevo sistema, a
nivel macro y general. En el documento se
hace referencia a los documentos
elaborados por la Unidad de Métodos y que
se encuentren vigentes.
Requisitos Diseño Funcional (DF). El  Diseño Funcional (DF)  Word
documento está compuesto de las  Especificación de Requerimientos.  Excel
siguientes secciones: Contiene el listado de los requerimientos
 Especificación de funcionales y no funcionales, solicitados por
Requerimientos las áreas usuarias encargadas, así como
 Diagrama de actores (roles) información relacionada a la clasificación de
 Listado de Casos de Uso cada requerimiento.
 Especificación de Casos de  Diagrama de actores (roles). Diagrama  Archivo de
Uso que contiene los actores o roles que se han Diagrama
 Bosquejos de Casos de Uso identificado en el sistema.
 Diagramas de Casos de Uso  Listado de Casos de Uso. Contiene los  Excel
casos de uso del sistema, indicando la
agrupación funcional y módulo al cual
pertenecen.
 Especificación de Casos de Uso.  Word
Contiene la descripción de los pasos o las
actividades que deberán realizarse para
llevar a cabo algún proceso en el sistema.
 Bosquejos de Casos de Uso. Contiene la  Archivo de
interfaz gráfica del caso de uso. Diagrama

25
 Procesos Entregable Descripción del Contenido del Entregable Tipo de
Entregable
 Diagramas de Casos de Uso. Diagrama  Archivo de
UML que contenga la funcionalidad del Diagrama
sistema agrupándola en descripciones de
acciones ejecutadas por un sistema para
obtener un resultado. Diagrama UML que
contenga la relación entre los casos de uso
y con los actores del sistema. Se va a
diagramar los casos de uso que
corresponden a un módulo o paquete del
sistema.
Análisis y Diseño Técnico (DT). El  Diseño Técnico (DT)  Word
Diseño documento está compuesto de las  Diagramas de Interacción. Diagramas  Archivo de
siguientes secciones: UML como "Secuencia" o "Colaboración", Diagrama
 Diagrama de Paquetes contienen la interacción entre los objetos y
 Diagramas de Clases los mensajes que intercambian entre sí
 Diagramas de Estados junto con el orden temporal de los mismos o
 Diagramas de Interacción la organización estructural de los objetos,
respectivamente.
 Diagramas de Clases. Diagrama UML que  Archivo de
contenga las clases de análisis, las cuales Diagrama
pueden agruparse por módulos o paquetes
del sistema. Las clases deben mostrar su
nombre y las relaciones entre ellas, debe
especificar el estereotipo de la clase
(Boundary, Control, Entity)
 Diagramas de Estados. Diagrama UML  Archivo de
que contenga los estados de las clases de Diagrama
entidad del diagrama de clases. Para cada
una de las entidades que cambian de
estado deberá mostrarse un diagrama de
estados. Si existen entidades que cumplen
con un cambio de estados igual, se puede
graficar un solo diagrama de estados y se
deberá indicar las clases que cumplen con
ese cambio de estados.
 Diagrama de Paquetes. Diagrama UML  Archivo de
que muestra cómo un sistema está dividido Diagrama
en agrupaciones lógicas mostrando las
dependencias entre esas agrupaciones. Se
va a diagramar los paquetes
correspondientes al sistema, asimismo los
paquetes de los sistemas relacionados.
Implementación Versión de Código Fuente y  Archivos fuente implementados que  Archivos
Objetos de Base de Datos contienen la lógica de negocio.
 Archivos fuentes que permiten la creación
de objetos de base de datos.
Diagrama de Componentes  Diagrama UML que contenga los  Archivo de
componentes del sistema, además deberá Diagrama
incluirse componentes externos con los que
se interactúe.
Pruebas Informe de Pruebas  De acuerdo al cronograma de pruebas se  Word
consolidará todas las incidencias
encontradas durante el proceso de pruebas.
Las incidencias encontradas permitirán
mejorar la funcionalidad del sistema y
servirá de evidencia para aceptar o aprobar
el módulo cuando estas se levanten.
Acta de Aprobación  Documento que aprueba la funcionalidad  Word
del sistema y autoriza su pase a producción
Manual de Usuario  El documento contendrá la funcionalidad del  Word
sistema de acuerdo a los roles creados en
el sistema.
Despliegue Manual de Instalación y Sistema  El documento contendrá los pasos que se  Word
requieran para configurar los servidores,
software base, herramientas que usa el
sistema, creación de base de datos y sus
objetos, y sistema.
Informe de Capacitación  Es el documento que informa las  Word
actividades de capacitación de acuerdo al
cronograma establecido para los diversos
roles creados para el sistema.

26
 Procesos Entregable Descripción del Contenido del Entregable Tipo de
Entregable
Versión Final de Código Fuente  Archivos actualizados de fuentes  Archivos
y Objetos de Base de Datos implementadas que contienen la lógica de
negocio.
 Archivos actualizados de fuentes que
permiten la creación de objetos de base de
datos.
Gestión del Documento de Alcance  Es la actualización del entregable  Word
Cambio y Documento Alcance de Alto Nivel.
Configuraciones
Informe de Cambio de Alcance  Es el documento que informa los diversos  Word
cambios solicitados por el usuario que
fueron aceptados, rechazados y pendientes.
Gestión del Entregables que serán definidos  Los entregables de esta metodología serán
Proyecto en la Metodología de Gestión de definidos en el proceso de gestión de
Proyectos proyectos.

La tabla siguiente muestra los entregables que se han considerado en el caso que un
proyecto sea simple o complejo, para lo cual es obligatorio la elaboración y
presentación del entregable a cargo del equipo del proyecto.
La simplicidad y/o complejidad del proyecto se determinará en base al alcance,
duración y costo del proyecto.

Tabla 7. Lista de Entregables por Tipo de Proyecto.

Entregables por Proceso Proyecto Simple Proyecto Complejo

Diagnóstico Situacional No Si o No
Alcance de Alto Nivel No Si o No
Diseño Funcional (DF) Si Si
Especificación de Si Si
Requerimientos
Diagrama de actores Si Si
(roles)
Listado de Casos de Uso Si Si
Especificación de Casos Si Si
de Uso
Bosquejos de Casos de No Si o No
Uso
Diagramas de Casos de Si Si
Uso
Diseño Técnico (DT) Si Si
Diagrama de Paquetes No Si
Diagramas de Clases Si Si
Diagramas de Estados No Si o No
Diagramas de Interacción No Si o No
Versión de Código Fuente y Si Si
Objetos de Base de Datos

Diagrama de Componentes No Si o No

Informe de Pruebas No Si

Acta de Aprobación Si Si
Manual de Usuario Si Si

Manual de Instalación y No Si
Sistema

Informe de Capacitación No Si o No

Versión Final de Código Si Si

Fuente y Objetos de Base de
Datos

Documento de Alcance No Si o No

27
Entregables por Proceso Proyecto Simple Proyecto Complejo

Informe de Cambio de No Si o No
Alcance

8. Plantilla de Cronograma de Trabajo

Ver Anexo “A” Plantilla de cronograma de trabajo.

9. Plantillas de Entregables
Ver Anexo “B” Plantillas de entregables de la Metodología de Desarrollo de software
del XXXXXXX.

28
10. Anexo “A” Plantilla de cronograma de trabajo.

29
11. Anexo “B” Plantillas de entregables de la Metodología de Desarrollo de
software del XXXXXXX.

11.1. Diagnóstico Situacional

11.2. Alcance de Alto Nivel

11.3. Diseño Funcional (DF)

Especificación de Requerimientos

Diagrama de actores (roles)

Listado de Casos de Uso

Especificación de Casos de Uso

Bosquejos de Casos de Uso

30
Diagramas de Casos de Uso

11.4. Diseño Técnico (DT)

Diagrama de Paquetes

Diagramas de Clases

Diagramas de Estados

Diagramas de Interacción

11.5. Versión de Código Fuente y Objetos de Base de Datos

 Archivo Comprimido con el código fuente (Código GDES015).
 Archivo Comprimido Compilado o Ejecutable (Código GDES016).
 Scripts de Creación de Objetos de Base de Datos (Código GDES017).

31
11.6. Diagrama de Componentes

11.7. Informe de Pruebas

11.8. Acta de Aprobación

11.9. Manual de Usuario

11.10. Manual de Instalación y Sistema

11.11. Informe de Capacitación

11.12. Versión Final de Código Fuente y Objetos de Base de Datos

 Archivo Comprimido con el código fuente (Código GDES015).
 Archivo Comprimido Compilado o Ejecutable (Código GDES016).
 Scripts de Creación de Objetos de Base de Datos (Código GDES017).

11.13. Documento de Alcance

Actualización del Documento de Alcance de Alto Nivel.

11.14. Informe de Cambio de Alcance

32