Ingeniería y Análisis del Sistema

Análisis de los Requisitos

Diseño

Codificación

Prueba

Mantenimiento

MODELOS DE PROCESOSModelo 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.

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.

ANALISIS DE REQUERIMIENTOS

DISEÑO DEL SISTEMA

DISEÑO DETALLADO

IMPLEMENTACION DE PROGRAMAS Y PRUEBA UNITARIA

PRUEBA DEL SISTEMA

PRUEBA DE ACEPTACION

OPERACIONY

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

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.

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 formalesUn 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 → Zpre-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 softwareLos 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.