El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el último de sus usuarios.
Etapas en el ciclo.
Veamos, a grandes rasgos, una pequeña 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, p.ej. 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):
Expresión de 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 partes (puede incluso tomarse como base para el propio acuerdo comercial).
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, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).
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 (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).
Análisis
Es necesario determinar qué 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
Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar cómo va a hacerlo (¿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.).
Observación:
Aunque todo debe ser tratado a su tiempo, y sería muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se dirán justificadas en simple política de empresa y por mantener “compatibilidad” en lo que respecta a los demás proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o cual herramienta mejoraría la velocidad de desarrollo u otro aspecto de interés (en parte de los casos no serán rumores con fundamento o estudios previos realizados al efecto, sino más bien debidos a la propia publicidad como consejera).
Implementación
Llegado este punto 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.
Observación:
Lamentablemente en la actualidad, año 2.000, quedan bastantes empresas en las que, tras una reunión comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de implementación; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto.
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, p.ej. de 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 ya 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 (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. 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).
5.6.1.2. ¿Con cuánta frecuencia se necesita llevarse a cabo la actualización del software principal?
Las Actualizaciones del sistema se darán cuando exista la necesidad de hacer algún cambio o corrección de estos siempre y cuando estos Sistemas son creados para una determina operación, en cambio sistemas creados para operaciones estándar con los sistemas operativos de los servidores de archivos y de las maquinas que acceden a esa información, antivirus, etc. deben de ser actualizados cada vez que la empresa responsable de estos sistemas y/o programas lancen nuevas actualizaciones.
5.6.1.3. ¿Con cuánta frecuencia se debe de dar mantenimiento?
El proceso de mejora y optimización del software debe ser de constante revisión como también corrección de los defectos.
El mantenimiento del software involucra varias técnicas específicas. Una técnica es el rebanamiento estático, la cual es usada para identificar todo el código de programa que puede modificar alguna variable. Es generalmente útil en la re fabricación del código del.
La fase de mantenimiento de software es una parte explícita del modelo en cascada del proceso de desarrollo de software el cual fue desarrollado durante el movimiento de programación estructurada en computadores. El otro gran modelo, el Desarrollo en espiral desarrollado durante el movimiento de ingeniería de software orientada a objeto no hace una mención explícita de la fase de mantenimiento. Sin embargo, esta actividad es notable, considerando el hecho de que dos tercios del costo del tiempo de vida de un sistema de software involucran mantenimiento.
En un ambiente formal de desarrollo de software, la organización o equipo de desarrollo tendrán algún mecanismo para documentar y rastrear defectos y deficiencias. El Software tan igual como la mayoría de otros productos, es típicamente lanzado con un conjunto conocido de defectos y deficiencias. El software es lanzado con esos defectos conocidos porque la organización de desarrollo en las utilidades y el valor del software en un determinado nivel de calidad compensan el impacto de los defectos y deficiencias conocidas.
Las deficiencias conocidas son normalmente documentadas en una carta de consideraciones operacionales o notas de lanzamiento (release notes) es así que los usuarios del software serán capaces de trabajar evitando las deficiencias conocidas y conocerán cuando el uso del software sería inadecuado para tareas específicas.
Con el lanzamiento del software (software release), otros, defectos y deficiencias no documentados serán descubiertas por los usuarios del software. Tan pronto como estos defectos sean reportados a la organización de desarrollo, serán ingresados en el sistema de rastreo de defectos.
Las personas involucradas en la fase de mantenimiento de software esperan trabajar en estos defectos conocidos, ubicarlos y preparar un nuevo lanzamiento del software, conocido como una lanzamiento de mantenimiento, el cual resolverá los temas pendientes.
Tipos de mantenimiento.
A continuación se señalan los tipos de mantenimientos existentes, definidos tal y como se especifican para la metodología de MÉTRICA:
Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia.
Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario.
Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc.
Correctivo: son aquellos cambios precisos para corregir errores del producto software.
Cabe señalar que, de estos 4 tipos de mantenimiento, solamente el correctivo y el evolutivo entran dentro del ámbito de MÉTRICA versión 3, ya que los otros dos requieres actividades y perfiles distintos a los del proceso de desarrollo.
5.6.1.4. ¿Cómo afecta a otros departamentos dentro de la organización las actualizaciones o mantenimiento?
Las actualizaciones y mantenimiento de los sistemas deben de llevarse a cabo primero en un ambiente de pruebas adonde se tienen que hacer todas las pruebas a la actualización de tal forma de garantizar que la actualización no afectará los procesos que realizan o se llevan a cabo dentro de cada departamento de la organización.
Luego de realizar las respectivas pruebas estas actualizaciones se llevan a cabo en un momento que no afecten las operaciones diarias de los usuarios de la organización.
5.6.1.5. ¿Cómo se pueden minimizar estos efectos?
Teniendo la mayor compatibilidad del sistema se pueden minimizar tanto los tiempos de pruebas, como también minimizar el hecho de que existan demasiados errores por corregir debido a las nuevas actualizaciones. Como también tener una calendarización para llevar a cabo los respectivos mantenimientos y actualización del software.
5.6.1.6. ¿Qué puesto o persona será el responsable de ejecutar y monitorear las actualizaciones y mantenimientos?
El soporte técnico.
5.6.1.7. ¿Qué penalidades deben de ser impuestas si las actualizaciones o reparaciones no son ejecutadas en el horario previsto?
Dependiendo del nivel de importancia y consecuencia de no realizar la actualización, parche del sistema así será la penalidad impuesta al encargado de realizar la actividad programa. Por ej.
Sanciones
Consecuencias de los errores
Amonestación escrita AE
Atrasos A
Amonestación verbal AV
Pérdida física PF
Despido D
Pérdida humana PH
Llamada de atención LA
Pérdida monetaria PM
Ninguna N
5.6.1.8. ¿Se tiene un sistema de prevención para asegurarse que estas actividades sean completadas de manera efectiva?
Se debe de llevar una bitácora de las actividades realizadas, adonde se plasme el estatus actual de la actividad como también la finalización exitosa de dicha actividad.
5.6.1.9. ¿Quién es el responsable de comunicar y entrenar a los usuarios acerca de las actualizaciones y mantenimiento que los afectan?
Cuando las actualizaciones no son criticas y las pueden llevar a cabo los usuarios, estos serán notificados de que existen actualizaciones disponibles para sus sistemas, previo entrenamiento o capacitación por parte del departamento de soporte informático.
5.6.1.10. Desarrolle un horario para actualización y mantenimiento de equipo y software o sistemas de información (Entrada: Actualización y Mejora de Datos)
Día y hora para realizar Actualización Sistema Operativo Programa a Actualizar Descargas Hora de realización Realizado por:
No hay comentarios:
Publicar un comentario