Ingenieria de Software Permitan controlar la complejidad inherente a sistemas de mediana envergadura
Enviado por Erick Ramos Carbajal • 5 de Septiembre de 2015 • Monografía • 4.778 Palabras (20 Páginas) • 159 Visitas
Universidad Simón Bolívar
Sistemas de Programas
La Problemática del Desarrollo de Software de Mediana Envergadura y La Ingeniería de Software
Recordatorio: Objetivo del curso
Introducir al estudiante a la problemática y a aquellas técnicas de desarrollo de software de mediana envergadura representativas del enfoque disciplinado asociado con la Ingeniería de Software. Se
enfatizarán las técnicas de diseño y validación de sistemas de programas que:
- Incrementen la productividad del desarrollador de software;
- Permitan controlar la complejidad inherente a sistemas de mediana envergadura;
- Introducen al estudiante al desarrollo en equipos (teams).
¿Qué es software de mediana envergadura?
Podemos distinguir entre software de pequeña, mediana y gran envergadura:
- Un software es de pequeña envergadura si lo puede desarrollar un programador en unas pocas semanas de trabajo;
- Un software puede considerarse de mediana envergadura si su desarrollo involucra un equipo hasta 10 personas durante un tiempo medido en la escala de meses;
- Un software puede considerarse de gran envergadura si su desarrollo requiere de múltiples equipos de trabajo trabajando durantes varios años.
¿Cuál es el tamaño de un software de mediana envergadura?
Una forma más convencional de definir la envergadura de un software es por el número de líneas de código fuente que lo constituyen. El problema con tal definición es que en el tiempo, los límites de tamaño entre un tipo de software y otro, han ido variando a medida que han mejorado los procesos y las herramientas de apoyo al desarrollo de software. Actualmente hay autores que consideran que:
- Un software es de envergadura trivial si le lleva a un programador hasta un mes para desarrollar hasta 500 líneas de código (abreviadas como 500 LOC). Este es el tamaño típico de una asignación en un curso introductorio de programación.
- Un software es de envergadura muy pequeña si le lleva a un programador hasta cuatro meses para desarrollar del orden de 2.000 líneas de código (2 KLOC). Este es típicamente el tamaño de un software desarrollado como proyecto de laboratorio en la carrera.
- Un software es de envergadura pequeña si requiere hasta dos años del trabajo de unos tres programadores que terminan produciendo 50 KLOC. Este es el tamaño del software necesario para controlar una planta generadora de electricidad u operar un marcapasos.
- Un software es de envergadura mediana si consume tres años de esfuerzo a decenas de programadores para producir del orden de 100 LOC. Este es el tamaño de un compilador optimizante.
- Un software es de envergadura grande si consume cinco años de esfuerzo a cientos de programadores para producir del orden de 1 MLOC (un millón de líneas de código). Este es el tamaño de programas como Microsoft Word.
- Un software es de envergadura muy grande si consume diez años de esfuerzo a miles de programadores para producir del orden de 10 MLOC. Este es el tamaño estimado del software que se requiere para controlar el tráfico aéreo sobre los Estados Unidos o el desarrollado para apoyar al transbordador espacial de la NASA.
Si bien las definiciones más viejas en la literatura distinguen el tipo de envergadura de un software netamente por el tamaño de su código fuente, es decir por el tamaño del producto entregado, las distinciones más recientes introducen, como acabamos de ver, alguna medida del esfuerzo o complejidad que requiere su proceso de desarrollo. En general, en cualquier actividad de Ingeniería se distingue claramente entre productos y procesos.
¿Por qué necesitamos distinguir la envergadura de un software?
El desarrollo de un software de un tipo de envergadura u otra presenta diferencias cuantitativas y, más críticas aún, diferencias cualitativas características. Por ejemplo, a medida que crece la envergadura del software a desarrollar, crecen las dificultades gerenciales para coordinar el esfuerzo de los participantes y controlar la complejidad del desarrollo.
Considere desarrollar un programa relativamente trivial como el que cuenta el número de elementos estrictamente positivos en una matriz bidimensional. Por más que, por razones pedagógicas, insistamos que tal desarrollo debe hacerse de manera formal y disciplinada, la mayoría de los programadores de experiencia se sentarán directamente ante el teclado y pantalla de su computador y creará, improvisadamente, este programa. Además, la mayoría de las veces tal programa será correcto y eficiente. Ahora, en contraste, considere desarrollar un software de más de cien mil líneas de código, como podría ser el software que controla una red nacional de cajeros automáticos. Sentarse ante un computador para improvisar una solución no es más que una receta segura para el desastre.
En todas las disciplinas de Ingeniería, la escala del producto produce cambios cualitativos en el proceso de desarrollo. No es lo mismo colocar un madero sobre un charco para cruzarlo, que diseñar, construir y mantener un puente sobre veinte kilómetros de mar abierto.
Diferencias cualitativas en el desarrollo de software pequeño y mediano
En un fascinante catálogo, Capers Jones discute 60 factores de riesgo en el desarrollo de software (Assessment and Control of Software Risks, Prentice-Hall, 1994): estimo que menos de cinco de esos factores aplican al desarrollo de software pequeño.
Entre los factores críticos en el desarrollo de software (comercial) podemos mencionar:
- Relevancia empresarial
El desarrollo de software está condicionado y restringido por metas de negocio. E. Yourdon comentó que existen compañías que dedican 1-2% de su presupuesto a unos recursos computacionales que son críticos para su éxito, a tal grado que un desarrollo o funcionamiento inadecuado puede amenazar seriamente su viabilidad o llevarlo a la quiebra. En este sentido el caso de Montreal Life Insurance es instructivo. Más recientemente, durante el año 2000, se produjo una seria ola de quiebras y recortes de las llamadas empresas punto com, debido en gran parte a discrepancias entre su desarrollo de productos y servicios de software y las realidades del mercado. Este ola alcanzó varias empresas venezolanas, incluyendo Intesa, la empresa mixta formada entre PDVSA y SAIC.
**Toda disciplina de Ingeniería estudia la elaboración de artefactos útiles sujeto a restricciones de recursos
- Ingeniería de requerimientos
¿Quién quiere el software? ¿Para qué lo quiere? ¿Qué debe hacer el software? ¿Hay restricciones sobre cómo debe funcionar el software? La Ingeniería de Requerimientos, que forma parte de la Ingeniería de Software, aborda uno de los aspectos más problemáticos del desarrollo de software: la elicitación, análisis y manejo de los requerimientos que debe satisfacer el software. Tome en consideración que los requerimientos de sistemas de cierta envergadura cambian a un promedio de 1% mensual en el período de desarrollo de un proyecto: así, al finalizar un proyecto de tres años, la tercera parte de los requerimientos surgieron durante el desarrollo mismo.
- Manejar la complejidad y envergadura del desarrollo
¿Cuál es la arquitectura más apropiada para el producto? ¿Cómo se puede descomponer el desarrollo para poder repartirlo entre varios desarrolladores? ¿Cómo garantizamos que los componentes desarrollados independientemente, calcen juntos? ¿Cuánto tiempo falta por terminar? ¿El producto tiene un nivel de calidad aceptable? ¿El diseño escogido será suficientemente flexible? ¿Los tiempos de respuesta son apropiados? ¿Cabrá el código en la memoria disponible? En software pequeño estas preguntas no surgen o tienen a lo sumo un interés académico; en software de mayor envergadura un proyecto en que se pierda el control del desarrollo puede amenazar la viabilidad de las empresas participantes. Un ejemplo de los problemas en que puede incurrir una empresa lo proporciona la otra empresa líder en reservaciones aéreas computariizadas, American Airlines, en el desarrollo del sistema de gestión de viajes Confirm.
- Soporte y mantenimiento
Tres años despues de entregado el software, ¿quién puede responderme por qué falla baja ciertas circunstancias, el sistema de control de tráfico aéreo sobre un aeropuerto internacional? ¿Quién corrige ese software? ¿Dónde están documentadas las decisiones de diseño? ¿Cómo puedo estar seguro que si modifico estas líneas de código de esta manera, no introduzco una nueva falla? Un software exitoso tiene una vida de al menos tres años y, con las modificaciones apropiadas, puede facilmente alcanzar de siete a veinte años de uso. ¿Se imaginan tener que actualizar un software de un cuarto de millón de líneas de código que tiene componentes con más de diez años en servicio y del cual depende en forma crítica una empresa con más de dos mil empleados? Considere la siguiente estadística: entre el 50 y 80% del costo de desarrollo del software comercial se incurre durante su mantenimiento, es decir, despues de su primera entrega.
En este curso vamos a concentrarnos en eliminar cuatro simplificaciones que sólo son válidas para el desarrollo de software pequeño y que están relacionados con los factores 2 (Ingeniería de requerimientos) y 3 (Manejar la complejidad y envergadura del desarrollo):
- El enunciado de lo que debe hacer un programa es cerrado y preciso;
- Un software es pequeño y relativamente auto-explicativo;
- Cualquier sistema de software puede desarrollarse por una persona;
- Desarrollar un software es equivalente a desarrollar un programa basado en un algoritmo que utiliza una pocas estructuras de datos.
En las próximas secciones analizaremos cada una de estas simplificaciones.
...