Conceptos extra usados en la ingeniería de software

1. Temas Extra de Ingeniería de Software

2. El Principio de Pareto (80-20) Pareto observó que la gente en su sociedad se dividía naturalmente entre los “pocos de mucho” y los “muchos de poco”; se establecían así dos grupos de proporciones 80-20, tal que el grupo minoritario (formado por el 20% de la población) tenía el 80% de algo, y el grupo mayoritario (el 80% restante) el 20% de ese mismo algo. Estas cifras son arbitrarias; no son exactas y pueden variar. 2

3. Principio de Pareto (2) Cuando se habla de los costos de desarrollo se puede decir que “el 80% del esfuerzo de desarrollo (en tiempo y recursos) produce el 20% del código, mientras que el 80% restante es producido con tan solo 20% del esfuerzo”. Cuando se habla de pruebas, el principio dice que “el 80% de los fallos es generado por el 20% del código, mientras que el otro 80% genera tan solo un 20% de los fallos”. “El 80% del tiempo solo se ejecuta el 20% del código”. 3

4. Principio de Pareto (3) Este principio también explica por qué las aplicaciones que parecen casi terminadas se demoran al final del proyecto, cuando solo faltan por resolver los cabos sueltos que siempre se dejan para el final: lo que más cuesta en una aplicación no es construir el esqueleto, sino pulir los detalles. 4

5. Principio de Pareto (3) Esto puede jugar a nuestro favor, ya que podemos desarrollar primero las partes más útiles del sistema, con un 20% del esfuerzo ya se puede ver si el diseño está bien hecho y si la aplicación es realmente lo que el cliente necesita. Si hay que hacer cambios en el diseño o en los requisitos, cuanto antes se definan estos cambios serán más útiles y costará menos implementarlos. 5

6. Principio de Pareto (4) Esto también tiene sus aspectos negativos, como el hecho de que el 20% del presupuesto total del proyecto durante todo su ciclo de vida se gaste en desarrollo, mientras el 80% se gaste en mantenimiento post-entrega. Es debido a esto que hay que poner énfasis en que se reduzcan gastos en la parte del mantenimiento del sistema. 6

7. La Ley de Miller (el mágico número 7) En 1956, George A. Miller, un profesor de psicología, publicó un ensayo que tenía su base de investigación en los límites de nuestra capacidad para procesar información, que encontramos dentro de los rangos de la memoria a corto plazo Miller mostró que nuestra memoria a corto plazo presenta una capacidad de almacenamiento limitada, en cualquier momento los humanos podemos procesar 7±2 chunks(unidades de información). 7

8. La Ley de Miller (2) Un artefacto de software común tiene mucho más de siete chunks. Por ejemplo, un artefacto de código puede tener más de siete variables, y tal vez un documento de requerimientos tenga muchos más de siete requerimientos. 8

9. La Ley de Miller (3) Una forma en la que podemos manejar esta restricción sobre la cantidad de información, es el uso de depuración paso a paso, es decir, nos concentramos en aquellos aspectos que actualmente son más importantes, y posponemos los que por ahora son menos cruciales. 9

10. La Ley de Miller (3) Comenzamos construyendo un artefacto que soluciona una pequeña parte de lo que estamos intentando lograr. Después, consideramos otros aspectos del problema, y anexamos las nuevas piezas resultantes al artefacto existente. Por ejemplo, podríamos construir un documento de requerimientos tomando en cuenta los siete que, a nuestro juicio, son más importantes. 10

11. Modelo de Incapacidad de Inmadurez Hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM (producen software de modo heroico), proponiendo que existen niveles negativos o de inmadurez. Este “Modelo de Incapacidad e Inmadurez” incluye cuatro niveles de idiotez 11

12. Nivel 0 - Negligencia La organización presume de estar de acuerdo, algunas veces con exceso de fanfarria, en la implementación de procesos de ingeniería de software, pero carecen de la voluntad necesaria para llevar a cabo los esfuerzos necesarios 12

13. Nivel 0 – Negligencia (2) Mientras que el nivel 1 de CMM asume que eventualmente se tendrá éxito en desarrollar software, las organizaciones en el nivel 0 de CIMM generalmente fallan al producir cualquier producto, o lo hacen abandonando los procesos regulares, a favor del cowboy programming 13

14. Nivel -1 - Obstrucción Se implementan procesos, inapropiados e ineficientes, rigurosamente y tienden a obstruir el trabajo. La adherencia al proceso es la medida de éxito para las organizaciones de nivel -1. No se evalúa la calidad del producto debido a la suposición de que si se sigue el proceso, se asegura un alto grado de calidad. 14

15. Nivel -2 - Desdén Desprecian cualquier institucionalización de buenas prácticas. Aunque existe un proceso, es ignorado rutinariamente por el equipo de desarrollo y aquellos encargados de observar que el proceso se siga sin mirados con hostilidad. Las mediciones son manipuladas para hacer que la organización se vea bien 15

16. Nivel -3 - Neutralización No contentas falsificar sus propios resultados, este tipo de organizaciones trabaja rutinariamente para minimizar y sabotear los esfuerzos de organizaciones rivales, especialmente aquellas que han implementado con éxito procesos de CMM nivel 2 o superior 16

17. Temas de Ética Los productos de software son creados y mantenidos por humanos. Si estos individuos son trabajadores, inteligentes, sensibles, están actualizados y, sobre todo, tienen ética, entonces hay buenas probabilidades de que los programas que producen y mantienen sean satisfactorios. Por desgracia, lo contrario también es cierto. 17

18. Temas de Ética (2) Algunas sociedades tienen un código de ética para los profesionales, al cual se deben apegar todos sus miembros. La ACM y la IEEE-CS aprobaron de manera conjunta un código de ética y práctica profesional para la ingeniería de software como el estándar para enseñar y practicar la ingeniería de software. 18

19. Preámbulo de la versión corta La versión abreviada del código resume las aspiraciones a un nivel de abstracción elevado; las clausulas que se incluyen en la versión completa dan ejemplos y detalles de cómo estas aspiraciones cambian el modelo en que actúan los ingenieros en software profesionales. Sin las aspiraciones, los detalles pueden volverse legales y tediosos; las aspiraciones solas pueden sonar muy bien, pero estar vacías; juntos, aspiraciones y detalles, forman un código cohesivo. 19

20. Preámbulo de la versión corta (2) Los ingenieros en software deben comprometerse a hacer del análisis, la especificación, el diseño, el desarrollo, la prueba, y el mantenimiento del software una profesión benéfica y respetada. De acuerdo con su compromiso con la salud, la seguridad y el bienestar del público, los ingenieros en software se deben apegar a los siguientes 8 principios 20

21. Principios Sociedad. Los ingenieros de software actuarán de forma congruente con el interés social. Cliente y Empresario. Los ingenieros de software actuarán de manera que se concilien los mejores intereses de sus clientes y empresarios, congruentemente con el interés social. 21

22. Principios (2) Producto. Los ingenieros de software asegurarán que sus productos y modificaciones correspondientes cumplen con los estándares profesionales más altos posibles Juicio. Los ingenieros de software mantendrán integridad e independencia en su juicio profesional. 22

23. Principios (3) Administración. Los ingenieros de software gerentes y líderes promoverán y se suscribirán a un enfoque ético en la administración del desarrollo y mantenimiento de software. Profesión. Los ingenieros de software incrementarán la integridad y reputación de la profesión congruentemente con el interés social. 23

24. Principios (4) Colegas. Los ingenieros de software apoyarán y serán justos con sus colegas. Personal. Los ingenieros de software participarán toda su vida en el aprendizaje relacionado con la práctica de su profesión y promoverán un enfoque ético en la práctica de la profesión. 24

25. ¿Alguna Pregunta? 25

26. Gracias 26 http://www.javatutoriales.com/ Java Tutoriales en Facebook