Desarrollo de Sistemas de Información
Proceso de desarrollo de sistema.
Los sistemas de información son un producto complejo. un sistema de información incluye componentes y tecnologías de datos, procesos y comunicaciones, que deben atender las necesidades de una diversidad de interesados.
Cada vez más, las organizaciones no tienen otra elección más que adoptar y seguir un proceso estandarizado de desarrollo de sistemas ya que ofrece:
- Primero, utilizar un proceso consistente de desarrollo de sistemas crea eficiencias que permiten a la administración compartir recursos entre proyectos.
- Segundo, una metodología consistente produce documentación consistente que reduce los costos del tiempo de vida para mantener los sistemas.
Modelo de Madurez de la Capacidad
Se demostró que conforme un proceso de desarrollo de sistemas de información de una organización madura, la duración y el costo del proyecto disminuyen al tiempo que la productividad y la calidad aumentan.
- Nivel 1, Inicial. Esto a veces es llamado anarquía o caos. En este nivel, los proyectos de desarrollo de sistemas no siguen un proceso consistente. Cada equipo de desarrollo utiliza sus propias herramientas y métodos. El éxito o el fracaso generalmente es una función de la habilidad y experiencia del equipo. El proceso es impredecible y no es repetible. Casi todas las organizaciones empiezan en el nivel 1.
- Nivel 2, Repetible. En este nivel los procesos y las prácticas de administración de proyectos están establecidos para rastrear costos, programas y funcionalidad del proyecto. El éxito o el fracaso está todavía en función de la habilidad y experiencia del equipo del proyecto; sin embargo, se hace un esfuerzo concertado por repetir éxitos de proyectos anteriores. Las prácticas de administración de proyectos eficaces establecen la base para procesos estandarizados en el siguiente nivel.
- Nivel 3, Definido. En este nivel se adquiere o se desarrolla un proceso de desarrollo de sistemas estándar (a veces llamado metodología). Todos los proyectos utilizan una versión personalizada de este proceso para desarrollar y mantener sistemas de información y software. El proceso es estable, predecible y repetible.
- Nivel 4, Administrado. En este nivel se establecen metas mensurables para la calidad y la productividad. Las mediciones detalladas del proceso de desarrollo de sistemas estándar y la calidad del producto se recolectan y almacenan rutinariamente en una base de datos.
- Nivel 5, Optimizado. En este nivel el proceso de desarrollo del sistema estandarizado es vigilado continuamente y mejorado con base en medidas y análisis de datos establecidos en el nivel 4. Esto puede incluir cambiar la tecnología y las mejores prácticas utilizadas para realizar actividades requeridas en el proceso estándar de desarrollo del sistema, así como ajustar el proceso mismo. En resumen, la organización ha institucionalizado una mejora continua del proceso de desarrollo de sistemas.
Es muy importante reconocer que cada nivel es un requerimiento previo para el siguiente nivel. Actualmente, muchas organizaciones están trabajando fuerte para lograr al menos un nivel 3 de CMM. Un tema central para lograr el nivel 3 (definido) es el uso de un proceso o una metodología estándar para construir o integrar sistemas.
Ciclo de vida frente a metodología.
Los términos ciclo de vida del sistema y metodología de desarrollo del sistema con frecuencia son intercambiados incorrectamente. La mayoría de los procesos de desarrollo de sistemas se derivan de un ciclo de vida del sistema natural. El ciclo de vida del sistema sólo sucede.
En realidad, un sistema puede estar en más de una etapa al mismo tiempo. Por ejemplo, una versión puede estar en operación y soporte mientras que la siguiente versión está en desarrollo.
Una metodología de desarrollo de sistemas “ejecuta” la etapa de desarrollo de sistemas del ciclo de vida del sistema. Cada sistema de información tiene su propio ciclo de vida.
La metodología es el proceso estándar para construir y mantener ese sistema y todos los demás sistemas de información a través de sus ciclos de vida. En consistencia con las metas de CMM, las metodologías aseguran que:
- Un método consistente y reproducible se aplique a todos los proyectos.
- Hay un riesgo reducido asociado con las omisiones y los errores.
- Se produzca documentación completa y consistente de un proyecto al otro.
- Analistas de sistemas, diseñadores y constructores puedan ser reasignados rápidamente entre proyectos debido a que todos usan el mismo proceso.
- Como los equipos y el personal de desarrollo cambian constantemente, los resultados del trabajo anterior pueden ser encontrados con facilidad y entendidos por las personas que les siguen.
Las metodologías internas en general están basadas en metodologías genéricas y técnicas que están bien documentadas en libros y en sitios Web. Algunos ejemplos de metodologías de desarrollo de sistemas están listados en el margen de la siguiente página.
FAST, que significa Framework for the Application of Systems Thinking. FAST no es una metodología comercial del mundo real. La desarrollamos como una mezcla de las mejores prácticas que hemos encontrado en muchas metodologías comerciales y de referencia. A diferencia de muchas metodologías comerciales, FAST no es estricta. Esto es, FAST es un marco de referencia que es ágil y lo suficientemente flexible para proporcionar distintos tipos de proyectos y estrategias. Pero lo más importante, FAST tiene mucho en común con las metodologías basadas en los libros y las comerciales que usted encontrará en la práctica.
Principios fundamentales para el desarrollo de sistemas.
Antes de examinar la metodología FAST, se presenta algunos principios generales que deben estar en todas las metodologías del desarrollo de sistemas.
- Principio 1: Hacer participar a los usuarios del sistema Los analistas, programadores y otros especialistas de la tecnología de la información frecuentemente se refieren a “mi sistema”. Esta actitud, en parte, ha creado un conflicto de “nosotros contra ellos” entre el personal técnico y los usuarios y la administración. Aunque los analistas y programadores trabajan fuerte para crear soluciones impresionantes de tecnología, esas soluciones a menudo les ocasionan problemas porque no abordan los problemas reales de la organización.
- Principio 2: Utilizar un método de solución de problemas Una metodología de desarrollo de sistemas es, primero y sobretodo, un enfoque de solución de problemas de la construcción de sistemas. El término problema es ampliamente utilizado a lo largo de este libro para incluir problemas reales, oportunidades para mejorar, directrices de la administración.
- Principio 3: Establecer fases y actividades Todas las metodologías tienen fases y actividades. El número y el alcance de ambas varían de autor en autor, de experto en experto, de metodología en metodología y de empresa a empresa. La página de inicio de este capítulo ilustra las ocho fases de nuestra metodología FAST en el contexto de su marco de referencia de sistemas de información.
- Principio 4: Documentar a través del desarrollo. La documentación mejora las comunicaciones y la aceptación. La documentación revela fortalezas y debilidades del sistema para los múltiples interesados. Estimula la participación de los usuarios y reasegura la administración acerca del progreso. Al mismo tiempo, algunas metodologías han sido criticadas por esperar demasiada documentación que agrega poco valor al proceso o sistema resultante. Nuestra metodología FAST defiende un equilibrio entre el valor de la documentación y el esfuerzo por producirla. Los expertos llaman a esto modelado acelerado.
- Principio 5: Establecer estándares En un mundo perfecto, todos los sistemas de información estarían integrados de tal forma que se comportaran como un solo sistema. Desafortunadamente, esto nunca sucede debido a que los sistemas de información son desarrollados y reemplazados durante un largo periodo.
- Principio 6: Administrar el proceso y los proyectos La mayoría de las organizaciones tienen un proceso o una metodología de desarrollo de sistemas, pero no siempre lo utilizan en forma consistente en los proyectos. Tanto el proceso como los proyectos que lo utilizan deben ser administrados.
- Principio 7: Justificar sistemas de información como inversiones de capital Los sistemas de información son inversiones de capital, tal como una flota de camiones o un nuevo edificio. Los propietarios del sistema se comprometen con esta inversión.
- Principio 8: No temer en cancelar o revisar el alcance. No tema cancelar un proyecto o revisar un alcance, sin importar cuánto dinero se haya gastado hasta el momento; recorte sus pérdidas. Para este fin, se recomienda un método de compromiso ajustado para el desarrollo de sistemas.
- Principio 9: Divida y vencerá Ya sea que usted esté consciente o no, ha aprendido el método llamado “divide y vencerás” a lo largo de su educación. Desde la secundaria, a usted le ha sido enseñado a delinear un trabajo antes de escribirlo.
- Principio 10: Diseñar sistemas para crecimiento y cambio Los negocios cambian con el paso del tiempo. Sus necesidades cambian. Sus prioridades cambian. En consecuencia, los sistemas de información que respaldan a un negocio deben cambiar con el paso del tiempo. Los sistemas deben ser diseñados para incorporar tanto los requerimientos de crecimiento como de cambio.
Proceso de desarrollo de sistemas.
Se analizara un proceso lógico para el desarrollo de sistemas. (Recordatorio: FAST es una metodología hipotética creada para fines de aprendizaje).
¿De dónde surgen los proyectos de desarrollo de sistemas?
Los propietarios y los usuarios de sistemas inician la mayoría de los proyectos. El ímpetu (Fuerza o energía con que alguien hace algo o con que se desarrolla algo) de casi todos los proyectos es alguna combinación de problemas, oportunidades y directrices.
Hay demasiados problemas potenciales de sistemas para listarlos todos en este texto. Sin embargo, James Wetherbe desarrolló un marco de referencia útil para clasificar problemas. El le llama PIECES debido a las letras en inglés de cada una de las seis categorías, que cuando se unen, deletrean la palabra “pieces”. Las categorías son:
- P (performance) la necesidad de corregir o mejorar el desempeño
- I (information) la necesidad de corregir o mejorar la información (y datos)
- E (economics) la necesidad de corregir o mejorar la economía, controlar costos o aumentar las utilidades.
- C (control) la necesidad de corregir o mejorar el control o la seguridad.
- E (eficiency) la necesidad de corregir o mejorar la eficiencia de las personas y los procesos.
- S (service) la necesidad de corregir o mejorar el servicio a clientes, proveedores, socios, empleados y demás.
Las fases del proyecto FAST.
FAST, al igual que la mayoría de las metodologías, consiste de fases. El número de ellas variará de una metodología a otra:
- Inicio de proyecto
- Análisis del sistema
- Diseño del sistema
- Implantación del sistema
Definición de alcance La primera fase de un proyecto típico es la "Definición de alcance". El propósito de la fase de definición de alcance es de dos sentidos. Primero, responde la pregunta, “¿vale la pena atender este problema?”. Segundo y suponiendo que el problema vale la pena, establece el tamaño y las fronteras del proyecto, la visión del proyecto, cualquier restricción o limitación, los participantes requeridos del proyecto y finalmente, el presupuesto y el programa.
Análisis del problema Siempre hay un sistema existente, sin importar si actualmente utiliza tecnología de la información. La fase del "Análisis del problema" estudia el sistema existente y analiza los resultados que proporciona al equipo del proyecto con una comprensión más completa de los problemas que dispararon el proyecto.
Análisis de requerimientos: Ésta es tal vez la fase más importante del desarrollo de sistemas. Errores y omisiones en el análisis de requerimientos resultarán en la insatisfacción del usuario con el sistema final y modificaciones costosas
Diseño lógico : Los requerimientos del negocio generalmente son expresados en palabras. Los analistas del sistema han encontrado que es útil traducir esas palabras en imágenes llamadas modelos de sistemas para validar los requerimientos con el fin de que estén completos y sean consistentes.
Análisis de decisión: Dados los requerimientos de negocios y los modelos de sistema lógicos, normalmente hay diversas alternativas para diseñar un nuevo sistema de información que satisfagan esos requerimientos.
Diseño físico e integración Dada la aprobación de la propuesta del diseño de la fase de análisis de decisión, al fin, usted puede diseñar el nuevo sistema. El propósito de la fase de diseño fisico e integracion es transformar los requerimientos de negocios en las especificaciones de diseño fisico que guiarán la construcción del sistema.
Construcción y pruebas: El propósito de la construcción y la fase de pruebas es doble:1) Construir y probar un sistema que satisfaga los requerimientos de negocios y las especificaciones de diseño físico.2) implantar las interfaces entre el nuevo sistema y los sistemas existentes.
Instalación y entrega: La fase de instalación y entrega incluye capacitar a los individuos que utilizarán el sistema final y desarrollar documentación para ayudar a los usuarios de sistemas. La fase de implantación normalmente incluye alguna forma de revisión posterior a la auditoria para calcular el éxito del proyecto de sistemas terminado.
Operación del sistema y mantenimiento: Una vez que el sistema esté puesto en operación, requerirá un soporte del sistema continuo para el resto de su vida útil y productiva. El soporte de sistemas consiste en las siguientes actividades continuas:
- Ayuda a usuarios.
- Arreglar los defectos de software.
- Recuperación del sistema.
- Adaptar el sistema a requerimientos nuevos.
Actividades transversales del ciclo de vida.
El desarrollo del sistema también incluye diversas actividades transversales del ciclo de vida.
Identificación de hechos Hay muchas ocasiones para una identificación de hechos durante un proyecto. La identificación de hechos es más crucial para las primeras fases de un proyecto. Es durante estas fases que el equipo de proyecto aprende acerca del vocabulario del negocio, los problemas, oportunidades, restricciones, requerimientos y prioridades.
Documentación y presentación Las habilidades de comunicación son esenciales para el cumplimiento exitoso de cualquier proyecto. De hecho, una mala comunicación con frecuencia es citada como la principal causa de retrasos de proyectos y repetición del trabajo.
Análisis de factibilidad En consistencia con nuestro enfoque de compromiso ajustado al desarrollo de sistemas, el análisis de factibilidad es una actividad transversal del ciclo de vida
Administración de proyecto y de proceso Recuerde que CMM considera el desarrollo de sistemas como un proceso que debe ser manejado de proyecto en proyecto. Por ésta y otras razones, la administración de proceso y la administración de proyecto son actividades continuas, transversales del ciclo de vida.
Desarrollo secuencial o iterativo.
El desarrollo iterativo o proceso de desarrollo incremental requiere completar suficiente análisis, diseño e implantación para ser capaz de desarrollar completamente una parte del nuevo sistema y de colocarlo en operación tan rápido como sea posible.
Herramientas y tecnología automatizada
En el pasado no muy lejano, las herramientas principales del analista de sistemas eran papel, lápiz y una plantilla de diagrama de flujos.
Actualmente, conjuntos de herramientas automatizadas han sido desarrolladas, comercializadas e instaladas para ayudar a los desarrolladores de sistemas. Mientras que las metodologías de desarrollo de sistemas no siempre requieren herramientas automatizadas, la mayoría de las metodologías se benefician de dicha tecnología.
Ingeniería de sistemas asistida por computadora.
Los desarrolladores de sistemas han aspirado desde hace mucho a transformar el desarrollo de los sistemas de información y el software en disciplinas estilo ingeniería. Los términos ingeniería de sistemas e ingeniería de software están basados en una visión de que los sistemas y el desarrollo de software pueden y deben desempeñarse con precisión y rigor tipo ingeniería.
Repositorios CASE: Al centro de cualquier arquitectura de herramientas CASE está una base de datos de un desarrollador llamada repositorio CASE.
Ventajas de CASE:
- Las herramientas de elaboración de diagramas se utilizan para dibujar los modelos de sistemas requeridos o recomendados en la mayoría de las metodologías de desarrollo de sistemas.
- Las herramientas de diccionario se utilizan para grabar, eliminar, editar y producir documentación y especificaciones detalladas.
- Las herramientas de diseño pueden ser utilizadas para desarrollar muestras de los componentes de sistemas como entradas y salidas.
- Con las herramientas de administración de calidad se analizan los modelos de sistemas, las descripciones y especificaciones y los diseños para integridad, consistencia y cumplimiento a las reglas y metodologías aceptadas.
- Las herramientas de documentación se utilizan para ensamblar, organizar e informar acerca de los modelos de sistemas, descripciones y especificaciones y prototipos.
- Las herramientas de documentación se utilizan para ensamblar, organizar e informar acerca de los modelos de sistemas, descripciones y especificaciones y prototipos.
- Las herramientas de prueba estimulan transacciones o tráfico de datos, miden el desempeño y proporcionan una administración de configuración de los planes de prueba y los guiones de prueba.
Ingeniería hacia adelante e inversa.
se afirmó antes, la tecnología CASE automatiza la elaboración de sistemas. Las herramientas CASE actuales proporcionan dos formas para desarrollar los modelos de sistemas ingeniería hacia adelante e ingeniería inversa.
Ambientes de desarrollo de aplicación.
Los ambientes de desarrollo de aplicación proporcionan diversas instalaciones de administración de productividad y calidad.
Administradores de proceso y proyecto.
Una tercera clase de herramientas automatizadas nos ayuda a manejar la metodología y los proyectos de desarrollo de sistemas que utilizan esa metodología. Mientras que las herramientas CASE y los ADE fueron hechos para soportar el análisis, diseño y construcción de los nuevos sistemas de información y software, las herramientas de aplicación de administrador de proceso y aplicación de administrador de proyecto fueron hechas para soportar las actividades transversales del ciclo de vida.
No hay comentarios:
Publicar un comentario