Rivadeneira The Mythical Man Month

TÍTULO:
The Mythical Man Month
1. DESARROLLO:
CAPÍTULO 11 Planea deshacerte de uno (Plan to Throw One Away)

Plantas piloto y ampliación
Dentro del desarrollo de software una de las prácticas más comunes realizadas por los programadores es desarrollar y probar para un porcentaje de la capacidad del real del sistema, en el libro nos pone el ejemplo de un proceso de desalación del agua con unacapacidad de diez mil galones de agua por día, implementado en una planta que usa 2 millones de litros por día.
En la mayoría de proyectos la primera versión es apenas utilizable, muchas veces lenta, pesada e incómoda de usar; es aquí donde entra el proceso de rediseño en cual se la puede cambiar pieza por pieza o botarlo todo y empezar de nuevo. La verdadera pregunta es que si se debe planificarcon antelación el usar y tirar.

La única Constancia es el cambio
Una vez que la idea de usar y tirar es reconocida, el frente al cambio es mucho más aceptado, y se lo debe implementar de manera que sea una forma de vida y no una rutina molesta. Cosgrove señala que el programador satisface una necesidad del cliente más que un producto tangible; y tanto esta necesidad y la percepción del usuariocambiará a medida que el software se construye, prueba y utiliza, por lo que nos podemos dar cuenta que el software estará en constante cambio en los requisitos. Es verdad que no todo cambio debe ser hecho, sin embargo algunos son inevitables y es mejor estar preparados, que asumir que no vendrán.

Planificar el Sistema para el Cambio
La planificación y el diseño de un sistema son posiblemente muchomás hablados que puestos en práctica, las cuales incluyen subrutinas y documentación, en las cuales es muy importante el uso de un lenguaje de alto nivel y técnicas de documentación con el fin de reducir errores al ejecutar los cambios. Esta cuantificación del el cambio es una técnica necesario, introduciendo versionamiento contemplado en el tiempo, del cambio y el proceso de pasar a la siguienteversión.

Planee la Organización para el cambio
Cosgrove enfatiza el tratamiento de los planes, las metas y los horarios para facilitar el cambio; un error común de los grupos de programación es el poco control en la gestión del cambio, y no se debe tanto a la pereza o al tiempo, sino que cuando un software está siendo documentado a medida que se lo desarrolla, este está sujeto a críticas y porconsecuencia nada será documentado hasta que esté completamente defendible.
El estructurar una organización para el cambio es mucho más difícil que el diseño de un sistema para el cambio, ya que cada hombre y su fuerza de trabajo debe ser flexible. Dentro de la caballería de un proyecto se debe mantener dos o tres buenos programadores, definidos por el gerente, el cual debe tener mucha atención amantener sus directivos y sus técnicos como intercambiables como sus talentos lo permitan.
Otro punto a tomar en cuenta son las barreras sociológicas dentro de la empresa, donde usualmente se valora más a las personas mayores por la experiencia, cada profesional es un miembro del personal.

Un paso adelante y un paso atrás
Muchas de las reparaciones de software suelen dañar o destruir otrosobjetos o funcionalidades del software, en donde es necesario un rediseño desde las bases, de esta manera es menos probable que uno siga retrocediendo con cada paso adelante que vaya.

CAPÍTULO 13 El todo y las partes (The Whole and the Parts)
Diseño de Bugs

Bug a prueba, la definición
Los bugs son los más dañinos y sutiles errores del sistema, la integridad conceptual de un producto facilita lausabilidad y la construcción, además de estar sujeto a menos errores. Por lo tanto la definición de Bug se reduce a utilizar todas las técnicas para mitigar el número de bus encontrados en el sistema.

Probando las especificaciones
Las especificaciones deben estar definidas mucha antes de que se empiece a escribir el código, una manera más de mitigar Bugs.

Diseño descendiente
Es la implementación de...