resumen de los modelos prescriptivos del desarrollo de sistemas de información
TRANSCRIPT
INSTITUTO TECNOLÓGICO DE TUXTEPEC
“ “Fundamentos De Sistemas De Información”
Actividad:
Resumen
Tercer semestre Turno: Matutino
Grupo “A”
Presentado por: Correos: Fátima De Jesús Martínez López [email protected]
Iliana Pioquinto Barradas [email protected]
Itzayana Pérez Ibáñez [email protected]
Indira Said Santiago Santiago [email protected]
Graciela Avendaño Mendoza [email protected]
Mariano CDG [email protected]
Profesor:
Ma. De Los Ángeles Martínez Morales
7/10/2012
2
PROCESOS DEL CICLO DE VIDA
El proceso de vida se divide en dos etapas:
Las de los PROCESOS PRINCIPALES que son:
Adquisición
Suministro
Desarrollo
Explotación
mantenimiento
PROCESOS DE SOPORTE
Documentación
Gestión de configuración
Aseguramiento de calidad
Verificación
Validación
Revisión conjunta
auditoria
resolución de problemas
PROCESOS DE LA ORGANIZACIÓN
gestión
mejora
infraestructura
formación
proceso de adaptación
3
PROCESOS PRINCIPALES
Este proceso es útil a los desarrolladores, usuarios del software durante su ciclo de
vida
PRCESOS DE ADQUISICIÓN
Este proceso es sobre las tareas que el comprador, el cliente o el usuario realizan para
adquirir un sistema o producto (servicio) software. También en la Preparación y
publicación de una solicitud de ofertas.
En la Selección del suministrador del software. Y en la Gestión de los procesos desde
la adquisición hasta la aceptación del producto.
PROCESOS DE SUMINISTRO
Se inicia al preparar una propuesta para atender una petición de un comprador, o por la
firma de un contrato con el comprador para proporcionarle un producto software.
También identifica los procesos y recursos para gestionar bien el proyecto. Desarrolla
los planes del proyecto y ejecuta los planes del mismo hasta la entrega del producto
software al comprador.
PROCESOS DE DESARROLLO
Esta contiene las actividades realizadas por el desarrollador. Y se sigue una serie de
puntos como:
Implementación del proceso.
Análisis de requisitos del Sistema.
Diseño de la arquitectura del Sistema.
Análisis de los requisitos del Software.
Diseño de la arquitectura del Software.
Diseño detallado del software.
Codificación y prueba del Software.
Integración del software.
Prueba del software.
Integración del sistema.
4
Prueba del sistema.
Instalación del software.
Soporte del proceso de
aceptación del software.
PROCESO DE EXPLOTACIÓN
Se define a la explotación del software y del soporte del mismo. El sistema debe ser
operado de acuerdo con la documentación del usuario en su entorno previsto. Se
puede desarrollar un plan para llevar a cabo las actividades y tareas de este proceso.
También el proceso para comprobar el producto software en su entorno de operación,
enviando informes de problemas y peticiones de modificación al proceso de
mantenimiento.
PROCESO DE MANTENIMIENTO
El software o la documentación necesitan ser modificado, debido a problemas o a
necesidades de mejora o adaptación como: nuevos errores detectados, necesidad de
mejoras y migración a un nuevo entorno operativo.
PROCESO DE SOPORTE
Sirve de apoyo al resto de procesos.
PROCESOS DE DOCUMENTACIÓN
Registra la información producida por cualquier proceso o actividad del ciclo de vida.
También gestiona los documentos necesarios para todas las personas involucradas en
el software.
PROCESO DE GESTIÓN DE LA CONFIGURACIÓN
La configuración del software involucra: programas, documentación, y datos. En
aplicaciones grandes, la gestión de la configuración del software se convierte en un
problema.
PROCESO DE ASEGURAMIENTO DE LA CALIDAD
Aporta confianza en que los procesos y los productos Software del ciclo de vida
cumplen con los requisitos especificados y se ajustan a los planes establecidos. Y el
5
Aseguramiento de la calidad puede ser: interno o externo. Usa resultados de otros
procesos de apoyo: verificación, validación, auditorías, etc.
PROCESO DE VERIFICACIÓN
Existen dos tipos horizontal y vertical.
Verificación horizontal: si los productos software de cada fase del ciclo de vida
cumplen los requisitos impuestos sobre ellos en las fases previas.
Verificación vertical: ¿Estamos construyendo correctamente el producto?
PROCESO DE VALIDACIÓN
Indica si el sistema o software final cumple con las necesidades del usuario. También
se puede validar una especificación. Puede ser realizado por una organización de
servicios independiente (proceso de validación independiente).
PROCESODE REVISIÓN CONJUNTA
Evaluar el estado del software y sus productos en una actividad del ciclo de vida o fase
del proyecto. Se realiza durante todo el ciclo de vida: a nivel de gestión, a nivel de
gestión.
PROCESO DE AUDITORIA
Tipos de auditoría informática:
De explotación
De sistemas
De comunicaciones
De desarrollo de proyectos
De seguridad
Fraudes y delitos económicos producidos en las empresas (a veces por los
propios empleados, sin conocimiento de la dirección)
Problemas en privacidad y seguridad (auditoria de seguridad informática, tanto
lógica como física)
La corrección de los datos de entrada (auditoria informática de datos)
Problemas de diseño del sistema informático
6
LA INGENIERÍA DE SOFTWARE EN EL MODELO DE
DESARROLLO DEL SOFTWARE LIBRE
La ingeniería de software es aquella que crea y mantiene las aplicaciones tecnológicas
y lo principal es aplicar este software con el fin de que estos sean más rápidos, a
menor costo, y de mayor calidad.
El software libre es aquel que al ser obtenido puede ser usado, copiado, estudiado,
modificado y redistribuido libremente. El modelo de desarrollo del SL es atípico y no
convencional, se basa de un entorno distribuido y colaborar programando porciones del
software o en diferente tareas especificas, surgió de manera natural.
La evolución del modelo de desarrollo del software libre
Años 60-70
Necesidad de los mismos “informáticos”.
Programación en ASM y C.
El software se opone4 tal cual, si da problemas ellos mismos lo arreglan.
1972 : TCP-IP (protocolo)
1974 : PDP-11 (Unix de Berkley)
1975 : Emacs (entorno completo)
1976 : Vi (editor de texto)
Años 80
Requerimientos del movimiento, principalmente dev-tools y commapps.
Programación en C, C++ y lenguajes de scripting, gestionada en repositorios de
código.
Se establecen convenciones y estándares para documentación.
1981 : BSD 4.1 (OS)
1984 : Latex (procesador de textos)
1986 : CVS (control diversiones)
1987 : Perl (lenguaje)
1987 : GCC (compilador)
Años 90
Integración de muchos paquetes independientes y despliegue.
Aplicaciones afinadas y especializadas para laborar distribuida mente (Internet).
Automatas de pruebas y documentación.
7
1993: Debían y Slackware (distros de Linux)
1997: Doxygen (automatización de documentación a partir del código
fuente)
1998: APT (administrador de paquetes)
Actualmente
Software para diseno de software.
Desarrollo basado en MVC.
Herramientas de GESTION de trabajo en grupo.
Herramientas de apoyo para
GESTION de proyectos.
1998: Bugzilla (administración de errores y requerimientos).
2000: Umbrello (herramienta case)
2000: PhpGroupWare (gestión de proyectos)
2004: Ruby on Rails (framework dedesarrollo)
El modelo de desarrollo del software libre claro que encaja dentro de la ingeniería de
software, se fue adecuando de manera natural a través de los años, el modelo de
desarrollo del software libre también aporta a la ingeniería de software nuevas prácticas
que antes no eran siguiera imaginadas.
MODELO EN ESPIRAL
En una representación de la espiral encontramos lo que es la dirección de avance y el
esfuerzo acumulado.
Estrategia de resolución de problemas:
*Determinar objetivos, alternativas de solución y restricciones.
*Evaluar alternativas identificar riesgos proponer estrategias de resolución de riesgos.
*Encargo.
*Entrega de resultados.
*Recapitulación, propuestas de planificación.
*Verificación.
*Desarrollo.
8
El modelo en espiral también está formado por ventajas e inconvenientes.
Ventajas:
– Evaluación en cada fase que permite cambios de objetivos
– Funciona bien en proyectos de innovación.
Inconvenientes:
-La evaluación de riesgos es compleja
– Excesiva flexibilidad para algunos proyectos.
MODELO EVOLUTIVO:
*Es el modelo cuyas etapas consisten en expandir incrementos de un
producto de software operacional.
*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
9
-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 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.
Los evolutivos son modelos iterativos, permiten desarrollar versiones
cada vez más completas y complejas, hasta llegar al objetivo final
deseado; incluso evolucionar más allá, durante la fase de operación.
10
Los modelos «iterativo incremental» y «espiral» (entre otros) son dos
de los más conocidos y utilizados del tipo evolutivo.
MODELO INCREMENTAL
El Modelo Incremental combina elementos del MLS con la filosofía
interactiva de construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño,
Código y Prueba. Sin embargo, para la producción del Software, se usa el
principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras
formas de programación. Con esto se mantiene al cliente en constante
contacto con los resultados obtenidos en cada incremento.
Es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades
reales. El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de
naturaleza interactiva pero se diferencia de aquellos en que al final de
cada incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con una
dotación de personal suficiente. Los primeros pasos los pueden realizar un
grupo reducido de personas y en cada incremento se añadir• personal, de
ser necesario. Por otro lado los incrementos se pueden planear para
gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:
- 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.
11
- Difícil de aplicar a los 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.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir transformando
un flujo de datos en un proceso comprendido por varias fases
secuenciales, siendo la entrada de cada una la salida de la anterior.
Esta arquitectura es muy común en el desarrollo de programas para el
intérprete de comandos, ya que se pueden concatenar comandos
fácilmente con tuberías (pipe).
También es una arquitectura muy natural en el paradigma de
programación funcional, ya que equivale a la composición de funciones
matemáticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de
mandatos obtenidos del usuario por medio de una interfaz alfanumérica.
Características
- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con
cierta frecuencia.
- El usuario se involucre más.
- Difícil de evaluar el costo total.
- Difícil de aplicar a los 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.
12
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial,
ya que se implementa la funcionalidad parcial.
- También provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada
realimentado, reduciendo sus desventajas sólo al ámbito de cada
incremento.
- Permite entregar al cliente un producto más rápido en comparación del
modelo de cascada.
- Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.
- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel
administrativo como técnico.
Desventajas:
- El modelo Incremental no es recomendable para casos de sistemas de
tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o
de alto índice de riesgos.
- Requiere de mucha planeación, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto.
EL PROCESO UNIFICADO DE DESARROLLO DE
SOFTWARE
El Proceso Unificado es un proceso de desarrollo de software conjunto de
actividades necesarias para transformar los requisitos del usuario en un
sistema software. El Proceso Unificado se repite a lo largo de una serie de
ciclos que constituyen la vida de un sistema. Cada ciclo constituye una
versión del sistema.
RUP es un marco genérico que puede especializarse para una variedad
de tipos de sistemas, diferentes áreas de aplicación, tipos de
organizaciones, niveles de aptitud y diferentes tamaños de proyectos.
13
RUP está basado en componentes. El software esta formado por
componentes software interconectados a través de interfaces.
RUP está dirigido por casos de uso, centrado en la arquitectura, y es
iterativo e incremental.
El Proceso Unificado no es simplemente un proceso, sino un marco de
trabajo extensible que puede ser adaptado a organizaciones o proyectos
específicos. De la misma forma, el Proceso Unificado de Rational, también
es un marco de trabajo extensible, por lo que muchas veces resulta
imposible decir si un refinamiento particular del proceso ha sido derivado
del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres
suelen utilizarse para referirse a un mismo concepto.
Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los
requisitos funcionales y para definir los contenidos de las iteraciones. La
idea es que cada iteración tome un conjunto de casos de uso
o escenarios y desarrolle todo el camino a través de las distintas
disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por
casos de uso es el rup.
Un caso de uso es un fragmento de funcionalidad del sistema que
proporciona un resultado de valor a un usuario. Los casos de uso modelan
los requerimientos funcionales del sistema.
• Todos los casos de uso juntos constituyen el modelo de casos de uso.
• Los casos de uso también guían el proceso de desarrollo (diseño,
implementación, y prueba). Basándose en los casos de uso los
desarrolladores crean una serie de modelos de diseño e implementación
que llevan a cabo los casos de uso. De este modo los casos de uso no
solo inician el proceso de desarrollo sino que le proporcionan un hilo
conductor, avanza a través de una serie de flujos de trabajo que parten de
los casos de uso.
14
HERRAMIENTAS CASE.
Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas
que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante
todos los pasos del Ciclo de Vida de desarrollo de Software.
CASE se define también como:
1. Conjunto de métodos, utilidades y técnicas que facilitan la automatización del
ciclo de vida del desarrollo de sistemas de información, completamente o en
alguna de sus fases.
2. La sigla genérica para una serie de programas y una filosofía de desarrollo
software que ayuda a automatizar el ciclo de visa de desarrollo de los sistemas.
3. Una innovación en la organización, un concepto avanzado en la evolución de
tecnología con un potencial efecto profundo en la organización. Se puede ver al
CASE como la unión de las herramientas automáticas de software y las
metodologías de desarrollo de software formales.
CLASIFICACION DE LAS HERRAMIENTAS CASE:
No existe una única clasificación de herramienta CASE y, en ocasiones, es difícil
incluirlas en una clase determinada. Podrían clasificarse atendiendo a:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se
pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado):
Abarca todas las fases del ciclo de vida del desarrollo de sistemas. Son
llamadas también CASE workbeanch.
2. Herramientas de alto nivel, U-CASE (Upper CASE, CASE superior) o front-end,
orientadas a la automatización y soporte de las actividades desarrolladas
durante las primeras fases del desarrollo: análisis y diseño.
15
3. Herramienta de bajo nivel, L-CASE (Lower CASE, CASE inferior) o back-end,
dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juego de herramientas o Tools-CASE, son el tipo más simple de herramientas
CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se
encontrarían las herramientas de reingeniería, orientadas a la fase de
mantenimiento.
Tipo de Case
Ventajas Desventajas
I – Case Integra el ciclo de vida. Permite lograr importantes
mejoras de productividad a mediano plazo. Permite un eficiente soporte
al mantenimiento de sistemas. Mantiene la consistencia de
los sistemas a nivel corporativo.
No es tan eficiente para soluciones simples, sino para soluciones complejas. Depende del Hardware y
del Software. Es costoso.
Upper Case Se utiliza en plataforma PC, es aplicable a diferentes entornos, Menor costo
Permite mejorar la calidad de los sistemas, pero no mejora la productividad. No permite la integración
Lower Case Permite lograr importantes mejoras de productividad a corto plazo. Permite un eficiente soporte
al mantenimiento de sistemas.
No garantiza la consistencia de los resultados a nivel corporativo. No garantiza la eficiencia
del Análisis y Diseño. No permite la integración
del ciclo de vida.