Hay un gran número de factores que repercuten en la persona que trabaja dentro de un entorno de desarrollo software. Los cambios en el sistema operativo, el lenguaje de programación, la organización del proyecto, o los estándares establecidos para los diferentes aspectos del ciclo de vida de un proyecto pueden influir tanto en el trabajador como en la cantidad de trabajo que puede realizar.
La productividad, cómo una medida cuantitativa de la cantidad de trabajo que puede ser realizada por una persona, se puede alterar de distintas maneras, alguna de ellas tan simple como, por ejemplo, enseñar a todos los implicados en el trabajo a escribir a máquina. Este hecho, sin ir más lejos, podría tener un mayor impacto en la productividad que el de introducir unas nuevas herramientas software o técnicas de diseño.
Sin embargo la productividad no tiene en consideración la calidad del producto. Por ejemplo los trabajadores en una planta de ensamblaje de ordenadores pueden producir 100 ordenadores por hora, pero esta medida no es útil, en cuanto que los ordenadores pueden requerir trabajo adicional para corregir problemas surgidos en la etapa del ensamblaje. Lo mismo ocurre en el desarrollo de software, el objetivo es establecer un entorno que no sólo mejore la productividad del que lo desarrolla, sino que también genere la creación de mejores productos.
Diferentes metodologías en la fabricación de coches.
En http://www.volvocars.es/ Volvo se adoptó una organización de equipo para la producción de coches, así como para mejorar la satisfacción del trabajador. Averiguaron que sus trabajadores podían trabajar conjuntamente de una manera efectiva, compartir responsabilidades y variar tareas. Mientras que en http://www.bmw.es/ BMW (Bayerische Motor Werke) se averiguó que tal organización no se podía aplicar a su entorno, dada la dificultad de comunicación entre los trabajadores. Tanto Volvo como BMW producen coches de las mismas características. Con la misma calidad y precios, pero diferencias en su personal les hacen emplear diferentes metodologías.
Es obvio que el elemento mas importante en cualquier empresa de desarrollo de software es disponer de personas con una elevada cualificación, y sin embargo ello no asegura el éxito en la consecución de los objetivos propuestos, ya que existe el peligro de una falta de conjunción, producida por la manera personal de desarrollar el software de cada individuo, por muy bueno que este sea, y la imposibilidad de un auténtico trabajo en equipo.
El Modelo de Madurez, viene a indicarnos que los mejores informáticos necesitan un entorno disciplinado y estructurado en el cual puedan realizar un trabajo en equipo, para lograr unos productos con alta calidad.
El ingeniero de software es una persona que trabaja en equipo, que conoce que lo que el realiza es un componente que se combinar con otros para formar un sistema. Es consciente de que el componente software que diseña debe poseer los principios de la Ingeniería del Software para que el sistema final sea satisfactorio.
Los programadores tradicionales argumentan que la aplicación de una metodología supone una gran carga. Es cierto, pero si no se emplea una metodología pueden surgir los siguientes problemas:
~- Resultados impredecibles
~- Detección tardía de errores
~- La introducción de nuevas herramientas afectará perjudicialmente al proceso
~- Cambios de organización también afectarán al proceso
~- Resultados distintos con nuevas clases de productos
que pedo
La situación actual se debe ver como una situación en la que la empresa que comience a poner los elementos necesarios para mejorar el proceso software tendrá mucha más ventaja competitiva frente a las demás
El modelo de métodos formales
Este http://research.nianet.org/~munoz/espanol.html modelo acompaña a un conjunto de actividades que conducen a la especificación matemática del software. Los http://www.ual.es/~jjcanada/2001_02/mfis/#Apuntes métodos formales permiten que un ingeniero especifique, desarrolle y verifique un sistema aplicando una notación rigurosa y matemática. Hay una variación, que se utiliza por algunos ingenieros de software, se conoce como "ingeniería del software de sala limpia".
Cuando se utilizan métodos formales, se eliminan muchos de los problemas que son difíciles de superar con las metodologías habituales. La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más facilmente, mediante la aplicación del análisis matemático.
Esta forma de crear software ofrece un producto libre de defectos. Sin embargo se ha difundido poco, por ser caro de desarrollar, requerir bastante tiempo y es dificil de comunicar a clientes sin muchos conocimientos técnicos.
El mundo industrial empieza a cambiar de actitud frente a los métodos formales. Son varias las razones, por una parte, los lenguajes de especificación son cada vez más cercanos a los lenguajes de programación, las técnicas se acomodan mejor a los nuevos paradigmas de desarrollo (orientación por objetos o computación distribuida son ejemplos notables) y herramientas comerciales de calidad que soportan dichos métodos se consiguen en el mercado. Estas no son todas las razones. A medida que los sistemas informáticos crecen en complejidad, las perdidas causadas por fallos en dichos sistemas son cada vez mayores. Cuando "corrección certificada" se traduce en dinero, los métodos formales atraen a la industria.
Dos conocidos ejemplos ilustran este último punto. En 1995, un profesor de matemáticas de la universidad de Lynchburg descubrió un error en los procesadores Pentium de la compañía Intel. Aunque Intel corrigió rapidamente el error y se comprometió a reemplazar los procesadores, el daño ya estaba hecho. Cerca de dos millones de procesadores defectuosos habían sido distribuidos. El fallo: un error de diseño en el algoritmo de división de punto flotante. Apenas un año después, la explosión de la nave espacial europea Ariane 5, 40 segundos después de su lanzamiento, nos volvió a recordar que los sistemas informáticos no son infalibles. Los informes oficiales indican que la perdida alcanzó los 500 millones de dolares. La comisión de expertos que investigó el desastre concluyó que el fallo, un número fuera de rango, se produjo en una pedazo de código heredado del sistema de Ariane 4. Lo irónico del caso, es que este código no tenía ninguna utilidad en el nuevo sistema.
