PRESENTACIÓN Desarrollo de Un Software

“Año del buen servicio al ciudadano”
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
CICLO : VIII
DOCENTE : Ing. Leónidas Asto Huamán
TEMA : Desarrollo de un software utilizando metodología XP
ASIGNATURA : Ingeniería De Software II
ESTUDIANTE :
 Robit Cotarma Torres

 Edy Franco Ortiz
 Ronny Rivera
ANDAHUAYLAS - PERÚ
2017-II
DESARROLLO DE UN SISTEMA DE ADMINISTRACIÓN
Y GESTIÓN DEL GRIFO MUNICIPAL DE PACUCHA
2017-2022
DEPARTAMENTO DE APURÍMAC - PROVINCIA ANDAHUAYLAS – DISTRITO DE PACUCHA
ROBIT COTARMA TORRES

EDY FRANCO ORTIZ
RONNY RIVERA
UNIVERSIDAD NACIONAL JOSÉ MARÍA ARGUEDAS

FACULTAD DE INGENIERÍA: INGENIERÍA DE SISTEMAS
2017 - II
Andahuaylas, lunes 06 de noviembre de 2017.

Contenido
OBJETIVOS ................................................................................................................................ 5
JUSTIFICACIÓN ........................................................................................................................ 6
RESUMEN ................................................................................................................................... 7
INTRODUCCIÓN ........................................................................................................................ 8
1. MARCO TEÓRICO ............................................................................................................ 9
1.1. INTRODUCCIÓN ...................................................................................................... 11
1.2. QUE ES XP ............................................................................................................... 11
1.3. MODELO XP ............................................................................................................. 12
1.4. ROLES XP................................................................................................................. 12
1.5. MODELO XP ............................................................................................................. 14
1.6. PROCESO XP .......................................................................................................... 14
1.7. REGLAS Y PRÁCTICAS ........................................................................................ 17
1.8. VENTAJAS Y DESVENTAJAS ............................................................................. 24
1.9. CONCLUSIONES Y RECOMENACIONES ......................................................... 25
2. PRESENTACIÓN ............................................................................................................. 26
2.1. HERRAMIENTAS A EMPLEAR ............................................................................ 27
2.2. DESCRIPCIÓN DEL NEGOCIO ............................................................................ 28
2.3. DESCRIPCIÓN DE CLIENTE Y USUARIO ......................................................... 28
3. ADMINISTRACIÓN DEL PROYECTO. ........................................................................ 29
3.1. OBJETIVOS GENERALES: ................................................................................... 30
3.2. FASES DE LA ADMINISTRACIÓN DE PROYECTOS: .................................... 30
3.2.1. INICIO. ............................................................................................................... 30
3.2.2. PLANEACIÓN. ................................................................................................. 31
3.2.3. EJECUCIÓN. .................................................................................................... 36
3.2.4. CONTROL. ........................................................................................................ 36
3.2.5. CONCLUSIÓN. ................................................................................................. 36
4. ADMINISTRACIÓN DE RIESGOS ................................................................................ 38
4.1. IDENTIFICACIÓN DE RIESGOS .......................................................................... 38
4.1.1. RIESGOS DE CRONOGRAMACIÓN Y TIEMPO:...................................... 38
4.1.2. RIESGOS DE FUNCIONALIDAD DEL SISTEMA: .................................... 39
4.1.3. RIESGOS DE SUBCONTRATACIÓN: ......................................................... 39
4.1.4. RIESGOS DE ADMINISTRACIÓN DE REQUERIMIENTOS .................... 39
4.1.5. RIESGOS DE USO Y DESEMPEÑO DE LOS RECURSOS .................... 39
4.1.6. RIESGOS DE ADMINISTRACIÓN DEL PERSONAL ................................ 40
4.2. ANÁLISIS DEL RIESGO ........................................................................................ 41
4.3. ALCANCES DEL PROCESO DE ADMINISTRACIÓN DE RIESGOS ............ 43
5. DISEÑO ............................................................................................................................. 44
5.1. METÁFORA DEL SISTEMA .................................................................................. 45
5.2. TARJETAS DE CLASE, RESPONSABILIDAD, COLABORACIÓN (CRC
CARDS) ................................................................................................................................. 45
5.3. SOLUCIONES PUNTUALES (SPIKE SOLUTION) ........................................... 45
5.4. NO SOLUCIONAR ANTES DE TIEMPO ............................................................. 46
5.5. REFACTORIZACIÓN (REFACTORING) ............................................................. 46
5.6. REFACTORIZACIÓN (REFACTORING) ............................................................. 46
6. CODIFICACIÓN................................................................................................................ 47
6.1. CLIENTE SIEMPRE PRESENTE. ......................................................................... 47
6.2. CODIFICAR PRIMERO LA PRUEBA................................................................... 47
6.3. PROGRAMACIÓN EN PAREJAS ........................................................................ 47
6.4. INTEGRACIÓN SECUENCIAL .............................................................................. 48
6.5. INTEGRACIONES FRECUENTES. ...................................................................... 48
6.6. ESTÁNDARES Y PROPIEDAD COLECTIVA DEL CÓDIGO .......................... 48
7. CONTROL DE CALIDAD EN EL SOFTWARE ........................................................... 50
7.1. DEFINICION DE CALIDAD EN EL SOFTWARE ............................................... 51
7.2. METRICAS DE CONTROL DE LA CALIDAD EN EL SOFTWARE ................ 52
8. PRUEBAS ......................................................................................................................... 54
8.1. PRUEBAS UNITARIAS .......................................................................................... 54
8.2. PRUEBAS DE ACEPTACIÓN ............................................................................... 54
8.3. CUANDO SE ENCUENTRA UN ERROR ............................................................ 55
9. CONCLUSIONES............................................................................................................. 56
10. RECOMENDACIONES ............................................................................................... 57
OBJETIVOS
OBJETIVOS GENERALES
 Realizar un software utilizando la metodología ágil XP a través del desarrollo de

una serie de pasos que menciona la metodología.
OBJETIVOS ESPECÍFICOS
 Consultar acerca de la metodología XP para el desarrollo del software.

 Diseñar en compañía del cliente las iteraciones.
 Desarrollar las tareas planteadas en cada una de las iteraciones.
 Realizar la documentación del proyecto según la guía XP.
 Concluir sobre la conveniencia de la utilización de la metodología XP en este
proyecto basándose en los resultados obtenidos.
JUSTIFICACIÓN
El sistema de control del grifo municipal del distrito de Pacucha permite obtener una
mayor eficiencia en el almacenamiento, seguridad, integridad, fiabilidad de la
información y de control que el ente maneja en cada una de las dependencias
encargadas de los procesos de provisionar y comercializar combustible
El sistema no se limita a obtener datos de un único proceso y dar información resultado
del mismo. Por el contrario, posibilita que los datos sean reutilizados por todos los
procesos, obteniendo al final de cada uno, la información que permite la revisión del
mismo y los reportes necesarios para la iniciación del siguiente o del proceso que lo
requiera. Lo anterior, por cuanto, actualmente dicha información no está disponible de
manera sistematizada y relacionada, por lo que el cruce de información debe hacerse
en forma manual.
La información de la gestión presupuestal requiere de un sistema que permita
automatizar todos los procesos que se llevan a cabo, puesto que los resultados de estos
procesos arrojan información que es requerida para la elaboración de informes que se
deben presentar a los entes de control fiscal, quienes a través de esta información
realizan un seguimiento y calificación de la administración de los recursos públicos. Si
los informes presentan inconsistencias, las cuales se pueden generar por la ineficiente
e inadecuada manipulación de la información, el Municipio acarrearía con graves
sanciones que perjudicarían el desarrollo económico y social del mismo.
El desarrollo de software para la administración de bases de datos elimina los problemas
existentes con la gestión de datos mediante archivos y estandariza un modo de gestión
de datos más eficaz, universal e independiente de las máquinas y sistemas operativos
sobre los que se implementen, generando un sistema de almacenamiento de datos, con
una interfaz de usuario de fácil manejo y sencilla de consultar.
El diseño de bases de datos representa dos ventajas. La primera es la independencia
lógica de datos, lo cual quiere decir que los cambios realizados en un objeto de la misma
no obligan a modificar otros elementos de la base de datos. La segunda es la
independencia física de los datos, es decir, la base de datos no depende del tipo de
dispositivo de almacenamiento en que se guarde.
El proyecto sistema de control del grifo municipal del distrito de Pacucha. Esta
desarrollado utilizando la herramienta PHP XAMPP la cual cuenta con un gestor de base
de datos que se encarga de administrar de manera eficiente la información almacenada
en las tablas que conforman la base de datos. PHP cuenta con herramientas de fácil
manejo para la creación de las tablas y de las interfaces gráficas para el ingreso de la
información, así mismo brinda facilidad y rapidez en la elaboración de consultas e
informes.
El manejo de la información de adquirir, provisionar y comercializar combustible que rige
la presentación de informes cambia frecuentemente; por lo cual se requirió utilizar una
herramienta de fácil manejo y rápido desarrollo para adaptar el sistema a los nuevos
cambios, sin que el Municipio incurra en elevados costos de actualización del sistema
que exige las variaciones en la normatividad.
RESUMEN
El proyecto titulado SISTEMA DE CONTROL DEL GRIFO MUNICIPAL desarrollado

para la municipalidad de Pacucha permite gestionar la información de los procesos que
se realizan en la ejecución de compra y reparto de combustible. Realizado por los
estudiantes de ingeniería de sistemas EDY FRANCO ORTIZ Y ROBIT COTARMA
TORRES de la universidad Nacional José María Arguedas
El Proyecto fue desarrollado mediante la aplicación de la metodología Procesos

Unificado de Desarrollo (RUP), utilizando el Lenguaje Unificado de Modelado (UML) y
utilizando las herramientas PHP, XAMPP. Al final se logró el desarrollo de un software
que cumple con las especificaciones hechas por los usuarios, siendo de fácil manejo
para ellos debido a que la interfaz es totalmente grafica
INTRODUCCIÓN
El grifo municipal es un instrumento que le permite provisión y comercialización de

combustible de buena calidad para garantizar un buen servicio a maquinarias y
vehículos, que posee la municipalidad y la población de dicho territorio.
Esta Unidad Orgánica operativa desconcertada de la Municipalidad distrital de Pacucha,
dependiente de la Gerencia Municipal encargada de planificar, organizar, dirigir, ejecutar
y supervisar el desarrollo de las actividades relacionadas con la provisión y
comercialización de combustibles, lubricantes y Aditivos, a Terceros y a la
Municipalidad, así como velar por el mantenimiento y conservación del vehículo, equipos
e instalaciones asignadas, así como de la operación de los mismos.
Para cualquier entidad territorial es de vital importancia contar con las herramientas
necesarias que les permitan adquirir, provisionar y comercializar combustible de buena
calidad; puesto que del buen manejo de la misma depende un buen ejercicio en la
administración de los recursos, la toma de decisiones y la rendición de informes ante los
entes de control.
El proyecto pone a disposición del Municipio distrital de Pacucha un sistema que les
permite adquirir, provisionar y comercializar combustible, confiable y ágil la información
de la ejecución y además genera los reportes que sirven de base para elaborar los
informes oficiales que deben ser enviados a los entes de control Departamentales
(Informes para el programa SEREC) y Nacionales. (SIDEF).
El proyecto SISTEMA DE CONTROL DEL GRIFO MUNICIPAL DEL DISTRITO DE
PACUCHA está desarrollado utilizando las herramientas PHP, XAMPP, y cuenta con
una utilidad Web.
Para la realización de este proyecto se contará con el apoyo y colaboración del
Municipio de Pacucha.
1. MARCO TEÓRICO
RESUMEN
Las metodologías ágiles han ganado bastante popularidad desde hace algunos años.
Si bien son una muy buena solución para proyectos a corto plazo, en especial, aquellos
proyectos en donde los requerimientos están cambiando constantemente, en proyecto
a largo plazo, el aplicar metodologías ágiles no dan tan buenos resultados. El diseño de
la arquitectura de software es una práctica muy importante para el desarrollo de
software. Tener una buena arquitectura implica que nuestro sistema tiene atributos de
calidad que nos van a dar un valor muy importante en el software. Si se definen
actividades que fomenten el uso de métodos para el desarrollo de la arquitectura, en un
proceso de desarrollo de software, se puede obtener muchos beneficios con respecto al
producto que se desarrolló. Sin embargo, para las metodologías ágiles esas actividades
no se consideran en forma importante.
Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo,
a la colaboración con el cliente y al desarrollo incremental del software con iteraciones
muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos
muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo,
pero manteniendo una alta calidad.
Las metodologías ágiles están revolucionando la manera de producir software, y a la
vez generando un amplio debate entre sus seguidores y quienes por escepticismo o
convencimiento no las ven como alternativa para las metodologías tradicionales.
La razón de ser de este trabajo se basa en el análisis de algunos tipos de metodologías
existentes, viendo sus principales características, conceptos y conclusiones.
JUSTIFICACION
La metodología ágil XP surge con el propósito de transformar la esencia del desarrollo
de los procesos que se ejecutan al momento de llevar acabo la planificación y ejecución
de un proyecto de creación de software esta metodología se enfoca en integrar en una
mejora continua al usuario y al grupo de individuo que se encargaran de resolver la
problemática percibida.
XP en comparación de las metodologías tradicionales es más rápida, ya que conlleva
menos protocolo, lo que evita que existan jerarquías dentro del grupo, lo cual permite
que cada integrante del grupo pueda aportar en cualquier motivo, por la cual se
implementará o hará uso de esta metodología es, que la misma se enfoca en resultados
a corto plazos es decir los resultados que se van obteniendo a lo largo de la modulación
serán verificados al instante y de existir alguna anomalía o falta se hará las correcciones
correspondientes. De esta forma rápida es posible obtener los resultados esperados a
corto plazo y de manera eficiente el sistema tomará robustez en la utilización de los
módulos se logrará de manera instantánea.
Los resultados son verificados por el usuario de manera que apruebe el producto y así
obtener una seguridad y solidez en el desarrollo del sistema, de esta manera el resultado
final lograra satisfacer en un gran porcentaje la expectativa y las necesidades del
usuario.
1.1. INTRODUCCIÓN
La programación extrema o XP es una metodología de desarrollo que se englobaría
dentro de las denominadas metodologías Ágiles en la que se da máxima prioridad a la
obtención de resultados y reduce la burocracia que utiliza las metodologías
tradicionales.
Generalmente el proceso de desarrollo llevaba asociado un marcado énfasis en el
control del proceso mediante una rigurosa definición de roles, actividades y artefactos,
incluyendo modelado y documentación detallada. Este esquema "tradicional" para
abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos
de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto
grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más
adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy
cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo, pero
manteniendo una alta calidad.
Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de
tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir de las
buenas prácticas de la Ingeniería del Software, asumiendo el riesgo que ello conlleva.
En este contexto las metodologías ágiles emergen como una posible respuesta para
llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos
pequeños, las Metodologías Ágiles constituyen una solución a medida para ese entorno,
aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas
esenciales para asegurar la calidad del producto.
1.2. QUE ES XP
XP es una metodología ágil para el desarrollo de software y consiste básicamente en
ajustarse estrictamente a una serie de reglas que se centran en las necesidades del
cliente para lograr un producto de buena calidad en poco tiempo, centrada en potenciar
las relaciones interpersonales como clave para el éxito del desarrollo de software.
La filosofía de XP es satisfacer al completo las necesidades del cliente, por eso lo integra
como una parte más del equipo de desarrollo.
Promueve el trabajo en equipo, preocupándose en todo momento del aprendizaje de los
desarrolladores y estableciendo un buen clima de trabajo.
Este tipo de programación es la adecuada para los proyectos con requisitos imprecisos,
muy cambiantes y donde existe un alto riesgo técnico.
XP está diseñada para el desarrollo de aplicaciones que requieran un grupo de
programadores pequeño, dónde la comunicación sea más factible que en grupos de
desarrollo grandes. La comunicación es un punto importante y debe realizarse entre los
programadores, los jefes de proyecto y los clientes.
1.3. MODELO XP
1.3.1. COMUNICACIÓN:
Prevalece en todas las prácticas de Extreme Programming. Comunicación cara a
cara es la mejor forma de comunicación, entre los desarrolladores y el cliente.
Método muy ágil. Gracias a esto el equipo esta pude realizar cambios que al cliente
no le gustaron.
1.3.2. SIMPLICIDAD:
La simplicidad ayuda a que los desarrolladores de software encuentren soluciones
más simples a problemas, según el cliente lo estipula. Los desarrolladores también
crean características en el diseño que pudieran ayudar a resolver problemas en un
futuro.
1.3.3. RETROALIMENTACIÓN:
La retroalimentación continua del cliente permite a los desarrolladores llevar y dirigir
el proyecto en una dirección correcta hacia donde el cliente quiera.
1.3.4. VALENTÍA:
Requiere que los desarrolladores vayan a la par con el cambio, porque sabemos que
este cambio es inevitable, pero el estar preparado con una metodología ayuda a ese
cambio. Programa para hoy y no para mañana.
1.3.5. RESPETO:
El equipo debe trabajar como uno, sin hacer decisiones repentinas. Extreme
Programming promueve el trabajo del equipo. Cada integrante del proyecto (cliente,
desarrolladores, etc.) forman parte integral del equipo encargado de desarrollar
software de calidad. El equipo debe trabajar como uno, sin hacer decisiones
repentinas.
1.4. ROLES XP
Aunque en otras fuentes de información aparecen algunas variaciones y extensiones de
roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original
de Beck.
1.4.1. PROGRAMADOR
El programador escribe las pruebas unitarias y produce el código del sistema. Debe
existir una comunicación y coordinación adecuada entre los programadores y otros
miembros del equipo.
1.4.2. CLIENTE
El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementación. Además, asigna la prioridad a las historias de usuario y decide
cuáles se implementan en cada iteración centrándose en aportar mayor valor al
negocio. El cliente es sólo uno dentro del proyecto, pero puede corresponder a un
interlocutor que está representando a varias personas que se verán afectadas por
el sistema.
1.4.3. ENCARGADO DE PRUEBAS (TESTER)

El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta
las pruebas regularmente, difunde los resultados en el equipo y es responsable de
las herramientas de soporte para pruebas.
1.4.4. ENCARGADO DE SEGUIMIENTO (TRACKER)

El encargado de seguimiento proporciona realimentación al equipo en el proceso
XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado,
comunicando los resultados para mejorar futuras estimaciones. También realiza el
seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables
con las restricciones de tiempo y recursos presentes.
Determina cuándo es necesario realizar algún cambio para lograr los objetivos de
cada iteración.
1.4.5. ENTRENADOR (COACH)

Es responsable del proceso global. Es necesario que conozca a fondo el proceso
XP para proveer guías a los miembros del equipo de forma que se apliquen las
prácticas XP y se siga el proceso correctamente.
1.4.6. CONSULTOR
Es un miembro externo del equipo con un conocimiento específico en algún tema
necesario para el proyecto. Guía al equipo para resolver un problema específico.
1.4.7. GESTOR (BIG BOSS)

Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinación.
1.5. MODELO XP
La metodología XP define cuatro variables para cualquier proyecto de software: costo,
tiempo, calidad y alcance.
Además, se especifica que, de estas cuatro variables, sólo tres de ellas podrán ser
fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes
de proyecto). El valor de la variable restante podrá ser establecido por el equipo de
desarrollo, en función de los valores de las otras tres. Este mecanismo indica que, por
ejemplo, si el cliente establece el alcance y la calidad, y el jefe de proyecto el precio, el
grupo de desarrollo tendrá libertad para determinar el tiempo que durará el proyecto.
Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con
entregables funcionales al finalizar cada ciclo. En cada iteración se realiza un ciclo
completo de análisis, diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas
y prácticas que caracterizan a XP.
Típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones. La siguiente figura
esquematiza los
ciclos de desarrollo en cascada e iterativos tradicionales (por ejemplo, incremental o
espiral), comparados con el de XP.
Fig. 1 Evolución de los largos ciclos de desarrollo en cascada (a) a

ciclos iterativos más cortos (b) y a la mezcla que hace XP.
1.6. PROCESO XP
Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a
implementar basado en la habilidad del equipo para medir la funcionalidad que puede
entregar a través del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los
siguientes pasos:
El cliente define el valor de negocio a implementar. El programador estima el esfuerzo
necesario para su implementación. El cliente selecciona qué construir, de acuerdo con
sus prioridades y las restricciones de tiempo. El programador construye ese valor de
negocio. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden.
No se debe presionar al programador a realizar más trabajo que el estimado, ya que se
perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente
tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que
el sistema tenga el mayor valor de negocio posible con cada iteración.
Si bien el ciclo de vida de un proyecto XP es muy dinámico, se puede separar en las
siguientes Fases:
 Exploración,
 Planificación de la Entrega (Release),
 Iteraciones,
 Producción,
 Mantenimiento y
 Muerte del Proyecto.
1.6.1. FASE I: EXPLORACIÓN

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son
de interés para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnologías y prácticas que se
utilizarán en el proyecto.
Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema
construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos
meses, dependiendo del tamaño y familiaridad que tengan los programadores con
la tecnología
1.6.2. FASE II: PLANIFICACIÓN DE LA ENTREGA

En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimación del esfuerzo
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera
entrega y se determina un cronograma en conjunto con el cliente. Una entrega
debería obtenerse en no más de tres meses. Esta fase dura unos pocos días.
Las estimaciones de esfuerzo asociado a la implementación de las historias la
establecen los programadores utilizando como medida el punto. Un punto, equivale
a una semana ideal de programación. Las historias generalmente valen de 1 a 3
puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad”
de desarrollo, establecida en puntos por iteración, basándose principalmente en la
suma de puntos correspondientes a las historias de usuario que fueron terminadas
en la última iteración.
La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad
del proyecto es utilizada para establecer cuántas historias se pueden implementar
antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto
de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la
velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al
planificar según alcance del sistema, se divide la suma de puntos de las historias de
usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de
iteraciones necesarias para su implementación.
El resultado de esta fase es un Plan de Entregas, o “Release Plan”.
1.6.3. FASE III: ITERACIONES

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan
de Entrega está compuesto por iteraciones de no más de tres semanas. En la
primera iteración se puede intentar establecer una arquitectura del sistema que
pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las
historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre
es posible ya que es el cliente quien decide qué historias se implementarán en cada
iteración (para maximizar el valor de negocio). Al final de la última iteración el
sistema estará listo para entrar en producción.
Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la
Iteración son:
 historias de usuario no abordadas,

 velocidad del proyecto,
 pruebas de aceptación no superadas en la iteración anterior y
 tareas no terminadas en la iteración anterior
Todo el trabajo de la iteración es expresado en tareas de programación, cada una
de ellas es asignada a un programador como responsable, pero llevadas a cabo por
parejas de programadores.
Fig. 2 iteración
1.6.4. FASE IV: PRODUCCIÓN

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento
antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se
deben tomar decisiones sobre la inclusión de nuevas características a la versión
actual, debido a cambios durante esta fase.
Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana.
Las ideas que han sido propuestas y las sugerencias son documentadas para su
posterior implementación (por ejemplo, durante la fase de mantenimiento).
En esta fase no se realizan más desarrollos funcionales, pero pueden ser necesarias
tareas de ajuste (“fine tuning”).
1.6.5. FASE V: MANTENIMIENTO
Mientras la primera versión se encuentra en producción, el proyecto XP debe
mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De
esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema
en producción. La fase de mantenimiento puede requerir nuevo personal dentro del
equipo y cambios en su estructura.
1.6.6. FASE VI: MUERTE DEL PROYECTO

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto
requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema. Se genera la documentación final del
sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto
también ocurre cuando el sistema no genera los beneficios esperados por el cliente
o cuando no hay presupuesto para mantenerlo.
1.7. REGLAS Y PRÁCTICAS

La metodología XP tiene un conjunto importante de reglas y prácticas. En forma
genérica, se pueden agrupar en:
 Reglas y prácticas para la Planificación

 Reglas y prácticas para el Diseño
 Reglas y prácticas para el Desarrollo
 Reglas y prácticas para las Pruebas
1.7.1. PLANIFICACIÓN
La metodología XP plantea la planificación como un dialogo continuo entre las partes
involucradas en el proyecto, incluyendo al cliente, a los programadores y a los
coordinadores o gerentes. El proyecto comienza recopilando “Historias de usuarios”,
las que sustituyen a los tradicionales “casos de uso”. Una vez obtenidas las “historias
de usuarios”, los programadores evalúan rápidamente el tiempo de desarrollo de
cada una.
Si alguna de ellas tiene “riesgos” que no permiten establecer con certeza la
complejidad del desarrollo, se realizan pequeños programas de prueba (“spikes”),
para reducir estos riesgos. Una vez realizadas estas estimaciones, se organiza una
reunión de planificación, con los diversos actores del proyecto (cliente,
desarrolladores, gerentes), a los efectos de establecer un plan o cronograma de
entregas (“Release Plan”) en los
que todos estén de acuerdo. Una vez acordado este cronograma, comienza una
fase de iteraciones, en dónde en cada una de ellas se desarrolla, prueba e instala
unas pocas “historias de usuarios”.
Según Martín Fowler (uno de los firmantes del “Agile Manifesto”), los planes en XP
se diferencian de las metodologías tradicionales en tres aspectos:
Simplicidad del plan. No se espera que un plan requiera de un “gurú” con
complicados sistemas de gerenciamiento de proyectos.
Los planes son realizados por las mismas personas que realizarán el trabajo.
Los planes no son predicciones del futuro, sino simplemente la mejor estimación de
cómo saldrán las cosas. Los planes son útiles, pero necesitan ser cambiados cuando
las circunstancias lo requieren. De otra manera, se termina en situaciones en las
que el plan y la realidad no coinciden, y en estos casos, el plan es totalmente inútil.
Los conceptos básicos de esta planificación son los siguientes:
1.7.1.1. LAS HISTORIAS DE USUARIO

Las historias de usuario son la técnica utilizada en XP para especificar los
requisitos del software. Se trata de tarjetas de papel en las cuales el cliente
describe brevemente las características que el sistema debe poseer, sean
requisitos funcionales o no funcionales.
El tratamiento de las historias de usuario es muy dinámico y flexible, en
cualquier momento historias de usuario pueden romperse, remplazarse por
otras más específicas o generales, añadirse nuevas o ser modificadas. Cada
historia de usuario es lo suficientemente comprensible y delimitada para que
los programadores puedan implementarla en unas semanas.
Respecto de la información contenida en la historia de usuario, existen varias
plantillas sugeridas, pero no existe un consenso al respecto. En muchos casos
sólo se propone utilizar un nombre y una descripción o sólo una descripción,
más quizás una estimación de esfuerzo en días. Beck en su libro presenta un
ejemplo de ficha (customer story and task card) en la cual pueden reconocerse
los siguientes contenidos:
 Fecha,
 tipo de actividad (nueva, corrección, mejora),
 prueba funcional, número de historia,
 prioridad técnica y del cliente,
 referencia a otra historia previa,
 riesgo,
 estimación técnica,
 descripción,
 notas y una lista de seguimiento con la fecha, estado cosas por terminar
y comentarios.
1.7.1.2. PLAN DE ENTREGAS (“RELEASE PLAN”)

El cronograma de entregas establece qué historias de usuario serán agrupadas
para conformar una entrega, y el orden de las mismas. Este cronograma será
el resultado de una reunión entre todos los actores del proyecto (cliente,
desarrolladores, gerentes, etc.).
XP denomina a esta reunión “Juego de planeamiento” (“Planning game”), pero
puede denominarse de la manera que sea más apropiada al tipo de empresa y
cliente (por ejemplo, Reunión de planeamiento, “Planning meeting” o “Planning
workshop”) Típicamente el cliente ordenará y agrupará según sus prioridades
las historias de usuario. El cronograma de entregas se realiza en base a las
estimaciones de tiempos de desarrollo realizadas por los desarrolladores.
Luego de algunas iteraciones es recomendable realizar nuevamente una
reunión con los actores del proyecto, para evaluar nuevamente el plan de
entregas y ajustarlo si es necesario.
1.7.1.3. PLAN DE ITERACIONES (“ITERATION PLAN”)

Las historias de usuarios seleccionadas para cada entrega son desarrolladas y
probadas en un ciclo de iteración, de acuerdo al orden prestablecido. Al
comienzo de cada ciclo, se realiza una reunión de planificación de la iteración.
Cada historia de usuario se traduce en tareas específicas de programación.
Así mismo, para cada historia de usuario se establecen las pruebas de
aceptación.
Estas pruebas se realizan al final del ciclo en el que se desarrollan, pero
también al final de cada uno de los ciclos siguientes, para verificar que
subsiguientes iteraciones no han afectado a las anteriores. Las pruebas de
aceptación que hayan fallado en el ciclo anterior son analizadas para evaluar
su corrección, así como para prever que no vuelvan a ocurrir.
1.7.1.4. REUNIONES DIARIAS DE SEGUIMIENTO (“STAND-UP

MEETING”)
El objetivo de tener reuniones diarias es mantener la comunicación entre el
equipo, y compartir problemas y soluciones. En la mayoría de estas reuniones,
gran parte de los participantes simplemente escuchan, sin tener mucho que
aportar. Para no quitar tiempo innecesario del equipo, se sugiere realizar estas
reuniones en círculo y de pie.
1.7.2. DISEÑO
La metodología XP hace especial énfasis en los diseños simples y claros. Los
conceptos más importantes de diseño en esta metodología son los siguientes:
1.7.2.1. SIMPLICIDAD
Un diseño simple se implementa más rápidamente que uno complejo. Por ello
XP propone implementar el diseño más simple posible que funcione. Se sugiere
nunca adelantar la implementación de funcionalidades que no correspondan a
la iteración en la que se esté trabajando.
1.7.2.2. SOLUCIONES “SPIKE”
Cuando aparecen problemas técnicos, o cuando es difícil de estimar el tiempo
para implementar una historia de usuario, pueden utilizarse pequeños
programas de prueba (llamados “spike”), para explorar diferentes soluciones.
Estos programas son únicamente para probar o evaluar una solución, y suelen
ser desechados luego de su evaluación.
1.7.2.3. RECODIFICACIÓN:
La recodificación (“refactoring”) consiste en escribir nuevamente parte del
código de un programa, sin cambiar su funcionalidad, a los efectos de hacerlo
más simple, conciso y/o entendible. Muchas veces, al terminar de escribir un
código de programa, pensamos que, si lo comenzáramos de nuevo, lo
hubiéramos hecho en forma diferente, más clara y eficientemente. Sin
embargo, como ya está pronto y “funciona”, rara vez es rescrito.
Las metodologías de XP sugieren recodificar cada vez que sea necesario. Si
bien, puede parecer una pérdida de tiempo innecesaria en el plazo inmediato,
los resultados de ésta práctica tienen sus frutos en las siguientes iteraciones,
cuando sea necesario ampliar o cambiar la funcionalidad. La filosofía que se
persigue es, como ya se mencionó, tratar de mantener el código más simple
posible que implemente la funcionalidad deseada.
1.7.2.4. METÁFORAS
Una “metáfora” es algo que todos entienden, sin necesidad de mayores
explicaciones. La metodología XP sugiere utilizar este concepto como una
manera sencilla de explicar el propósito del proyecto, y guiar la estructura y
arquitectura del mismo. Por ejemplo, puede ser una guía para la nomenclatura
de los métodos y las clases utilizadas en el diseño del código. Tener nombres
claros, que no requieran de mayores explicaciones, redunda en un ahorro de
tiempo.
Es muy importante que el cliente y el grupo de desarrolladores estén de
acuerdo y compartan esta “metáfora”, para que puedan dialogar en un “mismo
idioma”. Una buena metáfora debe ser fácil de comprender para el cliente y a
su vez debe tener suficiente contenido como para que sirva de guía a la
arquitectura del proyecto. Sin embargo, ésta práctica resulta, muchas veces,
difícil de realizar.
1.7.3. DESARROLLO
Fig. 3 Desarrollo
1.7.3.1. DISPONIBILIDAD DEL CLIENTE

Uno de los requerimientos de XP es tener al cliente disponible durante todo el
proyecto. No solamente como apoyo a los desarrolladores, sino formando parte
del grupo.
El involucramiento del cliente es fundamental para que pueda desarrollarse un
proyecto con la metodología XP.
Al comienzo del proyecto, el cliente debe proporcionar las historias de usuarios.
Pero, dado que estas historias son expresamente cortas y de “alto nivel”, no
contienen los detalles necesarios para realizar el desarrollo del código. Estos
detalles deben ser proporcionados por el cliente, y discutidos con los
desarrolladores, durante la etapa de desarrollo. No se requieren de largos
documentos de especificaciones, sino que los detalles son proporcionados por
el cliente, en el momento adecuado, “cara a cara” a los desarrolladores.
1.7.3.2. USO DE ESTÁNDARES

Si bien esto no es una idea nueva, XP promueve la programación basada en
estándares, de manera que sea fácilmente entendible por todo el equipo, y que
facilite la recodificación.
1.7.3.3. PROGRAMACIÓN DIRIGIDA POR LAS PRUEBAS (“TEST-

DRIVEN PROGRAMMING”)
En las metodologías tradicionales, la fase de pruebas, incluyendo la definición
de los tests, es usualmente realizada sobre el final del proyecto, o sobre el final
del desarrollo de cada módulo. La metodología XP propone un modelo inverso,
en el que, lo primero que se escribe son los test que el sistema debe pasar.
Luego, el desarrollo debe ser el mínimo necesario para pasar las pruebas
previamente definidas.
Las pruebas a los que se refieren esta práctica, son las pruebas unitarias,
realizados por los desarrolladores. La definición de estos test al comienzo,
condiciona o “dirige” el desarrollo.
1.7.3.4. PROGRAMACIÓN EN PARES
XP propone que se desarrolle en pares de programadores, ambos trabajando
juntos en un mismo ordenador. Si bien parece que ésta práctica duplica el
tiempo asignado al proyecto (y, por ende, los costos en recursos humanos), al
trabajar en pares se minimizan los errores y se logran mejores diseños,
compensando la inversión en horas. El producto obtenido es por lo general de
mejor calidad que cuando el desarrollo se realiza por programadores
individuales.
 Adicionalmente, la programación en pares tiene las siguientes ventajas:

 La mayoría de los errores se descubren en el momento en que se
codifican, ya que el código es permanentemente revisado por dos
personas.
 La cantidad de defectos encontrados en las pruebas es
estadísticamente menor.
 Los diseños son mejores y el código más corto. El equipo resuelve
problemas en forma más rápida.
 Las personas aprenden significativamente más, acerca del sistema y
acerca de desarrollo de software.
 El proyecto termina con más personas que conocen los detallas de cada
parte del código.
 Las personas aprenden a trabajar juntas, generando mejor dinámica de
grupo y haciendo que la información fluya rápidamente.
 Las personas disfrutan más de su trabajo.
1.7.3.5. INTEGRACIONES PERMANENTES

Todos los desarrolladores necesitan trabajar siempre con la “última versión”.
Realizar cambios o mejoras sobre versiones antiguas causan graves
problemas, y retrasan al proyecto. Es por eso que XP promueve publicar lo
antes posible las nuevas versiones, aunque no sean las últimas, siempre que
estén libres de errores. Idealmente, todos los días deben existir nuevas
versiones publicadas. Para evitar errores, solo una pareja de desarrolladores
puede integrar su código a la vez.
1.7.3.6. PROPIEDAD COLECTIVA DEL CÓDIGO

En un proyecto XP, todo el equipo puede contribuir con nuevas ideas que
apliquen a cualquier parte del proyecto. Asimismo, cualquier pareja de
programadores puede cambiar el código que sea necesario para corregir
problemas, agregar funciones o recodificar. En otras metodologías, este
concepto puede parecer extraño. Muchas veces se asume que, si hay algo de
propiedad colectiva, la responsabilidad también es colectiva. Y que “todos sean
responsables”, muchas veces significa que “nadie es responsable”.
1.7.3.7. RITMO SOSTENIDO
La metodología XP indica que debe llevarse un ritmo sostenido de trabajo.
Anteriormente, ésta práctica se denominaba “Semana de 40 horas”. Sin
embargo, lo importante no es si se trabajan, 35, 40 o 42 horas por semana. El
concepto que se desea establecer con esta práctica es el de planificar el trabajo
de manera de mantener un ritmo constante y razonable, sin sobrecargar al
equipo. Cuando un proyecto se retrasa, trabajar tiempo extra puede ser más
perjudicial que beneficioso. El trabajo extra desmotiva inmediatamente al grupo
e impacta en la calidad del producto. En la medida de lo posible, se debería
renegociar el plan de entregas (“Release Plan”), realizando una nueva reunión
de planificación con el cliente, los desarrolladores y los gerentes.
Adicionalmente, agregar más desarrolladores en proyectos ya avanzados no
siempre resuelve el problema.
1.7.4. PRUEBAS
1.7.4.1. PRUEBAS UNITARIAS
Las pruebas unitarias son una de las piedras angulares de XP. Todos los
módulos deben de pasar las pruebas unitarias antes de ser liberados o
publicados. Las pruebas deben ser definidas antes de realizar el código (“Test-
driven programming”).
Que todo código liberado pase correctamente las pruebas unitarias es lo que
habilita que funcione la propiedad colectiva del código. En este sentido, el
sistema y el conjunto de pruebas debe ser guardado junto con el código, para
que pueda ser utilizado por otros desarrolladores, en caso de tener que
corregir, cambiar o recodificar parte del mismo.
1.7.4.2. DETECCIÓN Y CORRECCIÓN DE ERRORES
Cuando se encuentra un error (“bug”), éste debe ser corregido inmediatamente,
y se deben tener precauciones para que errores similares no vuelvan a ocurrir.
Asimismo, se generan nuevas pruebas para verificar que el error haya sido
resuelto.
1.7.4.3. PRUEBAS DE ACEPTACIÓN

Las pruebas de aceptación son creadas en base a las historias de usuarios, en
cada ciclo de la iteración del desarrollo. El cliente debe especificar uno o
diversos escenarios para comprobar que una historia de usuario ha sido
correctamente implementada.
Las pruebas de aceptación son consideradas como “pruebas de caja negra”
(“Black box system tests”). Los clientes son responsables de verificar que los
resultados de estas pruebas sean correctos. Asimismo, en caso de que fallen
varias pruebas, deben indicar el orden de prioridad de resolución.
Una historia de usuario no se puede considerar terminada hasta tanto pase
correctamente todas las pruebas de aceptación. Dado que la responsabilidad
es grupal, es recomendable publicar los resultados de las pruebas de
aceptación, de manera que todo el equipo esté al tanto de esta información.
1.8. VENTAJAS Y DESVENTAJAS
1.8.1. VENTAJAS
Evidentemente, para que algo esté siendo tomado tan en cuenta como la XP, debe
ofrecer una serie de ventajas a la hora de ponerlo en práctica que haga que el
esfuerzo de entender y aplicar sus prácticas, sea insignificante con respecto a los
beneficios obtenidos.
 Se consiguen productos usables con mayor rapidez.

 El proceso de integración es continuo, por lo que el esfuerzo final para la
integración es nulo. Se consigue integrar todo el trabajo con mucha mayor
facilidad.
 Se atienden las necesidades del usuario con mayor exactitud. Esto se
consigue gracias a las continuas versiones que se ofrecen al usuario.
 Se consiguen productos más fiables y robustos contra los fallos gracias al
diseño de los test de forma previa a la codificación.
 Obtenemos código más simple y más fácil de entender, reduciendo el
número de errores.
 Gracias a la filosofía del “pair programming” (programación en parejas), se
consigue que los desarrolladores apliquen las buenas prácticas que se les
ofrecen con la XP.
 Gracias al “refactoring” es más fácil el modificar los requerimientos del
usuario.
 Conseguimos tener un equipo de desarrollo más contento y motivado. Las
razones son, por un lado, el que la XP no permite excesos de trabajo (se
debe trabajar 40 horas a la semana), y por otro la comunicación entre los
miembros del equipo que consigue una mayor integración entre ellos.
1.8.2. DESVENTAJAS
 Resulta muy complicado planear el proyecto y establecer el costo y la
duración del mismo.
 No se puede aplicar a proyectos de gran escala, que requieran mucho
personal, a menos que se las subdivida en proyectos más pequeños.
 Es más complicado medir los avances del proyecto, pues es muy complicado
el uso de una medida estándar.
 Altas comisiones en caso de fallar.
1.9. CONCLUSIONES Y RECOMENACIONES
1.9.1. CONCLUSIONES
 Es difícil estimar el costo y duración del proyecto por no existir una definición
desde inicio.
 El cliente le da un valor agregado al proyecto ya que ayuda a que los
requerimientos sean más compresibles y de fácil aprobación.
 Organiza a los integrantes del equipo para trabajar a un mismo ritmo divertido
y con horario adecuado.
 Los desarrolladores deben estar involucrados en todas las funcionalidades
del proyecto
 La programación en parejas ayuda a reducir costo y tiempos y mejorar la
calidad del proyecto.
 Los métodos en cascada o espiral son los más adecuados para proyectos.
 Que requieran decenas de desarrolladores y en los que las especificaciones
estén claramente determinadas desde el comienzo.
1.9.2. RECOMENDACIONES.
 Para proyectos medianos, y en los que las especificaciones no se puedan
obtener hasta luego de comenzado el proyecto, XP es la metodología
recomendada.
 Usar XP en equipos pequeños de desarrollo que no superen a 20
 Se debe involucrar al cliente en el desarrollo del proyecto desde el inicio
hasta el final ya que es indispensable que conozca y apruebe la metodología.
 Los desarrolladores deben compartan el código y ser responsables del
código de todo el proyecto.
2. PRESENTACIÓN
En este capítulo se hace una introducción a las condiciones del entorno que rodearon
al proyecto entre las cuales se resaltan aspectos relacionados con el cliente y el negocio
para el cual se desarrolló el proyecto. Además, se hace una descripción de las
herramientas que se emplearon en el desarrollo del proyecto y el motivo por el que
fueron elegidas.
2.1. HERRAMIENTAS A EMPLEAR
2.1.1. UML
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de
modelado visual común y semántica y sintácticamente rico para la arquitectura, el
diseño y la implementación de sistemas de software complejos, tanto en estructura
como en comportamiento. UML tiene aplicaciones más allá del desarrollo de
software, p. ej., en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes tipos
de diagramas. En general, los diagramas UML describen los límites, la estructura y
el comportamiento del sistema y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se pueden
usar para generar código en diversos lenguajes usando los diagramas UML. UML
guarda una relación directa con el análisis y el diseño orientados a objetos.
2.1.2. PHP
Es un Lenguaje de Programación para trabajar páginas WEB ofreciendo la ventaja
de mezclarse con HTML. Las ejecuciones son realizadas en el Servidor y el cliente
es el encargado de recibir los resultados de la ejecución. Si el cliente realiza una
petición, se ejecuta el intérprete de PHP y se genera el contenido de manera
dinámica. Permite conexión con varios tipos de Bases de Datos como: MySql,
Oracle, Postgress, SQL Server, etc. permitiendo aplicaciones robustas sobre la
WEB. Este lenguaje de programación puede ser ejecutado en la gran mayoría de
sistemas operacionales y puede interactuar con Servidores WEB populares
2.1.3. MYSQL
Es un manejador de Bases de Datos, el cual permite múltiples hilos y múltiples
usuarios, fue desarrollado como software libre. Aunque se puede usar sobre varias
plataformas es muy utilizado sobre LINUX. Es libre para uso en Servidores WEB.
Ofrece ventajas tales como fácil adaptación a diferentes entornos de desarrollo,
Interacción con Lenguajes de Programación como PHP, Java Script y fácil
Integración con distintos sistemas operativos.
2.1.4. APACHE
Es un Servidor WEB desarrollado por el grupo Apache. Su código fuente se puede
distribuir y utilizar de forma libre. Está disponible para diferentes plataformas de
Sistemas Operativos entre otros Windows, Linux, Mac y NetWare. Ofrece ventajas
tales como independencia de plataforma, haciendo posible el cambio de plataforma
en cualquier momento; creación de contenidos dinámicos, permitiendo crear sitios
mediante lenguajes PHP.
Además de ser libre su soporte técnico es accesible ya que existe una comunidad
que está disponible en foros, canales IRC y servidores de noticias, donde hay gran
cantidad de usuarios disponibles para cuando surge algún problema.
2.2. DESCRIPCIÓN DEL NEGOCIO
Se trata de una sucursal de la MUNICIPALIDAD DE Pacucha (grifo), con un capital para
el desarrollo del software aproximadamente catorce mil nuevos soles.
El proyecto, el negocio cuenta con manejo de sus registros a través de libros y
cuadernos muy convencional la cual no ofrecía la seguridad y manejo que requería el
cliente, por lo cual se desarrollara un software que desempeñara las funcionalidades de
un sistema “DESARROLLO DE UN SISTEMA DE ADMINISTRACIÓN Y GESTIÓN DEL
GRIFO MUNICIPAL DE PACUCHA 2017-2022” que cumpliera las necesidades
específicas del cliente.
2.3. DESCRIPCIÓN DE CLIENTE Y USUARIO

Para este proyecto se contará con dos usuarios del cual uno era el cliente.
El primer usuario que además era el cliente se trata del alcalde de la municipalidad
distrital de Pacucha “Claudio Velázquez Carbajal”, mayor de cincuenta años la cual tiene
conocimientos muy básicos sobre informática que limitaba de forma importante su
capacidad para plantear las funcionalidades que requiere el programa.
El segundo usuario es una ex empleada del cliente de 25 (veinticinco) años de edad, la
cual cuenta con conocimientos suficientes de informática, también tenía pleno
conocimiento del funcionamiento del negocio ya que lo había administrado hacía poco.
La participación de este segundo usuario fue muy importante para el proyecto debido
que facilitó la comunicación y planteo numerosos aspectos para tener en cuenta en el
proyecto que el primer usuario desconoció.
3. ADMINISTRACIÓN DEL PROYECTO.
El proyecto consiste en el DESARROLLO DE UN SISTEMA DE ADMINISTRACIÓN Y

GESTIÓN DEL GRIFO MUNICIPAL DE PACUCHA 2017-2022 que cuenta con un
capital de trabajo de 15 000.00 nuevos soles, en un periodo de tiempo estimado de dos
meses y medio calendario (70 días).
El sponsor del proyecto a realizarse es la Municipalidad de PACUCHA.
DEPARTAMENTO DE APURÍMAC - PROVINCIA ANDAHUAYLAS – DISTRITO DE
PACUCHA. Juntamente con las áreas de Logística y Tesorería. Con fin de colaborar en
las diferentes interrogantes que se mostraran durante el proyecto a ejecutarse.
3.1. OBJETIVOS GENERALES:
 Conocer los conceptos de la metodología de administración de proyectos.
 Establecer los lineamientos en el uso de la práctica de administración de
proyectos.
 Identificar las actividades de la administración de proyectos.
 Establecer el tiempo y uso de recursos del proyecto.
 Monitoreo del uso del dinero por fases del proyecto.
3.2. FASES DE LA ADMINISTRACIÓN DE PROYECTOS:

3.2.1. INICIO.
3.2.1.1. OBJETIVOS
 El proyecto a ejecutase se llevará a cabo un lapso de 70 días calendario
que tiene una duración de dos meses y medio aproximado. Y monto de
15 000.00 nuevos soles.
 Queremos lograr un sistema la cual gestione y administre el grifo
municipal en sus diferentes módulos que se especificara de acuerdo a
las necesidades del cliente.
 Tendrá un alcance general que englobará las siguientes áreas:
Tesorería y Logística para contar con aprobación de venta y reposición
del dinero al área de tesorería.
 Nuestros miembros de equipo de trabajo serán:
 Cuatro programadores
 Un analizador de base de datos
 Un diseñador.
 Un analista experto en diferentes temas externo.
3.2.1.2. CARTA DE PROYECTO
CARTA DEL PROYECTO

NOMBRE DEL PROYECTO DSAGGMP.
RESPONSABLE DEL PROYECTO Ing. Isaías Pérez Torres.
OBJETIVO Desarrollar un sistema de
Administración y Gestión.
BENEFICIOS Optimizar procesos
DESCRIPCIÓN Sistema cerrado solo para personal de
administración.
PRIORIDAD Clasificado de prioridad media.
JUSTIFICACIÓN Por necesidad del municipio.
PRODUCTOS Laptops, PCS, Internet.
APROBACIÓN Contamos con la aprobación:
 Del municipio.
 Del jefe del área de informática.
 De junta vecinal de PACUCHA.
3.2.2. PLANEACIÓN.
3.2.2.1. OBJETIVOS
 El proyecto contara con seis fases de desarrollo.
 Cada fase tendrá un tiempo estimado y el uso de recurso.
 Las fases son secuenciales. Para pasar a una fase más adelante tendrá
que cumplir una fase inferior. También se pueden llevar fases en
paralelo.
3.2.2.2. DESARROLLO DE LAS FASES

3.2.2.2.1. FASE 1: “DENOMINADO: TOMA DE HISTORIAL DEL
USUARIO” con una duración total de TRES DÍAS
Calendario.
ACTIVIDAD 1.1: DURACIÓN UN DÍA.
Se realizará una reunión con cliente para definir el sus necesidades,
problemas y características del proyecto que se realizará.

Una jungla con equipo para ver y estudiar el problema su alcance el
tiempo en la que se desarrolla, cuanto de presupuesto se utilizara, que
utilizaremos necesitamos para poder desarrollar

Reunión con el cliente para darle las especificaciones de cómo se
realizará su proyecto de cómo y cuánto tiempo tardar el realizarse.
3.2.2.2.2. “DENOMINADO: REPARTICIÓN DE CARGOS Y

TAREAS” con una duración de UN DÍA calendario
Se realizará una junta con el equipo, el director del proyecto tomará las
decisiones de dar los cargos de acuerdo a las características de cada
persona y denominará su rol a realizarse durante el proyecto
3.2.2.2.3. FASE 3: “DENOMINADO: DISEÑO” con una duración de

CATORCE DÍAS calendario
ACTIVIDAD 3.1: DURACIÓN DOS DÍAS
Solo se diseñan aquellas historias de usuario que el cliente ha
seleccionado de la iteración. Reunión con el equipo de trabajo ideas,
opiniones y sugerencias al director de proyecto para llevar el proyecto
de mejor manera.
ACTIVIDAD 3.2: DURACIÓN SEIS DÍAS

Diseño de la base de datos del proyecto.
ACTIVIDAD 3.3: DURACIÓN DOS DÍAS

normalización de la base de datos.
ACTIVIDAD 3.4: DURACIÓN CUATRO DÍAS
Análisis de la base de datos del proyecto. Para la desfragmentación por
modulo, en este contara con cinco módulos.
3.2.2.2.4. FASE 4: “DENOMINADO: CODIFICACIÓN” con una

duración de CINCUENTA DÍAS calendario
ACTIVIDAD 4.1: DURACIÓN DIEZ DÍAS.
Se realizará la codificación del módulo 1 del proyecto




3.2.2.2.5. FASE 5: “DENOMINADO: INSTALACIÓN Y PRUEBAS”

con una duración de DOS DÍAS calendario
Instalación del proyecto en su respectiva área de trabajo
Pruebas utilizando datos reales que proporcione el cliente
3.2.2.2.6. FASE 6: “DENOMINADO: MANTENIMIENTO” con un

periodo de tiempo o rango de uno a dos años.
ACTIVIDAD 5.1: DURACIÓN RANGO DE UNO A DOS AÑOS.
Mientras que el usuario lo sugiera
3.2.2.3. TABLA DE PRECEDENCIAS

Contiene todas las actividades del proyecto en el orden que se ejecutarán.
Clave de Actividad Duración Actividades Responsable

actividad precedentes
0 INICIO --- --- ---
1 Toma de historial Tres días. Project Owner.
del usuario.
2 Repartición de Un día Project Owner
cargos y tareas
3 Diseño Catorce Project Owner
días
4 Codificación Cincuenta Project Owner
días
5 Instalación y Dos días Project Owner
pruebas
6 Mantenimiento De uno a Project Owner
dos años
7 FIN --- --- ---
3.2.2.4. DIAGRAMA DE GANTT
3.2.3. EJECUCIÓN.
 Al culminarse una actividad se debe comunicarse con el TRACKER para
contar con la aprobación necesario y continuar con el proyecto.
 Se guardará en un portafolio las actividades que fueron cumplidas.
Mas…
N° PROBLEMA SOLUCIÓN
1 Surgieran Increencia de datos. Utilizaremos metodologías para la
solución de los datos.
2 Inconsistencia de un dato a otro Buscaremos la concordancia de un
dato con otro.
3 Datos de minería en general Normalizaremos los datos a la
tercera forma de normalización.
4 Horario de dialogo con empleados Un opción de horario 24*7 de la
cerrados. semana.
3.2.4. CONTROL.
Para asegurar la eficacia de la ejecución el director de proyectos asignará las
siguientes personas a cargo de operación de tendrá que cumplir.
 TRACKER (ENCARGADO DE SEGUIMIENTO): controlara el avance de las

tareas.
 COACH (ENTRENADOR): responsable del proceso global.
 CONSULTOR: es un miembro externo del equipo con conocimiento en algún
tema. A quien se atribuye preguntas o dudas en una área o tema específico.
3.2.5. CONCLUSIÓN.
Como resultado del proyecto a realizarse, es posible concluir que existe una relación
más fuerte entre las áreas de trabajo como es de LOGÍSTICA y TESORERÍA, debido
a un factor principal; contar con la aprobación del jefe de logística.
3.2.5.1. CIERRE ADMINISTRATIVO
El Cierre Administrativo del proyecto se realiza al final de cada fase para
documentar la información producida en el proyecto y almacenarla en un medio
seguro y accesible para proyectos subsiguientes. El Cierre Administrativo debe
realizarse también al final del proyecto. Incluye estas actividades:
 CREACIÓN DE LOS ARCHIVOS DEL PROYECTO: se archivan todos

los documentos técnicos producidos por el equipo del proyecto, los
contratos y documentos con respecto al desarrollo del software, el
cronograma de actividades, etc.
 ACEPTACIÓN FORMAL: el Cierre Administrativo busca verificar que el
producto cumple con todos los requerimientos y el cliente del proyecto
aceptó formalmente esto, preferiblemente por escrito.
 LECCIONES APRENDIDAS: son usadas para documentar los éxitos y
fracasos del proyecto. Las realiza el gerente de proyecto con su equipo,
en una sesión especial, preferiblemente fuera de la oficina. El gerente
es responsable de crear un ambiente distendido para que los miembros
del equipo se sientan cómodos de expresar sus opiniones y puedan
comentar qué salió bien y qué salió mal en el proyecto.
3.2.5.2. CIERRE DE CONTRATO

El Project Owner. Dara como aprobado al finalizar cada fase, analizando si
cumple con las especificaciones que el usuario especifico durante su toma de
historial. Hasta la culminación de todas las fases como a cada una de las fases
de su ciclo de vida. De esta forma si tenemos un proyecto que se ejecuta en
fases. Cada una de las fases debe incluir su proceso de aceptación y cierre,
ajustado a sus características concretas. Por tanto, aunque el artículo está
escrito en referencia al proyecto en su conjunto, lo comentado sería igualmente
válido para una fase del mismo.
3.2.5.3. PRODUCTO, SERVICIO O RESULTADO FINAL
El software cumplirá con las siguientes características: que especificamos en
un cuadro. Cada punto será tomado de manera igual llegando a satisfacer lo
más que se puede al cliente. Para la obtención de un resultado final.
PRODUCTO ÚNICO.
EFICACIA EFICIENCIA
Grado de cumplimiento de los objetivos DESCRIBE LA RELACIÓN ENTRE DOS

de la organización, sin referirse al costo MAGNITUDES:
de los mismos. Por esta razón podemos La producción física de un producto
obtener indicadores de eficacia, tanto de (bien o servicio) y Los insumos o recursos
los productos (outputs), o bien de los que se utilizaron para alcanzar ese nivel
resultados ya sea intermedios o finales de producción
(impactos-outcomes)
CALIDAD ECONOMIA
Capacidad de la institución por responder Mide la capacidad de la institución para

en forma consistente, rápida y directa a movilizar adecuadamente sus recursos
las necesidades de los usuarios: financieros para lograr el cumplimiento de
A) Mediciones Indirectas. sus objetivos.
Mejorar los atributos y características de
los productos.
B) Mediciones Directas.
Grado de satisfacción de los usuarios.
3.2.5.4. MIS OBJETIVOS
N° OBJETIVOS
1 Mi objetivo principal es satisfacerle lo mucho más que se pueda cumpliendo
todos mis actividades antes mencionadas.
2
4. ADMINISTRACIÓN DE RIESGOS
4.1. IDENTIFICACIÓN DE RIESGOS

El proceso de análisis para la identificación de riesgos empezará así con identificar las
posibles causas de problemas que el proyecto enfrenta.
Los factores principales identificados como asociados a los riesgos que enfrentan los
proyectos más frecuentemente se relacionan con tres elementos:
 Cometer alguno de los “errores clásicos” de los proyectos informáticos.
 Ignorar los “fundamentos del desarrollo de software”.
 Fallar en la administración activa del riesgo como se describe en este informe
Los “errores clásicos” identificados se clasifican en:
a) Relacionados con la Gente (motivación débil, socavada o inexistente, personal

mediocre o insuficiente capacitado para las tareas asignadas, expectativas poco
realistas tanto del cliente como del equipo de proyecto, falta de un patrocinador
efectivo del proyecto que defina, aclare y defienda oportunamente las acciones
propuestas por el equipo de proyecto).
b) Relacionados con el Proceso (planificación excesivamente optimista, gestión

de riesgos insuficiente, fallas en el contrato, abandono del plan de trabajo al estar
bajo presión).
c) Relacionados con el Producto (requerimientos excesivos, cambios en

Funcionalidad durante el desarrollo, negociación constantemente fluctuante).
d) Relacionados con la Tecnología (síndrome de la panacea: el proyecto no

puede resolver de la noche a la mañana todos los problemas de la organización
asociados a Su área de acción, cambio de herramientas en medio proyecto:
versiones, herramientas complementarias, plataforma).
Complementariamente, en el desarrollo de la capacidad de identificación de riesgos
necesaria para este proceso, podemos considerar la propuesta de clasificación para la
identificación de riesgos en la delineación empírica de seis componentes de riesgo en
el desarrollo de software obtenida mediante una encuesta, que presentamos con los
principales factores de influencia para cada componente:
4.1.1. RIESGOS DE CRONOGRAMACIÓN Y TIEMPO:

referidos a la planeación de actividades y su correspondiente estimación de
esfuerzos:
a) experiencia en métodos de administración de riesgos

b) uso regular continuo de métodos de administración de riesgos
c) dimensión del último proyecto realizado
d) experiencia del líder del proyecto
e) conocimiento y características de la industria (en nuestro caso, del desarrollo de
software)
f) tipo de la aplicación desarrollada
4.1.2. RIESGOS DE FUNCIONALIDAD DEL SISTEMA:

a) análisis de decisiones clave
b) nivel de estandarización de los métodos de administración de riesgos
c) complementariedad y coordinación entre los métodos de administración de
riesgos y los métodos de desarrollo
d) características de la industria
e) entrenamiento del líder de proyecto
f) experiencia del líder de proyecto
4.1.3. RIESGOS DE SUBCONTRATACIÓN:

a) extensión del entrenamiento en administración de proyectos
b) experiencia en la administración de proyectos complejos y/o extensos
c) el tamaño de la organización de software (subcontratista)
4.1.4. RIESGOS DE ADMINISTRACIÓN DE REQUERIMIENTOS

La administración de requerimientos se fortalece con un compromiso en la aplicación
de métodos de administración de riesgos y enfocándose (frecuente, no
esporádicamente), en analizar aquellas partes del plan de proyecto o
especificaciones que se encuentren débilmente definidas.
a) herramientas de administración de proyectos
b) uso de metodología de desarrollo
c) arquitectura del hardware
d) tipo de aplicación
4.1.5. RIESGOS DE USO Y DESEMPEÑO DE LOS RECURSOS

a) experiencia con métodos de administración de riesgos
b) características de la industria
c) el tamaño de la organización de software
4.1.6. RIESGOS DE ADMINISTRACIÓN DEL PERSONAL
a) extensión de la aplicación de los métodos de administración de riesgos
b) nivel de estandarización de los métodos de administración de riesgos
c) características de la industria
d) educación del líder de proyecto
e) arquitectura del hardware (dominio, solidez, experiencia)
f) uso de metodologías de análisis y diseño
El objetivo del proceso será tener una lista de los Riesgos más relevantes que debe
enfrentar el proyecto.
Como ejemplo, veamos la lista de los 10 Riesgos más comunes Incremento no
valorado de funcionalidad
 Perfeccionismo de requerimientos o del desarrollador (“enchapado en oro”)

 Escatimar en la calidad
 Planificación excesivamente optimista
 Diseño inadecuado
 Síndrome de la solución mágica y rápida
 Desarrollo orientado a la investigación
 Personal mediocre
 Fallas en la contratación
 Desacuerdos entre desarrolladores y el cliente
4.2. ANÁLISIS DEL RIESGO
La palabra riesgo ha sido utilizada de manera indistinta para referirse a varias
situaciones diferentes. Para efectos del proceso de administración de riesgos es preciso
diferenciar el concepto de riesgo y su definición básica, del concepto de AMENAZA, la
cual se entiende como la percepción que se tiene de un peligro
Los riesgos se clasifican según los diversos criterios aplicables a cada situación.
Riesgo Subjetivo: Es la percepción particular que una persona posee sobre un riesgo.
Puede tener o no relación directa con la verdadera probabilidad de ocurrencia. Dicha
percepción puede verse afectada por factores como:
 La potencial severidad de sus consecuencias;

 El grado de conocimiento de la persona respecto al riesgo;
 La familiaridad con el riesgo
 Factores sicológicos que predisponen;
 El grado de aversión al riesgo.
Riesgo aceptable: Es el nivel de riesgo subjetivo que un individuo u organización están
dispuestos a aceptar.
Riesgos puros: Son aquellos cuya materialización siempre representarán una pérdida,
nunca una utilidad.
Riesgos especulativos: Pueden producir ganancias o pérdidas. La mayoría de los
riesgos asumidos por las organizaciones son especulativos. Los principios básicos de
la administración de estos dos tipos de riesgos son esencialmente los mismos, pero las
técnicas de administración de riesgos puros se han desarrollado en forma separada de
las de administración de riesgos financieros y especulativos. Esto refleja la tendencia de
muchas empresas que encuentran operacionalmente conveniente para la
administración de cada tipo de riesgo su manejo por diferentes áreas. No obstante, la
frontera entre los dos tipos de riesgos a veces no está claramente definida. Tal es el
caso del riesgo político.
Riesgos estáticos: Son aquellos que siempre están presentes en un sistema ordenado.
Los riesgos de rayo y otros fenómenos naturales son ejemplos de este tipo de riesgos;
los cuales a su vez caen dentro de la categoría de riesgos puros.
Riesgos dinámicos: Son aquellos que cambian y se transforman al ritmo que cambia
el sistema mismo. Los cambios económicos, políticos, sociales, legales, tecnológicos y
ambientales pueden crear nuevos riesgos o modificar los existentes. Los riesgos
dinámicos usualmente son también especulativos, pero incluyen además una categoría
especial de riesgos puros: los riesgos de responsabilidad, los cuales dependen
enteramente del desarrollo de la legislación.
Riesgos fundamentales: Son aquellos que pueden afectar a la totalidad o a la mayor
parte de una sociedad, como son los desastres naturales o factores económicos o
políticos de amplio espectro, como las guerras o la recesión. Las organizaciones
usualmente tienen poco control sobre este tipo de riesgos y su administración se
concentra en reducir sus efectos.
Riesgos particulares: Son aquellos que de manera directa pueden afectar a una
organización, los cuales pueden ser controlables en alguna medida. De acuerdo con el
tipo de amenaza que puede materializarse, se tiene la siguiente clasificación:
Riesgos físicos: incluyen las lesiones o muerte de personas y todas las formas de
pérdida o daño de propiedades. Las causas de pérdidas físicas son usualmente el
resultado de la materialización de peligros comunes, como incendio, explosión,
terremoto, colisión, contaminación, rayo. Etc.; pero también puede ser el resultado del
incendio intencional, robo, actos mal intencionados o daños causados por error humano.
Riesgos de responsabilidad: Los riesgos de responsabilidad pueden provenir de
reclamaciones de los empleados, de los clientes o proveedores y del público en general.
Si bien dichas reclamaciones pueden resultar de factores mencionados en la
clasificación anterior, también pueden relacionarse con los productos o servicios que
presta la empresa, los efectos de la responsabilidad contractual con los clientes,
proveedores u otros y el efecto de regulaciones nacionales o internacionales. —
Riesgos sociales: El efecto de los cambios sociales es una amenaza creciente para
las organizaciones. Esta categoría incluye los cambios en los hábitos de consumo, el
desempleo, la recesión, el vandalismo y todas las manifestaciones de fraude.
Riesgos políticos: Los cambios bruscos en las políticas gubernamentales, las nuevas
legislaciones, las decisiones proteccionistas, los efectos de la inflación, los cambios
bruscos en la política monetaria, la imposición de nuevos aranceles de importación y en
general, todo cambio en las reglas de juego del sector.
Riesgos ambientales: La identificación de los riesgos ambientales implica el
reconocimiento de cambios en el medio ambiente con cierta anticipación. Deberán
considerarse los efectos del clima, el agotamiento de los recursos, la necesidad de elegir
fuentes alternativas de energéticos y la posible necesidad de un cambio en la tecnología.
Riesgos de administración: Una administración deficiente puede tener un efecto
catastrófico en las organizaciones, aunque su costo muchas veces permanezca oculto
hasta que los resultados de una pobre administración se hacen evidentes en los
resultados generales de la organización. Una administración inadecuada se traducirá en
desperdicios, mala planeación, fallas en almacenamiento, errores en la selección y
políticas de personal, etc. Una planeación inadecuada puede determinar la imposibilidad
de la empresa para mantenerse al día con los cambios tecnológicos y administrativos y
un errado desarrollo de nuevos productos, servicios y alternativas, lo cual puede
determinar una irremediable pérdida de mercado.
4.3. ALCANCES DEL PROCESO DE ADMINISTRACIÓN DE RIESGOS
La mayoría de los riesgos descritos anteriormente pueden ser identificados y
administrados. Puede decirse que los riesgos físicos, de responsabilidad, de
interrupción de negocios y administrativos pueden ser directamente manejados por una
organización. Los riesgos sociales, políticos y ambientales rara vez pueden ser
manejados desde el interior de una empresa. Sin embargo, si es posible identificar y
anticipar las consecuencias de estos riesgos y tomar algunos cursos de acción para
reducir la Vulnerabilidad de la organización en sus áreas más sensibles. Antes de
considerar métodos de identificación de riesgos en gran detalle, es de utilidad definir los
propósitos básicos de dicho proceso:
La mayoría de las técnicas usadas en administración de riesgos han sido adaptadas de
otras áreas de la actividad industrial y comercial. Lo que resulta nuevo acerca del
concepto de administración de riesgos es el uso integrado de las técnicas disponibles
para identificar, medir y administrar los riesgos.
Un proceso típico de administración de riesgos consta de los siguientes pasos: su
administración. Si se decide administrarlo, deberán prepararse las siguientes
estrategias:
Prevención: Orientada a reducir la probabilidad de ocurrencia de un evento indeseado.
Ejemplos: manuales de procedimiento, políticas empresariales, capacitación.
Protección: Es el conjunto de acciones, elementos y equipos destinados a reducir las
consecuencias de la materialización de un riesgo, tales como extintores, hidrantes, fosos
de seguridad, rociadores automáticos.
Control: Son las acciones de combate del evento en su más temprana manifestación,
tales como las brigadas de bomberos, los comités de crisis, etc.
Atención: Son aquellas acciones orientadas a recuperar los recursos afectados por un
evento, con el fin de reducir las consecuencias; tales como planes de evacuación,
primeros auxilios, remplazo de personal indispensable, etc.
5. DISEÑO
En XP solo se diseñan aquellas historias de usuario que el cliente ha seleccionado para
la iteración actual por dos motivos: por un lado, se considera que no es posible tener un
diseño completo del sistema y sin errores desde el principio. El segundo motivo es que,
dada la naturaleza cambiante del proyecto, el hacer un diseño muy extenso en las fases
iniciales del proyecto para luego modificarlo, se considera un desperdicio de tiempo
Es importante resaltar que esta tarea es permanente durante la vida del proyecto
partiendo de un diseño inicial que va siendo corregido y mejorado en el transcurso del
proyecto.
Los aspectos que se tratarán a continuación son: simplicidad en el diseño, metáfora del
sistema, tarjetas CRC, spike solution, no solucionar antes de tiempo y refactoring.
5.1. METÁFORA DEL SISTEMA
Una de las partes más importantes de la filosofía XP es la simplicidad en todos los
aspectos. Se considera que un diseño sencillo se logra más rápido y se implementa en
menos tiempo, por lo cual esto es lo que se busca. La idea es que se haga el diseño
más sencillo que cumpla con los requerimientos de las historias de usuario.
Sobre los diagramas, se es muy claro que se pueden usar siempre que no tome mucho
tiempo en realizarlos, que sean de verdadera utilidad y que se esté dispuesto a “tirarlos
a la basura”. En XP se prefiere tener una descripción del sistema o parte de él, en lugar
de una serie de complejos diagramas que probablemente tomen más tiempo y sean
menos instructivos
5.2. TARJETAS DE CLASE, RESPONSABILIDAD, COLABORACIÓN (CRC

CARDS)
Se trata de plasmar la arquitectura de sistema en una “historia” con la cual se le dé al
grupo de desarrollo una misma visión sobre el proyecto además de brindarles un primer
vistazo muy completo a los nuevos integrantes del grupo para hacer su adaptación más
rápida.
Es muy importante dentro del desarrollo de la metáfora darles nombres adecuados a
todos los elementos del sistema constantemente, y que estos correspondan a un
sistema de nombres consistente. Esto será de mucha utilidad en fases posteriores del
desarrollo para identificar aspectos importantes del sistema.
5.3. SOLUCIONES PUNTUALES (SPIKE SOLUTION)

La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento
procedimental para incorporarse al enfoque orientado a objetos. Cada tarjeta representa
una clase con su nombre en la parte superior, en la sección inferior izquierda están
descritas las responsabilidades y a la derecha las clases que le sirven de soporte.
En el proceso de diseñar el sistema por medio de las tarjetas CRC como máximo dos
personas se ponen de pie adicionando o modificando las tarjetas, prestando atención a
los mensajes que éstas se transmiten mientras los demás miembros del grupo que
permanecen sentados, participan en la discusión obteniendo así lo que puede
considerarse un diagrama de clases preliminar.
5.4. NO SOLUCIONAR ANTES DE TIEMPO
En muchas ocasiones los equipos de desarrollo se enfrentan a requerimientos de los
clientes (en este caso historias de usuario) los cuales generan problemas desde el punto
de vista del diseño o la implementación. Spike Solution, es una herramienta de XP para
abordar este inconveniente. Se trata de una pequeña aplicación completamente
desconectada del proyecto con la cual se intenta explorar el problema y propone una
solución potencial. Puede ser burda y simple, siempre que brinde la información
suficiente para enfrentar el problema encontrado.
5.5. REFACTORIZACIÓN (REFACTORING)

Los desarrolladores tienden a predecir las necesidades futuras e implementarlas antes.
Según mediciones, esta es una práctica ineficiente, concluyendo que tan solo el 10% de
las soluciones para el futuro son utilizadas, desperdiciando tiempo de desarrollo y
complicando el diseño innecesariamente. En XP sólo se analiza lo que se desarrollará
en la iteración actual, olvidando por completo cualquier necesidad que se pueda
presentar en el futuro, lo que supone uno de los preceptos más radicales de la
programación extrema.
5.6. REFACTORIZACIÓN (REFACTORING)

Como se trató al principio de este apartado, el diseño es una tarea permanente durante
toda la vida del proyecto y la refactorización concreta este concepto. Como en cualquier
metodología tradicional en XP se inicia el proceso de desarrollo con un diseño inicial. La
diferencia es que en las metodologías tradicionales este diseño es tan global y completo
como se es posible tomando generalmente mucho tiempo en lograrse y con la creencia
de que si se ven forzados a modificarlo será un fracaso para el grupo de desarrollo. El
caso de XP es el opuesto. Se parte de un diseño muy general y simple que no debe
tardar en conseguirse, al cual se le hacen adiciones y correcciones a medida que el
proyecto avanza, con el fin de mantenerlo tanto correcto como simple.
La refactorización en el código pretende conservarlo tan sencillo y fácil de mantener
como sea posible. En cada inspección que se encuentre alguna redundancia,
funcionalidad no necesaria o aspecto en general por corregir, se debe rehacer esa
sección de código con el fin de lograr las metas de sencillez tanto en el código en sí
mismo como en la lectura y mantenimiento.
Estas prácticas son difíciles de llevar a cabo cuando se está iniciando en XP por varios
motivos. En primer lugar, debido el temor que genera en los equipos de desarrollo
cambiar algo que ya funciona bien sea a nivel de diseño o implementación. Sin embargo,
si se cuenta con un esquema de pruebas completo y un sistema de automatización para
las mismas se tendrá éxito en el proceso. El otro motivo es la creencia que es más el
tiempo que se pierde en refactoring que el ganado en sencillez y mantenimiento. Según
XP la ganancia obtenida en refactoring es tan relevante que justifica suficientemente el
esfuerzo extra en corrección de redundancias y funcionalidades innecesarias.
6. CODIFICACIÓN
La codificación es un proceso que se realiza en forma paralela con el diseño y la cual
está sujeta a varias observaciones por parte de XP consideradas controversiales por
algunos expertos tales como la rotación de los programadores o la programación en
parejas.
Además de los mencionados temas, el lector encontrará a continuación una descripción
de los siguientes temas: cliente siempre presente, codificar primero la prueba,
integración secuencial e integraciones frecuentes.
6.1. CLIENTE SIEMPRE PRESENTE.

Uno de los requerimientos de XP es que el cliente esté siempre disponible. No
solamente para solucionar las dudas del grupo de desarrollo, debería ser parte de éste.
En este sentido se convierte en gran ayuda al solucionar todas las dudas que puedan
surgir, especialmente cara a cara, para garantizar que lo implementado cubre con las
necesidades planteadas en las historias de usuario.
6.2. CODIFICAR PRIMERO LA PRUEBA

Cuando se crea primero una prueba, se ahorra mucho tiempo elaborando el código que
la haga pasar, siendo menor el tiempo de hacer ambos procesos que crear el código
solamente.
Una de las ventajas de crear una prueba antes que el código es que permite identificar
los requerimientos de dicho código. En otras palabras, al escribir primero las pruebas
se encuentran de una forma más sencilla y con mayor claridad todos los casos
especiales que debe considerar el código a implementar. De esta forma el desarrollador
sabrá con completa certeza en qué momento ha terminado, ya que habrán pasado todas
las pruebas.
6.3. PROGRAMACIÓN EN PAREJAS

Todo el código debe ser creado por parejas de programadores sentados ambos frente
a un único computador lo que en principio representa una reducción de un 50% en
productividad, sin embargo, según XP no es tal la pérdida. Se entiende que no hay
mucha diferencia, en lo que a la cantidad se refiere, entre el código producido por una
pareja bajo estas condiciones que el creado por los mismos miembros trabajando en
forma separada, con la excepción que uno o ambos programadores sean muy expertos
en la herramienta en cuestión.
Cuando se trabaja en parejas se obtiene un diseño de mejor calidad y un código más
organizado y con menores errores que si se trabajase solo, además de la ventaja que
representa contar con un compañero que ayude a solucionar inconvenientes en tiempo
de codificación, los cuales se presentan con mucha frecuencia.
Se recomienda que mientras un miembro de la pareja se preocupa del método que se
está escribiendo el otro se ocupe de cómo encaja éste en el resto de la clase.
6.4. INTEGRACIÓN SECUENCIAL

Uno de los mayores inconvenientes presentados en proyectos de software tiene que ver
con la integración, sobre todo si todos los programadores son dueños de todo el código.
Para saldar este problema han surgido muchos mecanismos, como darle propiedad de
determinadas clases a algunos desarrolladores, los cuales son los responsables de
mantenerlas actualizadas y consistentes. Sin embargo, sumado al hecho que esto va
en contra de la propiedad colectiva del código no se solucionan los problemas
presentados por la comunicación entre clases.
XP propone que se emplee un esquema de turnos con el cual solo una pareja de
programadores integre a vez. De esta forma se tiene plena seguridad de cuál es la última
versión liberada y se le podrán hacer todas las pruebas para garantizar que funcione
correctamente. A esto se le conoce como integración secuencial.
6.5. INTEGRACIONES FRECUENTES.

Se deben hacer integraciones cada poca hora y siempre que sea posible no debe
transcurrir más un día entre una integración y otra. De esta forma se garantiza surjan
problemas como que un programador trabaje sobre versiones obsoletas de alguna
clase.
Es evidente que entre más se tarde en encontrar un problema más costoso será
resolverlo y con la integración frecuente se garantiza que dicho problema se encuentre
más rápido o aún mejor, sean evitados por completo.
6.6. ESTÁNDARES Y PROPIEDAD COLECTIVA DEL CÓDIGO

Así como se recomienda que la programación se haga siempre en parejas ubicadas en
un único computador, también se aconseja que estas se vayan rotando no solo de
compañero sino de partes del proyecto a implementar, con el fin de que se logre tener
una propiedad colectiva del código. Todos y cada uno de los programadores tienen
suficiente conocimiento del código de los demás de modo tal que en cualquier momento
puedan continuar la codificación que alguien más empezó sin que represente un
traumatismo para nadie.
Uno de los principales motivos por los que se promueve esta práctica dentro de la
programación extrema es la posibilidad que brinda de evitar los cuellos de botella. Si
una pareja de programadores se retrasa debido a inconvenientes no estimados pueden
ser ayudados o reemplazados por otra pareja que al conocer el código no tendrá que
familiarizarse con él.
Para lograr lo anterior se recomienda el establecimiento de estándares en la
codificación, de modo tal que todo el código escrito por el grupo de desarrollo parezca
hecho por una sola persona. No se establecen los aspectos específicos a tener en
cuenta dentro de estos estándares, sin embargo, se aconseja que sean de total
aceptación por parte del equipo.
Si bien en la actualidad existen herramientas de soporte en la integración tales como
CVS2 las cuales ayudan a sobrellevar algunos de los inconvenientes del trabajo en
paralelo, es recomendable prestar atención al mecanismo de integración, para evitar
problemas en el proyecto que reduzcan bien sea la calidad del proyecto o el rendimiento
del equipo de desarrollo.
7. CONTROL DE CALIDAD EN EL SOFTWARE
El concepto de calidad total aplicado por los japoneses como estrategia de desarrollo a
partir de la Segunda Guerra Mundial, con el fin de recuperar su economía y tener una
presencia a nivel internacional, ha empezado a popularizarse a nivel mundial y es el
tema obligado de las naciones, organizaciones, entidades e individuos que buscan
consolidación y presencia en los mercados del mundo.
El concepto de calidad total propende por la búsqueda de la excelencia en lodo lo que
el hombre, la sociedad y las organizaciones realizan. Este concepto puede entonces
aplicarse al desarrollo de sistemas de información basados en equipos de
procesamiento de datos y en programas diseñados por el hombre. Hoy en día las
investigaciones en el área de la ingeniería de software se centran en el desarrollo de
metodologías que garanticen y controlen la calidad en el software construido.
El presente documento busca ilustrar, además del concepto de calidad en el software,
las actividades necesarias para controlar y garantizar la calidad de los sistemas de
información que se implementen. El problema principal para garantizar la calidad en el
software está en la concepción de la gran mayoría de las personas cuando suponen que
la garantía de calidad es algo que se impone bajo una medida que se obtiene al finalizar
un proyecto de software. El control de calidad en el software se fundamenta en el
principio de que la calidad se construye a través de un proceso continuo de desarrollo,
verificación (revisión) y optimización en diferentes etapas.
El control de calidad en el software, denominado SQA ("Software Quality Assurance"),
se basa en las siguientes actividades:
1. Uso de métodos y herramientas de análisis, diseño, codificación y prueba.
2. Revisiones técnicas formales, que se aplican durante cada paso de la Ingeniería de
software.
3. Estrategia de prueba multiescalada.
4. Control de la documentación del software y de los cambios realizados.
5. Procedimientos que aseguren un ajuste a los estándares de desarrollo.
Mecanismos de medida de la calidad ("métricas").
7.1. DEFINICION DE CALIDAD EN EL SOFTWARE
Se han formulado muchas definiciones sobre el concepto de calidad en el software. Para
no transcribir estas definiciones en el presente documento tratemos de responder la
pregunta ¿qué es calidad en el software? Seguramente la primera respuesta en qué
pensaría la mayoría de las personas es: La calidad en el software está en relación
directa con el cumplimiento de los requerimientos formulados por el usuario, de tal forma
que si un programa no cumple con alguno de estos requerimientos es un software de
baja calidad.
Aunque el criterio de cumplimiento de los requerimientos es un factor importante, no es
el único factor, ya que existen condiciones implícitas que el software debe cumplir como
son eficiencia, seguridad, integridad, consistencia, etc.; por lo tanto, no podemos afirmar
que un software es de alta calidad cuando cumple con los requerimientos del usuario,
pero:
 No es eficiente al utilizar los recursos de la máquina (programas muy lentos).
 no es confiable; los resultados que entrega varían, no son siempre iguales al
procesar los mismos datos.
 no es fácil de utilizar.
 no es seguro.
 no es fácil hacerle mantenimiento
La calidad en el software es una mezcla compleja de ciertos factores que varían de
acuerdo con el usuario y con los tipos de aplicación.
Podemos resumir el concepto de la calidad en el software en los siguientes puntos:
1. Los requerimientos del usuario sobren un programa son los fundamentos desde los
que se mide la calidad. La falta de concordancia con estos requerimientos es una
falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que
guían la forma como se aplica la ingeniería de software; si no se siguen estos
estándares, probablemente se obtendrá software de baja calidad.
3. Existe un conjunto de requerimientos implícitos que a menudo no se mencionan
(eficiencia, facilidad de uso, facilidad de mantenimiento).
Si el software falla en alcanzar los requerimientos implícitos, la calidad en el software
queda en entredicho.
Aspecto Factor
Operación del producto Cumplimiento
Exactitud,
Eficiencia
Integridad
Facilidad de uso
Revisión del producto Facilidad de mantenimiento Facilidad de
prueba Flexibilidad
Transición del producto Portabilidad
Reusabilidad
Interoperabilidad
7.2. METRICAS DE CONTROL DE LA CALIDAD EN EL SOFTWARE
Se define como métrica el valor asociado con la respuesta a una pregunta formulada en
una revisión para evaluar o establecer un atributo o un requerimiento de un criterio o su
criterio relacionado con un factor. Por ejemplo:
Un criterio del factor de calidad "Eficiencia “es "Ejecución eficiente" y un atributo de este
su criterio serio "datos agrupados para procesamiento eficiente". En una revisión para
evaluar este su criterio se podría formular la siguiente pregunta: "¿Están los datos
agrupados para permitir un procesamiento eficiente"?
Si la respuesta a la pregunta es "sí", podemos calificar con 1 en la hoja de chequeos
este su criterio; si la respuesta es "no" lo calificamos con O.
El valor de la métrica para el factor de calidad que está siendo juzgado será la suma de
todos los valores obtenidos por criterios/sus criterios divididos por el número de
preguntas aplicadas.
Factor calidad Definición

Cumplimiento El grado en que un programa satisface
sus especificaciones y consigue los
objetivos de la misión encomendada por
el cliente.
Fiabilidad El grado en que se puede esperar que un
programa lleve a cabo sus funciones
esperadas con la precisión requerida.
Eficiencia La cantidad de recursos de hardware y de
código requerido por un programa para
realizar su función.
Integridad El grado en que puede controlarse el
acceso al software o a los datos por
personas no autorizadas
Facilidad de uso El esfuerzo requerido para aprender,
trabajar, preparar la entrada e interpretar
la salida de un programa.
Facilidad de mantenimiento El esfuerzo requerido para localizar y
arreglar un error en un programa.
Facilidad de prueba El esfuerzo requerido para probar un
programa de forma que se asegure que
realiza la función requerida.
Portabilidad El esfuerzo requerido para transferir el
programa desde una configuración de
hardware o sistema operativo a otro.
Reusabilidad El grado en que un programa (o partes de
él) se pueden reutilizar en otras
aplicaciones.
Facilidad de interoperación El esfuerzo requerido para acoplar un
sistema a otro.
Facilidad de auditoría Facilidad con que se puede comprobar la
conformidad con los estándares.
Exactitud La precisión en los cálculos y el control.
Normalización de las comunicaciones. El grado en que se usan el ancho de
banda, los protocolos y las interfaces
estándar:
Completitud El grado en que se ha conseguido la total
implementación de las funciones
requeridas.
Concisión Lo compacto que es el programa en
términos de Líneas de código.
Consistencia El uso de un diseño uniforme y de
técnicas de documentación.
Estandarización datos El uso de estructuras de datos y de tipos
datos estándar.
Tolerancia de errores El daño que se produce cuando el
programa encuentra un error.
Eficiencia en la ejecución El rendimiento en tiempo de ejecución de
un programa.
Facilidad de expansión El grado en que se puede ampliar el
diseño arquitectónico de datos.
Generalidad La amplitud de aplicación potencial de los
componentes del programa.
Independencia del hardware El grado en que el software es
independiente del hardware que usa.
Instrumentación El grado en que el programa muestra su
propio funcionamiento e identifica errores
que aparecen.
Modularidad Independencia funcional de los
componentes del programa.
Facilidad de operación Grado de facilidad de operación.
Seguridad La disponibilidad de mecanismos que
controlen o protejan los programas o los
datos.
Auto documentación El grado en que el código fuente
proporciona documentación significativa.
Simplicidad El grado en que un programa puede ser
entendido sin dificultad.
Facilidad de trazo La posibilidad de seguir la pista de la
representación del diseño de los
componentes reales del programa hacia
atrás.
Formación El grado en que el software ayuda a
permitir que nuevos usuarios apliquen el
sistema.
8. PRUEBAS
XP enfatiza mucho los aspectos relacionados con las pruebas, clasificándolas en
diferentes tipos y funcionalidades específicas, indicando quién, cuándo y cómo deben
ser implementadas y ejecutadas.
Del buen uso de las pruebas depende el éxito de otras prácticas, tales como la propiedad
colectiva del código y la refactorización. Cuando se tienen bien implementadas las
pruebas no habrá temor de modificar el código del otro programador en el sentido que,
si se daña alguna sección, las pruebas mostrarán el error y permitirán encontrarlo. El
mismo criterio se aplica a la refactorización. Uno de los elementos que podría
obstaculizar que un programador cambie una sección de código funcional es
precisamente hacer que este deje de funcionar. Si se tiene un grupo de pruebas que
garantice su buen funcionamiento, este temor se mitiga en gran medida.
Según XP se debe ser muy estricto con las pruebas. Sólo se deberá liberar una nueva
versión si esta ha pasado con el cien por ciento de la totalidad de las pruebas. En caso
contrario se empleará el resultado de estas para identificar el error y solucionarlo con
mecanismos ya definidos.
8.1. PRUEBAS UNITARIAS

Estas pruebas se aplican a todos los métodos no triviales de todas las clases del
proyecto con la condición que no se liberará ninguna clase que no tenga asociada su
correspondiente paquete de pruebas. Uno de los elementos más importantes en estas
es que idealmente deben ser construidas antes que los métodos mismos, permitiéndole
al programador tener máxima claridad sobre lo que va a programar antes de hacerlo,
así como conocer cada uno de los casos de prueba que deberá pasar, lo que optimizará
su trabajo y su código será de mejor calidad.
Deben ser construidas por los programadores con el empleo de algún mecanismo que
permita automatizarlas de modo tal que tanto su implementación y ejecución consuman
el menor tiempo posible permitiendo sacarles el mejor provecho
LOS empleos de pruebas unitarias completas facilitan la liberación continua de
versiones por cuanto al implementar algo nuevo y actualizar la última versión, solo es
cuestión de ejecutar de forma automática las pruebas unitarias ya creadas para saber
que la nueva versión no contiene errores.
8.2. PRUEBAS DE ACEPTACIÓN

Las pruebas de aceptación, también llamadas pruebas funcionales son supervisadas
por el cliente basándose en los requerimientos tomados de las historias de usuario. En
todas las iteraciones, cada una de las historias de usuario seleccionadas por el cliente
deberá tener una o más pruebas de aceptación, de las cuales deberán determinar los
casos de prueba e identificar los errores que serán corregidos.
Las pruebas de aceptación son pruebas de caja negra, que representan un resultado
esperado de determinada transacción con el sistema. Para que una historia de usuario
se considere aprobada, deberá pasar todas las pruebas de aceptación elaboradas para
dicha historia.
Es importante resaltar la diferencia entre las pruebas de aceptación y las unitarias en lo
que al papel del usuario se refiere. Mientras que en las pruebas de aceptación juega un
papel muy importante seleccionando los casos de prueba para cada historia de usuario
e identificando los resultados esperados, en las segundas no tiene ninguna intervención
por ser de competencia del equipo de programadores.
8.3. CUANDO SE ENCUENTRA UN ERROR

Al momento de encontrar un error debe escribirse una prueba antes de intentar
corregirlo. De esta forma tanto el cliente logrará tener completamente claro cuál fue y
dónde se encontraba el mismo como el equipo de desarrollo podrá enfocar mejor sus
esfuerzos para solucionarlo. Por otro lado, se logrará evitar volver a cometerlo.
Si el error fue reportado por el cliente y este creó la correspondiente prueba de
aceptación junto al equipo de desarrollo, el programador encargado podrá a su vez
producir nuevas pruebas unitarias que le permita ubicar la sección específica donde el
error se encuentra.
9. CONCLUSIONES
Nuestras experiencias en desarrollo de proyectos son muy amplias y reconocidas. La
elección y aplicación de esta metodología dadas las características del problema que
presenta el usuario. Resultará positivos en términos de satisfacción del cliente,
cumplimiento de los plazos que establecemos y un buen ambiente de trabajo.
encontramos que la metodología se ajustara muy bien al problema del cliente y a las
características del problema, también se adecuada para el entorno de trabajo y las
características de los desarrolladores.
La metodología de trabajo presenta aspectos positivos y negativos en su aplicación,

pero sirven como puntos de referencia para proyectos de similares.
10. RECOMENDACIONES
 Debe hacerse lo posible por no realizar modificaciones a XP demasiado
drásticas ya que se corre el riesgo de alterar la esencia de la metodología.
 Debe plantearse una estrategia para afrontar el diseño de datos en XP.
 Se deben fijar una serie de reglas generales en la comunicación con el cliente
ya que por el grado de informalidad que la metodología presenta, pueden surgir
diferencias que pongan en peligro la culminación exitosa del proyecto.
 Debe hacerse una capacitación al cliente sobre XP antes de iniciar el proyecto
debido que este hace parte del equipo de desarrollo.
 Plantear una estrategia especial de refactoring para las bases de datos.
 Tener un buen conocimiento de las herramientas para la implementación antes
de iniciar dicha etapa.
 Plantear como unidad de tiempo horas en lugar de días para la asignación de
tareas.
 Considerar el internet y herramientas basadas en él como mecanismos de
comunicación válidos dentro de XP y discutir la necesidad de un único sitio
geográfico de trabajo.
 Hacer una experiencia realizando un mismo proyecto por dos grupos de
desarrollo independientes empleando una metodología pesada y XP con el fin
de comparar los resultados obtenidos.
 Emplear XP en un proyecto de mayor envergadura con el fin de evaluar el
desempeño de la metodología en ese tipo de proyectos.

PRESENTACIÓN Desarrollo de Un Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PRESENTACIÓN Desarrollo de Un Software

Cargado por

Copyright:

Formatos disponibles

“Año del buen servicio al ciudadano”

 Robit Cotarma Torres

DEPARTAMENTO DE APURÍMAC - PROVINCIA ANDAHUAYLAS – DISTRITO DE PACUCHA

ROBIT COTARMA TORRES

UNIVERSIDAD NACIONAL JOSÉ MARÍA ARGUEDAS

Andahuaylas, lunes 06 de noviembre de 2017.

 Realizar un software utilizando la metodología ágil XP a través del desarrollo de

 Consultar acerca de la metodología XP para el desarrollo del software.

El proyecto titulado SISTEMA DE CONTROL DEL GRIFO MUNICIPAL desarrollado

El Proyecto fue desarrollado mediante la aplicación de la metodología Procesos

El grifo municipal es un instrumento que le permite provisión y comercialización de

1.4.3. ENCARGADO DE PRUEBAS (TESTER)

1.4.4. ENCARGADO DE SEGUIMIENTO (TRACKER)

1.4.5. ENTRENADOR (COACH)

1.4.7. GESTOR (BIG BOSS)

Fig. 1 Evolución de los largos ciclos de desarrollo en cascada (a) a

1.6.1. FASE I: EXPLORACIÓN

1.6.2. FASE II: PLANIFICACIÓN DE LA ENTREGA

1.6.3. FASE III: ITERACIONES

 historias de usuario no abordadas,

1.6.4. FASE IV: PRODUCCIÓN

1.6.6. FASE VI: MUERTE DEL PROYECTO

1.7. REGLAS Y PRÁCTICAS

 Reglas y prácticas para la Planificación

1.7.1.1. LAS HISTORIAS DE USUARIO

1.7.1.2. PLAN DE ENTREGAS (“RELEASE PLAN”)

1.7.1.3. PLAN DE ITERACIONES (“ITERATION PLAN”)

1.7.1.4. REUNIONES DIARIAS DE SEGUIMIENTO (“STAND-UP

1.7.3.1. DISPONIBILIDAD DEL CLIENTE

1.7.3.2. USO DE ESTÁNDARES

1.7.3.3. PROGRAMACIÓN DIRIGIDA POR LAS PRUEBAS (“TEST-

 Adicionalmente, la programación en pares tiene las siguientes ventajas:

1.7.3.5. INTEGRACIONES PERMANENTES

1.7.3.6. PROPIEDAD COLECTIVA DEL CÓDIGO

1.7.4.3. PRUEBAS DE ACEPTACIÓN

 Se consiguen productos usables con mayor rapidez.

2.3. DESCRIPCIÓN DE CLIENTE Y USUARIO

El proyecto consiste en el DESARROLLO DE UN SISTEMA DE ADMINISTRACIÓN Y

3.2. FASES DE LA ADMINISTRACIÓN DE PROYECTOS:

3.2.1.2. CARTA DE PROYECTO

CARTA DEL PROYECTO

3.2.2.2. DESARROLLO DE LAS FASES

ACTIVIDAD 1.2: DURACIÓN UN DÍA.

ACTIVIDAD 1.3: DURACIÓN UN DÍA.

3.2.2.2.2. “DENOMINADO: REPARTICIÓN DE CARGOS Y

3.2.2.2.3. FASE 3: “DENOMINADO: DISEÑO” con una duración de

ACTIVIDAD 3.2: DURACIÓN SEIS DÍAS

ACTIVIDAD 3.3: DURACIÓN DOS DÍAS

3.2.2.2.4. FASE 4: “DENOMINADO: CODIFICACIÓN” con una

ACTIVIDAD 4.2: DURACIÓN DIEZ DÍAS.

ACTIVIDAD 4.3: DURACIÓN DIEZ DÍAS.

ACTIVIDAD 4.4: DURACIÓN DIEZ DÍAS.

ACTIVIDAD 4.5: DURACIÓN DIEZ DÍAS.

3.2.2.2.5. FASE 5: “DENOMINADO: INSTALACIÓN Y PRUEBAS”

3.2.2.2.6. FASE 6: “DENOMINADO: MANTENIMIENTO” con un

3.2.2.3. TABLA DE PRECEDENCIAS

Clave de Actividad Duración Actividades Responsable

 TRACKER (ENCARGADO DE SEGUIMIENTO): controlara el avance de las

 CREACIÓN DE LOS ARCHIVOS DEL PROYECTO: se archivan todos

3.2.5.2. CIERRE DE CONTRATO

Grado de cumplimiento de los objetivos DESCRIBE LA RELACIÓN ENTRE DOS

Capacidad de la institución por responder Mide la capacidad de la institución para

3.2.5.4. MIS OBJETIVOS

4.1. IDENTIFICACIÓN DE RIESGOS