INSTITUTO
TECNOLÓGICO DE CD. ALTAMIRANO
“MODELOS PRESCRIPTIVOS DEL DESARROLLO DE
SISTEMAS DE INFORMACIÓN.”
MATERIA
FUNDAMENTOS DE
SISTEMAS DE INFORMACIÓN
Maestra:
L.I YURY
NUÑEZ MEDRANO.
Que presentan:
IVÁN
MARTINEZ MALDONADO
ADILENE
ESTRADA GARCIA
FERNANDO
SANTAMARIA BERRUM
ESTUDIANTE DE LA CARRERA:
INGENIERIA EN
INFORMATICA
Periodo:
27 de
enero -
05 de julio de 2014
FUNDAMENTOS
DE SISTEMAS DE INFORMACIÓN
UNIDAD
III: MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN.
3.1
MODELO EN CASCADA.
En Ingeniería
de software
el desarrollo en cascada, también llamado modelo en cascada, es
el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio
de cada etapa debe esperar a la finalización de la etapa anterior.[1]La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.
Un ejemplo de una metodología de desarrollo en cascada es:
- Análisis
de requisitos.
- Diseño
del Sistema.
- Diseño
del Programa.
- Codificación.
- Pruebas.
- Implantación.
- Mantenimiento.
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: 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.
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 debidos 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.
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 en acomodar posibles incertidumbres que pueden existir al
comienzo de muchos productos.
- El cliente debe tener paciencia. Hasta llegar a
las etapas finales del proyecto, no estará disponible una versión
operativa del programa. Un error importante no detectado hasta que el
programa este funcionando puede ser desastroso.
La
ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software.
Modelo V (Ministerio
de Defensa de Alemania, 1992):
El Modelo V tiende a ser muy relacionado
con el Modelo de Cascada puesto que es una evolución del mismo.
Puede notarse que su primera mitad
es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer
pruebas e integración asociado a cada una de las etapas de la mitad anterior.
Se puede identificar una ventaja
principal con respecto al Modelo Cascada más simple, y se refiere a que este
modelo involucra chequeos de cada una de las etapas del modelo de cascada.
Desventajas:
- El
riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de
aceptación al final de cada etapa, las pruebas comienzan a efectuarse
luego de haber terminado la implementación, lo que puede traer como
consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero.
- El
modelo no contempla la posibilidad de retornar a etapas inmediatamente
anteriores, cosa que en la realidad puede ocurrir.
- Se toma
toda la complejidad del problema de una vez y no en iteraciones o ciclos
de desarrollo, lo que disminuye el riesgo.
A pesar de todo lo antes mencionado,
definitivamente se trata de un modelo más robusto y completo que el Modelo de
Cascada, y puede producir software de mayor calidad que con el modelo de
cascada.
3.2
MODELO EVOLUTIVO.
MODELOS EVOLUTIVOS
¿Qué es un modelo de desarrollo?
Un modelo de desarrollo es una representación
abstracta de un proceso de software, cada modelo representa el proceso de
desarrollo de software de una manera en particular. A pesar de estar definidos
claramente, no representan necesariamente la realidad de cómo se debe
desarrollar el software, sino que establece un enfoque común. Un modelo puede
ser modificado y adaptado de acuerdo a las necesidades del software en
desarrollo.
En forma general podemos clasificar los
modelos de desarrollo en 3 grupos:
1. El modelo en cascada. Considera las
actividades fundamentales del proceso de especificación, desarrollo, validación
y evolución, y los representa como fases separadas del proceso, tales como la
especificación de requerimientos, el diseño del software, la implementación,
las pruebas, etcétera.
2. Desarrollo evolutivo. Este enfoque
entrelaza las actividades de especificación, desarrollo y validación. Un
sistema inicial se desarrolla rápidamente a partir de especificaciones
abstractas. Éste se refina basándose en las peticiones del cliente para
producir un sistema que satisfaga sus necesidades.
MODELOS EVOLUTIVOS
Ø Es el modelo cuyas etapas consisten en expandir
incrementos de un producto de software operacional donde la dirección de la
evolución la dicta la experiencia con el sistema
Ø El cliente recibe pequeños incrementos del sistema a
medida que van siendo desarrollados : distribución incremental
Características:
• Gestionan bien la naturaleza
evolutiva del software
• Son iterativos: construyen
versiones de software cada
vez más completas
Se adaptan bien:
• Los cambios de requisitos del
producto
• Fechas de entrega estrictas
poco realistas
• Especificaciones parciales del
producto
VENTAJAS
•
ES INTERACTIVO
-Con cada incremento se entrega al cliente un producto operacional , que
puede evaluarlo
•
PERSONAL
- Permite variar el personal asignado a cada interacción
•
GESTION RIESGOS
TECNICOS
- Por ejemplo disponibilidad de hardware especifico
INCONVENIENTES
•
La primera
interacción puede plantear los mismos problemas que un modelo lineal secuencial
Incrementos
ž El modelo evolutivo de desarrollo no implica
necesariamente entregas incrementales
ž Entregas incrementales implican no solo código, si no
también manuales de uso
ž Los incrementos deben ser unidades auto contenidas.
Etapas
del modelo evolutivo
Etapas
de modelo evolutivo
-Entregar al cliente algo útil
-Medir el valor agregado del incremento
-Ajustar el diseño y los objetivos en base a
las mediciones
Sin
rigor el modelo evolutivo degenera rápidamente en codificar y corregir.
3.3
MODELOS ESPECIALES.
Modelos
especiales
Son dos que
es el Incremental y el concurrente
INCREMENTAL:
Cambian los elementos del modo lineal
secuencial (aplicados repetidamente) con la filosofía interactiva de
construcción de prototipos.
El modelo incremental aplica secuencias
lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software.
Por ejemplo, el software de tratamiento de
textos desarrollando con el paradigma i8ncremental podría extraer funciones de
gestión de archivos básicos y de producción de documentos en el primer
incremento; funciones de edición más sofisticadas y de producción de documentos
en el segundo incremento; corrección ortográfica y gramatical en tercero; y una
función avanzada de esquema de pagina en el cuarto. Se deberían tener en cuenta
que el flujo del proceso de cualquier incremento puede incorporar el paradigma
de construcción de prototipos.
Cuando se utiliza un modelo incremental el
primer incremento es un producto esencial. Es decir se afrontan requisitos
básicos pero muchas funciones suplementarias (algunas conocidas otras no). Como
un resultado de utilización y/o de evaluación, se desarrolla un plan para el
incremento.
El plan afronta la modificación del
producto central a fin de cumplir mejor las necesidades del cliente y la
entrega de funciones, y características adicionales. Este proceso se repite
siguiendo la entrega de cada incremento, hasta que se elabore el producto
completo.
El desarrollo incremental es
particularmente útil cuando la dotación de personal no está disponible para una
implementación completa en la fecha limitada que se haya establecido para el
proyecto.
CONCURRENTE:
se puede sentar en forma de esquema como una serie de actividades técnicas
importantes, tareas y estados asociados a ellas. Por ejemplo, la actividad de
ingeniería definida para el modelo en espiral, se lleva acabo invocando las
tareas siguientes: modelado de construcción de prototipos y/o análisis,
especificación de requisitos y diseño.
El modelo de proceso unificado
Proporciona una representación esquemática de una actividad dentro del
modelo de proceso concurrente. La actividad, análisis se puede encontrar en uno
de los estados destacados en cualquier momento dado. De forma similar, otras
actividades (por ejemplo el diseño o comunicación con el cliente) se pueden
representar de una forma analógica.
Todas las actividades existen concurrentemente, pero residen en estados
diferentes, por ejemplo, al principio del proyecto la actividad de comunicación
con el cliente ha finalizado su primera interacción y esta en el estado de
cambios en espera. La actividad de análisis (que esta en el estado ninguno
mientras que se iniciaba la comunicación inicial con el cliente) ahora hace una
transacción al estado bajo desarrollo. Sin embargo, si el cliente indica que se
deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo
desarrollo al estado cambios en espera.
El modelo de proceso concurrente define una serie de acontecimientos que
dispararan transiciones de estado a estado para cada una de las actividades de
la ingeniería del software. Por ejemplo, durante las primeras etapas del
diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera
la corrección del modelo de análisis de sucesos, que dispara la actividad de
análisis del estado hecho al estado cambios en espera.
El modelo de proceso concurrente se utiliza a menudo como el paradigma de
desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se
compone de un conjunto de componentes funcionales. Cuando se aplica a
cliente/servidor, el modelo de proceso concurrente define actividades en dos
dimensiones: una dimensión de sistemas y una dimensión de componentes. Los
aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño,
ensamblaje y uso.
Las dimensiones de componentes se afrontan con dos actividades: diseño y realización.
La concurrencia se logra de dos formas 1.- las actividades de sistemas y de
componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado
a objetos.
2.- una aplicación cliente/servidor típica se implementa con muchos
componentes, cada uno de los cuales se pueden diseñar y realizar concurrente
mente En realidad, el modelo del proceso concurrente es aplicable a todo tipo
de desarrollo de software y proporciona una imagen exacta del estado actual de
un proyecto.
3.4
EL PROCESO UNIFICADO EN DESARROLLO DE SOFTWARE.
El proceso
unificado provee un enfoque disciplinado en la asignación de tareas y
responsabilidades dentro de una organización de desarrollo. Su meta es asegurar
la producción de software de muy alta calidad que satisfaga las necesidades de
los usuarios finales, dentro de un calendario y presupuesto predecible.
El Proceso Unificado tiene dos dimensiones (Figura 1):
·
Un eje horizontal que representa el tiempo y muestra
los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento
·
Un eje vertical que representa las disciplinas, las
cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza.
La primera dimensión representa el aspecto dinámico del proceso conforme se
va desarrollando, se expresa en términos de fases, iteraciones e hitos
(milestones).
La segunda dimensión representa el aspecto estático del proceso: cómo es
descrito en términos de componentes del proceso, disciplinas, actividades, flujos
de trabajo, artefactos y roles.
El Proceso Unificado se basa en componentes (component-based), lo que
significa que el sistema en construcción está hecho de componentes de software
interconectados por medio de interfaces bien definidas (well-defined
interfaces).
El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la
preparación de todos los planos del sistema. De hecho, UML es una parte
integral del Proceso Unificado, fueron desarrollados a la par.
Los aspectos distintivos del Proceso Unificado están capturados en tres
conceptos clave: dirigido por casos de uso (use-case driven), centrado en la
arquitectura (architecture-centric), iterativo e incremental. Esto es lo que
hace único al Proceso Unificado.
El Proceso Unificado es dirigido por casos de uso.
Un sistema de software se crea para servir a sus usuarios. Por lo tanto,
para construir un sistema exitoso se debe conocer qué es lo que quieren y
necesitan los usuarios prospectos.
El término usuario se refiere no solamente a los usuarios humanos, sino a
otros sistemas. En este contexto, el término usuario representa algo o alguien
que interactúa con el sistema por desarrollar.
Un caso de uso es una pieza en la
funcionalidad del sistema que le da al usuario un resultado de valor. Los casos
de uso capturan los requerimientos funcionales. Todos los casos de uso juntos
constituyen el modelo de casos de uso
el cual describe la funcionalidad completa del sistema. Este modelo reemplaza
la tradicional especificación funcional del sistema. Una especificación
funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que
el sistema debe hacer? La estrategia de casos de uso puede ser definida
agregando tres palabras al final de la pregunta: ¿por cada usuario? Estas tres
palabras tienen una implicación importante, nos fuerzan a pensar en términos
del valor a los usuarios y no solamente en términos de las funciones que sería
bueno que tuviera. Sin embargo, los casos de uso no son solamente una
herramienta para especificar los requerimientos del sistema, también dirigen su
diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo.
El Proceso Unificado está centrado en la arquitectura.
El papel del arquitecto de sistemas es similar en naturaleza al papel que
el arquitecto desempeña en la construcción de edificios. El edificio se mira
desde diferentes puntos de vista: estructura, servicios, plomería,
electricidad, etc. Esto le permite al constructor ver una radiografía completa
antes de empezar a construir. Similarmente, la arquitectura en un sistema de
software es descrita como diferentes vistas del sistema que está siendo
construido.
El concepto de arquitectura de software involucra los aspectos estáticos y
dinámicos más significativos del sistema. La arquitectura surge de las
necesidades de la empresa, tal y como las interpretan los usuarios y otros
stakeholders, y tal y como están reflejadas en los casos de uso. Sin embargo,
también está influenciada por muchos otros factores, tales como la plataforma
de software en la que se ejecutará, la disponibilidad de componentes
reutilizables, consideraciones de instalación, sistemas legados, requerimientos
no funcionales (ej. desempeño, confiabilidad). La arquitectura es la vista del
diseño completo con las características más importantes hechas más visibles y
dejando los detalles de lado.
El Proceso Unificado es Iterativo e Incremental.
Desarrollar un producto de software comercial es una tarea enorme que puede
continuar por varios meses o años. Es práctico dividir el trabajo en pequeños
pedazos o mini-proyectos. Cada mini-proyecto es una iteración que finaliza en
un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los
incrementos se refieren a crecimiento en el producto. Para ser más efectivo,
las iteraciones deben estar controladas, esto es, deben ser seleccionadas y
llevadas a cabo de una manera planeada.
Los desarrolladores basan su selección de qué van a implementar en una
iteración en dos factores. Primero, la iteración trata con un grupo de casos de
uso que en conjunto extienden la usabilidad del producto. Segundo, la iteración
trata con los riesgos más importantes. Las iteraciones sucesivas construyen los
artefactos del desarrollo a partir del estado en el que fueron dejados en la
iteración anterior.
3.5
MODELO DE PROCESO DE SOFTWARE IEEE.
INTRODUCCIÓN.
A través de la historia de la ingeniería en
software ha evolucionado un conjunto de conceptos fundamentales de diseño de
software, aunque el grado de interés en cada concepto ha variado en los años,
han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software
fundamentos sobre el cual pueden aplicarse métodos de diseño más elaborados.
El diseño de software juega un papel importante en
el desarrollo de software lo cual permite al ingeniero de software producir
varios modelos del sistema o producto de que se va a construir el mismo que
forman una especie de plan de la solución de la aplicación.
Estos modelos pueden evaluarse en relación con su
calidad y mejorarse antes de generar código, de realizar y pruebas y de que los
usuarios finales se vean involucrados a gran escala. El diseño es el sitio en
el que se establece la calidad del software.
Diseño es definido como: “El proceso de definición
de la arquitectura, componentes, interfaces y otras características de un
sistema o componente que resulta de este proceso” [IEEE610.12-90]
DESARROLLO.
Se
desarrolla y se centra su diseño, con una existencia lógica de instrucciones
sobre un soporte. Es un producto que no se gasta con el uso como otros y
repararlo no significa restaurarlo al estado original, sino corregir algunos
defectos de origen, lo que significa que el producto entregado posee defectos,
que podrán ser solucionados en la etapa de mantenimiento.
El
diccionario IEEE estándar de ingeniería en software dice que son software: “Los
programas de ordenador, los procedimientos y, posiblemente la documentación
asociada y los datos relativos a la operación del sistema informática”. No
limitándose al código.
Da
la definición de calidad como “el grado con el que un sistema componente o
proceso cumple con los requisitos especificados y las necesidades o
expectativas del cliente o usuario”.
Pressman
la define como “concordancia del software con los requisitos explícitamente
establecidos con los estándares de desarrollo expresamente fijados y con los
requisitos implícitos, no establecidos formalmente que desea el usuario”.
La
aplicación de estándares de desarrollo y de normas para el software permitirá
lograr calidad técnica del mismo. La calidad del software se puede ver a nivel
de proyecto aplicando las técnicas de evaluación y control de la calidad del
software a lo largo del ciclo de vida.
3.6
HERRAMIENTAS CASE.
Día a día la
tecnología avanza, surgen nuevas y mejores formas de hacer las cosas, siempre
buscando métodos más efectivos, confiables, con mayor calidad y menos riesgos.
Las herramienta CASE nacen para auxiliar a los desarrolladores de software, lo
que permite el apoyo computarizado en todo o en parte del ciclo de vida del
desarrollo de un sistema de software. En este blog conoceras que son las
herramientas case, como surgieron y con que proposito fueron creadas asi como
sus ventajas y desventajas.
Las herramientas
CASE han surgido para dar solución a varios problemas inherentes al diseño del
software, principalmente nacen para solucionar el problema de la mejora de la
calidad del desarrollo de sistemas de mediano y gran tamaño, y en segundo
término, por el aumento de la productividad.
Para que los
negocios sean competitivos deben llevar una buena calidad de los productos o
servicios que ofrece. La mejora de la calidad se logra al reducir
sustancialmente muchos de los problemas de análisis y diseño relacionados con
los proyectos, como la lógica en el diseño y la coherencia de módulos, entre
otros. Y la mejora de la productividad se consigue a través de la
automatización de tareas como la generación y reutilización de código, que son
puntos importantes a considerar en una herramienta CASE.
HISTORIA DE LAS HERRAMIENTAS CASE
Las Herramientas CASE se iniciaron con un
procesador de palabras que fue usado para crear y manipular documentación. Los
70’s vieron la introducción de técnicas gráficas y diagramas de flujo de datos.
Sobre este punto, el diseño y especificaciones en forma pictórica han sido
extremadamente complejos y consumían mucho tiempo para realizar cambios.
La introducción de las herramientas CASE para
ayudar en este proceso ha permitido que los diagramas puedan ser fácilmente
creados y modificados, mejorando la calidad de los diseños de software. Los
diccionarios de datos, un documento muy usado que mantiene los detalles de cada
tipo de dato y los procesos dentro de un sistema, son el resultado directo de
la llegada del diseño de flujo de datos y análisis estructural, hecho posible a
través de las mejoras en las Herramientas CASE.
Pronto se reemplazaron los paquetes gráficos por
paquetes especializados que habilitan la edición, actualización e impresión en
múltiples versiones de diseño. A diario, las herramientas gráficas integradas
con diccionarios de base de datos para producir poderosos diseños y desarrollar
herramientas, podrían sostener ciclos completos de diseño de documentos. Como
un paso final, la verificación de errores y generadores de casos de pruebas
fueron incluidos para validar el diseño del software. Todos estos procesos
pueden saberse integrados en una simple herramienta CASE que soporta todo el
ciclo de desarrollo. La primera herramienta comercial se remonta a 1982, aunque
algunos especialistas indican que algunos ejemplos de herramientas para
diagramación ya existían. No fue sino hasta 1985 cuando las herramientas CASE
se volvieron realmente importantes en el proceso de desarrollo de software. Los
proveedores prometieron a la Industria que muchas actividades serían
beneficiadas por la ayuda de las CASE.
Las
herramientas CASE son un conjunto de herramientas y métodos asociados que
proporcionan asistencia automatizada en el proceso de desarrollo del software a
lo largo de su ciclo de vida.
Fueron desarrolladas para
automatizar esos procesos y facilitar las tareas de coordinación de los eventos
que necesitan ser mejorados en el ciclo de desarrollo de software.
OBJETIVOS
·
Aumentar
la productividad de las áreas de desarrollo y mantenimiento de los sistemas
informáticos.
Aumentar
la productividad de las áreas de desarrollo y mantenimiento de los sistemas
informáticos.
·
Mejorar
la calidad del software desarrollado.
Mejorar
la calidad del software desarrollado.
·
Reducir
tiempos y costos de desarrollo y mantenimiento del software.
Reducir
tiempos y costos de desarrollo y mantenimiento del software.
·
Mejorar
la gestión y dominio sobre el proyecto en cuanto a su planificación, ejecución
y control.
Mejorar
la gestión y dominio sobre el proyecto en cuanto a su planificación, ejecución
y control.
·
Mejorar el archivo de datos
(enciclopedia) de conocimientos (know-how) y sus facilidades de uso, reduciendo
la dependencia de analistas y programadores.
·
Automatizar:
·
El
desarrollo del software
El
desarrollo del software
·
La
documentación
La
documentación
·
La
generación del código
La
generación del código
·
El
chequeo de errores
El
chequeo de errores
·
La
gestión del proyecto
La
gestión del proyecto
Permitir:
·
La
reutilización (reusabilidad) del software
La
reutilización (reusabilidad) del software
·
La
portabilidad del software
La
portabilidad del software
·
La
estandarización de la documentación
La
estandarización de la documentación
·
Integrar
las Mejorar el archivo de datos (enciclopedia) de conocimientos .
Integrar
las Mejorar el archivo de datos (enciclopedia) de conocimientos .
·
Facilitar
la utilización de las distintas metodologías que desarrollan la propia
ingeniería del software.
Facilitar
la utilización de las distintas metodologías que desarrollan la propia
ingeniería del software. 