CAPITULO Iv

Oliveros Ocrospoma Miguel Angel
CAPITULO IV: DESARROLLO

En este captulo se desarrollaran los objetivos propuestos para este trabajo.
1. ANLISIS DE LOS PROCESOS DE DESARROLLO DE SISTEMAS
INFORMTICOS EN EL PROYECTO ESPECIAL SIGA DEL
MINISTERIO DE ECONOMA Y FINANZAS DEL PER

METODO:

A. REVISIN DE DOCUMENTACIN:
Para el desarrollo del presente mtodo se realizar la revisin de
toda la documentacin oficial de los 5 ltimos proyectos de
desarrollo de sistemas informticos en el proyecto especial SIGA
del Ministerio de Economa y Finanzas del Per.

CONCLUSIONES:
No existe documento alguno en el cual se tenga
informacin respecto al cronograma y recursos utilizados
en los proyectos.
En los proyectos revisados, slo existen 3 documentos:
documento de anlisis funcional, documento de anlisis de
sistema y documento de pase a produccin.
Existe un grupo de personas que realizan pruebas de
calidad, sin embargo no existe un documento de pase a
calidad ni de anlisis de calidad, tanto el pase como las
observaciones y aprobacin final por parte de calidad se
manejan a travs de correo electrnico.
No se cuenta con una plantilla de ejemplo y/o gua para el
llenado de estos 3 documentos, ya que en todos los casos
dichos documentos difieren; en cuanto a estructura; unos
de otros.
El documento de anlisis funcional slo contiene los
requerimientos funcionales del proyecto, los cuales en
muchos de los casos son ambiguos y no se encuentran
debidamente especificados.
El documento de anlisis de sistema contiene:
o Diagrama de Casos de Uso: los cuales, en los
proyectos revisados, se encuentran mal definidos.
o Prototipos: los cuales aparentemente fueron hechos
despus del desarrollo ya que son captura de las
pantallas desarrolladas.

o Diagrama de Clases: los cuales difieren en su
diseo unos de otros, ya que algunos tienen
solamente el nombre de la Clase, otros incluyen
atributos y hay algunos que tambin incluyen los
mtodos.
La mayora de los documentos de anlisis de sistema
parecen haber sido realizados despus del desarrollo del
software.
El documento de pase a produccin contiene escasa
informacin relevante as como carecer de mecanismos de
regresin en casos de falla.

B. OBSERVACIN
Para el desarrollo del presente mtodo se observar la forma de
trabajo de 3 proyectos, actuales, de desarrollo de sistemas
informticos en el proyecto especial SIGA del Ministerio de
Economa y Finanzas del Per.

CONCLUSIONES:
Los proyectos no cuentan con una metodologa estndar
para ser gestionados de manera integral ni tampoco en
ninguna de las fases del ciclo de vida de estos.
No existen polticas ni estndares oficiales aplicables a los
proyectos.
Los proyectos no pasan un filtro previo, dentro del equipo
SIGA, antes de ser aceptados. Con esto se pierde el
enfoque de apoyo a las metas y objetivos estratgicos
institucionales por parte del equipo. Actualmente se est
desarrollando un proyecto que por el negocio y enfoque del
mismo debi ser asignado a otro equipo de trabajo.
No existe una adecuada gestin de recursos ya que estos
son tomados de manera aleatoria generando sobrecarga
en muchos de ellos y holgura en otros. Los recursos
muchas veces desempean ms de un rol en los proyectos
a los cuales son asignados.
No se gestionan los riesgos de los proyectos.
Los tiempos no son gestionados adecuadamente. En la
mayora de proyectos slo se tiene una fecha estimada de
culminacin la cual no se encuentra debidamente
documentada.
Los proyectos no cuentan con un documento que ayude a
definir el alcance claramente, existe un documento de
requerimientos funcionales el cual nicamente cuenta con

un listado requerimientos funcionales que en su mayora
suelen ser redundantes y algunos son ambiguos.
No se cuenta con un diagrama de procesos tanto actual
como propuesto.
El documento de anlisis de sistemas es hecho despus
del desarrollo del software y es visto como una prdida de
tiempo.
No se tiene conocimiento claro de cmo hacer los
requerimientos de sistema, los diagramas y artefactos
incluidos en el documento de anlisis.
No se cuenta con un documento de diseo de sistemas.
Todos los proyectos desarrollados cuentan los mismos
frameworks (zk, spring, hibernate), sin embargo no cuentan
con una arquitectura ni estructura estndar, as mismo los
estilos del diseo de las pantallas difiere entre uno y otro y
el cdigo no se encuentra documentado.
Existen muchos problemas en la integracin de sistemas
sobretodo desarrollados entre los 2 principales equipos de
desarrollo del MEF, los cuales son el equipo SIGA y el
equipo SIAF, esto se debe a que los proyectos de ambos
equipos requieren consumir datos de las bases de datos
de estos, y el problema reside en que los cdigos y
nomenclaturas de muchos de estos no se encuentran
estandarizados por lo cual cada equipo define estos a su
parecer generando problemas a futuro como los que se
tienen actualmente. Estos problemas hasta el momento
han ocasionado perdida de informacin en produccin as
como la generacin de data inconsistente y sancin al
personal de ambos equipos.
Cuando un nuevo recurso es asignado a un proyecto en
curso o a darle mantenimiento a un sistema, este tiene una
curva de aprendizaje demasiado alta ya que no se cuenta
con documentacin suficiente que facilite su adaptacin y
familiarizacin con el proyecto ya que debe leer todo el
cdigo e interpretarlo, lo cual adems de generar retraso
tambin genera inconsistencia y cdigo redundante.
Cuando se culmina el desarrollo, se convoca a una reunin
con los miembros del equipo de control de calidad y se les
explica cmo funciona el software, en base a esto y al
conocimiento del negocio que tienen, los miembros de
calidad, ellos piden que se les genere un link para que
puedan hacer sus pruebas.

No se cuenta con un documento de plan de pruebas, todas
las pruebas realizadas son funcionales.
Si el personal de calidad encuentra un error ellos lo
registran en un sistema de control de errores en el cual
describen el error y adjuntan una captura de pantalla, y
posteriormente envan un correo al desarrollador
informndole que han registrado errores.
Muchas veces registran sus propuestas de mejora, como si
fuesen errores.
Una vez que ya se levantaron todas las observaciones
registradas, el personal de calidad comunica al
desarrollador que ya no existen ms observaciones y
envan un correo dando su conformidad para que se
realice el pase a produccin.
Antes de realizar el pase a produccin el desarrollador
hace la documentacin de anlisis de sistema, luego
continan con el llenado del formato de pase a produccin
el cual nicamente cuenta con 4 puntos.
En paralelo, al punto anterior, se asigna un documentador
para que realice el manual del sistema.
Una vez ejecutado el pase a produccin, por parte del
personal de produccin, estos envan el enlace generado
de la aplicacin para que el equipo SIGA verifique y de su
conformidad.

C. ENCUESTAS
Para el desarrollo del presente mtodo se realizarn 2 encuestas;
la primera ser aplicada a los jefes y coordinadores de proyectos
y la segunda al resto del personal entre los cuales se encuentran
los analistas, diseadores, desarrolladores, testers y
documentadores; a los miembros del proyecto especial SIGA del
Ministerio de Economa y Finanzas del Per, las encuestas son
las siguientes:

Las encuestas aplicadas deben de ir en anexos

Datos generales:
Nombres y apellidos
Nmero de DNI
Edad
Profesin

Aos de experiencia laboral en proyectos de desarrollo de
software.

Encuesta 1:

Qu cantidad de proyectos suelen manejar en paralelo?
De qu manera gestionan los proyectos?
Asigna prioridades a los proyectos? En caso de ser
afirmativa la respuesta, especifique en que se basa para
asignar las prioridades y en que escala estn.
De qu forma asignan los recursos disponibles a cada
proyecto?
Utilizan una metodologa estndar para gestionar cada
proyecto?
Qu indicadores utiliza para evaluar el rendimiento de
cada proyecto?
En caso de utilizar indicadores, Los indicadores utilizados
son los mismos para todos los proyectos? En caso de que
no sea as explique por qu y de forma varan.
En caso de utilizar indicadores, Qu porcentaje de stos
son entregados en promedio?
En caso de utilizar indicadores, Cules de los indicadores
son los que menos se entregan y en qu porcentaje estn?
La manera en que gestionan los proyectos le permite
tener una visin clara del rendimiento de cada uno de
estos y a su vez ver el resultado reflejado en trminos de
rentabilidad?
Tiene conocimiento de ontologa? En caso que la
respuesta sea afirmativa, describir que es una ontologa.
Actualmente, Utilizan ontologas en sus proyectos?
Cree que es necesario contar con una capa de ontologa
en los proyectos que desarrollan? En caso de ser
afirmativa, indique Qu resultados espera obtener con la
aplicacin de ontologas en sus proyectos?
Cuentan con un documento de lecciones aprendidas?
Toman en cuenta los objetivos y estrategias
organizacionales durante el desarrollo de cada proyecto?
En caso de ser afirmativa su respuesta, diga de qu forma
alinean ambos.

Encuesta 2:


Qu rol desempea en los proyectos a los cuales est
asignado?
Alguna vez ha desempeado ms de un rol en un mismo
proyecto? En caso de ser una respuesta afirmativa, indique
cuales son aquellos roles por proyecto.
Tiene una metodologa de trabajo definida?
En caso de tener metodologa, Indique cul es y describa
brevemente sus procesos.
En todos los proyectos, en los cuales ha participado
asumiendo el mismo rol, se ha seguido el mismo proceso?
En caso de ser negativa la respuesta anterior, Indique por
qu no se ha seguido el mismo proceso?
Alguna vez ha utilizado una metodologa de desarrollo de
software?
En caso de ser afirmativa la respuesta a la pregunta
anterior, indique Cul(es) es/son la(s) metodologa(s) que
utiliz y cul es su opinin respecto a esta(s)?
Tiene conocimiento de ontologa? En caso que la
respuesta sea afirmativa, describir que es una ontologa.
Alguna vez ha diseado o desarrollado ontologas?
Actualmente, Utilizan ontologas en sus proyectos?

Conclusiones:

En lugar de recomendaciones debemos de tener tabulados los
resultados de las encuestas para luego hacer un anlisis y tener las
recomendaciones que nos lleven al marco de trabajo a proponer, todo
esto luego del anlisis de las metodologas estandares.

RECOMENDACIONES:
1. Se debe definir un modelo a medida para la gestin de proyectos de
desarrollo de sistemas de informacin en el equipo SIGA acorde a su
realidad.
2. Se debe capacitar al personal en el uso del modelo.
3. Se debe de contar con un filtro previo a la aceptacin de un proyecto,
el cual deba contemplar que los proyectos a desarrollarse se alineen
con los objetivos estratgicos del equipo SIGA.
4. Se debe tener un plan de proyecto el cual permita manejar y
gestionar adecuadamente el tiempo, costo y alcance del proyecto.
5. Se debe de manejar una matriz de riesgos del proyecto.
6. Se deben definir los roles y sus respectivas responsabilidades.

7. Se debe contar con una matriz de trazabilidad para la compatibilidad
de los roles que puede asumir un mismo recurso dentro de un
proyecto.
8. Se deben definir entregables como parte del modelo y tener plantillas
de estos con instrucciones que faciliten su llenado.
9. Se debe contar con actas de reuniones y conformidad que sustenten
el avance del proyecto.
10. Se debe contar con un documento que permita tener una visin
general del proyecto que sea entendible sin necesidad de tener
detalles tcnicos.
11. Se debe contar con un documento de lnea base del proyecto a
travs del cual se tenga una visin del estado del proyecto.
12. Se debe contar con un diagrama de proceso del negocio.
13. Se debe contemplar, como parte del modelo, un proceso de anlisis
y construccin de ontologas para resolver el problema de la
integracin de los diferentes sistemas desarrollados por el equipo
SIGA.
14. Se debe contar con un documento de anlisis de software.
15. Se debe contar con un documento de diseo de software.
16. Se debe contar con un plan de pruebas.
17. Se debe contar con un documento de ejecucin de pruebas en el
cual se documente la ejecucin y resultado de cada prueba
realizada.
18. Se debe contar con un instructivo de configuracin e instalacin del
software, en el cual se deba incluir un mecanismo de regresin.
19. Se debe contar con una plantilla y estructura estndar para la
elaboracin de los manuales de usuario.

2. ANLISIS DE LAS METODOLOGAS ESTNDARES DE GESTIN Y
DESARROLLO DE PROYECTOS Y DE ANLISIS Y DESARROLLO
DE ONTOLOGAS PARA SISTEMAS INFORMTICOS

METODO:
Anlisis de lectura.

OPM3:
o OPM3 es el primer modelo de su clase, que describe
las mejores prcticas para la gestin de proyectos, gestin
de programas, y gestin de carteras en un modelo de
madurez. se alinea con el PMBOK, un estndar aceptado
globalmente para la gestin de proyectos. Nos permite:

o Ganar conocimiento sobre lo que constituye las
mejores prcticas en la gestin de organizacional de
proyectos.
o Medir el nivel de madurez actual de la gestin de
proyectos en la organizacin.
o Identificar una trayectoria para el mejoramiento
continuo, basada en el conocimiento de las mejores
prcticas y en el nivel de madurez actual de la gestin de
proyectos de la organizacin.
(Colocar las citas a la referencia bibliogrfica)

UPMM:
o UPMM es un modelo desarrollado sobre PMS
(Portfolio Management Standar) y OPM3, abordando y
cubriendo completamente las reas de gestin de portafolio
extendidas tanto del modelo OPM3 como del PMS. Este
modelo a dado mejores resultados al ser aplicado para
portafolio de proyectos comerciales como de inversin.
Este modelo permite realizar un cambio organizacional , en
la gestin de portafolio de proyectos, con las siguientes
caractersticas:
o Cambiar en el camino los componentes que son
mejorados. Moviendo recursos entre los componentes.
o Cambios en la composicin del portafolio. Cerrando
los componentes que no tienen posibilidad de conseguir la
meta para la cual fue creado.
o Sugerencias para una modificacin estratgica.
Permite concentrarse en las actividades de la organizacin
sobre una de las metas estratgicas.

CONCLUSIONES:

Habiendo analizado ambos modelos y tomando en cuenta
que la presente tesis est enfocada a brindar una solucin a
empresas del sector micro financiero, se puede rescatar 2
puntos relevantes:
El modelo OPM3 ha sido desarrollado tomando en cuenta la
realidad de grandes y medianas empresas en el mundo,
motivo por el cual la cantidad de recursos requeridos y los
puntos a implementar as como grado de experiencia y
conocimientos sobre PMBOK de los miembros de estos, lo

hace poco adaptable al tipo de empresa a la cual nos
enfocamos.
El modelo UPMM por ha sido desarrollado en base a OPM3
presenta un diseo ms flexible y acorde con empresas
medianas y pequeas pero no ha sido enfocado para la
gestin de proyectos informticos puesto que su aplicacin en
el mercado mundial se ha dado mayormente en proyectos
comerciales y de inversin.

RECOMENDACIONES:
Se recomienda utilizar el modelo OPM3 como base puesto
que es ms completo y se puede abstraer de las mejores
prcticas y adaptarlas a las empresas del sector micro
financiero acorde a las caractersticas que estas presentan.
Sin embargo tambin se debe utilizar como apoyo el modelo
UPMM puesto que por el hecho de haber sido desarrollado
orientado a empresas medianas y pueden tener
caractersticas que se adapten adecuadamente a las
empresas micro financieras.

3. ELABORACIN DE LA PROPUESTA DE MODELO DE GESTIN DE
PROYECTOS DE DESARROLLO DE SISTEMAS INFORMTICOS
BASADOS EN ONTOLOGAS EN EL PROYECTO ESPECIAL SIGA
DEL MINISTERIO DE ECONOMA Y FINANZAS DEL PER

METODO:
Implementacin

RESULTADO:
Modelo de Gestin de Proyectos de Desarrollo de Sistemas
Informticos Basados en Ontologas en el Proyecto Especial
SIGA del Ministerio de Economa y Finanzas del Per:

3.1. Roles/ Responsabilidades:
En este punto definiremos los roles que deben existir en los
proyectos a desarrollarse, as como la descripcin de sus
responsabilidades.

3.1.1. Jefe/coordinador del proyecto especial SIGA:
Cdigo: JC

Responsabilidades:
Recibir la carta de solicitud de proyecto, y dar el
visto bueno de la viabilidad o no viabilidad del
proyecto, en una primera fase.
Es el Stakeholder con mayor influencia en el
proyecto, por parte del equipo del proyecto
especial SIGA.
3.1.2. Jefe de Proyecto
Cdigo: JP
Responsabilidades:
Identificar inicialmente si un proyecto es o no
viable.
Es el principal responsable de la elaboracin,
actualizacin adecuada y cumplimiento del plan
de proyecto.
Asegurar la calidad del proyecto revisando el
cumplimiento del modelo y los estndares
definidos por el proyecto especial SIGA. Este
aseguramiento lo deber realizar sobre el trabajo
desarrollado por el resto del equipo de proyecto y
sobre el trabajo desarrollado por los jefes de
proyectos de los dems proyectos.
3.1.3. Analista de Sistemas
Cdigo: AS
Responsabilidades:
Comprender y plasmar los requerimientos del
usuario en los diversos documentos y diagramas
comprendidos dentro del modelo.
3.1.4. Desarrollador
Cdigo: DS
Responsabilidades:
Desarrollar el cdigo fuente del software, hacer
determinadas pruebas de calidad y actualizar los
documentos de diseo del proyecto.
3.1.5. Tester
Cdigo: TS
Responsabilidades:
Desarrollar el plan de pruebas del proyecto y
realizar la mayor parte de pruebas.
3.1.6. Documentador
Cdigo: DC
Responsabilidades:

Elaborar el instructivo de configuracin e
instalacin y el manual de usuario.
Capacitar al responsable del rea usuaria.
3.1.7. Stakeholder
Cdigo: ST
Responsabilidades:
Son los interesados en el proyecto tanto por
parte de los usuarios como del proyecto especial
SIGA.
3.1.8. Capacitador del rea usuaria
Cdigo: CU
Responsabilidades:
Es la persona, designada por la parte usuaria,
que ser capacitada el documentador del
proyecto.
Realizar la capacitacin al resto de usuarios.
3.2. Matriz de compatibilidad de Roles:
En este punto se define la compatibilidad entre los roles
que puede asumir un mismo recurso dentro de un proyecto.
Aquellas casillas que se encuentran en color verde indican
que los roles son compatibles y aquellas que se encuentran
en color rojo indican que no son compatibles.
ROL JC JP AS DS TS DC ST CU
JC SI NO NO NO NO NO SI NO
JP NO SI SI NO NO NO SI NO
AS NO SI SI SI NO NO SI SI
DS NO NO SI SI NO SI SI SI
TS NO NO NO NO SI NO SI NO
DC NO NO NO SI NO SI SI SI
ST SI SI SI SI SI SI SI SI
CU NO NO SI SI NO SI SI SI

3.3. Documentos:
En este punto definiremos los documentos que se utilizarn
en el modelo, estos se dividen en 3 grupos:

3.3.1. Entregables:
Son los documentos que contendrn toda la informacin
del proyecto de inicio a fin.

3.3.1.1. Carta de solicitud:
Cdigo: No tiene
Propsito:

Solicitar el inicio de un proyecto, por parte del
usuario.

3.3.1.2. Visin general:
Cdigo: E1_<NomProyecto>_SIGA-MEF
Propsito:
Permitir mostrar la visin de alto nivel del
proyecto para poder determinar su viabilidad.

3.3.1.3. Lnea Base:
Propsito:
Contener actualizadas las lneas base de tiempo,
costos, alcance del proyecto y la matriz de
riesgos.

3.3.1.4. Anlisis del Software:
Propsito:
Proporcionar los casos de uso y sus
especificaciones y los prototipos acorde a los
estndares definidos por el equipo del proyecto
especial SIGA.

3.3.1.5. Plan de pruebas:
Propsito:
Proporcionar las pruebas a realizarse en el
proyecto y las fechas en que estas sern
desarrolladas.

3.3.1.6. Diseo de Software:
Propsito:
Proporcionar la arquitectura del software y los
diagramas y artefactos necesarios para su
desarrollo.

3.3.1.7. Documento de ejecucin de pruebas:
Propsito:
Documentar las pruebas realizadas al software.

3.3.1.8. Instructivo de configuracin e instalacin:

Propsito:
Brindar las instrucciones necesarias para poder
configurar el ambiente de produccin en el cual
se instalar el software y realizar la instalacin
del software adecuadamente.

3.3.1.9. Manual de usuario:
Propsito:
Brindar la informacin necesaria para hacer un
adecuado uso del software.

3.3.2. Actas obligatorias:
Es la documentacin que sustenta todo lo acordado y
aceptado en el proyecto de inicio a fin.

3.3.2.1. Acta de aprobacin del proyecto:
Cdigo: AA1_<NomProyecto>_SIGA-MEF
Propsito:
Sustentar la aprobacin del proyecto por parte de
los principales Stakholder.

3.3.2.2. Acta de aprobacin del plan de pruebas:
Propsito:
Sustentar la aprobacin de las pruebas que se
realizarn al sistema.

3.3.2.3. Acta de aprobacin de Hitos y Entregables:
Propsito:
Sustentar la aprobacin de los entregables y las
fechas de entrega de estos.

3.3.2.4. Acta de conformidad de pruebas internas:
Propsito:
Sustentar la conformidad de las pruebas
realizadas al sistema, por parte del equipo de
trabajo.

3.3.2.5. Acta de conformidad de capacitacin:

Propsito:
Sustentar la conformidad de la capacitacin
brindada al usuario.

3.3.2.6. Acta de conformidad instalacin del
software:
Propsito:
Sustentar la conformidad en el proceso de
instalacin del sistema.

3.3.2.7. Acta de cierre de proyecto:
Propsito:
Sustentar la aceptacin del sistema por parte de
todos los Stakeholder.

3.3.2.8. Acta de conformidad del avance:
Propsito:
Sustentar la conformidad del avance presentado
por hito.

3.3.3. Actas complementarias:
Es la documentacin que sustenta las reuniones y
acuerdo realizados en temas especficos que no se
encuentran contemplados dentro de las actas
obligatorias.
Estas actas tienen un cdigo asignado segn la
siguiente nomenclatura:
AR<nroCorrelativo>_<NomProyecto>_SIGA-MEF

3.4. Fases:
En este punto definiremos las 4 fases en las que se divide
el modelo:

3.4.1. Fase de inicio
En esta fase se inicia el proceso del Modelo, tiene como
propsito principal determinar la viabilidad del proyecto
y en base a ello generar el plan de proyecto.

3.4.2. Fase de anlisis

Esta fase tiene como propsito principal dotar al
proyecto del detalle necesario para poder iniciar su
construccin y pruebas.

3.4.3. Fase de construccin
Esta fase tiene como propsito el ejecutar lo planificado
en base al detalle de las especificaciones generadas en
la fase de anlisis, en esta fase se realiza la
construccin del software as como las pruebas de
calidad.

3.4.4. Fase de transicin
Esta fase tiene como propsito principal traspasar el
producto de construccin hacia el ambiente de
produccin.

3.5. Procesos:
En este punto definiremos los procesos agrupados por
cada una de las fases del modelo.

3.5.1. Fase de inicio:
Esta fase cuenta con 5 procesos:

3.5.1.1. Recepcin de Carta
Actor:
Jefe/coordinador del proyecto especial SIGA
Entrada:
Carta de solicitud
Salida:
Jefe de proyecto asignado
Descripcin:
Este proceso incluye el ingreso de la carta al
proyecto especial SIGA y la asignacin del jefe de
proyecto, para que elabore la visin general de la
solicitud.

3.5.1.2. Determinacin de la Visin General de la
Solicitud
Actor:
Jefe de proyecto
Entrada:
Carta de solicitud
Salida:

E1_<NomProyecto>_SIGA-MEF.doc
Tiempo estimado:
Este proceso debe tomar como mximo tres (3) das
hbiles contados a partir de la asignacin del jefe de
proyecto.
Descripcin:
Esta actividad es un primer acercamiento con el
usuario para saber en qu consiste el requerimiento
mencionado en la carta.
Es necesario determinar, en trminos generales, qu
desea la parte usuaria, con qu urgencia lo necesita
y qu tipo de solicitud se est haciendo.
Para aprobar el desarrollo del proyecto, es necesario
que:
El proyecto se alinee con al menos un
objetivo estratgico del rea usuario o
institucional.
La solicitud amerite desarrollo, ya sea inicial o
de modificacin.
En caso no cumplir estos requisitos, el proyecto ser
declarado como no viable y se responder la carta
comunicando lo antes mencionado.
Recomendacin:
Normar que el nmero mximo de reuniones con el
usuario sea 2.

3.5.1.3. Gestin de Lineamientos del Proyecto
Actor:
Jefe de proyecto
Entrada:
Salida:
Tiempo estimado: Mximo 5 das hbiles.
Descripcin:
El propsito de la gestin de lineamientos es contar
con las tres lneas base del proyecto: Lnea de
Alcance, Lnea de Costo y Lnea de Tiempo.
La lnea de Alcance:
Una vez definida la visin general del
proyecto, es necesario determinar el alcance
del proyecto, para esto se realizar un
levantamiento de requerimientos a alto nivel y

definicin de proceso. Se necesita adjuntar
flujograma (primera versin).
La lnea de Tiempo:
La lnea del tiempo consiste en la realizacin
de un cronograma de trabajo para las fases
de Elaboracin, Construccin y Transicin.
La lnea de Costo:
La lnea de costo debe cubrir los recursos que
se necesiten para la realizacin del proyecto.
Matriz de riesgos:
Contiene los riesgos tanto inherentes como
externos, del proyecto.
Recomendacin:
Normar que el nmero mximo de reuniones
con el usuario sea 3.
Para la determinacin de estos lineamientos
se recomienda que el jefe de proyecto
consulte con otros jefes de proyecto ms
experimentados, los cuales pueden
asesorarle sobre los tiempos, costos y
arquitectura a utilizar.
Utilizar el software libre OpenProj como
herramienta para la realizacin del
cronograma.
En la plantilla de la matriz de riesgos se
deberan de considerar riesgos fijos aplicables
a los proyectos segn su naturaleza o
tipificacin.

3.5.1.4. Reunin de Inicio de Proyecto (Kick off)
Actor:
Jefe/coordinador del proyecto especial SIGA
Jefe de proyecto
Entrada:
Salida:
AA1_<NomProyecto>_SIGA-MEF.doc
(actualizacin)
Tiempo estimado: Mximo 3 das hbiles a partir de
la primera reunin hasta la aceptacin.
Descripcin:

Una vez definidas las lneas base se proceder a
negociarlas con el usuario en la reunin de Kick off.
En la reunin de Kick off se informar al usuario, el
tiempo, costo y alcance que tendra el proyecto. De
no estar ste de acuerdo, puede modificar las lneas
pero debe considerar que cualquier modificacin en
una lnea afectar a las otras dos.
Recomendacin:
Normar que una vez que se solicite la reunin
de kick off, el usuario deber tener como
mximo dos das para proponer una fecha de
reunin. De no responder, se considerarn
como aceptados los lineamientos.
La reunin de kick off se puede desarrollar
mximo en 2 etapas. Con diferencia de
mximo 2 das.

3.5.1.5. Formacin del Equipo de Trabajo
Actor:
Jefe de proyecto
Entrada:
Salida:
(actualizacin)
Tiempo estimado: Mximo 1 da a partir de la
disponibilidad de recursos en la institucin.
Descripcin:
Asignar el personal disponible a cada rol del
proyecto.
Recomendacin:
Utilizar el software libre OpenProj como herramienta
para la asignacin de recursos.

3.5.2. Fase de anlisis:

3.5.2.1. Refinacin de Requerimientos del Software
Actor:
Analista de Sistemas
Entrada:

Salida:
(actualizacin)
Tiempo estimado: Mximo 5 das.
Descripcin:
Tenindose aprobadas las lneas del proyecto, se
proceder a hacer el levantamiento de
requerimientos del software.
Deben incluirse los requerimientos funcionales y no
funcionales, dentro de los cuales se deber incluir
los requerimientos que permitan la construccin y/o
reutilizacin de ontologas, as como una lista de los
posibles sistemas con los cuales se integrarn.
Recomendacin:
Capacitar al personal en temas de definicin
de requerimientos de software ya que se ha
observado, en la documentacin existente en
los proyectos desarrollados por el equipo del
proyecto especial SIGA, que muchas veces
estos son definidos de manera ambigua e
inconsistente.
Capacitar al personal en temas de anlisis y
definicin de ontologas.

3.5.2.2. Anlisis del Software
Actor:
Analista de sistemas
Jefe de proyecto
Entrada:
Salida:
(actualizacin)
Descripcin:
En el proceso de anlisis se organizarn los
requerimientos que se recopilaron y se construirn
los diagramas de casos de uso, las especificaciones
y los prototipos del software.
En este proceso se deber elaborar el modelo
conceptual de las ontologas a utilizar lo cual implica
definir los trminos importantes para la ontologa,
definir las clases para las ontologas y sus

jerarquas, definir las propiedades de las clases para
las ontologas y las restricciones de las propiedades.
Al finalizar el proceso de anlisis se debe actualizar
la lnea base de Tiempo, afinando el cronograma en
base a los casos de uso del sistema.
Recomendaciones:
Realizar el nuevo ajuste del cronograma en base a
mdulos.
3.5.2.3. Elaboracin de Plan de Pruebas
Actor:
Tester
Jefe de proyecto
Entrada:
Salida:
(actualizacin)
Tiempo estimado: Mximo de 5 das.
Descripcin:
Este plan debe elaborarse en conjunto con el
usuario, quien debe dar su aceptacin. En este plan
debe especificarse los tipos de pruebas que se van a
realizar (caja blanca, caja negra, penetracin, estrs,
etc) y los procedimientos para cada una.
Este plan de pruebas debe incluir la verificacin y
validacin de las ontologas.
Recomendacin:
Elaborar una lista de pruebas aplicables para
los proyectos segn su naturaleza o
tipificacin.
Capacitar al personal en temas de ontologas
para que puedan definir adecuadamente las
pruebas que realizaran a estas.
Debido a la limitante de recursos con que
cuenta la institucin, considerar la proporcin
de 1 a 0.5 con respecto al desarrollo.
3.5.2.4. Reunin de aceptacin de Hitos y
Entregables
Actor:
Stakeholder
Jefe de proyecto

Tester
Entrada:
Salida:
(actualizacin)
Tiempo estimado: 3 das hbiles a partir de la
primera reunin.
Descripcin:
Este proceso consiste en una reunin con la parte
usuaria donde debe aprobarse el plan de pruebas
del sistema y software, as como definir la fecha y
alcance de cada hito del proyecto.
Un hito del proyecto consistir en una reunin
donde se le mostrar al usuario el avance al
que se hayan comprometido.
Cada una de estas reuniones debe culminar
con la aceptacin o no del usuario.
La aceptacin debe basarse en la ejecucin
por parte del usuario de los casos de prueba
y/o del sistema segn corresponda.
La consignacin de estos hitos estar en los
Lineamientos del proyecto: lnea base de Tiempo.

3.5.2.5. Diseo del Software
Actor:
Desarrollador
Entrada:
Salida:
Tiempo estimado: Mximo de 5 das
Descripcin:
El diseo del software debe hacerse de tal manera
que cualquier desarrollador, sin estar desde un
principio en el proyecto, pueda entender fcilmente
la arquitectura del software e incorporarse al
desarrollo del mismo.
Las tareas que aqu deben realizarse son: la
elaboracin del diseo fsico de datos, diseo de
clases y diagrama de secuencias.

Recomendacin:
Capacitar al personal en la elaboracin de los
diagramas del diseo fsico de datos, de
clases y de secuencia.
Utilizar Power Designer como herramienta
para la elaboracin de los diagramas, ya que
el MEF cuenta con licencias para esta
herramienta.
Capacitar al personal en el uso de la
herramienta.

3.5.3. Fase de construccin:

3.5.3.1. Desarrollo del Software
Actor:
Desarrollador
Entrada:
Salida:
Cdigo fuente
(actualizacin)
(actualizacin)
Descripcin:
Desarrollo de los casos de uso tomando en cuenta el
diagrama de secuencias elaborado y el cronograma
del proyecto.
El analista deber actualizar el Plan del proyecto
acorde al estado real del mismo en cada etapa.
Por cada conjunto de mdulos enviados a probar,
debe llenar todos los puntos del instructivo de
configuracin e instalacin (E7) que considere
necesarios.
Recomendaciones:
Se recomienda exigir a los desarrolladores
tener un paquete de pruebas unitarias.

Exigir la actualizacin de los diagramas de
secuencia y clases semanalmente.
Exigir subir los avances al servidor de
versiones, semanalmente.
Actualizacin constante del avance de las
tareas respecto al cronograma.
Designar un responsable de asegurar que se
cumplan con los estndares definidos por el
equipo del proyecto especial SIGA.

3.5.3.2. Ejecucin de Pruebas
Actor:
Tester
Desarrollador
Entrada:
Salida:
(actualizacin)
(actualizacin)
Descripcin:
Ejecucin de los casos de pruebas, contemplados
en el plan de pruebas, segn el cronograma del
proyecto, evaluacin del instructivo de configuracin
e instalacin, elaborar el documento de pruebas.
En el documento de lineamientos del proyecto (E2),
el tester encontrar los casos de prueba que deben
realizarse por cada periodo. Al finalizar el periodo,
debern presentarse dos documentos: 1) los
resultados de las pruebas (E6), cuyos resultados
parciales pueden ser informados al desarrollador
para que pueda corregirlos antes de la presentacin
de avance (hito) del periodo; 2) la acta de ejecucin
de pruebas internas (AA4) con las firmas
correspondientes.

Los resultados parciales sern comunicados
mediante el llenado del acta de pruebas internas
(AA4), en esta acta tambin pueden hacerse las
correcciones acerca del instructivo de configuracin
e instalacin presentado por el desarrollador.
El analista deber actualizar el Plan del proyecto
acorde al estado real del proyecto en cada etapa en
la que se haya considerado medir dicho avance.
Recomendaciones:
Actualizacin constante del avance de las
tareas respecto al cronograma.
El rea de pruebas debera exigir un
instructivo de configuracin e instalacin por
cada conjunto de mdulos que recibe para
realizar pruebas internas.

3.5.3.3. Reunin de presentacin de avance
Actor:
Jefe de proyecto.
Entrada:
Salida:
Descripcin:
La reunin consiste en presentar el avance del
proyecto de acuerdo al hito que se consider en los
lineamientos del proyecto.
Recomendaciones:
Actualizacin constante del avance de las tareas
respecto al cronograma.

3.5.4. Fase de transicin:

3.5.4.1. Elaboracin de Instructivos y Manuales
Actor:
Documentador
Entrada:
Software terminado
Salida:

Tiempo estimado: Mximo de 8 das
Descripcin:
Este proceso consiste en actualizar los manuales
instructivos de configuracin, instalacin y de
utilizacin del sistema.
Al iniciar este proceso, el instructivo (E7) debe estar
ya en una versin estable debido a que se ha ido
llenando conforme el desarrollador mandaba a
probar sus mdulos al tester, por lo tanto, en este
proceso debe considerarse solo algunas
actualizaciones que deban hacerse debido a la
integracin del sistema u otros motivos.

3.5.4.2. Capacitacin
Actor:
Documentador
Capacitador (es) del rea usuaria
Entrada:
Salida:
Descripcin:
Se capacitar a las personas designadas por el rea
usuario. El objetivo es que despus de la entrega del
sistema, sean estas personas las encargadas de
capacitar a toda persona que lo requiera.
Recomendacin:
Normar que el nmero mximo de personas
capacitadas debe ser 3.

3.5.4.3. Implementacin
Actor:
Jefe de proyecto
Desarrollador
Entrada:
Software terminado
Salida:
Descripcin:

Este proceso consiste en el despliegue del sistema.
Es responsabilidad del equipo del proyecto especial
SIGA, verificar que todo trabaje tal y como lo hara
en un ambiente de desarrollo.
El proceso termina con un acta de aprobacin por
parte del rea de produccin certificando que el
sistema funciona correctamente.
Recomendacin:
Delimitar un tiempo prudencial (3 das) en el cual se
est probando el sistema en el ambiente de
produccin. Despus de ese tiempo la
responsabilidad del sistema ser de produccin.
3.5.4.4. Reunin de cierre
Actor:
Jefe de proyecto
Entrada:
Salida:
Descripcin:
Reunin donde se firmar un acta de aprobacin con
todas las gerencias involucradas.
Recomendacin:
Contar con un documento de lecciones
aprendidas a nivel del equipo del proyecto
especial SIGA, la cual deber ser actualizado
en este proceso.
El acta debe contener las observaciones
acerca del trabajo general realizado en el
equipo del proyecto especial SIGA.

3.6. Diagrama de procesos:


3.6.1. Diagrama de procesos por fases


3.6.2. Diagrama de procesos por roles


CONCLUSIONES:
El modelo propuesto cumple los actuales estndares de
desarrollo de software NTP ISO/IEC 12207 y la ISO/IEC
9127 as mismo se ajusta a la estructura actual del
proyecto especial SIGA.
El modelo propuesto es escalable ante una posible
reestructuracin debido a la utilizacin de roles.
El modelo propuesto cubre la necesidad de implementar
una capa de ontologa la cual solucionar el problema de
integracin.
El modelo puede adaptarse a cualquier proyecto de
desarrollo de software sea de pequeo o gran tamao, de
corto o largo tiempo, y de diferentes estilos de
programacin, mediante la reduccin de ciertos procesos.

RECOMENDACIONES:
Designar como experto a un miembro de cada rea por
cada tipo de proyecto.
Normar las recomendaciones que se hicieron a lo largo de
los procesos.
Utilizar un servidor de versiones para cada entregable del
proyecto.

CAPITULO Iv

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CAPITULO Iv

Încărcat de

Drepturi de autor:

Formate disponibile

Oliveros Ocrospoma Miguel Angel

CAPITULO IV: DESARROLLO

S-ar putea să vă placă și