SlideShare una empresa de Scribd logo
1 de 16
Descargar para leer sin conexión
MODELOS DE PROCESOS
Modelo primitivo
Los modelos de datos primitivos estaban absolutamente orientados al fichero:
las entidades se representan en registros (divididos en campos, que
representan sus propiedades), que se agrupan en ficheros. Las relaciones
entre entidades son únicamente aquellas que pueden ser representadas
usando directorios, por ejemplo índices y listas invertidas. Un ejemplo de
DBMS comercial de fichero, concretamente del tipo "lista invertida", es el CA-
DATACOMB de Computer Associates International.
Modelo en Cascada1(Bennington 1956):
El más conocido, está 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.
1 Ingeniería del Software: Un enfoque practico, Roger S. Presuman, 3ra Edición, Pag. 26-30.
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
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 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.
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:
ANALISIS DE
REQUERIMIENTOS
DISEÑO DEL
SISTEMA
DISEÑO
DETALLADO
IMPLEMENTACION
DE PROGRAMAS Y
PRUEBA DEL
SISTEMA
PRUEBA DE
ACEPTACION
OPERACION
Y MANTENIMIENTO
PRUEBA DE
INTEGRACION
Plan de
Pruebas
de Integración
Verificar diseño
Plan de
Pruebas
del Sistema
Validar requerimientos
Plan de
Pruebas
de Aceptación
Los planes de prueba son
el nexo entre el desarrollo
y la verificación
 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.
MODELOS BASADOS EN PROTOTIPOS
Este modelo consiste en un procedimiento que permite al equipo de desarrollo
diseñar y analizar una aplicación que representa el sistema que sería
implementado (McCracken y Jackson, 1982). Dicha aplicación, llamada
prototipo, está compuesta por los componentes que se desean evaluar
(i.e. las funciones principales). Las etapas del modelo son:
- Investigación preliminar.
- Colecta y refinamiento de los requerimientos y proyecto rápido:
- Análisis y especificación del prototipo.
- Diseño y construcción del prototipo.
- Evaluación del prototipo por el cliente.
- Renacimiento del prototipo.
- Diseño técnico.
- Programación y test.
- - Operación y mantenimiento.
http://rguerrero334.blogspot.es/1192897080/
Métodos formales
Un método formal es un camino a la construcción y análisis de modelos
matemáticos que permitan una automatización del desarrollo de sistemas
informáticos; se caracterizan por emplear técnicas y herramientas matemáticas
para lograr una facilitación a la hora de encarar la construcción o el análisis de
un modelo matemático de un sistema. Los métodos formales se refieren
entonces al uso de técnicas de la lógica y de la matemática discreta para
especificar, diseñar, verificar, desarrollar y validar programas. La palabra
“formal” se deriva de la lógica formal, ciencia que estudia el razonamiento
desde el análisis formal de acuerdo con su validez o no validez, y omite el
contenido empírico del razonamiento para considerar sólo la forma
estructurada sin materia. Los métodos formales más rigurosos aplican estas
técnicas para comprobar los argumentos utilizados para justificar los requisitos,
u otros aspectos de diseño e implementación de un sistema complejo.
En la lógica formal como en los métodos formales el objetivo es el mismo,
“reducir la dependencia de la institución y el juicio humanos para evaluar
argumentos” (Kiniry & Zimmerman, 2008). Los métodos menos rigurosos
enfatizan en la formalización y renuncian a la computación, definición que
implica un amplio espectro de técnicas, y una gama igualmente amplias de
estrategias. La interacción de las técnicas y estrategias de muchos métodos
formales, en determinados proyectos, se limita por el papel que interpretan y
por los recursos disponibles para su aplicación (García et al., 2006).
Se puede decir también que un método formal es una técnica basada en
matemáticas, usada para describir sistemas de hardware o software, Wing,
Jeannette M. (1990). Los métodos formales permiten representar la
especificación del software, verificación y diseño de componentes mediante
notaciones matemáticas. El uso de métodos formales permite plantear de
manera clara la especificación de un sistema, generando modelos que definen
el comportamiento en términos del “qué debe hacer” y no del “cómo lo hace”.
Gracias al correcto proceso de especificación, se pueden verificar propiedades
derivadas de cada módulo mediante técnicas de razonamiento asociadas a los
modelos formales, como probadores de teoremas y verificadores de modelos
Hall (1996). Para los procesos de especificación se reconoce las siguientes
clasificaciones:
1. Especificaciones basadas en lógicas de primer orden y teoría de
conjunto: Permiten especificar el sistema mediante un concepto formal de
estados y operaciones sobre estados. Los datos y relaciones/funciones se
describen en detalle y sus propiedades se expresan en lógica de primer orden.
La semántica de los lenguajes está basada en la teoría de conjuntos. Los
métodos de este tipo más conocidos son: VDM, Z, B, OCL.
Niveles de los métodos formales
• Especificación formal: Es una descripción de un sistema que utiliza
notaciones matemáticas para describir precisamente las propiedades que dicho
sistema debe tener, sin preocuparse por la forma de obtener estas
propiedades: “describe lo que el sistema debe hacer sin decir como se va
hacer”.
Algunas de las ventajas que podemos nombrar sobre una especificación formal
son las siguientes:
• Prototipado: Las especificaciones formales pueden llegar a ser ejecutables.
• Corrección del programa: Verificación automática y formal de que el
programa funciona correctamente.
• Reusabilidad: Posibilidad de usar la especificación formal en distintos
ámbitos.
En cuanto a la notación, una descripción formal constará de cuatro (04) partes:
• NOMBRE: Nombre genérico del TAD.
• CONJUNTOS: Conjuntos de datos que intervienen en la definición.
• SINTAXIS: Signatura de las operaciones definidas ->
<nombre operación>: <conj_dominio> → <conj_resultado>
• SEMÁNTICA: Indica el significado de las operaciones.
Las distintas notaciones formales existentes difieren en la forma de definir la
semántica:
• Método axiomático o algebraico. Se establece el significado de las
operaciones a través de relaciones entre operaciones (axiomas). Significado
implícito de las operaciones.
Los métodos axiomáticos o algebraicos, poseen la semántica de las
operaciones, como dijimos anteriormente se define a través de un conjunto de
axiomas.
Un axioma es una regla que establece la igualdad de dos expresiones:
<Expresión 1> = <Expresión 2>
Por ejemplo: Suma (dos, dos) = Producto (dos, dos)
Supongamos un TAD, T. Los tipos de operaciones son:
• Constructores: Conjunto mínimo de operaciones del TAD, a partir del cual
se puede obtener cualquier valor del tipo T.
• Modificación: A partir de un valor del tipo obtienen otro valor del tipo T, y no
son constructores.
• Consulta: Devuelven un valor que no es del tipo T.
Además, una especificación es:
• Completa: Si de cualquier expresión se puede encontrar otra más sencilla,
con operaciones de construcción.
• Correcta: Si a partir de una expresión sólo se puede obtener un resultado
final.
Para conseguir que una especificación sea completa y correcta, hay que definir
los axiomas suficientes para relacionar las operaciones de modificación y
consulta con los constructores. Y no incluyendo axiomas que se puedan
deducir de los otros ya descritos.
• Método constructivo u operacional. Se define cada operación por sí misma,
independientemente de las otras. Significado explícito de las operaciones. En la
semántica de este método se establecen las precondiciones y las
poscondiciones de las operaciones:
• Precondición: Relación que se debe cumplir con los datos de entrada para
que la operación se pueda aplicar.
• Poscondición: Relaciones que se cumplen después de ejecutar la operación.
No debe incluir detalles de implementación.
En cuanto a la notación, para cada operación <nombre>:
pre-<nombre> (<param_entrada>)::= <condición_lógica>
post-<nombre> (<param_entrada>;<param_salida>)::= <condición_lógica>
Algunas veces es necesario tener modelos subyacentes para especificar otros
complejos. Por ejemplo: para especificar Pila[T] o Cola[T] el tipo subyacente
puede ser Lista[T]. Esta especificación está limitada por la necesidad de estos
modelos.
Ejemplo:
Máximo restringido, que sólo se aplica a enteros positivos: max_restring: Z x Z
→ Z
pre-max_restring (x, y) ::= (x > 0) ^ (y > 0)
post-max_restring (x, y; r) ::= (r ≥ x) ^ (r ≥ y) ^ (r=x V r=y)
Desventajas de los métodos formales
• El desarrollo de herramientas que apoyen la aplicación de métodos formales
es complicado y los programas resultantes son incómodos para los usuarios.
• Los investigadores por lo general no conocen la realidad industrial.
• Es escasa la colaboración entre la industria y el mundo académico, que en
ocasiones se muestra demasiado dogmático.
• Se considera que la aplicación de métodos formales encarece los
productos y ralentiza su desarrollo.
No obstante es posible que el enfoque a través de métodos formales tenga
más partidarios entre los desarrolladores del software que deben construir
software de mucha seguridad (por ejemplo: los desarrolladores de aviónica
y dispositivos médicos), y entre los desarrolladores que pasan grandes
penurias económicas al aparecer errores de software.
Métodos formales en ingeniería del software
Los métodos formales en ingeniería de software tienen como objetivo aumentar
la rigurosidad, consistencia y completitud en el desarrollo del software y evitar
los problemas que son origen de errores en el software.
Una de las técnicas utilizadas para garantizar la calidad en un proyecto
software es la verificación formal, que engloba una serie de técnicas
matemáticas para demostrar que el software que se está desarrollando se
ajuste a las especificaciones.
El papel de los métodos formales en la ingeniería del software:
• Se basan en el empleo de técnicas, lenguajes y herramientas definidos
matemáticamente.
• Facilitan el análisis y construcción de sistemas confiables
independientemente de su complejidad.
• Delatan posibles inconsistencias o ambigüedades que de otra manera
pudieran pasar desapercibidas.
• Facilita el desarrollo de especificaciones claras, concisas y no ambiguas.
• Permite el análisis funcional de la especificación.
• Posibilita el desarrollo de implementaciones correctas respecto a sus
especificaciones.
Modelo de Transformación Formal
Este modelo, propuesto por Robert Balzer en 1983, aplica una serie de
transformaciones usando un soporte automatizado para convertir una
especificación formal (modelo matemático) en un sistema implementable
(ejecutable). Es decir, este paradigma intenta automatizar las etapas de diseño
e implementación utilizando el concepto de transformación. También se
denomina a este paradigma Síntesis Automática de Software.
Fases:
 Análisis de requisitos
 Especificación formal
 Transformación
 Integración del sistema final
La especificación formal se convierte en forma sistemática en una
representación más detallada del sistema, matemáticamente correcta. Cada
paso agrega detalle hasta que la especificación formal se convierte en un
programa equivalente. Como hay muchos caminos a seguir desde la
especificación hasta el sistema final, la secuencia de transformaciones y su
justificación se reflejan en un registro formal de desarrollo. Se utilizan técnicas
de validación del modelo matemático, como la Simulación.
La especificación de requisitos se refina en una especificación formal detallada,
expresada en notación matemática. Los procesos de diseño, implementación y
prueba de unidades se reemplaza por un proceso de transformaciones donde
la especificación formal se refina hasta llegar a un Software.
Proceso de Transformación formal de Robert Balzer - "Software technology in
the 1990s: using a new paradigm".
http://innovacionpnfi2012.wordpress.com/metodos-formales-2/
MODELO EVOLUTIVO
Este modelo, también conocido como Evolutivo, es una derivación del ciclo
de vida en cascada puro, que busca reducir el riesgo que surge entre las
necesidades delUsuario y el Producto final por malos entendidos durante la
etapa de solicitud de requerimientos.
En el ciclo de vida iterativo, en cada Iteración se reproduce el ciclo de vida en
cascada a menor escala. Los objetivos de una Iteración se establecen en
función de la evaluación de las Iteraciones precedentes. Desde el principio, al
final de cada Iteración se le entrega al Cliente una versión completa y mejorada
del Producto. El Cliente es quien luego de cada Iteración evalúa el Producto y
lo corrige o propone mejoras. Estas Iteraciones irán Refinando el sistema y se
repetirán hasta obtener un Producto que satisfaga al Cliente.
La Especificación de requisitos se realiza en forma creciente: a medida que
los Usuarios logran un mejor entendimiento del problema, éste es reflejado en
el sistema software. Es decir, el Producto de cada etapa de Especificación de
requisitos es un agregado o mejora al Producto de la etapa de especificación
anterior.
Este modelo se basa en dos premisas:
1) Los Usuarios a menudo no saben bien lo que quieren o necesitan.
2) Por lo general, los requisitos en algún momento van a cambiar.
Para solucionar el primer punto, los requisitos se determinan en base a alguna
forma operacional del sistema (por ejemplo, un prototipo) para ser revisado por
los Usuarios. Para atender el segundo punto, se realizan entregas parciales del
sistema que permiten incorporar nuevos requisitos o cambios en requisitos
existentes en la siguiente entrega. Es decir, cada versión es una mejora sobre
la predecesora.
Este modelo se utiliza cuando no se puede especificar a priori “todos” los
requisitos del software, sino que el proceso ayudará a ir descubriendo paso a
paso los requisitos a partir de cada nueva Entrega.
http://procesosoftware.wikispaces.com/Modelo+Iterativo
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el
enfoque incremental de desarrollocomo una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este
modelo se conoce también bajo las siguientes denominaciones:
 Método de las comparaciones limitadas sucesivas.
 Ciencia de salir del paso.
 Método de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la
filosofía interactiva de Construcción de Prototipos. Como se muestra en la
Figura 1, el modelo incremental aplica secuencias lineales de forma
escalonada mientras progresa el tiempo en el calendario. Cada secuencia
lineal produce un incremento del software. El primer incremento generalmente
es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:
 Análisis
 Diseño
 Código
 Prueba
Sin embargo, para la producción del Software, se usa el principio de trabajo en
cadena o Pipeline. 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
elabora el producto completo. De esta forma el tiempo de entrega se reduce
considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada
incremento la entrega de un producto completamente operacional. Este modelo
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.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes
partes que al final terminará siendo la solución completa requerida por el
cliente, pero éstas partes no se pueden realizar en cualquier orden, sino
que dependen de lo que el cliente este necesitando con más urgencia, de
los puntos más importantes del proyecto, los requerimientos más
básicos, difíciles y con mayor grado de riesgo, ya que estos se deben
hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en
cada versión.
De este modo podemos terminar una aplicación ejecutable (primera versión)
que podrá ser entregada al cliente para que éste pueda trabajar en ella y el
programador pueda considerar las recomendaciones que el cliente efectúe
para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a
ser integradas en la siguiente versión junto con los demás requerimientos que
no fueron tomados en cuenta en la versión anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura
completa del sistema, seguido de sucesivos incrementos funcionales. Cada
incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su
funcionalidad ni sus interfaces. Una vez entregado un incremento, no se
realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado
que la arquitectura completa se desarrolla en la etapa inicial, es necesario
conocer los requerimientos completos al comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos,
las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo
de requisitos funcionales y será el cliente quien se encarga de priorizar que
funcionalidades son mas importantes. Con las funcionalidades priorizadas, se
puede confeccionar un plan de incrementos, donde en cada incremento se
indica un subconjunto de funcionalidades que el sistema entregará. La
asignación de funcionalidades a los incrementos depende de la prioridad dada
a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el
primer incremento.
Características:
 Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
 El usuario se involucra más.
 Dificil de evaluar el costo total.
 Dificil 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 positivo.
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.
 Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.
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.
http://procesosoftware.wikispaces.com/Modelo+Incremental
MODELO ESPIRAL
EL Modelo Espiral, propuesto en 1988 por Barry Boehm, reconoce la
naturaleza iterativa del desarrollo y combina actividades de desarrollo con
gestión de riesgo, para minimizar y controlar el riesgo. Cada ciclo o iteración
del espiral se divide en cuatro fases: determinar objetivos, alternativas y
restricciones; evaluar alternativas, identificar y resolver los riesgos; desarrollar,
verificar el producto del próximo nivel y planificar las siguientes fases.
El modelo espiral es en cierto sentido semejante al Modelo Iterativo pues
maneja cuatro iteraciones o ciclos. Comienza con los requisitos y un plan inicial
de desarrollo (incluye presupuesto, restricciones y alternativas para personal,
diseño y ambiente de desarrollo). Se evalúan riesgos del proyecto y se
construye prototipos de las alternativas. Luego se escribe un documento con el
"concepto de las operaciones" que describe la funcionalidad del sistema en un
nivel alto, desde el punto de vista del usuario. Este es el producto de la 1°
iteración. A partir de este documento se especificación los requisitos del
software, los cuales son validados, éstos son el producto de la 2° iteración. En
la 3° iteración se hace un plan de desarrollo, se produce el diseño, que es
verificado y validado. en la 4° iteración se hace un plan de integración y prueba,
se genera el software y se realizan las pruebas.
En cada iteración se hace un análisis de riesgo de las alternativas según los
requisitos y restricciones, y se construyen prototipos para analizar las
alternativas y seleccionar una. Estos prototipos pueden ser simples maquetas
en papel, prototipos de interfaz de usuario o simulaciones del sistema,
dependiendo del riesgo a evaluar, según el ciclo en el proceso y del tipo de
aplicación.
http://procesosoftware.wikispaces.com/Modelo+Espiral
Modelos basados en reutilización
El diseño basado en reutilización puro busca construir un producto software
integrando componentes pre-existentes.
Los beneficios principales que otorga este modelo son:
-Tiempos de desarrollos cortos
-Disminución de errores
-Disminución de costos y riegos ya que se reduce los componentes a
desarrollar
-Existe un aumento de la confiabilidad ya que los componentes a utilizar ya
fueron testeados y utilizados en otro momento previo al comienzo del proyecto
A modo de desventaja podemos mencionar el hecho de que al no poseer algún
componente que cubra con un requisito dado por el usuario, este debe ser
modificado para adaptarlo a los componentes almacenados en el repositorio de
componentes.
Esto se da en el modelo puro. En cambio en el modelo real si no se puede
adaptar un requisito de usuario, se conseguirá o se desarrollara ese modulo
para que cumpla con lo pedido por el usuario.
Otra desventaja de este modelo es que una vez finalizada la etapa de
modificación de requisitos, y ante la eventual necesidad de cambios en estos
últimos, puede pasar que no haya componentes que se adapten a las nuevas
modificaciones.
Tipos de modelos de procesos

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de software
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Modelo espiral
Modelo espiralModelo espiral
Modelo espiral
 
Unidad 4
Unidad 4Unidad 4
Unidad 4
 
Ensayo sobre la calidad de software
Ensayo sobre la calidad de softwareEnsayo sobre la calidad de software
Ensayo sobre la calidad de software
 
Principios del RUP
Principios del RUPPrincipios del RUP
Principios del RUP
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
 
Ejemplo rup
Ejemplo rupEjemplo rup
Ejemplo rup
 
Etica de ingenieria de software
Etica de ingenieria de softwareEtica de ingenieria de software
Etica de ingenieria de software
 
DIAGRAMAS DE CLASE
DIAGRAMAS DE CLASEDIAGRAMAS DE CLASE
DIAGRAMAS DE CLASE
 
Metodologia Incremental
Metodologia IncrementalMetodologia Incremental
Metodologia Incremental
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a Objetos
 
Prueba software orientado a objetos
Prueba software orientado a objetosPrueba software orientado a objetos
Prueba software orientado a objetos
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
 
Capas de la ingenieria de software
Capas de la ingenieria de softwareCapas de la ingenieria de software
Capas de la ingenieria de software
 
Estructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativoEstructuras (CAPAS) de un sistema operativo
Estructuras (CAPAS) de un sistema operativo
 
Ingenieria requisitos
Ingenieria requisitosIngenieria requisitos
Ingenieria requisitos
 
Modelo incremental
Modelo incrementalModelo incremental
Modelo incremental
 

Similar a Tipos de modelos de procesos

Trabajo de Christian Oblitas
Trabajo de Christian OblitasTrabajo de Christian Oblitas
Trabajo de Christian OblitasChristian1705
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaamendez45
 
Ingenieria de la informatica
Ingenieria de la informaticaIngenieria de la informatica
Ingenieria de la informaticaAriel Medina
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteCAMILO
 
Unidad III Sistemas de Informacion
Unidad III Sistemas de InformacionUnidad III Sistemas de Informacion
Unidad III Sistemas de InformacionCasssandraG
 
Sistemas de Informacion
Sistemas de InformacionSistemas de Informacion
Sistemas de InformacionCasssandraG
 
Insidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De SoftwareInsidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De SoftwareUniversidad De Cordoba
 
Ciclo Vida Sw
Ciclo Vida SwCiclo Vida Sw
Ciclo Vida Swmsc080277
 
Modelado de requisitos
Modelado de requisitosModelado de requisitos
Modelado de requisitosKleo Jorgee
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOSFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOSValentina
 
El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...
El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...
El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...Gabriel Méndez
 
Presentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watchPresentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watchdanielnp33
 
Significado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemasSignificado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemasJuan Pablo Bustos Thames
 
Significado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemasSignificado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemasJuan Pablo Bustos Thames
 

Similar a Tipos de modelos de procesos (20)

Trabajo de Christian Oblitas
Trabajo de Christian OblitasTrabajo de Christian Oblitas
Trabajo de Christian Oblitas
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
 
Ingenieria de la informatica
Ingenieria de la informaticaIngenieria de la informatica
Ingenieria de la informatica
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de Coste
 
Unidad III Sistemas de Informacion
Unidad III Sistemas de InformacionUnidad III Sistemas de Informacion
Unidad III Sistemas de Informacion
 
Sistemas de Informacion
Sistemas de InformacionSistemas de Informacion
Sistemas de Informacion
 
Insidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De SoftwareInsidencias En Los Paradigmas De La Ingeniera De Software
Insidencias En Los Paradigmas De La Ingeniera De Software
 
Ciclo Vida Sw
Ciclo Vida SwCiclo Vida Sw
Ciclo Vida Sw
 
Ciclo de vida cascada
Ciclo de vida cascadaCiclo de vida cascada
Ciclo de vida cascada
 
Modelado de requisitos
Modelado de requisitosModelado de requisitos
Modelado de requisitos
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOSFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
 
El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...
El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...
El desarrollo de un programa o de un conjunto de aplicaciones se basa en un c...
 
Manual de sistema
Manual de sistemaManual de sistema
Manual de sistema
 
1127082.ppt
1127082.ppt1127082.ppt
1127082.ppt
 
SSADM Material de apoyo
 SSADM Material de apoyo SSADM Material de apoyo
SSADM Material de apoyo
 
Presentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watchPresentacion lineas de productos de software y el metodo watch
Presentacion lineas de productos de software y el metodo watch
 
Metodología de desarrollo
Metodología de desarrolloMetodología de desarrollo
Metodología de desarrollo
 
Significado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemasSignificado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemas
 
Significado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemasSignificado dentro del ciclo de vida de desarrollo de sistemas
Significado dentro del ciclo de vida de desarrollo de sistemas
 
Proceso software
Proceso softwareProceso software
Proceso software
 

Más de EIYSC

Appserv
AppservAppserv
AppservEIYSC
 
Qué es own cloud
Qué es own cloudQué es own cloud
Qué es own cloudEIYSC
 
Prot.comunicación ej.
Prot.comunicación ej.Prot.comunicación ej.
Prot.comunicación ej.EIYSC
 
Denegación de servicio
Denegación de servicio Denegación de servicio
Denegación de servicio EIYSC
 
Pfsense
PfsensePfsense
PfsenseEIYSC
 
¿Qué es un firewall ?
¿Qué es un firewall ?¿Qué es un firewall ?
¿Qué es un firewall ?EIYSC
 
Cifrado cesar
Cifrado cesarCifrado cesar
Cifrado cesarEIYSC
 
Estructura del modelo osi de iso
Estructura del modelo osi de isoEstructura del modelo osi de iso
Estructura del modelo osi de isoEIYSC
 
Dhcp
DhcpDhcp
DhcpEIYSC
 
Miembros de una vlan
Miembros de una vlanMiembros de una vlan
Miembros de una vlanEIYSC
 
Ejemplos de simplex
Ejemplos de simplexEjemplos de simplex
Ejemplos de simplexEIYSC
 
Configurar rip
Configurar ripConfigurar rip
Configurar ripEIYSC
 
Protocolo rip
Protocolo ripProtocolo rip
Protocolo ripEIYSC
 
Funcionalidad rip
Funcionalidad ripFuncionalidad rip
Funcionalidad ripEIYSC
 
Monografia redes
Monografia redesMonografia redes
Monografia redesEIYSC
 
Música.docx
Música.docxMúsica.docx
Música.docxEIYSC
 
Proyecto ciencias y diseño grafico
Proyecto ciencias y diseño graficoProyecto ciencias y diseño grafico
Proyecto ciencias y diseño graficoEIYSC
 
Proyecto final
Proyecto final Proyecto final
Proyecto final EIYSC
 
Caso de uso de caja negra
Caso de uso de caja negraCaso de uso de caja negra
Caso de uso de caja negraEIYSC
 
Conceptos de calidad
Conceptos de calidadConceptos de calidad
Conceptos de calidadEIYSC
 

Más de EIYSC (20)

Appserv
AppservAppserv
Appserv
 
Qué es own cloud
Qué es own cloudQué es own cloud
Qué es own cloud
 
Prot.comunicación ej.
Prot.comunicación ej.Prot.comunicación ej.
Prot.comunicación ej.
 
Denegación de servicio
Denegación de servicio Denegación de servicio
Denegación de servicio
 
Pfsense
PfsensePfsense
Pfsense
 
¿Qué es un firewall ?
¿Qué es un firewall ?¿Qué es un firewall ?
¿Qué es un firewall ?
 
Cifrado cesar
Cifrado cesarCifrado cesar
Cifrado cesar
 
Estructura del modelo osi de iso
Estructura del modelo osi de isoEstructura del modelo osi de iso
Estructura del modelo osi de iso
 
Dhcp
DhcpDhcp
Dhcp
 
Miembros de una vlan
Miembros de una vlanMiembros de una vlan
Miembros de una vlan
 
Ejemplos de simplex
Ejemplos de simplexEjemplos de simplex
Ejemplos de simplex
 
Configurar rip
Configurar ripConfigurar rip
Configurar rip
 
Protocolo rip
Protocolo ripProtocolo rip
Protocolo rip
 
Funcionalidad rip
Funcionalidad ripFuncionalidad rip
Funcionalidad rip
 
Monografia redes
Monografia redesMonografia redes
Monografia redes
 
Música.docx
Música.docxMúsica.docx
Música.docx
 
Proyecto ciencias y diseño grafico
Proyecto ciencias y diseño graficoProyecto ciencias y diseño grafico
Proyecto ciencias y diseño grafico
 
Proyecto final
Proyecto final Proyecto final
Proyecto final
 
Caso de uso de caja negra
Caso de uso de caja negraCaso de uso de caja negra
Caso de uso de caja negra
 
Conceptos de calidad
Conceptos de calidadConceptos de calidad
Conceptos de calidad
 

Último

Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)EmanuelMuoz11
 
permiso de trabajo de alto riesgo- modelo
permiso de trabajo de alto riesgo- modelopermiso de trabajo de alto riesgo- modelo
permiso de trabajo de alto riesgo- modeloJAMESDIAZ55
 
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdfPPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdfANGHELO JJ. MITMA HUAMANÌ
 
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdfPrincipios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdfYADIRAXIMENARIASCOSV
 
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdfCV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdfsd3700445
 
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdfMecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdfaaaaaaaaaaaaaaaaa
 
Cuadro de las web 1.0, 2.0 y 3.0 pptx
Cuadro de las web 1.0, 2.0 y 3.0     pptxCuadro de las web 1.0, 2.0 y 3.0     pptx
Cuadro de las web 1.0, 2.0 y 3.0 pptxecarmariahurtado
 
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERUBROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERUSharonRojas28
 
analisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdfanalisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdfJOHELSANCHEZINCA
 
Presentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptxPresentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptxwilliam atao contreras
 
IA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptxIA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptxcecymendozaitnl
 
Diseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra RinaDiseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra RinaLuisAlfredoPascualPo
 
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍCALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍArquitecto Chile
 
Poder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfestPoder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfestSilvia España Gil
 
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...AmeliaJul
 
Método inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenasMétodo inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenas182136
 

Último (16)

Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
 
permiso de trabajo de alto riesgo- modelo
permiso de trabajo de alto riesgo- modelopermiso de trabajo de alto riesgo- modelo
permiso de trabajo de alto riesgo- modelo
 
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdfPPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
 
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdfPrincipios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
 
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdfCV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdf
 
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdfMecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
 
Cuadro de las web 1.0, 2.0 y 3.0 pptx
Cuadro de las web 1.0, 2.0 y 3.0     pptxCuadro de las web 1.0, 2.0 y 3.0     pptx
Cuadro de las web 1.0, 2.0 y 3.0 pptx
 
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERUBROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
 
analisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdfanalisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdf
 
Presentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptxPresentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptx
 
IA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptxIA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptx
 
Diseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra RinaDiseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra Rina
 
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍCALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
 
Poder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfestPoder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfest
 
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
 
Método inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenasMétodo inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenas
 

Tipos de modelos de procesos

  • 1. MODELOS DE PROCESOS Modelo primitivo Los modelos de datos primitivos estaban absolutamente orientados al fichero: las entidades se representan en registros (divididos en campos, que representan sus propiedades), que se agrupan en ficheros. Las relaciones entre entidades son únicamente aquellas que pueden ser representadas usando directorios, por ejemplo índices y listas invertidas. Un ejemplo de DBMS comercial de fichero, concretamente del tipo "lista invertida", es el CA- DATACOMB de Computer Associates International. Modelo en Cascada1(Bennington 1956): El más conocido, está 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. 1 Ingeniería del Software: Un enfoque practico, Roger S. Presuman, 3ra Edición, Pag. 26-30. Ingeniería y Análisis del Sistema Análisis de los Requisitos Diseño Codificación Prueba Mantenimiento
  • 2. 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 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. 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.
  • 3. 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: ANALISIS DE REQUERIMIENTOS DISEÑO DEL SISTEMA DISEÑO DETALLADO IMPLEMENTACION DE PROGRAMAS Y PRUEBA DEL SISTEMA PRUEBA DE ACEPTACION OPERACION Y MANTENIMIENTO PRUEBA DE INTEGRACION Plan de Pruebas de Integración Verificar diseño Plan de Pruebas del Sistema Validar requerimientos Plan de Pruebas de Aceptación Los planes de prueba son el nexo entre el desarrollo y la verificación
  • 4.  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. MODELOS BASADOS EN PROTOTIPOS Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar y analizar una aplicación que representa el sistema que sería implementado (McCracken y Jackson, 1982). Dicha aplicación, llamada prototipo, está compuesta por los componentes que se desean evaluar (i.e. las funciones principales). Las etapas del modelo son: - Investigación preliminar. - Colecta y refinamiento de los requerimientos y proyecto rápido: - Análisis y especificación del prototipo. - Diseño y construcción del prototipo. - Evaluación del prototipo por el cliente. - Renacimiento del prototipo.
  • 5. - Diseño técnico. - Programación y test. - - Operación y mantenimiento. http://rguerrero334.blogspot.es/1192897080/ Métodos formales Un método formal es un camino a la construcción y análisis de modelos matemáticos que permitan una automatización del desarrollo de sistemas informáticos; se caracterizan por emplear técnicas y herramientas matemáticas para lograr una facilitación a la hora de encarar la construcción o el análisis de un modelo matemático de un sistema. Los métodos formales se refieren entonces al uso de técnicas de la lógica y de la matemática discreta para especificar, diseñar, verificar, desarrollar y validar programas. La palabra “formal” se deriva de la lógica formal, ciencia que estudia el razonamiento desde el análisis formal de acuerdo con su validez o no validez, y omite el contenido empírico del razonamiento para considerar sólo la forma estructurada sin materia. Los métodos formales más rigurosos aplican estas técnicas para comprobar los argumentos utilizados para justificar los requisitos,
  • 6. u otros aspectos de diseño e implementación de un sistema complejo. En la lógica formal como en los métodos formales el objetivo es el mismo, “reducir la dependencia de la institución y el juicio humanos para evaluar argumentos” (Kiniry & Zimmerman, 2008). Los métodos menos rigurosos enfatizan en la formalización y renuncian a la computación, definición que implica un amplio espectro de técnicas, y una gama igualmente amplias de estrategias. La interacción de las técnicas y estrategias de muchos métodos formales, en determinados proyectos, se limita por el papel que interpretan y por los recursos disponibles para su aplicación (García et al., 2006). Se puede decir también que un método formal es una técnica basada en matemáticas, usada para describir sistemas de hardware o software, Wing, Jeannette M. (1990). Los métodos formales permiten representar la especificación del software, verificación y diseño de componentes mediante notaciones matemáticas. El uso de métodos formales permite plantear de manera clara la especificación de un sistema, generando modelos que definen el comportamiento en términos del “qué debe hacer” y no del “cómo lo hace”. Gracias al correcto proceso de especificación, se pueden verificar propiedades derivadas de cada módulo mediante técnicas de razonamiento asociadas a los modelos formales, como probadores de teoremas y verificadores de modelos Hall (1996). Para los procesos de especificación se reconoce las siguientes clasificaciones: 1. Especificaciones basadas en lógicas de primer orden y teoría de conjunto: Permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Los métodos de este tipo más conocidos son: VDM, Z, B, OCL. Niveles de los métodos formales • Especificación formal: Es una descripción de un sistema que utiliza notaciones matemáticas para describir precisamente las propiedades que dicho sistema debe tener, sin preocuparse por la forma de obtener estas propiedades: “describe lo que el sistema debe hacer sin decir como se va hacer”. Algunas de las ventajas que podemos nombrar sobre una especificación formal son las siguientes: • Prototipado: Las especificaciones formales pueden llegar a ser ejecutables. • Corrección del programa: Verificación automática y formal de que el programa funciona correctamente. • Reusabilidad: Posibilidad de usar la especificación formal en distintos ámbitos. En cuanto a la notación, una descripción formal constará de cuatro (04) partes: • NOMBRE: Nombre genérico del TAD.
  • 7. • CONJUNTOS: Conjuntos de datos que intervienen en la definición. • SINTAXIS: Signatura de las operaciones definidas -> <nombre operación>: <conj_dominio> → <conj_resultado> • SEMÁNTICA: Indica el significado de las operaciones. Las distintas notaciones formales existentes difieren en la forma de definir la semántica: • Método axiomático o algebraico. Se establece el significado de las operaciones a través de relaciones entre operaciones (axiomas). Significado implícito de las operaciones. Los métodos axiomáticos o algebraicos, poseen la semántica de las operaciones, como dijimos anteriormente se define a través de un conjunto de axiomas. Un axioma es una regla que establece la igualdad de dos expresiones: <Expresión 1> = <Expresión 2> Por ejemplo: Suma (dos, dos) = Producto (dos, dos) Supongamos un TAD, T. Los tipos de operaciones son: • Constructores: Conjunto mínimo de operaciones del TAD, a partir del cual se puede obtener cualquier valor del tipo T. • Modificación: A partir de un valor del tipo obtienen otro valor del tipo T, y no son constructores. • Consulta: Devuelven un valor que no es del tipo T. Además, una especificación es: • Completa: Si de cualquier expresión se puede encontrar otra más sencilla, con operaciones de construcción. • Correcta: Si a partir de una expresión sólo se puede obtener un resultado final. Para conseguir que una especificación sea completa y correcta, hay que definir los axiomas suficientes para relacionar las operaciones de modificación y consulta con los constructores. Y no incluyendo axiomas que se puedan deducir de los otros ya descritos. • Método constructivo u operacional. Se define cada operación por sí misma, independientemente de las otras. Significado explícito de las operaciones. En la semántica de este método se establecen las precondiciones y las poscondiciones de las operaciones: • Precondición: Relación que se debe cumplir con los datos de entrada para que la operación se pueda aplicar. • Poscondición: Relaciones que se cumplen después de ejecutar la operación. No debe incluir detalles de implementación. En cuanto a la notación, para cada operación <nombre>: pre-<nombre> (<param_entrada>)::= <condición_lógica> post-<nombre> (<param_entrada>;<param_salida>)::= <condición_lógica> Algunas veces es necesario tener modelos subyacentes para especificar otros complejos. Por ejemplo: para especificar Pila[T] o Cola[T] el tipo subyacente
  • 8. puede ser Lista[T]. Esta especificación está limitada por la necesidad de estos modelos. Ejemplo: Máximo restringido, que sólo se aplica a enteros positivos: max_restring: Z x Z → Z pre-max_restring (x, y) ::= (x > 0) ^ (y > 0) post-max_restring (x, y; r) ::= (r ≥ x) ^ (r ≥ y) ^ (r=x V r=y) Desventajas de los métodos formales • El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios. • Los investigadores por lo general no conocen la realidad industrial. • Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático. • Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo. No obstante es posible que el enfoque a través de métodos formales tenga más partidarios entre los desarrolladores del software que deben construir software de mucha seguridad (por ejemplo: los desarrolladores de aviónica y dispositivos médicos), y entre los desarrolladores que pasan grandes penurias económicas al aparecer errores de software. Métodos formales en ingeniería del software Los métodos formales en ingeniería de software tienen como objetivo aumentar la rigurosidad, consistencia y completitud en el desarrollo del software y evitar los problemas que son origen de errores en el software. Una de las técnicas utilizadas para garantizar la calidad en un proyecto software es la verificación formal, que engloba una serie de técnicas matemáticas para demostrar que el software que se está desarrollando se ajuste a las especificaciones. El papel de los métodos formales en la ingeniería del software: • Se basan en el empleo de técnicas, lenguajes y herramientas definidos matemáticamente. • Facilitan el análisis y construcción de sistemas confiables independientemente de su complejidad. • Delatan posibles inconsistencias o ambigüedades que de otra manera pudieran pasar desapercibidas. • Facilita el desarrollo de especificaciones claras, concisas y no ambiguas. • Permite el análisis funcional de la especificación. • Posibilita el desarrollo de implementaciones correctas respecto a sus especificaciones. Modelo de Transformación Formal
  • 9. Este modelo, propuesto por Robert Balzer en 1983, aplica una serie de transformaciones usando un soporte automatizado para convertir una especificación formal (modelo matemático) en un sistema implementable (ejecutable). Es decir, este paradigma intenta automatizar las etapas de diseño e implementación utilizando el concepto de transformación. También se denomina a este paradigma Síntesis Automática de Software. Fases:  Análisis de requisitos  Especificación formal  Transformación  Integración del sistema final La especificación formal se convierte en forma sistemática en una representación más detallada del sistema, matemáticamente correcta. Cada paso agrega detalle hasta que la especificación formal se convierte en un programa equivalente. Como hay muchos caminos a seguir desde la especificación hasta el sistema final, la secuencia de transformaciones y su justificación se reflejan en un registro formal de desarrollo. Se utilizan técnicas de validación del modelo matemático, como la Simulación. La especificación de requisitos se refina en una especificación formal detallada, expresada en notación matemática. Los procesos de diseño, implementación y prueba de unidades se reemplaza por un proceso de transformaciones donde la especificación formal se refina hasta llegar a un Software. Proceso de Transformación formal de Robert Balzer - "Software technology in the 1990s: using a new paradigm". http://innovacionpnfi2012.wordpress.com/metodos-formales-2/
  • 10. MODELO EVOLUTIVO Este modelo, también conocido como Evolutivo, es una derivación del ciclo de vida en cascada puro, que busca reducir el riesgo que surge entre las necesidades delUsuario y el Producto final por malos entendidos durante la etapa de solicitud de requerimientos. En el ciclo de vida iterativo, en cada Iteración se reproduce el ciclo de vida en cascada a menor escala. Los objetivos de una Iteración se establecen en función de la evaluación de las Iteraciones precedentes. Desde el principio, al final de cada Iteración se le entrega al Cliente una versión completa y mejorada del Producto. El Cliente es quien luego de cada Iteración evalúa el Producto y lo corrige o propone mejoras. Estas Iteraciones irán Refinando el sistema y se repetirán hasta obtener un Producto que satisfaga al Cliente. La Especificación de requisitos se realiza en forma creciente: a medida que los Usuarios logran un mejor entendimiento del problema, éste es reflejado en el sistema software. Es decir, el Producto de cada etapa de Especificación de requisitos es un agregado o mejora al Producto de la etapa de especificación anterior. Este modelo se basa en dos premisas: 1) Los Usuarios a menudo no saben bien lo que quieren o necesitan. 2) Por lo general, los requisitos en algún momento van a cambiar. Para solucionar el primer punto, los requisitos se determinan en base a alguna forma operacional del sistema (por ejemplo, un prototipo) para ser revisado por los Usuarios. Para atender el segundo punto, se realizan entregas parciales del sistema que permiten incorporar nuevos requisitos o cambios en requisitos existentes en la siguiente entrega. Es decir, cada versión es una mejora sobre la predecesora. Este modelo se utiliza cuando no se puede especificar a priori “todos” los requisitos del software, sino que el proceso ayudará a ir descubriendo paso a paso los requisitos a partir de cada nueva Entrega.
  • 11. http://procesosoftware.wikispaces.com/Modelo+Iterativo El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:  Método de las comparaciones limitadas sucesivas.  Ciencia de salir del paso.  Método de atacar el problema por ramas. El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo. En una visión genérica, el proceso se divide en 4 partes:  Análisis  Diseño  Código  Prueba
  • 12. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. 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 elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo 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. Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminará siendo la solución completa requerida por el cliente, pero éstas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos más importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión. De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.
  • 13. El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo. Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de requisitos funcionales y será el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregará. La asignación de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento. Características:  Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.  El usuario se involucra más.  Dificil de evaluar el costo total.  Dificil 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 positivo. 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.  Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
  • 14. 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. http://procesosoftware.wikispaces.com/Modelo+Incremental MODELO ESPIRAL EL Modelo Espiral, propuesto en 1988 por Barry Boehm, reconoce la naturaleza iterativa del desarrollo y combina actividades de desarrollo con gestión de riesgo, para minimizar y controlar el riesgo. Cada ciclo o iteración del espiral se divide en cuatro fases: determinar objetivos, alternativas y restricciones; evaluar alternativas, identificar y resolver los riesgos; desarrollar, verificar el producto del próximo nivel y planificar las siguientes fases. El modelo espiral es en cierto sentido semejante al Modelo Iterativo pues maneja cuatro iteraciones o ciclos. Comienza con los requisitos y un plan inicial de desarrollo (incluye presupuesto, restricciones y alternativas para personal, diseño y ambiente de desarrollo). Se evalúan riesgos del proyecto y se construye prototipos de las alternativas. Luego se escribe un documento con el "concepto de las operaciones" que describe la funcionalidad del sistema en un nivel alto, desde el punto de vista del usuario. Este es el producto de la 1° iteración. A partir de este documento se especificación los requisitos del software, los cuales son validados, éstos son el producto de la 2° iteración. En la 3° iteración se hace un plan de desarrollo, se produce el diseño, que es verificado y validado. en la 4° iteración se hace un plan de integración y prueba, se genera el software y se realizan las pruebas. En cada iteración se hace un análisis de riesgo de las alternativas según los requisitos y restricciones, y se construyen prototipos para analizar las alternativas y seleccionar una. Estos prototipos pueden ser simples maquetas en papel, prototipos de interfaz de usuario o simulaciones del sistema, dependiendo del riesgo a evaluar, según el ciclo en el proceso y del tipo de aplicación.
  • 15. http://procesosoftware.wikispaces.com/Modelo+Espiral Modelos basados en reutilización El diseño basado en reutilización puro busca construir un producto software integrando componentes pre-existentes. Los beneficios principales que otorga este modelo son: -Tiempos de desarrollos cortos -Disminución de errores -Disminución de costos y riegos ya que se reduce los componentes a desarrollar -Existe un aumento de la confiabilidad ya que los componentes a utilizar ya fueron testeados y utilizados en otro momento previo al comienzo del proyecto A modo de desventaja podemos mencionar el hecho de que al no poseer algún componente que cubra con un requisito dado por el usuario, este debe ser modificado para adaptarlo a los componentes almacenados en el repositorio de componentes. Esto se da en el modelo puro. En cambio en el modelo real si no se puede adaptar un requisito de usuario, se conseguirá o se desarrollara ese modulo para que cumpla con lo pedido por el usuario. Otra desventaja de este modelo es que una vez finalizada la etapa de modificación de requisitos, y ante la eventual necesidad de cambios en estos últimos, puede pasar que no haya componentes que se adapten a las nuevas modificaciones.