SlideShare una empresa de Scribd logo
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 
Modelos de proceso de software 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software 
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software 
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> 
Inicio Elaboración Construcción Transición 
Tiempo 
Visión Arquitectura Capacidad 
inicial 
Edición 
del 
producto 
Iteración 
Preliminar 
Iteración 
Arquitectura 
Iteración 
Desarrollo 
Iteración 
Desarrollo 
Iteración 
Transición 
Figura 4.4 Iteraciones y fases 
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
· 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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software 
Inicio Elaboración Construcción Transición 
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>
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
· 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 
Modelos de proceso de software
· 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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
· 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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
170 
PSP2.1 
Diseño de plantillas 
Planeación de Tareas 
Planeación de horarios 
Modelos de proceso de software 
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software 
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software 
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
· 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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
· 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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
· 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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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. 
· Incorporación de los datos iniciales en el resumen del plan de proyecto. 
· 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 
Modelos de proceso de software
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 
· Incorporación de los datos iniciales en el resumen del plan de proyecto. 
· Registrar los datos iniciales en el registro de tiempo 
Desarrollo 
187 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
· 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 
Modelos de proceso de software 
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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
· 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 
Modelos de proceso de software
Instituto Tecnológico de Morelia 
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 
Modelos de proceso de software
[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 
Modelos de proceso de software

Más contenido relacionado

La actualidad más candente

MOD Unidad 3: Modelado y verificación formal
MOD Unidad 3: Modelado y verificación formalMOD Unidad 3: Modelado y verificación formal
MOD Unidad 3: Modelado y verificación formal
Franklin Parrales Bravo
 
IIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del softwareIIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del software
Franklin Parrales Bravo
 
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientosIDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
Franklin Parrales Bravo
 
PSW Unidad 1 PROCESO DE SOFTWARE
PSW Unidad 1 PROCESO DE SOFTWAREPSW Unidad 1 PROCESO DE SOFTWARE
PSW Unidad 1 PROCESO DE SOFTWARE
Franklin Parrales Bravo
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitos
Franklin Parrales Bravo
 
IIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de SoftwareIIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de Software
Franklin Parrales Bravo
 
INGENIERIA DE SOFTWARE 2012
INGENIERIA DE SOFTWARE 2012INGENIERIA DE SOFTWARE 2012
INGENIERIA DE SOFTWARE 2012
Diego Prado
 
MOD Unidad 2: Tipos de modelado
MOD Unidad 2: Tipos de modeladoMOD Unidad 2: Tipos de modelado
MOD Unidad 2: Tipos de modelado
Franklin Parrales Bravo
 
Ingeniería De Requisitos
Ingeniería De RequisitosIngeniería De Requisitos
Ingeniería De Requisitos
ssharLudena
 
IHM Unidad 1: Introducción a la Interacción Hombre-Máquina
IHM Unidad 1: Introducción a la Interacción Hombre-MáquinaIHM Unidad 1: Introducción a la Interacción Hombre-Máquina
IHM Unidad 1: Introducción a la Interacción Hombre-Máquina
Franklin Parrales Bravo
 
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONESPRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
Franklin Parrales Bravo
 
Introducción al proceso unificado de desarrollo de software en Curso de Anali...
Introducción al proceso unificado de desarrollo de software en Curso de Anali...Introducción al proceso unificado de desarrollo de software en Curso de Anali...
Introducción al proceso unificado de desarrollo de software en Curso de Anali...
Educagratis
 
PSW Unidad 2 MODELOS DE PROCESO
PSW Unidad 2 MODELOS DE PROCESOPSW Unidad 2 MODELOS DE PROCESO
PSW Unidad 2 MODELOS DE PROCESO
Franklin Parrales Bravo
 
Ciclo de vida de un proyecto informatico
Ciclo de vida de un proyecto informaticoCiclo de vida de un proyecto informatico
Ciclo de vida de un proyecto informatico
juan pablo guaman
 
IHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacción
IHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacciónIHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacción
IHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacción
Franklin Parrales Bravo
 
8.conceptos de diseño
8.conceptos de diseño8.conceptos de diseño
8.conceptos de diseño
Ramiro Estigarribia Canese
 
Gestión de proyectos de software - Tema 3: Planificación del proyecto
Gestión de proyectos de software - Tema 3: Planificación del proyectoGestión de proyectos de software - Tema 3: Planificación del proyecto
Gestión de proyectos de software - Tema 3: Planificación del proyecto
Jair Valenz
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
monik1002
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26
DEBANI SALAS
 
1_1 Introduccion
1_1 Introduccion1_1 Introduccion
1_1 Introduccion
landeta_p
 

La actualidad más candente (20)

MOD Unidad 3: Modelado y verificación formal
MOD Unidad 3: Modelado y verificación formalMOD Unidad 3: Modelado y verificación formal
MOD Unidad 3: Modelado y verificación formal
 
IIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del softwareIIS Unidad 2 Modelos de proceso del software
IIS Unidad 2 Modelos de proceso del software
 
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientosIDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
 
PSW Unidad 1 PROCESO DE SOFTWARE
PSW Unidad 1 PROCESO DE SOFTWAREPSW Unidad 1 PROCESO DE SOFTWARE
PSW Unidad 1 PROCESO DE SOFTWARE
 
IDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitosIDR Unidad 4: Validación y gestión de requisitos
IDR Unidad 4: Validación y gestión de requisitos
 
IIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de SoftwareIIS Unidad1: Introducción a la Ingeniería de Software
IIS Unidad1: Introducción a la Ingeniería de Software
 
INGENIERIA DE SOFTWARE 2012
INGENIERIA DE SOFTWARE 2012INGENIERIA DE SOFTWARE 2012
INGENIERIA DE SOFTWARE 2012
 
MOD Unidad 2: Tipos de modelado
MOD Unidad 2: Tipos de modeladoMOD Unidad 2: Tipos de modelado
MOD Unidad 2: Tipos de modelado
 
Ingeniería De Requisitos
Ingeniería De RequisitosIngeniería De Requisitos
Ingeniería De Requisitos
 
IHM Unidad 1: Introducción a la Interacción Hombre-Máquina
IHM Unidad 1: Introducción a la Interacción Hombre-MáquinaIHM Unidad 1: Introducción a la Interacción Hombre-Máquina
IHM Unidad 1: Introducción a la Interacción Hombre-Máquina
 
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONESPRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
 
Introducción al proceso unificado de desarrollo de software en Curso de Anali...
Introducción al proceso unificado de desarrollo de software en Curso de Anali...Introducción al proceso unificado de desarrollo de software en Curso de Anali...
Introducción al proceso unificado de desarrollo de software en Curso de Anali...
 
PSW Unidad 2 MODELOS DE PROCESO
PSW Unidad 2 MODELOS DE PROCESOPSW Unidad 2 MODELOS DE PROCESO
PSW Unidad 2 MODELOS DE PROCESO
 
Ciclo de vida de un proyecto informatico
Ciclo de vida de un proyecto informaticoCiclo de vida de un proyecto informatico
Ciclo de vida de un proyecto informatico
 
IHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacción
IHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacciónIHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacción
IHM Unidad 2: Factores Humanos, Estilos y Dispositivos de interacción
 
8.conceptos de diseño
8.conceptos de diseño8.conceptos de diseño
8.conceptos de diseño
 
Gestión de proyectos de software - Tema 3: Planificación del proyecto
Gestión de proyectos de software - Tema 3: Planificación del proyectoGestión de proyectos de software - Tema 3: Planificación del proyecto
Gestión de proyectos de software - Tema 3: Planificación del proyecto
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
 
Estimación para proyectos de software cap26
Estimación para proyectos de software cap26Estimación para proyectos de software cap26
Estimación para proyectos de software cap26
 
1_1 Introduccion
1_1 Introduccion1_1 Introduccion
1_1 Introduccion
 

Destacado

Proceso del diseño
Proceso del diseñoProceso del diseño
Proceso del diseño
MercedesAllegue
 
Proyecto
ProyectoProyecto
Proyecto 2012 pucp
Proyecto 2012 pucpProyecto 2012 pucp
Tarea3
Tarea3Tarea3
Encuesta sobre el control interno
Encuesta sobre el control internoEncuesta sobre el control interno
Encuesta sobre el control interno
MajinRuiz63
 
Indicador de desempeño 4.1
Indicador de desempeño 4.1Indicador de desempeño 4.1
Indicador de desempeño 4.1
DayannaYCamila
 
3 indicador
3 indicador3 indicador
3 indicador
Cristian Torres
 
Taller comercio multimedial
Taller comercio multimedialTaller comercio multimedial
Taller comercio multimedial
Ferney Medina Parra
 
L A D I F E R E N C I A Q U E H A C E L A D I F E R E N C I A
L A  D I F E R E N C I A  Q U E  H A C E  L A  D I F E R E N C I AL A  D I F E R E N C I A  Q U E  H A C E  L A  D I F E R E N C I A
L A D I F E R E N C I A Q U E H A C E L A D I F E R E N C I A
Asei Sv
 
Presentacion emgoldex
Presentacion emgoldexPresentacion emgoldex
Presentacion emgoldex
Thommy Mancilla
 
Finanzas internacionales
Finanzas internacionalesFinanzas internacionales
Finanzas internacionales
KaRo Arciniegas
 
Diapositivas de conceptos b
Diapositivas de conceptos bDiapositivas de conceptos b
Diapositivas de conceptos b
aaular100
 
Estrategias de az. annie d
Estrategias de az. annie dEstrategias de az. annie d
Estrategias de az. annie d
ElianaCrespo
 
Nuevo trabajo energia oelica mari ana ramirez rojo...
Nuevo trabajo energia oelica mari ana ramirez rojo...Nuevo trabajo energia oelica mari ana ramirez rojo...
Nuevo trabajo energia oelica mari ana ramirez rojo...
marianamejiacsj
 
Innovación educativa a partir de los recursos educativos
Innovación educativa a partir de los recursos educativosInnovación educativa a partir de los recursos educativos
Innovación educativa a partir de los recursos educativos
otrolouis
 
Explora
ExploraExplora
Explora
Andy Abril
 
Posicionar tu marca session 3
Posicionar tu marca session 3Posicionar tu marca session 3
Posicionar tu marca session 3
Caro Fletcher
 
Portafolio vivi
Portafolio viviPortafolio vivi
Portafolio vivi
jucateja
 
Cool Tabs - BetaBeers Madrid Sept 2012
Cool Tabs - BetaBeers Madrid Sept 2012Cool Tabs - BetaBeers Madrid Sept 2012
Cool Tabs - BetaBeers Madrid Sept 2012
Cool Tabs
 
Herramientas web
Herramientas webHerramientas web
Herramientas web
StvnTapia
 

Destacado (20)

Proceso del diseño
Proceso del diseñoProceso del diseño
Proceso del diseño
 
Proyecto
ProyectoProyecto
Proyecto
 
Proyecto 2012 pucp
Proyecto 2012 pucpProyecto 2012 pucp
Proyecto 2012 pucp
 
Tarea3
Tarea3Tarea3
Tarea3
 
Encuesta sobre el control interno
Encuesta sobre el control internoEncuesta sobre el control interno
Encuesta sobre el control interno
 
Indicador de desempeño 4.1
Indicador de desempeño 4.1Indicador de desempeño 4.1
Indicador de desempeño 4.1
 
3 indicador
3 indicador3 indicador
3 indicador
 
Taller comercio multimedial
Taller comercio multimedialTaller comercio multimedial
Taller comercio multimedial
 
L A D I F E R E N C I A Q U E H A C E L A D I F E R E N C I A
L A  D I F E R E N C I A  Q U E  H A C E  L A  D I F E R E N C I AL A  D I F E R E N C I A  Q U E  H A C E  L A  D I F E R E N C I A
L A D I F E R E N C I A Q U E H A C E L A D I F E R E N C I A
 
Presentacion emgoldex
Presentacion emgoldexPresentacion emgoldex
Presentacion emgoldex
 
Finanzas internacionales
Finanzas internacionalesFinanzas internacionales
Finanzas internacionales
 
Diapositivas de conceptos b
Diapositivas de conceptos bDiapositivas de conceptos b
Diapositivas de conceptos b
 
Estrategias de az. annie d
Estrategias de az. annie dEstrategias de az. annie d
Estrategias de az. annie d
 
Nuevo trabajo energia oelica mari ana ramirez rojo...
Nuevo trabajo energia oelica mari ana ramirez rojo...Nuevo trabajo energia oelica mari ana ramirez rojo...
Nuevo trabajo energia oelica mari ana ramirez rojo...
 
Innovación educativa a partir de los recursos educativos
Innovación educativa a partir de los recursos educativosInnovación educativa a partir de los recursos educativos
Innovación educativa a partir de los recursos educativos
 
Explora
ExploraExplora
Explora
 
Posicionar tu marca session 3
Posicionar tu marca session 3Posicionar tu marca session 3
Posicionar tu marca session 3
 
Portafolio vivi
Portafolio viviPortafolio vivi
Portafolio vivi
 
Cool Tabs - BetaBeers Madrid Sept 2012
Cool Tabs - BetaBeers Madrid Sept 2012Cool Tabs - BetaBeers Madrid Sept 2012
Cool Tabs - BetaBeers Madrid Sept 2012
 
Herramientas web
Herramientas webHerramientas web
Herramientas web
 

Similar a Sdf p4

Jose gpe act4
Jose gpe act4Jose gpe act4
Jose gpe act4
lupinmtzrincon
 
Inf 162
Inf 162Inf 162
Inf 162
Markitozzz100
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
mendez45
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
Jazmin Cr
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
angelicasolishernnde
 
Desarrollo en cascada
Desarrollo en cascadaDesarrollo en cascada
Desarrollo en cascada
Isaias Castro
 
Desarrollo en cascada
Desarrollo en cascadaDesarrollo en cascada
Desarrollo en cascada
Isaias Castro
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
Evelin Oña
 
Proceso del Software
Proceso del Software Proceso del Software
Proceso del Software
Ares Atzarel Hernández Rodríguez
 
(Inmer)La Ingenieria de Software
(Inmer)La Ingenieria de Software(Inmer)La Ingenieria de Software
(Inmer)La Ingenieria de Software
Inmer Alexai Flores Rodriguez
 
Apuntes
ApuntesApuntes
Presentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del softwarePresentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del software
paoaboytes
 
Modelos
ModelosModelos
Modelos
Jose Lema
 
Modelos de proceso de software
Modelos de proceso de softwareModelos de proceso de software
Modelos de proceso de software
Juan Vidal Zegarra De La Sota
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
UVM
 
Fundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdfFundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdf
BibliotecaenlineaUNI
 
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos
bren1995
 
Act18
Act18Act18
Act18
karinaaura
 
Modelos de proceso del software
Modelos de proceso del softwareModelos de proceso del software
Modelos de proceso del software
Diego Llusco
 
Proceso de desarrollo de sofware
Proceso de desarrollo de sofwareProceso de desarrollo de sofware
Proceso de desarrollo de sofware
McDonald's
 

Similar a Sdf p4 (20)

Jose gpe act4
Jose gpe act4Jose gpe act4
Jose gpe act4
 
Inf 162
Inf 162Inf 162
Inf 162
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
 
Modelos del software
Modelos del softwareModelos del software
Modelos del software
 
Desarrollo en cascada
Desarrollo en cascadaDesarrollo en cascada
Desarrollo en cascada
 
Desarrollo en cascada
Desarrollo en cascadaDesarrollo en cascada
Desarrollo en cascada
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
 
Proceso del Software
Proceso del Software Proceso del Software
Proceso del Software
 
(Inmer)La Ingenieria de Software
(Inmer)La Ingenieria de Software(Inmer)La Ingenieria de Software
(Inmer)La Ingenieria de Software
 
Apuntes
ApuntesApuntes
Apuntes
 
Presentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del softwarePresentaciòn modelos para el desarrollo del software
Presentaciòn modelos para el desarrollo del software
 
Modelos
ModelosModelos
Modelos
 
Modelos de proceso de software
Modelos de proceso de softwareModelos de proceso de software
Modelos de proceso de software
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
 
Fundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdfFundamentos de ingenieria de software - metodologias.pdf
Fundamentos de ingenieria de software - metodologias.pdf
 
Investigación de modelos
Investigación de modelos Investigación de modelos
Investigación de modelos
 
Act18
Act18Act18
Act18
 
Modelos de proceso del software
Modelos de proceso del softwareModelos de proceso del software
Modelos de proceso del software
 
Proceso de desarrollo de sofware
Proceso de desarrollo de sofwareProceso de desarrollo de sofware
Proceso de desarrollo de sofware
 

Último

Graficas de Control, problemas resueltos, minitab
Graficas de Control, problemas resueltos, minitabGraficas de Control, problemas resueltos, minitab
Graficas de Control, problemas resueltos, minitab
XIOMARAANTONELLACAST
 
ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........
ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........
ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........
IVANBRIANCHOQUEHUANC
 
FICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdf
FICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdfFICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdf
FICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdf
jesus869159
 
AUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CON
AUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CONAUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CON
AUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CON
FreddyJuniorOrtechoC
 
Presentacion ATS 2015 Trens argentinos Sanchez.pptx
Presentacion ATS   2015 Trens argentinos Sanchez.pptxPresentacion ATS   2015 Trens argentinos Sanchez.pptx
Presentacion ATS 2015 Trens argentinos Sanchez.pptx
MAURICIOALEJANDROTAS1
 
Infografía de operaciones básicas....pdf
Infografía de operaciones básicas....pdfInfografía de operaciones básicas....pdf
Infografía de operaciones básicas....pdf
jahirrtorresa
 
Presentación- de motor a combustión -diesel.pptx
Presentación- de motor a combustión -diesel.pptxPresentación- de motor a combustión -diesel.pptx
Presentación- de motor a combustión -diesel.pptx
ronnyrocha223
 
Comunicación del Protocolo de investigación..pdf
Comunicación del Protocolo de investigación..pdfComunicación del Protocolo de investigación..pdf
Comunicación del Protocolo de investigación..pdf
211k0304
 
Calculo-de-Camaras-Frigorificas.pdf para trabajos
Calculo-de-Camaras-Frigorificas.pdf para trabajosCalculo-de-Camaras-Frigorificas.pdf para trabajos
Calculo-de-Camaras-Frigorificas.pdf para trabajos
JuanCarlos695207
 
Cargas de Cálculos Estructurales de un Puente
Cargas de Cálculos Estructurales de un PuenteCargas de Cálculos Estructurales de un Puente
Cargas de Cálculos Estructurales de un Puente
jemifermelgarejoaran1
 
9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN
9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN
9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN
KarinToledo2
 
Taller de Robots Velocistas2 esquema....
Taller de Robots Velocistas2 esquema....Taller de Robots Velocistas2 esquema....
Taller de Robots Velocistas2 esquema....
lawjose243
 
GRAFICAS AÑOSsssssssss (2022 - 2023).pdf
GRAFICAS AÑOSsssssssss (2022 - 2023).pdfGRAFICAS AÑOSsssssssss (2022 - 2023).pdf
GRAFICAS AÑOSsssssssss (2022 - 2023).pdf
Jose Calderas
 
PRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptx
PRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptxPRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptx
PRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptx
brandonsinael
 
56201776-Formato-...........triptico.pdf
56201776-Formato-...........triptico.pdf56201776-Formato-...........triptico.pdf
56201776-Formato-...........triptico.pdf
zuleicalindauracarne
 
tipos de energias: la Energía Radiante.pdf
tipos de energias: la Energía Radiante.pdftipos de energias: la Energía Radiante.pdf
tipos de energias: la Energía Radiante.pdf
munozvanessa878
 
Metodología - Proyecto de ingeniería "Dispensador automático"
Metodología - Proyecto de ingeniería "Dispensador automático"Metodología - Proyecto de ingeniería "Dispensador automático"
Metodología - Proyecto de ingeniería "Dispensador automático"
cristiaansabi19
 
PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...
PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...
PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...
CarlitosWay20
 
Las operaciones básicas en la construcción.
Las operaciones básicas en la construcción.Las operaciones básicas en la construcción.
Las operaciones básicas en la construcción.
MaraManuelaUrribarri
 
DIAGRAMA ELECTRICOS y circuito electrónicos
DIAGRAMA ELECTRICOS y circuito electrónicosDIAGRAMA ELECTRICOS y circuito electrónicos
DIAGRAMA ELECTRICOS y circuito electrónicos
LuisAngelGuarnizoBet
 

Último (20)

Graficas de Control, problemas resueltos, minitab
Graficas de Control, problemas resueltos, minitabGraficas de Control, problemas resueltos, minitab
Graficas de Control, problemas resueltos, minitab
 
ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........
ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........
ABR-FUNDAMENTOS DEL CALCULO uc 2024 ........
 
FICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdf
FICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdfFICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdf
FICHA TECNICA PRODUCTOS CONGELADOS EMBALAJE.pdf
 
AUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CON
AUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CONAUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CON
AUTOCAD 2D - UA1 DE NIVEL INTERMEDIO CON
 
Presentacion ATS 2015 Trens argentinos Sanchez.pptx
Presentacion ATS   2015 Trens argentinos Sanchez.pptxPresentacion ATS   2015 Trens argentinos Sanchez.pptx
Presentacion ATS 2015 Trens argentinos Sanchez.pptx
 
Infografía de operaciones básicas....pdf
Infografía de operaciones básicas....pdfInfografía de operaciones básicas....pdf
Infografía de operaciones básicas....pdf
 
Presentación- de motor a combustión -diesel.pptx
Presentación- de motor a combustión -diesel.pptxPresentación- de motor a combustión -diesel.pptx
Presentación- de motor a combustión -diesel.pptx
 
Comunicación del Protocolo de investigación..pdf
Comunicación del Protocolo de investigación..pdfComunicación del Protocolo de investigación..pdf
Comunicación del Protocolo de investigación..pdf
 
Calculo-de-Camaras-Frigorificas.pdf para trabajos
Calculo-de-Camaras-Frigorificas.pdf para trabajosCalculo-de-Camaras-Frigorificas.pdf para trabajos
Calculo-de-Camaras-Frigorificas.pdf para trabajos
 
Cargas de Cálculos Estructurales de un Puente
Cargas de Cálculos Estructurales de un PuenteCargas de Cálculos Estructurales de un Puente
Cargas de Cálculos Estructurales de un Puente
 
9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN
9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN
9 Lección perro.pptxcvBWRFWBCCCCCCCCCCCCCCTEN
 
Taller de Robots Velocistas2 esquema....
Taller de Robots Velocistas2 esquema....Taller de Robots Velocistas2 esquema....
Taller de Robots Velocistas2 esquema....
 
GRAFICAS AÑOSsssssssss (2022 - 2023).pdf
GRAFICAS AÑOSsssssssss (2022 - 2023).pdfGRAFICAS AÑOSsssssssss (2022 - 2023).pdf
GRAFICAS AÑOSsssssssss (2022 - 2023).pdf
 
PRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptx
PRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptxPRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptx
PRES 3. METROLOGÍA DE GASES Y RADIACIONES IONIZANTES.pptx
 
56201776-Formato-...........triptico.pdf
56201776-Formato-...........triptico.pdf56201776-Formato-...........triptico.pdf
56201776-Formato-...........triptico.pdf
 
tipos de energias: la Energía Radiante.pdf
tipos de energias: la Energía Radiante.pdftipos de energias: la Energía Radiante.pdf
tipos de energias: la Energía Radiante.pdf
 
Metodología - Proyecto de ingeniería "Dispensador automático"
Metodología - Proyecto de ingeniería "Dispensador automático"Metodología - Proyecto de ingeniería "Dispensador automático"
Metodología - Proyecto de ingeniería "Dispensador automático"
 
PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...
PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...
PROCEDIMIENTO Y PLAN DE RESCATE PARA TRABAJOS EN ALTURAS (Recuperado automáti...
 
Las operaciones básicas en la construcción.
Las operaciones básicas en la construcción.Las operaciones básicas en la construcción.
Las operaciones básicas en la construcción.
 
DIAGRAMA ELECTRICOS y circuito electrónicos
DIAGRAMA ELECTRICOS y circuito electrónicosDIAGRAMA ELECTRICOS y circuito electrónicos
DIAGRAMA ELECTRICOS y circuito electrónicos
 

Sdf p4

  • 1. 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
  • 2. 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 Modelos de proceso de software 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>
  • 3. 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 Modelos de proceso de software
  • 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 143 Modelos de proceso de software
  • 5. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 6. 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 Modelos de proceso de software
  • 7. Instituto Tecnológico de Morelia 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 Modelos de proceso de software 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
  • 8. 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 Modelos de proceso de software
  • 9. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 10. 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 Modelos de proceso de software
  • 11. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 12. 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 Modelos de proceso de software
  • 13. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 14. 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 Modelos de proceso de software
  • 15. Instituto Tecnológico de Morelia 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 Modelos de proceso de software 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> Inicio Elaboración Construcción Transición Tiempo Visión Arquitectura Capacidad inicial Edición del producto Iteración Preliminar Iteración Arquitectura Iteración Desarrollo Iteración Desarrollo Iteración Transición Figura 4.4 Iteraciones y fases Ivar Jacobson, “Applying UML in The Unified Process” [En linea], [Consulta:Enero de 2006], <http://www.jeckle.de/files/uniproc.pdf>
  • 16. 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 Modelos de proceso de software
  • 17. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 18. 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 Modelos de proceso de software
  • 19. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 20. · 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 Modelos de proceso de software
  • 21. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 22. 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 Modelos de proceso de software Inicio Elaboración Construcción Transición 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>
  • 23. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 24. 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 Modelos de proceso de software
  • 25. Instituto Tecnológico de Morelia · 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 Modelos de proceso de software
  • 26. · 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 Modelos de proceso de software
  • 27. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 28. 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 Modelos de proceso de software
  • 29. Instituto Tecnológico de Morelia · 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 Modelos de proceso de software
  • 30. 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 Modelos de proceso de software
  • 31. Instituto Tecnológico de Morelia 170 PSP2.1 Diseño de plantillas Planeación de Tareas Planeación de horarios Modelos de proceso de software 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>
  • 32. 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 Modelos de proceso de software
  • 33. Instituto Tecnológico de Morelia 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 Modelos de proceso de software 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>
  • 34. · 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 Modelos de proceso de software
  • 35. Instituto Tecnológico de Morelia 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 Modelos de proceso de software 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>
  • 36. · 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 Modelos de proceso de software
  • 37. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 38. · 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 Modelos de proceso de software
  • 39. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 40. 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 Modelos de proceso de software
  • 41. Instituto Tecnológico de Morelia · 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 Modelos de proceso de software
  • 42. 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 Modelos de proceso de software
  • 43. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 44. · 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 Modelos de proceso de software
  • 45. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 46. 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 Modelos de proceso de software
  • 47. Instituto Tecnológico de Morelia 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. · Incorporación de los datos iniciales en el resumen del plan de proyecto. · 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 Modelos de proceso de software
  • 48. 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 · Incorporación de los datos iniciales en el resumen del plan de proyecto. · Registrar los datos iniciales en el registro de tiempo Desarrollo 187 Modelos de proceso de software
  • 49. Instituto Tecnológico de Morelia · 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 Modelos de proceso de software 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>
  • 50. · 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 Modelos de proceso de software
  • 51. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 52. · 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 Modelos de proceso de software
  • 53. Instituto Tecnológico de Morelia 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 Modelos de proceso de software
  • 54. [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 Modelos de proceso de software