Sdf p4

4. Modelos de Proceso del Software
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.
Aun 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 [4]
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
quiere y después, cuando se conozca todo lo que se quiere, empezar a
construirlo.
140
Modelos de proceso de software

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:
141
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 vida de Ingeniería de Software” [En línea], Caracas Venezuela [Consulta: Abril
de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc>

Instituto Tecnológico de Morelia
4.1.1 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). [4]
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. [4]
142

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. [4]
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. [4]
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. [4]
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
143

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 este 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.
4.2 Modelo de espiral
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
mas completas del sistema diseñado.
144

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. [1]
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.
[1]
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".[1]
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 Sommerville 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
145

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.
146
Análisis de
Riesgos
Codificación
Prueba de Unidad
Análisis de
riesgo
Análisis de
riesgo
Prototipo 2
Prototipo 1
Prototipo 3
Prototipo
Análisis de Operativo
riesgo
AR
Planificación
Evaluación del
Cliente
Ingeniería
Plan de
requisitos,
Plan de
ciclo de vida
Plan de
desarrollo
Plan de
prueba e
Integración
Concepto de
operación
Simulaciones, Modelos, Estándares
Validación
de
requisitos
Requisitos
de Software
Verificación
y validación
de diseño
Diseño del
producto de
software
Prueba de aceptación
Implementación
Prueba de Integració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

4.3 Modelo incremental [2]
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. [2]
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.
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
147

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 esta
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, aun existe
el problema de determinar si los requisitos propuestos son validos. Los errores en
los requisitos se presentan tarde y su corrección resulta tan costosa como en el
modelo en cascada.
4.4 Proceso de desarrollo unificado [18]
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.
4.4.1 Orígenes
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
148

Objectory 3.8 y la Metodología Rational (Rational Approach) que adopta por
primera vez UML como lenguaje de modelamiento. [16]
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 puede visualizar mejor en la figura 2.1 [16]
4.4.2 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
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
149

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.
4.4.2.1 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. [17]
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.
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
4.4.2.2 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
150

cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus
colaboraciones, y su composición. [17]
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 mas
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.
151

4.4.2.3 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.
4.4.2.4 Basado en componentes
152

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 se desarrolla 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.
4.4.3 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.
4.4.3.1 Fases
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
153

Inicio Elaboración Construcción Transición
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
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
154
Tiempo
Visión Arquitectura Capacidad
inicial
Edición
del
producto
Figura 4.3 Fases del Ciclo de Vida
Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de 2006],
<http://www.jeckle.de/files/uniproc.pdf>
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
Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de 2006],
<http://www.jeckle.de/files/uniproc.pdf>

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.
4.4.3.3 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
y esfuerzo consumidos en cada fase. Estos datos son útiles para la estimación en
futuros proyectos.
4.4.3.4 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.
155

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.
4.4.3.4.1 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.
· 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,
postcondiciones, 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
156

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, interfases 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,
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
157

Web pueden ser las imágenes de las diferentes pantallas creadas por el
diseñador gráfico.
4.4.3.4.2 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
de estos documentos con alcance global para todo el proyecto y uno por
cada iteración del ciclo de vida del producto.
· Guión 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.
158

· 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).
· 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.
159

4.4.3.4.3 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.
· 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.
160

Flujos de Trabajo de proceso
Flujos de Trabajo de soporte
4.4.3.5 Inicio
Su meta principal es lograr el consenso de todos los involucrados acerca de los
objetivos del ciclo de vida del proyecto. Es muy importante especialmente en
proyectos nuevos en que existen riesgos significativos en el negocio o la
implementación de los requisitos, y deben ser solucionados para que el proyecto
proceda.
Para los proyectos que se enfocan en mejorar sistemas existentes, esta fase es
más breve, pero aún así centrada en asegurar que el proyecto vale la pena y se
puede realizar.
161
Modelo de negocio
Requisitos
Análisis y Diseño
Implementación
Pruebas
Implantación
Gestión de Configuración
Gestión
Entorno
Iteraciones
preliminares
Iter
#1
Iter
#n
Iter
#n+1
Iter
#n+2
Iter
#m
Iter
#m+1
Iter
#2
Figura 4.5 Estructura del Proceso Unificado
Juan Pavón Maestras, Universidad Complutense de Madrid, “El proceso unificado” [En línea], Madrid España [Consulta:
Abril de 2006], <http://www.fdi.ucm.es/profesor/jpavon/is2/03ProcesoUnificado.pdf>

Objetivos
· Establecer el alcance y fronteras del software del proyecto, incluyendo la
visión operacional, criterio de aceptación, qué se espera que esté en el
producto y qué no.
· Discriminar los casos de uso críticos del sistema, los escenarios primarios
de operación que dirigirán las principales decisiones de diseño.
· Mostrar al menos una arquitectura candidata para alguno de los escenarios
primarios.
· Estimar el costo global y planificación para el proyecto completo
(estimaciones más precisas se obtendrán en la fase siguiente).
· Estimar los riesgos potenciales.
· Preparar el ambiente de soporte al proyecto
Actividades
· Formular el alcance del proyecto.
· Planificar y preparar el caso de negocio.
· Sintetizar una arquitectura candidata.
· Preparar el ambiente del proyecto: evaluar el proyecto y la organización,
seleccionar las herramientas, decidir qué partes del proceso mejorar.
Hito
Establecer el ámbito del producto, la identificación de los principales riesgos y la
viabilidad del proyecto.
4.4.3.6 Elaboración
162

El propósito de la etapa de Elaboración es crear la línea base de la arquitectura
del software para así disponer de unos cimientos sólidos sobre los que se basará
el grueso del esfuerzo de diseño e implementación durante la siguiente fase de
Construcción. En la definición de la línea base de la arquitectura se incluyen los
requisitos más significativos (aquéllos que tienen un mayor impacto sobre la
arquitectura del sistema), y los componentes de mayor riesgo para el sistema.
Para evaluar la estabilidad de la arquitectura se emplean prototipos evolutivos de
la arquitectura.
Objetivos
· Asegurar que la arquitectura, requisitos y planes son lo suficientemente
estables y los riesgos han sido mitigados lo suficiente para poder
determinar los costos y planificación necesarios para completar el
desarrollo.
· Solucionar todos los riesgos significativos para la arquitectura del proyecto.
· Establecer la línea base de la arquitectura obtenida después de tratar los
escenarios más significativos para la arquitectura, que por lo general
muestra los mayores riesgos técnicos del proyecto.
· Producir un prototipo progresivo de componentes con calidad para la
producción, así como también algunos prototipos desechables exploratorios
donde se mitigan riesgos específicos, como por ejemplo: Soluciones de
compromiso en el diseño, reutilización de componentes, factibilidad del
producto, o demostraciones a inversores, clientes y usuarios finales
· Demostrar que la arquitectura incluida en la línea base respaldará los
requisitos del sistema a un costo y tiempo razonables.
· Establecer el ambiente de soporte para el proyecto. Esto incluye crear los
planes de desarrollo, preparar las plantillas de los documentos,
instrucciones, y herramientas
Actividades
163

· Definir, validar y añadir la arquitectura a la línea base.
· Refinar la Visión basándose en información nueva obtenida durante la fase.
· Crear y añadir a la línea base planes de iteración detallados para la fase de
construcción.
· Refinar los planes de desarrollo y ponerlos en práctica en el ambiente de
desarrollo.
· Refinar la arquitectura y seleccionar componentes.
Hito
Obtener una línea base de la arquitectura del sistema, capturar la mayoría de los
requisitos y reducir los riesgos principales así como permitir la escalabilidad del
equipo del proyecto durante la fase de construcción.
4.4.3.7 Construcción
En esta fase se documentan los requisitos restantes y se completa el desarrollo
del sistema basándose en la arquitectura que se ha sido añadida a la línea base.
La Construcción es un proceso de fabricación donde se hace énfasis en la
administración de los recursos y el control de operaciones para optimizar costos,
el tiempo dedicado, y la calidad del producto. En este sentido la administración
experimenta una transición del desarrollo de propiedad intelectual durante las
fases de Inicio y Elaboración, al desarrollo de productos instalables durante la
Construcción y Transición.
Objetivos
164

· Minimizar los costos de desarrollo optimizando los recursos y evitando
cambios innecesarios que resulten en desechar o modificar trabajo ya
realizado.
· Obtener una calidad apropiada tan rápido como sea posible.
· Obtener versiones útiles (alfa, beta, y otras entregas de prueba) tan rápido
como sea posible.
· Completar el análisis, diseño, desarrollo y prueba de toda la funcionalidad
requerida.
· Desarrollar de forma iterativa e incremental un producto completo que esté
listo para su transición hacia la comunidad de usuarios. Esto implica detallar
los casos de uso restantes y otros requisitos así como completar el diseño,
implementación y prueba del software.
· Decidir si el software, sitio y usuarios están listos para la instalación de la
aplicación.
· Alcanzar algún grado de paralelismo en el trabajo de los equipos. Hasta en
los proyectos más pequeños existen componentes que pueden ser
desarrollados de forma independiente entre ellos, permitiendo un
paralelismo natural entre los equipos. Este paralelismo puede acelerar
significativamente el desarrollo de actividades.
Actividades
· Administración de recursos, control y optimización del proceso.
· Desarrollo y prueba completa de los componentes utilizando el criterio de
evaluación definido.
· Evaluación de las entregas del producto utilizando los criterios de
aceptación de la Visión.
Hito
165

Podemos decir que se alcanza el hito principal de la fase cuando hemos
conseguido desarrollar el sistema con calidad de producción, y puede entonces
prepararse para la entrega al equipo de transición. En esta fase, toda la
funcionalidad ha sido implementada, y completadas las pruebas para el estado
alfa de la aplicación.
4.4.3.8 Transición
En esta fase la atención se enfoca en asegurar que el software está disponible
para los usuarios finales. Puede extenderse a varias iteraciones, e incluye las
pruebas del producto como parte de su preparación para ser entregado, y la
realización de ajustes menores en respuesta a la retroalimentación recibida de los
usuarios. En este punto del ciclo de vida la retroalimentación de los usuarios debe
enfocarse fundamentalmente a ajustes específicos y de corto alcance al producto,
junto a otros temas como configuración, instalación, y usabilidad. Referencias a
otros ajustes estructurales mayores habrán sido solucionadas anteriormente en el
ciclo de vida y serán documentadas para futuras generaciones del software.
Al final de la fase de Transición los objetivos del ciclo de vida se han cumplido, y el
proyecto está listo para cerrarse. En algunos casos el final de este ciclo coincide
con el inicio de otro ciclo en el mismo proyecto, encaminándose a la siguiente
generación o versión del producto. Para otros proyectos el final de esta fase puede
coincidir con la entrega completa de los productos (aplicaciones) y subproductos
(documentación) a terceros que pudieran ser responsables de la operación,
mantenimientos, y mejoras al sistema entregado. Esta fase de transición puede
variar de muy sencilla a extremadamente compleja, dependiendo del tipo de
producto.
Esta etapa comienza cuando la línea base está lo suficientemente madura como
para realizar una entrega al dominio de los usuarios finales. Esto por lo general
requiere que se haya completado un subconjunto usable del sistema con un nivel
166

de calidad aceptable y documentación de usuario de modo que la transición
produzca resultados positivos para todas las partes.
Objetivos
· Realizar pruebas de estadio beta para validar el nuevo sistema con las
expectativas de los usuarios.
· Realizar pruebas de estadio beta y la operación en paralelo al sistema
anterior que se está reemplazando.
· Entrenamiento de usuarios y encargados del mantenimiento.
· Salida a comerciales, distribución y ventas.
· Ingeniería específica de instalación: comercialización y producción de los
paquetes, etc.
· Actividades de corrección de errores, mejoras en el funcionamiento y
rendimiento y usabilidad.
· Evaluación de la línea base de la instalación con la visión completa y
criterios de la aceptación del producto.
· Lograr el consenso de los involucrados en que la línea base está completa.
· Lograr el consenso de los involucrados en que la línea base es consistente
con el criterio de evaluación de la visión.
Actividades
· Ejecutar los planes de instalación.
· Completar el material de soporte de los usuarios finales.
· Pruebas del producto en el sitio de desarrollo.
· Preparar la entrega de esta versión del producto.
· Recoger la retroalimentación de los usuarios.
· Hacer ajustes finos al producto basándose en la retroalimentación de los
usuarios.
167

· Hacer disponible el producto para los usuarios finales.
Hito
Al finalizar esta fase se decide si los objetivos se cumplieron y si debe comenzarse
otro ciclo de desarrollo. Es el resultado de la revisión y aceptación por parte del
cliente de los productos y subproductos que le han sido entregados.
4.5 Proceso Software Personal.
El Proceso Personal del Software (PSP) es un sistema estructurado de
descripciones, de medidas, y de los métodos de proceso que pueden ayudar a
ingenieros a mejorar su actividad personal.
El PSP fue definido por Watts S. Humphrey del Software Engineering Institute
(SEI) en la Carnegie Mellon University.
4.5.1 Principios del Proceso de Software Personal [15]
· Cada ingeniero es diferente; para ser más eficiente, debe planificar su
trabajo basándose en datos tomados de su propia trayectoria profesional.
· Para mejorar auténticamente su trabajo, los ingenieros deben usar
procesos personales bien definidos y cuantificados.
· Para obtener productos de calidad, el ingeniero debe asumir la
responsabilidad personal de la calidad de sus productos. Los buenos
productos no se obtienen por azar, sino como son secuencia de un
esfuerzo positivo para hacer un trabajo de calidad.
· Cuanto antes se detecten y corrijan los defectos menos esfuerzo será
necesario.
· Es mas efectivo evitar los defectos que detectarlos y corregirlos.
· Trabajar bien es siempre la forma más rápida y económica de trabajar.
168

El PSP Cubre los siguientes aspectos como:
· Definición de procesos
· Medida de la calidad
· Medida de la productividad.
Es un acercamiento general que se puede utilizar en casi cualquier parte del
proceso del software.
El costo personal de un PSP, es el tiempo que se requiere para aprender y para
usarlo, el costo emocional de tener una disciplina necesaria y el riesgo potencial a
su ego.
Los beneficios del PSP:
· Habilidades y talentos obtenidos
· El estímulo de una corriente casi ilimitada de ideas
· El marco que proporciona para la mejora personal
· El grado de control se gana sobre el trabajo
· La sensación del orgullo y de la realización
· Una base mejorada para el trabajo en equipo eficaz
· La seguridad para hacer el trabajo la manera que usted sabe que usted
debe.
169

170
PSP2.1
Diseño de plantillas
Planeación de Tareas
Planeación de horarios
Revisión de código
Revisión de diseño
PSP0
Proceso actual
Tiempo de registro
Registro de fallas
Estándar de fallas
PSP1
PSP2
Estimación de tamaño
Reporte de pruebas
PSP3
Desarrollo cíclico
PSP0.1
PSP1.1
Codificación estándar
Medida del tamaño
Mejora del proceso
Figura 4.6 Evolución de PSP
Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland EUA [Consulta: Mayo
de 2006] <http://www.csee.umbc.edu/~mikeg/cmsc645/se_psp.pdf>

4.5.2 PSP0 Línea Base [15]
Establece una línea de medida del progreso y para definir un fundamento para
mejorar.
EL PSP0 provee una estructura muy conveniente para hacer tareas a pequeña
escala, un marco de trabajo para medir las tareas y un fundamento de mejora del
proceso
Las tareas incluyen lo siguiente:
· Definición del proceso actual (PSP0).
· Tiempo de registro (PSP0).
· Registro de falla (PSP0).
· Registro de falla estándar (PSP0).
· Codificación estándar (PSP0.1).
· Medida del tamaño (PSP0.1).
· Mejora del proceso (PSP0.1).
171

4.5.2.1 PSP0 Proceso Actual [15]
Se debe identificar el proceso actual del desarrollo de software. En caso de que no
se tenga un proceso regular se puede utilizar el siguiente:
· Diseño, Codificación, Compilación, Prueba
El proceso incluye las siguientes tareas:
· Planeación (Produce un Plan de trabajo).
· Desarrollo (Desarrollo del software actual).
· Post ejecución (Comparación del funcionamiento actual con el plan
de trabajo).
4.5.2.2 PSP0 Tiempo de Registro [15]
172
Planeación
Diseño
Código
Compilación
Pruebas
Post-ejecución
Scripts Registros
Resumen
del plan
Requerimientos
Producto terminado
Figura 4.7 Flujo del proceso
Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland
EUA [Consulta: Mayo de 2006] <http://www.csee.umbc.edu/~mikeg/cmsc645/se_psp.pdf>

· El tiempo de registro se usa para medir el tiempo que se lleva en cada
parte del proceso PSP.
· El objetivo es determinar donde se invierte más tiempo.
· Ser bastante minucioso con los datos (probablemente hasta minutos)
El tiempo de registro incluye:
· Fecha de entrada
· Hora de Inicio
· Hora de fin
· Estimación de tiempo de interrupción para esta entrada
· Tiempo delta (el tiempo en el que se trabaja para esta entrada)
· Fase en la que se esta trabajando
· Comentarios pertinentes
4.5.2.3 PSP0 Registro de fallas [15]
El registro de una falla se usa para tener los defectos encontrados y corregidos. El
objetivo de esto es determinar donde se pierde mucho tiempo y ser lo mas
minucioso posible con los datos.
El registro de fallas debe incluir lo siguiente:
· Fecha de la falla encontrada
· Numero de falla
· Tipo de falla (Documentación, sintaxis, asignación, interfase, etc.…)
· Fase donde se inicio la falla
· Fase donde la falla se elimino
· Tiempo que se llevo para reparar la falla
· Descripción del porque de la falla
173

4.5.2.4 PSP0 Estándar de fallas [15]
Estos pueden se algunas de las fallas que se registran y que se pueden tomar
como un estándar:
No Nombre o descripción
10 Comentario de documentación, mensajes
20 Deletreo de sintaxis, puntuación, formato
30
Construcción, Manejo de cambio de paquete, librería, control de
versión
40
Declaración de asignación, duplicado de nombres, alcance,
limitaciones
50
Procedimiento de la Interfaz, llamadas, referencias, I/O, formato
de usuario
60 Chequeo de mensajes de error
70 Estructura de datos, contenido
80 Función de conexión, enlace, recursividad,
90 Configuración de sistema, sincronización, memoria
100
Diseño del entorno, compilación, prueba, otro sistema de soporte
de problemas
El resumen del plan guarda y estima los datos del proyecto actual, el cual debería
de contener lo siguiente:
· Estimación original de LOC(“Lines Of Code”, Líneas de código) que
se estima se van a desarrollar.
· Líneas de código que se llevan en desarrollo hasta ese momento.
· El tiempo estimado que es requerido para cada fase.
· El tiempo que se requiere para cada fase.
· El numero total y el porcentaje de fallos que se han provocado en
cada fase.
· El numero total y el porcentaje que se han eliminado en cada fase.
4.5.2.5 PSP0.1 Codificación estándar [15]
Desarrollo de la codificación estándar para lo siguiente:
· Cabecera
174
Tabla 4.1 Estanda de fallas
Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland EUA
[Consulta: Mayo de 2006] <http://www.csee.umbc.edu/~mikeg/cmsc645/se_psp.pdf>

· Uso/ reuso
· Identificadores
· Comentarios
· Sección mas importante
· Espacios en blanco
· Identidad
· Capitalización
Dentro de este estándar se pueden incluir definiciones y ejemplos.
4.5.2.6 PSP0.1 Medida del tamaño [15]
Durante la planeación del proceso de software, incluye la estimación del tamaño
del trabajo así como las líneas de código.
El desarrollo del estándar tiene pequeños problemas con lo siguiente:
· Modificación o eliminación de líneas.
· Comentarios o líneas en blanco.
· Líneas con múltiples declaraciones.
· Declaraciones nulas o vacías.
· Incluir archivos (agregados una vez o varias veces).
· Funciones de línea o expansión de marcos.
· Declaraciones
· Etiquetas
· Símbolos como llaves “{ }” , begin/ end, else, case….
4.5.2.7 PSP0.1 Mejora del proceso [15]
175

La mejora del proceso provee un registro de fallas problemas e ideas de mejora.
Puede contener lo siguiente:
· Descripción de la falla encontrada dentro del proyecto
· Numero del problema
· Descripción y las dificultades
· Descripción del impacto que tiene el producto o el proceso con la
falla o problema.
· Descripción de las sugerencias para mejorar el proceso.
· Numeración de cada una de las sugerencias.
· Identificación de los elementos del proceso que son afectados.
· Cuando será apropiado, relacionar las sugerencias de mejor para
el problema.
· Dar prioridades a las sugerencias y explicar porque son
importantes.
· Agregar comentarios sobre el proyecto.
· Lección aprendida
· Condiciones que es necesario recordar para determinar el porque
funciona bien el proceso o el porqué es deficiente.
4.5.2.8 PSP0 Documentación del proceso [15]
En esta parte se debe tener documentada la planeación el desarrollo y el post
ejecución del proceso. En seguida se describe que es lo que debe contener cada
uno de ellos.
Planeación:
· Producir u obtener los requerimientos de las declaraciones.
· Estimación de nuevos totales como los cambios en las líneas de
código requeridos en PSP0.1.
· Estimación del tiempo requerido para el desarrollo.
176

· Registrar el inicio del proyecto en el resumen del plan del proyecto.
· Registrar la fecha del proyecto.
Desarrollo:
· Diseño, implementación, compilación, prueba.(PSP0.1)
· Registrar el tiempo.
Post-ejecución:
· Completar el resumen del plan del proyecto, con el tiempo actual,
fallas, tamaño de los datos.
· Terminar el mejoramiento del proceso.
4.5.3 PSP1 Planeación Personal del Proceso [15]
El PSP1 estima el tamaño del software, hace una prueba de reporte del PSP.
Adicionalmente contribuye a PSP1 estimar los recursos y el horario.
El PSP1 intenta establecer el proceso de forma ordenada y repetida para
desarrollar el software usando el tamaño, recursos y horarios estimados.
El proceso de valoración llega a ser progresivamente más exacto conforme los
datos se recopilan de varios proyectos.
Las tareas que se incluyen del PSP0 y PSP0.1 agregan lo siguiente:
· Estimación de tamaño.
· Reporte de prueba.
· Planeación de tareas
· Planeación del horario
4.5.3.1 PSP1 Estimación de tamaño [15]
177

Las siguientes disciplinas se usan para estimar las líneas de código. Se debe
tener el tamaño de los datos sobre un número de proyectos previamente
desarrollados para poder establecer estimaciones iniciales.
Método PROBE (Proxy-Based Estimating), Descrito en la disciplina para la
Ingeniería de Software.
Puntos de Función:
· Ali Arifoglu. Metodología de software para la estimación de costos
ACM Sigsoft Software Engineering.
· COCOMO Model (Constructive Cost Model) es el modelo
constructivo de costos. Este modelo es para la estimación de
líneas de código.
4.5.3.2 PSP1 Reporte de pruebas [15]
El reporte de pruebas se usa para mantener un registro de pruebas de ejecución y
resultados obtenidos. Estos pueden ser tan detallados como se desee, con esto se
puede hacer la misma prueba y obtener los mismos resultados. El reporte incluye
lo siguiente:
· Nombre y numero de prueba
· Objetivo de la prueba
· Descripción de la prueba
· Condiciones de tiempo o configuración especial
· Resultados esperados
· Resultado actual
4.5.3.3 PSP1.1 Planeación de Tareas [15]
178

La planeación de las tareas implica estimar el tiempo de desarrollo y de los datos
de la terminación para cada tarea del proyecto. Este también proporciona una
base según el horario que se sigue. El plan debe contener lo siguiente:
· Nombre y número de la tarea.
· Planeación de hora de acuerdo a la tarea por semana, y para el
proyecto.
· Tiempo actual por tarea por semana, y ara el proyecto.
4.5.3.4 PSP1.1 Planeación de horarios [15]
El horario se usa para recordar el horario actual y empleado en el calendario por
periodo. Se usa para relacionar tareas previstas con el horario según el
calendario. Las siguientes semanas se usan para pequeños proyectos, y puede
que sea mejor hacer mayor esfuerzo por día.
El horario puede contener lo siguiente:
· Numero de cada semana, típicamente empezando en 1.
· Fechad de calendario para cada semana.
· Planeación prevista para el trabajo en el proyecto por semana.
· Horas previstas acumuladas.
· Horas reales que se invierten en el proyecto por semana.
· Horas reales acumuladas.
4.5.3.5 PSP1 Documentación del proceso [15]
Planeación
· Produce u obtiene la declaración de los requisitos.
· Estimación del tamaño del software, tiempo del desarrollo requerido
(PSP1).
· Plan completo de tareas.
179

· Horario completo del plan (PSP1.1).
· Incorporación de los datos iniciales en el resumen del plan de proyecto.
· Registro de tiempo y datos iniciales.
Desarrollo
· Diseño, Implementación, compilación, prueba.
· Recolectar los datos del reporte de prueba (PSP1).
· Recolectar los registros de los datos.
Post-ejecución
· Resumen del plan del proyecto completo con el tiempo real, fallas, tamaño
de los datos.
· Completar la mejora del proceso.
4.5.4 PSP2 Calidad personal [15]
El proceso PSP2 introduce revisiones de diseño, código a la medida y medición de
la calidad.
Este tipo de revisiones mejoran la calidad del software más que otro cambio
personal que se haga en el proceso del software. Introduce también criterios y
verificación de diseño completos.
Se incluyen tareas de PSP1 y de PSP1.1 más las siguientes:
· Revisión de código (PSP2).
· Revisión de diseño (PSP2).
· Diseño de plantillas (PSP2.1).
4.5.4.1 PSP2 Revisión de código [15]
180

El objetivo principal de la revisión de calidad es mejorar la calidad del programa
examinando parte o todo el sistema y su documentación asociada.
Las revisiones técnicas o inspecciones de programa son similares excepto porque
su objetivo principal es identificar las fallas o defectos tales como anomalías en el
código, errores lógicos, incumplimiento de estándares.
Las revisiones tienen un número de pruebas dinámicas del excedente de las
ventajas.
· No requieren que el programa se este ejecutando
· Son una medida directa de defectos o cualidades de la calidad
· Se consideran mas efectivos
La revisión de código consiste en la comprobación de la inicialización de la
variable y sus parámetros.
· En el inicio del programa, inicio de los ciclos, formato de la llamada de la
función
Llamada de función y formato de la llamada
· Punteros parámetros, y el uso de ‘&’
Comprobación y deletreo de nombres
· Es consistente.
· Esta dentro del alcance de la declaración.
· Todas las estructuras y clases usan ‘.’ Y ‘->’ de forma correcta.
Comprobación de secuencias
· Identificación de terminación por puntuaciones y NULL.
Comprobación de archivos
· Declaración correcta.
· Abrir y cerrar correctamente.
181

Comprobación de punteros
· Iniciar en NULL.
· Borrar solamente después que se crea o es nuevo
· Borrar siempre después de su uso
Comprobación del formato de salida
· Alineación y espaciado correcto
Verificación de operadores lógicos
· Uso apropiado de operadores lógicos (=, <, >,…etc.).
· Uso apropiado de paréntesis para operaciones lógicas.
Asegurar que las llaves estén alineadas.
Verificar cada línea de código por instrucciones, sintaxis y puntuación apropiada.
Asegurar el código conforme al estándar de codificación.
4.5.4.2 PSP2 Revisión de Diseño [15]
En la revisión de diseño se deben asegurar los requisitos, especificaciones y
niveles altos de diseño sean cubiertos totalmente. En esta parte se producen
todas las salidas especificadas, se crean todas las entradas necesarias y todos los
requerimientos incluidos son indicados en esta parte.
Verificación de la lógica del programa
· Apilado, Listas, Recursividad
· Todos los ciclos son propiamente inicializados, tanto el incremento y
terminación del mismo.
Verificación de casos especiales
182

· Asegurar las operaciones con los valores de empty, full, min, max,
negative, zero.
· Proteger contra fuera de limites, desbordamiento (overflow),
desbordamiento de menor capacidad (underflow).
· Asegurar que las condiciones imposibles son imposibles.
· Manejar todas las condiciones incorrectas de entrada.
Verificación de uso de funciones
· Todas las funciones y objetos se deben de usar y entender propiamente.
· Todas las abstracciones externas son definidas.
Verificación de nombres
· Todos los nombres y tipos son claramente definidos.
· El alcance de todas las variables son evidentes o bien definidos.
· Todos los nombres y objetos se usan dentro de su alcance definido.
Revisión del diseño de acuerdo al estándar aplicable al diseño.
4.5.4.3 PSP2.1 Diseño de plantillas [15]
Hay cuatro plantillas de diseño que proveen de forma ordenada un marco de
trabajo y el formato de registro para los diseños.
Los formatos no indican la forma en como hacer el diseño, pero pueden ayudar a
que se registren de manera apropiada.
Las plantillas incluyen lo siguiente:
· Escenario de operación de la plantilla.
· Especificación funcional de la plantilla.
· Especificación de estado de la plantilla.
· Especificación lógica de la plantilla.
183

Escenario de operación de la plantilla
Esta plantilla tiene las descripciones de los panoramas probables que se seguirán
al usar el programa.
Las plantillas deben incluir lo siguiente:
· Numero de escenarios para los escenarios y los pasos para el escenario.
· Identificación del objetivo de los usuarios.
· Fuente de acción así como los usuarios, programas o sistemas.
· Descripción de la acción, que lugar toma así como el mensaje de error de
una entrada incorrecta.
· Lista de comentarios significativos.
Especificación funcional de la plantilla
Esta plantilla se puede usar para describir funciones y procedimientos de diseño
de funciones o de objetos de diseño orientado a objetos.
Las plantillas deben incluir:
· Nombre de la función / clase o clases de donde hereda.
· Cualquier parámetro o atributo cuyos valores son externos visibles
o cualquier comportamiento del objeto.
· Documentación de los métodos para cada objeto, incluyendo el
prototipo, variables requeridas, tipos y la operación realizada.
Especificación de estado de la plantilla
Esta plantilla se usa para registrar el comportamiento del programa, subprograma
o clase en un sistema orientado a objetos.
184

La plantilla incluye lo siguiente:
· Nombre del estado.
· Descripción de estado.
· Atributos o variables que caracterizan el estado.
· Para cada estado.
o Lista de todos los estados siguientes posibles.
o Lista de condiciones para cada estado siguiente.
o Dar ejemplos de la condición de transición.
Especificación lógica de la plantilla
Esta plantilla mantiene la lógica del pseudo código para cada función o unidad del
programa.
La plantilla debe contener lo siguiente:
· Enumerar todos los “incluyes” nuevos o inusuales requeridos por la
función.
· Enumerar todos los tipos inusuales o especiales.
· Entregar el prototipo de la función o la declaración.
· Documentación auxiliar de información requerida para entender la función.
· Asignar un número o etiqueta para cada declaración lógica significativa.
· Documentar la lógica del programa
o Uso de pseudocódigo.
o Uso de una línea separada para cada función significativa.
o Uso de lenguaje común o matemático para mayor claridad.
o Incluir comentarios donde sea necesario.
185

4.5.4.4 PSP2 Documentación del Proceso [15]
Planeación
· Producir u obtener la declaración de los requisitos.
· Estimación del tamaño del software, tiempo de desarrollo requerido.
· Estimación de tiempo requerido en el desarrollo.
· Completar el plan de tareas.
· Completar el horario.
· Registrar los datos iniciales en el registro de tiempo
Desarrollo
· Diseñar, implementar, compilar y probar.
· Agregar la revisión del diseño y revisión de código (PSP2).
· Usar las plantillas de diseño donde sea apropiado.
· Tomar los datos del informe de prueba.
· Tomar los datos del informe de registro de tiempo.
Post-ejecución
· Completar el resumen del plan del proyecto con el tiempo real, falla y
tamaño de los datos.
4.5.5 PSP3 Proceso cíclico [15]
El proceso cíclico combina múltiples procesos de PSP2.1 para soportar el
desarrollo de software a gran escala.
El objetivo principal es ampliar el proceso de software personal hacia proyectos
industriales y para cubrir el trabajo de proyecto de equipo.
186

Esta estrategia se centra en el desarrollo del producto, incrementos convenientes
para el desarrollo cíclico.
Las tareas incluyen todo lo de PSP2 y PSP2.1 y lo siguiente:
· Desarrollo cíclico(PSP3)
4.5.5.1 PSP3 Desarrollo Cíclico [15]
Cuando se usa PSP3, se debe de tener un plan para implementar grandes
programas en módulos incrementales más o menos de 100 líneas de código (u
otro tamaño apropiado).
A lo largo del resumen del proyecto PSP3 utilizara el resumen del ciclo para seguir
los datos.
· Tamaño del programa
· Tiempo que se lleva en el desarrollo de cada fase
· Fallas eliminadas
4.5.5.2 PSP3 Documentación del Proceso [15]
Planeación
· Declaración de los requerimientos producidos y obtenidos
· Estimación del tamaño del software, tiempo de desarrollo requerido
· Completar el plan de tareas.
· Completar el horario de trabajo
· Registrar los datos iniciales en el registro de tiempo
Desarrollo
187

· Diseñar, implementar, compilar y probar.
· Agregar la revisión del diseño y revisión de código
· Usar las plantillas de diseño donde sea apropiado.
· Usar el desarrollo cíclico, y seguir los resúmenes del ciclo.
· Tomar los datos del informe de prueba.
· Tomar los datos del informe de registro de tiempo.
Post-ejecución
· Completar el resumen del plan del proyecto con el tiempo real, falla y
tamaño de los datos
Asignaciones
Los principios de estas asignaciones son los siguientes:
188
Planeación y Requerimientos
Niveles Altos de diseño y Revisión de Diseño
Desarrollo Cíclico
Post - Ejecución
Especificación del ciclo
Desarrollo
Valoración del nuevo ciclo
Especificaciones
Producto Terminado
Proyecto y Datos de proceso
Figura 4.8 Proceso cíclico del desarrollo
Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland EUA
[Consulta: Mayo de 2006] <http://www.csee.umbc.edu/~mikeg/cmsc645/se_psp.pdf>

· Atención especial a las tareas de PSP. El objetivo principal de estas
asignaciones no es completarlas correctamente sino que estas tareas usen
completa y correctamente los elementos apropiados del PSP.
· Sobre todo, el trabajo debe ser correcto. Es mejor estar atrasado que este
incorrecto. Si se necesita mas tiempo es necesario pedirlo.
· Todas las asignaciones son individuales. La asistencia técnica se obtiene
del instructor o de otro grupo de miembros que aclaran los requerimientos o
tareas de PSP. Se debe de registrar cuando se recibe asistencia.
Vinculación de listas
Se debe escribir un programa para calcular la desviación estándar de una serie de
n números usando lista encadenada. Es el promedio de los números. La formula
de la desviación estándar es:
σ (x1 ... xn) Σ(x1 - xavg)2
Contando las Líneas de Código
Al escribir el programa se deben de contar las líneas de código, omitiendo
comentarios y líneas en blanco. Asegurarse de que las declaraciones se hagan en
una sola línea, o se cuenten varias veces. Por ejemplo, las siguientes líneas se
cuentan de manera múltiple ya que contienen dos líneas de código
· If (x==0) f();
· If (x==0)
f();
· X=10; y=x + 5;
El total de Líneas de código del programa debe contar los totales para cada
unidad logia(es decir para cada función). También el número de las declaraciones
que no son ejecutables deben de contadas.
189

Almacenamiento y recuperación de archivos
Escribir un programa para almacenar, recuperar y modificar serie de n números
reales de un archivo. De entrada el programa debe aceptar enteros o números
reales y guardar como números reales. Las funciones que debe proveer el usuario
son las siguientes:
· El usuario asigna el nombre del archivo.
· El usuario selecciona la forma de usar el archivo, lectura, escritura,
modificar.
· Lectura, el programa proporciona una numeración por línea dentro del
archivo.
· Escritura, el usuario establece el número de registros.
· Modificación
o El programa proporciona el número y el usuario tiene la opción de
aceptar, reemplazar o eliminar el número.
o El usuario puede dar orden al programa de aceptar el resto de la
numeración al archivo.
o El usuario puede guardar las modificaciones con un nuevo nombre
dejando el original intacto.
Asignación Estándar
Desarrollar los siguientes estándares para el PSP
Cuenta estándar de las líneas de código
· Producir una especificación estándar de cómo contar las líneas de
código.
· Se puede usar en conjunto con la asignación.
Codificación estándar
· Producir una codificación estándar que se usara para nuestro PSP
190

· Se puede usar para evaluar cualquier asignación que se desarrolle
Revisión estándar
· Producir un estándar que sea usado para el diseño y revisión de código
Proceso de Ingeniería de Software
· Producir un estándar que documente el proceso de la Ingeniería de
Software, donde se usa y demostrar donde encajan las tareas de PSP
Análisis del reporte de fallas
Agregar los siguientes comentarios al resumen de comentarios basados en las
fallas encontradas durante el desarrollo.
· El total de fallas encontradas
· Las nuevas y modificadas líneas de código
· Las fallas por KLOC(Kilo Lines Of Code)
Que debe dar la tabla:
· Numero de fallas encontradas en la compilación
· Numero de fallas encontradas al probarlo
· Numero de fallas encontradas por KLOC en la pruebas.
· Numero de fallas encontradas en la compilación por KLOC
·
El listado debe dar el promedio de reparación
· Fallas encontradas durante la compilación
· Fallas encontradas durante la prueba
· Fallas introducidas en el diseño y la codificación
· Fallas introducidas en el código
191

BIBLIOGRAFÍA
[1] Sommerville, Ian (2005), Ingeniería de software, Ed. Addison Wesley 7ª Edicion.
[2] Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª edición
REFERENCIAS WEB
[3] Nelson Medinilla Martínez, Facultad de Informática, Universidad Politécnica de Madrid,
“Análisis y selección de estrategias de desarrollo de software” [En línea], Madrid
España [Consulta: Mayo de 2006], <http://is.ls.fi.upm.es/udis/docencia/proyecto/docs/
estrategias.pdf>
[4] Carolina Zibert, “Ciclos de vida de Ingeniería de Software” [En línea], Caracas
Venezuela [Consulta: Abril de 2006],<carolina.terna.net/ingsw2/Datos/Cascada-
ModeloV.doc>
[5] Tesis doctorales en Zarza, “Ingeniería de Software” [En línea], España [Consulta: Mayo
de 2006], <http://www.tdx.cesca.es/TESIS_UPC/AVAILABLE/TDX-0716102-
102210//05Capitulo05.pdf>
[6] Mundo Geek, “Ciclos de vida del software” [En línea], [Consulta: Mayo de 2006],
<http://mundogeek.net/archivos/2004/05/20>
[7] Wikipedia Foundation Inc, EUA Desarrollo en Cascada [En línea], St. Petersburg
[Consulta: Mayo de 2006], <http://es.wikipedia.org/wiki/Modelo_en_cascada>
[8] 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://www.itlp.edu.mx/publica/tutoriales/
analisis/index.htm>
[9] Copyright © Programación en Castellano, [En línea], España [Consulta: Mayo de
2006], <http://www.programacion.com/blogs/46_aprendiendostruts>
[10] Zavala R. 2000. Diseño de un Sistema de Información Geográfica sobre Internet. Tesis
de Maestría en Ciencias de la Computación. Universidad Autónoma Metropolitana-
Azcapotzalco., “La Ingeniería del Software” [En línea], [Consulta: Abril de 2006],
México, D.F. <http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#fig2>
[11] Juan Pavón Maestras, Universidad Complutense de Madrid, “El proceso unificado” [En
línea], Madrid España [Consulta: Abril de 2006], <http://www.fdi.ucm.es/profesor/
jpavon/is2/03ProcesoUnificado.pdf>
[12] Carlos Reynoso, Universidad de Buenos Aires, Arquitectura de Software [En línea]
Buenos Aires Argentina [Consulta: Mayo de 2006], <http://www.microsoft.com/spanish/
msdn/arquitectura/roadmap_arq/heterodox.asp>
192

[13] Grupo de Investigación Kybele, Universidad Rey Juan Carlos, “Fases del proceso
unificado” [En linea], Madrid España [Consulta: Abril de 2006],
<http://kybele.escet.urjc.es/Documentos/ISI/Fases%20del%20Proceso
%20Unificado.pdf>
[14] Wikipedia Foundation Inc, EUA “Proceso Unificado de Rational” [En línea], St.
Petersburg [Consulta: Abril de 2006],http://es.wikipedia.org/wiki/RUP
[15] Mike Grasso, University of Maryland, “The Personal Software Process” [En línea],
Maryland EUA [Consulta: Mayo de 2006] <http://www.csee.umbc.edu/~mikeg/
cmsc645/se_psp.pdf>
[16] Gustavo Adolfo Ramírez González, Universidad del Caucan Popayán, “Proceso
Unificado para desarrollo de Software”, Colombia [Consulta: Junio de 2006],
<http://atenea.ucauca.edu.co/~gramirez/archivos/AnotacionesRUP.pdf>
[17] A.U.S. GustavoTorossi, “El Proceso Unificado de Desarrollo de Software” [En línea],
Provincia de Chaco Republica de Argentina [Consulta: Junio de 2006]
<http://www.chaco.gov.ar/UTN/disenodesistemas/apuntes/oo/ApunteRUP.pdf>
[18] Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de
2006], <http://www.jeckle.de/files/uniproc.pdf>
193

Sdf p4

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Sdf p4

Último

Sdf p4