Cap Gemini SDM , o SDM2 (Metodología de Desarrollo de Sistemas) es un desarrollo de software método desarrollado por la compañía de software Pandata en los Países Bajos en 1970. El método es un modelo de cascada dividida en siete fases que tienen un comienzo y un final claro. Cada fase entrega subproductos, llamados hitos. Se utilizó ampliamente en los Países Bajos para proyectos de TIC [ aclaración necesaria ] en los años ochenta y noventa. Pandata fue comprado por Capgeminien la década de 1980, y la última versión de SDM que se publicó en inglés fue SDM2 (sexta edición) en 1991 por Cap Gemini Publishing BV. El método se enseñó y distribuyó regularmente entre los consultores y clientes de Capgemini, hasta que el método en cascada lentamente pasó de moda a raíz de métodos de programación extremos más iterativos , como el desarrollo rápido de aplicaciones , el proceso unificado racional y el desarrollo de software ágil .
La metodología Cap Gemini SDM
Desde principios hasta mediados de la década de 1970, los diversos pasos de trabajo genéricos de las metodologías de desarrollo de sistemas fueron reemplazados por pasos de trabajo basados en diversas técnicas de análisis estructurado o diseño estructurado. SDM, SDM2, SDM / 70 y Spectrum evolucionaron hacia metodologías de desarrollo de sistemas que se basaron en los trabajos de Steven Ward, Tom Demarco, Larry Constantine , Ken Orr , Ed Yourdon , Michael A. Jackson y otros, así como en técnicas de modelado de datos. desarrollado por Thomas Bachmann y Peter Chen . SDM es un modelo de arriba hacia abajo . Partiendo del sistema en su conjunto, su descripción se vuelve más detallada a medida que avanza el diseño. El método se comercializó como un método patentado que todos los desarrolladores de la empresa debían utilizar para garantizar la calidad en los proyectos de los clientes. Este método muestra varias similitudes con los métodos patentados de los competidores más importantes de CAP Gemini en 1990. Un método de cascada similar que se utilizó más tarde contra la propia empresa en los procedimientos judiciales en 2002 fue CMG: Commander. [1]
Historia
SDM fue desarrollado en 1970 por una empresa conocida como PANDATA, ahora parte de Cap Gemini , que a su vez fue creada como una empresa conjunta por tres empresas holandesas: AKZO , Nationale Nederlanden y Posterijen, Telegrafie en Telefonie (Nederland) . La empresa se fundó con el fin de desarrollar el método y crear materiales de formación para difundir el método. Tuvo éxito, pero se revisó en 1987 para estandarizar y separar la teoría del método de los aspectos más técnicos utilizados para implementar el método. Esos aspectos se incluyeron en la herramienta de modelado de procesos llamada "Software Development Workbench", que luego se vendió en 2000 a BWise, otra empresa holandesa. Esta versión revisada del método sin la herramienta se conoce comúnmente como SDM2 . [2]
Diferencia principal entre SDM y SDM2
SDM2 era una versión revisada de SDM que intentaba resolver un problema básico que ocurría a menudo en los proyectos de SDM; el sistema entregado no cumplió con los requisitos del cliente. Aunque podría surgir una serie de razones específicas para esto, el método de cascada básico utilizado en SDM fue una receta para este problema debido a la cantidad relativamente grande de tiempo que los equipos de desarrollo dedicaron entre el estudio de definición y las fases de implementación. Fue durante las fases de diseño que el proyecto a menudo se desincronizó con los requisitos del cliente.
Durante la fase de diseño funcional SDM denominada BD (Diseño Básico), los aspectos del diseño fueron documentados (fuera de fase) en detalle para el posterior diseño técnico DD (Diseño Detallado). Esto provocó que se produjera una zona gris de responsabilidad entre las dos fases; el equipo funcional responsable de los flujos de datos y procesos en la BD estaba tomando decisiones que el equipo técnico necesitaba codificar posteriormente, aunque su conocimiento técnico no era lo suficientemente detallado para tomar esas decisiones. Obviamente, esto condujo a problemas en la colaboración entre los equipos de proyecto durante las fases de BD y DD. Debido al método en cascada de las decisiones Pasar / No Pasar al final de cada fase, el equipo técnico tendría que hacer una solicitud de Cambio formal para poder hacer correcciones en las secciones detalladas del Diseño Básico. Dichos cambios a menudo resultaban confusos para el cliente, porque se originaban en el equipo del proyecto y no directamente en los requisitos del cliente, incluso después de que se implementó una congelación de cambios . Por lo general, al cliente solo se le permitía producir requisitos hasta e incluido el diseño funcional en la fase de BD. Después de eso, el cliente tuvo que esperar pacientemente hasta las pruebas de aceptación en la fase de Implementación.
En SDM2, el término "Diseño básico" fue reemplazado por el término "Diseño global" para indicar que este documento se actualizaba continuamente y estaba sujeto a cambios durante las fases BD y DD. Por lo tanto, el "diseño básico" es global y detallado al final del proyecto. En el diseño global se documentan los principios de funcionalidad y construcción, así como sus relaciones. Así nació la idea del desarrollo iterativo; un diseño funcional está influenciado por naturaleza por la plataforma de tecnología elegida para la implementación, y algunas decisiones de diseño básicas deberán revisarse cuando las suposiciones iniciales demuestren ser incorrectas o costosas de implementar. Esto se convirtió en el precursor del método de desarrollo rápido de aplicaciones, lo que provocó que estas dos fases se volvieran cíclicas y funcionaran en conjunto.
SDM2 solo resolvió parcialmente el problema de cumplir con los requisitos del cliente; Los métodos modernos de desarrollo de software van varios pasos más allá al insistir, por ejemplo, en entregas incrementales o en que el cliente designe a los usuarios clave del sistema entregado para que desempeñen un papel en el proyecto de principio a fin.
El método SDM
SDM es un método basado en fases. Antes de cada fase, es necesario llegar a un acuerdo detallando las actividades para esa fase. Estos documentos se conocen como documentos de hitos . Existen varios usos para estos documentos:
- Trazabilidad: mediante la aplicación de plazos a los documentos de hitos, los clientes pueden realizar un seguimiento de si un proyecto está dentro del cronograma
- Consolidación: al aprobar un documento de hito, adquiere un cierto estado. El cliente no puede cambiar ninguna de las especificaciones posteriormente durante el desarrollo.
- Si es necesario, el proyecto se puede cancelar. Esto ocurre principalmente durante el inicio del desarrollo.
Etapas
El método utiliza 7 fases que se ejecutan sucesivamente, como el modelo de cascada. Las fases son:
- Planificación de la información: definición del problema y plan inicial
- Estudio de definición: análisis de requisitos y plan revisado
- Diseño básico: diseño técnico de alto nivel y plan revisado
- Diseño detallado: construcción del sistema (y plan revisado)
- Realización: Prueba y aceptación (y plan revisado)
- Implementación: instalación, conversión de datos y transición a producción
- Operación y soporte: Entrega al departamento de soporte de TIC
Una vez completada una fase, se decide si pasar a la siguiente fase o no; los términos "Go" y "No-Go" se utilizan para esto. La siguiente fase no comenzará hasta que se dé un 'Go', mientras que si hay un 'No-Go', el proyecto permanece en la fase actual para ser mejorado o se cancela por completo.
Planificación de la información
En esta fase se definen los problemas que tiene que resolver el proyecto. Se analizan las situaciones actuales y deseadas y se deciden los objetivos del proyecto. En esta fase, es importante considerar las necesidades de todas las partes, como los futuros usuarios y su gestión. A menudo, sus expectativas chocan, causando problemas más adelante durante el desarrollo o durante el uso del sistema.
Estudio de definición
En esta fase se realiza un estudio más profundo del proyecto. La organización se analiza para determinar sus necesidades y determinar el impacto del sistema en la organización. Se discuten y deciden los requisitos del sistema. Se determina la viabilidad del proyecto. Los aspectos que se pueden considerar para determinar la viabilidad son:
- Aconsejable: ¿Los recursos (tanto tiempo como conocimientos) están disponibles para completar el proyecto?
- Importancia - ¿Es necesario reemplazar el sistema actual?
- Técnica: ¿Puede el equipo disponible cumplir con los requisitos que le impone el sistema?
- Economía: ¿Los costos de desarrollar el sistema son más bajos que las ganancias obtenidas al usarlo?
- Organización: ¿podrá la organización utilizar el nuevo sistema?
- Legal - ¿El nuevo sistema entra en conflicto con las leyes existentes?
Diseño básico
En esta fase se realiza el diseño del producto. Una vez que el estudio de definición ha determinado lo que debe hacer el sistema, el diseño determina cómo se hará. Esto a menudo da como resultado dos documentos: el diseño funcional o el diseño de la interfaz de usuario que explica lo que hace cada parte del sistema, y el diseño técnico de alto nivel, que explica cómo va a funcionar cada parte del sistema. Esta fase combina el diseño funcional y técnico y solo da un diseño amplio para todo el sistema. A menudo, aquí se describe la arquitectura del sistema.
SDM2 dividió este paso en dos partes, una para la fase BD y otra para la fase DD, con el fin de crear un documento de diseño global.
Diseño detallado
En esta fase, el diseño del producto se describe técnicamente en la jerga necesaria para los desarrolladores de software (y más tarde, el equipo responsable del soporte del sistema en la fase de O&S). Una vez que se ha firmado el diseño básico, el diseño técnico detallado determina cómo se desarrollará con el software. Esto a menudo da como resultado una biblioteca de documentación fuente: el diseño funcional por función y el diseño técnico por función, explicando cómo va a funcionar cada parte del sistema y cómo se relacionan entre sí.
En SDM2, esta fase elabora el Diseño Global creando diseños más detallados, o refinando aún más los diseños detallados existentes, hasta el punto en que pueden usarse para construir el sistema en sí.
Realización
En esta fase, el diseño se convierte en un sistema funcional. La forma real de hacerlo dependerá del sistema utilizado. Mientras que en los sistemas más antiguos, los programadores a menudo tenían que escribir todo el código, los sistemas más nuevos permiten a los programadores convertir el diseño en código directamente, dejando menos trabajo por hacer y una menor posibilidad de errores. En el mismo tipo, el sistema se vuelve más dependiente del diseño: si el diseño se ha probado correctamente, se generará el código adecuado, pero si el diseño no es completamente correcto, el código será incorrecto sin un programador que lo busque. problemas.
Implementación
La fase de implementación o prueba consta de dos pasos: una prueba del sistema y una prueba de aceptación.
Durante la prueba del sistema, el equipo de desarrollo, o un equipo de pruebas independiente, prueba el sistema. La mayor parte de esto se centrará en los aspectos técnicos: ¿el sistema funciona como debería o todavía hay errores? Se solucionarán los errores que se encuentren en esta fase. Al final de esta fase, el programa debería funcionar correctamente.
Durante la prueba de aceptación, los usuarios finales probarán el sistema. Ellos probarán para ver si el programa hace lo que ellos quieren que haga. No probarán todos los escenarios posibles, pero probarán para ver si el programa hace lo que quieren y esperan que haga y que funcione de una manera fácil. Los errores que se encuentren en esta fase se informarán al equipo de desarrollo para que puedan solucionarlos.
Durante esta fase, la organización implementa la versión final del sistema: se configura el hardware, se instala el software, se crea la documentación del usuario final y, los usuarios finales capacitados para usar el programa, se ingresan los datos existentes en el sistema.
Operación y soporte
Una vez implementado el sistema, se utiliza dentro de la organización. Durante su vida útil, debe mantenerse en funcionamiento y posiblemente mejorar.
Referencias
- ^ Artículo holandés en la revista Computable sobre cómose utilizó el método CMG: Commanderdel competidor CMG para demostrar la responsabilidad de la empresa por el trabajo de los empleados
- ^ Artículo computable holandés sobre la venta de Software Development Workbench a BWise
enlaces externos
