Factores económicos y Humanos de la Ingeniería de Software

Complejidad del Software

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.

Link:http://api.ning.com/files/1hjSKWZVcZyhHIsOcGjfdtCPcvLP62Kc1WQDxB2HOxLZbIGdcFfItBxWQtIcb5BCAjSSxJDATqjBKBzDwbgpxIPpE62MTWMI/ingenieria_del_software_factores_economicos_y_humanos.pdf

Factores económicos y Humanos de la Ingeniería de Software

Software Capital Intelectual de la empresa

Hoy, más que nunca, la economía más productiva depende de la infraestructura y los sistemas técnicos. Dentro de este panorama, la infotecnología, por ella misma y por su papel instrumental en las demás tecnologías, juega un rol principal. Y dentro de la infotecnología, el software siempre está presente.

Hay una forma brutal de comprender esta función, mirando su lado oscuro, observando por ejemplo lo que sucede cuando alguna pieza de software, por error, avería o sabotaje, decae bruscamente, falla, se interrumpe o se bloquea. Las consecuencias económicas pueden ser muy importantes, cuando no desastrosas, valorables en miles de millones de dólares en todo el mundo, monto que no hace más que aumentar debido a la creciente capilaridad de la informática.

Pero, más allá del plano económico, lo peor es que, a veces, las consecuencias afectan a una parte más general del flujo de actividades sociales, incluyendo pérdidas de vidas humanas, lo que demuestra la trascendental clase de rol que juega el software en las sociedades desarrolladas. 

el conjunto de conocimientos precisos para desarrollar software es algo difícilmente disponible y por ello el proceso de acopiarlo, estructurarlo e implementarlo es un proceso de descubrimiento y de diálogo, es decir, de aprendizaje. No es éste un proceso individual, sino un entramado de procesos individuales, porque interviene mucha gente con diferentes intereses y especialidades, trabajando generalmente en grupos, que intercambian conocimientos, aprendiendo unos de otros.

• Se requiere un diálogo entre el equipo de diseño y los usuarios, entre otras cosas para descubrir y definir los requisitos. Es preciso que los usuarios se apliquen a comprender mejor lo que necesitan.

•

Planteando que el diseño mismo ha de ser evolutivo, debería haber un diálogo entre el equipo de diseño y el diseño propiamente dicho, lo mismo que entre los usuarios y el diseño 

Los desarrolladores deben trabajar para comprender mejor cómo construir sus sistemas de forma efectiva.

•

El aprendizaje se potencia en la medida en que las herramientas de desarrollo ayuden a diseñadores y programadores a comprender mejor lo que están haciendo. Estas herramientas deberían estar construidas como herramientas para pensar.

•

Al mismo tiempo, se requieren herramientas que contribuyan al proceso de comunicación interpersonal, puesto que estamos comprometidos en un proceso social de aprendizaje o construcción colectiva de conocimiento.

Desde un punto de vista económico, mantener software significa aportar esfuerzos (costes) para conservar y, si es posible, acrecentar el valor de este bien de capital. Pero dado que, como se dijo, la estructura del capital de producción cambia constantemente, el diseño de bienes de capital debe evolucionar para encajar con las nuevas estructuras del capital, y, aún mejor, debería contener el embrión de los cambios previsibles. Esta estrategia del embrión es imprescindible para minimizar los esfuerzos (tiempo, costes) necesarios para hacer evolucionar el software.

En el caso del software, una parte importantísima de la estructura de capital es la tecnología conexa: sistemas operativos, plataformas de hardware, capacidades de red, otros sistemas y herramientas de software, los progresos de orden metodológico, etcétera. Sus cambios implican un cambio del entorno propio del ciclo de vida del software. Así, el cambio del software es coevolutivo con su entorno propio y en buena medida es impredecible. Tome nota el lector de que un peligro difícil de evitar es el de buscar la optimización del software desarrollado con respecto a algún apartado muy concreto del entorno, por ejemplo, el sistema de gestión de base de datos. Tal proceder puede ir en contra de la evolutividad de este software, teniendo en cuenta que el software es un bien duradero, de desarrollo lento y muy costoso.

Link:http://api.ning.com/files/1hjSKWZVcZyhHIsOcGjfdtCPcvLP62Kc1WQDxB2HOxLZbIGdcFfItBxWQtIcb5BCAjSSxJDATqjBKBzDwbgpxIPpE62MTWMI/ingenieria_del_software_factores_economicos_y_humanos.pdf

Historia de la gestión de Proyectos

En la década del 50 no se tenía metodología. La computación era incipiente. Neos diferenciaba bien entre software y hardware. Esta situación continúo hasta comenzada la siguiente década

En la década del 60 ocurre la primera gran crisis de la gestión de proyectos de software: la crisis del OS/360. La nueva línea de computadores de IBM, la líneas/360 planteo, por primera vez. La realización de un paquete de programación de tamaño mediano. Hasta este momento puede decirse que todos los proyectos eran pequeños, o si bien eran medianos se habían hecho en ambientes universitarios sin preocuparse por plazos y costos.

Con el sistema operativo de /360 IBM desborda todos los plazos y costos imaginables. De este primer gran atraso (que no fue el único atraso en la entrega de software,) nace la gestión de proyectos.

La década del 70 se caracteriza por la realización de los grandes estudios empíricos. La difusión de las computadoras y la aparición de las minicomputadoras hacen que se disponga de muchos proyectos medianos y grandes. Con todo este material empírico se hacen gran cantidad de estudios. De estos estudios nacen modelos y metodologías

La década de 80 es el periodo de confrontación de los modelos e metodología con los grandes proyectos de software. Es paradojal, pero la difusión de las computadoras personales hace que los proyectos sean más complejos y exigentes. De todas estas tecnologías sobreviven solamente unas pocas de la confrontación con la realidad.

La década del 90, es la época de normalización de las metodologías. Ya se ha separado lo útil de la teórico, lo bueno de lo malo y se procede a normalizar las metodologías

Gestión de Proyectos

Tamaño de los proyectos

Los proyectos de software son diferentes por la sola razón de su tamaño. Por lo que existen tres categorías diferenciadas de proyectos con problemas diferentes cada una:

Proyectos pequeños: conciten solamente en implementación. No tienes costos indirectos importantes.

Proyectos grandes: posees implementación, pero hay más cosas. Poseen gerencia de proyecto, control de calidad, capacitación de personal, hay un plan de mantenimiento, hay documentación importante para uso interno y externo. Se genera información para mercadeo.

Proyectos medianos: es un caso intermedio entre los otros dos.

Un error clásico en la historia de la gestión de proyectos fue no advertir la existencia de tres categorías diferentes. Todavía hoy se sigue pensando que la información o la experiencia adquirida en proyectos pequeños pueden servir para proyectos medianos o grandes. Este es uno de los orígenes del los resultados catastróficos en la gestión de proyectos

Gestión de Proyectos de Software

Dentro de la Ingeniería la gestión o control de proyecto básicamente engloba las mismas características independientemente de la rama que se escoja o el ángulo desde el cual se mire, Los primero es determinar cual es el objetivo que es lo que queremos alcanzar con tales fines, y luego que ha finalizado, lo que se quiere es analizar que sucedió con el proyecto ya finalizado.

Y las preguntas o interrogantes numérica cuáles son? Las mismas básicamente para todos los casos. 

1.- En cuanto tiempo estará listo?

2.- Que personal y cuantos en total necesito?

3.- Cuanto me cuesta eso?

Ahora bien en el plano particular de la gestión de proyectos de software, es una rama de la ingeniería de Software, que posee su propia metodología además de la generales de la ingeniería normal.

Las gestiones dentro de un proyecto de software deben realizarse según el tipo de proyecto que se plantee, entre los cuales se encuentran:

Los proyectos nuevos: es por supuesto el más complicado por todo lo que implica un proyecto nuevo.

Replanteo de proyectos viejos: se busca corregir y actualizar la metodología de estimación.

Extensión o ampliación de un proyecto existente: para esta tipo de proyecto lo que se busca es tener buena precisión entre costos y plazos de ejecución.