INSTITUTO TECNOLOGICO

SUPERIOR DE CENTLA
ING. SISTEMAS COMPUTACIONALES

FUNDAMENTOS DE DESARROLLO DE
SISTEMAS

MAESTRO: WILVER POTENCIANO MORALES

ALUMNA: CHRISTIAN JOVANA TZEC HERNANDEZ

1
 INDICE

• INTRODUCCION=======================• 4
• MODELO EN CASCADA================= • 5
• DESCRIPCION======================== • 6
• ESTRUCTURA=========================• 7
• CARACTERISTICA===================== • 10
• VENTAJAS============================ • 11
• DESVENTAJAS======================== • 12
• MODELO ESPIRAL===================== • 13
• DESCRIPCION======================== • 14
• ESTRUCTURA======================== • 15
• CARACTERISTICAS==================== • 19
• VENTAJAS============================ • 20
• DESVENTAJAS======================== • 21
• MODELO INCREMENTAL=============== • 22
• DESCRIPCION ======================= • 23
• ESTRUCTURA======================== • 24

2
• VENTAJAS============================ • 25
• PROCESO DEL DESARROLLO UNIFICADO==== • 26
• DESCRIPCION======================== • 27
• ESTRUCTURA=========================• 28
• CARACTERISTICAS==================== • 32
• PROCESO DEL SOFTWARE PERSONAL=== • 33
• DESCRIPCION======================== • 34
• PRINCIPIOS========================== • 36
• OBJETIVOS ========================== • 37
• DESVENTAJAS======================== • 38
• VENTAJAS============================ • 39
• NIVELES============================= • 40
• CONCLUSION========================= • 42
• BIBLIOGRAFIA======================== • 43

3
 INTRODUCCION
Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo
y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho
mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir
un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se
denominan el ciclo de vida del software y en cada caso, en función de cuales sean las
características del proyecto, se configurará el ciclo de vida de forma diferente.
Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación
de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estará
influida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las
diferentes fases como un apartado especial para recalcar su importancia en el conjunto del
desarrollo del software.

4
5
 DESCRIPCION

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que
se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual
significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las
pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer
de nuevo el resto de las etapas.

Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.

6
 Estructura Modelo en Cascada(Bennington 1956)

El más conocido, esta basado en el ciclo convencional de una ingeniería, el

paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniería y Análisis del

Sistema

Análisis de los
Requisitos

Diseño

Codificación

Prueba

Mantenimiento

7
• 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 debe comprender el ámbito de la
información del software, así como la función, el rendimiento y las interfaces requeridas.

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

8
• Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación
realiza esta tarea.

• Prueba: 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.

9
 CARACTERISTICAS
• Es el más utilizado.

• Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos
intermedios.

• Para que el proyecto tenga éxito deben desarrollarse todas las fases.

• Las fases continúan hasta que los objetivos se han cumplido.

• Si se cambia el orden de las fases, el producto final será de inferior calidad.

10
 VENTAJAS
• La planificación es sencilla.

• La calidad del producto resultante es alta.

• Permite trabajar con personal poco cualificado.

11
 DESVENTAJAS
• No refleja realmente el proceso de desarrollo del software

• Se tarda mucho tiempo en pasar por todo el ciclo

• Perpetua el fracaso de la industria del software en su comunicación con el usuario final

• El mantenimiento se realiza en el código fuente

• Las revisiones de proyectos de gran complejidad son muy difíciles

• Impone una estructura de gestión de proyectos

12
13
 DESCRIPCION
Propuesto inicialmente por Boehm en 1988.

• Desarrollo cíclico (iterativo) donde en cada ciclo se llevan a cabo 4 tareas:

– Determinación de objetivos, alternativas y restricciones

– Evaluación de alternativas, análisis y control de riesgos.

– Desarrollo y verificación del producto.

– Planificación del siguiente ciclo (fase).

• Cada ciclo corresponde a una fase del proyecto.

.
14
Un representación típica de esta estructura:

15
16
 En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:

• Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.

• Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos
puntos de vista

– Características del producto.

– Formas de gestionar el proyecto.

• Restricciones:

– Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.

– Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

17
• Riesgos: Lista de riesgos identificados.

• Resolución de riesgos: La técnica más usada es la construcción de prototipos.

• Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.

• Planes: Lo que se va a hacer en la siguiente fase.

• Compromiso: Decisiones de gestión sobre como continuar.

Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los
requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el
producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase
de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

18
 CARACTERISTICAS
• En cada giro se construye un nuevo modelo del sistema completo.

• Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo)

• Mejor modelo para el desarrollo de grandes sistemas.

• El análisis de riesgo requiere la participación de personal con alta cualificación.

19
 VENTAJAS
• No necesita una definición completa de los requisitos para empezar a funcionar.

• Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.

• El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos
invertidos en una iteración (las anteriores iteraciones están bien).

• El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo
de subsanarlos.

20
 DESVENTAJAS
• Es difícil evaluar los riesgos.

• Necesita de la participación continua por parte del cliente.

• Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y
esto lleva tiempo.

21
22
 DESCRIPCION
• Combina elementos del modelo lineal con la filosofía de creación de prototipos.

• El primer incremento a menudo es un producto esencial (núcleo).

• A partir de la evaluación se planea el siguiente incremento y así sucesivamente.

• Es interactivo por naturaleza

• Es útil cuando el personal no es suficiente

• para la implementación completa

23
Representación grafica:

24
 VENTAJAS
• Se puede financiar el proyecto por partes

• Apropiado para proyectos grandes de larga duración

• No se necesita tanto personal al principio como para una implementación completa

25
26
 DESCRIPCION
El proceso unificado conocido como RUP, es un modelo de software que permite el desarrollo de
software a gran escala, mediante un proceso continuo de pruebas y retroalimentación, garantizando el
cumplimiento de ciertos estándares de calidad.

El proceso de desarrollo constituye un marco metodológico que define en términos de metas

estratégicas, objetivos, actividades y artefactos (documentación) requerido en cada fase de desarrollo.
Esto permite enfocar esfuerzo de los recursos humanos en términos de habilidades, competencias y
capacidades a asumir roles específicos con responsabilidades bien definidas.

27
Estructura del ciclo de vida del proceso de desarrollo unificado:

Fases

Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición.

28
Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas
o flujos de trabajos.

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

30
Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están
compuestos por artefactos.
Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso,
modelo de diseño, modelo de implementación, y modelo de prueba.

31
 CARACTERISTICAS
 Es iterativo e incremental

 Dirigido por los casos de uso

 Centrado en la arquitectura

 Enfocado en los riesgos

32
33
 DESCRIPCION
• En el año de 1995 el PSP fue propuesto por Watts Humphrey, este inicialmente estaba dirigido para
estudiantes.

• Para 1997 con el lanzamiento del libro "An Introduction to the Personal Software Process" el PSP ya
estaba destinado a los ingenieros.

• PSP se concentra en las prácticas de trabajo de los ingenieros en una forma individual.

• El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000
líneas de código.

34
• El PSP sirve para producir software de calidad, donde cada ingeniero debe trabajar en la necesidad de
realizar trabajo de calidad.

• El PSP se centra en la administración del tiempo y en la administración de la calidad a través de la

eliminación temprana de defectos.

• El PSP busca proporcionar un marco de trabajo para el personal involucrado en el proceso de desarrollo
de software.

• PSP demuestra cómo manejar la calidad desde el principio del trabajo.

35
 PRINCIPIOS DEL PSP
• Cada ingeniero es esencialmente diferente (Cada uno se encarga de su trabajo).

• Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos
bien definidos y medidos.

• Los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos, esto
mejorará la 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.

36
 OBJETIVOS DE PSP
• Lograr una disciplina de mejora continua en el proceso de desarrollo.

• Medir, estimar, planificar, seguir y controlar el proceso de desarrollo.

• Mejorar la calidad del proceso de desarrollo.

• En general, PSP provee calidad y productividad.

– El tiempo ahorrado en el testeo en base a una mejor calidad ahorra entre un 20 a 40 % del
desarrollo…

37
 DESVENTAJAS DE APLICAR
PSP
• El tiempo requerido para conocerlo

• El costo emocional por mantener una disciplina

• El ego del cambio en las costumbres

38
 VENTAJAS DE APLICAR PSP
• La idea de que ganamos en talento y habilidad

• La estimulación por nuevas ideas

• Una estructura de trabajo de mejoramiento personal

• Tomar control del propio trabajo

• La sensación de logro

• Una base mejorada para el trabajo en grupo (TSP)

• La convicción de que es lo mejor que se puede hacer

39
 NIVELES PSP
• El PSP define cinco actividades del marco de trabajo:

– PLANEACIÓN.

– DISEÑO DE ALTO NIVEL

– REVISIÓN DEL DISEÑO DE ALTO NIVEL

– DESARROLLO

– ANÁLISIS DE RESULTADOS

40
 NIVELES PSP
PSP 3
PSP 2.1
Plantillas de diseño (Marco de
trabajo y listas) Verificación de
PSP 2 tareas de diseño
-Revisión del diseño
-Revisión del código
PSP 1.1
PSP 1 -Planeación de tareas
-Planeación de tiempos
-Aptitud para estimar tamaño.
-Informe de pruebas
PSP 0.1
PSP 0 -Establecer estándares de código
-Practicas actuales desarrollo. (Definir “Líneas de código”)
-Mantener registros de tiempo -Proponer maneras de mejorar
trabajado en un proyecto. proceso desarrollo
-Registrar defectos encontrados -Realizar mediciones
-Registrar tipos de defectos.

41
 CONCLUSION
Después de explicar algunos de los modelos de ciclo de vida mas utilizados, ha de surgir
una pregunta a la cual daré una respuesta precisa y concreta.

¿Qué modelo de ciclo de vida elegir? y mi conclusión o mi respuesta seria que debemos de elegir el
modelo que mejor se adapte al proyecto que desarrollaremos. Podemos analizar para guiarnos al
momento de elegir , la complejidad del problema, el tiempo que disponemos para hacer la entrega
final, o si el usuario o cliente desea entrega parciales, la comunicación que existe entre el equipo
de desarrollo y el usuario y por ultimo que certeza tenemos que los requerimientos dado por el
usuario son correctos o complejos.

42
 BIBLIOGRAFIA
www.slideshare.net
www.lsi.ugr.es/~mvega/docis/respsp.pdf
www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP
www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10
www.es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3 -
www.biblioteca.co.cr/pdf/unidad12-4.pdf
www.alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf
www.scribd.com/doc/11468082/CICLO-DE-VIDA-Y-MODELO-EN-CASCADA -

43