El tamaño de los problemas resueltos por software ha ido evolucionando desde los pequeños hasta los muy grandes, y este cambio de escala ha traído importantes cambios de complejidad, que, por un lado, afectan sin duda a las técnicas, pero que van mucho más allá y comprenden desde la naturaleza misma de los problemas, hasta la variedad multidisciplinar de los aspectos y áreas involucrados en los procesos DDE.
Años 60: Programación a pequeña escala: Programas comprensibles. Uso de lenguajes de alto nivel.
Años 70: Programación a gran escala: Persisten las dificultades de la programación a pequeña escala, a las que se une un incremento del orden de magnitud de la complejidad. Necesidad de organizar largos proceso de desarrollo. Herramientas.
Años 80 y 90: Programas-componentes de sistemas heterogéneos y Programas-delegados: Se construyen piezas de software integrables en sistemas formados por toda clase de componentes físicos y humanos, diferentes lenguajes, constricciones temporales o materiales, etc. Porciones creativas del proceso del desarrollo y control de los sistemas de software son delegadas en ciertas funciones de software.
En los primeros años de los 80, cuando estaba en pleno auge la programación a gran escala y cuando ya se aceptaba que era necesario desarrollar y potenciar un conjunto de técnicas agrupadas bajo la denominación de “Ingeniería del Software”, se hizo una encuesta muy completa para resaltar la importancia de su parcela gerencial (management). Los resultados se publicaron en un informe y diversos artículos con el título de “El reto de la gestión de proyectos de ingeniería del software (S.E.P.M.: Software Engineering Project Management). Algunos de los problemas al tiempo más importantes y para las que los responsables de proyectos se sentían más desasistidos fueron:
- Definir requisitos del sistema
- Establecer criterios de éxito en el proceso de desarrollo
- Planificar proyectos de desarrollo
- Estimar costes
- Definir calendario de actividades
- Fijar estructura de rendición de cuentas y responsabilidades
- Seleccionar jefes de proyectos o subproyectos
- Establecer (definir, elegir) técnicas de control de fiabilidad del software
- Establecer (definir, elegir) técnicas y estándares de medida de la cantidad/calidad de producción de programadores y analistas.
Modelo CMM
El Capability Maturity Model es una norma de calidad y experiencia técnica y de gestión de los equipos y organizaciones dedicadas al desarrollo de software. Ha sido elaborado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (U.S.A.). Sólo a partir del nivel 2 puede decirse que se entra en un nivel de profesionalidad. En U.S.A., para conseguir contratos de desarrollo con departamentos de la Administración es imprescindible que las empresas o equipos aspirantes tengan reconocido un nivel especificado del CMM.
Código ACM de ética y práctica profesional
Creemos que todo ingeniero de software debería leer este código y reflexionar sobre él. El código ACM/IEEE-CS, elaborado, tras muchas reuniones, consultas y versiones, por un selecto grupo de profesionales convocados por las dos sociedades profesionales más importantes, contiene 8 principios deontológicos, que desarrollan una serie de puntos cada uno de ellos. El código no tiene ningún poder regulador, su fuerza reside en su aceptación práctica como guía de sus actividades por parte de los profesionales de estas técnicas.
Fíjese el lector que incluso el apartado de Gestión contiene aspectos relacionados con la ética.
No hay comentarios:
Publicar un comentario