Está en la página 1de 24

IMPLEMENTACIN Y CONSTRUCCIN

DEL PROYECTO MxM

Integrantes:
Oscar Prez
Felipe Espinoza

Docente:
Jos Luis Ramrez

Fecha de entrega:
02/12/2014

ndice
ANLISIS...Pg. 3-12
Requerimientos del Software....Pg. 3
Detalles SLA....Pg. 4-5
StakeHolders....Pg. 6
DESARROLLO.....Pg. 7
Manual de Usuario....Pg.7
UML (Casos de Uso).........Pg. 8
Control de Versiones.......Pg. 9
Estimacin por puntos de Casos de Uso....Pg. 9-12
QA.Pg. 13
Certificaciones......Pg. 13
Plan de Pruebas.....Pg. 14-15
Plan de Gestin de Calidad..Pg. 16-18
Plan de Gestin de Riesgos.Pg. 19-21
PRODUCCINPg. 22
Anlisis de Impacto/ Clasificar.......Pg. 22
Captura del Problema..Pg. 23
Seguimiento del Problema..Pg. 23
Fase por Fase....Pg.23
Correcciones/Parches.....Pg. 24
Mantencin a Realizar.Pg. 24

ANLISIS
Requerimientos del Software
Este documento describe los requerimientos de software de MxM, cuyo objetivo principal
es la mantencin adaptativa al nuevo escenario que se le propone seguir a la empresa.
ALCANCE
Este documento de requerimientos de software es la base del desarrollo de software del
proyecto. Describe los siguientes tpicos:

Adaptacin al nuevo entorno de trabajo.

Modificacin de las bases de datos (bases de datos SQL Server 2008).

Consulta de ventas por artculos, local y agrupacin,

Consulta de compra por artculos por local y agrupacin,

Reporte de gestin comercial (Ventas centralizadas y compras centralizadas).

Requerimientos no funcionales.
Para que esta mantencin cumpla con lo solicitado por el cliente y logre cumplir
con sus especificaciones.
Esta mantencin debe responder a la adaptacin del sistema de software ya
utilizado en el supermercado, para lograr el completo funcionamiento con las
nuevas especificaciones del negocio (la nueva forma de dividir el pas bajo la
visin de la empresa).
Adaptacin al nuevo entorno de trabajo. Desarrollado en .net y enlazado a bases
de datos SQL Server 2008.
Proporcionar interface, para las operaciones de la empresa (Aplicacin software).
Lograr completa interaccin y coordinacin entre las diferentes zonas en las que
se divide el Pas.

Requerimientos Funcionales
Para que esta mantencin cumpla con lo solicitado por el cliente y logre cumplir
con sus especificaciones, esta ser una mantencin de tipo adaptativa.
Normalizacin de estructura de las base de datos (Estructura necesaria para dar
respuesta a las nuevas visiones de la empresa).
Proporcionar interface (Aplicacin software) para las consultas de ventas por
artculos, local y agrupacin. As tambin las de compra.
Y por ltimos generar reportes de gestin comercial (ventas y comprar
centralizadas)

DETALLES SLA
Documento de Detalles de Acuerdo de Nivel de Servicio
Contenido

Detalles para incluir

Propsito

Este documento de acuerdo de nivel de servicio y las


caractersticas de la prestacin y el apoyo del servicio
que es requerido por la empresa MxM, son
comprendidos y aceptados por los representantes de
La
Empresa
Externa.

El propsito de esta SLA es garantizar que todos los


componentes y los compromisos que se han
establecido para proporcionar un servicio de ptimo
rendimiento
de
la
funcin
empresarial.

Los niveles de servicio especificados en el presente


acuerdo
se
revisar
mensualmente
por
los
representantes de los grupos propietarios de la
Empresa Externa.
Este documento SLA se hace entre las dos partes por
un lado estn los gerentes de cada Zona y la
organizacin de las empresa MxM, representada por el
jefe de proyecto. Las personas nombradas han
examinado
y
aprobado
este
SLA.

Autorizacin

Los representantes que comparten la propiedad de la


prestacin
del
servicio:
Servicios de TI. El servicio de la Empresa Externa es
administrado por el departamento de Sistemas
teniendo como principal responsable a Jefe de
Sistemas.

Servicio

Administracin
servicio

del

Departamento de TI funcional. Tiene como


representantes a cada gerente.
El sistema de reportes MxM es una solucin de
administracin eficiente de los procesos de pago y
gestin de las remuneraciones, cubre en forma integral
las necesidades administrativas y provee de importante
informacin
en
lnea.

Este servicio es utilizado por todo el departamento de


RR.HH, Finanzas y Gerencia que utilicen un equipo de
computacin unido a la red corporativa de MxM y que
deseen hacer uso de los recursos
y servicios
compartidos
existentes.

Se establece una atencin ininterrumpida del servicio


de respaldo 24x7 a lo largo de todo el ao, por lo que el
cliente podr ponerse en contacto con el equipo de de
la Empresa Externa en cualquier momento. Se
establece como norma que el cliente tendr que
ponerse en contacto con el rea por medio del correo

Mantenimientos del
sistema

Tiempo de respuesta
del servicio

electrnico, el nmero fijo del equipo y el nmero mvil


de respaldo antes de reclamar la no disponibilidad del
servicio.
Para satisfacer el nivel de servicio, el mantenimiento es
un proceso obligatorio. En ocasiones el mantenimiento
derivado por la actualizacin de algn componente
como Software, Hardware, upgrade o algn otro
ocasionado por algn bug, resultara en la no
disponibilidad del servicio para los clientes. Constituye
una buena prctica acordar estos espacios de
mantenimiento en el SLA a los fines de excluirlos como
no
disponibilidades.
Se le notificara con anticipacin a todos los clientes
que utilizan el servicio especificando la justificacin,
con el fin de programar la ventana de mantenimiento y
resolver el problema.
En respaldo a los servicios resaltados en este acuerdo,
se
responder a servicios relacionados con
restauraciones y/o solicitudes remitidas por los
usuarios en base a los siguientes parmetros de
tiempo.
Respuesta inmediata (durante horas laborales y no
laborales) para situaciones clasificada como incidencia.
1 hora(durante horas laborales) para situaciones
clasificadas Criticas.
2 horas(durante horas laborales) para situaciones
clasificadas como de alta prioridad.
4 horas(durante horas laborales) para situaciones
clasificadas como prioridad media.
8 horas (durante horas laborales) para situaciones
clasificadas como prioridad baja.
24 horas (durante horas laborales) para solicitudes de
servicio generales.

Stakeholders
Los interesados en el proyecto son personas y organizaciones que participan de forma
activa en el proyecto o cuyos intereses pueden verse afectados como resultado de la
ejecucin del proyecto o de su conclusin. Los interesados tienen niveles de
responsabilidad y autoridad variable al participar en un proyecto. Estos niveles de
responsabilidad pueden ir desde el promotor y patrocinador del proyecto hasta el operario
que participa en la ejecucin del proyecto, pasando por todos los tcnicos y mandos
intermedios.

DESARROLLO
Manual de usuario:
En l se escriben las caractersticas tcnicas y de funcionamiento de la aplicacin.
Su lectura detenida, como casi todas, es muy recomendable y obligatoria para el correcto
uso de la aplicacin y poder explotar sus funcionalidades.
El manual del usuario contiene los siguientes aspectos:
Introduccin
a. Identificacin del software expresando su nombre comercial y el problema que
resuelve.
b. Panormica de los elementos componentes (subsistemas) describiendo de forma
general las caractersticas bsicas de cada uno de ellos, as como exponiendo a grandes
rasgos la informacin que es necesario suministrar al software y los resultados que sern
obtenidos.
c. Organizacin y estructura del documento y breve descripcin del contenido del manual.
d. Forma de usar el manual.
Generalidades
a. Informacin sobre el producto del software, indicando quien dise, desarroll y
document el software.
b. Forma de como contactar con el productor, brindando adems la informacin que el
usuario debe tener en caso de detectar errores en el software.
c. Informacin sobre la facilidad de obtener ayuda o asesora tcnica.
Iniciacin
a. Comienzo. Pasos inciales para dar inicio a la utilizacin del software, por ejemplo el
procesamiento de la informacin antes del tratamiento automatizado, el procedimiento de
carga, etc.
b. Modo de ayuda, descripcin de cmo se puede obtener ayuda referente a la utilizacin
del software.
c. Documentacin de referencia. Recomendacin en caso necesario de la consulta de
cualquier material impreso que posibilite completar los conocimientos de los
mtodos, algoritmos, etc. utilizados en el software.

UML (Casos de Uso)

1 Escenario

Escenario:
Actor:

Inicio de sesin
Usuario

Pre Requisitos:
Objetivos:
Resumen:

Debe tener permisos de acceso y cuenta activa


Acceder a la interfaz principal
El usuario desea acceder al sistema, para realizar las acciones
que estime conveniente
Acceder al sistema principal, sin problemas

Post Requisitos:

2 Escenario

Escenario:
Actor:

Control de datos empleados


Usuario

Pre Requisitos:
Objetivos:

Iniciar sesin previamente.


Atender y administrar de manera eficiente la informacin de los
empleados
El usuario accede al sistema, para controlar los datos de los
empleados.
Mantener organizada la informacin del empleado y la empresa

Resumen:
Post Requisitos:

CONTROL DE VERSIONES
El control de versiones involucra procedimientos y herramientas para gestionar los
cambios en los elementos creados durante el ciclo de vida del software. Comenzando por
la asignacin de un nmero de versin para la configuracin de la lnea de base.
En el existe tambin los repositorios donde bsicamente un rbol del sistema de archivos
(directorio), centralizado y controlado por una herramienta que gestiona los permisos y
conexiones para leer o escribir dichos archivos, y guardar un registro histrico de las
modificaciones que se les realizan.
Tambin existen los llamados mecanismo de control que permiten un acceso colaborativo
al repositorio (para modificacin y lectura), las herramientas utilizan diferentes estrategias,
orientadas a evitar conflictos al compartir archivos.

Estimacin por Puntos de Casos de Uso


A continuacin se explicar la metodologa de estimacin mediante el anlisis de
puntos de casos de uso, para luego realizar los clculos para estimar el esfuerzo
que requerir el proyecto.

Clculo de puntos de Casos de Uso sin ajustar


El primer paso para la estimacin, consiste en el clculo de los Puntos de Casos
de Uso sin ajustar.
Este valor, se calcula a partir de la siguiente ecuacin:
UUCP = UAW + UUCW
Donde,
-UUCP: Puntos de casos de uso sin ajustar.
-UAW: Factor de Peso de los Actores sin ajustar.
-UUCW: Factor de Peso de los Casos de Uso sin ajustar.

Factor de Peso de los Actores sin ajustar (UAW)


Este valor se calcula mediante un anlisis de la cantidad de Actores presentes en
el sistema y la complejidad de cada uno de ellos.
Los criterios son:
Tipo de Actor
Simple

Medio

Complejo

Descripcin
Otro
sistema
que
interacta con el sistema
a desarrollar mediante
una
interfaz
de
programacin
de
aplicaciones (API).
Otro
sistema
que
interacta con el sistema
a desarrollar mediante un
protocolo o una interfaz
basada en texto.
Una
persona
que
interacta con el sistema
mediante una interfaz
grfica.

Factor de peso
1

Factor de Peso de los Casos de Uso sin ajustar (UUCW)


Este valor se calcula mediante un anlisis de la cantidad de Casos de Uso
presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de
los Casos de Uso se establece teniendo en cuenta la cantidad de transacciones
efectuadas en el mismo, donde una transaccin se entiende como una secuencia

de actividades atmica, es decir, se efecta la secuencia de actividades completa,


o no se efecta ninguna de las actividades de la secuencia. Los criterios se
muestran en la siguiente tabla:
Tipo de Caso de Uso
Simple
Medio
Complejo

Descripcin
El Caso de Uso contiene
de 1 a 3 transacciones.
El Caso de Uso contiene
de 4 a 7 transacciones.
El Caso de Uso contiene
ms de 8 transacciones.

10

Factor de Peso
5
10
15

Clculo de Puntos de Casos de Uso ajustados


Una vez que se tienen los Puntos de Casos de Uso sin ajustar se debe ajustar
ste valor mediante la siguiente ecuacin:
UCP = UUCP x TFC x EF
Donde,
-

UCP: Puntos de Casos de Uso ajustados.


UUCP: Puntos de Casos de Uso sin ajustar.
TCF: Factor de complejidad tcnica.
EF: Factor de ambiente.

Factor de complejidad tcnica (TCF)


Este coeficiente se calcula mediante la cuantificacin de un conjunto de factores
que determinan la complejidad tcnica del sistema. Cada uno de los factores se
cuantifica con un valor de 0 a 5, donde 0 significa un aporte irrelevante y 5 un
aporte muy importante. Para mayor detalle de los factores y cuantificacin,
consultar las pginas 11-16 de documento estimacin de proyectos de software
(7).En la siguiente tabla se muestra el significado y el peso de cada uno de estos
factores:
Factor
T1
T2

T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13

Descripcin
Sistema Distribuido.
Objetivos
de
Rendimiento o Tiempos
de respuesta.
Eficiencia del usuario
final.
Procesamiento
interno
complejo.
Cdigo
debe
ser
reutilizable.
Facilidad de instalacin.
Facilidad de uso.
Portabilidad.
Facilidad de cambio.
Concurrencia
Incluye
objetivos
especiales de seguridad.
Provee acceso directo a
terceras partes.
Se requiere facilidades
especiales
de
entrenamiento
a
usuarios.

11

Peso
2
1

1
1
1
0.5
0.5
2
1
1
1
1
1

El Factor de complejidad tcnica se calcula mediante la siguiente ecuacin:


TCF = 0.6 + 0.01 x (Peso(i) x Valor asignado(i))

Factor de Ambiente (EF)


Las habilidades y el entrenamiento del grupo involucrado en el desarrollo tienen un
gran impacto en las estimaciones de tiempo.
Estos factores son los que se contemplan en el clculo del Factor de ambiente. El
clculo del mismo es similar al clculo del Factor de complejidad tcnica, es decir,
se trata de un conjunto de factores que se cuantifican con valores de 0 a 5.
En la siguiente tabla se muestra el significado y el peso:
Factor
E1

E2
E3
E4
E5
E6
E7
E8

Descripcin
Familiaridad
con
el
modelo
de
proyecto
utilizado.
Experiencia
en
la
aplicacin.
Experiencia
en
orientacin a objetos.
Capacidad del analista
lder.
Motivacin.
Estabilidad
de
los
requerimientos.
Personal
a
tiempo
parcial.
Dificultad del lenguaje de
programacin.

Peso
1.5

0.5
1
0.5
1
2
-1
-1

Para los factores E1 al E4, un valor asignado de 0 significa sin experiencia,


3 experiencia media y 5 amplia experiencia (experto).
Para el factor E5, 0 significa sin motivacin para el proyecto, 3 motivacin
media y 5 alta motivacin.
Para el factor E6, 0 significa requerimientos extremadamente inestables, 3
estabilidad media y 5 requerimientos estables sin posibilidad de cambios.
Para el factor E7, 0 significa que no hay personal part-time (es decir todos
son full-time), 3 significa mitad y mitad, y 5 significa que todo el personal es
part-time (nadie es full-time).
Para el factor E8, 0 significa que el lenguaje de programacin es fcil de
usar, 3 medio y 5 que el lenguaje es extremadamente difcil.
El Factor de ambiente se calcula mediante la siguiente ecuacin:
EF = 1.4 0.03 x (Peso (i) x Valor asignado (i))

12

QA
Dentro de la configuracin del software se ofrecen distintos procesos de verificacin,
validacin, certificacin, de cada paso para poder autorizar, desarrollar y liberar el
producto llamado Software. Todo esto estos procesos estn bajo los estndares IEEE
828-1990 y IEEE 1042-1987.
Con estas funcionalidades ya dadas a conocer se definirn los mtodos utilizados para
controlar los cambios, ofrecer la facilidad, asegurar la integridad y el mantener
peridicamente informado al jefe de proyecto, para documentar todas las actividades que
se realicen.
-

Documentacin del Sistema


Cdigo y listados del Software
Solicitudes de Modificacin
Documentacin de Pruebas

Certificaciones
Las principales normas o estndares que nos rigen en el mbito de la mantencin son los
siguientes:

IEEE 1219

Es la modificacin de un producto software despus de su entrega al cliente o usuario


para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para
adaptarlo a un cambio de entorno.

ISO 12207

En l se definen los procesos, actividades y tareas presentes en la adquisicin,


suministro, desarrollo, operacin y mantenimiento del software.

13

Plan de Pruebas

Pruebas del Sistema


Durante la fase de pruebas del sistema, se debe de asegurar la integridad de los
datos de los casos de prueba, del producto software y el entorno de utilizacin, y
de cualquier material de pruebas a utilizar. Ser responsable de dar al grupo de
pruebas todo el material que solicite. Se aadir a la documentacin de la versin,
ya archivada, el informe de los datos de prueba. Los problemas encontrados
durante las pruebas sern documentados y guardados en la base de datos.
Pruebas de Aceptacin
El informe de los datos de prueba de aceptacin ser aadido a la documentacin
de la versin. Los problemas que se encuentren durante esta fase sern
documentados y guardados en la base de datos.
Puesta en Produccin
Despus de ser aprobada por la comisin de revisin final y corroborada
por el jefe de proyecto, la puesta en produccin podr ser llevada a cabo al
reemplazar el sistema existente con la nueva versin, o un sistema de copia para
usuarios remotos, o la transmisin digital a los usuarios.
Adems de la instalacin fsica del sistema, tambin el actualizar los registros de
configuracin para reflejar en ellos la nueva versin, adems de archivar el
sistema completo, incluyendo todos los datos de la versin. Tambin se deber
dar copias del sistema para la recuperacin posterior del mismo ante cualquier
desastre.
Caractersticas de una buena Infraestructura.
Para que exista una buena Infraestructura en el mantenimiento del Software se
deben de realizar diversas tareas Dependiendo de la correccin de problemas sea
en un tiempo o periodo corto, se requiere una alta calidad y para esto algunas
prcticas como:
-

Los problemas puedan ser fcilmente reproducidos esto necesita


una alta calidad de la informacin sobre el entorno en el que se
produjo el problema.
Los problemas puedan ser comunicados al grupo de desarrollo en un
corto periodo de tiempo (minutos u horas).
Los cambios del cdigo puedan ser relativos a los problemas
Las pruebas de regresin puedan ser aumentadas con una prueba
para garantizar la correccin de los problemas.
Las nuevas versiones puedan ser liberadas a intervalos controlados.

14

Pruebas de Regresin
Utilizaremos pruebas de Regresin, estas pruebas de regresin me asegura como
MxM poder tener una infraestructura slida y poder verificar por cada fase de
desarrollo saber si existe algn error que corregir y con ello liberar versiones del
software de alta calidad.
Tenemos que minimizar los riesgos en el sistema existente para que los cambios o
modificaciones realizados para corregir un problema no creen problemas
adicionales o tengan efectos laterales no deseados. Para ello se tendr que
adoptar un proceso o utilizar herramientas que ayuden a realizar las pruebas de
regresin.
Las pruebas de regresin son particularmente valiosas cuando se utilizan como un
repositorio para las pruebas que validan la solucin de los defectos del software
encontrados.
Como resultado, la porcin de mantenimiento de estas pruebas de regresin,
crece con el tiempo. Otros efectos interesantes sern:

problemas se han encontrado.


s de regresin garantizarn que no sean introducidos al
sistema como resultado de otros cambios.

15

PLAN DE GESTIN DE CALIDAD


Plan de Gestin de la Calidad

Componente

Descripcin
Supermercado con el motivo de expandirse a todo el pas.

MxM
La Poltica de Calidad del Proyecto cumplir con los requisitos de
Poltica de calidad calidad desde el punto de vista de la Organizacin Ejecutante, es
del proyecto.
decir culminar el Proyecto en el tiempo y presupuesto planificado,
cumpliendo con las normas aplicables y utilizando la tecnologa
adecuada con el fin de brindar la satisfaccin a los requerimientos
del cliente.

Estructura
Organizacional

La Calidad del proyecto ser gestionada con mtricas tcnicas,


entradas y herramientas descritas:

Planificacin de la Calidad

Se utilizar una mtrica de calidad para gestionar la aplicacin


mediante polticas establecidas con el fin de realizar un estudio
comparativo en base a otras experiencias. Como una salida a esto
se le considera el plan de gestin, las mtricas de calidad, listas de
control de calidad y matriz de trazabilidad de los procesos de
calidad.

Aseguramiento de Calidad

Se utilizar como entrada el plan de gestin del proyecto, tambin


Descripcin de la las mtricas de calidad, la informacin sobre el desempeo del
Gestin de Calidad trabajo, revisando de una forma constante el desempeo de la
aplicacin mvil dando a conocer la efectividad del mismo. Como
del Proyecto
una salida para este proceso se considerar solicitudes de cambio,
acciones correctivas y preventivas.

Control de Calidad

Se utilizar como entrada el plan de gestin del proyecto, las


mtricas de calidad, las listas de control de calidad, tambin
mediciones del desempeo del trabajo mismo y de cualquier
solicitud de cambio aprobada.
Se revisarn los entregables para verificar si estn conforme a los
requerimientos pedidos y con ello asegurar la calidad del mismo.
Una vez hecho estas pruebas de calidad se informarn sobre el
proceso, y se dar a conocer el total aseguramiento de calidad.
Los entregables nuevamente se revisarn y se verificarn si est
conforme se pidi.

16

Como tcnica de control de calidad se utilizarn los diagramas de


caso de uso, con el fin de detectar cualquier defecto y eliminar el
error.
Como salida se considerarn las solicitudes s de cambio, las
acciones correctivas, preventivas, donde se formalizarn los
resultados.

Patrocinador
Objetivo del Rol:
Responsable financiero del proyecto y Stakeholders.
Funciones del Rol:
Provee polticas y normas de calidad adecuadas con el fin
de aprobar el plan de gestin del proyecto.
Proteger el proyecto de influencias externas, obviamente
negativas, y asegurar que sean alcanzados los estndares
de calidad.
Nivel de Autoridad:
Designacin o reasignacin de recursos de la empresa para
los fines correspondientes del proyecto.

Roles
y
Responsabilidades

Reporta / Supervisa:
Directorio / Gerente del proyecto

Gerente del Proyecto / Director de Proyecto

Objetivo del Rol:


Responsable de elaborar y asegurar el cumplimiento del
Plan de gestin de la calidad.

Funciones del Rol:


Supervisar el cumplimiento de los estndares de calidad.
Definidos para el proyecto mismo.
Tomar acciones preventivas y correctivas para controlar la
calidad de los entregables.
Asegurar que las auditorias de calidad estn de acuerdo con el
plan de gestin de la calidad y otros requerimientos aplicables.
Identificar oportunidades para establecer mejoras de procesos.
Nivel de autoridad:
Exigir el cumplimiento de entregables al equipo del
Proyecto.
Reporta / Supervisa:
Patrocinador / Equipo del proyecto

Equipo del Proyecto

Objetivo del rol:


Asegurar y controlar la calidad de los entregables segn los
estndares establecidos.

Funciones del rol:


Determinar el recurso necesario para cumplir con la

17

Implementacin del plan de gestin de la calidad.


Satisfacer los objetivos de calidad a travs del proyecto.
Proponer mejoramientos en los procesos para satisfacer los
estndares de calidad establecidos en el plan de gestin de
Calidad.
Documentar los reportes emitidos por la auditora de calidad.

Nivel de autoridad
Uso de recursos asignados.
Reporta / Supervisa
Gerente del proyecto / Equipo del personal

Mejora de Procesos
Auditorias de Procesos
Aseguramiento de Calidad
Solucin de Problemas

Documentos
Normativos para la
Calidad

Formatos

Mtricas de Calidad
Plan de Gestin de Calidad

Plantillas

Mtricas de Calidad
Plan de Gestin de Calidad

Procedimientos

Checklists

De Mtricas de Calidad
De Auditorias
De Acciones Correctivas / Preventivas

Cada vez que se requiera mejorar un proceso, debido a las


necesidades del proyecto, se seguir los siguientes pasos:
Mejora
Continua 1. Definir el proceso.
del Proceso.
2. Establecer la oportunidad de mejora.
3. Analizar la informacin sobre el proceso.
4. Definir y Aplicar las acciones correctivas para mejorar el
proceso.
5. Verificar si las acciones correctivas han sido efectivas.
6. Estandarizar las mejoras logradas para hacerlas parte del
proceso.

18

GESTIN DE RIESGOS
Plan de Gestin de Riesgos
Descripcin de la Gestin del Riesgo
del Proyecto

a) Planificar la Gestin de
Riesgos
Se utilizar como entrada el enunciado
del Alcance del Proyecto, Gestin de
Costos,
Plan
de
Gestin
del
Cronograma.

Factores ambientales
Dado que este proyecto se realizar
principalmente por personas con baja
experiencia, es necesario realizar
control de avance y estado en cada
actividad del cronograma.
Herramienta para la planificacin de la
Gestin del Riesgo:
Reunin de Planificacin y Anlisis
-

El director del proyecto junto a


su equipo darn sus opiniones
respecto a las actividades a
desarrollar y sus posibles
consideraciones.

Como salida se obtendr el Plan de


Gestin de los Riesgos.
b) Identificar los Riesgos
Las entradas
riesgos, son:

para

identificar

los

Plan de gestin de los riesgos,


estimados de costos, lnea base del
Alcance, plan de gestin de los costos,
Plan del cronograma, plan de gestin
de la calidad.
Factores Ambientales
Dado que se pueden generar
imprevistos, el director del proyecto
deber
detectar
y
actuar
proactivamente en su solucin.
Activos de
organizacin

19

los

procesos

de

la

El director del proyecto se encargar


de implementar, evaluar y controlar los
documentos del proyecto (platillas de
riesgos y lecciones aprendidas).
Tcnicas para la identificacin de
riesgos:
Tormenta de Ideas
-

El director de proyecto junto a


su equipo, expondrn sus
diferentes puntos de vista para
evidenciar los riesgos y sus
posibles consecuencias en las
actividades a realizar.

Anlisis de Supuestos
Se revisar el planteamiento de las
actividades y los costos para saber si
algo no fue considerado. As mismo se
complementar
con los
riesgos
detectados.
Como salida se obtendr el registro de
riesgos.
c) Anlisis Cualitativo de los
Riesgos
Las entradas para realizar el anlisis
cualitativo de los riesgos son:
Plan de gestin de los riesgos y el
enunciado del alcance del proyecto.
Determinacin de la probabilidad e
impacto de los Riesgos
En base a las reuniones realizadas se
identificar y evaluar el nivel de
impacto de cada riesgo.
Escalas de Probabilidad e Impacto
Para clasificar los riesgos negativos y
positivos detectados, se utilizar las
escalas de probabilidad e impacto,
para determinar los umbrales de
riesgos.
Como salida se obtendr las
actualizaciones al registro de riesgos.

20

d) Planificar las respuestas a


los riesgos
Las entradas para planificar
respuestas a los riesgos son:

las

Registro de riesgos y plan de gestin


de los riesgos.
Herramienta para el anlisis cualitativo
de riesgos:
-

Estrategias
para
enfrentar
riesgos negativos o amenazas.

Estrategias
para
riesgos
positivos u oportunidades.

Estrategias para respuestas de


contingencias, al detectar un
riesgo con alta incidencia de
impacto en el proyecto.

Como
salida
se
obtendr
la
actualizacin al registro de riesgos,
actualizaciones al plan de gestin del
proyecto
e) Monitorear y controlar los
riesgos
Las entradas para
controlar los riesgos:

monitorear

Registro de riesgos.
Herramientas para el monitoreo y
control de los riesgos:
-

Reevaluacin de los riesgos, se


consultar cada 25 das el plan
de riesgos.
Auditorias de riesgos, se
realizarn cada 30 das
Reuniones sobre el estado del
proyecto, se realizarn cada 30
das.
Como salida se tendr la
actualizacin continua de la lista
de riesgos registrados.

21

PRODUCCIN

Implementacin
En la Produccin se realiza la puesta en produccin, la implementacin de nuestro
trabajo, donde van consecutivamente fases las cuales se describen a continuacin.

Anlisis de Impacto.
La actual empresa MxM ha decidido automatizar sus funciones, tanto nivel
operativo como nivel administrativo. Para esto MxM quiere la implementacin de
un aumento de zonas, los cuales pasan de 3 a 5 el cual permite apoyar la gestin
en la parte administrativa de la empresa y le permitir tomar mejores decisiones
con informacin certera, confiable y actualizada, adems se llevar un control ms
detallado de la actividad laboral, tambin el sistema es capaz de sacar informe
diario, semanal, mensual, por trimestre, por semestre y anual de sus compras y
ventas.
Los impactos que generar sern los siguientes:
-

Controlar/Gestionar los costos de salario


Motivacin y compromiso del personal: a travs de un sistema de
remuneracin adecuado se puede conseguir que el personal est
satisfecho y de lo mejor de s mismo.
Captar y mantener a los buenos profesionales existentes en la empresa
evitando la rotacin.
Enviar Solicitud de Modificacin

IDENTIFICAR, CLASIFICAR Y PRIORIZAR


Una vez recibido la Solicitud de Modificacin, comienza el Mantenimiento del Software.
Los procedimientos a seguir son:
-

Asignacin de un Nmero de Identificacin.


Clasificacin del tipo de mantenimiento.
Anlisis de la modificacin para determinar si se acepta, se deniega o se evala.
Realizar una estimacin preliminar de la magnitud de lamodificacin.
Priorizar la modificacin.
Asignar Solicitudes de Modificacin a bloques de tareas planificadas para su
implementacin.

22

CAPTURA DEL PROBLEMA


La captura del problema es el punto de inicio del proceso de mantenimiento.
La dificultad estriba en asegurar que el grupo de soporte y desarrollo
reciben la informacin con la suficiente rapidez y calidad. Para ello se pueden
establecer herramientas y procesos para facilitar la captura de informacin crtica
de los
problemas surgidos a los usuarios del sistema para que la informacin pueda estar
disponible rpidamente para el grupo de desarrollo.
Para obtener la informacin precisa se debera:

de los pasos que los usuarios deben realizar para describir los problemas
del sistema impedirn su verdadera funcin. Muchos pasos dan ms
oportunidad a que la informacin sea modificada.

el hecho de reproducir los procesos para el grupo de desarrollo.


Dependiendo del entorno de ejecucin, existirn ficheros de la aplicacin
que resulten cruciales.

SEGUIMIENTO DEL PROBLEMA


Una vez los problemas han sido capturados, debern ser gestionados como
recursos dentro del proceso de mantenimiento, como los componentes software
son gestionados durante el proceso de desarrollo.
La informacin recogida en la captura del problema debe ser organizada y
gestionada para determinar el estado de las respuestas asociadas al problema.

FASE POR FASE


Anlisis:

Su deber es ofrecer la documentacin actualizada al personal que realiza el


anlisis. Adems tendr que facilitar los listados actualizados del cdigo fuente y
los informes del sistema de Cuentas del Estado de Configuracin mostrando el
estado exacto del problema.

Diseo:
Se asegurar de que el personal encargado del diseo tenga la
documentacin actualizada de la librera del sistema. Ser muy importante que los
diseadores reciban cualquier cambio en la documentacin tan pronto como sea
posible.
Implementacin:
Responsable de ofrecer a los programadores copias de los
mdulos que se van a modificar y asegurarse del control riguroso de versiones.
Tambin se debe de asegurar la organizacin convenientemente para prevenir la
prdida de los cambios.

23

CORRECCIONES:
Las correcciones ofrecen un soporte formal para relacionar
uno o ms problemas con su conjunto asociado de clases y/o cambios de las
versiones. La correccin es slo aplicable si el problema representa un defecto del
software.

PARCHES:
Un parche es un conjunto de correcciones que juntas
comprenden un mantenimiento incremental sobre un nivel de la versin de la
aplicacin. En otras palabras, un parche es una unidad de versin incremental.

MANTENCIN A REALIZAR
La mantencin a realizar ser Adaptativa, debido que a los cambios que se deber
aplicar a MxM, solo deriva de ciertos cambios estructurales internos, ante todo se debe
Priorizar la modificacin, y despus de ello Realizaruna estimacin preliminar de la
magnitud de la modificacin. No es necesario utilizar la Reingeniera, solo se necesita
adaptar los cambios correspondientes para que todo funcione como debe de ser.

24

También podría gustarte