ensayo de los modelos para el desarrollo de software

1. Universidad Interactiva y a Distancia del Estado de
Guanajuato
Unideg Comonfort
Ing. En sistemas
Alumno: José Guadalupe Martínez Rincón
Maestra: Angelina Pérez Arvizu
Materia: Análisis y diseño de sistemas
Actividad 4 Ensayo modelos para el desarrollo de
Software

2. El proceso es el conocimiento incorporado, y puesto que el conocimiento esta
inicialmente disperso, el desarrollo de software implícito, latente e incompleto en
gran medida es un proceso social de aprendizaje. El proceso es un dialogo en el
que se reúne el conocimiento y se incluye en el software para convertirse en
software. El proceso proporciona una iteración entre los usuarios y los
diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los
diseñadores y las herramientas de desarrollo (tecnología). Es un proceso
interactivo donde la herramienta de desarrollo se usa como medio de
comunicación, con cada iteración del dialogo se obtiene mayor conocimiento.
Howard Baetjer
Desde un punto de vista técnico se puede decir que el proceso de software es un
marco de trabajo de las tareas que se requieren para construir software de alta
calidad.
Aún más importante es que la Ingeniería del Software la realizan personas
creativas, con conocimiento, que deberían trabajar dentro de un proceso del
software definido y avanzado que es apropiado para los productos que construyen
y para las demandas de su mercado.
4.1 Modelo de cascada
Modelo de Cascada (Bennington 1956, Modificado por Royce en 1970, Pressman
lo presenta como ciclo de vida clásico). Se denomina modelo en cascada porque
su característica principal es que no se comienza con un paso hasta que no se ha
terminado el anterior. El modelo en Cascada establece que el software debe ser
construido, rigurosamente, a través de una transformación sucesiva de
documentos, siguiendo una estrategia lineal de desarrollo. Primero saber qué se

3. quiere y después, cuando se conozca todo lo que se quiere, empezar a
construirlo.
El modelo de cascada también conocido como modelo lineal secuencial sugiere
un enfoque sistemático, secuencial para el desarrollo del software que comienza
en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento.
A grandes rasgos el primer paso es conseguir un documento con la especificación
completa, exacta, no ambigua de los requisitos del sistema software que debe ser
desarrollado. Este documento inicial es transformado en un documento de
análisis, supuestamente alejado de la máquina. Después, a partir del análisis, se
obtiene otro documento, el diseño. Y por último, del diseño se obtiene el
documento final: el código. Para asegurar que no se introducen equivocaciones al
transformar un documento (modelo) en otro, se hacen pruebas, al terminar cada
uno. Las pruebas son planificadas desde el principio y se documentan como se
vayan realizando. Antes de la entrega del sistema software, se valida que
satisface los requisitos definidos en el documento inicial.
Está basado en el ciclo convencional de una ingeniería, tiene las siguientes
actividades que se muestran en la figura 4.1 del modelo de cascada:

4. Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
Figura 4.1 Modelo de Cascada
Carolina Zibert, “Ciclos de v ida de Ingeniería de Sof tware” [En línea], Caracas Venezuela [Consulta: Abril
de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc>

5. Actividades
Ingeniería y Análisis del Sistema
Debido a que el software es siempre parte de un sistema mayor, el trabajo
comienza estableciendo los requisitos de todos los elementos del sistema y luego
asignando algún subconjunto de estos requisitos al software.
Análisis de los requisitos del software
Análisis: Se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada
SRD (Documento de Especificación de Requisitos), que contiene la especificación
completa de lo que debe hacer el sistema sin entrar en detalles internos (debe
comprender el ámbito de la información del software, así como la función, el
rendimiento y las interfaces requeridas).
Diseño
El diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. El proceso de diseño traduce los requisitos en una
representación del software con la calidad requerida antes de que comience la
codificación. Como resultado surge el SDD (Documento de Diseño del Software),
que contiene la descripción de la estructura global del sistema y la especificación
de lo que debe hacer cada una de sus partes, así como la manera en que se
combinan unas con otras.

6. Codificación
Es la fase de programación. Aquí se desarrolla el código fuente, el diseño debe
traducirse en una forma legible para la maquina, haciendo uso de prototipos así
como pruebas y ensayos para corregir errores. El paso de codificación realiza esta
tarea. Si el diseño se realiza de una manera detallada la codificación puede
realizarse mecánicamente.
Prueba
Una vez que se ha generado el código comienza la prueba del programa. La
prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren. Se comprueba que funciona correctamente antes de
ser puesto en explotación.
Mantenimiento
El software sufrirá cambios después de que se entrega al cliente. Los cambios
ocurrirán cuando se hayan encontrado errores, esto en lugar de que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.

7. Desventajas
 Los proyectos reales raramente siguen el flujo secuencial que propone el
modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
 Normalmente, es difícil para el cliente establecer explícitamente al principio
todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades
en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
 El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estará disponible una versión operativa del programa. Un error
importante no detectado hasta que el programa esté funcionando puede ser
desastroso.
Se tiene un Alto riesgo en sistemas nuevos debido a problemas en las
especificaciones y en el diseño. Bajo riesgo para desarrollos bien comprendidos
utilizando tecnología conocida
Este modelo, que se lleva a cabo de forma descendente, exige que para pasar a la
siguiente fase hay que concluir correctamente la anterior, de manera que los
posibles errores sean fácilmente detectables. Así, la salida de una fase es la
entrada de la siguiente.
La Ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software.
Modelo de espiral

8. El modelo espiral propuesto originalmente por Boehm en 1988, es un modelo de
proceso de software evolutivo ha sido desarrollado para cubrir las mejores
características tanto del ciclo de vida clásico, como de la creación de prototipos,
añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. Proporciona
el potencial para el desarrollo rápido de versiones incrementales del software. En
este modelo el software se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones, la versión incremental podría ser un modelo en
papel o un prototipo. En las últimas iteraciones, se producen versiones cada vez
más completas del sistema diseñado.
El modelo representado mediante la espiral de la figura 4.2 define cuatro
actividades principales, también llamadas regiones de tareas o sectores:
1. Planificación. Durante la primera vuelta alrededor de la espiral se
definen los objetivos, las alternativas y las restricciones, 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.[1]
2. Análisis de riesgo. El proyecto se revisa y se toma la decisión de si se
debe continuar con un ciclo posterior de la espiral. Si se decide continuar,
se desarrollan los planes para la siguiente fase del proyecto.
3. Ingeniería. En este sector se desarrolla y se valida. Después de la
evaluación de riesgos, se elige un modelo para el desarrollo del sistema.
4. Evaluación del 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. 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".

9. 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
completas y, al final, el propio sistema operacional.
De acuerdo con Somerville Un ciclo en espiral inicia con la elaboración de
objetivos, como el rendimiento y la funcionalidad. Después se enumeran formas
alternativas de alcanzar estos objetivos y las restricciones impuestas en cada una
de ellas. Cada alternativa se evalúa contra cada objetivo y se identifican las
fuentes de riesgo del proyecto. Lo siguiente es resolver los riesgos mediante
actividades de recopilación de información como la de detallar más el análisis, la
construcción de prototipos y la simulación. Ya que se evaluaron los riesgos, se
lleva a cabo cierto desarrollo, seguido de una actividad de planificación para la
siguiente fase.
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, permitiendo al desarrollador y al cliente entender y
reaccionar a los riesgos en cada nivel. 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.

10. Prototipo 1
Prototipo 2
Prototipo 3
Prototipo
OperativoAnálisis de
riesgo
Análisis de
riesgo
Análisis de
riesgo
AR
Evaluación del
Cliente
Planificación
Ingeniería
Análisis de
Riesgos
Plan de
requisitos,
Plan de
ciclo de v ida
Plan de
desarrollo
Plan de
prueba e
Integración
Concepto de
operación
Simulaciones, Modelos, Estándares
Validación
de
requisitos
Requisitos
de Sof tware
Verif icación
y v alidación
de diseño
Diseño del
producto de
sof tware
Implementación
Prueba de aceptación
Prueba de Integración
Prueba de Unidad
Codif icación
Revisión
Figura 4.2 Modelo de Espiral de Boehm
Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª ed
Diseño detallado

11. Modelo incremental
El modelo incremental aplica secuencias lineales de forma escalonada mientras
avanza el tiempo. Corrige la necesidad de una secuencia no lineal de pasos de
desarrollo. Cada secuencia lineal produce un incremento del software. Por
ejemplo, el software de tratamiento de textos desarrollado con el paradigma
incremental podría extraer funciones de gestión de archivos básicos y de
producción de documentos en el primer incremento; funciones de edición mas
sofisticadas y de producción de documentos en el segundo incremento; corrección
ortográfica y gramatical en el tercero; y una función avanzada de esquema de
pagina en el cuarto. Se debería tener en cuenta que el flujo del proceso de
cualquier incremento pude incorporar el paradigma de construcción de prototipos.
El modelo incremental entrega el software en partes pequeñas, pero utilizables,
llamadas “incrementos”. En general, cada incremento se construye sobre aquel
que ya ha sido entregado.
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un
producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones
suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza
el producto central (o sufre la revisión detalla). Como un resultado de utilización
y/o de evaluación, se desarrolla un plan para el incremento siguiente. El plan
afronta la modificación del producto central a fin de cumplir mejor las necesidades
del cliente y la entrega de funciones, y características adicionales. Este proceso se
repite siguiendo la entrega de cada incremento. Hasta que se elabore el producto
completo.

12. El modelo de proceso incremental, como la construcción de prototipos y otros
enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la
construcción de prototipos, el modelo incremental se centra en la entrega de un
producto operacional con cada incremento. Los primero incrementos son
versiones “incompletas” del producto final, pero proporcionan al usuario la
funcionalidad que precisa y también una plataforma para la evaluación.
El desarrollo incremental es particularmente útil cuando el personal no está
disponible para una implementación completa en la fecha límite que se haya
establecido para el proyecto. Los primeros incrementos se pueden implementar
con menos personas.
Este modelo constituyo un avance sobre el modelo en cascada pero también
presenta problemas. Aunque permite el cambio continuo de requisitos, aún existe
el problema de determinar si los requisitos propuestos son válidos. Los errores en
los requisitos se presentan tarde y su corrección resulta tan costosa como en el
modelo en cascada.
Proceso de desarrollo unificado
Es un modelo complejo con mucha terminología propia, pensado principalmente
para el desarrollo de grandes proyectos. Es un proceso que puede adaptarse y
extenderse en función de las necesidades de cada empresa. Es el resultado de
esfuerzo de las tres últimas décadas en desarrollo de software y de la experiencia
de sus creadores Ivar Jacobson, Grady Booch y James Rumbaugh.
Orígenes

13. El antecedente más importante lo ubicamos en 1967 con la Metodología Ericsson
(Ericsson Approach), ésta es una aproximación de desarrollo basada en
componentes, que introdujo el concepto de caso de uso; entre los años de 1987 a
1995 Jacobson funda la compañía “Objectory AB” y lanza el proceso de desarrollo
Objectory (abreviación de Object Factory), posteriormente en 1995 “Rational
Software Corporation” adquiere “Objectory AB” y es entre 1995 y 1997 que se
desarrolla “Rational Objectory Process (ROP)” fruto del encuentro y evolución de
Objectory 3.8 y la Metodología Rational (Rational Approach) que adopta por
primera vez UML como lenguaje de modelamiento.
A principios de los noventas, la guerra de los métodos hizo evidente la necesidad
de unificar criterios, es así como Grady Booch autor del método Booch y James
Rumbaugh (desarrollador para General Electric) se unieron en Rational en 1994,
después en 1995 se une Jacobson y gracias al esfuerzo de varias compañías y
metodologistas evolucionó UML hasta ser un estándar en 1997, el cual es
adoptado en todos los modelos del ROP. Desde ese entonces y a la cabeza de
Booch, Jacobson y Rumbaugh, Rational ha desarrollado e incorporado diversos
elementos para expandir el ROP, destacándose especialmente el flujo de trabajo
conocido como modelamiento del negocio, es así como en junio del 1998 se lanza
Rational Unified Process 5.0. La evolución y orígenes de este proceso de
desarrollo se pueden visualizar mejor en la figura 2.1
Características del Proceso Unificado de Desarrollo
El Proceso Unificado guía a los equipos de proyecto en cómo administrar el
desarrollo iterativo de un modo controlado mientras se balancean los
requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El

14. proceso describe los diversos pasos involucrados en la captura de los
requerimientos y en el establecimiento de una guía arquitectónica, para diseñar y
probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El
proceso describe qué producto se debe producir, cómo desarrollar lo que vamos a
entregar y también provee patrones. El proceso unificado es soportado por
herramientas que automatizan entre otras cosas, el modelado visual, la
administración de cambios y las pruebas.
El Proceso Unificado está basado en componentes, lo cual quiere decir que el
sistema software en construcción está formado por componentes de software
interconectados a través de interfaces bien definidas. Además, el Proceso
Unificado utiliza el UML para expresar gráficamente todos los esquemas de un
sistema de software. Pero, realmente, las características que definen este Proceso
Unificado son tres: Iterativo e Incremental, Dirigido por casos de uso y Centrado
en la Arquitectura.
Dirigido por casos de uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un
resultado de valor a un usuario. Los casos de uso modelan los requerimientos
funcionales del sistema.
Basándose en los casos de uso, los desarrolladores crean una serie de modelos
de diseño e implementación que llevan a cabo. Además, estos modelos se validan
para que sean conforme a los casos de uso. Finalmente, los casos de uso se usan
para realizar los casos de pruebas sobre los componentes desarrollados. Los
casos de uso no solo inician el proceso, sino que también proporcionan un hilo
conductor en todo el ciclo de vida del desarrollo de software.

15. En conclusión los casos de uso son utilizados para:
 Establecer el comportamiento deseado del sistema
 Verificar y validar la arquitectura del sistema
 Hacer Pruebas
 Tener una comunicación entre los participantes del proyecto
Centrado en la arquitectura
La arquitectura de un sistema software se describe mediante diferentes vistas del
sistema en construcción.
Arquitectura: Conjunto de decisiones significativas acerca de la organización de
un sistema software, la selección de los elementos estructurales a partir de los
cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus
colaboraciones, y su composició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

16. 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). 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.
 Enseguida, 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.

17. Iterativo e incremental
Todo sistema complejo supone un gran esfuerzo que puede durar desde varios
meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias
fases o mini proyectos.
Una iteración es un bucle de desarrollo completo, es una secuencia de
actividades con un plan establecido y criterios de evaluación. Acaba en la edición
de un producto ejecutable, subconjunto del producto final bajo desarrollo.
Se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas
las fases. Cada recorrido por las fases se denomina Iteración en el proyecto en la
que se realizan varios tipos de trabajo (denominados flujos). Cada iteración parte
de la anterior incrementado (crece el producto) o revisando la funcionalidad
implementada. Los desarrolladores basan la selección de lo que implementarán en
cada iteración en dos cosas: el conjunto de casos de uso que amplían la
funcionalidad, y en los riesgos más importantes que deben mitigarse. Las
iteraciones deben estar controladas. Esto significa que deben seleccionarse y
ejecutarse de una forma planificada.
Los beneficios de este enfoque iterativo son:
 La iteración controlada reduce el riesgo a los costos de un solo incremento.
 Reduce el riesgo de retrasos en el calendario atacando los riesgos más
importantes primero.
 Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al
obtener resultados a corto plazo.
 Tiene un enfoque más realista al reconocer que los requisitos no pueden
definirse completamente al principio.

18. Basado en componentes
La creación de sistemas intensivos en software requiere dividir el sistema en
componentes con interfaces bien definidas, que posteriormente serán
ensamblados para generar el sistema. Esta característica en un proceso de
desarrollo, permite que el sistema se vaya creando a medida que se obtienen o
que desarrolles y maduran sus componentes.
Un componente, es una parte del sistema, física y reemplazable, que está sujeto
á, y proporciona la implementación de un conjunto de interfaces.
El desarrollo basado en componentes consiste en la creación e implantación de
sistemas de software complejos, ensamblados a partir de componentes, y que
ponen a la vez nuevos componentes a disposición de otros sistemas. Puede
automatizarse mediante herramientas y procesos, que permiten aumentar la
productividad, calidad y tiempo de desarrollo.
Ciclo de vida
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la
vida de un sistema. Cada ciclo constituye una versión del sistema.
Fases

19. Cada ciclo consta de cuatro fases: inicio, elaboración, construcción, y transición:
 Inicio: Definición del proyecto.
 Elaboración: Planificación del proyecto, especificación de características y
elaborar arquitectura base.
 Construcción: Construcción del sistema.
 Transición: Transición a usuarios
Iteraciones dentro del ciclo de vida. Cada fase se subdivide en iteraciones. En
cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de
trabajos.
4.4.3.2 Disciplinas
Inicio Elaboración Construcción Transición
Tiempo
Visión Arquitectura Capacidad
inicial
Edición
del
producto
Figura 4.3 Fases del Ciclo de Vida
Iv ar Jacobson, “Apply ing UML in The Unif ied Process” [En linea], [Consulta:Enero de 2006],
Inicio Elaboración Construcción Transición
Tiempo
Visión Arquitectura Capacidad
inicial
Edición
del
producto
Iteración
Preliminar
Iteración
Arquitectura
Iteración
Desarrollo
Iteración
Desarrollo
Iteración
Transición
… … … …
Figura 4.4 Iteraciones y fases
Iv ar Jacobson, “Apply ing UML in The Unif ied Process” [En linea], [Consulta:Enero de 2006],

20. Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo)
vinculadas a un área específica dentro del proyecto total. Las más importantes
son: Requerimientos, Análisis, Diseño, Codificación, y Prueba.
El agrupamiento de actividades en disciplinas es principalmente una ayuda para
comprender el proyecto desde la visión tradicional en cascada.
Cada disciplina está asociada con un conjunto de modelos que se desarrollan.
Estos modelos están compuestos por artefactos. Los artefactos más importantes
son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de
diseño, modelo de implementación, y modelo de prueba.
El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que
van desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan
modelos desde el modelo de casos de uso hasta el modelo de pruebas.
Hitos
Cada fase finaliza con un hito. Cada hito se determina por la disponibilidad de un
conjunto de artefactos (RUP llama artefactos a un subproducto), es decir un
conjunto de modelos o documentos que han sido desarrollados hasta alcanzar un
estado predefinido.
Los hitos tienen muchos objetivos. El más crítico es que los encargados del
proyecto deben tomar ciertas decisiones antes de que el trabajo continúe con la
siguiente fase. Los hitos también permiten controlar la dirección y progreso del
trabajo. Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo

21. y esfuerzo consumidos en cada fase. Estos datos son útiles para la estimación en
futuros proyectos.
Artefactos
Dentro del Proceso de Desarrollo Unificado se denomina artefacto a todo producto
o subproducto resultante del proceso. Dentro de esto se encuentra desde el propio
código fuente hasta la documentación aportada por el cliente y la entregada al
completarse cada hito dentro del proyecto. Para su mejor comprensión hemos
agrupado todos los artefactos posibles del proceso en tres grandes grupos:
Artefactos entregados por el cliente, Artefactos internos del proceso y Artefactos
entregables al cliente.
No siempre en todo proyecto se crean los mismos artefactos, esto dependerá de
las características del proyecto y los requisitos del cliente, siendo tarea de la
gestión de la configuración el definir qué artefactos específicos y con qué nivel de
formalidad se crearán para el proyecto en cuestión.
Artefactos entregados por el cliente
 Glosario de Términos: Sólo existe uno para todo el sistema, que contiene
un conjunto de definiciones concisas para favorecer la comunicación y
evitar malos entendidos entre todos los involucrados. Los miembros del
proyecto utilizarán el glosario inicialmente para comprender sus términos
específicos.

22.  Especificaciones de los casos de uso: Es una colección de documentos
que recogen la especificación completa de cada caso de uso. Cada uno
contiene los campos: nombre, descripción, actores, precondiciones, pos
condiciones, flujo básico, flujos alternativos, puntos de extensión, entre
otros que describen en detalle un caso de uso.
 Modelo de casos de uso: Es un modelo de las funciones concebidas del
sistema y su entorno. Es una entrada importante a actividades de análisis,
diseño y prueba. Incluye todos los actores y casos de uso del sistema con
sus descripciones. Puede ser entregado directamente en el formato que
utilice la herramienta de modelación o gestión empleada, o mediante un
informe de este modelo que contenga toda esta información que se
complementará con las Especificaciones de los casos de uso.
 Especificaciones suplementarias: Este artefacto captura los
requerimientos del sistema que no fueron recogidos en el Modelo de casos
de uso. Generalmente contiene los requerimientos no funcionales del
sistema.
 Especificación de requisitos del software: En los casos en que la
empresa cliente no desee utilizar el enfoque de casos de uso para la
gestión de requisitos, podrá entregar en lugar de los 3 artefactos descritos
anteriormente un solo documento que recoja las características, requisitos
funcionales y no funcionales del sistema, así como otra información útil
como por ejemplo: restricciones en el diseño e implementación,
componentes comprados a terceros, interfaces de hardware o software, etc.
 Documento de arquitectura del software: Este documento brinda un
resumen de la arquitectura utilizando varias vistas diferentes que muestran
distintos aspectos del sistema. Es un medio de comunicación entre el
arquitecto de software y otros miembros del equipo del proyecto, acerca de
las decisiones significativas que han sido tomadas para la arquitectura.
 Modelo de diseño: Es una abstracción de la implementación del sistema
que normalmente se utiliza para concebir y documentar su diseño. Es un
artefacto compuesto que contiene todas las clases, subsistemas, paquetes,

23. colaboraciones y las relaciones entre ellas. También contiene las
realizaciones de los casos de uso.
 Modelo de datos: Describe la representación física y lógica de los datos
persistentes utilizados por la aplicación. Se utilizará siempre que se
necesiten manejar datos persistentes. Usualmente describirá los diferentes
elementos componentes de la estructura de una base de datos relacional.
 Mapa de navegación: Expresa la estructura de los elementos de la interfaz
de usuario del sistema, junto a los caminos de navegación principales.
Existirá solamente uno de estos artefactos en el sistema y por lo general
será empleado para aplicaciones Web.
 Prototipo de la interfaz de usuario: Es un ejemplo de la interfaz de
usuario que se construye para validar y/o explorar su diseño. El grado de
formalidad y herramientas utilizadas para generarlo puede variar mucho de
proyecto en proyecto, pudiendo ir desde solo unas cuantas imágenes de
pantallas hasta un esqueleto de interfaz de usuario ejecutable producido en
un ambiente de Desarrollo rápido de aplicaciones (RAD : Rapid Application
Development) o un conjunto de páginas HTML interactivas. En aplicaciones
Web pueden ser las imágenes de las diferentes pantallas creadas por el
diseñador gráfico.
Artefactos Internos del Proceso
 Plan de gestión de requisitos: Describe los artefactos de la disciplina,
tipos de requisitos y sus respectivos atributos. Especifica la información que
deberá ser obtenida y los mecanismos de control que deberán ser utilizados
para reportar, medir, y controlar los cambios a los requisitos del producto.
 Plan de pruebas: Contiene la definición de los objetivos de las pruebas, los
elementos que deberán ser probados, los métodos que deberán utilizarse,
los recursos necesarios y documentos a entregar. Usualmente se tiene uno

24. de estos documentos con alcance global para todo el proyecto y uno por
cada iteración del ciclo de vida del producto.
 Guion de pruebas: Son las instrucciones paso a paso que indican como
llevar a cabo una prueba. Pueden ser documentos con información textual
que describa cómo realizar la prueba manualmente o archivos de
instrucciones legibles por las máquinas que posibiliten la ejecución
automatizada de la prueba.
 Informe resumen de las pruebas: Organiza y muestra un análisis
resumido de los resultados de las pruebas que será entregado a los
miembros del equipo de calidad para su revisión y evaluación.
Adicionalmente puede contener un enunciado general de la calidad relativa
y ofrecer recomendaciones para futuros esfuerzos de prueba.
 Plan de gestión de configuración: Describe todas las actividades de
Gestión de configuración y cambios que serán realizadas durante todo el
ciclo de vida del proyecto. Brinda planificaciones detalladas de las
actividades, responsabilidades asignadas, recursos necesarios que
incluyen personal, herramientas y equipamiento.
 Solicitud de cambio: Los cambios a los artefactos del proyecto se
proponen mediante Solicitudes de cambio (Change Requests CR). Estos se
utilizan para documentar y controlar defectos, solicitudes de mejoras o
cualquier otra solicitud de cambios al proyecto. El beneficio de utilizarlos es
que proporcionan un registro de las decisiones y, debido a su proceso
evaluativo, se asegura que los impactos de los cambios sean entendidos
por todos los miembros del equipo del proyecto.
 Plan de desarrollo de software: Es un artefacto compuesto que recoge
toda la información necesaria para llevar a cabo la dirección del proyecto.
Contiene otros planes no menos importantes que, al igual que éste son
desarrollados desde la fase de inicio y mantenidos durante todo el ciclo de
vida (Aseguramiento de la calidad, Gestión de riesgos, Métricas, Aceptación
del producto y Resolución de problemas).

25.  Plan de la iteración: Es un plan más refinado que contiene un conjunto
secuencial de actividades, tareas y recursos asignados a una iteración, por
lo que existirá un artefacto de este tipo por cada iteración del ciclo de vida
del producto. Incluye los objetivos de la iteración, que son utilizados como
criterio de evaluación y miden diferentes aspectos deseables a su final,
como grado de terminación de la funcionalidad planificada, niveles de
calidad, rendimiento, etc.
 Evaluación de la iteración: Se realiza al final de la iteración y captura el
grado en que se cumplió el criterio de evaluación, las lecciones aprendidas
y los cambios a realizar en la planificación de las subsiguientes iteraciones
en función del nuevo conocimiento adquirido. Es un artefacto esencial del
enfoque iterativo de desarrollo de software.
 Proceso de desarrollo: También conocido como Proceso específico del
proyecto, es una configuración del Proceso Unificado de Rational (RUP)
para ajustarse a las necesidades del proyecto. Es un artefacto compuesto
que contiene: el Caso de desarrollo, plantillas y normativas para el
proyecto.
Artefactos entregables al cliente
 Modelo de implementación: Representa la composición física de la
implementación, está constituido por subsistemas y elementos de
implementación (directorios y ficheros, incluyendo los de código fuente,
datos y ejecutables).
 Informe de entrega al cliente: Contendrá una descripción detallada de la
estructura de directorios del paquete entregado, instrucciones para la
instalación, errores conocidos y cambios realizados en la versión actual del
sistema, subsistema o componente implementado. Adicionalmente incluirá
cualquier otra información que sea considerada relevante referida al modelo
de implementación o los artefactos contenidos en la entrega al cliente.

26.  Documentación de soporte: En función de las características del
proyecto, se entregará también la documentación técnica del sistema,
subsistema o componente de software implementado, que podrá ser usada
posteriormente para su mantenimiento o modificación por parte de otro
equipo de desarrollo. Adicionalmente serán entregados los manuales
necesarios para el soporte al usuario final.
Conclusión
El desarrollo del software y la programación es uno de los pilares fundamentales
de la informática y al cual se dedican muchas horas de esfuerzos en empresas, y
universidades.
Conforme a la tecnología va avanzando, van apareciendo nuevas soluciones,
nuevas formas de programación, nuevos lenguajes y un sin fin de herramientas
que intentan realizar el trabajo del desarrollador un poco más fácil.
La programación orientadas a objetos o los compiladores basados en máquinas
virtuales (en muchos casos, multiplataforma), también a sus puestos unas
renovación en la manera de programar.
Microsoft como empresa desarrolladora de software, es consciente de lo
importante que es hacer buenos desarrollos y lo complicado que es; por eso,
intenta aportar las mejores soluciones al mercado. En la actualidad la sociedad se
encuentra en una época de transición, que se encamina hacia un nuevo estilo de
programación basada en estándares y para ello Microsoft propone la plataforma
.NET.
REFERENCIAS WEB
Nelson Medinilla Martínez, Facultad de Informática, Universidad Politécnica de Madrid, “Análisis y selección de
estrategias de desarrollo de softw are” [En línea], Madrid España [Consulta: Mayo de 2006],
<http://is.ls.fi.upm.es/udis/docencia/proyecto/docs/
estrategias.pdf>
Carolina Zibert, “Ciclos de vida de Ingeniería de Softw are” [En línea], Caracas Venezuela [Consulta: Abril de
2006],<carolina.terna.net/ingsw 2/Datos/Cascada-ModeloV.doc>
Tesis doctorales en Zarza, “Ingeniería de Softw are” [En línea], España [Consulta: Mayo de 2006],
<http://w w w .tdx.cesca.es/TESIS_UPC/AVAILABLE/TDX-0716102-102210//05Capitulo05.pdf>
Mundo Geek, “Ciclos de vida del softw are” [En línea], [Consulta: Mayo de 2006],
<http://mundogeek.net/archivos/2004/05/20>
Wikipedia Foundation Inc, EUA Desarrollo en Cascada [En línea], St. Petersburg [Consulta: Mayo de 2006],
<http://es.w ikipedia.org/w iki/Modelo_en_cascada>
Instituto Tecnológico de la paz, “Análisis y diseño de sistemas Modelo de Espiral” [En línea], México [Consulta: Mayo
de 2006], <http://w w w .itlp.edu.mx/publica/tutoriales/
analisis/index.htm>