Metodologia de jenkins

5.1.1 Metodología de Jenkins
En el modelo clásico, cada proyecto atraviesa por algún tipo de análisis, diseño e implantación, aunque no se haga exactamente como se muestra en la figura 2.1.1(a) El ciclo de vida de proyecto utilizado, pudiera diferir del que se muestra en la figura 2.1.1(a) en una o todas de las formas siguientes:
• La fase de exploración y análisis pudieran juntarse en unasola.
• Puede no haber fase de estudio de hardware si se cree que cualquier sistema nuevo pudiera instalarse con las computadoras existentes sin causar mayor problema operacional.
• La fase de diseño preliminar y el diseño de detalles pudieran juntarse en una sola llamada simplemente de diseño.
• Diversas fases de pruebas pueden juntarse en una sola; de hecho, podrían incluirse con lacodificación.

Figura 2.1:El ciclo de vida del proyecto clásico
El uso de la implantación ascendente es una de las grandes debilidades del ciclo de vida de los proyectos clásicos. Como se podrá ver en la figura 2.1, se espera que los programadores lleven a cabo primero sus pruebas modulares, luego las pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque también se conoce comoel ciclo de vida de cascada. .
Muchas organizaciones que desarrollan sistemas únicos, el enfoque ascendente presenta un gran número de dificultades serias:
• Nada esta hecho hasta que todo esté terminado.
• Las fallas más triviales se encuentran al comienzo del período de prueba y las más graves al final.
• La eliminación de fallas suele ser extremadamente difícil durante las últimas etapasde prueba del sistema.
• La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas finales de prueba.
La segunda debilidad más importante del ciclo de vida de un proyecto clásico es su insistencia en que las fases se sucedan secuencialmente. Querer esto es una tendencia natural humana: deseamos decir que hemos terminado la fase de análisis del sistema y que nuncatendremos que volver a preocuparnos por ella. El único problema del progreso ordenado es que no es nada realista. Por ejemplo, durante el período que transcurre para desarrollar el sistema pueden cambiar ciertos aspectos del ambiente del usuario (la economía, la competencia, los reglamentos gubernamentales que afectan a las actividades del usuario).
En la figura 2.2.1 se muestra el modelosemiestructurado, en donde se observa la siguiente diferencia con respecto al modelo clásico:
"La secuencia ascendente de codificación, la prueba de módulos y prueba del sistema se reemplaza por una implementación de arriba hacia abajo, que es un enfoque en el cual los módulos de alto nivel se codifican y prueban primero, seguidos por los más detallados de bajo nivel".

Figura 2.2:Modelosemiestructurado
Dentro del modelo semiestructurado encontramos otros detalles tales como, la implementación descendente que significa que se pondrán en ejecución paralelamente parte de la codificación y de las pruebas. Dándose con lo anterior una retroalimentación entre la codificación, la prueba y la eliminación de las fallas.
Como último punto acerca del modelo semiestructurado, tenemos que una granparte del trabajo que se realiza bajo el nombre de "diseño estructurado" es en realidad un esfuerzo manual para enmendar especificaciones erróneas. Otra funcion de los diseñadores, es traducir un documento narrativo, ambiguo, monolítico y redundante a un modelo útil, que sirva de base para derivar la jerarquía de módulos que cumplan con los requisitos del usuario.
En general con este enfoque dedesarrollo de sistemas los diseñadores tenían poco contacto con el analista que escribía la especificación y definitivamente "no tenía contacto con el usuario".
En el modelo estructurado se examinan brevemente las nueve actividades y los tres terminadores que lo componen, como se muestra en la figura 2.3.1. Los terminadores son los usuarios, los administradores, y el personal de operaciones. Los...