Tres razones para documentar tu software Legacy
Disminuir sobre dependencia de personal clave
Las personas que desarrollaron la aplicación ya no están o no puede prescindir de ellas porque tienen todo el conocimiento
Acelerar la curva de aprendizaje
Al incorporar personas nuevas el equipo se disminuye el tiempo en transferir el conocimiento acortando el período de aprendizaje
Cumplimiento de políticas de riesgo
Los auditores de TI usualmente solicitan -documentación de las aplicaciones para evaluar los niveles de riesgo.
“El software es un activo que tiene embebido el conocimiento acerca de cómo operamos en nuestro negocio. Este activo puede transformarse en un riesgo cuando el conocimiento no se encuentra protegido”.
Francisco Petour G
Socio Fundador ARsum
Prof. Diplomado en Gestión de TI
Universidad de Chile
Para ver nuestra metodología, roadmap y perfil de los consultores / Arsum
El Rol del Arquitecto de Software
Este es un tema que se discute con frecuencia. Es difícil definir exactamente lo que hace un arquitecto de software, especialmente cuando se intenta definir un perfil de rol para un proyecto o para reclutamiento.
En el diagrama que referimos más abajo se destila lo que significa ser un arquitecto de software en un proyecto de software a medida y se desglosa el rol en una serie de grupos amplios, que son los diferentes aspectos del rol.
http://www.codingthearchitecture.com/files/role-profile-for-software-architects-v1.pdf
El Modelo de “4+1” vistas de la Arquitectura del Software
Philippe Kruchten, el autor de este modelo que utilizamos en ARsum, fue director de desarrollo de procesos en Rational Software, los creadores de la metodología RUP (Rational Unified Process) que más tarde fue adquirida por IBM.
El modelo “4+1” permite describir la arquitectura de sistemas de software, basándose en el uso de múltiples vistas concurrentes. Este uso de múltiples vistas permite abordar los intereses de los distintos “stakeholders” de la arquitectura por separado: usuarios finales, desarrolladores, ingenieros de sistemas, administradores de proyecto, etc. y manejar los requisitos funcionales y no funcionales separadamente.
Este documento es un buen resumen del modelo «4+1»: http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_1.pdf