1. Metodologías de Análisis Clase 2 - 22/8/2007 Christian Sifaqui

2. Repaso mantención post-entrega 75% requerimientos/análisis 18% desarrollo 25% implementación/codificación 34% diseño 19% integración 29% Costos totales Detalle costos de desarrollo

3. Repaso Mientras más temprano se detecte y corrija un error, menos costoso será

4. Repaso Robert L. Glass dijo que "maintenance is one of the toughest tasks in the software business.“ - intellectually complex (it requires innovation while placing severe constraints on the innovator) - technically difficult (the maintainer must be able to work with a concept and a design and its code all at the same time) - unfair (the maintainer never gets all the things the maintainer needs. Take good maintenance documentation, for example)

5. Repaso - no-win (the maintainer only sees people who have problems) - dirty work (the maintainer must work at the grubby level of detailed coding) - living in the past (the code was probably written by someone else before they got good at it) - conservative (the going motto for maintenance is "if it ain't broke, don't fix it")

9. Repaso Testing: durante todo el desarrollo del proyecto

10. Repaso Testing: durante todo el desarrollo del proyecto grupo SQA

15. Repaso Resumen: Planificación, testing y documentación se realizan durante todo el proyecto

16. Repaso Hasta 1975 no habían técnicas específicas de desarrollo. De 1975 a 1985 se desarrolló el paradigma estructurado. análisis estructurado análisis de flujo de datos programación estructurada testing estructurado Pero estas técnicas no fueron eficaces con el tamaño creciente de los productos de software (no escalan) En vez de decrementar la mantención, la mantuvo y ésta se ha incrementado

17. Repaso El paradigma clásico está orientado a la operación o al atributo (dato) pero no a ambos. Técnicas como análisis de flujo de datos están orientadas al a la operación. Técnicas como el desarrollo de sistemas de Jackson están orientadas al atributo. La OO considera a ambos importantes.

18. Repaso Paradigma clásico Paradigma OO ocultamiento de la información diseño impacto en mantención y desarrollo mensaje girar ver_saldo depositar mensaje mensaje cuenta corriente girar ver_saldo cuenta corriente depositar

19. Repaso Debiera mejora la mantención post-entrega: - en el paradigma clásico un cambio en una componente (dato o método) podría afectar a todos los módulos que tienen relación con ésta con OO sólo se afecta al objeto que tiene el conocimiento de esta componente - debiera hacer el desarrollo más fácil, ya que habría correspondencia entre objetos reales y objetos de software - objetos bien diseñados son unidades independientes (encapsulación)

20. Repaso Debiera mejora la mantención post-entrega: - un producto (usando OO) es una agrupación de unidades pequeñas e independientes reduciendo así la complejidad, por el contrario un producto (usando paradigma clásico) es un conjunto de módulos que conforman una sola unidad, lo que no escala - la OO debería promover la reutilización de los objetos, debido a su naturaleza independiente, reduciendo tiempo y costos tanto en desarrollo como en mantención

21. Repaso Al utilizar OO se debe modificar el ciclo de vida cascada. Diferencias: Paradigma clásico Paradigma OO 1.- Fase de requerimientos 1.- Workflow de requerimientos 2.- Fase análisis (especificación) 2.- Workflow de análisis OO 3.- Fase diseño 3.- Workflow diseño OO 4.- Fase implementación 4.- Workflow implementación OO 5.- Mantención post-entrega 5.- Mantención post-entrega 6.- Retiro 6.- Retiro No hay correspondencia entre fases y workflows

22. Repaso Al usar el paradigma clásico hay una clara separación entre la fase de análisis (qué) y de diseño (cómo). Al usar OO los objetos entran a un ciclo de vida desde el inicio, se extraen en el workflow de análisis, se diseñan en el workflow de diseño y se codifican en el workflow de implmentación, la transición es más suave.

23. Repaso Paradigma clásico: Análisis Determinar qué es lo que hay que hacer Diseño Determinar cómo hacerlo Diseño arquitectónico – determinar los módulos Diseño detallado – diseñar cada módulo

24. Repaso Paradigma OO: Análisis OO Determinar qué es lo que hay que hacer Determinar los objetos Diseño OO Determinar cómo hacerlo Diseñar los objetos

26. Repaso Bug  “ A bug crept into the code” en vez “ I made a mistake”

27. Repaso Bug  ¿Egoless programming? Pro: Psychology of Computer Programming (Weinberg 1971) Con: Facts and Fallacies of Software Engineering (Robert Glass 2002)

28. Ser humano El problema humano es la comunicación. “ Human beings as living systems operating in language operate in a domain of recursive reciprocal consensual perturbations that constitutes their domain of existence as such. Therefore, language as a domain of recursive consensual coordinations of actions is a domain of existence, and, as such, a cognitive domain defined by the recursion of consensual distinctions in a domain of consensual distinctions. Furthermore, human beings as living systems operating in language constitute observing, and become observers, by bringing forth objects as primary consensual coordinations of actions distinguished through secondary consensual coordinations of actions in a process that obscures the actions that they coordinate. Human beings, therefore, exist in the domain of objects that they bring forth through languaging. At the same time, human beings by existing as observers in the domain of objects brought forth through languaging, exist in a domain that allows them to explain the happening of their living in language through reference to their operation in a domain of dynamic reciprocal structural coupling.”

29. Ser humano “ Languaging: operation in a domain of structural coupling. To the extent that language arises as a consensual domain in the coontogenic structural drift of living systems involved in recurrent interactions, the organisms that operate in language operate in a domain of reciprocal coontogenic structural coupling through reciprocal structural perturbations. Therefore, to operate in language is not an abstract activity as we usually think. To language is to interact structurally. Language takes place in the domain of relations between organisms in the recursion of consensual coordinations of consensual coordinations of actions, but at the same time language takes place through structural interactions in the domain of the bodyhoods of the languaging organisms. In other words, although languaging takes place in the social domain as a dance or recursive relations of coordinations of actions, interactions in language as structural interactions are orthogonal to that domain, and as such trigger in the bodyhoods of the participants structural changes that change as much the physiological background (emotional standing) on which they continue their languaging as the course that this physiological change follows.”

30. Ser humano “ The result is that the social recursive coordinations of actions that constitute languaging, as elements of a domain of recursive operation in structural coupling, become part or the medium in which the participant living systems conserve organization and adaptation through the structural changes that they undergo contingent to their participation in that domain. Thus, although the domain of coordinations of actions and the domain of structural change of the participants in language do no intersect, their changes are coupled orthogonally through the structural interactions that take place in language. As the body changes, languaging changes; and as languaging changes the body changes. Here resides the power of words. Words are nodes in coordinations of actions in languaging and as such they arise through structural interactions between bodyhoods. It is through this interplay of coordinations of actions and changes of bodyhoods that we bring forth in languaging becomes part of the domain in which our ontogenic and phylogenic structural drifts take place.”