GESTIÓN DE PROYECTOS DE SOFTWARE
La gestión de proyectos busca las técnicas necesarias para planificar, organizar, supervisar y controlar proyectos de software. El objetivo de gestionar proyectos es tener un producto de alta calidad.
La gestión de un proyecto de software se centra en tres partes como son:
- Personal
- Problema
- Proceso
- Personal: El factor humano es importante en la ingeniería de software. Es importante tener la capacidad de gestión del personal con el fin de aumentar la preparación en la organización del software; ayudando a atraer, motivar y retener el talento necesario para mejorar su capacidad de desarrollo de software.
En toda organización que alcanza la madurez en el área de gestión de personal tiene una mayor probabilidad de implementar unas eficaces prácticas de ingeniería de software, esto guía a que las organizaciones tengan un proceso de software maduro.
- El problema: Se establecen los objetivos y se deben considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Con esta información es posible definir unas estimaciones razonables del costo, una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso.
El desarrollador de software y el cliente deben reunirse para definir los objetivos del proyecto. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán.
Se identifican los datos primarios, funciones y comportamientos que caracterizan el problema, intenta abordar estas características de una manera cuantitativa. También se consideran las soluciones alternativas, estas permiten a los gestores y a los profesionales seleccionar el mejor enfoque.
- Proceso: En el proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Las actividades estructurales se pueden aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad, además permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto.
Personal
El proceso de software lo componen participantes que pueden clasificarse en cinco categorías:
- Gestores superiores: definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto
- Gestores técnicos del proyecto: deben planificar, organizar y controlar a los profesionales que realizan el trabajo del software.
- Profesionales: proporcionan las capacidades técnicas para la ingeniería de un producto
- Clientes: especifica los requisitos para la ingeniería de software.
- Usuarios finales: interaccionan con el software una vez que se ha entregado para la producción.
Para gestionar un proyecto de software, se requiere que el jefe del equipo humano tenga motivación, organización, ideas o innovación. El gestor del proyecto debe concentrarse en entender el problema a resolver, gestionando el flujo de ideas. Existen otras características como dotes de gestión, incentivo de los logros, espíritu de equipo.
Hay muchos motivos por los que los proyectos de software pueden tener problemas como son:
- La escala del desarrollo es grande, esto conduce a tener complejidades y dificultades para coordinar a los miembros del equipo.
- La incertidumbre se dan cambios continuos que impactan en el equipo del proyecto
- La interoperatividad es una característica de los sistemas
El software nuevo debe comunicarse con el anterior y ajustarse a las limitaciones predefinidas impuestas por el sistema. Los miembros de un equipo de ingeniería del software comparten ideas, piden ayudas a medida que surgen los problemas e interactúan los unos con los otros.
Problema
Busca un análisis detallado de los requisitos del software proporcionaría la información necesaria para las estimaciones, claro esta que puede llevar semanas o meses. Se debe examinar el problema al inicio de proyecto, establecer el problema y delimitándolo.
La primera gestión un proyecto de software es determinar el ámbito del software. Se define el contexto, que limitaciones se imponen; el objetivo de la información, que datos se obtienen del software; y la función, que realiza el software para transformar la información.
Para la descomposición del problema tiende a aplicarse la estrategia de divide y vencerás, cuando se enfrenta a problemas complejos, es decir el problema se parte en problemas más pequeños y con esto se busca que sean manejables.
Proceso
Las fases que caracterizan el proceso de software se encuentran la definición, el desarrollo y el mantenimiento. El gestor del proyecto decide qué modelo es el más adecuado para desarrollar el proyecto, luego debe definir un plan preliminar, para luego continuar con la descomposición del proceso. Se debe tener en cuenta la maduración del problema, descomposición del proceso. Es importante invertir tiempo al principio del proyecto para tener un plan con buenas bases que se evidencian durante el desarrollo del proyecto y llevar el control de calidad de dicho proyecto.
viernes, 31 de agosto de 2007
viernes, 24 de agosto de 2007
Solución de preguntas
CUÁLES SON LAS FASES PARA EL DISEÑO DE UN SOFTWARE
Etapas en el ciclo
Una descripción de etapas con que podemos contar a lo largo del ciclo de vida del software; una vez delimitadas en cierta manera las etapas, habrá que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la elección de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia; el orden de las etapas es un factor importante, por ejemplo tener una etapa de validación al final del proyecto, tal como sugiere el modelo en cascada o lineal, puede implicar serios problemas sobre la gestión de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y cuanto más tarde se haga más costoso resultará, por tanto el hecho de contar con una etapa de validación tardía tiene su riesgo y, por su situación en el ciclo, un posible tiempo de reacción mínimo en caso de tener que retornar a fases previas).
▲ Necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).
Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas.
▲ Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso).
Lo más normal será que no resulte posible obtener una buena especificación del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente.
▲ Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
- Funcional
- Estático
- Dinámico
▲ Diseño
Teniendo claro que debe hacer el sistema, determinaremos como se va hacer. ¿Cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.
▲ Implementación
Se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.
▲ Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, ejemplo rendimiento).
▲ Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).
▲ Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (por ejemplo mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución. Ejemplo: nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto.
La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa solamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).
Fase de definición (¿qué hacer?)
- Estudio de viabilidad.
- Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
- Asegurar que los requisitos son alcanzables.
- Formalizar el acuerdo con los usuarios.
- Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
- Identificar soluciones tecnológicas para cada una de las funciones del sistema.
- Asignar recursos materiales para cada una de las funciones.
- Proponer (identificar y seleccionar) subcontratas.
- Establecer métodos de validación del diseño.
- Ajustar las especificaciones del producto.
Fase de construcción
- Generar el producto o servicio pretendido con el proyecto.
- Integrar los elementos subcontratados o adquiridos externamente.
- Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
- Operación: asegurar que el uso del proyecto es el pretendido.
- Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste).
FASES DEL CICLO DE VIDA
- Ciclo Cascada
- Ciclo Prototipo
- Ciclo Espiral
- Ciclo Desarrollo incremental
- Ciclo Evolutivo
- Ciclo Modelo basado en reutilización
ASPECTOS QUE SE DEBEN TENER EN CUENTA PARA LA SELECCIÓN CORRECTA DEL MODELO DE CICLO DE VIDA
- El alcance del ciclo depende de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
- Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
CUÁL ES LA FUNCIONALIDAD DE LA INGENIERÍA DE SOFTWARE Y QUIENES SON LOS QUE SE BENEFICIAN DIRECTAMENTE
La Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas a los problemas de desarrollo de software, es decir, permite elaborar consistentemente productos correctos, utilizables y costo-efectivos.
El proceso de ingeniería de software se define como un conjunto de etapas parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la obtención de un producto de software de calidad.
El proceso de desarrollo de software es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo. Concretamente define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo.
Etapas en el ciclo
Una descripción de etapas con que podemos contar a lo largo del ciclo de vida del software; una vez delimitadas en cierta manera las etapas, habrá que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la elección de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia; el orden de las etapas es un factor importante, por ejemplo tener una etapa de validación al final del proyecto, tal como sugiere el modelo en cascada o lineal, puede implicar serios problemas sobre la gestión de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y cuanto más tarde se haga más costoso resultará, por tanto el hecho de contar con una etapa de validación tardía tiene su riesgo y, por su situación en el ciclo, un posible tiempo de reacción mínimo en caso de tener que retornar a fases previas).
▲ Necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).
Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas.
▲ Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso).
Lo más normal será que no resulte posible obtener una buena especificación del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente.
▲ Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
- Funcional
- Estático
- Dinámico
▲ Diseño
Teniendo claro que debe hacer el sistema, determinaremos como se va hacer. ¿Cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.
▲ Implementación
Se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.
▲ Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, ejemplo rendimiento).
▲ Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).
▲ Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (por ejemplo mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución. Ejemplo: nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto.
La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa solamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).
Fase de definición (¿qué hacer?)
- Estudio de viabilidad.
- Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
- Asegurar que los requisitos son alcanzables.
- Formalizar el acuerdo con los usuarios.
- Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
- Identificar soluciones tecnológicas para cada una de las funciones del sistema.
- Asignar recursos materiales para cada una de las funciones.
- Proponer (identificar y seleccionar) subcontratas.
- Establecer métodos de validación del diseño.
- Ajustar las especificaciones del producto.
Fase de construcción
- Generar el producto o servicio pretendido con el proyecto.
- Integrar los elementos subcontratados o adquiridos externamente.
- Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
- Operación: asegurar que el uso del proyecto es el pretendido.
- Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste).
FASES DEL CICLO DE VIDA
- Ciclo Cascada
- Ciclo Prototipo
- Ciclo Espiral
- Ciclo Desarrollo incremental
- Ciclo Evolutivo
- Ciclo Modelo basado en reutilización
ASPECTOS QUE SE DEBEN TENER EN CUENTA PARA LA SELECCIÓN CORRECTA DEL MODELO DE CICLO DE VIDA
- El alcance del ciclo depende de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
- Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
CUÁL ES LA FUNCIONALIDAD DE LA INGENIERÍA DE SOFTWARE Y QUIENES SON LOS QUE SE BENEFICIAN DIRECTAMENTE
La Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas a los problemas de desarrollo de software, es decir, permite elaborar consistentemente productos correctos, utilizables y costo-efectivos.
El proceso de ingeniería de software se define como un conjunto de etapas parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la obtención de un producto de software de calidad.
El proceso de desarrollo de software es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo. Concretamente define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo.
miércoles, 22 de agosto de 2007
Preguntas Ingeniería Software
Cuándo se habla de proyecto informático, a que se refiere?
Aciones secuenciales que incluyen personas, hardware, software, con el fin de obtener uno o más resultados sobre un sistema de información.
La inquietud que tengo, ¿Cuál es el modelo más usado en el proceso de desarrollo de software: cascada, prototipo, espiral, etc?.
Aciones secuenciales que incluyen personas, hardware, software, con el fin de obtener uno o más resultados sobre un sistema de información.
La inquietud que tengo, ¿Cuál es el modelo más usado en el proceso de desarrollo de software: cascada, prototipo, espiral, etc?.
viernes, 17 de agosto de 2007
Ciclo de Vida - Proyecto
Ciclo de vida
Conjunto de etapas que se han de llevar a cabo para crear, explotar y mantener un Sistema Informático.
OBJETIVOS DE CADA FASE
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Fase de definición (¿qué hacer?)
- Estudio de viabilidad.
- Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
- Asegurar que los requisitos son alcanzables.
- Formalizar el acuerdo con los usuarios.
- Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
- Identificar soluciones tecnológicas para cada una de las funciones del sistema.
- Asignar recursos materiales para cada una de las funciones.
- Proponer (identificar y seleccionar) subcontratas.
- Establecer métodos de validación del diseño.
- Ajustar las especificaciones del producto.
Fase de construcción
- Generar el producto o servicio pretendido con el proyecto.
- Integrar los elementos subcontratados o adquiridos externamente.
- Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
- Operación: asegurar que el uso del proyecto es el pretendido.
- Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste).
Cascada
- Llamado ciclo de vida clásico
- Orientado a fases, línea secuencial
- Cada proceso comienza cuando termina el anterior
- Es el ciclo ideal, es el más fácil de planificar
- Para un proyecto corto, es recomendable usar este ciclo de vida
1. Definición de requerimientos
Estudio detallado de la situación actual del problema a tratar, definición de los requerimientos que debe cumplir el nuevo sistema
2. Análisis y diseño del sistema
Descomposición modular de toda la aplicación, descripción detallada de cada uno de los módulos y sus interrelaciones, todo ello para poder facilitar al máximo la fase de codificación.
3. Implementación (codificación)
Cada módulo como resultado de la fase anterior es traducido a la herramienta o lenguaje apropiado.
4. Integración y pruebas
Verificación del correcto funcionamiento de cada módulo y todo el sistema una vez ha sido integrado, detectar errores en la codificación, definiciones de requerimientos y de diseño.
5. Explotación y mantenimiento
Garantizar el mantenimiento del sistema, corrección de errores detectados en esta fase, adaptación del sistema a nuevos entornos.
Ciclo de vida en espiral
• Es una generalización del ciclo prototipo, no basta con una sola evaluación de un prototipo.
• Sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espiral) las especificaciones del producto se van resolviendo paulatinamente.
• Consta de una serie de ciclos
• Cada uno empieza identificando los objetivos, las alternativas y las restricciones del ciclo
• Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado empezar a plantear el próximo.
• Incorpora el factor “riesgo del proyecto” al modelo de ciclo de vida
• Se produce una cadena continua de productos, los cuales están disponibles para la examinación y evaluación por parte del cliente
• Provee mecanismos para la aseguración de la calidad del software
• La reevaluación después de cada fase permite cambios en las percepciones de los usuarios, avances tecnológicos o perspectivas financieras.
• Se basa en análisis de riesgos
Fases del modelo espiral
• Planteamiento de Objetivos
- Se identifican los objetivos específicos para cada fase del proyecto.
• Identificación y reducción de riesgos
- Los riesgos clave se identifican y analizan, y la información sirve para minimizar los riesgos.
• Desarrollo y Validación
- Se elige un modelo apropiado para la siguiente fase del desarrollo.
• Planeación
- Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.
Modelo incremental
• Es una repetición de varios ciclos de vida en cascada
• Al final de cada ciclo se entrega una versión parcial del software incrementada con cierta funcionalidad nueva respecto a las entregas anteriores
• Los ciclos se repiten hasta obtener un producto completo
• Se suelo aplicar a desarrollos de gran tamaño
• Crear sistema añadiendo componentes funcionales (incrementos)
• En cada paso se actualiza el sistema con nuevas funcionalidades y requisitos
Ciclo de vida evolutivo
- Conseguir obtener todos los requisitos al comienzo del proyecto es prácticamente imposible
- Las necesidades de clientes y usuarios evolucionan durante el desarrollo y surgen nuevos requisitos
- El resultado de la evaluación permite evolucionar hacia la siguiente versión
- El ciclo de vida evolutivo presenta ciclos como requisitos, desarrollo, evaluación.
Prototipos
• Los prototipos se pueden usar como una herramienta para obtener y validar los requisitos de clientes y usuarios en cualquier ciclo de vida
• Se debe evaluar si el esfuerzo de desarrollo del prototipo merece la pena (coste de errores)
• Siempre se debe tener en cuenta que el prototipo no es el producto final, ya que su calidad no suele ser la necesaria
PROYECTO
Un proyecto es un conjunto de actividades interrelacionadas, con un inicio y un fin definido, que utiliza recursos limitados para lograr un objetivo deseado. Los dos elementos básicos que incluye esta definición son: las actividades y los recursos.
- Las actividades son las tareas que deben ejecutarse para llegar en conjunto al objetivo deseado; por ejemplo: recopilar información; realizar diagnósticos; confeccionar un diseño global de un procedimiento, programar, escribir manuales de procedimiento. El aspecto fundamental en todo proyecto es el orden en el cual se realizan las actividades. Y para determinar la secuencia lógica de las actividades se debe establecer el método, el tiempo y el costo de cada operación.
- Los recursos son los elementos utilizados para poder realizar la ejecución de cada una de las tareas; como por ejemplo: hardware, programas de base (sistemas operativos), programas de aplicación, discos de almacenamiento, energía, servicios, inversiones de capital, personal, información, dinero y tiempo.
En cuanto al objetivo del proyecto, este puede ser sencillo y no demandar ni muchas tareas ni demasiados recursos; o por el contrario, puede ser complejo y exigir múltiples actividades y una gran cantidad de recursos para poder alcanzarlo.
Todo proyecto los siguientes criterios:
1. Tener un principio y un fin
2. Tener un calendario definido de ejecución
3. Plantearse de una sola vez
4. Constar de una sucesión de actividades o de fases
5. Agrupar personas en función de las necesidades específicas de cada actividad
6. Contar con los recursos necesarios para desenvolver las actividades
Todos los proyectos que se desarrollan en las organizaciones deben cumplirse en un cierto plazo de tiempo y que además requieren de la concurrencia de otras personas. Y es aquí donde empieza a tener relevancia la figura del administrador, en los proyectos a realizarse en las organizaciones; incluidos los proyectos informáticos.
Los administradores eficaces de proyectos, son los que logran que el trabajo se ejecute a tiempo, dentro del presupuesto, y conforme a las normas de calidad especificadas.
PROYECTO INFORMÁTICO
Un proyecto informático es un sistema de acciones simultáneas y/o secuenciales que incluye personas, equipos de hardware, software y comunicaciones, enfocado en obtener uno o más resultados deseables sobre un sistema de información. Un proyecto informático es un sistema de información que nos ayuda a tomar decisiones en las actividades de construcción de software.
La planificación consiste en diseñar un futuro deseable y seleccionar o crear formas de lograrlo, hasta donde sea posible. Por lo tanto, al planificar se construye la secuencia de tareas con la lógica necesaria, y la asignación de recursos necesarios para alcanzar el objetivo del proyecto en un tiempo óptimo.
La disponibilidad de recursos, hace que la secuencia de tareas pueda variar en el tiempo; dependiendo de los recursos con que se dispongan. Por lo tanto, al momento de planificar, hay que considerar, las tareas y los recursos; con el mismo grado de importancia.
Los objetivos que caracterizan a un proyecto informático:
El inicio de un proyecto informático generalmente está dado en la solicitud de requerimientos de los usuarios, y siendo que los diferentes sistemas de Información abordan los diferentes tipos de problemas organizacionales; podemos clasificar a los Sistemas de Información según sean las aplicaciones que necesite cada usuario en:
- Sistemas de Transacciones,
- Sistemas de Soporte para la toma de decisiones, y
- Sistemas Expertos.
Los recursos más frecuentemente utilizados que caracterizan a un sistema de información, como ser el uso de Hardware, Software y Comunicaciones.
Inicio proyecto informático
Para iniciar un proyecto informático, se debe tener en cuenta las necesidades de mantenimiento, modificación, mejoramiento, reemplazo o capacidad:
- El Mantenimiento del programa: Involucra solucionar fallas menores del sistema, que obligará a la realización de cambios en el programa; como por ejemplo el descuido de no considerar que puedan ocurrir en el sistema, ciertas condiciones extraordinarias. Las fallas también pueden provenir de otros factores, como ser en el caso de que existan cambios en las expectativas de los usuarios.
- La Modificación del programa: Involucra un cambio estructural de una entidad Por ejemplo, un cambio en el número de dígitos del código postal, o en el código de zona telefónica. La diferencia con el Mantenimiento es el grado de importancia.
- El Mejoramiento del sistema: Es el agregado de capacidades que no formaron parte del sistema de información original; por ejemplo cuando en una división se implementó un sistema de inventarios, este sistema no incluía un modulo para calcular la futura demanda de bienes y partes. La inclusión de este sofisticado módulo de cálculo es considerado un mejoramiento del sistema.
- El Reemplazo del sistemaO ocurre cuando los sistemas de información se tornan físicamente, tecnológicamente o competitivamente obsoletos. Como es el caso de la utilización del láser, en el reconocimiento óptico de caracteres para la lectura del código de barras, remplazando a la entrada por teclado.
- La nueva capacidad del sistema: son sistemas de información para los cuales no es necesario el uso de la automatización. Están dados por la capacidad de poder modelizar la aplicabilidad de nuevos sistemas. Un ejemplo de ello, es la aplicación de los sistemas expertos.
Objetivos del proyecto informático
Los objetivos generales de la actividad de la gestión de un proyecto informático son los siguientes:
- Alcanzar unas funcionalidades determinadas que indiquen lo que se ha concretado que se debe realizar.
- Respetar los plazos que se han establecido para conseguir las funcionalidades, los cuales señalan cuándo se ha de terminar el proyecto informático.
- Respetar el presupuesto asignado al proyecto ajustándose a los costes predeterminados.
Etapas de un proyecto informático
Un proyecto informático es una actividad viva en el sentido de que nace, se desarrolla y finalmente termina. El objetivo principal de la gestión de un proyecto informático es, dirigir el desarrollo del mismo para llevarlo a su fin y obtener las funcionalidades deseadas, en los plazos establecidos y con el presupuesto autorizado.
La gestión de un proyecto debe permitirnos saber hacia dónde va (los objetivos),
cómo se va (planificación de recursos y actividades) y también nos debe
informar en todo momento de dónde se encuentra el proyecto (seguimiento).
La gestión de un proyecto informático tiene cuatro grandes etapas:
1. El inicio del proyecto: que establece los requisitos y los objetivos funcionales generales que se deben conseguir y, de hecho, da origen al proyecto y lo hace nacer.
2. La calificación del proyecto: que permite realizar una evaluación global de la carga de trabajo necesario para la realización del proyecto y, teniendo en cuenta los recursos disponibles, ayuda a repartir en el tiempo las diferentes actividades que se han de llevar a cabo. La calificación incluye la estimación del volumen de trabajo que se debe realizar y la planificación en el tiempo de las diferentes actividades.
3. El desarrollo del proyecto o, más exactamente, el seguimiento y control del desarrollo del proyecto, en el cual se reúnen datos de cómo se efectúa el proyecto y se identifican las desviaciones entre la planificación y la realidad (seguimiento) para poder tomar las medidas de corrección necesarias (control).
4. El cierre del proyecto, que indica la finalización definitiva del proyecto y permite efectuar un balance de la realización al mismo tiempo que libera los recursos que se le habían asignado.
Protocolo punto a punto (PPP)
El Protocolo punto a punto (PPP, Point-to-Point Protocol) es un conjunto de protocolos estándar que permiten la interacción de software de acceso remoto de diversos proveedores. Una conexión habilitada para PPP puede conectar con redes remotas a través de cualquier servidor PPP normalizado. PPP también permite que un servidor de acceso remoto reciba llamadas y proporcione acceso de red al software de acceso remoto de otros proveedores que cumpla los estándares de PPP.
Los estándares de PPP también admiten características avanzadas que no están disponibles en estándares más antiguos como SLIP. PPP acepta varios métodos de autenticación, así como compresión y cifrado de datos. En la mayor parte de las implementaciones de PPP, se puede automatizar todo el proceso de inicio de sesión.
PPP también admite múltiples protocolos de LAN. Puede utilizar TCP/IP o IPX como protocolo de red.
El protocolo IPX/SPX no está disponible en las versiones basadas en Itanium de los sistemas operativos Windows.
PPP es la base de los protocolos Protocolo de túnel punto a punto (PPTP) y Protocolo de túnel de capa dos (L2TP), que se utilizan en las conexiones seguras de red privada virtual (VPN).
Conjunto de etapas que se han de llevar a cabo para crear, explotar y mantener un Sistema Informático.
OBJETIVOS DE CADA FASE
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Fase de definición (¿qué hacer?)
- Estudio de viabilidad.
- Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
- Asegurar que los requisitos son alcanzables.
- Formalizar el acuerdo con los usuarios.
- Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
- Identificar soluciones tecnológicas para cada una de las funciones del sistema.
- Asignar recursos materiales para cada una de las funciones.
- Proponer (identificar y seleccionar) subcontratas.
- Establecer métodos de validación del diseño.
- Ajustar las especificaciones del producto.
Fase de construcción
- Generar el producto o servicio pretendido con el proyecto.
- Integrar los elementos subcontratados o adquiridos externamente.
- Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
- Operación: asegurar que el uso del proyecto es el pretendido.
- Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste).
Cascada
- Llamado ciclo de vida clásico
- Orientado a fases, línea secuencial
- Cada proceso comienza cuando termina el anterior
- Es el ciclo ideal, es el más fácil de planificar
- Para un proyecto corto, es recomendable usar este ciclo de vida
1. Definición de requerimientos
Estudio detallado de la situación actual del problema a tratar, definición de los requerimientos que debe cumplir el nuevo sistema
2. Análisis y diseño del sistema
Descomposición modular de toda la aplicación, descripción detallada de cada uno de los módulos y sus interrelaciones, todo ello para poder facilitar al máximo la fase de codificación.
3. Implementación (codificación)
Cada módulo como resultado de la fase anterior es traducido a la herramienta o lenguaje apropiado.
4. Integración y pruebas
Verificación del correcto funcionamiento de cada módulo y todo el sistema una vez ha sido integrado, detectar errores en la codificación, definiciones de requerimientos y de diseño.
5. Explotación y mantenimiento
Garantizar el mantenimiento del sistema, corrección de errores detectados en esta fase, adaptación del sistema a nuevos entornos.
Ciclo de vida en espiral
• Es una generalización del ciclo prototipo, no basta con una sola evaluación de un prototipo.
• Sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espiral) las especificaciones del producto se van resolviendo paulatinamente.
• Consta de una serie de ciclos
• Cada uno empieza identificando los objetivos, las alternativas y las restricciones del ciclo
• Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado empezar a plantear el próximo.
• Incorpora el factor “riesgo del proyecto” al modelo de ciclo de vida
• Se produce una cadena continua de productos, los cuales están disponibles para la examinación y evaluación por parte del cliente
• Provee mecanismos para la aseguración de la calidad del software
• La reevaluación después de cada fase permite cambios en las percepciones de los usuarios, avances tecnológicos o perspectivas financieras.
• Se basa en análisis de riesgos
Fases del modelo espiral
• Planteamiento de Objetivos
- Se identifican los objetivos específicos para cada fase del proyecto.
• Identificación y reducción de riesgos
- Los riesgos clave se identifican y analizan, y la información sirve para minimizar los riesgos.
• Desarrollo y Validación
- Se elige un modelo apropiado para la siguiente fase del desarrollo.
• Planeación
- Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.
Modelo incremental
• Es una repetición de varios ciclos de vida en cascada
• Al final de cada ciclo se entrega una versión parcial del software incrementada con cierta funcionalidad nueva respecto a las entregas anteriores
• Los ciclos se repiten hasta obtener un producto completo
• Se suelo aplicar a desarrollos de gran tamaño
• Crear sistema añadiendo componentes funcionales (incrementos)
• En cada paso se actualiza el sistema con nuevas funcionalidades y requisitos
Ciclo de vida evolutivo
- Conseguir obtener todos los requisitos al comienzo del proyecto es prácticamente imposible
- Las necesidades de clientes y usuarios evolucionan durante el desarrollo y surgen nuevos requisitos
- El resultado de la evaluación permite evolucionar hacia la siguiente versión
- El ciclo de vida evolutivo presenta ciclos como requisitos, desarrollo, evaluación.
Prototipos
• Los prototipos se pueden usar como una herramienta para obtener y validar los requisitos de clientes y usuarios en cualquier ciclo de vida
• Se debe evaluar si el esfuerzo de desarrollo del prototipo merece la pena (coste de errores)
• Siempre se debe tener en cuenta que el prototipo no es el producto final, ya que su calidad no suele ser la necesaria
PROYECTO
Un proyecto es un conjunto de actividades interrelacionadas, con un inicio y un fin definido, que utiliza recursos limitados para lograr un objetivo deseado. Los dos elementos básicos que incluye esta definición son: las actividades y los recursos.
- Las actividades son las tareas que deben ejecutarse para llegar en conjunto al objetivo deseado; por ejemplo: recopilar información; realizar diagnósticos; confeccionar un diseño global de un procedimiento, programar, escribir manuales de procedimiento. El aspecto fundamental en todo proyecto es el orden en el cual se realizan las actividades. Y para determinar la secuencia lógica de las actividades se debe establecer el método, el tiempo y el costo de cada operación.
- Los recursos son los elementos utilizados para poder realizar la ejecución de cada una de las tareas; como por ejemplo: hardware, programas de base (sistemas operativos), programas de aplicación, discos de almacenamiento, energía, servicios, inversiones de capital, personal, información, dinero y tiempo.
En cuanto al objetivo del proyecto, este puede ser sencillo y no demandar ni muchas tareas ni demasiados recursos; o por el contrario, puede ser complejo y exigir múltiples actividades y una gran cantidad de recursos para poder alcanzarlo.
Todo proyecto los siguientes criterios:
1. Tener un principio y un fin
2. Tener un calendario definido de ejecución
3. Plantearse de una sola vez
4. Constar de una sucesión de actividades o de fases
5. Agrupar personas en función de las necesidades específicas de cada actividad
6. Contar con los recursos necesarios para desenvolver las actividades
Todos los proyectos que se desarrollan en las organizaciones deben cumplirse en un cierto plazo de tiempo y que además requieren de la concurrencia de otras personas. Y es aquí donde empieza a tener relevancia la figura del administrador, en los proyectos a realizarse en las organizaciones; incluidos los proyectos informáticos.
Los administradores eficaces de proyectos, son los que logran que el trabajo se ejecute a tiempo, dentro del presupuesto, y conforme a las normas de calidad especificadas.
PROYECTO INFORMÁTICO
Un proyecto informático es un sistema de acciones simultáneas y/o secuenciales que incluye personas, equipos de hardware, software y comunicaciones, enfocado en obtener uno o más resultados deseables sobre un sistema de información. Un proyecto informático es un sistema de información que nos ayuda a tomar decisiones en las actividades de construcción de software.
La planificación consiste en diseñar un futuro deseable y seleccionar o crear formas de lograrlo, hasta donde sea posible. Por lo tanto, al planificar se construye la secuencia de tareas con la lógica necesaria, y la asignación de recursos necesarios para alcanzar el objetivo del proyecto en un tiempo óptimo.
La disponibilidad de recursos, hace que la secuencia de tareas pueda variar en el tiempo; dependiendo de los recursos con que se dispongan. Por lo tanto, al momento de planificar, hay que considerar, las tareas y los recursos; con el mismo grado de importancia.
Los objetivos que caracterizan a un proyecto informático:
El inicio de un proyecto informático generalmente está dado en la solicitud de requerimientos de los usuarios, y siendo que los diferentes sistemas de Información abordan los diferentes tipos de problemas organizacionales; podemos clasificar a los Sistemas de Información según sean las aplicaciones que necesite cada usuario en:
- Sistemas de Transacciones,
- Sistemas de Soporte para la toma de decisiones, y
- Sistemas Expertos.
Los recursos más frecuentemente utilizados que caracterizan a un sistema de información, como ser el uso de Hardware, Software y Comunicaciones.
Inicio proyecto informático
Para iniciar un proyecto informático, se debe tener en cuenta las necesidades de mantenimiento, modificación, mejoramiento, reemplazo o capacidad:
- El Mantenimiento del programa: Involucra solucionar fallas menores del sistema, que obligará a la realización de cambios en el programa; como por ejemplo el descuido de no considerar que puedan ocurrir en el sistema, ciertas condiciones extraordinarias. Las fallas también pueden provenir de otros factores, como ser en el caso de que existan cambios en las expectativas de los usuarios.
- La Modificación del programa: Involucra un cambio estructural de una entidad Por ejemplo, un cambio en el número de dígitos del código postal, o en el código de zona telefónica. La diferencia con el Mantenimiento es el grado de importancia.
- El Mejoramiento del sistema: Es el agregado de capacidades que no formaron parte del sistema de información original; por ejemplo cuando en una división se implementó un sistema de inventarios, este sistema no incluía un modulo para calcular la futura demanda de bienes y partes. La inclusión de este sofisticado módulo de cálculo es considerado un mejoramiento del sistema.
- El Reemplazo del sistemaO ocurre cuando los sistemas de información se tornan físicamente, tecnológicamente o competitivamente obsoletos. Como es el caso de la utilización del láser, en el reconocimiento óptico de caracteres para la lectura del código de barras, remplazando a la entrada por teclado.
- La nueva capacidad del sistema: son sistemas de información para los cuales no es necesario el uso de la automatización. Están dados por la capacidad de poder modelizar la aplicabilidad de nuevos sistemas. Un ejemplo de ello, es la aplicación de los sistemas expertos.
Objetivos del proyecto informático
Los objetivos generales de la actividad de la gestión de un proyecto informático son los siguientes:
- Alcanzar unas funcionalidades determinadas que indiquen lo que se ha concretado que se debe realizar.
- Respetar los plazos que se han establecido para conseguir las funcionalidades, los cuales señalan cuándo se ha de terminar el proyecto informático.
- Respetar el presupuesto asignado al proyecto ajustándose a los costes predeterminados.
Etapas de un proyecto informático
Un proyecto informático es una actividad viva en el sentido de que nace, se desarrolla y finalmente termina. El objetivo principal de la gestión de un proyecto informático es, dirigir el desarrollo del mismo para llevarlo a su fin y obtener las funcionalidades deseadas, en los plazos establecidos y con el presupuesto autorizado.
La gestión de un proyecto debe permitirnos saber hacia dónde va (los objetivos),
cómo se va (planificación de recursos y actividades) y también nos debe
informar en todo momento de dónde se encuentra el proyecto (seguimiento).
La gestión de un proyecto informático tiene cuatro grandes etapas:
1. El inicio del proyecto: que establece los requisitos y los objetivos funcionales generales que se deben conseguir y, de hecho, da origen al proyecto y lo hace nacer.
2. La calificación del proyecto: que permite realizar una evaluación global de la carga de trabajo necesario para la realización del proyecto y, teniendo en cuenta los recursos disponibles, ayuda a repartir en el tiempo las diferentes actividades que se han de llevar a cabo. La calificación incluye la estimación del volumen de trabajo que se debe realizar y la planificación en el tiempo de las diferentes actividades.
3. El desarrollo del proyecto o, más exactamente, el seguimiento y control del desarrollo del proyecto, en el cual se reúnen datos de cómo se efectúa el proyecto y se identifican las desviaciones entre la planificación y la realidad (seguimiento) para poder tomar las medidas de corrección necesarias (control).
4. El cierre del proyecto, que indica la finalización definitiva del proyecto y permite efectuar un balance de la realización al mismo tiempo que libera los recursos que se le habían asignado.
Protocolo punto a punto (PPP)
El Protocolo punto a punto (PPP, Point-to-Point Protocol) es un conjunto de protocolos estándar que permiten la interacción de software de acceso remoto de diversos proveedores. Una conexión habilitada para PPP puede conectar con redes remotas a través de cualquier servidor PPP normalizado. PPP también permite que un servidor de acceso remoto reciba llamadas y proporcione acceso de red al software de acceso remoto de otros proveedores que cumpla los estándares de PPP.
Los estándares de PPP también admiten características avanzadas que no están disponibles en estándares más antiguos como SLIP. PPP acepta varios métodos de autenticación, así como compresión y cifrado de datos. En la mayor parte de las implementaciones de PPP, se puede automatizar todo el proceso de inicio de sesión.
PPP también admite múltiples protocolos de LAN. Puede utilizar TCP/IP o IPX como protocolo de red.
El protocolo IPX/SPX no está disponible en las versiones basadas en Itanium de los sistemas operativos Windows.
PPP es la base de los protocolos Protocolo de túnel punto a punto (PPTP) y Protocolo de túnel de capa dos (L2TP), que se utilizan en las conexiones seguras de red privada virtual (VPN).
viernes, 10 de agosto de 2007
CICLO DE VIDA DE SOFTWARE
CICLO DE VIDA DE SOFTWARE
Un proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles.
La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).
De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor se adapte a nuestros requerimientos.
Elementos del ciclo de vida
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.
A continuación presentamos los distintos elementos que integran un ciclo de vida:
• Fases:
Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).
Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
Otro motivo para descomponer una fase en fases menores (subfases) puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.
Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.
Esquema general de operación de una fase
• Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto.
TIPOS DE MODELO DE CICLO DE VIDA
Las principales diferencias entre distintos modelos de ciclo de vida están en:
- El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
- Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
- La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral.
- Ciclo de vida lineal: Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.
- Ciclo de vida con prototipazo: A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.
Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado. La experiencia del desarrollo del prototipo y su evaluación deben permitir la definición de las especificaciones más completas y seguras para el producto definitivo.
A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definición, diseño y construcción dos veces: para el prototipo y para el producto real.
- Ciclo de vida en espiral: El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.
A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos). En cada vuelta el producto gana en “madurez” (aproximación al final deseado) hasta que en una vuelta la evaluación lo apruebe y el bucle pueda abandonarse.
OBJETIVOS DE CADA FASE
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Fase de definición (¿qué hacer?)
- Estudio de viabilidad.
- Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
- Asegurar que los requisitos son alcanzables.
- Formalizar el acuerdo con los usuarios.
- Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
- Identificar soluciones tecnológicas para cada una de las funciones del sistema.
- Asignar recursos materiales para cada una de las funciones.
- Proponer (identificar y seleccionar) subcontratas.
- Establecer métodos de validación del diseño.
- Ajustar las especificaciones del producto.
Fase de construcción
- Generar el producto o servicio pretendido con el proyecto.
- Integrar los elementos subcontratados o adquiridos externamente.
- Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
- Operación: asegurar que el uso del proyecto es el pretendido.
- Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste).
Etapas en el ciclo
Una descripción de etapas con que podemos contar a lo largo del ciclo de vida del software; una vez delimitadas en cierta manera las etapas, habrá que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la elección de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia; el orden de las etapas es un factor importante, por ejemplo tener una etapa de validación al final del proyecto, tal como sugiere el modelo en cascada o lineal, puede implicar serios problemas sobre la gestión de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y cuanto más tarde se haga más costoso resultará, por tanto el hecho de contar con una etapa de validación tardía tiene su riesgo y, por su situación en el ciclo, un posible tiempo de reacción mínimo en caso de tener que retornar a fases previas).
▲ Necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).
Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas.
▲ Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso).
Lo más normal será que no resulte posible obtener una buena especificación del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente.
▲ Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
- Funcional
- Estático
- Dinámico
▲ Diseño
Teniendo claro que debe hacer el sistema, determinaremos como se va hacer. ¿Cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.
▲ Implementación
Se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.
▲ Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, ejemplo rendimiento).
▲ Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).
▲ Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (por ejemplo mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución. Ejemplo: nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto.
La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa solamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).
Ciclo de vida de las aplicaciones de bases de datos
Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes:
1. Planificación del proyecto.
2. Definición del sistema.
3. Recolección y análisis de los requisitos.
4. Diseño de la base de datos.
5. Selección del SGBD.
6. Diseño de la aplicación.
7. Prototipado.
8. Implementación.
9. Conversión y carga de datos.
10. Prueba.
11. Mantenimiento.
Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias veces, haciendo lo que se conocen como ciclos de realimentación. Por ejemplo, los problemas que se encuentran en la etapa del diseño de la base de datos pueden requerir una recolección de requisitos adicional y su posterior análisis.
A continuación, se muestran las tareas más importantes que se realizan en cada etapa.
1. Planificación del proyecto
Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de la manera más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los recursos para llevarlo a cabo y el dinero para pagar por todo ello. Como apoyo a esta etapa, se necesitará un modelo de datos corporativo en donde se muestren las entidades principales de la empresa y sus relaciones, y en donde se identifiquen las principales áreas funcionales. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relación. En este modelo se tiene que mostrar también qué datos comparten las distintas áreas funcionales de la empresa.
La planificación de la base de datos también incluye el desarrollo de estándares que especifiquen cómo realizar la recolección de datos, cómo especificar su formato, qué documentación será necesaria y cómo se va a llevar a cabo el diseño y la implementación. El desarrollo y el mantenimiento de los estándares puede llevar bastante tiempo, pero si están bien diseñados, son una base para el personal informático en formación y para medir la calidad, además, garantizan que el trabajo se ajusta a unos patrones, independientemente de las habilidades y la experiencia del diseñador. Por ejemplo, se pueden establecer reglas sobre cómo dar nombres a los datos, lo que evitará redundancias e inconsistencias. Se deben documentar todos los aspectos legales sobre los datos y los establecidos por la empresa como, por ejemplo, qué datos deben tratarse de modo confidencial.
2. Definición del sistema
En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como con qué otros sistemas interactúa. También hay que determinar quienes son los usuarios y las áreas de aplicación.
3. Recolección y análisis de los requisitos
En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta información se puede recoger de varias formas:
• Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés.
• Observando el funcionamiento de la empresa.
• Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información.
• Utilizando cuestionarios para recoger información de grandes grupos de usuarios.
• Utilizando la experiencia adquirida en el diseño de sistemas similares.
La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios, la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de los requerimientos de cada área de aplicación o grupo de usuarios.
Esta etapa tiene como resultado un conjunto de documentos con las especificaciones de requisitos de los usuarios, en donde se describen las operaciones que se realizan en la empresa desde distintos puntos de vista.
La información recogida se debe estructurar utilizando técnicas de especificación de requisitos, como por ejemplo técnicas de análisis y diseño estructurado y diagramas de flujo de datos. También las herramientas CASE pueden proporcionar una asistencia automatizada que garantice que los requisitos son completos y consistentes.
4. Diseño de la base de datos
Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de datos. La primera fase consiste en la producción de un esquema conceptual, que es independiente de todas las consideraciones físicas. Este modelo se refina después en un esquema lógico eliminando las construcciones que no se pueden representar en el modelo de base de datos escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema lógico se traduce en un esquema físico para el SGBD escogido. La fase de diseño físico considera las estructuras de almacenamiento y los métodos de acceso necesarios para proporcionar un acceso eficiente a la base de datos en memoria secundaria.
Los objetivos del diseño de la base de datos son:
• Representar los datos que requieren las principales áreas de aplicación y los grupos de usuarios, y representar las relaciones entre dichos datos.
• Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar sobre los datos.
• Especificar un esquema que alcance las prestaciones requeridas para el sistema.
Hay varias estrategias a seguir para realizar el diseño: de abajo a arriba, de arriba a abajo, de dentro a fuera y la estrategia mixta. La estrategia de abajo a arriba parte de todos los atributos y los va agrupando en entidades y relaciones. Es apropiada cuando la base de datos es simple, con pocos atributos. La estrategia de arriba a abajo es más apropiada cuando se trata de bases de datos complejas. Se comienza con un esquema con entidades de alto nivel, que se van refinando para obtener entidades de bajo nivel, atributos y relaciones. La estrategia de dentro a fuera es similar a la estrategia de abajo a arriba, pero difiere en que se parte de los conceptos principales y se va extendiendo el esquema para considerar también otros conceptos, asociados con los que se han identificado en primer lugar. La estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a abajo, con un esquema de divide y vencerás. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada parte se obtiene un subesquema. Estos subesquemas se integran después para obtener el modelo final.
5. Selección del SGBD
Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que sea adecuado para el sistema de información. Esta elección se debe hacer en cualquier momento antes del diseño lógico.
6. Diseño de la aplicación
En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos. Esta etapa y el diseño de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar el diseño de las aplicaciones hasta que se ha terminado con el diseño de la base de datos. Por otro lado, la base de datos existe para dar soporte a las aplicaciones, por lo que habrá una realimentación desde el diseño de las aplicaciones al diseño de la base de datos.
En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de usuario se encuentra en el diseño de la aplicación. Habrá algunos programas que utilicen y procesen los datos de la base de datos.
Además, habrá que diseñar las interfaces de usuario, aspecto muy importante que se suele ignorar. El sistema debe ser fácil de aprender, fácil de usar, ser directo y estar ``dispuesto a perdonar''. Si la interface no tiene estas características, el sistema dará problemas, sin lugar a dudas.
7. Prototipado
Esta etapa, que es opcional, es para construir prototipos de la aplicación que permitan a los diseñadores y a los usuarios probar el sistema. Un prototipo es un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene toda la funcionalidad del sistema final, pero es suficiente para que los usuarios puedan utilizar el sistema e identificar qué aspectos están bien y cuáles no son adecuados, además de poder sugerir mejoras o la inclusión de nuevos elementos. Este proceso permite que quienes diseñan e implementan el sistema sepan si han interpretado correctamente los requisitos de los usuarios. Otra ventaja de los prototipos es que se construyen rápidamente.
Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo o utiliza nuevas tecnologías.
8. Implementación
En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, así como los programas de aplicación. La implementación de la base de datos se realiza mediante las sentencias del lenguaje de definición de datos (LDD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la base de datos, los ficheros en donde se almacenarán los datos y las vistas de los usuarios.
Los programas de aplicación se implementan utilizando lenguajes de tercera o cuarta generación. Partes de estas aplicaciones son transacciones sobre la base de datos, que se implementan mediante el lenguaje de manejo de datos (LMD) del SGBD. Las sentencias de este lenguaje se pueden embeber en un lenguaje de programación anfitrión como Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada o Pascal. En esta etapa, también se implementan los menús, los formularios para la introducción de datos y los informes de visualización de datos. Para ello, el SGBD puede disponer de lenguajes de cuarta generación que permiten el desarrollo rápido de aplicaciones mediante lenguajes de consultas no procedurales, generadores de informes, generadores de formularios, generadores de gráficos y generadores de aplicaciones.
También se implementan en esta etapa todos los controles de seguridad e integridad. Algunos de estos controles se pueden implementar mediante el LDD y otros puede que haya que implementarlos mediante utilidades del SGBD o mediante programas de aplicación.
9. Conversión y carga de datos
Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicación del sistema antiguo también se convierten para que se puedan utilizar en el sistema nuevo.
10. Prueba
En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe diseñar una batería de tests con datos reales, que se deben llevar a cabo de manera metódica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrirá los errores en los programas de aplicación y en la estructura de la base de datos. Además, demostrará que los programas ``parecen'' trabajar tal y como se especificaba en los requisitos y que las prestaciones deseadas ``parecen'' obtenerse. Por último, en las pruebas se podrá hacer una medida de la fiabilidad y la calidad del software desarrollado.
11. Mantenimiento
Una vez que el sistema está completamente implementado y probado, se pone en marcha. El sistema está ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas:
• Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un determinado nivel, puede ser necesario reorganizar la base de datos.
• Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar.
Herramientas Case
La ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas. Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software (Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.).
CASE es también definido como el conjunto de métodos, utilidades y técnicas que facilitan el mejoramiento del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
Existe también el CASE integrado que fue comenzando a tener un impacto muy significativo en los negocios y sistemas de información de las organizaciones, además con este CASE integrado las compañías pueden desarrollar rápidamente sistemas de mejor calidad para soportar procesos críticos del negocio y asistir en el desarrollo y promoción intensiva de la información de productos y servicios.
Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir:
• Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos.
• Herramientas de diseño para dar apoyo al análisis de datos.
• Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico.
• Herramientas para desarrollar los prototipos de las aplicaciones.
El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos.
La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información y se plantean los siguientes objetivos:
• Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo.
• Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
• Simplificar el mantenimiento de los programas.
• Mejorar y estandarizar la documentación.
• Aumentar la portabilidad de las aplicaciones.
• Facilitar la reutilización de componentes software.
• Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.
Componentes de una herramienta case
Una herramienta CASE se compone de los siguientes elementos:
• Diccionario donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.
• Meta modelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta.
• Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas.
• Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.
• Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.
La estructura CASE se basa en la siguiente terminología:
- CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas.
- CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas.
- CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación.
Clasificación de las herramientas case
Podrían clasificarse atendiendo a:
- 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.
CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo.
Las herramientas CASE, en función de las fases del ciclo de vida que cubre, se pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior), orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior), dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
Ejemplos de herramientas Case más utilizadas: ERwin, EasyCASE, Oracle Designer, System Architect.
Arquitectura Distribuida
Surge con los nuevos modelos organizativos, en los que la empresa se divide en unidades más o menos autónomas que establecen relaciones más definidas y directas entre sí. Aparecen entonces entornos informáticos departamentales adecuados a las necesidades de cada departamento en concreto.
- Características funcionales
• Cada usuario trabaja con su terminal local inteligente, con lo que obtiene mejores tiempo de respuesta.
• Los recursos necesarios que no estén disponibles sobre el terminal local (ordenador personal o estación de trabajo) pueden tomarse del ordenador central a través de la red de telecomunicaciones.
- Características físicas
• Sistemas informáticos distribuidos en los que los ordenadores a través de la organización están conectados por medio de una red de telecomunicaciones.
• Cada ordenador sobre la red tiene capacidad de tratamiento autónomo que permite servir a las necesidades de los usuarios locales.
• También proporciona acceso a otros elementos de la red o a servidores centrales.
• Toma importancia la red de comunicación de datos.
- Características lógicas
• Cada tarea individual puede ser analizada para determinar si puede distribuirse o no. En general, las tareas más complejas o de carácter estratégico para la organización se mantienen en el ordenador central. Las tareas de complejidad media o específicas para un determinado grupo de usuarios se distribuyen entre las máquinas locales de ese grupo.
• La plataforma física seleccionada puede ajustarse a las necesidades del grupo de usuarios, con lo que surgen los ordenadores especializados para determinados tipos de tareas.
Ventajas e Inconvenientes
• Ventajas
• Funcionamiento autónomo de los sistemas locales, lo que origina un buen tiempo de respuesta.
• Los sistemas de información llegan a todos los departamentos de la empresa.
• Abre posibilidades de trabajo mucho más flexibles y potentes.
• Inconvenientes
• Requiere un intenso flujo de informaciónes (muchas veces no útiles, como pantallas y datos incorrectos) dentro de la red, lo que puede elevar los costes de comunicaciones.
• Supone una mayor complejidad.
• Si los sistemas no están integrados, pueden producirse problemas de inconsistencia de datos.
Un proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles.
La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).
De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor se adapte a nuestros requerimientos.
Elementos del ciclo de vida
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.
A continuación presentamos los distintos elementos que integran un ciclo de vida:
• Fases:
Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).
Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
Otro motivo para descomponer una fase en fases menores (subfases) puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.
Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.
Esquema general de operación de una fase
• Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto.
TIPOS DE MODELO DE CICLO DE VIDA
Las principales diferencias entre distintos modelos de ciclo de vida están en:
- El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.
- Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).
- La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral.
- Ciclo de vida lineal: Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.
- Ciclo de vida con prototipazo: A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.
Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado. La experiencia del desarrollo del prototipo y su evaluación deben permitir la definición de las especificaciones más completas y seguras para el producto definitivo.
A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definición, diseño y construcción dos veces: para el prototipo y para el producto real.
- Ciclo de vida en espiral: El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.
A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos). En cada vuelta el producto gana en “madurez” (aproximación al final deseado) hasta que en una vuelta la evaluación lo apruebe y el bucle pueda abandonarse.
OBJETIVOS DE CADA FASE
Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan.
Fase de definición (¿qué hacer?)
- Estudio de viabilidad.
- Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto).
- Asegurar que los requisitos son alcanzables.
- Formalizar el acuerdo con los usuarios.
- Realizar una planificación detallada.
Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
- Identificar soluciones tecnológicas para cada una de las funciones del sistema.
- Asignar recursos materiales para cada una de las funciones.
- Proponer (identificar y seleccionar) subcontratas.
- Establecer métodos de validación del diseño.
- Ajustar las especificaciones del producto.
Fase de construcción
- Generar el producto o servicio pretendido con el proyecto.
- Integrar los elementos subcontratados o adquiridos externamente.
- Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
- Operación: asegurar que el uso del proyecto es el pretendido.
- Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o de desgaste).
Etapas en el ciclo
Una descripción de etapas con que podemos contar a lo largo del ciclo de vida del software; una vez delimitadas en cierta manera las etapas, habrá que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la elección de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia; el orden de las etapas es un factor importante, por ejemplo tener una etapa de validación al final del proyecto, tal como sugiere el modelo en cascada o lineal, puede implicar serios problemas sobre la gestión de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y cuanto más tarde se haga más costoso resultará, por tanto el hecho de contar con una etapa de validación tardía tiene su riesgo y, por su situación en el ciclo, un posible tiempo de reacción mínimo en caso de tener que retornar a fases previas).
▲ Necesidades
Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).
Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas.
▲ Especificaciones
Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso).
Lo más normal será que no resulte posible obtener una buena especificación del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente.
▲ Análisis
Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:
- Funcional
- Estático
- Dinámico
▲ Diseño
Teniendo claro que debe hacer el sistema, determinaremos como se va hacer. ¿Cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.
▲ Implementación
Se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.
▲ Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, ejemplo rendimiento).
▲ Validación
Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).
▲ Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (por ejemplo mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución. Ejemplo: nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto.
La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa solamente en un ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los casos).
Ciclo de vida de las aplicaciones de bases de datos
Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes:
1. Planificación del proyecto.
2. Definición del sistema.
3. Recolección y análisis de los requisitos.
4. Diseño de la base de datos.
5. Selección del SGBD.
6. Diseño de la aplicación.
7. Prototipado.
8. Implementación.
9. Conversión y carga de datos.
10. Prueba.
11. Mantenimiento.
Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias veces, haciendo lo que se conocen como ciclos de realimentación. Por ejemplo, los problemas que se encuentran en la etapa del diseño de la base de datos pueden requerir una recolección de requisitos adicional y su posterior análisis.
A continuación, se muestran las tareas más importantes que se realizan en cada etapa.
1. Planificación del proyecto
Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de la manera más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los recursos para llevarlo a cabo y el dinero para pagar por todo ello. Como apoyo a esta etapa, se necesitará un modelo de datos corporativo en donde se muestren las entidades principales de la empresa y sus relaciones, y en donde se identifiquen las principales áreas funcionales. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relación. En este modelo se tiene que mostrar también qué datos comparten las distintas áreas funcionales de la empresa.
La planificación de la base de datos también incluye el desarrollo de estándares que especifiquen cómo realizar la recolección de datos, cómo especificar su formato, qué documentación será necesaria y cómo se va a llevar a cabo el diseño y la implementación. El desarrollo y el mantenimiento de los estándares puede llevar bastante tiempo, pero si están bien diseñados, son una base para el personal informático en formación y para medir la calidad, además, garantizan que el trabajo se ajusta a unos patrones, independientemente de las habilidades y la experiencia del diseñador. Por ejemplo, se pueden establecer reglas sobre cómo dar nombres a los datos, lo que evitará redundancias e inconsistencias. Se deben documentar todos los aspectos legales sobre los datos y los establecidos por la empresa como, por ejemplo, qué datos deben tratarse de modo confidencial.
2. Definición del sistema
En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como con qué otros sistemas interactúa. También hay que determinar quienes son los usuarios y las áreas de aplicación.
3. Recolección y análisis de los requisitos
En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta información se puede recoger de varias formas:
• Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés.
• Observando el funcionamiento de la empresa.
• Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información.
• Utilizando cuestionarios para recoger información de grandes grupos de usuarios.
• Utilizando la experiencia adquirida en el diseño de sistemas similares.
La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios, la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de los requerimientos de cada área de aplicación o grupo de usuarios.
Esta etapa tiene como resultado un conjunto de documentos con las especificaciones de requisitos de los usuarios, en donde se describen las operaciones que se realizan en la empresa desde distintos puntos de vista.
La información recogida se debe estructurar utilizando técnicas de especificación de requisitos, como por ejemplo técnicas de análisis y diseño estructurado y diagramas de flujo de datos. También las herramientas CASE pueden proporcionar una asistencia automatizada que garantice que los requisitos son completos y consistentes.
4. Diseño de la base de datos
Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de datos. La primera fase consiste en la producción de un esquema conceptual, que es independiente de todas las consideraciones físicas. Este modelo se refina después en un esquema lógico eliminando las construcciones que no se pueden representar en el modelo de base de datos escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema lógico se traduce en un esquema físico para el SGBD escogido. La fase de diseño físico considera las estructuras de almacenamiento y los métodos de acceso necesarios para proporcionar un acceso eficiente a la base de datos en memoria secundaria.
Los objetivos del diseño de la base de datos son:
• Representar los datos que requieren las principales áreas de aplicación y los grupos de usuarios, y representar las relaciones entre dichos datos.
• Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar sobre los datos.
• Especificar un esquema que alcance las prestaciones requeridas para el sistema.
Hay varias estrategias a seguir para realizar el diseño: de abajo a arriba, de arriba a abajo, de dentro a fuera y la estrategia mixta. La estrategia de abajo a arriba parte de todos los atributos y los va agrupando en entidades y relaciones. Es apropiada cuando la base de datos es simple, con pocos atributos. La estrategia de arriba a abajo es más apropiada cuando se trata de bases de datos complejas. Se comienza con un esquema con entidades de alto nivel, que se van refinando para obtener entidades de bajo nivel, atributos y relaciones. La estrategia de dentro a fuera es similar a la estrategia de abajo a arriba, pero difiere en que se parte de los conceptos principales y se va extendiendo el esquema para considerar también otros conceptos, asociados con los que se han identificado en primer lugar. La estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a abajo, con un esquema de divide y vencerás. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada parte se obtiene un subesquema. Estos subesquemas se integran después para obtener el modelo final.
5. Selección del SGBD
Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que sea adecuado para el sistema de información. Esta elección se debe hacer en cualquier momento antes del diseño lógico.
6. Diseño de la aplicación
En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos. Esta etapa y el diseño de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar el diseño de las aplicaciones hasta que se ha terminado con el diseño de la base de datos. Por otro lado, la base de datos existe para dar soporte a las aplicaciones, por lo que habrá una realimentación desde el diseño de las aplicaciones al diseño de la base de datos.
En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de usuario se encuentra en el diseño de la aplicación. Habrá algunos programas que utilicen y procesen los datos de la base de datos.
Además, habrá que diseñar las interfaces de usuario, aspecto muy importante que se suele ignorar. El sistema debe ser fácil de aprender, fácil de usar, ser directo y estar ``dispuesto a perdonar''. Si la interface no tiene estas características, el sistema dará problemas, sin lugar a dudas.
7. Prototipado
Esta etapa, que es opcional, es para construir prototipos de la aplicación que permitan a los diseñadores y a los usuarios probar el sistema. Un prototipo es un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene toda la funcionalidad del sistema final, pero es suficiente para que los usuarios puedan utilizar el sistema e identificar qué aspectos están bien y cuáles no son adecuados, además de poder sugerir mejoras o la inclusión de nuevos elementos. Este proceso permite que quienes diseñan e implementan el sistema sepan si han interpretado correctamente los requisitos de los usuarios. Otra ventaja de los prototipos es que se construyen rápidamente.
Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo o utiliza nuevas tecnologías.
8. Implementación
En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, así como los programas de aplicación. La implementación de la base de datos se realiza mediante las sentencias del lenguaje de definición de datos (LDD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la base de datos, los ficheros en donde se almacenarán los datos y las vistas de los usuarios.
Los programas de aplicación se implementan utilizando lenguajes de tercera o cuarta generación. Partes de estas aplicaciones son transacciones sobre la base de datos, que se implementan mediante el lenguaje de manejo de datos (LMD) del SGBD. Las sentencias de este lenguaje se pueden embeber en un lenguaje de programación anfitrión como Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada o Pascal. En esta etapa, también se implementan los menús, los formularios para la introducción de datos y los informes de visualización de datos. Para ello, el SGBD puede disponer de lenguajes de cuarta generación que permiten el desarrollo rápido de aplicaciones mediante lenguajes de consultas no procedurales, generadores de informes, generadores de formularios, generadores de gráficos y generadores de aplicaciones.
También se implementan en esta etapa todos los controles de seguridad e integridad. Algunos de estos controles se pueden implementar mediante el LDD y otros puede que haya que implementarlos mediante utilidades del SGBD o mediante programas de aplicación.
9. Conversión y carga de datos
Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicación del sistema antiguo también se convierten para que se puedan utilizar en el sistema nuevo.
10. Prueba
En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe diseñar una batería de tests con datos reales, que se deben llevar a cabo de manera metódica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrirá los errores en los programas de aplicación y en la estructura de la base de datos. Además, demostrará que los programas ``parecen'' trabajar tal y como se especificaba en los requisitos y que las prestaciones deseadas ``parecen'' obtenerse. Por último, en las pruebas se podrá hacer una medida de la fiabilidad y la calidad del software desarrollado.
11. Mantenimiento
Una vez que el sistema está completamente implementado y probado, se pone en marcha. El sistema está ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas:
• Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un determinado nivel, puede ser necesario reorganizar la base de datos.
• Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar.
Herramientas Case
La ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas. Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software (Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.).
CASE es también definido como el conjunto de métodos, utilidades y técnicas que facilitan el mejoramiento del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
Existe también el CASE integrado que fue comenzando a tener un impacto muy significativo en los negocios y sistemas de información de las organizaciones, además con este CASE integrado las compañías pueden desarrollar rápidamente sistemas de mejor calidad para soportar procesos críticos del negocio y asistir en el desarrollo y promoción intensiva de la información de productos y servicios.
Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir:
• Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos.
• Herramientas de diseño para dar apoyo al análisis de datos.
• Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico.
• Herramientas para desarrollar los prototipos de las aplicaciones.
El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos.
La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información y se plantean los siguientes objetivos:
• Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo.
• Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
• Simplificar el mantenimiento de los programas.
• Mejorar y estandarizar la documentación.
• Aumentar la portabilidad de las aplicaciones.
• Facilitar la reutilización de componentes software.
• Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.
Componentes de una herramienta case
Una herramienta CASE se compone de los siguientes elementos:
• Diccionario donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.
• Meta modelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta.
• Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas.
• Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.
• Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.
La estructura CASE se basa en la siguiente terminología:
- CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas.
- CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas.
- CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación.
Clasificación de las herramientas case
Podrían clasificarse atendiendo a:
- 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.
CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo.
Las herramientas CASE, en función de las fases del ciclo de vida que cubre, se pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior), orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior), dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
Ejemplos de herramientas Case más utilizadas: ERwin, EasyCASE, Oracle Designer, System Architect.
Arquitectura Distribuida
Surge con los nuevos modelos organizativos, en los que la empresa se divide en unidades más o menos autónomas que establecen relaciones más definidas y directas entre sí. Aparecen entonces entornos informáticos departamentales adecuados a las necesidades de cada departamento en concreto.
- Características funcionales
• Cada usuario trabaja con su terminal local inteligente, con lo que obtiene mejores tiempo de respuesta.
• Los recursos necesarios que no estén disponibles sobre el terminal local (ordenador personal o estación de trabajo) pueden tomarse del ordenador central a través de la red de telecomunicaciones.
- Características físicas
• Sistemas informáticos distribuidos en los que los ordenadores a través de la organización están conectados por medio de una red de telecomunicaciones.
• Cada ordenador sobre la red tiene capacidad de tratamiento autónomo que permite servir a las necesidades de los usuarios locales.
• También proporciona acceso a otros elementos de la red o a servidores centrales.
• Toma importancia la red de comunicación de datos.
- Características lógicas
• Cada tarea individual puede ser analizada para determinar si puede distribuirse o no. En general, las tareas más complejas o de carácter estratégico para la organización se mantienen en el ordenador central. Las tareas de complejidad media o específicas para un determinado grupo de usuarios se distribuyen entre las máquinas locales de ese grupo.
• La plataforma física seleccionada puede ajustarse a las necesidades del grupo de usuarios, con lo que surgen los ordenadores especializados para determinados tipos de tareas.
Ventajas e Inconvenientes
• Ventajas
• Funcionamiento autónomo de los sistemas locales, lo que origina un buen tiempo de respuesta.
• Los sistemas de información llegan a todos los departamentos de la empresa.
• Abre posibilidades de trabajo mucho más flexibles y potentes.
• Inconvenientes
• Requiere un intenso flujo de informaciónes (muchas veces no útiles, como pantallas y datos incorrectos) dentro de la red, lo que puede elevar los costes de comunicaciones.
• Supone una mayor complejidad.
• Si los sistemas no están integrados, pueden producirse problemas de inconsistencia de datos.
Suscribirse a:
Entradas (Atom)
