Tema #3 - Estrategias para El Desarrollo de Sistemas (Hasta Este Punto Es El Exámen)

FACULTAD NACIONAL DE INGENIERÍA
INGENIERÍA DE SISTEMAS
INGENIERÍA INFORMÁTICA
MSc. Ing. Nelson Tapia Hinojosa

ANÁLISIS DE SISTEMAS
M Cs. Ing. Nelson Tapia Hinojosa

ESTRATEGIAS PARA EL
DESARROLLO DE SISTEMAS
3
M Sc. Ing. Nelson Tapia Hinojosa
DOCENTE EMERITO
4
5
Análisis de Sistemas
ESTRATEGIAS PARA EL
3.1. Introducción.
3.2. Paradigmas y Métodos para el desarrollo de
sistemas.
3.2.1. Método del ciclo de vida del desarrollo
de sistemas.
3.2.2. Modelo de cascada mejorado.
3.2.3. Modelo del proceso en cascada.
(ultima propuesta).
3.2.4. Modelo V.

ESTRATEGIAS PARA EL
3.2.5. Método del prototipo de sistemas.

3.2.6. Método de construcción de prototipos
(mejorado).
3.2.7. Técnicas de la cuarta generación.
3.2.8. Paradigmas de los ciclos iterativos.
3.3. Metodologías Agiles.
3.3.1. Desarrollo en Espiral.
3.3.2. Método de desarrollo XP.
3.3.3. SCRUM.
3.3.4. KAMBAN.
.

ESTRATEGIAS PARA EL
3.5. Combinación de paradigmas

3.6. Características de las estrategias
3.6.1. Método de análisis estructurado.
3.6.2. El paradigma orientado a objeto.
3.7. Métodos para requerimientos en las estrategias.
3.7.1. El método para la determinación de
requerimientos organizacional ISAC.
3.7.2. El Método VORD.
3.9. Herramientas CASE.

Estrategias para el desarrollo de sistemas
3.1. Introducción.
Hoy en día las organizaciones son

más eficientes con la incorporación
de la tecnología y en el ámbito de
los sistemas de información y
muchas han implantado sistemas
de información (S.I.) automatizados
en diferentes categorías
3.1. Introducción.
La empresa en sus diferentes estructuras

(Departamentos) como: Inventarios,
Mercadotecnia, Almacenes, Ventas,
Producción, Recursos Humanos, Gerencia,
etc., realizan diferentes transacciones
manuales y por lo tanto la necesidad de
contar con nuevos sistemas de información
es menester y urgente para mejorar estos
procesos.
3.1. Introducción.
Los sistemas de información

basados en computadora sirven
para diversas finalidades que van
desde el procedimiento de las
transacciones de una organización
hasta proveer de la información
necesaria para decisiones.
3.1. Introducción.
Los antecedentes señalados están

representados por distintos enfoques de
desarrollo de sistemas de información.
3.2. Paradigmas para el desarrollo de sistemas.
Frecuentemente se describe a los

paradigmas del desarrollo de
sistemas de información basados
en computadora como métodos
alternativos en vez de métodos
complementarios.
No existe un método único, que

solucione la crisis de desarrollo de
sistemas, sin embargo, puede
desarrollarse una disciplina para el
desarrollo de sistemas, combinando
métodos, herramientas para
automatizar y finalmente una filosofía
predominante de coordinación, control
y gestión.
Para la Ingeniería de Software el paradigma es

una agrupación de métodos, herramientas y
procedimientos con el fin de describir un
modelo.
Si ninguno de los paradigmas se adecua al

problema por resolver, entonces el
desarrollador se verá obligado a combinar los
paradigmas o definir uno nuevo.
Un paradigma es un conjunto de
proposiciones para resolver un
problema.
Por lo tanto podemos decir que un
paradigma es un modelo que permite
producir programas con unas
directrices específicas.
Paradigmas: Representan un enfoque

particular o filosofía para la
construcción del software. No es mejor
uno que otro sino que cada uno tiene
ventajas y desventajas.
Paradigmas: Representan un enfoque

particular o filosofía para la construcción del
software. No es mejor uno que otro sino que
cada uno tiene ventajas y desventajas.
También existen modelos híbridos, los cuales

combinan elementos diferentes modelos según
las necesidades existentes.
Las estrategias se llama paradigmas y consiste en

seleccionar un modelo de proceso para el desarrollo del
software y depende de:
• La naturaleza del proyecto
• El nivel de experiencia informática del usuario.
• Los recursos disponibles ($us, t , RRHH)
• La duración estimada del proyecto
• El nivel de precisión en las estimaciones.
• Los métodos a emplear.
• Las herramientas de desarrollo a utilizar
• Los controles.
• Las entregas de los productos que se requieren.
3.2.1. Método del ciclo de vida del desarrollo de sistemas

La primera descripción formal del modelo

de cascada se cita por Winston Royce en
1970.
Es el paradigma más antiguo y fue el más

utilizado durante la hegemonía del
método estructurado. El número de etapas
propuestas varía de acuerdo al proyecto a
desarrollar, aunque existen etapas
comunes para este paradigma.
Este paradigma concibe las fases de

desarrollo como proceso independientes en
el tiempo, es decir, no se pueden realizar de
manera simultánea; cada fase empieza
cuando se ha terminado la fase anterior y
para poder pasar a otra fase es necesario
haber conseguido todos los objetivos de la
etapa previa.
Las etapas de este paradigma se desarrollan

en forma secuencial y cuando se detecta
algún error en alguna etapa, lo más
probable será abandonar todo lo avanzado
y regresar a la etapa primera de análisis de
requisitos del sistema; pues, aunque la
vuelta atrás por etapas es posible, ésta
demanda mucho esfuerzo y puede terminar
en el colapso.
El mayor inconveniente del

modelo de cascada es que solo
se pasa a la siguiente fase
cuando se completa la anterior,
por tanto no es posible volver
atrás si se encuentra algún error
en las etapas posteriores.
3.2.2. Modelo de la Cascada Mejorado.

3.2.3. Modelo del proceso en Cascada (Ultima propuesta)

3.2.4. Modelo en V.
3.2.4. Modelo en V.
3.2.4. Modelo en V.
El mayor inconveniente del modelo de

cascada es que solo se pasa a la siguiente
fase cuando se completa la anterior, por
tanto no es posible volver atrás si se
encuentra algún error en las etapas
posteriores. El Modelo V aporta opciones de
evaluación del software en cada etapa de
manera inversa.
3.2.4. Modelo en V.
El Modelo V aporta opciones de evaluación

del software en cada etapa de manera
inversa, crea la planificación de las pruebas
y los casos de pruebas para verificar y
validar el producto según los requisitos de
la etapa. Por ejemplo, en la etapa de
recogida de requisitos, el equipo de
evaluadores prepara las pruebas de caso
correspondientes a los requisitos.
3.2.4. Modelo en V.
Más tarde, cuando el producto se desarrolla

y está preparado para ser evaluado, las
pruebas de caso en esta etapa verifican el
software y su validez según sus requisitos.
Esto hace que tanto la verificación como la

validación vayan en paralelo. Este modelo
también se conoce como modelo de
validación y verificación.
3.2.5. Método de Prototipo de Sistemas

En el caso de la ingeniería más compleja, se

crea un prototipo antes de la construcción del
producto final. Esto tiene por objeto poner a
prueba los principios, verificar que el sistema
funciona, y obtenga reglamentación de diseño
para poder ajustar dicho diseño antes de
realizar los gastos más importantes.
El método de prototipos crea un modelo

informático y puede tomar una de las
siguientes formas: prototipo de papel y un
prototipo que funcione.
El prototipo se prueba y modifica cuando es

necesario, y los resultados se anotan en la
revisión de los bosquejos y los dibujos en
funcionamiento.
VENTAJAS:
• No modifica el flujo del ciclo de vida.

• Reduce el riesgo de construir productos que no
satisfagan las necesidades de los usuarios.
• Reduce costo y aumenta la probabilidad de éxito.
• Exige disponer de las herramientas adecuadas.
• Ofrece un mejor enfoque cuando el responsable
del desarrollo del software está inseguro de la
eficacia de un algoritmo.
DESVENTAJAS:
• Debido a que el usuario ve que el prototipo
funciona piensa que este es el producto
terminado.
• 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 mantenimiento
que tiene con el cliente.
El análisis y diseño de sistemas
3.2.6. Método de construcción de Prototipo.( mejorado)

VENTAJAS:
• Permiten el desarrollo de un sistema a partir de
requisitos poco claros o cambiantes. Esto
ocurre con cierta frecuencia en muchos
proyectos de software.
• Como información complementaria a los
requisitos constituyen un gran apoyo a las
estimaciones de esfuerzo de todas las áreas,
incluyendo proveedores.
VENTAJAS:
• Son más fáciles de abordar con los usuarios finales.
• El usuario participa más activamente en la
construcción del producto de software (La Solución),
ya que “lo puede ver” y, dependiendo del tipo de
prototipo, “utilizar” desde el primer momento.
• Se reduce el riesgo o la incertidumbre sobre la
implementación del software.
VENTAJAS:
• Su uso redunda en una mayor satisfacción
del usuario con el producto final, ya que él
o ella han participado activamente de su
diseño.
• Permite a todos los involucrados entender
bien y mejor el problema antes de la
implementación final.
DESVENTAJAS:
• El usuario quiere empezar a trabajar desde el primer
momento con el prototipo para solucionar su
problema particular, cuando el prototipo es solo un
modelo de lo que será el producto.
• Los prototipos generan o pueden generar problemas
si su presentación y discusión con los usuarios no es
controlada, puesto que son modelos inconclusos, los
usuarios suelen enfocarse en aspectos “superficiales”
del prototipo que los pueden dejar inconformes
luego de verlos por primera vez.
DESVENTAJAS:
• Es posible que se pierda mucho tiempo,
innecesariamente, tratando de hacer
entender al usuario la finalidad real de los
prototipos.
• Requiere participación activa del usuario, al
menos, para evaluar el prototipo. Y mucho
más involucramiento si queremos que
participe en su creación.
3.2.7. Técnicas de la Cuarta Generación (T4G).

El término T4G abarca un gran espectro de

herramientas software (S.W.). Donde la
herramienta genera automáticamente el código
fuente basándose en las especificaciones.
El paradigma T4G para la ingeniería se orienta

hacia la habilidad de especificar a un nivel que sea
próximo al lenguaje material o en una notación
que proporciones funciones significativas.
El dominio de los T4G está limitado a las

aplicaciones de los S.I. Comerciales de Toma
de decisiones y específicamente el Análisis de
Información y la obtención de informes en
grandes Bases de Datos.
Las T4G se ha usado muy poco en productos

de ingeniería y áreas de aplicación de
sistemas.
Actualmente un entorno para el desarrollo del

software que soporte T4G incluye las siguientes
herramientas:
• Lenguajes no procedimentales
• Consulta a base de datos
• Generación de informes
• Manipulación de datos
• Interacción y definición de pantallas
• Generación de códigos
• Capacidades gráficas de alto nivel
3.2.8. Paradigma de los Ciclos Iterativos.

En la práctica casi todos los proyectos no cubren todos

los requisitos en su primera versión, por lo que una vez
realizada una entrega se vuelve a abordar una versión
posterior que incluye nuevas funcionalidades.
Asumir que esto es así desde un principio es lo que

plantea el ciclo de vida iterativo: que una vez realizada
la integración o entrega de una versión, se volverá a la
fase de análisis para seguir avanzando en el desarrollo.
Este es uno de los modelos de desarrollo

orientado a objetos más antiguos que se
conocen hasta ahora. Se basa en la creación
de prototipos, cuyo código fuente era utilizado
posteriormente para la creación de otro
programa o la integración del mismo a una
herramienta más avanzada
En muchos casos, los prototipos

obtenidos eran tan buenos, que se
consideraban un producto final.
Este modelo también tiene características

tradicionales, como el hecho de que
también se siguen una serie de procesos
para su desarrollo completo: inicialización,
iteración y lista de control.
3.2.9. Paradigma de desarrollo incremental.

El modelo incremental combina elementos

del modelo en cascada con la filosofía
interactiva de construcción de prototipos.
Se basa en la filosofía de construir
incrementando las funcionalidades del
programa.
Este modelo aplica secuencias lineales de

forma escalonada mientras progresa el
tiempo en el calendario. Cada secuencia
lineal produce un incremento del software.
Cuando se utiliza un modelo incremental,
el primer incremento es a menudo un
producto esencial, sólo con los requisitos
básicos.
Este modelo se centra en la entrega de un

producto operativo con cada incremento.
Los primeros incrementos son versiones
incompletas del producto final, pero
proporcionan al usuario la funcionalidad
que precisa y también una plataforma para
la evaluación.
Otras estrategias de desarrollo.

3.3. Metodologías Agiles.
Por definición, las metodologías

ágiles son aquellas que permiten
adaptar la forma de trabajo a las
condiciones del proyecto,
consiguiendo flexibilidad e inmediatez
en la respuesta para amoldar el
proyecto y su desarrollo a las
circunstancias específicas del entorno.
57
El exámen es hasta este punto de avance

Tema #3 - Estrategias para El Desarrollo de Sistemas (Hasta Este Punto Es El Exámen)

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema #3 - Estrategias para El Desarrollo de Sistemas (Hasta Este Punto Es El Exámen)

Cargado por

Copyright:

Formatos disponibles

FACULTAD NACIONAL DE INGENIERÍA

MSc. Ing. Nelson Tapia Hinojosa

M Cs. Ing. Nelson Tapia Hinojosa

MSc. Ing. Nelson Tapia Hinojosa

3.2.5. Método del prototipo de sistemas.

MSc. Ing. Nelson Tapia Hinojosa

3.5. Combinación de paradigmas

MSc. Ing. Nelson Tapia Hinojosa

Hoy en día las organizaciones son

La empresa en sus diferentes estructuras

Los sistemas de información

Los antecedentes señalados están

3.2. Paradigmas para el desarrollo de sistemas.

Frecuentemente se describe a los

3.2. Paradigmas para el desarrollo de sistemas.

No existe un método único, que

3.2. Paradigmas para el desarrollo de sistemas.

Para la Ingeniería de Software el paradigma es

Si ninguno de los paradigmas se adecua al

3.2. Paradigmas para el desarrollo de sistemas.

3.2. Paradigmas para el desarrollo de sistemas.

Paradigmas: Representan un enfoque

3.2. Paradigmas para el desarrollo de sistemas.

Paradigmas: Representan un enfoque

También existen modelos híbridos, los cuales

3.2. Paradigmas para el desarrollo de sistemas.

Las estrategias se llama paradigmas y consiste en

3.2.1. Método del ciclo de vida del desarrollo de sistemas

3.2.1. Método del ciclo de vida del desarrollo de sistemas

La primera descripción formal del modelo

Es el paradigma más antiguo y fue el más

3.2.1. Método del ciclo de vida del desarrollo de sistemas

Este paradigma concibe las fases de

3.2.1. Método del ciclo de vida del desarrollo de sistemas

Las etapas de este paradigma se desarrollan

3.2.1. Método del ciclo de vida del desarrollo de sistemas

El mayor inconveniente del

3.2.2. Modelo de la Cascada Mejorado.

3.2.3. Modelo del proceso en Cascada (Ultima propuesta)

El mayor inconveniente del modelo de

El Modelo V aporta opciones de evaluación

Más tarde, cuando el producto se desarrolla

Esto hace que tanto la verificación como la

3.2.5. Método de Prototipo de Sistemas

3.2.5. Método de Prototipo de Sistemas

En el caso de la ingeniería más compleja, se

3.2.5. Método de Prototipo de Sistemas

El método de prototipos crea un modelo

El prototipo se prueba y modifica cuando es

3.2.5. Método de Prototipo de Sistemas

• No modifica el flujo del ciclo de vida.

3.2.5. Método de Prototipo de Sistemas

3.2.6. Método de construcción de Prototipo.( mejorado)

3.2.6. Método de construcción de Prototipo.( mejorado)

3.2.6. Método de construcción de Prototipo.( mejorado)

3.2.6. Método de construcción de Prototipo.( mejorado)

3.2.6. Método de construcción de Prototipo.( mejorado)

3.2.6. Método de construcción de Prototipo.( mejorado)

3.2.7. Técnicas de la Cuarta Generación (T4G).

3.2.7. Método de construcción de Prototipo.( mejorado)

El término T4G abarca un gran espectro de

El paradigma T4G para la ingeniería se orienta