Cap Gemini SDM

SDM2 fue una versión revisada de SDM que intentó solucionar un problema básico frecuente en los proyectos SDM: el sistema entregado no cumplía con los requisitos del cliente. Si bien esto podía deberse a diversas razones específicas, el método básico en cascada utilizado en SDM propiciaba este problema debido al considerable tiempo que los equipos de desarrollo dedicaban entre las fases de Estudio de Definición e Implementación. Era durante las fases de diseño cuando el proyecto solía desincronizarse con los requisitos del cliente.

Durante la fase de diseño funcional de SDM, denominada BD (Diseño Básico), los aspectos de diseño se documentaron en detalle (fuera de fase) para el posterior diseño técnico DD (Diseño Detallado). Esto generó una zona gris de responsabilidad entre ambas fases; el equipo funcional responsable de los flujos de datos y de procesos en el BD tomaba decisiones que el equipo técnico debía codificar posteriormente, aunque su conocimiento técnico no era lo suficientemente detallado para tomarlas. Esto, obviamente, provocó problemas de colaboración entre los equipos del proyecto durante las fases BD y DD. Debido al método de cascada de decisiones de "Aprobar/No Aprobar" al final de cada fase, el equipo técnico debía realizar una solicitud de cambio formal para corregir las secciones detalladas del Diseño Básico. Estos cambios solían resultar confusos para el cliente, ya que provenían del equipo del proyecto y no directamente de sus requisitos, incluso después de haber establecido una congelación de cambios . Por lo general, al cliente solo se le permitía presentar requisitos hasta el diseño funcional inclusive en la fase BD. Posteriormente, el cliente debía 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 "Diseño Global" para indicar que este documento se actualizaba continuamente y estaba sujeto a cambios durante las fases de Diseño Básico (DB) y Diseño Detallado (DD). De esta manera, el "Diseño Básico" es global y, al final del proyecto, detallado. En el diseño global, se documentan los principios de funcionalidad y construcción, así como sus interrelaciones. Así surgió la idea del desarrollo iterativo: un diseño funcional está influenciado por la plataforma tecnológica elegida para su implementación, y algunas decisiones de diseño básicas deberán revisarse cuando las suposiciones iniciales resulten erróneas o costosas de implementar. Esto sentó las bases del método de Desarrollo Rápido de Aplicaciones (RAD), que hizo que estas dos fases se volvieran cíclicas y trabajaran en conjunto.

SDM2 solo resolvió parcialmente el problema de satisfacer los requisitos del cliente; los métodos modernos de desarrollo de software van mucho más allá, insistiendo, por ejemplo, en entregas incrementales o en que el cliente designe a usuarios clave del sistema entregado para que participen en el proyecto de principio a fin.

En esta fase, se definen los problemas que el proyecto debe resolver. Se analizan la situación actual y la deseada, y se establecen los objetivos del proyecto. En esta fase, es importante considerar las necesidades de todas las partes involucradas, como los futuros usuarios y su equipo directivo. A menudo, sus expectativas chocan, lo que puede generar problemas posteriormente durante el desarrollo o el uso del sistema.

En esta fase, se realiza un estudio más profundo del proyecto. Se analiza la organización para determinar sus necesidades y el impacto del sistema en la misma. Se discuten y definen los requisitos del sistema. Se determina la viabilidad del proyecto. Algunos aspectos que se pueden considerar para determinar la viabilidad son:

• Recomendable: ¿Se dispone de los recursos (tanto de tiempo como de conocimientos) necesarios 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: ¿Son los costes de desarrollo del sistema inferiores a los beneficios obtenidos al utilizarlo?
• Organización: ¿Podrá la organización utilizar el nuevo sistema?
• Aspectos legales: ¿El nuevo sistema entra en conflicto con las leyes vigentes?

En esta fase se realiza el diseño del producto. Tras el estudio de definición, que determina las funciones del sistema, el diseño define cómo se llevarán a cabo. Esto suele dar como resultado dos documentos: el diseño funcional , o diseño de interfaz de usuario, que explica la función de cada parte del sistema, y ​​el diseño técnico de alto nivel, que explica el funcionamiento de cada parte del sistema. Esta fase combina el diseño funcional y el técnico, y proporciona un diseño general del sistema. A menudo, en esta etapa 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.

En esta fase, el diseño del producto se describe técnicamente con la jerga necesaria para los desarrolladores de software (y posteriormente, para el equipo responsable del soporte del sistema en la fase de operación y mantenimiento). Una vez aprobado el diseño básico, el diseño técnico detallado determina cómo se desarrollará mediante software. Esto suele dar como resultado una biblioteca de documentación fuente: el diseño funcional para cada función y el diseño técnico para cada función, que explican cómo funcionará cada parte del sistema y cómo se relacionan entre sí.

En SDM2, esta fase profundiza en el Diseño Global mediante la creación de diseños más detallados, o bien perfeccionando los diseños detallados ya existentes, hasta el punto en que puedan utilizarse para construir el propio sistema.

En esta fase, el diseño se convierte en un sistema funcional. La forma de hacerlo dependerá del sistema utilizado. Mientras que en los sistemas antiguos los programadores solían tener que escribir todo el código, los sistemas más modernos les permiten convertir el diseño directamente en código, lo que reduce la carga de trabajo y la probabilidad de errores. Sin embargo, el sistema se vuelve más dependiente del diseño: si este se ha probado correctamente, se generará el código adecuado; pero si el diseño no es del todo correcto, el código será incorrecto si no hay un programador que detecte dichos problemas.

La fase de implementación o de pruebas 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— lo prueba. La mayor parte de la prueba se centra en los aspectos técnicos: ¿funciona el sistema correctamente o persisten errores? Los errores detectados en esta fase se corregirán. Al finalizar esta fase, el programa debería funcionar correctamente.

Durante la prueba de aceptación, los usuarios finales probarán el sistema. Comprobarán si el programa funciona como se espera de ellos. No probarán todos los escenarios posibles, sino que verificarán que el programa cumpla con sus expectativas y que funcione de forma sencilla. Los errores detectados en esta fase se comunicarán al equipo de desarrollo para que puedan corregirlos.

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 para el usuario final y se capacita a los usuarios finales para usar el programa, introduciendo los datos existentes en el sistema.

Una vez implementado, el sistema se utiliza dentro de la organización. Durante su vida útil, es necesario mantenerlo en funcionamiento y, posiblemente, mejorarlo.