EN ESTE BLOG ENCONTRARAS INFORMACION NECESARIA ACERCA A TODO LO RELACIONADO A LA COMPUTACION, PARA AQUELLOS QUE ESTEN INTERESADOS EN ESTE TEMA EN GENERAL.
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 calculo. Cada una de estas herramientas existen, 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.
Los pasos del paradIgma son: Recolección de requerimientos, Estrategia de Diseño, Implementacion usando T4G y 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 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.
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 Proceso Unificado “es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational”, donde confluyen ‘los tres amigos’ como se llaman a sí mismos o los tres grandes: Grady Booch, James Rumbaugh e Ivar Jacobson.
El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas.
“El proceso Unificado es un proceso de desarrollo de software configurable que se adapta a proyectos que varían en tamaño y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología de objetos en el desarrollo de software de misión crítica en una variedad de industrias. Uno de los componentes clave es el UML”
El Proceso Unificado ha adoptado un enfoque que se caracteriza por:
Interacción con el usuario continua desde un inicio
Mitigación de riesgos antes de que ocurran
Liberaciones frecuentes
Aseguramiento de la calidad
Involucramiento del equipo en todas las decisiones del proyecto
Anticiparse al cambio de requerimientos
El Proceso Unificado es un proceso porque “define quién está haciendo qué, cuándo lo hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software” [Jacobson 1998]. Según [Booch 1998], los conceptos clave del Proceso Unificado son:
Fase e iteraciones ¿Cuándo se hace?
Flujos de trabajo de procesos (actividades y pasos) ¿Qué se está haciendo?
Artefactos (modelos, reportes, documentos) ¿Qué se produjo?
Trabajador: un arquitecto ¿Quién lo hace?)
El ciclo de vida del software en el Proceso Unificado
MODELO DE ESAMBLAJE DE 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 ensamblador de componentes configura aplicaciones desde componentes separados del software (algunas veces llamados “clases”).
Esto se debe gracias a que, si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadoras. En primer lugar se identifica las clases candidatas examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a crear para conseguir el tratamiento. Si estas clases han sido creadas por programas anteriores se almacenan en una biblioteca de clases o depósito. Se determina cuáles de ellas ya existen a fin de reutilizarlas. En caso de que exista alguna que no esté diseñada, se aplican los métodos orientados a objetos. Este proceso se inicia en el estado de Análisis de Riesgos del Espiral y se inserta en el estado de Construcción de Ingeniería.
VENTAJAS.- Existen dos ventajas principales de los CIs sobre los circuitos convencionales: coste y rendimiento. El bajo coste es debido a que los chips, con todos sus componentes, son impresos como una sola pieza por fotolitografía y no construidos por transistores de a uno por vez.
DESVENTAJAS.- Las desventajas del diseño totalmente a la medida son un costo y tiempo de desarrollo mayores, costos fijos mayores, mayor complejidad del software CAD y la necesidad de habilidades mucho mayores por parte del equipo de diseño. Sin embargo, para diseños puramente digitales, las librerías de “celdas estándares”, junto con los sistemas CAD modernos, pueden ofrecer ventajas considerables en términos de costos y desempeño junto a un bajo riesgo. Las herramientas de layout automático son rápidas y fáciles de usar, y ofrecen la posibilidad de optimizar manualmente cualquier aspecto que limite el desempeño del diseño.
Este modelo se basa en ir construyendo con la construcción de cada sistema una biblioteca de Componentes (clases /objetos) , cuando se va a construir un nuevo sistema, se hace el proceso de definir los objetos del sistema, buscar en la librería de objetos, construir los que no existen, meterlos en la biblioteca, emsamblar los objetos, la metodología busca que sea evolutiva pasando por una fase de planificación, análisis de riesgos, ingeniería, construcción y adaptación, evaluación del cliente y repetir estas fases de tal forma que las primeras iteraciones desarrollan los conceptos, al avanzar se desarrollan los nuevos componentes, luego se busca mejorarlos y finalmente se les da mantenimiento.
MODELO DE METODOS FORMALES
Los métodos formales se basan en el empleo de técnicas, lenguajes y herramientas definidos matemáticamente para cumplir objetivos tales como facilitar el análisis y construcción de sistemas confiables independientemente de su complejidad, delatando posibles inconsistencias o ambigüedades que de otra forma podrían pasar inadvertidas.
En los últimos años, la idea de que la formalización matemática del SW es el enfoque más apropiado para conseguir mejorar su calidad va adquiriendo cada vez más fuerza. Los partidarios de los métodos formales defienden que su empleo, a lo largo de todo el ciclo de vida, facilita el desarrollo de especificaciones claras, concisas y no ambiguas, permite el análisis funcional de la especificación y posibilita el desarrollo de implementaciones correctas respecto a su especificación. Sin embargo los detractores aseguran que el empleo de métodos formales supone un volumen de trabajo considerable, aumento en los costes y tiempo de desarrollo y que debe quedar supeditado a herramientas que lo automaticen.
Ventajas de los métodos formales
Se comprende mejor el sistema.
La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.
El sistema se describe de manera más precisa.
El sistema se asegura matemáticamente que es correcto según las especificaciones.
Mayor calidad software respecto al cumplimiento de las especificaciones.
Mayor productividad
Problemática actual de los métodos formales:
La falta de madurez en la práctica de los métodos formales es la causa de la imposibilidad de utilizarlos a nivel industrial tal y como se utilizan otros métodos de la Ingeniería del Software. Algunas de estas causas son las siguientes:
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.
Clasificación de los métodos formales:
Se pueden encontrar multitud de métodos y técnicas formales con lo que los criterios de clasificación son bastante variados. La clasificación más común se realiza en base al modelo matemático subyacente en cada método, de esta manera podrían clasificarse en:
Especificaciones basadas en lógica de primer orden y teoría de conjuntos: 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: Z, VDM y B.
Especificaciones algebraicas: proponen una descripción de estructuras de datos estableciendo tipos y operaciones sobre esos tipos.
Para cada tipo se define un conjunto de valores y operaciones sobre dichos valores. Las operaciones de un tipo se definen a través de un conjunto de axiomas o ecuaciones que especifican las restricciones que deben satisfacer las operaciones. Métodos más conocidos: Larch, OBJ, TADs.
Especificación de comportamiento:
Métodos basados en álgebra de procesos: modelan la interacción entre procesos concurrentes. Esto ha potenciado su difusión en la especificación de sistemas de comunicación (protocolos y servicios de telecomunicaciones) y de sistemas distribuidos y concurrentes. Los más conocidos son: CCS,CSP y LOTOS.
Métodos basados en Redes de Petri: una red de petri es un formalismo basado en autómatas, es decir, un modelo formal basado en flujos de información. Permiten expresar eventos concurrentes. Los formalismos basados en redes de petri establecen la noción de estado de un sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y post condiciones) describe la evolución del sistema entendida como la producción y consumo de marcas en varios puntos de la red.
Métodos basados en lógica temporal: se usan para especificar sistemas concurrentes y reactivos. Los sistemas reactivos son aquellos que mantienen una continua interacción con su entorno respondiendo a los estímulos externos y produciendo salidas en respuestas a los mismos, por lo tanto el orden de los eventos en el sistema no es predecible y su ejecución no tiene por qué terminar.
El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos. En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental caracteristicas:
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
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/o 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 EN ESPIRAL
El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software.Las actividades de este modelo son una espiral, cada bucle es una actividad. Para cada actividad habrá cuatro tareas:
No. 1
Planificación:
Determinación de objetivos, alternativas y restricciones.
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
No. 2
Análisis de riesgo:
Análisis de alternativas e identificación/resolución de riesgos.
No. 3
Ingeniería:
Desarrollo del producto del “siguiente nivel”
Tareas de la actividad propia y se prueba.
Análisis de alternativas e identificación resolución de riesgos.
No.4
Evaluación del cliente:
Valorización de los resultados de la ingeniería.
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.
El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.
MODELO DE DESARROLLO CONCURRENTE
El Modelo de Desarrollo Concurrente conocido además como Ingeniería Concurrente dado por Davis Sitaram, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor.
Provee una meta-descripción del proceso del software. El modelo concurrente tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
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 encontrará 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.
El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. 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.
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. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones:
1. Dimensión de sistemas.
2. Dimensión de componentes.
Los aspectos del nivel de sistema se afrontan mediante tres actividades: diseño, ensamblaje y uso.
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.
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.
Ventajas
• Excelente para proyectos en los que se conforman grupos de trabajo independientes.
• Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
• Si no se dan las condiciones señaladas no es aplicable.
• Si no existen grupos de trabajo no se puede trabajar en este método
El modelo de desarrollo de software se compone de una mezcla de varios elementos, entre los que se encuentran la filosofía, el modelo de negocio, y el licenciamiento. Ni la calidad ni el desempeño dependen del modelo.
CONCEPTO DE MODELO:
Se ha propuesto, igualmente, que un modelo es una estructura conceptual que sugiere un marco de ideas para un conjunto de escripciones que de otra manera no podrían ser sistematizadas. De esta manera, su estructura es diferente de la que se supone existe en el conjunto de fenómenos de la naturaleza. El modelo concebido en esta forma, impulsa la inteligibilidad y ayuda a la comprensión de los fenómenos, ya que proporciona los canales de interconexión entre hechos que sin la existencia de los lazos inferenciales, podrían permanecer aislados e independientes unos de otros.
CONCEPTO DE SOFTWARE:
Se denomina software, programática, equipamiento lógico o soporte lógico a todos los componentes intangibles de un ordenador o computadora, es decir, al conjunto de programas y procedimientos necesarios para hacer posible la realización de una tarea específica, en contraposición a los componentes físicos del sistema (hardware). Esto incluye aplicaciones informáticas tales como un procesador de textos, que permite al usuario realizar una tarea, y software de sistema como un sistema operativo, que permite al resto de programas funcionar adecuadamente, facilitando la interacción con los componentes físicos y el resto de aplicaciones.
CONCEPTO DE DESARROLLO DE SOFTWARE:
Se persigue que a través de la incursión coordinada por los principios, las técnicas, metodologías y tecnologías de avanzada, se pueda tener una visión aplicada de los procesos de desarrollo de software y del aseguramiento y certificación de la calidad en los mismos, de tal forma que se logre evidenciar suficientemente la importancia y los beneficios resultantes de la aplicación adecuada de dichos modelos en el producto final de cualquier tipo de desarrollo.
La especialización busca crear una cultura en el profesional estudiante, mediante la cual a partir de su propia disciplina sea capaz de aplicar y reapropiar conocimientos científicos, técnicos y vivenciales con el objetivo de mejorar los procesos de construcción de software en organizaciones, establecer estrategias para el desarrollo de productos de calidad y su adecuada planeación y comercialización en el medio colombiano, latinoamericano y global.
MODELO DE DESARROLLO DE SOFTWARE
"MODELO DE CICLO DE VIDA CLASICO O EN CASCADA"
El método del ciclo de vida para desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información.
El método del ciclo de vida para el desarrollo de sistemas consta de las siguientes actividades:
1) Investigación preliminar
La solicitud para recibir ayuda de un sistema de información pueden originarse por una persona, cuando se formula la solicitud comienza la primera actividad del sistema.
2) Aprobación de la solicitud
Algunas organizaciones reciben tantas solicitudes de sus empleados que sólo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes.
3) Determinación de los requisitos del sistema.
Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a ciertas preguntas claves. Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa. Cuando no es posible entrevistar, en forma personal a los miembros de grupos grandes dentro de la organización, se emplean cuestionarios para obtener esta información.
4) Diseño del sistema.(diseño lógico)
El diseño de un sistema de información responde a la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Es común que los diseñadores hagan un esquema del formato o pantalla que esperan que aparezca cuando el sistema esta terminado, se realiza en papel o en la pantalla de una terminal utilizando algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas.
5) Desarrollo de software (diseño físico).
Los encargados de desarrollar software pueden instalar software comprado a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Los programadores son responsables de la documentación de los programas y de explicar su codificación, esta documentación es esencial para probar el programa y hacer el mantenimiento.
6) Prueba de sistemas.
Durante esta fase, el sistema se emplea de manera experimental para asegurarse que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema, para que los analistas observen si tratan de emplearlo en formas no previstas, antes de que la organización implante el sistema y dependa de él.
7) Implantación y evaluación.
La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas. Los sistemas de información deben mantenerse siempre al día, la implantación es un proceso de constante evolución.
La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones.
MODELO DE CICLO DE VIDA CLASICO
"MODELO DE CONSTRUCCION DE PROTOTIPOS"
Este modelo comienza con la recolección de requisitos, el desarrollador y el cliente definen los objetivos globales para el software, originándose un diseño rápido que se centra en una representación de esos aspectos del software que sean visibles para el usuario/cliente. De este diseño surge la construcción de un prototipo y este es evaluado por el cliente/usuario. La interacción ocurre cuando el prototipo satisface las necesidades del cliente.
CONSTRUCCIÓN DE PROTOTIPOS.
Otro modelo adicional, como alternativa a los mencionados o bien como complemento a los mismos es la construcción de prototipos, que 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.
Los mitos del software son creencias acerca del software y de los procesos empleados para construirlos se pueden rastrear hasta los primeros días de la computación. Los mitos tienen ciertos atributos que los convierten en insidiosos.
Mitos de la administración
Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir las propuestas, hacer que no se retrase el proyecto y mejorar la calidad. Un gestor de software se agarra frecuentemente a un mito del software.
Mito: Si se falla en la planificación, se puede añadir mas programadores y adelantar el tiempo perdido.
Mitos del cliente
En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores de software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el desarrollador del software.
Mito: Si los requisitos del proyecto cambian continuamente, los cambios pueden acomodarse fácilmente, ya que el software es flexible.
Mitos de los desarrolladores
Los mitos en los que aun creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir.
Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.
MITOS DE LAS COMPUTADORAS
ENFOQUE DE INGENIERIA DE SOFTWARE EN INFORMATICA
La ingeniería informática es la profesión que consiste en la aplicación de los fundamentos de la ciencia de la computación, la electrónica y la ingeniería de software, para el desarrollo de soluciones integrales de cómputo y comunicaciones, capaces de procesar información de manera automática.
Por lo que se refiere al soporte físico, la ingeniería informática se fundamenta en la tecnología electrónica, lo que le permite a los ordenadores interactuar con sistemas físicos, así como desarrollar interfaces de comunicación y control entre el ordenador y diversos dispositivos mecánicos y eléctricos, tales como sistemas de adquisición de datos, instrumentación virtual, control de robots, sistemas de iluminación, etc.
En el aspecto lógico y formal, la ingeniería informática se fundamenta en la teoría de autómatas, los lenguajes formales, la teoría de la información, el diseño de algoritmos, el reconocimiento de patrones, la inteligencia artificial y la ingeniería del conocimiento.
En el aspecto de integración, la ingeniería informática comprende multitud de técnicas y conocimientos específicos para el diseño, construcción y mantenimiento de software, sujetos a restricciones de calidad, tiempo y coste. El conjunto de estas técnicas se conoce como ingeniería del software.
TENDENCIAS DE LA INGENIERIA DE SOFTWARE
Una de las preocupaciones actuales más urgentes de la industria del software es crear sistemas confiables y de mayor calidad con menor inversión de tiempo y costo, que resuelvan problemas cada vez más complejos. Es preciso utilizar técnicas avanzadas de la ingeniería de software que ayuden a aliviar el esfuerzo en las diferentes etapas del ciclo de vida.
Tal como lo manifiestan J. Martin y J. Odell, en el software se necesita un avance en:
*Complejidad
*Capacidad de diseño
*Flexibilidad
*Rapidez de desarrollo
*Facilidad de modificación
*Confiabilidad
La Tecnologia Orientada a Objetos ha demostrado ser una excelente herramienta para resolver problemas de gran envergadura y complejidad, permitiendo obtener sistemas interoperables, modulares, evolutivos y con alto índice de reusabilidad. La reutilización conduce a un desarrollo más rápido y programas de mejor calidad.
Las técnicas orientadas a objetos combinadas con otras herramientas como las CASE (ingeniería de software asistida por coputadora), programación visual, generadores de código, metodologías basadas en depositos, bases de datos, bibliotecas de clases que maximicen la reutilización, tecnología cliente servidor, etc.; pueden proporcionar la magnitud de cambio necesario para lograr ese salto anteriormente mencionado.
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversasaplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.
Objetivos
Mejorar la productividad en el desarrollo y mantenimiento del software.
Aumentar la calidad del software.
Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.
Mejorar la planificación de un proyecto
Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
Gestión global en todas las fases de desarrollo de software con una misma herramienta.
Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
CLASIFICACION
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.
La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:
Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.
Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.
HISTORIA DE LA INGENIERIA DE SOFTWARE
La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse según Alan Davis como “la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios”.
El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías.
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.
CRISIS DE SOFTWARE
El término “Crisis del Software” fue acuñado a principios de los años 70, cuando la ingeniería de software era prácticamente inexistente. El término expresaba las dificultades del desarrollo de software frente al rápido crecimiento de la demanda por software, de la complexidad de los problemas a ser resueltos y de la inexistencia de técnicas establecidas para el desarrollo de sistemas que funcionaran adecuadamente o pudieran ser validados.
CAUSAS DE LA CRISIS DE SOFTWARE:
Una de las principales causas de todo esto, si no la principal, era el enfoque dado al proceso de desarrollo de software, el cual era malo e incluso a veces era inexistente. En este proceso, solo ¼ del tiempo de desarrollo se dedicaba a las fases de análisis, diseño, codificación y pruebas, y más de ¾ del tiempo se dedicaba a correcciones y mantenimiento. Es evidente que dedicándole sol ¼ del tiempo a las primeras fases, se arrastran errores graves, sobre todo procedentes de las fases de análisis y diseño, lo que dificultaba muchísimo la implementación, produciendo constantes paradas y retrocesos para revisar este análisis/diseño.
Para que nos hagamos una idea, el conjunto de las fases de análisis y diseño abarcaban el 8% del tiempo total de desarrollo de software. Además casi el 80% de los errores se producían en estas dos fases, con lo que se incrementaba el coste de corrección de errores conforme evolucionaban las fases de manera bestial. Con estos indicadores estaba claro que algo estaba fallando y que el proceso de desarrollo de software necesitaba un cambio radical.
Durante finales de los años 50 y principios de los 60, la potencia computacional de las maquinas era bastante limitada. Es por esto que los programas que se desarrollaban eran “simples” desde nuestro punto de vista actual. Seguían un proceso de desarrollo bastante artesanal, sin una metodología o un camino a seguir para su desarrollo. En esta época se solían usar los lenguajes de bajo nivel para el desarrollo de Software.
Pero a finales de los 60, la potencia de las maquinas empezó a aumentar de forma considerable. Empezaron a aparecer los lenguajes de programación de alto nivel, y las maquinas necesitaban programas mucho más complejos de los desarrollados hasta la época. En definitiva, fue un salto tremendo en cuanto a potencial de hardware, que no fue acompañado por un salto en el desarrollo de software.
En esta época, se empezó a concebir el Software como producto, y se empezaron a desarrollar algunos proyectos para que funcionaran en las máquinas de la época. Pero aparecieron importantes problemas: los productos excedían la estimación de costes, había retrasos en las entregas, las prestaciones no eran las solicitadas, el mantenimiento se hacía extremadamente complicado y a veces imposible, las modificaciones tenían un coste prohibitivo…en resumen, se desarrollaba software de mala calidad, ya que la técnica utilizada para desarrollar pequeños programas para maquinas con mucho menos potencial se quedaba desfasada, y muchas veces este software acababa en el olvido.
.jpg)
