Paranormal Activity 2. ADOO. By Nashua.
Paradigmas (Modelos)
La ingeniería de software está compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos.
PARADIGMA CICLO DE VIDA DEL SOFTWARE
Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.
Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.
La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
· estructura de datos
· arquitectura de software
· detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta 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 enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
El ciclo de vida clásico es el mas viejo y más ampliamente usado paradigma en la ingeniería de software. Sin embargo con el paso de unos cuantos años se han producido criticas al paradigma, incluso por seguidores activos que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se presentan algunas veces cuando se aplica este paradigma se encuentran:
1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre ocurre iteraciones y se crea problemas en la aplicación del paradigma.
2. Normalmente es difícil para el cliente establecer explícitamente el principio todos los requerimientos del sistema. El ciclo de vida clásico requiere esto y tiene dificultades para acomodar posibles incertidumbres que puedan existir al comienzo de dichos proyectos.
3. El cliente debe tener paciencia. Una versión funcional del programa no esta disponible hasta las etapas finales del desarrollo del proyecto. Un error importante no detectado hasta que el programa este en funcionamiento puede ser desastroso.
4. Los responsables del desarrollo se retrasan innecesariamente.
PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS
Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:
Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.
CARACTERISTICAS:
· Este paradigma ayuda al cliente a brindar requisitos paso a paso.
· También facilita al programador ir probando algoritmos no explotados con anterioridad, de los que no tiene seguridad de su eficiencia.
· Consiste en la creación de prototipos
DESVENTAJAS:
La construcción de prototipos como paradigma para la ingeniería de software puede ser problemático por las siguientes razones:
1. El cliente ve funcionando lo que parece ser una versión del software ignorando que el prototipo se ha hecho con chicle y alambres, ignora que por las prisas hacer que funcione no han considerado los aspectos de calidad y mantenimiento a largo plazo del software. Cuando se informa al cliente que el producto debe ser reconstruido, este grita horrible y solicita que el producto se le aplique en cuantas mejoras se han necesarias para hacer del prototipo un producto final que funcione. Demasiadas veces el gestor del desarrollo del software sede.
2. El técnico del desarrollo realiza frecuentemente ciertos compromisos de implementación en orden a obtener un prototipo que funcione rápidamente. Puede utilizarse un S.O. o lenguaje de programación inapropiado simplemente porque esta disponible y es conocido. Un algoritmo ineficiente puede implementarse de forma sencilla para demostrar su capacidad; después de pasar un tiempo en el que el técnico esta familiarizado con estas selecciones, olvida las razones por las que eran inapropiadas. La elección menos ideal forma ahora parte integral del sistema.
Aunque se puede presentar problemas, la construcción de prototipos es un paradigma efectivo para la ingeniería de software. La clave de esta es definir desde el comienzo las reglas del juego, esto es que el cliente y el técnico deben de estar de acuerdo en que el prototipo se construya para servir solo como un mecanismo de definición de los requerimientos. Posteriormente ha de ser descartado o al menos una parte y debe construirse el software real con ojos puestos en la calidad y mantenimiento.
PARADIGMA DEL MODELO ESPIRAL
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS:
· Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos.
· Incluye la etapa de análisis de riesgos, no incluida anteriormente.
· Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras.
· La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
· Este es el enfoque más realista actualmente.
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
VENTAJAS:
· El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
· Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
· Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
· Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
· Reduce los riesgos antes de que se conviertan en problemáticos.
PROBLEMAS:
· Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable.
· Requiere gran habilidad y experiencia para valorar el riesgo y saber cuándo detener la evolución.
EL MODELO DRA
El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:
· Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
· Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
· Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
· Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear .
· componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
· Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.
Obviamente la limitación de tiempo impuestas en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
· Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
· DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasaran.
No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.
DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.
PARADIGMA DE TÉCNICAS DE CUARTA GENERACION
El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.
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 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.
Hay algunos méritos en las razones de cada parte. Aunque es algo difícil separar los hechos de las suposiciones es posible resumir el estado actual de los métodos T4G:
1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.
2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño.
3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.
EL MODELO DE DESARROLLO CONCURRENTE
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal está escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento específico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
COMBINACIÓN DE PARADIGMAS
Frecuentemente se describe a los paradigmas de la ingeniería de software tratados en las secciones anteriores como métodos alternativos, para la ingeniería de software en vez de los métodos complementarios.
En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.
No hay comentarios:
Publicar un comentario