Modelos de Proceso del Software - Sistemas y...

Instituto Tecnológico de Morelia

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.

140Modelos 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:


Ingeniería y Análisis del Sistema

Análisis de los Requisitos

Diseño

Codificación

Prueba

Mantenimiento

Figura 4.1 Modelo de CascadaCarolina 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>


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]


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



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.


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



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.


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 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

Implementación

Prueba de aceptación

Prueba de Integración

Prueba de Unidad

Codificación

Revisión

Figura 4.2 Modelo de Espiral de BoehmSommerville, 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



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


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



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


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.



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


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



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


Inicio Elaboración Construcción Transición

Tiempo

Visión Arquitectura Capacidad inicial

Edición del

producto

Figura 4.3 Fases del Ciclo de VidaIvar 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 fasesIvar 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.



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


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



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.


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.



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.


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.



Modelo de negocio

Requisitos

Análisis y Diseño

Implementación

Pruebas

Implantación

Gestión de Configuración

Gestión

Entorno

Flujos de Trabajo de proceso

Flujos de Trabajo de soporte

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 UnificadoJuan 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

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

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

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

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

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.

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.

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.


PSP0Proceso actualTiempo de registroRegistro de fallasEstándar de fallas

PSP1Estimación de tamaño Reporte de pruebas

PSP2Revisión de códigoRevisión de diseño

PSP3Desarrollo cíclico

PSP0.1Codificación estándar

Medida del tamañoMejora del proceso

PSP1.1Planeación de Tareas

Planeación de horarios

PSP2.1Diseño de plantillas

Figura 4.6 Evolución de PSPMike 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).


Planeación

Diseño

Código

Compilación

Pruebas

Post-ejecución

ScriptsRegistros

Resumen del plan

Requerimientos

Producto terminado

Figura 4.7 Flujo del procesoMike 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.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]

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

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

30Construcción, Manejo de cambio de paquete, librería, control de

versión

40Declaración de asignación, duplicado de nombres, alcance,

limitaciones

50Procedimiento 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

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]


Tabla 4.1 Estanda de fallasMike 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>


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]

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.

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]

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]

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.

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]

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.

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

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.

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.

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.


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.



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

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:

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.


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 TerminadoProyecto y Datos de procesoFigura 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>


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:

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.

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


σ (x1 ... xn) Σ(x1 - xavg)2

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

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


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>

[13] Grupo de Investigación Kybele, Universidad Rey Juan Carlos, “Fases del proceso

unificado” [En linea], Madrid España [Consulta: Abril de 2006],


http://es.wikipedia.org/wiki/Modelo_en_cascada

http://mundogeek.net/archivos/2004/05/20


<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>


Modelos de Proceso del Software - Sistemas y...

Documents

Transcript of Modelos de Proceso del Software - Sistemas y...