La Ingeniería del Software va a introducirse en la cuarta década de su existencia y sufre de los muchos puntos fuertes y débiles. La Ingeniería del Software se va aproximando a su edad media con muchos logros a sus espaldas, pero con un trabajo significativo todavía por hacer. Hoy en día, está reconocida como una disciplina legítima, digna de tener una investigación seria, un estudio concienzudo y un grande y tumultuoso debate. En la industria el Ingeniero del software ha sustituido al programador como titulo de trabajo preferente. Los modelos de procesos de software, métodos de ingeniería de software y herramientas se han adoptado con éxito en el amplio espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la necesidad de un enfoque más disciplinado del software.
La búsqueda de técnicas que mejorasen la calidad y permitiesen reducir los costos de las soluciones basadas en computadoras ha sido uno de los objetivos más perseguidos desde los inicios de la informática. A mediados de los 60, la creación de un producto software se convertía en una tarea angustiosa, se hizo por tanto necesario introducir una serie de herramientas y procedimientos que facilitaran por un lado, la labor de creación de nuevo software y por otro, la comprensión y el manejo del mismo. Estos fueron los inicios de la Ingeniería del Software. Con el paso del tiempo, la evolución de estos métodos nos han llevado a reconocer la Ingeniería del Software como una verdadera disciplina, derivada de una investigación seria y de un estudio minucioso.
La evolución del Software
Durante los primeros años de la era de la computadora, el software se contemplaba como un añadido. La programación de computadoras era un "arte de andar por casa" para el que existían pocos métodos sistemáticos. El desarrollo del software se realizaba virtualmente sin ninguna planificación, hasta que los planes comenzaron a descalabrarse y los costes a correr. Los programadores trataban de hacer las cosas bien, y con un esfuerzo heroico, a menudo salían con éxito. El software se diseñaba a medida para cada aplicación y tenia una distribución relativamente pequeña.
La mayoría del software se desarrollaba y era utilizado por la misma persona u organización. La misma persona lo escribía, lo ejecutaba y, si fallaba, lo depuraba. Debido a este entorno personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien y, la documentación normalmente no existía.
La segunda era en la evolución de los sistemas de computadora se extienden desde la mitad de la década de los sesenta hasta finales de los setenta. La multiprogramación y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre - maquina. Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticación del hardware y del software. Los sistemas de tiempo real podían recoger, analizar y transformar datos de múltiples fuentes, controlando así los procesos y produciendo salidas en milisegundos en lugar de minutos. Los avances en los dispositivos de almacenamiento en línea condujeron a la primera generación de sistemas de gestión de bases de datos.
La segunda era se caracterizo también por el establecimiento del software como producto y la llegada de las "casas del software". Los patronos de la industria, del gobierno y de la universidad se aprestaban a "desarrollar el mejor paquete de software" y ganar así mucho dinero.
Conforme crecía el numero de sistemas informáticos, comenzaron a extenderse las bibliotecas de software de computadora. Las casas desarrollaban proyectos en los que se producían programas de decenas de miles de sentencia fuente. Todos esos programas, todas esas sentencias fuente tenían que ser corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos dispositivos hardware que se hubieran adquirido. Estas actividades se llamaron colectivamente mantenimiento del software.
La tercera era en la evolución de los sistemas de computadora comenzó a mediados de los años setenta y continuo mas allá de una década. El sistema distribuido, múltiples computadoras, cada una ejecutando funciones concurrente y comunicándose con alguna otra, incrementó notablemente la complejidad de los sistemas informáticos. Las redes de área local y de área global, las comunicaciones digitales de alto ancho de banda y la creciente demanda de acceso "instantáneo" a los datos, supusieron una fuerte presión sobre los desarrolladores del software.
La conclusión de la tercera era se caracterizo por la llegada y amplio uso de los microprocesadores. El microprocesador ha producido un extenso grupo de productos inteligentes, desde automóviles hasta hornos microondas, desde robots industriales a equipos de diagnósticos de suero sanguíneo.
La cuarta era de la evolución de los sistemas informáticos se aleja de las computadoras individuales y de los programas de computadoras, dirigiéndose al impacto colectivo de las computadoras y del software. Potentes maquinas personales controladas por sistemas operativos sofisticados, en redes globales y locales, acompañadas por aplicaciones de software avanzadas se han convertido en la norma.
La industria del software ya es la cuna de la economía del mundo. Las técnicas de la cuarta generación para el desarrollo del software están cambiando en la forma en que la comunidad del software construye programas informáticos. Las tecnologías orientadas a objetos están desplazando rápidamente los enfoques de desarrollo de software más convencionales en muchas áreas de aplicaciones.
Sin embargo, un conjunto de problemas relacionados con el software ha persistido a través de la evolución de los sistemas basados en computadora, y estos problemas continúan aumentando.
los avances del software continúan dejando atrás nuestra habilidad de construir software para alcanzar el potencial del hardware.
Nuestra habilidad de construir nuevos programas no pueden ir al mismo ritmo de la demanda de nuevos programas, ni podemos construir programas lo suficientemente rápido como para cumplir las necesidades del mercado y de los negocios.
El uso extenso de computadoras ha hecho de la sociedad cada vez más dependiente de la operación fiable del software. Cuando el software falla, pueden ocurrir daños económicos enormes y ocasionar sufrimiento humano.
Luchamos por construir software informático que tengan fiabilidad y alta calidad.
Nuestra habilidad de soportar y mejorar los programas existentes se ve amenazada por diseños pobres y recursos inadecuados.
En respuesta a estos problemas, las practicas de la Ingeniería del Software se están adoptando en toda la industria.
Que es la Ingeniería del Software ?
La Ingeniería del software es una disciplina o área de la Informática o Ciencias de la Computación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Hoy día es cada vez mas frecuente la consideración de la Ingeniería del Software como una nueva área de la Ingeniería, y el Ingeniero del Software comienza a ser una profesión implantada en el mundo laboral internacional, con derechos, deberes y responsabilidades que cumplir, junto a una, ya, reconocida consideración social en el mundo empresarial y, por suerte, para esas personas con brillante futuro.
La ingeniería del software trata con áreas muy diversas de la Informática y de las Ciencias de la Computación, tales como construcción de compiladores, sistemas operativos o desarrollos de Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a una infinidad de áreas tales como: negocios, investigación científica, medicina, producción, logística, banca, control de trafico, meteorología, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.
Definición del termino Ingeniería del Software
El termino Ingeniería se define en el Diccionario de la Real Academia Española de la Lengua como: "1. Conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la utilización de la materia y de las fuentes de energía. 2. Profesión y ejercicio del Ingeniero" y el termino Ingeniero se define como: persona que profesa o ejerce la Ingeniería. De igual modo la Real Academia de Ciencias Exactas, Físicas y Naturales de España define el termino Ingeniería como: " Un conjunto de conocimientos y técnicas cuya aplicación permite la utilización racional de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras realizaciones provechosas para el hombre".
Evidentemente, si la Ingeniería del Software es una nueva Ingeniería, parece lógico que reúna las propiedades citadas en las definiciones anteriores. Sin embargo ni el DRAE(Diccionario de la Real Academia Española de la Lengua), ni la Real Academia Española de Ciencias han incluido todavía el termino en sus ultimas ediciones; en consecuencia vamos a recurrir para su definición mas precisa a algunos de los autores mas acreditados que comenzaron en su momento a utilizar el termino o bien en las definiciones dadas por organismos internacionales profesionales de prestigio tales como IEEE o ACM, de los cuales se han seleccionado las siguientes definiciones de Ingeniería del Software.
Definición 1:
Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software [Zelkovits, 1978].
Definición 2:
Ingeniería del Software es la aplicación practica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación necesaria requerida para desarrollar, operar(funcionar) y mantenerlos [Bohem, 1976].
Definición 3:
Ingeniería del Software trata del establecimiento de los principios y métodos de la Ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales [Bauer, 1972].
Definición 4:
La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación(funcionamiento) y mantenimiento del software; es decir, la aplicación de Ingeniería al software [IEEE, 1993].
Una perspectiva industrial
En los primeros días de la informática, los sistemas basados en computadora se desarrollaban usando técnicas de gestión orientadas a hardware. Los gestores del proyecto se centraban en el hardware, debido a que era el factor principal del presupuesto en el desarrollo del sistema. Para controlar los costes del hardware, los gestores instituyeron controles formales y estándares técnicos. Exigían un análisis y diseño completo antes de que algo se construyera. Median el proceso para determinar donde podían hacerse mejoras. Dicho sencillamente, aplicaban los controles, los métodos y las herramientas que reconocemos como Ingeniería del Hardware. Desgraciadamente, el software no era normalmente mas que un añadido.
En los primeros días, la programación se veía como un arte. Existían pocos métodos formales y pocas personas los usaban.
Hoy, la distribución de costes en el desarrollo de sistemas informáticos ha cambiado drásticamente. El software, en lugar del hardware, es normalmente el elemento principal del coste.
En las décadas pasadas los ejecutivos y muchos aprendices técnicos se habían hechos las siguientes preguntas:
Por qué lleva tanto tiempo terminar los programas?
Por qué es tan elevado el coste?
Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes?
Por qué nos resulta difícil constatar el progreso conforme se desarrolla el software?
Estas y otras muchas cuestiones son una manifestación del carácter del software y de la forma en que se desarrolla, un problema que ha llevado a la adopción de la Ingeniería del Software como practica.
Competitividad del Software
Durante muchos años, los desarrolladores de software empleados por grandes y pequeñas compañías eran los únicos en este campo. Como todos los programas se construían de forma personalizada, los desarrolladores de este software domestico dictaban los costes, planificación y calidad. Hoy, todo esto ha cambiado.
El software ahora es una empresa extremadamente competitiva. El software que se construía internamente ahora se puede adquirir en tiendas. Muchas empresas que en su momento pagaban legiones de programadores para crear aplicaciones especializadas ahora ofrecen a un tercero mucho del trabajo del software.
El Software
La descripción de software en un libro de texto podría tomar la forma siguiente: el software es (1) instrucciones que cuando se ejecutan proporcionan la función y el rendimiento deseados, (2) estructuras de datos que permiten a los programas manipular adecuadamente la información, y (3) documentos que describen la operación y el uso de programas.
Características del Software
Para poder comprender lo que es el software (y consecuentemente la Ingeniería del Software), es importante examinar las características del software que lo diferencian de otras cosas que los hombres pueden construir.
El software es un elemento del sistema que es lógico, en lugar de físico. Por lo tanto el software tiene unas características considerablemente distintas a las del hardware:
El software se desarrolla, no se fabrica en un sentido clásico. Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relación entre las personas dedicadas y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren de la construcción de un producto, pero los métodos son diferentes.
Los costes del software se encuentran en la ingeniería. Esto significa que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación.
El software no se estropea. El software no es susceptible a los males del entorno que hacen que el hardware se estropee. Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software. Cuando un componente se estropea, se sustituye por una pieza de repuesto. No hay pieza de repuesto para el software. Cada fallo en el software indica un error en el diseño o en el proceso mediante el que se tradujo el diseño a código maquina ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware.
La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. No existen catálogos de componentes de software. Se puede comprar software ya desarrollado, pero solo como una unidad completa, no como componentes que pueden reensamblarse en nuevos programas.
importante para un componente de software de alta calidad. El componente debería diseñarse
Componentes del Software
La reutilización es una característica e implementarse para que pueda volver a ser reutilizado en muchos programas diferentes.
Los componentes de software se construyen mediante un lenguaje de programación que tiene un vocabulario limitado, una gramática definida explícitamente y reglas bien formadas de sintaxis y semántica.
Aplicaciones del Software
El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto especifico de pasos procedimentales (es decir, un algoritmo). (Excepciones notables a esta regla son el software de los sistemas expertos y de redes neuronales).
Las siguientes áreas del software indican la amplitud de las aplicaciones potenciales:
Software de Sistemas: El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. El área del Software de Sistemas se caracteriza por una fuerte interacción con el hardware de la computadora; una gran utilización por múltiples usuarios; una operación concurrente que requiere una planificación, una compartición de recursos y una sofisticada gestión de procesos; unas estructuras de datos complejas y múltiples interfaces externas. (p. Ej.: compiladores, editores, utilidades, ciertos componentes del sistema operativo, utilidades de manejo de periféricos, procesadores de telecomunicaciones).
Software de Tiempo Real: El software que mide/analiza/controla sucesos del mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolecta y da formato a la información recibida del entorno externo, un componente de análisis que transforma la información recibida del entorno externo, un componente de análisis que transforma la información según lo requiera la aplicación, un componente de control/salida que responda al entorno externo y un componente de monitorización que coordina todos los demás componentes, de forma tal que pueda mantenerse la respuesta en tiempo real.
Software de Gestión: El procesamiento de información comercial constituye la mayor de las áreas de aplicación del software. Los sistemas discretos (p. Ej.: nominas, cuentas de haberes/débitos, inventarios, etc.), han evolucionado hacia el software de sistemas de información de gestión (SIG), que accede a una o más bases de datos grandes que contienen información comercial. Las aplicaciones en esta área reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Además de las tareas convencionales de procesamiento de datos, las aplicaciones de software de gestión también realizan calculo interactivo (p. Ej. : el procesamiento de transacciones en puntos de ventas).
Software de Ingeniería y Científico: El software de Ingeniería y Científico está caracterizado por los algoritmos de manejo de números. Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de los lanzadores espaciales y desde la biología molecular a la fabricación automática.
Software Empotrado: El software Empotrado reside en memoria de solo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (p. Ej.: el control de las teclas de un horno de microondas) o suministrar una función significativa y con capacidad de control (p. Ej.: funciones digitales en un automóvil, tales como control de la gasolina, indicaciones en el salpicadero, sistemas de frenado, etc.).
Software de Computadoras Personales: El mercado del software de computadoras personales ha germinado en la pasada década. El procesamiento de textos, las hojas de calculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras de negocios y personales, y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.
Software de Inteligencia Artificial: El software de inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el calculo o el análisis directo. El área más activa de la IA es la de los sistemas expertos, también llamados sistemas basados en el conocimiento.
Hoy en día el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehículo para hacer entrega de un producto. Como producto, hace entrega de la potencia informática del hardware informático. Si reside dentro de un teléfono celular u opera dentro de una computadora central, el software es un transformador de información, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo información que puede ser tan simple como un solo bit, o tan compleja como una simulación en multimedia. Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de la computadora (sistemas operativos), la comunicación de información (redes), y la creación y control de otros programas (herramientas de software y entornos).
El software de computadora, se ha convertido en el alma mater. Es la maquina que conduce a la toma de decisiones comerciales. Sirve como la base de investigación científica moderna y de resolución de problemas de ingeniería. Es el factor clave que diferencia los productos y servicios modernos. Está inmerso en sistemas de todo tipo: de transportes, médicos, de telecomunicaciones, militares, procesos industriales, entretenimientos, productos de oficina, etc. El software será el que nos lleve de la mano en los avances en todo desde la educación elemental a la Ingeniería Genética.
Evolución de la Ingeniería del Software
Inicialmente la programación de las computadoras era un arte que no disponía de métodos sistemáticos en los que poder basarse para la realización de productos software. Se realizaban sin ninguna planificación. Evolución y Perspectivas de la Ingeniería del Software Posteriormente, desde mediados de los 60 hasta finales de los 70 se caracterizó por el establecimiento del software como un producto que se desarrollaba para una distribución general. En esta época nació lo que se conoce como el mantenimiento del software que se da cuando cambian los requisitos de los usuarios y se hace necesaria la modificación del software. El esfuerzo requerido para este mantenimiento era en la mayoría de los casos tan elevado que se hacía imposible su mantenimiento. A continuación, surge una etapa que se caracteriza por la aparición de una serie de técnicas como la Programación Estructurada y las Metodologías de Diseño que solucionan los problemas anteriores. A finales de esta etapa aparecen las herramientas CASE, aunque como podemos imaginar eran muy rudimentarias.
Ciclo de Vida del Software
El ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren paravalidar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.
Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.
El ciclo de vida básico de un software consta de los siguientes procedimientos:
Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
Diseño general: requisitos generales de la arquitectura de la aplicación.
Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
Implementación
Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.
Modelos de ciclo de vida
Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante).
Modelo en cascada
El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:
Modelo V
El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.
Modelo De Desarrollo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, sólo la última iteración necesita ser descartada.
Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.
Modelo De Desarrollo Evolutivo
Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere.
Modelo de Prototipado de Requerimientos.
El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.
El Prototipado ha sido usado frecuentemente en los 90, porque la especificación de requerimientos para sistemas complejos tienden a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación convenientemente basado en la manipulación, desde un prototipo, en vez de leer una especificación de requerimientos potencialmente ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente.
En caso que ustedes construyan requerimientos bien entendidos, el cliente podría responder con "sí, así es", y nada podría ser aprendido de la experiencia.
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
Determinar qué quieres lograr.
Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, -analizar los riesgos y resultados finales, y seleccionar la mejor.
-Seguir la alternativa seleccionada en el paso 2.
-Establecer qué tienes terminado.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios básicos:
Decidir qué problema se quiere resolver antes de viajar a resolverlo.
Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.
En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5.
En todos estos casos, diversas actividades están ocurriendo simultáneamente. Eligiendo seguir un proyecto usando técnicas de modelación concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.
El analista de sistemas
El Analista de Sistemas es imprescindible en cualquier organización, debido al abanico de destrezas que éste posee y los beneficios que le produce. Se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen.
Todo desarrollo líderizado o no por un analista de sistemas posee fases que pueden dividirse lógica en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. Este conjunto de fases son conocidas como el Ciclo de Vida de Desarrollo de Sistemas, herramienta fundamental para el desempeño de un analista de sistemas.
un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.
¿Qué hace un analista de sistemas?
El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema de información. Como lo indica su nombre, analiza los sistemas informáticos, con el fin de automatizarlos.
Tiene que delimitar el análisis para ver lo que se quiere hacer inicialmente y después darle al usuario nuevas opciones de uso.
Dependiendo de los objetivos del análisis, pueden existir dos problemáticas distintas:
- Análisis de un sistema ya existente para comprender, mejorar, ajustar y/o predecir su comportamiento.
- Análisis como paso previo al diseño de un nuevo sistema-producto.
El analista de sistemas tiene habilidades de comunicación que le permiten relacionarse con diferentes personas diariamente, así como también habilidades de computación.
Se diferencia de un diseñador de software en que el analista describe el problema (el qué hacer) mientras que el diseñador describe la solución (el cómo hacerlo).
El Analista de Sistema nace de la necesidad de recopilar, desglosar, catalogar y analizar información necesaria de una empresa para poder proponer nuevos métodos, mejores o modificar los actuales para que así aumente el desempeño de los departamentos dentro de la organización.
En toda organización un analista se vale de la información de entrada, los procesos modificadores y la información de salida, para así definir los procesos intermedios y poder entender con claridad a la organización. Todos estos flujos y procesos son estudiados sistemáticamente para poder determinar si son los adecuados, si se deben mejorar o si deben ser reemplazados por otros más idóneos.
Santos (1980, p.12) define las funciones del analista de sistemas para la década de los ochenta como sigue;
"…el analista de problemas en computación deberá conocer procedimientos para indagar sobre lo existente y para saber proponer un verdadero sistema racionalizado, pero también deberá conocer sobre modernos sistemas de información, base del diseño, sobre todo en computación… Estos últimos factores son los que justifican tal especialidad, porque realmente debieron existir los analistas de sistemas, aunque no hubiera computadores, toda vez que siempre hubo sistemas para organizar, que posiblemente no se difundieron porque no existieron en importancia esos dos factores que hoy prevalecen: el computador y la información."
La definición de analista de sistemas de Senn (1992, p. 12), agrega: "…Los analistas hacen mucho más que resolver problemas. Con frecuencia se solicita su ayuda para planificar la expansión de la organización…", es decir, el papel de los analistas sobrepasa los limites impuestos por la definición inicial, también cumplen el papel de asesores, ya sea en sistemas manuales o informatizados, o cualquier otro sistema donde la empresa tenga que invertir en información, después de todo esa es la razón de ser del analista.
Comparando las dos definiciones anteriores podemos notar que en veinte años no ha cambiado la descripción de analista de sistemas, más bien se le han atribuido nuevas características que lo definen como un ente de cambio, necesario en cualquier organización con tendencia a crecer.
Según Senn, dependiendo de las funciones de un analista de sistemas se puede clasificar en: Analista de sistemas, Analista y diseñador de sistemas y analista diseñador y programador de sistemas, en donde cada uno se puede identificar y diferenciar de los demás por las actividades que definen sus denominaciones. También podemos clasificar a los analista de sistema como Consultor, Experto de soporte y Agente de cambio, clasificación según Kendall (1997, p.6).
Una pregunta común sobre los analistas de sistemas es ¿Todos los analistas deben programar?, Según Senn (1992, p.16); "…La respuesta depende de la organización. Sin embargo, una cosa es evidente: el analista de sistemas más valioso y mejor calificado es aquel que sabe programar.", ciertamente el analista que tiene fuertes principios de programación sabe que se puede y que no se puede, o que es difícil de desarrollar en un lapso de tiempo, recordemos que todos los proyectos informáticos tienen siempre lapsos de tiempo bien reducidos y que si no se tiene el equipo apropiado es difícil cumplir con los plazos establecidos, lo que trae como consecuencia muchas veces la falla de todo el proyecto. Además el analista programador tiene facilidad para comunicar sus ideas a los constructores de código, ya que él estuvo en ese lugar alguna vez y sabe en que forma se necesita la información al momento de generar código.
Contacto del Analista con los Usuarios
Es difícil determinar el tamaño de un sistema a desarrollar si no conocemos los diferentes niveles del mismo, los diferentes detalles de las salidas de información, a quienes van dirigidas y cual es la mejor forma de hacerlo.
Los analistas de Sistemas están en la obligación de recorrer desde los niveles más altos de la empresa (gerentes y directivos), hasta los niveles más bajos (obreros y empleados) para determinar quienes realmente necesitan la información, con que oportunidad y grado de detalle de cada peldaño de la escalera institucional. "Los gerentes y empleados tienen buenas ideas a qué es lo que si trabaja y qué es lo que no, qué causa problemas y qué no, dónde son necesarios los cambios y dónde no."(Senn, p.13), en efecto, quien mejor que los que día a día ven el sistema y como sus compañeros o subordinados lo reciben, para decirle al analista con anticipación cual será la aceptación del producto final y que mejoras deben tener. A fin de cuentas ellos son los que le sacarán provecho al sistema, los que se alimentarán del mismo.
No hay comentarios:
Publicar un comentario