jueves, 21 de octubre de 2010

Modelos de Desarrollo de Software


Modelo Lineal Secuencial


Llamado en algunos de los casos ciclo de vida básico o modelo de cascada, el modelo lineal secuencial siguiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza con un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

 














Ingeniería y modelado de sistemas/Información. El trabajo comienza estableciendo requisitos de todos los elementos de sistema asignando al software algún subgrupo de estos requisitos. 

Análisis. Se debe comprender el dominio de información de software, así como la función requerida, el comportamiento, rendimiento e interconexión. 

Diseño. Proceso de muchos pasos, que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental. El diseño traduce requisitos en una representación de software para poder evaluar su calidad antes de la codificacion.

Generación de código. El diseño se debe traducir en una forma legible por la maquina, es en este paso que esa labor se lleva a cabo, si el diseño se realizo de una manera detallada la generación de código se realiza mecánicamente. 

Pruebas. Se realizan pruebas para la detección de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados definidos. 


El modelo lineal secuencial es el paradigma mas antiguo y mas extensamente utilizado en la ingeniería de software. Sin embargo, las criticas a este modelo han puesto en duda si eficacia, los problemas que se encuentran algunas veces en este modelo son:
  • Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.
  • A menudo es difícil que el cliente exponga explícitamente todos los requisitos.
  • El cliente debe tener paciencia.
  • Cada uno de estos errores es real, pero pese a sus debilidades, este modelo es significativamente mejor que un enfoque hecho al azar para el desarrollo de software.

Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.

Modelo de Construccion de Prototipos 

En Ingenieria del Software; El Modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros podemos iniciar el verdadero desarrollo del software.






















El diseño rapido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interación ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

La construcción de prototipos, consiste en construir un modelo en computadora, que describa la interacción sistema - usuario y que implemente un subconjunto de la función requerida, sometiendolo a la revisión por parte del usuario en un proceso iterativo y evolutivo.

Los pasos necesarios para la construcción de prototipos son los siguientes: 

I. Evaluar la solicitud del software para determinar si el sistema es candidato para la construcción de un prototipo. Considerando si es necesario presentar la interacción usuario-sistema y tomando en cuenta la complejidad del desarrollo del propio prototipo.


II. Elaborar una representación abreviada de los requisitos. Utilizando alguno de los modelos mencionados anteriormente.

III. Crear un conjunto de especificaciones de diseño para el prototipo. Centrandose en los aspectos de mas alto nivel y no en el detalle.


IV. Crear y probar el software del prototipo. De ser posible utilizar herramientas automatizadas para tal efecto, como lenguajes de cuarta generación, módulos de código reusables, herramientas RAD o paquetes especializados en prototipos.

V. Presentar el prototipo al usuario y orientarlo a que sea él quien lo “opere”. Aquí es donde el usuario podrá validar sus propios requerimientos y sugerir las modificaciones necesarias.

VI. Repetir los pasos IV y V hasta que todos los requisitos queden formalizados. 

El modelo de construcción de prototipos se recomienda especialmente cuando los requerimientos cambian frecuentemente, cuando no se tiene la suficiente participación del usuario o cuando no se tienen suficientemente especificados los requerimientos.

Ventajas

  • Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.  
  • También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. 
  • Una ventaja importante es que el usuario va “viendo” la evolución del sistema. 

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. 

De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

El principal inconveniente; Es que se desconoce el tiempo que se tardará en crear un producto aceptable. No se sabe cuantas iteraciones se tendrán que realizar. Otro inconveniente es que se pueden adoptar prácticas de programación de prueba-y-error, sin un análisis y diseño formales previos. 

Modelo de Desarrollo Rapido de Aplicaciones



El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.




















Pricipios tras la definicion:

  • En ciertas situaciones, una solución utilizable al 80% puede producirse en el 20% de tiempo que se hubiera requerido para la solución completa.
  • En ciertas situaciones, los requisitos de negocio de un sistema pueden satisfacerse aun cuando algunos de sus requisitos operacionales no se satisfagan.
  • En ciertas situaciones, la aceptabilidad de un sistema puede determinarse en base a un conjunto mínimo de requisitos consensados en lugar de la totalidad de los requisitos.

RAD tiende a funcionar cuando:

  1. La aplicación funcionará de manera independiente.
  2. Se pueden usar mayormente bibliotecas existentes.
  3. Desempeño no crítico.
  4. Distribución limitada, interna o vertical.
  5. Alcance del proyecto limitado.
  6. Confiabilidad no crítica.
  7. El sistema puede dividirse en muchos módulos independientes.

RAD tiende a fallar cuando:

  1. La aplicación debe interoperar con sistemas existentes.
  2. Existen pocos componentes reutilizables.
  3. Alto desempeño crítico.
  4. El desarrollo no puede aprovechar herramientas de alto nivel.
  5. Distribución amplia, horizontal o masiva.

Ventajas de RAD

  1. Comprar puede ahorrar dinero en comparación con construir.
  2. Los entregables pueden ser facilmente trasladados a otra plataforma.
  3. El desarrollo se realiza a un nivel de abstracción mayor.
  4. Visibilidad temprana.
  5. Mayor flexibilidad.
  6. Menor codificación manual.
  7. Mayor involucramiento de los usuarios.

Desventajas de RAD

  1. Comprar puede ser más caro que construir.
  2. Costo de herramientas integradas y equipo necesario.
  3. Progreso más difícil de medir.
  4. Menos eficiente.
  5. Menor precisión científica.
  6. Riesgo de revertirse a las prácticas sin control de antaño.
  7. Más fallas.


Con el fin de asegurar gran interacción, los proyectos se diseñan con calendarios fijos y se sacrifica la funcionalidad si es necesario. Esto permite que el equipo de desarrollo se enfoque en las piezas de funcionalidad que tienen el mayor valor de negocio y en entregar dicha funcionalidad rápidamente. Los cambios son frecuentemente la razón de los retrasos en el desarrollo de una aplicación. 


En los largos procesos lineales de desarrollo, los cambios en los requisitos funcionales o en el alcance del proyecto, particularmente cuando gran cantidad de tiempo se ha invertido en la planeación, diseño, desarrollo y pruebas, provocan que se pierdan meses de trabajo y se incurra en grandes gastos por rediseño y redesarrollo.



Modelo Incremental


El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos. En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.















Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. 

De esta forma el tiempo de entrega se reduce considerablemente.Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añade personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

Características 


- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia. 
- El usuario se involucre más.


- Dificil de evaluar el costo total.


- Díficil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.


- Requiere gestores experimentados.


- Los errores en los requisitos se detectan tarde.


- El resultado puede ser muy positivo. 

Ventajas

- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. 
-También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.


-El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.


-Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.


-Resulta más sencilo acomodar cambios al acotar el tamaño de los incrementos.


-Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico. 

Desventajas

- El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.


- Requere de mucha planeacion, tanto administrativa como técnica.


- Requiere de metas claras para conocer el estado del proyecto. 

Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del productoSoftware denomidados “incrementos” del sistema, que son escogidos en base a prioridades predefinidas de algún modo.


El modelo permite una implementación con refinacmientos sucesivos (ampliación y mejora).


Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.

 Modelo Espiral


El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
















Boehm, autor de diversos artículos de ingeniería del software; modelos de estimación de esfuerzo y tiempo que se consume en hacer productos software y Modelos de Ciclo de Vida; Ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. 


Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.


En cada vuelta o iteración hay que tener en cuenta:

Los Objetivos: Que necesidad debe cubrir el producto.


Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
  1. Características: experiencia del personal, requisitos a cumplir, etc.
  2. Formas de gestión del sistema.
  3. Riesgo asumido con cada alternativa.


Desarrollar y Verificar: Programar y probar el software.
  
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades; Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:
  1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
  2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.


Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.


Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.


Para cada ciclo habrá cuatro actividades:
  
1) Determinar o fijar objetivos
  • Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.
  • Fijar las restricciones.
  • Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
  • Hay una cosa que solo se hace una vez: planificación inicial o previa.

2) Análisis del riesgo

3) Desarrollar, verificar y validar (probar)

  • Tareas de la actividad propia y de prueba.
  • Análisis de alternativas e identificación resolución de riesgos.
  • Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc.

 Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

4) Planificar

  • Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Ventajas

El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
  • Reduce riesgos del proyecto
  • Incorpora objetivos de calidad
  • Integra el desarrollo con el mantenimiento, etc.


Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas

  • Genera mucho tiempo en el desarrollo del sistema.
  • Modelo costoso.
  • Requiere experiencia en la identificación de riesgos.





Modelo de Desarrollo Concurrente


El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.


Representa un estado de una actividad de ingeniería del software. Al principio la actividad de comunicación con el cliente ha finalizado su primera iteración y está en el estado de cambios en espera mientras que se iniciaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Si el cliente indica que se deben hacer cambios en los requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera. 























El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.

El modelo de proceso concurrente se utiliza como paradigma de desarrollo de aplicaciones cliente/servidor, que cuando se aplica, el modelo de proceso concurrente define actividades en dos dimensiones: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso.

La dimensión de componentes se afronta con dos actividades:
  • Diseño.
  • Realización. 

La concurrencia se logra de dos formas:

1) Las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos.

2)  Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente. En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. 


Modelo de Desarrollo Basado en Componentes


El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software.















El modelo de desarrollo basado en componentes conduce ala reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software. Según estudios de reutilización, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reducción del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un índice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software.

El proceso unificado de desarrollo de software representa un número de modelos de desarrollo basado en componentes que han sido propuestos en la industria. El lenguaje de modelado unificado define los componentes. Utilizando una combinación del desarrollo ¡ncremental e interactivo, el proceso unificado define la función del sistema aplicando un enfoque basado en escenarios. El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos más efectivos para la construcción de grandes sistemas y aplicaciones de software.

Una vez que la mayor parte de los aspectos funcionales de esta disciplina comienzan a estar bien definidos, la atención de la comunidad científica comienza a centrarse en los aspectos extrafuncionales y de calidad, como un paso hacia una verdadera ingeniería. En este artículo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen, con especial énfasis en los estándares internacionales que los definen y regulan, y en los problemas que se plantean en este tipo de entornos.

El uso de este paradigma posee algunas ventajas: 

1. Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software. 
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.


3. Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.


4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.

Un componente puede ser algo como un control Actives; tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio. 

El diagrama de componentes muestra la relación entre componentes de software, sus dependencias, su comunicación su ubicación y otras condiciones.Los componentes también pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente está ofreciendo y dejando disponibles a otros componentes de software y clases. Típicamente, un componente está compuesto por numerosas clases y paquetes de clases internos. También se puede crear a partir de una colección de componentes más pequeños.

Un diagrama de despliegue muestra el despliegue físico del sistema en un ambiente de producción (o de prueba). Muestra dónde se ubican los componentes, en qué servidores, máquinas o hardware. Puede representar los enlaces de redes.

Los componentes pueden tener restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna función; las post-condiciones indican lo que debe ser verdadero después de que un componente haya realizado algún trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente.

Tenemos la fortuna de presenciar el nacimiento de una nueva forma de hacer software, que traerá beneficios inmensos para todos. El desarrollo de software basado en componentes desde siempre fue la idea revolucionaria que nos llevó a pensar que sí era posible el construir software de calidad en corto tiempo y con la misma calidad que la mayoría de las industrias de nuestro tiempo. Al mirar hacia atrás, vemos los increíbles avances que hemos logrado en la comprensión de la forma correcta de reutilizar el software y el conocimiento existente, y nos asombramos cada vez más al darnos cuenta de que este solo es el inicio.

El desarrollo de software basado de componentes se convirtió en el pilar de la Revolución Industrial del Software y se proyecta hoy en día en diversas nuevas formas de hacer software de calidad con los costos más bajos del mercado y en tiempos que antes eran impensables. Empresas como Microsoft entendieron el potencial de esta metodología hace años y hoy nos ofrecen nuevas iniciativas y herramientas que buscan llevar al proceso de construcción de software hacia el sitial privilegiado en el que debió colocarse desde un principio.


Modelo de Metodos Formales


Son técnicas de base matemática para desarrollar sistemas de computadora. El proceso de desarrollo se basa en la transformación matemática formal de la especificación del sistema a un programa ejecutable. La ejecución de este tipo de modelos requiere mucho tiempo y esfuerzo.






















Las matemáticas proporcionan un elevado nivel de verificación cuando son usadas como medio de desarrollo del software:
  • Permiten especificar, desarrollar y verificar un sistema aplicando una notación rigurosa y matemática.
  • Eliminan muchos de los problemas que son difíciles de superar con otros paradigmas. La ambiguedad, la incompletez y la inconsistencia se pueden descubrir y corregir, no mediante una revisión, sino mediante la aplicación del análisis matemático.
  • Su principal desventaja es que requiere que el desarrollador y el cliente tengan conocimientos formales para poderlos aplicar y comunicarse entre sí.

Mitos Sobre Los Métodos Formales
1) Garantizan la perfección del sw y hacen innecesaria su verificación.
 
2)  Solo sirven para demostrar que los programas son correctos.
 
3) Sólo es necesario aplicarlos en sistemas donde la seguridad es crítica.
 
4)  Sólo pueden ser aplicados por expertos en matemáticas.
 
5) La aplicación de métodos formales aumentan los costes de desarrollo.
 
6)  No son bien vistos por los usuarios.  
7)  No se aplican en sistemas reales de gran tamaño.
 
8)  Retrasan el desarrollo.



Los 10 Mandamientos De Los Métodos Formales


1) Seleccionaras la notación adecuada.  


2) Formalizaras, pero no de mas. 


3) Estimaras los costes.  


4) Poseerás un experto en métodos formales a tu disposición.  


5) No abandonarás tus métodos formales de desarrollo.  


6) Documentarás suficientemente.  


7) No comprometerás los estándares de calidad.  


8) No serás dogmático.  


9) Comprobarás, comprobarás y volverás a comprobar. 


10) Reutilizarás cuanto puedas.



Ventajas

v  Ofrece un fundamento para entornos de especificación que  dan lugar a modelos de análisis más completos, consistentes y carentes de ambigüedad, que aquellos que se producen empleando métodos convencionales u orientados a objetos.
v  Mayor Consistencia.

Desventajas

v  * Complejo.
v  * Demanda mucho tiempo.


Modelo de Tecnica de 4ta Generacion



Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen´por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, mas tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.


Los tipos más comunes de generadores de código curen uno o varios de los siguientes aspectos:
  • Acceso a base de datos:  utilizando lenguajes de consulta de alto nivel. 
  • Generadores de códigos:  a partir de una especificación de los requisitos se genera automáticamente toda la aplicación. 
  • Generación de pantallas: permitiendo diseñar la pantalla dibujandola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada. 
  • Gestión de entornos gráficos.
  • Generación de informes.
  •  
El paradigma T4G para la ingeniería de software se describe en la siguiente figura:









Los pasos de los paradigmas son: 


  • Recolección de requerimientos
  • Estrategia de Diseño
  • Implementación usando T4G 
  • Producto. 


Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. Idealmente el cliente debe describir los requerimientos y estos debe traducirse directamente en un prototipo operacional pero este no funciona. 

El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo en este momento el dialogo cliente técnico descrito por los otros paradigmas permanecen como una pequeña parte esencial del enfoque T4G.

Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, usando un lenguaje de cuarta generación no procedimental (L4G) sin embargo es necesario un mayor esfuerzo para desarrollar una estrategia del diseño para el sistema incluso si se utiliza un L4G. 


El uso de T4G sin diseño para grandes proyectos causará las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales.

Permite especificar el software usando lenguajes especializados o notaciones gráficas que describan el problema. 

Estas Tecnicas de la 4ta Generacion:
  • Requiere usar alguna herramienta CASE (Computer-aided Software Engineering) con herramientas tales como: SQL (Structured Query Language), generador de reportes, base de datos, definidores de pantallas, generadores de código, generador de gráficas, hoja de cálculo, etc.
  • Idealmente el cliente describe los requisitos, que son traducidos inmediatamente a un prototipo operativo.
  • En aplicaciones pequeñas, se puede ir directamente a la implementación usando un lenguaje de cuarta generación (4GL).
  • En aplicaciones grandes, el uso de 4GL sin diseño provocará los mismos problemas que los otros paradigmas (poca calidad, mantenimiento pobre y mala aceptación del cliente).
  • El uso de 4GL permite al desarrollador centrarse en la representación de los resultados deseados.
  • Para transformar una implementación 4GT en un producto, el desarrollador debe dirigir una prueba completa, hacer una buena documentación y ejecutar el resto de las actividades de integración requeridas en los otros paradigmas. Además, el software desarrollado con 4GT debe ser construido de modo que facilite el mantenimiento.


Entre las críticas mas habituales están las siguientes:


  • No son mas fáciles de utilizar; Que los lenguajes de tercera generación.
  • El código fuente que produce es ineficiente; Al estar generado automáticamente no pueden hacer uso de de los trucos habituales para aumentar el rendimiento, que se basan en el buen conocimiento de cada caso en particular.
  • Sólo son aplicables al software de gestión; la mayoría de las herramientas de cuarta generación estan orientadas a la gerneración a partir de grandes bases de datos, pero últimamente estan surgiendo herramientas que generan esquemas de códigos para aplicaciones de ingeniería y de timpo real.

Aplicación de Modelo DRA al Caso de Estudio Fundación FES

Modelado de Gestion



Modelado de Datos



Modelado de Procesos



Generacion de Aplicaciones



Prueba y Validacion



Gestion de Configuracion del Software GCS

Concepto
 
Es un conjunto de actividades aplicadas a la Línea Base para gestionar los cambios del software a lo largo del ciclo de vida e implica una revisión técnica formal (RTF) de los Elementos de Configuración del Software( ECS).

 
Los ECS son objetos que poseen sus nombres, atributos y relaciones entre ellos. Una manera fácil de obtenerlos, es respondiendo las preguntas orientadoras:

1.         ¿Cómo identifico y gestiono las diferentes versiones existentes de un mismo software (y s documentación)?
2.         ¿Cómo controlo los cambios, antes y después que he entregado software al cliente?
3.       ¿Quién tiene la responsabilidad de aprobar y asignar prioridades en los cambios (la organización o mi equipo de trabajo)?
4.        ¿Cómo garantizo que los cambios realizados han sido los adecuados?
5.        ¿Qué mecanismos se usan para avisar a otros, de los cambios realizados?
  
Los cambios se clasifican como completos y parciales:

1.CAMBIOS COMPLETOS: Implica una modificación general en las diversas líneas base. Y para ello se usa <NOMBRE SOFTWARE> V 1.0, 1.1, 1.2, ….
2.CAMBIOS PARCIALES: Implica una modificación dirigida en alguna línea base. Y para ello se usa <NOMBRE SOFTWARE> V 1.0, 1.0.1, 1.0.2, …. 
En el caso de obtener otro software similar al existente. Se utiliza <NOMBRE SOFTWARE> V 1.0, 2.0, 3.0
 
Para constatar la magnitud del cambio, se practica la
AUDITORÍA DE SISTEMAS.

Garantia de la Calidad del Software SQA

Que es la garantia de la calidad del software?

Es una disciplina de la ingeniería de software se especializa en la aplicación de procesos de calidad a lo largo del proyecto de software.

Su misión no se limita a actividades de verificación, sino que además asume un rol de liderazgo en la gestión de la calidad durante el proceso de creación y diseño del producto. La garantía de calidad no debe confundirse con la técnica específica de control de calidad, cuyo objetivo es verificar el producto. 

Una concepción errónea que aún persiste en la industria, es limitar su acción al aseguramiento de la calidad del producto y a constatar adherencia a estándares.

Responsabilidades
La garantía de calidad toma responsabilidad por los siguientes procesos:
  • gestión de los procesos de ingeniería de software
  • iniciativas de mejoramiento de procesos a lo largo de la organización,
  • integración de los procesos de calidad de ingeniería y servicios a la clientela
El liderazgo de la garantía de calidad puede ser asumida en organizaciones pequeñas o muy jóvenes por el jefe del proyecto, siendo el grupo de desarrollo el responsable de su ejecución. Estos individuos pueden provenir de organizaciones más maduras donde hayan adquirido el "know-how" en procesos de calidad, o pueden hacerse asesorar por consultores externos que los ayuden a definir sus sistema de calidad.

Beneficios

El beneficio principal de un programa de garantía de calidad de software es asegurar a la gerencia del proyecto que los procesos establecidos se han ejecutado cabalmente. Esta evaluación es hecha por un grupo independiente, especializado en métodos de calidad, con un criterio objetivo y con visión de contexto.

Actividades Principales

La garantía de calidad se asegura de lo siguiente:
  • Se usa la metodología de desarrollo apropiada
  • Las actividades de desarrollo han sido debidamente planeadas
  • Se han definido estándares y procedimientos para al proyecto
  • El personal ha sido debidamente entrenado en los procesos de calidad aplicables
  • Se llevan a cabo regularmente revisiones y auditorías independientes
  • El desarrollo es documentado adecuadamente para facilitar la mantención y la reutilización
  • La documentación se produce oportunamente y no después que el desarrollo ha sido completado
  • Los cambios introducidos han sido debidamente controlados
  • Las pruebas efectuadas son eficaces para detectar defectos, especialmente en aquellas áreas de mayor riesgo
  • Las actividades se llevan a cabo de acuerdo a los plazos y en los términos planeados
  • Las desviaciones a los estándares se identifican rápidamente
  • El proyecto está en condiciones para ser sometido a auditorías externas, si corresponde
  • La calidad es verificada con respecto a criterios preestablecidos
  • La gerencia es oportunamente informada de problemas y riesgos relativos a la calidad
  • Los problemas de calidad se analizan y las causas se comunican al proyecto para tomar medidas preventivas que eviten su repetición
 Aspectos de la garantia de la calidad
  
La calidad en el software tiene 3 dimensiones:
  • El sistema de calidad
  • La aplicacion adecuada del proceso
  • La actividades que aseguran la calidad  del producto
 

miércoles, 20 de octubre de 2010

Conceptos Del Espectro De Gestion

La gestión eficaz de un proyecto de software se centra en las cuatro P's: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos.

El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.
 

PERSONAL


El <<factor humano>> es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) <<para aumentar la preparación de organizaciones del software.


El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equio..


PRODUCTO

El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).
 


El gestor de un proyecto de software se enfrenta a un dilema al inicio de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida.



Ámbito del software.



El ámbito se define respondiendo a las siguientes cuestiones:


Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultados del contexto?


Objetivos de información. ¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué objetos de datos son requeridos de entrada?


Función y rendimiento. ¿Qué función realiza el software para transformar la información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?



Descomposición del problema.



La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente. Más bien, la descomposición se aplica en dos áreas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se empleará para entregarlo.

PROCESO


Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.
 


El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para (1) los clientes que han solicitado el producto y la gente que realizará el trabajo; (2) las características del producto en sí, y (3) el entorno del proyecto en el que trabaja el equipo de software.

Maduración del producto y del proceso.


La planificación de un proyecto empieza con la maduración del producto y del proceso. Se asumen las siguientes actividades estructurales:



· Comunicación con el cliente- tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación- tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo- tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería- tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente- tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.

Descomposición del proceso

Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido.



Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.


PROYECTO



Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.



Para gestionar un proyecto de software con éxito, debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel define diez señales que indican que un proyecto de sistemas de información está en peligro:



1.- La gente del software no comprende las necesidades de los clientes.
2.- El ámbito del producto está definido pobremente.
3.- Los cambios están mal realizados.
4.- La tecnología elegida cambia.
5.- Las necesidades del negocio cambian (o están mal definidas)
6.- Las fechas de entrega no son realistas.
7.- Los usuarios se resisten.
8.- Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente)
9.- El equipo del proyecto carece del personal con las habilidades apropiadas.
10.- Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones.


PRACTICAS CRITICAS

  • Gestion Basada en el rendimiento
  • Gestion formal del riesgo
  • Riesgo
  • Oportunidad de ser problemas
  • Impacto
  • Costo emprico y estraccion de la planificacion
  • Gestion basada en metricas
  • Segmento del valor ganado
  • Segmento de defectos frente a objetivos de calidad
  • Gestion del programa personal