DESARROLLO DE SISTEMAS
Etapas del proceso de desarrollo de software: cualquier sistema de información va pasando por una serie de fases a lo largo de su vida, su ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes:
PLANIFICACIÓN
Esta fase se emplea para determinar y evaluar los objetivos generales y lo que se espera del nuevo sistema. El primer paso es identificar un proyecto que aporte valor al negocio y crear un system request, que es el documento donde se describen las razones para construir o implantar el sistema y los beneficios que se van a derivar de su operación. Este documento también se denomina project charter o business case. Un segundo componente de la fase es el análisis de la viabilidad técnica, económica y organizativa. Realizado éste, se produce la aprobación o rechazo del proyecto. Elegido el proyecto, el responsable estima su tamaño, define el plan de trabajo y forma el equipo de desarrollo. Además determinará las herramientas de desarrollo, los estándares, la documentación y los procedimientos de change control y de gestión de riesgos. En la implantación de un SE hay que definir una estrategia (top-down botton-up y big-bang vs. phased vs.) y decantarse por una metodología de implantación, que puede ser la del implementation partner (p. ej. Accenture, DMR Consulting…) o la del suministrador del SE (v.g. SAP). En este caso también hay que elegir las plataformas y los vendedores.
CARACTERÍSTICAS
Se caracteriza por una fuerte intervención de la alta dirección y de las direcciones funcionales de la empresa en: 1) los análisis previos de la situación actual, problemas, oportunidades y riesgos de la empresa; 2) las primeras acciones de formación/sensibilización en la aplicación de una solución basada en TI ( first-cut education ); 3) la revisión de los análisis coste-beneficio; 4) la decisión de aprobar el proyecto; 5) el desarrollo por escrito de una visión de la transformación de la empresa, de lo que parecerá y de sus nuevas capacidades; y 6) la creación de nuevos grupos de trabajo y puestos de responsabilidad transitorios.
El project leader o project manager es responsable del desarrollo del sistema o de la implantación del SE. Tiene dedicación total al proyecto, pertenece a la organización, tiene experiencia en áreas clave de la empresa, es veterano y el mejor de los disponibles, tiene un buen historial, conoce a los empleados, goza del respeto y confianza de sus colegas y sabe comunicar bien. El champion o torchbearer es responsable de la implantación al más alto nivel, preside el comité de seguimiento y recibe informes del project leader. El Comité de Seguimiento está formado por el champion y otros directivos.
TIPOLOGÍAS / CLASIFICACIÓN
Un buen número de empresas comienzan nuevos proyectos de implantación de TI con grandes ideas que parecen a primera vista eficaces y altamente resolutorias, para luego acabar en errores clásicos de planificación que conducen a retrasos, desviaciones sobre el presupuesto o ambas consecuencias. Algunos de estos errores son:
— Planificación demasiado optimista, que conlleva un análisis y diseño superficiales y ejerce una excesiva presión en el equipo de trabajo. Remedio: prever márgenes de tiempo en cada tarea.
— Fallos en el seguimiento de la planificación, debido a que el equipo de trabajo no informa regularmente del progreso, por lo que nadie sabe si el proyecto está en fecha. Remedio: lograr que el equipo informe honestamente del progreso todas las semanas.
— Fallos en la actualización de la planificación: cuando una parte pequeña del proyecto se retrasa. Remedio: reducir la funcionalidad (timeboxing) o informar del retraso.
— Adición de más personal a un proyecto retrasado: genera más retraso porque se incrementan los problemas de coordinación y hay que explicar a los nuevos el trabajo ya realizado. Remedio: revisar el plan y añadir personal sólo en partes aisladas del proyecto.
GRÁFICO ILUSTRATIVO
ANÁLISIS DE REQUISITOS
Es el proceso de estudiar las necesidades de los usuarios con la idea de llegar a la determinación de los requisitos de un sistema, hardware o software (IEEE). También según el IEEE, requisito es una condición o capacidad que necesita un usuario para resolver un problema o alcanzar un objetivo.
El análisis de requisitos ha sido una fuente de conflicto permanente en los proyectos de desarrollo de sistemas de información o de implantación de SE. Por un lado, es casi imposible planificar y organizar un proyecto si no se sabe lo que se da por descontado que se debe entregar. Por otro, si el usuario no entiende los requisitos, o no es capaz de articularlos, ¿cómo pueden documentarlos adecuadamente los responsables del desarrollo? Y si los requisitos están sometidos a un constante cambio, ¿cómo se justifica el perder tiempo y energías documentándolos?.
El análisis de requisitos ha sido una fuente de conflicto permanente en los proyectos de desarrollo de sistemas de información o de implantación de SE. Por un lado, es casi imposible planificar y organizar un proyecto si no se sabe lo que se da por descontado que se debe entregar. Por otro, si el usuario no entiende los requisitos, o no es capaz de articularlos, ¿cómo pueden documentarlos adecuadamente los responsables del desarrollo? Y si los requisitos están sometidos a un constante cambio, ¿cómo se justifica el perder tiempo y energías documentándolos?.
CARACTERÍSTICAS
En el proceso de análisis de requisitos se diferencian tres subprocesos: extracción, documentación y gestión de los requisitos.
La extracción de requisitos se caracteriza por una «conversación» no trivial entre dos culturas: los usuarios que no son especialistas en TI y los profesionales de las TI que no dominan el aspecto del negocio que se va a automatizar. También entran en juego otros aspectos como los derivados del personal afectado por una reingeniería de procesos. Entre las técnicas de extracción cabe citar: entrevistas, cuestionarios, brainstorming, storyboarding, prototyping, Joint Application Development (JAD) y modelización.
La documentación es un aspecto conflictivo por las posiciones extremas que genera. Lo importante es descubrir el equilibrio óptimo. Además de los requisitos funcionales y de datos hay que documentar los no-funcionales (v.g. fiabilidad y escalabilidad). Los modelos visuales (object models, diagramas UML o diagramas de flujo) son muy útiles.
La gestión de requisitos se centra en evaluar la prioridad, riesgo y esfuerzo de cada uno de ellos. Entre los Requirement Management tools (RM) más utilizados se citan DOORS, Caliber-RM o Requisite Pro.
La extracción de requisitos se caracteriza por una «conversación» no trivial entre dos culturas: los usuarios que no son especialistas en TI y los profesionales de las TI que no dominan el aspecto del negocio que se va a automatizar. También entran en juego otros aspectos como los derivados del personal afectado por una reingeniería de procesos. Entre las técnicas de extracción cabe citar: entrevistas, cuestionarios, brainstorming, storyboarding, prototyping, Joint Application Development (JAD) y modelización.
La documentación es un aspecto conflictivo por las posiciones extremas que genera. Lo importante es descubrir el equilibrio óptimo. Además de los requisitos funcionales y de datos hay que documentar los no-funcionales (v.g. fiabilidad y escalabilidad). Los modelos visuales (object models, diagramas UML o diagramas de flujo) son muy útiles.
La gestión de requisitos se centra en evaluar la prioridad, riesgo y esfuerzo de cada uno de ellos. Entre los Requirement Management tools (RM) más utilizados se citan DOORS, Caliber-RM o Requisite Pro.
TIPOLOGÍAS / CLASIFICACIÓN
Los requisitos funcionales especifican una función que un sistema o componente de sistema debe ser capaz de desarrollar. Es el tipo que viene antes al pensamiento. Los requisitos no-funcionales, como el througput del sistema, la amigabilidad de la interfaz de usuario, la escalabilidad o la fiabilidad, son cruciales en la aceptabilidad del sistema.
Los interface requirements especifican un ítem externo con el cual debe interaccionar un sistema o componente de sistema, o establecen las restricciones de formato, tiempo u otros factores causados por dicha interacción.
Los design requirements especifican o restringen el diseño de un sistema o de uno de sus componentes.
Los implementation requirements especifican o restringen la codificación o construcción de un sistema o de uno de sus componentes.
Los performance requirements imponen condiciones en un requisito funcional; por ejemplo, un requisito que especifica la velocidad, precisión o cantidad de memoria utilizada con la cual se debe ejecutar una función determinada.
Los interface requirements especifican un ítem externo con el cual debe interaccionar un sistema o componente de sistema, o establecen las restricciones de formato, tiempo u otros factores causados por dicha interacción.
Los design requirements especifican o restringen el diseño de un sistema o de uno de sus componentes.
Los implementation requirements especifican o restringen la codificación o construcción de un sistema o de uno de sus componentes.
Los performance requirements imponen condiciones en un requisito funcional; por ejemplo, un requisito que especifica la velocidad, precisión o cantidad de memoria utilizada con la cual se debe ejecutar una función determinada.
GRÁFICO ILUSTRATIVO
DISEÑO
El diseño es el proceso de definir la arquitectura, componentes, interfaces y otras características de un sistema o componente (IEEE). Es la etapa del SDLC que produce las especificaciones funcionales y las especificaciones de diseño del sistema de la aplicación que está en desarrollo.
La codificación es el proceso de expresar un programa en un lenguaje de programación o la transformación de la lógica y datos contenida en las descripciones del diseño en un lenguaje de programación. En un SE, aunque existirá actividad de codificación, ésta será menor que la de un sistema in-house, añadiéndose otra de configuración del SE.
Lo que el director de un proyecto de desarrollo o implantación de sistemas debe hacer es seguir y controlar el progreso de estas actividades. De hecho a ello dedica la mayor parte de su día.
Según sea la formación del director del proyecto —experiencia de muchos años, un player-coach joven o un non-technical project manager— participará más o menos en estos procesos, pero lo importante es que asegure que el trabajo correcto lo hace la persona adecuada y con la calidad precisa.
La codificación es el proceso de expresar un programa en un lenguaje de programación o la transformación de la lógica y datos contenida en las descripciones del diseño en un lenguaje de programación. En un SE, aunque existirá actividad de codificación, ésta será menor que la de un sistema in-house, añadiéndose otra de configuración del SE.
Lo que el director de un proyecto de desarrollo o implantación de sistemas debe hacer es seguir y controlar el progreso de estas actividades. De hecho a ello dedica la mayor parte de su día.
Según sea la formación del director del proyecto —experiencia de muchos años, un player-coach joven o un non-technical project manager— participará más o menos en estos procesos, pero lo importante es que asegure que el trabajo correcto lo hace la persona adecuada y con la calidad precisa.
CARACTERÍSTICAS
El proceso de diseño tiene tres subprocesos: asignación y reparto de tareas; determinación y seguimiento de la calidad del trabajo y seguimiento del proyecto. Los requisitos deben dirigir el proceso de diseño y la asignación y reparto de tareas, aunque se tomen a priori decisiones de diseño influidas por las circunstancias. En la determinación y seguimiento de la calidad del trabajo son clave los requisitos no-funcionales; también la documentación, aunque se limite a un diagrama de alto nivel que defina componentes y subsistemas; así como la frecuencia y profundidad de las revisiones.
Una actividad clave del proceso de codificación es la gestión del código fuente (Source Code Management o SCM) para la que hay herramientas que se adaptan a cualquier lenguaje. Otra es el uso de entornos de desarrollo que producen automáticamente documentación de diseño a partir del código (Rational ROSE y Together C++). Otra, el concepto de Pair Programming de XP, que promete más productividad.
La naturaleza y número de los parámetros de configuración y su facilidad de cambio, varían según el paquete. Algunos como SAP tienen reputación de gran funcionalidad.
Una actividad clave del proceso de codificación es la gestión del código fuente (Source Code Management o SCM) para la que hay herramientas que se adaptan a cualquier lenguaje. Otra es el uso de entornos de desarrollo que producen automáticamente documentación de diseño a partir del código (Rational ROSE y Together C++). Otra, el concepto de Pair Programming de XP, que promete más productividad.
La naturaleza y número de los parámetros de configuración y su facilidad de cambio, varían según el paquete. Algunos como SAP tienen reputación de gran funcionalidad.
TIPOLOGÍAS / CLASIFICACIÓN
El architectural design es el proceso de definir una colección de componentes de hardware y software y sus interfaces, para establecer el marco del desarrollo de un sistema de información. También recibe este nombre el resultado de dicho proceso.
El functional design es el proceso de definir las interrelaciones entre los componentes de un sistema. También recibe este nombre el resultado de dicho proceso.
Un preliminary design es el proceso de analizar alternativas de diseño y definir la arquitectura, componentes, interfaces y las estimaciones de tiempo y tamaño de un sistema o componente. Un detailed design es el proceso de refinar y expandir un diseño preliminar de un sistema o componente, hasta el grado en el que el diseño sea lo suficientemente preciso para ser implantado. En ambos casos, se hace referencia con este nombre al resultado de los respectivos procesos.
El source code o código fuente son instrucciones de ordenador y definiciones de datos expresadas en una forma susceptible de ser la entrada a un programa ensamblador, compilador u otra forma de traductor a lenguaje máquina.
El functional design es el proceso de definir las interrelaciones entre los componentes de un sistema. También recibe este nombre el resultado de dicho proceso.
Un preliminary design es el proceso de analizar alternativas de diseño y definir la arquitectura, componentes, interfaces y las estimaciones de tiempo y tamaño de un sistema o componente. Un detailed design es el proceso de refinar y expandir un diseño preliminar de un sistema o componente, hasta el grado en el que el diseño sea lo suficientemente preciso para ser implantado. En ambos casos, se hace referencia con este nombre al resultado de los respectivos procesos.
El source code o código fuente son instrucciones de ordenador y definiciones de datos expresadas en una forma susceptible de ser la entrada a un programa ensamblador, compilador u otra forma de traductor a lenguaje máquina.
GRÁFICO ILUSTRATIVO
IMPLANTACIÓN
Es la fase final de la SDLC. Durante ella se construye el sistema. Al final de esta fase el sistema se entrega al project sponsor. Es la fase a la que, habitualmente, se presta más atención, porque en la mayoría de los sistemas es la más larga y de mayor coste.
Su primera etapa es la de construcción. Durante ella se programa o configura, prueba y documenta. Las pruebas son una de las actividades más críticas de la implantación porque el coste de los errores puede ser impresionante; la mayoría de las organizaciones dedica más tiempo a las pruebas que a la programación.
Superadas una serie de pruebas el sistema se instala. Durante esta etapa se da de baja al sistema antiguo y de alta al nuevo. Los usuarios dejan de utilizar los procesos y programas as-is y emigran hacia los procesos y programas to-be. En esta etapa juegan un importante papel las actividades de gestión del cambio centradas en las personas y no en la tecnología. El ciclo de desarrollo se cierra con las actividades post-implantación que institucionalizan el uso del nuevo sistema.
Su primera etapa es la de construcción. Durante ella se programa o configura, prueba y documenta. Las pruebas son una de las actividades más críticas de la implantación porque el coste de los errores puede ser impresionante; la mayoría de las organizaciones dedica más tiempo a las pruebas que a la programación.
Superadas una serie de pruebas el sistema se instala. Durante esta etapa se da de baja al sistema antiguo y de alta al nuevo. Los usuarios dejan de utilizar los procesos y programas as-is y emigran hacia los procesos y programas to-be. En esta etapa juegan un importante papel las actividades de gestión del cambio centradas en las personas y no en la tecnología. El ciclo de desarrollo se cierra con las actividades post-implantación que institucionalizan el uso del nuevo sistema.
CARACTERÍSTICAS
En la etapa de construcción hay que ejecutar con especial cuidado las actividades de: asignación de módulos —separados y distintos— a los programadores; coordinación del programa y de sus cambios durante la construcción; gestión de la programación temporal de tareas; planificación y el diseño de las pruebas (unit tests, integration tests, system tests y acceptance tests); y el desarrollo de la documentación del sistema y de los usuarios (documentos de referencia, manuales de procedimiento y tutoriales).
En la etapa de instalación hay que realizar la conversión —instalación de hardware, de software y conversión de datos del sistema as-is al to-be—; la revisión de las políticas de gestión adaptándolas al sistema to-be; la comparación en términos de costes y beneficios del nuevo sistema con el antiguo; tanto en términos apropiados a la organización como a los stakeholders. También hay que definir la estrategia de motivación a la adopción, la formación de los potenciales adoptadores, el soporte de los usuarios y el mantenimiento del sistema.
Otra actividad es la evaluación del proyecto, y la consiguiente detección de logros y oportunidades de mejora de cara a la próxima actuación.
En la etapa de instalación hay que realizar la conversión —instalación de hardware, de software y conversión de datos del sistema as-is al to-be—; la revisión de las políticas de gestión adaptándolas al sistema to-be; la comparación en términos de costes y beneficios del nuevo sistema con el antiguo; tanto en términos apropiados a la organización como a los stakeholders. También hay que definir la estrategia de motivación a la adopción, la formación de los potenciales adoptadores, el soporte de los usuarios y el mantenimiento del sistema.
Otra actividad es la evaluación del proyecto, y la consiguiente detección de logros y oportunidades de mejora de cara a la próxima actuación.
TIPOLOGÍAS / CLASIFICACIÓN
La conversión de un sistema a otro se puede analizar desde tres puntos de vista: el estilo o forma, la localización o partes afectadas, y las partes del sistema que se convierten a un tiempo.
El estilo de conversión, o forma en la que los usuarios «conmutan» de un sistema a otro, puede ser directo —el nuevo sistema reemplaza instantáneamente al antiguo (big-bang , cold turkey, abrupt cutover) —o en paralelo— se usan ambos sistemas simultáneamente hasta que se tiene una certeza razonable de la correcta operación del nuevo.
Desde el punto de vista de la localización se puede distinguir entre una conversión piloto (una o más localizaciones o unidades se seleccionan para formar parte del piloto o test), una conversión en fases (el sistema se instala progresivamente en diferentes localizaciones) y una conversión simultánea (todas las localizaciones se convierten al mismo tiempo).
Desde el punto de vista de las partes del sistema que se convierten se puede hablar de una conversión total (todo el sistema se instala a un tiempo) o modular (el sistema se instala módulo a módulo). Esta última requiere que los módulos sean separados y distintos.
El estilo de conversión, o forma en la que los usuarios «conmutan» de un sistema a otro, puede ser directo —el nuevo sistema reemplaza instantáneamente al antiguo (big-bang , cold turkey, abrupt cutover) —o en paralelo— se usan ambos sistemas simultáneamente hasta que se tiene una certeza razonable de la correcta operación del nuevo.
Desde el punto de vista de la localización se puede distinguir entre una conversión piloto (una o más localizaciones o unidades se seleccionan para formar parte del piloto o test), una conversión en fases (el sistema se instala progresivamente en diferentes localizaciones) y una conversión simultánea (todas las localizaciones se convierten al mismo tiempo).
Desde el punto de vista de las partes del sistema que se convierten se puede hablar de una conversión total (todo el sistema se instala a un tiempo) o modular (el sistema se instala módulo a módulo). Esta última requiere que los módulos sean separados y distintos.
GRÁFICO ILUSTRATIVO
Comentarios
Publicar un comentario