Licenciatura en Administración Policial

LISTA DE COTEJO PARA TRABAJOS Y TAREAS

DATOS GENERALES DEL PROCESO DE EVALUACIÓN

Nombre(s) del alumno(s) y/o Equipo: Firma del alumno(s):
Pérez Flores Michael Fernando

Producto: Nombre o tema del Trabajo: Modelos de Ciclo Fecha:

Resultado único de Vida de los Proyectos 03/08/2020

Asignatura: Grupo: Periodo:

Administración y evaluación de proyectos. A OCTAVO SEMESTRE

Nombre del Docente: Firma del Docente:

Maglorio Navidad Jiménez

INSTRUCCIONES

Revisar las características que se solicitan y se calificara en la columna “Valor Obtenido” el valor asignado con respecto al “Valor del Reactivo”.
En la columna “OBSERVACIONES” se pondrá las indicaciones que puedan ayudar al alumno a saber cuales son las condiciones no cumplidas.

Valor del
reactivo Característica a cumplir (Reactivo) Valor Obtenido OBSERVACIONES

Es entregado puntualmente. Hora y

10%
fecha solicitada (indispensable)

Presentación (alineación del cuero del

10%
texto, etc.), Ortografía

DESARROLLO

80% Investigación correcta y opinión personal

100% CALIFICACIÓN:
 SECRETARIA DE
SEGURIDAD CIUDADANA DE LA
CDMX

UNIVERSIDAD DE LA CIUDAD DE
MEXICO

PROFESOR: Maglorio Navidad Jiménez

ASIGNATURA: Administración y evaluación de

proyectos.

ALUMNO: Pérez Flores Michael Fernando

LICENCIATURA: Administración Policial Sexta

Generación

GRUPO: “A”

TRABAJO: Modelos de Ciclo de Vida de los

Proyectos
CICLO DE LA VIDA DEL SOFTWARE

Ciclo de vida del software. Es el proceso que se sigue para construir, entregar y
hacer evolucionar el software, desde la concepción de una idea hasta la entrega y
retiro del sistema.

MODELO DE CASCADA
GRAFICA DE CICLO DE VIDA

Ingeniería de
sistemas Especificación del sistema

Análisis
Especificación del Software

Diseño
arquitectónico
Documentos de arquitectura del sistema

Diseño detallado
Especificaciones de módulos y funciones

Codificación
Código fuente

Pruebas de unidades
Módulos utilizables

Pruebas de sistema
Sistema aceptado

Explotación y
mantenimiento

También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su origen en

el "Modelo de cascada" ingeniado por Winston Royce, aunque omite los muchos
bucles de este último. El Modelo Lineal Secuencial sugiere un enfoque sistemático
o más bien secuencial del desarrollo de software que comienza en un nivel de
 sistemas y progresa con el análisis, diseño,
codificación, pruebas y mantenimiento.

El modelo en cascada (o waterfall model en inglés) fue el primer método

ampliamente utilizado en la industria del software. Como enfoque tradicional, no es
repetitivo en contraste con los modelos ágiles con sprints simples, pero puede ser
complementado con bucles de retroalimentación y loopbacks. Todavía se utiliza
hoy en día en varias versiones si los requisitos y características de un software
pueden ser claramente definidos durante la fase conceptual.

FECHA APROXIMADA DE CREACIÓN.

La primera mención de un modelo en fases se remonta a Winston Royce. En su
ensayo "Managing the Development of Large Software Systems" (Gestión del
desarrollo de grandes sistemas de software) describió un método de desarrollo
para grandes proyectos de software, que se divide en fases ya en 1970. También
criticó este enfoque y propuso una alternativa que se asemeja a la creación de
prototipos. Royce se refería al "Nine Phase Stage-Wise Model" de Herbert
Benington, publicado en 1956. Mientras que Benington preveía nueve fases,
Royce las redujo a siete. El término modelo en cascada no fue utilizado por
ninguno de los dos. Su uso se basa en un libro de 1976, que trata principalmente
de los requisitos para software.

GRUPOS DE PROCESOS DENTRO DEL MODELO DE CASCADA

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: el proceso de recopilación de los

requisitos se centra e intensifica especialmente en el software. El ingeniero de
software (Analistas) debe comprender el ámbito de la información del software, así
como la función, el rendimiento y las interfaces requeridas.

Análisis de requerimientos: En la fase de análisis de requisitos, las funciones del

software se diseccionan y estructuran de modo que los elementos funcionales
individuales y las unidades funcionales puedan separarse entre sí. El análisis de
necesidades tiene por objeto examinar la viabilidad e importancia de las funciones.
Los resultados de esta fase son las especificaciones que contienen los requisitos
que hay que desarrollar.

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.
Codificación: el diseño debe traducirse en una forma legible para la maquina. El
paso de codificación realiza esta tarea. Si el diseño se realiza de una manera
detallada la codificación puede realizarse mecánicamente.

Prueba: una vez que se ha generado el código comienza la prueba del programa.
La prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.

Mantenimiento: el software sufrirá cambios después de que se entrega al cliente.

Los cambios ocurrirán debido a que hayan encontrado errores, a 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.

AREAS DE CONOCIMIENTO EN QUE SE DIVIDE MODELO DE CASCADA

Documentación: La documentación del software impregna el ciclo de vida del

mismo. Es la parte más visible de su proceso. Sin ella, no se puede dar
mantenimiento al software, los usuarios no pueden entrenar y prácticamente no
pueden utilizar el software, los desarrolladores nuevos tendrían que reinventar la
rueda en el desarrollo del software. La documentación del software es su
manifestación más importante. Es la guía para el laberinto del software.

Gestión de configuración: Se denomina Gestión de la Configuración al conjunto

de procesos destinados a asegurar la calidad de todo producto obtenido durante
cualquiera de las etapas del desarrollo de un Sistema de Información (S.I.), a
través del estricto control de los cambios realizados sobre los mismos y de la
disponibilidad constante de una versión estable de cada elemento para toda
persona involucrada en el citado desarrollo. Estos dos elementos (control de
cambios y control de versiones de todos los elementos del S.I.) facilitan también el
mantenimiento de los sistemas al proporcionar una imagen detallada del sistema
en cada etapa del desarrollo. La gestión de la configuración se realiza durante
todas las fases del desarrollo de un sistema de información, incluyendo el
mantenimiento y control de cambios, una vez realizada la puesta en producción.

Aseguramiento de calidad: El Aseguramiento de la Calidad del Software es el

conjunto de actividades planificadas y sistemáticas necesarias para aportar la
confianza que el software satisfará los requisitos dados de calidad. Este
aseguramiento se diseña para cada aplicación antes de comenzar a desarrollarla y
no después.
La validación: El proceso de evaluación de software durante o al final del proceso
de desarrollo para determinar si cumple los requisitos especificados.

La verificación: Proceso de evaluación de software para determinar si los

productos de una determinada fase de desarrollo satisfacen las condiciones
impuestas en el inicio de esa fase.

Revisión Conjunta: Las revisiones de software se usan como modelo para la

amplificación de defectos y para ilustrar la generación y detección de errores
durante los pasos de diseño preliminar, diseño detallado y codificación del proceso
de ingeniería del software.

BENEFICIOS / DESVENTAJAS
Algunas ventajas y desventajas del modelo en cascada
Ventajas
 Debido a la estructura lógica del modelo, a menudo se pueden evitar
errores conceptuales.
 El modelo conduce a una extensa documentación técnica, que es un alivio
para los nuevos programadores y desarrolladores y también es útil en la
fase de prueba.
 El progreso del proyecto puede ser monitoreado usando metas.
 El coste total puede estimarse con relativa precisión si no hay conflictos.

Desventajas
 Los conflictos, bugs y errores de programación a veces conducen a un
aumento de los costes y a una cantidad considerable de tiempo. Lo mismo
se aplica si los clientes no están satisfechos.
 Las especificaciones que se hacen inicialmente son a menudo difíciles de
entender para los clientes porque son más abstractas de lo que se supone
que el software debe hacer. Especialmente en proyectos subcontratados,
esto puede ser una desventaja decisiva, ya que la fecha de lanzamiento
debe posponerse y el mercado puede haber cambiado durante este tiempo.
 La entrega del software lleva más tiempo porque los departamentos no
trabajan simultáneamente y cada fase sólo puede comenzar cuando se ha
completado la fase anterior.
MODELO EN ESPIRAL
GRAFICA DE CICLO DE VIDA

El desarrollo o modelo en espiral es un enfoque de desarrollo de software que

puede ser considerado como una respuesta a los inconvenientes del desarrollo en
cascada. El modelo en espiral describe el ciclo de vida de un software por medio
de espirales, que se repiten hasta que se puede entregar el producto terminado. El
desarrollo en espiral también se conoce como desarrollo o modelo incremental. El
producto se trabaja continuamente y las mejoras a menudo tienen lugar en pasos
muy pequeños.

Una característica clave del desarrollo en espiral es la minimización de los riesgos

en el desarrollo de software, lo que podría resultar en un aumento de los costes
totales, más esfuerzo y un lanzamiento retardado. Estos riesgos son
contrarrestados por el enfoque incremental, haciendo primero prototipos, que
luego pasan al menos una vez, por las fases de desarrollo de software.
El desarrollo en espiral es genérico y puede combinarse con otros métodos de
 desarrollo clásicos y ágiles, por lo que también se
denomina modelo o desarrollo de segundo orden.

FECHA DE CREACIÓN

El desarrollo en espiral es un modelo de ciclo de vida del software definido por

primera vez por Barry Boehm en 1986, utilizado generalmente en la ingeniería de
software. Las actividades de este modelo se conforman en una espiral, en la que
cada bucle o iteración representa un conjunto de actividades.

GRUPOS DE PROCESOS DENTRO DEL MODELO DE ESPIRAL

El modelo de desarrollo en espiral se caracteriza por los siguientes ciclos

(también cuadrantes):
• Objetivo y determinación alternativa: Los objetivos se determinan
conjuntamente con el cliente. Al mismo tiempo, se discuten posibles
alternativas y se especifican las condiciones marco (por ejemplo, sistemas
operativos, entornos y lenguajes de programación).

• Análisis y evaluación de riesgos: Se identifican y evalúan los riesgos

potenciales. También se evalúan las alternativas existentes. Los riesgos
son registrados, evaluados y luego reducidos utilizando prototipos,
simulaciones y softwares de análisis. En este ciclo, existen varios prototipos
como plantillas de diseño o componentes funcionales.

• Desarrollo y prueba: Los prototipos se amplían y se añaden

funcionalidades. El código real es escrito, probado y migrado a un entorno
de prueba varias veces hasta que el software pueda ser implementado en
un entorno productivo.

• Planificación del siguiente ciclo: El siguiente ciclo se planifica al final de

cada etapa. Si se producen errores, se buscan soluciones, y si una
alternativa es una mejor solución, se prefiere en el siguiente ciclo.

La fuerza impulsora más importante del desarrollo en espiral es el análisis y la

evaluación de riesgos. Cualquier riesgo que amenace el proyecto debe ser
identificado desde el principio. El progreso del proyecto depende decisivamente de
cómo se puedan eliminar los riesgos. El proyecto se considera exitoso sólo
cuando no hay riesgos. El objetivo del ciclo es producir un producto en continua
mejora. El software o la aplicación se perfecciona constantemente. El modelo en
espiral es incremental, pero no necesariamente repetitivo. Las repeticiones
 ocurren sólo cuando los riesgos, errores o
conflictos amenazan el proyecto. Entonces el
producto tiene que pasar por un ciclo de nuevo, llamado una
iteración o repetición.

BENEFICIOS / DESVENTAJAS

• El modelo de desarrollo en espiral se utiliza a menudo para proyectos más

grandes que están sujetos a riesgos. Dado que estos riesgos tienen un
impacto monetario directo, el control de los presupuestos de los clientes y
de las empresas promotoras es fundamental. El modelo en espiral se utiliza
especialmente en los nuevos entornos técnicos, ya que éstos suponen un
riesgo.

• Los conflictos entre los requisitos de un software y su diseño se evitan

eficazmente mediante el enfoque cíclico, ya que los requisitos pueden
comprobarse constantemente y, si es necesario, modificarse.

• Se puede obtener feedback de los usuarios, desarrolladores y clientes en

las primeras fases del proyecto. Sin embargo, esta estructura también
requiere una gestión que tenga en cuenta los ciclos del producto y pueda
responder rápidamente a los riesgos. El control de tales proyectos es, por lo
tanto, relativamente complejo y también requiere una buena documentación
para que se registren todos los cambios.

• Aunque el software se prueba bajo varios aspectos durante el ciclo de

desarrollo y prueba (unidad, prueba de aceptación e integración), a menudo
sucede que los prototipos se transfieren al sistema de producción. Por lo
tanto, existe el riesgo de que se introduzcan otros errores e incoherencias
conceptuales en el producto final posterior.

• En los lugares donde se toman decisiones sobre los ciclos siguientes,

existe el riesgo de que se formen bucles y el proyecto tarde más tiempo si
se toman decisiones equivocadas. Por esta razón, las alternativas y su
evaluación son importantes.
MODELO DE PROTOTIPOS
DIAGRAMA DE CICLO DE VIDA

También conocido como desarrollo con prototipación o modelo de desarrollo

evolutivo, se inicia con la definición de los objetivos globales para el software,
luego se identifican los requisitos conocidos y las áreas del esquema en donde es
necesaria más definición.

Es básicamente prueba y error dado que si al usuario no le gusta una parte del
prototipo significa que la prueba fallo por lo cual se debe corregir el error que se
tenga hasta que el usuario quede satisfecho. Además, debe ser construido en
poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero
pues a partir de que este sea aprobado se puede iniciar el verdadero desarrollo
del software. Pero eso si al construir el prototipo nos asegura que nuestro software
sea de mejor calidad, además de que su interfaz sea de agrado para el usuario.

FECHA DE CREACION

En los años 70s, surgieron proyectos grandes, pero con requisitos inestables. En
los 80s, la Ingeniería de Software solucionaron este problema dando lugar a la
 “construcción de prototipos”, el modelo de de ciclo
de vida de dichos prototipos fue propuesto por
Hassan Gomaa en 1984.

ETAPAS DE LA IS CUBIERTAS EN EL MODELO DE PROTOTIPOS:

Descripción: Recolección de requisitos, Diseño rápido.

Desarrollo: Construcción del prototipo, Evaluación, Refinamiento, Producto.
Mantenimiento: Operación y mantenimiento. 

Esta metodología es no secuencial, basado en la construcción de simulaciones o

modelos ejecutables de aplicaciones más extensos, requiere de la participación
directa del cliente en la construcción del software requerido.

EL PROTOTIPO SIRVE COMO MECANISMO PARA IDENTIFICAR LOS

REQUISITOS DEL SOFTWARE, Y SU CONSTRUCCIÓN SUELE LLEVAR LAS
SIGUIENTES ETAPAS:

·Recolección de requisitos: El programador/ingeniero de software y el cliente

definen los objetivos globales del software, y aquéllos más específicos que se
desean destacar con el prototipo.

·Diseño rápido: Centrado en los aspectos del software visible al usuario (por
ejemplo, interfaz de usuario, entradas y salidas…).

·Construcción del prototipo.

·Evaluación: Se realiza por el cliente y usuarios, lo que permitirá concretar y
refinar los requisitos del software a desarrollar.

·Refinamiento: Se produce un proceso iterativo en el que el prototipo es refinado

para que satisfaga las necesidades del cliente, al tiempo que facilita al ingeniero
de software un mejor conocimiento del sistema.

·Producto: En la mayoría de los casos este sistema refinado (piloto) hay que
desecharlo y hacer uno nuevo. Por ello, el desarrollo de un prototipo se debe
planificar con el acuerdo expreso del cliente.

·Operación y mantenimiento: En esta fase se realiza ya la instalación y

mantención del software, la complejidad en este caso resulta menor ya que en las
etapas anteriores los usuarios han trabajado con el sistema al momento de hacer
las pruebas de prototipos. Si existiese el caso en el cual se requiera
mantenimiento entonces el proceso de prototipado es repetido y se definirá un
nuevo conjunto de requerimientos.
Ventajas:
 Permite la construcción del sistema con requisitos poco claros o cambiantes
 El cliente recibe una versión del sistema en muy poco tiempo, por lo que lo
puede evaluar, probar e, incluso, empezar a utilizarlo
 Se pueden introducir cambios en las funcionalidades del sistema en
cualquier momento
 Involucra al usuario en la evaluación de la interfaz de usuario
 Se reduce el riesgo y la incertidumbre sobre el desarrollo
 Los cambios iníciales durante el desarrollo de un proyecto son menos
costosos que si se realizan en etapas tardías
 Genera signos visibles de progreso, que se utilizan cuando existe una
demanda en la velocidad del desarrollo
 Permite entender bien el problema antes de la implementación final

Desventajas:
 Administración difícil: Dicha dificultad radica en manejar el prototipo como
un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista
cual era su propósito.
 Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas
pueden considerar al prototipo como el sistema final cuando aún es
incompleto e inadecuado.
 El desarrollador y el cliente tienen poca comunicación al inicio del proceso.
 Surgen cambios imprevistos que retrasan el progreso del prototipo.

CUADRO COMPARATIVO DE MODELOS DE CICLO DE VIDA

CONCLUSIÓN

La metodología de cascada ordena rigurosamente las etapas del ciclo del

software, es decir en este modelo se tienen que terminar las fases en un orden, Lo
que puedo mencionar es que la modelo cascada es un modelo que al llevarse a
cabo se debe de llevar fase por fase para poder pasar a la siguiente etapa.
El modelo de cascada es exitoso cuando se tienen bien especificados los
requerimientos del software y se conozcan las herramientas a utilizar, este modelo
también nos permite realizar una organización más fácil de comprender tratando
de no mezclar las diferentes fases del modelo y así nos permite organizar el tipo
de proyecto que pretende solucionar es decir donde se conozcan todos los
requisitos especificados durante su ejecución.
El prototipo del modelo en espiral para la ingeniería de software es en la
actualidad el enfoque más realista para el desarrollo de software y de sistemas a
gran escala. Utiliza un enfoque evolutivo para la ingeniería de software,
permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en
cada nivel del modelo en espiral. 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.
FUENTES DE CONSULTA

https://uv-mdap.com/programa-desarrollado/bloque-i-el-ciclo-de-vida-del-
proyecto/presentacion-del-ciclo-de-vida-del-proyecto/#:~:text=Qu%C3%A9%20es
%20el%20ciclo%20de%20vida%20del%20Proyecto%3A%20el%20ciclo,hasta
%20que%20el%20Proyecto%20finaliza.

https://techlandia.com/importancia-documentacion-software-sobre_538552/

https://www.monografias.com/trabajos99/gestion-configuracion-del-
software/gestion-configuracion-del-software.shtml

https://dankocs2012.blogspot.com/2012/12/aseguramiento-de-la-calidad-de-
software.html#:~:text=El%20Aseguramiento%20d

https://es.qwe.wiki/wiki/Software_verification_and_ validation

https://ingsoftware2020.webcindario.com/tercera-unidad/garantia-de-calidad-del-
software/revisiones-del-software.html

https://es.ryte.com/wiki/Modelo_en_cascada%20es,del%20software%20hasta
%20su%20entrega.Cascada#:~:text=El%20modelo%20en%20

https://es.ryte.com/wiki/Modelo_en_Espiral

https://ingsoftwarei2019.blogspot.com/2019/03/investigacion-de-metodologia-
prototipo.html