Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SDF p4
SDF p4
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
141
Modelos de proceso de software
Instituto Tecnológico de Morelia
4.1.1 Actividades
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
142
Modelos de proceso de software
Codificación
Prueba
Mantenimiento
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
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.
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]
145
Modelos de proceso de software
Instituto Tecnológico de Morelia
Análisis de
Planificación
Riesgos
Análisis de
riesgo
Análisis de
riesgo
Prototipo
Análisis de Operativo
riesgo
Prototipo 3
Revisión
AR Prototipo 2
Prototipo 1
Plan de Codificación
prueba e Verificación
Integración y validación Prueba de Unidad
de diseño
Prueba de Integración
Prueba de aceptación
Evaluación del
Ingeniería
Cliente Implementación
146
Modelos de proceso de software
4.3 Modelo incremental [2]
147
Modelos de proceso de software
Instituto Tecnológico de Morelia
4.4.1 Orígenes
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]
149
Modelos de proceso de software
Instituto Tecnológico de Morelia
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.
150
Modelos de proceso de software
cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus
colaboraciones, y su composición. [17]
La arquitectura es una vista del diseño completo con las características más
importantes resaltadas, dejando los detalles de lado.
151
Modelos de proceso de software
Instituto Tecnológico de Morelia
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.
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.
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.
4.4.3.1 Fases
153
Modelos de proceso de software
Instituto Tecnológico de Morelia
Tiempo
Tiempo
4.4.3.2 Disciplinas
154
Modelos de proceso de software
son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de
diseño, modelo de implementación, y modelo de prueba.
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
155
Modelos de proceso de software
Instituto Tecnológico de Morelia
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.
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
160
Modelos de proceso de software
Flujos de Trabajo de proceso 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
4.4.3.5 Inicio
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
Instituto Tecnológico de Morelia
Objetivos
Actividades
Hito
4.4.3.6 Elaboración
162
Modelos de proceso de software
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
Actividades
163
Modelos de proceso de software
Instituto Tecnológico de Morelia
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
Objetivos
164
Modelos de proceso de software
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
Hito
165
Modelos de proceso de software
Instituto Tecnológico de Morelia
4.4.3.8 Transición
Al final de la fase de Transición los objetivos del ciclo de vida se han cumplido, y el
proyecto está listo para cerrarse. En algunos casos el final de este ciclo coincide
con el inicio de otro ciclo en el mismo proyecto, encaminándose a la siguiente
generación o versión del producto. Para otros proyectos el final de esta fase puede
coincidir con la entrega completa de los productos (aplicaciones) y subproductos
(documentación) a terceros que pudieran ser responsables de la operación,
mantenimientos, y mejoras al sistema entregado. Esta fase de transición puede
variar de muy sencilla a extremadamente compleja, dependiendo del tipo de
producto.
Esta etapa comienza cuando la línea base está lo suficientemente madura como
para realizar una entrega al dominio de los usuarios finales. Esto por lo general
requiere que se haya completado un subconjunto usable del sistema con un nivel
de calidad aceptable y documentación de usuario de modo que la transición
produzca resultados positivos para todas las partes.
Objetivos
166
Modelos de proceso de software
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
167
Modelos de proceso de software
Instituto Tecnológico de Morelia
El PSP fue definido por Watts S. Humphrey del Software Engineering Institute
(SEI) en la Carnegie Mellon University.
168
Modelos de proceso de software
Medida de la productividad.
169
Modelos de proceso de software
Instituto Tecnológico de Morelia
PSP3
Desarrollo cíclico
PSP2.1
PSP2 Diseño de plantillas
Revisión de código
Revisión de diseño
PSP1.1
PSP1 Planeación de Tareas
Estimación de tamaño Planeación de horarios
Reporte de pruebas
PSP0.1
PSP0 Codificación estándar
Proceso actual Medida del tamaño
Tiempo de registro Mejora del proceso
Registro de fallas
Estándar de fallas
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>
170
Modelos de proceso de software
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
171
Modelos de proceso de software
Instituto Tecnológico de Morelia
Requerimientos
Planeación
Diseño
Código
Scripts
Compilación Registros
Pruebas Resumen
del plan
Post-ejecución
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>
172
Modelos de proceso de software
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 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.
173
Modelos de proceso de software
Instituto Tecnológico de Morelia
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
Construcción, Manejo de cambio de paquete, librería, control de
30
versión
Declaración de asignación, duplicado de nombres, alcance,
40
limitaciones
Procedimiento de la Interfaz, llamadas, referencias, I/O, formato
50
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
Diseño del entorno, compilación, prueba, otro sistema de soporte
100
de problemas
El resumen del plan guarda y estima los datos del proyecto actual, el cual debería
de contener lo siguiente: Tabla 4.1 Estanda de fallas
Mike Grasso, University of Maryland, “The Personal Software Process” [En línea], Maryland EUA
Estimación [Consulta:
original dedeLOC(“Lines
Mayo Of Code”, Líneas de código) que
2006] <http://www.csee.umbc.edu/~mikeg/cmsc645/se_psp.pdf>
174
Modelos de proceso de software
Identificadores
Comentarios
Sección mas importante
Espacios en blanco
Identidad
Capitalización
175
Modelos de proceso de software
Instituto Tecnológico de Morelia
Planeación:
Producir u obtener los requerimientos de las declaraciones.
Estimación de nuevos totales como los cambios en las líneas de
código requeridos en PSP0.1.
Estimación del tiempo requerido para el desarrollo.
Registrar el inicio del proyecto en el resumen del plan del proyecto.
Registrar la fecha del proyecto.
Desarrollo:
176
Modelos de proceso de software
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.
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.
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.
177
Modelos de proceso de software
Instituto Tecnológico de Morelia
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.
178
Modelos de proceso de software
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.
Planeación
Produce u obtiene la declaración de los requisitos.
Estimación del tamaño del software, tiempo del desarrollo requerido
(PSP1).
Plan completo de tareas.
Horario completo del plan (PSP1.1).
Incorporación de los datos iniciales en el resumen del plan de proyecto.
Registro de tiempo y datos iniciales.
179
Modelos de proceso de software
Instituto Tecnológico de Morelia
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.
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.
180
Modelos de proceso de software
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.
Comprobación de archivos
Declaración correcta.
Abrir y cerrar correctamente.
Comprobación de punteros
Iniciar en NULL.
181
Modelos de proceso de software
Instituto Tecnológico de Morelia
182
Modelos de proceso de software
Asegurar que las condiciones imposibles son imposibles.
Manejar todas las condiciones incorrectas de entrada.
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.
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
Esta plantilla tiene las descripciones de los panoramas probables que se seguirán
al usar el programa.
184
Modelos de proceso de software
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.
Esta plantilla mantiene la lógica del pseudo código para cada función o unidad del
programa.
185
Modelos de proceso de software
Instituto Tecnológico de Morelia
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.
186
Modelos de proceso de software
Esta estrategia se centra en el desarrollo del producto, incrementos convenientes
para el desarrollo cíclico.
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
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
Diseñar, implementar, compilar y probar.
187
Modelos de proceso de software
Instituto Tecnológico de Morelia
Especificaciones
Planeación y Requerimientos
Desarrollo
Desarrollo Cíclico
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>
Post-ejecución
Completar el resumen del plan del proyecto con el tiempo real, falla y
tamaño de los datos
Asignaciones
188
Modelos de proceso de software
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
189
Modelos de proceso de software
Instituto Tecnológico de Morelia
Asignación Estándar
Revisión estándar
190
Modelos de proceso de software
Producir un estándar que sea usado para el diseño y revisión de 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>
[13] Grupo de Investigación Kybele, Universidad Rey Juan Carlos, “Fases del proceso
unificado” [En linea], Madrid España [Consulta: Abril de 2006],
192
Modelos de proceso de software
<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