El documento detalla un marco lógico para la adquisición y mantenimiento del software, describiendo procesos secuenciales y metodologías de desarrollo, como el modelo en cascada y el modelo espiral. Se destacan las etapas desde el análisis y diseño hasta la implementación y mantenimiento, abordando retos como la comunicación entre analistas y usuarios y la importancia del feedback. Además, se discuten las críticas a los métodos tradicionales y se propone el prototipado como una estrategia para ajustar requerimientos de manera iterativa.

1. ING.Wilfredo Montero M.

2.  “Una aproximación lógica a la adquisición, el
suministro, el desarrollo, la explotación y el
mantenimiento del software”
IEEE 1074
 “Un marco de referencia que contiene los
procesos, las actividades y las tareas
involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software,
abarcando la vida del sistema desde la definición
de los requisitos hasta la finalización de su uso”
ISO 12207-1

4. FABREGAS:
1- Requerimientos
2- Análisis/Diseño
3- Construcción
4- Pruebas
5- Producción/Mantenimiento
SENN:
1- Investigación Preliminar
2- Determ. de Requerimientos.
3- Diseño del Sistema
4- Desarrollo del Software
5- Prueba del Sistema
6- Implantación y Evaluación
PRESSMAN:
1- Análisis
2- Diseño
3- Codificación
4- Prueba
5- Mantenimiento
EN GENERAL USAREMOS:
1- Análisis
2- Diseño
3- Implementación
4- Mantenimiento

6. • Implantación Ascendente
• Las fases deben sucederse de manera Secuencial
• El usuario no ve resultados, sino hasta el final
• El usuario o el ambiente pueden cambiar las
especificaciones originales del sistema.
• Presenta numerosos problemas Analista-Usuario
• Manejable como proyecto

7. EL USUARIO:
FASE 1
FASE 2
FASE 3
FASE N
FASE N + 1

8. ?El usuario
y
su
Sistema
Definitivo.

9. Esto no es lo
que yo
esperaba...

10. Y al final del ciclo de Desarrollo del
sistema.....
¿ Será que no supe
explicarles mis
requerimientos ?

11. Y al final del ciclo de Desarrollo del
sistema.....
Tal vez ellos
no me
entendieron...

12. ?
Y al final del ciclo de Desarrollo del
sistema.....

13. No siempre se definen los requerimientos
en forma:
Completa
Correcta y
Consistente

14. Sr. Usuario:
Tiene que leerse
esto, esto, esto...
A veces resulta difícil para
el usuario, revisar todas las
especificaciones
Analista

15. Sistemas II.
ANALISIS
IMPLEMENTACION
DISEÑO
MANTENIMIENTO

16. Sistemas II.
1. ANALISIS:
1.1. Estudio Preliminar
1.2. Levantamiento de Información
1.3. Definición del Problema
1.4. Elaboración del Modelo Funcional del Sistema actual
1.5. Determinación de Requerimientos
1.6. Descripción y Evaluación de Alternativas
1.7. Aprobación de alternativas

17. Sistemas II.
2.DISEÑO
2.1. Elaborar Modelo Funcional del Sistema Propuesto
2.2. Diseño Lógico
2.3. Elaboración y Presentación del prototipo del Sistema
2.4. Aprobación del Sistema Propuesto

18. Sistemas II.
3. IMPLEMENTACION
3.1. Desarrollo del Software
3.2. Prueba del Sistema
3.3. Puesta en Marcha
¿ Qué significa poner en
Marcha un Sistema ?

19. Sistemas II.
PUESTA EN MARCHA:
Actividad de traslado de una aplicación probada a un ambiente de producción
- Acondicionamiento de locales
- Organización del Cliente
- Entregar aplicación probada
- Elaborar datos en Vivo
- Adiestramiento
- Carga de datos en vivo
- Entrega de documentación
- Asignar Responsabilidades
- Determinar FIN de la instalación

21.  Este, aunque es más comúnmente conocido como
modelo en cascada es también llamado «modelo
clásico», «modelo tradicional» o «modelo lineal
secuencial».

22.  CRITICAS
 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

23.  Los procesos iterativos pueden ayudar a desvelar
metas del diseño en el caso de clientes que no saben
cómo definir lo que quieren.

24.  Observaciones:
 Se evitan proyectos largos y se entrega “Algo de
valor” a los usuarios con cierta frecuencia
 El usuario se involucra más
 Difícil de evaluar el coste total
 Difícil de aplicar a sistemas transaccionales que
tienden a ser integrados y a operar como un todo
 Requiere gestores experimentados
 Los errores en los requisitos se detectan tarde.
 El resultado puede ser muy positivo.

25.  Consiste en iterar en la fase de análisis tantas veces como
sea necesario, mostrando prototipos al usuario para que
pueda indicarnos de forma mas eficiente los requisitos del
sistema.

26.  Observaciones:
 No modifica el flujo del ciclo de vida
 Reduce el riesgo de construir productos que
no satisfagan las necesidades de los usuarios
 Reduce costos y aumenta la probabilidad de éxito
 Exige disponer de las herramientas adecuadas
 No presenta calidad ni robustez
 Una vez identificados todos los requisitos
mediante el prototipo, se construye el producto
de ingeniería.

27.  PARA QUE SEA EFECTIVO:
 Debe ser un sistema con el que se pueda
experimentar
 Debe ser comparativamente barato (< 10%)
 Debe desarrollarse rápidamente
 Énfasis en la interfaz de usuario
 Equipo de desarrollo reducido
 Herramientas y lenguajes adecuados
“El prototipado es un medio excelente para recoger el
‘feedback’ (realimentación) del usuario final”

28.  PELIGROS DEL PROTOTIPO
 El cliente ve funcionando lo que para él es la
primera versión del prototipo que ha sido
construido con “plastilina y alambres”, y puede
desilusionarse al decirle que el sistema aun no ha
sido construido.
 El desarrollador puede caer en la tentación de
ampliar el prototipo para construir el sistema
final sin tener en cuenta los compromisos de
calidad y de mantenimiento que tiene con el
cliente.

29.  Proporciona potencial para desarrollo rápido de versiones
incrementales. En el modelo Espiral el software se construye
en una serie de versiones incrementales. En las primeras
iteraciones la versión incremental podría ser un modelo en
papel o bien un prototipo.

30. En cada vuelta o iteración hay que tener en cuenta:
 Los Objetivos: qué necesidad debe cubrir el producto.
 Alternativas: las diferentes formas de conseguir los
objetivos de forma exitosa, desde diferentes puntos de vista
como pueden ser:
 Características: experiencia del personal, requisitos a
cumplir, etc.
 Formas de gestión del sistema.
 Riesgo asumido con cada alternativa.
 Desarrollar yVerificar: Programar y probar el software.

31.  Observaciones
 Trata de mejorar los ciclos de vida clásicos y prototipos.
 Permite acomodar otros modelos
 Incorpora objetivos de calidad y gestión de riesgos
 Elimina errores y alternativas no atractivas al comienzo
 Permite iteraciones, vuelta atrás y finalizaciones rápidas
 Cada ciclo empieza identificando:
▪ Los objetivos de la porción correspondiente
▪ Las alternativas
▪ Restricciones
 Cada ciclo se completa con una revisión que incluye todo
el ciclo anterior y el plan para el siguiente.

32.  Reconocimiento explícito de las diferentes
alternativas.
 Identificación de riesgos para cada alternativa
desde el comienzo.
 Al dividir el proyecto en ciclos, al final de cada
uno existe un acuerdo para los cambios que
hay que realizar en el sistema.
 El modelo se adapta a cualquier tipo de
actividad adicional.

34.  Principios
 Existen similitudes entre distintos sistemas de un mismo dominio
de aplicación
 El software puede representarse como una combinación de módulos
 Diseñar aplicaciones = especificar módulos + interrelaciones
 Los sistemas nuevos se pueden caracterizar por diferencias respecto a
los antiguos
 Reduce tiempos y costes de desarrollo
 Aumenta la fiabilidad
 Dificultad para reconocer los componentes potencialmente reutilizables
 Dificultad de catalogación y recuperación
 Problemas de motivación
 Problemas de gestión de configuración.

36.  Se define el sistema utilizando un lenguaje
formal.
 La implementación es automática, asistida por
el ordenador.
 La documentación se genera de forma
automática.
 El mantenimiento se realiza “por
sustitución” no mediante “parches”.
 Dificultad en la participación del usuario.
 Diseños poco optimizados.