Sunteți pe pagina 1din 137

*-rrpr

niJ
Desarrollo y
Mantenimiento
de
Software
1 de 78
DMS
4
141abr120
1
O
Direccibn
de Finanzas
Jefatura
de
Senricias
de
Coordinacin del
Sistema
de
Informcibn
FinahCh
Desarrolln
y
Mantenimiento
de
Software

Hoja:
Cbdig0.
Revisin: Fecha de
elabamcibn:

Tabla
de
Contenido
Desmolla
y
Mantenimiento
de
Software
A.
Objetivo
B.
Politicas
de
OpemiOn
C.
Descripcibn
E.
R.gistros
E. Referencias
G.Tkminos
y Definiciones H. Anexos 2 de
78
DMS
1
14labr12010

1.
Reswnen
de
Cambias
ANEXOS
Hoja:
Cwjg~:
Revisibn:
Fecha de
elaboracirjn:
M'
Anexo
1.
Tabla
de
Referencias
Cnraadas
Anexo
2.
Especficacibn
de
RequeRmient~s
Anexo
4,
Manual
de
Usuario
Anexo
5.
Anlisis y

Biseflo
Anexo 6.
Registro
de Rastreo Anexo 7. Plan de
Pnreh
de
Inlegmcih
Anexe
8,
Reponte
de
Pruebas
de
htegaccrn
Anexo
9. Manual de
Opera~in
62
Anexo
1
O. Reparte de
Pmh
de Sistema 66 Anexo
1
1.
Confi&ura~iGn
de
Sofiware
68 Anexo
12.

Ph
de
Instalacin
de
Componenes
70 Anexo
1
J
.Matriz
de
Docmentas
74 Anexo 14.
Manual
de
Mantenimiento
Direccin de Finanzas Jefatura de
Servidas
de
Coordinacitin
del Sistema de
Informacibn
Financiera
Desarrollo y Mantenimiento de
Somare

A. Objetivo El
propiisito
de Desarrollo y Mantenimiento de Software es la
realizacibn

sistemtica de las actividades de


anglisis,
diseo,
construcci6n,
integracin y pruebas de productos de software nuevo o modificado cumpliendo con l
os requerimientos especificados. Objetivos
especificas
del
procedimiento:
1.
01
Lograr que los productos de salida sean consistentes con los productos de entrad
a en cada fase de un ciclo de desarrollo mediante las actividades de
verificacion,
validacibn
o prueba. 3
de
78 DMS 1
14la
br120
1
0 Direccin de Finanzas Jefatura de Servicios de
Coordinacibn
del
Sistema de
Infomacibn
Financiera Desarrollo y Mantenimiento de
Software
2. 02 Sustentar la
realizacibn
de

dclos
posteriores o proyectos de mantenimiento futuros mediante la
integracibn
de la Configuracin de
Somare
del ciclo actual. Hoja: ,
CWlgo:
Revisibn:
Fecha de
elaboracidn:
3. 03 Llevar a cabo las actividades de las fases de
un
ciclo mediante el cumplimiento del Plan de
Proyecto
actual. l. La Coordinacion del Sistema de Informacin Financiera sera responsable
de la atencin de los requerimientos de las reas solicitantes desde su recepcin hast
a su cierre con el fin de dar cumplimiento y satisfaccin de calidad a las dichas r
eas. El Jefe de Departamento de la Coordinacin del Sistema de
Informacibn
Financiera deber:
2.1.Dar
el seguimiento necesaria para el cumplimiento de las necesidades de las
Areas
usuarias. 2.2. Generar el Plan del
Proyecto
o actualizarlo antes de iniciar un nuevo
ciclo
de desarrollo de acuerdo al procedimiento
Pfaneacin
de la
Administracion
de proyecto. 2.3. Revisar el Registro de Rastreo de los requerimientos del usuar

io a travs de
t
ciclo.
2.4.Revisar
los productos generados durante el ciclo, que forman parte de la
Confislumcidn
de
Somare
junto
cori
el responsable del equipo de
desarro
tlo.
2.5. Recibir y
analizar
las Solicitudes de Cambio o Mantenimiento de acuerdo al procedimiento de
Control
Integrado de
Cambios
e incorporar los cambios aprobados en el Plan del Proyecto. En caso de cambios a
requerimientos se incorporan al inicio de un nuevo ciclo.
2.6.Formalizar
la terminacin del
ciclo
o del proyecto de acuerdo al Protocolo de

Documento de
Acepiacibn
con el Cliente. 2.7.
Deber$

reunirse
peribdicamente
con el cliente y usuario para el seguimiento. 3. El equipo de
desarrallo
de la Coordinacin del Sistema de
Infomacibn
Financiera deber:
3.1
,Aplicar el procedimiento de
Desarrolio
y Mantenimiento de
Software.
4. Todo el personal que ejecute el procedimiento
deber4
ser capacitado. 5. Para los proyectos de Mantenimiento; 5.1 . Los proyectos de
mantenimiento
se
retroalimentaran
de las Solicitudes de Cambio o Mantenimiento que el Jefe de Departamento
recibir6
a travs del usuario. 5.2. Para los proyectos de
mantenimiento
se
deber&
realizar un
anblisis
de la Solicitud y del impacto para determinar si esta se
convierte
en un nueva proyecto.
5.3.

Se deber aplicar la
Matriz
de
Documentos
para el
llenado
de la Configuracin
del
Sofware.
6.
Descripcbn
del Procedimiento El
procedimiento
de Desarrollo y Mantenimiento de
Software
se compone de uno o
m8s
ciclos de desarrollo. Cada ciclo esta compuesto de las siguientes fases: Inicio:
Revisin del
Plan
de Proyecto por los
miembros
del Equipo de Trabajo para lograr un entendimiento comn del proyecto y para obten
er el compromiso de su
realiracidn.
Requerimientos: Conjunto de actividades cuya finalidad es obtener la
documntaci6n
de
la
Especificacin de Requerimientos y Plan de Pruebas de Sistema, para
conseguir

un entendimiento comn entre el cliente y


el
proyecto.
Anlisis y
Diseno:
Conjunto de actividades en las cuales se analizan los requerimientos especificad
os para producir una
dascripcidn
de la estructura de los componentes de software, la cual servir de base para la
construccidn.
Como resultado se obtiene la documentacin
del
AnAlisis
y Diseo y
Plan
de Pruebas de
Integraci~n.
Construccibn:
Conjunto de actividades para
producir
Comgonente(s)
de software que correspondan al Anlisis y
Disefio,
as
como
la
realkaci6n
de pruebas unitarias.
Gamo
resultado se obtienen el
(los)

Componente(s)
de
software
probados.

Direccibn
de Finanzas Hoja: 5 de 78 Jefatura de Servicios da
Coordinacidn
del Sistema de Cdigo: DMS
Infomacibn
Financiera
Revisibn:
1 Desarrollo y
Mantenimiento
de Software Fecha de
elaboracidn:
141abr12010
lntegracibn
y Pruebas. Conjunto de actividades para integrar y probar los componentes de sof
tware, basados en los Planes de
Pruebas
de Integracin y de Sistema, con la finalidad de obtener el Software que satisfaga
los requerimientos especificados. Se genera
la
versin
final del Manual de Usuario, Manual de Operacin y Manual de Mantenimiento. Como r
esultado se obtiene el producto de Software probado y documentado.
Cierre: Integrar todos los productos de la Configuracin del
software
generada en las fases para su entrega. Para generar los productos da cada una de
estas fases se realizan las siguientes actividades:

Distribucin de tareas, se asignan las responsabilidades de cada miembro del Equip


o de Trabajo de acuerdo al Plan de Proyecto.
Produccibn,
verificacibn,
validaci6n
a prueba
de
los productos, asi como su correccin correspondiente, 7.
Indicadores
Il
(01)
En cada fase de un ciclo se
efectijan
todas las actividades de verificacin,
validacidn
o prueba, as como las correcciones correspondientes.
12 (02) La
Confjguracion
de Software est integrada por los productos generados en el
ciclo.
13 (03) Las actividades planificadas en cada fase de un ciclo se realizan confor
me a to establecido en el
Plan
de Proyecto. 8. Responsabilidad y autoridad Responsable:
Responsable
de
Desarrollo y Mantenimiento de Software Autoridad:
Administrador del Proyecto 9. Procedimientos Relacionados
OAP
Ir
Planeacibn

de
la
Administracidn
de
PmyecfU
J
Vetificaci&
de
Alcance
J
Contml
integrado
de
Cambios
i
Administracidn
de Cambios y Liberaciones
Conocimiento de la
Oiganizacin

Direccibn
de Finanzas Hoja: 6
de
78 Jefatura de Servicios de Coordinacin del Sistema de
Cbdigo:
DMS Informacin financiera Revisin: 1 Desarrollo v Mantenimiento de Software Fecha
de elaboracin:
141a
br1201

O 10. Entradas
Especificacidn
de Requerimientos Nombre Plan de Proyecto Protocolo de Entrega Solicitud de Camb
io o
Man
fenimiento
autorizada
Descripcin Destino Fuente
Pianeacidn
de la
Administracibn
de Proyecto
Vefficacibn
y Alcance
Control
Integrado de Cambios Se compone de la
Descripcibn
de Requerimientos:
J
Funcionales: Necesidades establecidas que debe satisfacer
el
software cuando es usado en condiciones especificas. Las funcionalidades deben s
er adecuadas, exactas y seguras.
J
Interfaz
con usuario: Definicin de aquellas caractersticas de la
interfaz
de usuario que permiten que el
software
sea
fdcil

de entender, aprender, que genere satisfaccin y con el cual el usuario pueda


desempeiiar
su tarea
eficientemente.
tncluyendo la descripcin del prototipo de la
interaz.
Verificacin de Alcance Conocimiento de
la
Organizacin
J
l
nterfaces externas: Definicin de las
interfaces
con otro software o con
hardware.

Especificacion
del
nivel
de desempeo del software con respecto a la madurez, tolerancia a fallas y
reclineracihn
Dimcidn
de Finanzas Jefatura de Servicios de
Coordinaci6n
del Sistema de
I
nfomacion
Financiera
m
Desarrollo y Mantenimiento de

Somare
J
Eficiencia:
Especificacibn
del
nivel de desempeo del
software
con
respecto
al tiempo y a la utilizacin de recursos.
J
Mantenimiento: Descripcin de los elementos que
facilitarhn
la comprensin y la
realracin
de las modificaciones futuras del software. Hoja: Cdigo: Revisin: Fecha de
elaboraci&n:
J
Portabilidad:
DescripciOn
de las caractersticas del software que permitan
su
transferencia de un ambiente a otro. 7 de 78 DMS 1
14labr/2010
Restricciones de diseo y
construccib~i:
Necesidades impuestas por el diente.
J
Legales
y reglamentarios: Necesidades impuestas por leyes, reglamentos, entre otros. Est

e documento contiene la descripcin


J
Arq u
itectbn
ica:
Contiene la estructura interna del sistema, es decir la
descomposici6n
del sistema en
subsistemas.
Asj
como la
identificacibn
de los componentes que integran los
subsistemas
y las relaciones de
interaccibn
entre ellos.
mflcacin
d'~~cGi
textual y
grafica
de la estructura de los componentes de software. El cual consta de
las
siguientes partes: Conocimiento de
1s
OrganizaciEin

J
Detallada: Contiene el detalle de los componentes que permita de manera evidente
su construccin y prueba en

-Y
Ll--A-I-:<Direccibn
de Finanzas
Jefatura
de
Semicios
de
Coordinacidn
del Sistema de
lnformacidn
Financiera
Desanollo
y
Mantenimiento
de
Soffware
ei
am
wienre
ae
pragramacion
. Componente
IConjunto
de unidades de
cOdigoIVerificacidncleA/cance
relacionadas. Hoja:
Cddigo:

Revisidn:
Fecha de
elaboracidn:
Sistema de software, destinado a un cliente o usuario, constituido por component
es agrupados en
subsistemas,
pasi
blamente
8 de 78 DMS
1
141abr/201
O Configuracin de
Conocirnienfo
de
/a
Organizacin anidados. Conjunto consistente de productos de
software
Conocimiento de la Organiza
cidn
software,
que incluye:
Especificacin de Requerimientos
Anlsis
y Diseo
Verificacidn
de Alcance Conocimiento de
la
Organizacidn
Software
Registro de Rastreo
Plan de Pruebas de Sistema

Repoote
de Pruebas de Sistema
Plan de Pruebas de
Integracibn
Reporte de Pruebas de Integracin
Manual de Usuario
Manual de
Operacibn
Solicitud de Cambio o Mantenimiento Usuario Manual de Manual de
Operaci6n
describe la forma de uso del software
ion
base a la
interfaz
del usuario.
este
deber ser redactado en
tkrminos
comprensibks
a los
Plan de
tnsta!aci6n
de Componentes Documento electrnico o impreso que usuarios.
Verificaci6n
de Alcance Documento electrnico o impreso que contenga la informacin indispensable
para la instalacin y
administraci6n
del
software,
as

como el ambiente de
peracidn
(sistema operativo, base de datos,
senridores,
etc.).
Este
deber ser redactado en
trminos
com
prensibies
al personal responsable
de
la
operacibn.
Conocimiento de
la
Organizacin
Verificaccidn
de Alcance Conocimiento de
la
Organizaciri

Direccin de Finanzas Hoja: 10 de 78 Jefatura de Servicios de Coordinacin del Siste


ma de
Cbdigo:
DMS
Informacin Financiera
Revlsidn

: 1
Desarrollo
y Mantenimiento de Software Fecha de
elaboracibn:
1
Wabr12010
12. Roles
involucrados
y
capacitaci6n
Capacitacibn
Capacidad de
liderazgo
con experiencia en la toma de decisiones,
planeacibn
estratkgica,
manejo de personal y desarrollo de software. Conocimiento y experiencia en el de
sarrollo y mantenimiento de software. Conocimiento y experiencia en la
obtencibn
,
espificacidn
y
anaiisis
de las
requerimientos.
Conocimiento en
diseAo
de
interaces
de usuario y criterios
ergonmicos.

Rol Administrador del Proyecto Responsable de Desarrollo y Mantenimiento de


Software
Analista
Disefiador
de
lnteifaz
de
Usuario Conocimiento y experiencia en el
revisibn
y experiencia en el desarrollo y mantenimiento de
redaccibn
y experiencia en el Abreviatura AP RDMS AN DIU

13. Verificaciones y Validaciones Verificacin O Validacin


Ver1
Actividad Producto Especificacin de
Rt?q~err'n?i8nfos
Especi
ficacidn
de
Requeiimien
fos
Plan de Pruebas de
Sistema
Plan
de
Pruebas de Sistema
-.
Mahual

de Usuario
Descri
pcibn
Verificar claridad de
redacci6n
de la
Especificaciidn
de
Requerimientos
y su consistencia con la Descripcin del
Pmducto
y con el
estndar
de
docurnenta&n
requerido en el Proceso
Especifim.
Adicionalmente
revisar que los requerimientos sean completos y no ambiguos o contradictorios. L
os defectos encontrados se documentan en un
~epode
de
v~nfic~cibn.
Validar que la
Especificacibn
de
~e~uerimi&fos
cumple
con las
necesidades
y

expectativas
acordadas, incluyendo la
realizacibn
de la prueba de
usabilidad
de
la
interfaz
del usuario. Los defectos encontrados se documentan en un
Repode
de
Validacibn.
Verificar consistencia del
Plan
de
PI*UB~~J
de Sistema con la
EspecificaCj6n
de
Requetimien
tos y con el
estandar
de
documentacibn
requerido en el Proceso Especfico. Los defectos encontrados se documentan en un R
eporte de Verificacin. Validar que
Plan
de Pruebas de
Sistema
cumple con la Especificacin de

Requerr'rnientos.
Verificar consistencia del Manual de
Usuapio
con
la Especificacin de
Rscyuerimienfos
y con el
estCindar
de
docurnentacibn
requerido Especifico. Los
defectos

Registro de Rastreo
1
documentan
en un Reporte de
[
12
de
78 DMS
7
1
41a bd20
10
Direccin de Finanzas Jefatura de Servicios de
Coordinacbn
del Sistema de Informacin Financiera
DesamHo
y Mantenimiento de

Software
Verificaciin
. RE Verificar claridad de
la
documentaci6n
Hoja:
Cbdigo:
Revisido:
Fecha de
elaboracin;
1
del
Anlis
y
Diceiso,
su
facbilidad
y la
1
. .
m
.C
..
Diseo
Pruebas
de
Integracin Manual
de
Operacin consistencia con

ia
tspecrrcacion
ue
Requerimientos
y con el
estndar
de documentacin requerido en el
Proceso
Especifico.
Verificar que el
Registro
de Rastreo contenga las relaciones adecuadas entre los requerimientos y los elem
entos de
AnBlisis
y Diseo.
tus
defectos encontrados se documentan en un
Reporfe
de
V8Mcacin.
Validar que el Anlisis y Diseo cumple con las necesidades y expectativas acordadas
mn
el diente. Los defectos encontrados se documentan en un Reporte de
Validacin.
Verificar consistencia del Plan de
Pruebas
de
lntegracidn
con el
Anlisis

y
DimAo
y con el
estndar
de
documentaci6n
requerido en el Proceso
EspecifiCo.
Los defectos encontrados se documentan en un
Reparfe
de
Vetifi~acidn.
Verificar que el Registro de
Rastreo
contenga
lis
relaciones adecuadas entre las elementos de
Andiisis
y Diseo y los componentes. Los defectos encontrados documentan en un Reporte de
Verificacibn.
Verificar consistencia del Manual de Operacin con
el
Sornare
y con el
estndar
de documentacin requerido en el Proceso
Especifico.
Los defectos encontrados se documentan
eh
un Reporte de Verificacin. Mantenimiento

dacumentacibn
requerido
en el Proceso Especifica.
Ver%
A5.9 Manual de RE Verificar consistencia del Manual de
Usuanb
Usuario
con el sistema de
Sofhivare
y can el
estandar
de
documentacibn
requerido
en
el Proceso
Espec*co.
Los
defectos
encontrados se documentan en un Reporte de Verificacin. Va19
A5.6.
a)
Reporfe
de
US
Validar las pruebas de sistema. Pruebas
d~
Sistema

Val10
A5.12
Plan
de AP Validar los datos necesarios
para
la
Instalacin
de instalacin de
19s
componentes. Componentes
14.lncorporaci6n
a
ta
base de conocimiento
Producto
Especificacidn
de
Requerfmienfos
PIan
de Pruebas de Sistema Manual
de
Usuario
Anlisis y Diseo
Registro
de Rastreo
Plan
de Pruebas de Integracin
Componente(s)
Registro de Rastreo
Sohvare

Manual de
Opemcibn
Manual de Mantenimiento Manual de Usuaria 1 5. Situaciones excepcionales Forma d
e
Aprobacibn
Verl,
Val7
Vea,
Val2.1
Ver3
Ver4,
Va12 Ver4
Ver5
Prueba unitaria exitosa Ver6 Prueba de
integracibn
exihsa
Ver7 Ver7 Ver8
Repode
de
Pruebas de
lritegractn
Reporfe
de Pruebas de Sistema Plan de Instalacin de Componentes tos roles involucrados en
el procedimiento de Desarrollo y Mantenimiento de Software
deberan
notificar al RDMS, de manera
oportuna,
las situaciones que les impidan
el
desarrollo de
las

actividades
asignadas. .
/
Ninguna
Val9
Val
1
O

1
I
,
i
1
Direccidn
de Finanzas
1
Hoja:
1
14 de78
1
1
Im(
1
Jefatura de Servicios de
Coordinecidn
del Sistema de
1
Cbdigo:
]

DMS
Inbrmacibn
Financiera
Revisibn
:
11
/
bd
Desarrollo
v
Mantenimiento
de
C0Tktf6
Fecha de
elaboracibh:
El RDMS
deberA
dar respuesta a estas situaciones y en caso de no poder resolverlas o no sean de
su competencia deber escalarlas al AP.
7
6. Guas de ajuste Fase de Requerimientos:
./
Especificacidn
de Requerimientos La
Especificacidn
de Requerimientos puede incluir un prototipo de interfaz con el usuario sencilla
, que inclusive no tenga funcionalidad.
./
Manual
de
Usuario En

la
fase de Requerimientos se puede omitir la elaboracin o
actualizaci6n
del Manual del
Usuah,
as
como su verificacin. Sin embargo esta actividad se deber realizar a ms tardar en
la
fase de integracin y pruebas. Fase de
Construccitin:
Revisihn
entre colegas del
cbdigo
Antes de
realizar
pruebas unitarias se pueden incluir revisiones entre colegas para verificar el cd
igo de los componentes con respecto al Anlisis y
Diseiio.
El beneficio de estas revisiones es
la
disminucin del nmero de defectos de fases posteriores y el tiempo de correccin.
J
Pruebas Unitarias Las pruebas unitarias se pueden definir de manera sistemtica y
documentada siguiendo el
estdndar
IEEE Std A0081987 (R
1993)
Standard
for
Software
Unit

Testing
. Prototipo de
Interfaz
En la fase de Construccin se puede agregar la elaboracin o modificacin del prototip
o de la interfaz para realizar una prueba con el usuario, con el fin de identifi
car defectos crticos de uso. Si no se cuenta con los usuarios para la prueba de
interfaz
puede
recurrirse
a la
revisibn
de un experto o se pueden escoger individuos de un
perfil
similar.

17,
Diagrama de Flujo de
Trabajo
,,m
q
r3---15
d.
78
DMS
I
1
Sfiirrr1201
O
Rimxibri

de
Finanzas
Jefatura
de
brvioios
de
Cwrdinacibri
del
Sisteina
de
In@rmmibn
Financiefa
Desarroilo
y
Mentenimbnka
de
SoWare
Hoja:
,
mgo:
Revisibn
:
Fecha
de
atabomcih:

Inicia el
~mdimiento
Al.
~~~c~II

th
frr
fim
Ue
bWb
imi
Al
.l.
Revisar
con
b
miembm
del
@pQ
d@
trgbqo
&
Plan
de
mya&
*para
iqw
unmbnd
PMnaEg~~~~~~~m
A2.
Realizacin do la fase de Requerimientos
(01,031

1
Responsable
1
17
de 78
DMS
1
14labrMOl
O
Direcci6n
de Finanzas Jefatura de
Seniicios
de
Coordinacih
del Sistema de
Infomacibn
Financiera Desarrollo y Mantenimiento de Software
A2.3.
Verificar la Requerimientos
(Verl
) . A2.4. Corregir defectos encontradas en la
Requermientos
y obtener la
142.5.
Validar la Especificacin Requerimientos cumple con las necesidades y expectativas
acordadas, incluyendo la
realizacidn
de
la
prueba de
usabilidad

de la
intetfaz
del A2.6. Corregir defectos encontrados
en
la Especificacin de
Requerimienfos
y obtener la Hoja:
CMigo:
Revisibn:
Fecha de
elabaracin:
Actividad RE AN
D1U
CL
US
RP

18
de
78 DMS
1
Direccibn
de
Fnanzas
Jefatura de
Sewicios
de Coordinacin del Sistema de
Informacibn
Financiera Hoja:

CWo:
Revisin: Desarrollo y Mantenimiento de
Software
Fecha de
elaboracibn:
141abr/2910

Direccibn
de Finanzas Hoja: 19 de 78 Jefatura de Servicios de Coordinacin del Sistema de
Cbdigo:
DMS
I
nfomacibn
Financiera
Revisibn:
1
De~rrollo
y Mantenimiento de Software Fecha de elaboracin:
141abr12010
A2.11.
Verificar el Manual de
A2.12.
Corregir
Iw
defectos
encanados
en el Manual de Usuario y
obbner
la
aprebacdn

de las
A2.13.lncorporar
la
RequeHmentos,
Plan de Pruebas de
Sistema
y Manual
de
Usuario como
lineas
base
a la
Configuraci6n
de Software.
A3.
Realizacin de
la
fase de
Analhis
y Diseio
(0q
$3)
A3.1
Distribuir tareas a los miembros del equipo de trabajo segun su rol, de
Plan
de Proyecto actual.
//
Elabpd
1
w

1
r

21 de 78
DMS
1
141abr12010
Direccidn
de Finanzas Jefatura de Servicios de
Cwdinacidn
del
Sistema de
l
nformacin
Financiera
m
Desarrollo y Mantenimiento de Software Actividad
Hty
a :
CMig0:
Revisibn:
Fecha de elaboracin:
A3.4.
Corregir los defectos encontrados en el
RnCilisis
y
DiseAo
y en el Registro de

Rasfreo
y obtener la
A3.5.
Validar el Anlisis y A3.6. Corregir los defectos encontrados en el
AnAlisis
y
Diseffo
y obtener la
aprobacibn
de las correcciones.
A3.7.
Elaborar o modificar
Plan
de
Pruebas
de Integracin. Responsable RP
CL
aiv
AN
DI
1

22 de 78 DMS 1
141a
br120
1
0
Direccibn
de Finanzas Jefatura de Servicios de
Cmrdinacin

del Sistema de Informacin Financiera Desarrollo y Mantenimiento de Software Activ


idad A3.8. Verificar el Plan
de
Pruebas de
lntegmcidn
(Ves).
Hoja:
CdigO:
Revisin: Fecha de
elaboracibn:
A3.0.
Corregir los
defectos
encontrados
en el Plan de
Pmebas
de
Infegmcidn
y obtener la
aprobaddn
de las correcciones. A3 10. Incorporar
Andlisis
y
Disefl~,
Registro de Rastreo y Plan de
Pruebas
de
Integracidn
como
iineas

base a
la
Configuracn
de
Sofhyam.
A4.
Realizaci6n
da la fase de
Construccibn
(O
,03)
A4.1. Distribuir tareas a los miembros del equipo de trabajo
segn
su rol, de acuerdo al Plan de Proyecto actual. Responsable RDMS RE
A3.8
I
RP 1

Actividad PR RE RDMS 23 de 78 DMS


1
141atir1201
O
Direccibn
de Finanzas Jefatura de
Sewidos
de
Coordinacibn
dd

Sistema
de
Informaci6n
Financiera Desarrollo y
Manfenjmiento
de
Sobere
A4.2. Construir o modificar
el(los)
Componerrte(s)
de
software:
Hoja:
Cbdigo:
RwisWn:
Fecha da
elaboracibn:
J
Irnplerneritar
o modificar
Componente(s)
con base a la
par&
detallada del Anlisis y Diseo.
J
Definir y aplicar pruebas unitarias para verificar que el funcionamiento de coda
componente
estb
acorde
con

la parte detallada del


Andlisis
y
Diselo.
*r
Corregir los defectos encontrados hasta lograr pruebas unitarias
exitosas
(sin
defectos).
*/
Actualizar el Registra
de
Rastreo, incorporando los componentes construidos o
modiiicados.
A4.3. Verificar el Registro
de
Rastreo
(Ve6).
A4.4.
Corregir las defectos encontrados en
el
Registro
de Rastreo y obtener la
aprobacibn
de
las
correcciones. A4.5. Incorporar Componentes y Registro de Rastreo
como
lneas
base a

ta
Configuracibn
de
Software,

r
1
Resaonsa
ble
I
Direccin de Finanzas Jefatura de Servicios da
Cwrdin~@Qn
del Sistema de Informacin Financiera
-Desarrollo y Mantenimiento de
Somare
AS.
Realizacin de la fase de Integracin y
Pniebas(01,03)
A5.1. Distribuir
tareas
a los miembros del equipo de trabajo segn su rol, de acuerdo al Plan de
Proyecto
actual.
Hoja:
Cfidigo:
Revisin: Fecha de
elaboracibn:
Actividad

A5.2.
Realizar
integraci6n
y pruebas. 24 de 78
DMS
1
141abr12010
J
Integrar los
corrPpmentes
en
subsistemas
o en el
sistema
del
SoPtwam
y aplicar
las
pruebas
siguiendo el
Plan
de
Pruebas
de
Infegracidn,
dacumsntando
los resultados en un
Repode
de
Pruebas

de
1nb~miOn.
J
Corregir
los
defeencontrados, con
basa
en
Reporfa
de Prueba3 de
Intgsracidn,
hasta
lograr
una prueba de
Intqreicibn
exima
(sin
defectos).
4
Actualizar el
Re~jstrn
de
Rasfles.
RDMS
A5.3.
Documentar el
Manual
de
OpemcrQn

y
d
Manual de Mantenimiento a modificar tos manuales existentes. PR
RP
RM

A5.4. Verificar Documentar el Manual de


Operacidn
y el Manual
dfi
Mantenimiento o
modificar
los manuales existentes. A5.5. Corregir
bs
defectos encontrados en el Manual de
Operacidn
y en el
Manual
de
Mantenimiento
y obtener la aprobacin de
las
correcciones. A5.6. Realizar
las
pruebas de sistema siguiendo el Plan de Pruebas de Sistema, documentando
los
resultados en un Reporte de Pruebas de
Sistema.
A5.6. a) Validar las Pruebas de A5.7. Corregir los defectos encontrados en las p
ruebas de sistema con base en el Reporte de Pruebas de Sistema y obtener la apro

bacin de las correcciones. A5.8. Documentar el Manual de Usuario o modificar el e


xistente.
A5.9.
Verifimr
el Manual
de
Uwaro
Direccin de Finanzas Jefatura de Servicios de
Coordinacibn
del Sistema de
Informacidn
Financiera Desarrollo y Mantenimiento de Software Hoja:
Cbdigo:
Revisibn:
Fecha
de
ehbaracibn:
25 de 78 DMS
1
14labr12010

26 de
78
DMS
1
141abr12010
Direccibn
de Finanzas
Jefatura
de Servicios da

Coordinacibn
del Sistema de
lnformacidn
Financiera Desarrollo y
Mantenirnienfa
de
Somare
Actividad Hoja:
Cddigo:
Revsin:
Fecha de elaboracin: A5.10. Corregir los defectos encontrados en el Manual de Usu
ario y obtener la aprobacin de las correcciones. A5.11 Generar Plan de Instalacin
de Componentes. Responsable A5.11
A512
Validar
Plan
de
Instalacicin
de Componentes
(VaMOJ.
A5.13 Corregir los defectos encontrados en
Plan
de
lnstalacidn
de Componentes. A5.14. Incorporar
SoMam,
Reporfe
de Pruebas de
lntegracidn,
Registro
$e

Rastreo,
Manual
de
Opsmcibn,
Manual de Usuario y Plan de
Insfalacidn
de Componentes como
llneas
base a la
Configuracibn
de A5.15. Enviar Plan de Instalacin de Componentes
al
R t.
Admrni&aCh
au
/L/
Elahrb/
/
I
1
AP
RM RDMS

27 de 78
Direccidn
de Finanzas
Informacidn
Financiera Desarrollo y
Mantenimienta
de Software

A6.
Realizacin de la fase da Cierre (02) Hoja: Actividad A6.1 Integrar la
Configuracidn
del
Software.
Jefatura de Servicios de
Coordinacibn
del Sistema da
8evisibn:
Fecha de
elaboracibn:
A6.2 Validar la Configuracin del
Software.
1
14/abr!201
O
Responsable
A6.3
Corregir los defectos encontrados en
la
Configuracibn
del Software.
Cbdigo:
RDMS
A6.4
Obtener el documento de Aceptacin con el CL.
DMS
AP

28 de 78 DMS 1
14/abr/2010
Direccibn
de Finanzas Jefatura de
Servicias
de
Coordinacifrn
del
Sistema de
Informacibn
Financiera Desarrollo y Mantenimiento de Software E. Registros Hoja:
Cbdjgo:
Revisibn
: Fecha de
elaboracibn:
Tiempo
de
retencibn
Ordenado
Par
Nombre
de'
registro Almacenamiento
Proteccin
Disposicin

cuando
no
afecten

al
cumplirnienfez
de
sus
obj&tivos.
m
Gesfibn
Hacer
dillgmeisrs~~onducenEes
at
logro de un
nqocb.
Administracin
Organimr
tmbw
y
dj$poner
recursas.
Dimidn
de
Finanzas
Jefatura
da
Serviejos
de
Gwqdinwibn
del
Sisfma
de
frifamcb

Finahci~nea
Dei;aolto
y Mantenimiento de
Software
Organkqoin
Emmw
o
6interna de una
organ9c'idn
dedicada
al
desamlb
yfa
--mb.-..%.:-L.mb*
A*
-..&..<*Lnimes4nicalra
Conjunto
de
elementos
o
servicios
que
se consideran
nmehiiioa
para
la
cmiQn
y

funcionamienta
de una
organizan.
Hoja:
ad@o:
Revis&n
1
Fecha
de
ehbaracan;
Base
d
conoqimhto
8
un
mpwbrio
da todos
1productos
Wm
como
pr0dudQs
de
software,
3g
de 78 DMS
1
1
4Mr/201
O

1
planes,
rppwtes.
regjstros,
lecciones aprendidas y
btros
dofumentos.
/
Estudh
d.
la
potencialidad
o
capacidad
que
tialguna cosa
pra
1
3.
,.
1
..
. .
.... . . .
r
i
WUUG~
e

wnwure
Es
el
pmducta
qQ@
se
ene era
en
d
prodimienta
de
De%jmllo
y
Mantmimknto
ds
Software,
Lo5
productos
de
software
$o
ctas-8can
da manera
general
mmo
Espmificacibn
de
Requer'irnientos,
hSilisls
y Diseo,

%ftware,
Prueba,
R#gistra
de
kstm
y
#a~ual.
Esta
dasificetcibn
puede
rrri-i:*l:i-.A---.'a1--..---:diiI-i-Li
-Liuil.ni.
2xr
eapwiiLtiimya
yuri
rqa
n-aiuaa-,
par
ej%rnpro
mpubue
signifmr

Plan
de
Pruebas
a
R6prk
de
Pruebas,
Mahm.1
puede
ser especializado
en
Manual
de
Wari,
Manual da
Operacibn
o Manual
tk
Mnbrrimknto,
rnknhs
que
el
Software
pu~de
ser
un
Componente,
un
Sistema
de

carnponentss
a un
Sima
compuesto
d0
sistemas. Plan
Programa
d&altado
de
las
acflvidadea,
reapsrisebles
wf
reali-mrlas
Y
-i,--l-.l

Mantenimiento del Software


Dei
estndar
l
EEE
1219
es: El
~~I&TiW~~
del
S
de un producto
coffware

despues
de
la
entrega
mejorar el rendimiento u
otros
atributos, o para
adap*
H
'pda
un
entorno modificado. Pueden ser:
i
Correccion
de
defectos en el
strfhvare.
Creacihn
de nuevas
funcionalidades
@TI
4
requisitos de usuario.
O
Mejora de la
funcionalidad
y del rendimiento OAP Oficina de
Administracidn
de Proyectos H. Anexos Anexo

4.
Tabla de
referencias
cruzadas Anexo
2.
Especkacian
de
Requerimientos
Anexo
3.
Plan de Pruebas de Sistema
Anexo
4. Manual
de
Usuario Anexo 5.
AnBlisis
y
Diseno
Anexo 6. Registro de Rastrea Anexo
7.
Plan
de
Pruebas
da
lntegmcidn
Anexo 8. Reporte de Pruebas de
lntegracidn
Anexo 9. Manual de
Opemcibn
Anexo 10. Reporte de Pruebas de Sistema Anexo 1 1.

Configuracibn
de Software Anexo 12.
Plan
de
Instalacibn
de Componentes Anexo
1
3.
Matriz de Documentos Anexo 14. Manual de
Mantenimienh
1
f.
Resumen de
Cambios
1
--- Resumen y motivo del cambio Pagina
6-seccibn
#el
d,rn&O

go:
1
DMS Anexo
1.
Tabla de Referencias Cruzadas Esta tabla es un ajuste necesaria para poder ident
ificar quien o

quienes
cubren
que roles y que
posibles
roles
faltan por cubrir dentro de la organizacin.
cwmnhm?
m
ib&mwmm
ACL
*&
4B

Direccin
de Finanzas Jefatura
de
Servicios de Coordinacin del Sistema de
tnfomacidn
Fnanciora
Desarrollo y Mantenimiento
de!
Software
Anexo
2. Instructivo del formato: Especificacin de Requerimientos. Para el
casa
de un
proyecto

nuevo se
&~bSfit1~8
por el M
del
Pmvecfo.
H~ja:
CMgo:
Revisidn:
Fecha de
elaboracidn:
Clave del formato:
DMS-A2.2
l.
Descripcibn
Genwal
36 de 78 DMS 1
141abr12010
Debe
anotarse
Indicar el
nomero
de solicitud de cambio o mantenimiento que
asignarCi
cada AP. Debiendo seguir la siguiente
norneriglatura:
Siglas
del
aistemaMod
ulo-ano-nu
mero consecutivo con 4 d igitos.

Empezando
cada
aAo
desde uno. Por ejemplo:
SPEPM-2010-0001
No.
1.
En esta
seccibn
se describen todos aquellos factores
que
afectan al producto y a sus
requerimientos.
No se describen los requerimientos,
sino
su
contexto.
Esto
permitir&
definir con detalle los requerimientos en la
seccidn
3, haciendo que
sean
mas
Mciles
da entender. Normalmente, esta
seccibn
consta
de las siguientes
subsecciones:

vsion
general
del
documento,
Perspectiva del producto, funciones del producto,
caracteristicas
de los usuarios, restricciones,
suposiciones
y dependencias,
factores
que se Donde dice: No. Folio
1
asumen y futuros
requerimierrtos.
3.
1
2.1.1
Reuuerimentoa
de
1
Se describirn las requerimientos
aue
afecten a la
interfaz
de
1
1
como sern soportados y los
protooolos
usados.

7.
1
2.1.5
lntetfaces
c,on
otro
(
Se
debe
especifisar
el uso requerido da otras
itkcionas
o 4. 5. 6.
l
nterfaces
Externas 2.1.2
Interfaces
con el Sistema General 2.1.3
InteFfaz
con Usuario 2.1.4
Interaces
de
Hardware
usuario,
interfaz
can
'otras sistemas
(hardware
y
somare)

e
interfams
de
comunicaciones.
Se deben
sspedficar
las
Interfaces
del
sofkvare
con el sistema general al que pertenece indicando los objetivos de las
tnterfaces
y una descripcin detallada de
ellas.
Definicibn
de
aquellas
caractersticas de la
interaz
de usuario que
permiten
que
el
software
sea
fAcii
de entender, aprender, que genere
sa;lsfaccidn
y con el cual el usuario pueda
desernpefiar

su tarea
eficientemente.
Incluyendo
la
descripcin del prototipo de la
interfaz.
Incluir
algunas
isracterlsticas
de
la
interfaz
como lo son:
Entrehamisnto
necesario para un usuario
estandar.
Caracteristlcas
del ambiente
grdfico,
a de
procesas
de captura de
acuerdo
a
las
caracterlscas
de la aplicacin.
Estndares
de
interfaz

de usuario. Se debe especificar las


cawcteristicas
lgicas
de todas las posibles
inbracciones
entre
d
producto
y
componentes
de
hardware,
esto incluye las
caracter4sticas
da
mnfiguracion
(ej. numero de
puerto,
conjunto de instrucciones,
etc.).
TambBn
se deben incluir aspectos Mimo que dispositivos
sarhn
soportados,

Direccibn
de Finanzas Jefatura de Servicios de
Coordinacidn
del

Sistema de
Informaci6n
Financiera Desarrollo y Mantenimiento de
Sofhivare
2.3. Requerimientos de Rendimiento Se deben incluir los siguientes puntos: Hoja:
Cddig0:
Revisin: Fecha de
elabomciOn:
productos de
software
(por ejemplo un sistema de recursos
kmanos
@tia
tener una interfaz con un
software
que realice
examenes
gsico-mtricos,
o un sistema
podria
requerir tomar
informacibn
de
una hqa de
c&lculo
en
Excel)
e
InterFaces
con otros

si$terrtas
de
informacibn
que no hacen parte del Sistema
Generat.
Para cada producto
cun
el que se realice
la
interfaz se debe especificar el nombre y la
veni6n.
Para cada interfaz
se
debe
especificar
el
propbsito
de la
interfar
y ta
definiciun
de ella en
$minos
del contenido y formato.
Si
existe
alglin
documento que describa
detalladamente
la interfaz, no es necesario

transcribirlo,
se
puede
hacer
referencia al documento. Se debe especificar todas las
Interfaces
de
comunicacibn
coma
redes locales, protocolos,
ek.
En caso en que el sistema no tenga
lnterfaces
externas o no tengan ninguna
caracteristica
especial, se debe indicar en esta
seccitin.
Los requerimientos funcionales
deben
definir las acciones que deben ser
tomadas
por el sistema al recibir entradas de datos y
al
generar
!as
salidas de datos. Estos requerimientos generalmente se expresan
en
i&rmiilas
de "debe",
o

requerimientos 8. 9. Validaciones de las


entradas
Secuencia
exacta
de
operacibn
Respuesta a situaciones anormales, incluidas: Desbordamiento Fallas en
c~irnunicaciones
Manejo de errores y recuperacin Efecto de las
acciones
da los usuarios
Relacianes
entre
las
entradas y las salidas del
cisterna
inctuyendo Secuencias de entrada y
salida
Frmulas para convertir tos datos de entrada en datos
de
salida
Tarnbibn
puede ser apropiado dividir los requerimientos funcionales
en
sub-funciones o sub-procesos,
dn
que esto signifique una
dccisidn
de
diseno,

es decir esta
subdivicii5n
es solo por
organizacdn
y no afecta ni anticipa el
disefio.
Aplica para sistemas nuevos, de la
contrario
para un proceso de mantenimiento en un sistema
actual
se
pude
omitir
esta
seccin.
Solo en
caso
de que le proceso de
mantenimiento
afecte la
funcionalidaid
principal, identificar si
as
necesario el registro de
esta
secdbn.
Se deben
especificar
querjrnientos
nurn&ricos,

dinmicos y
estAtcos,
basados en la
interaccn
del
software
can las usuarios o en el sistema como un todo. Los
requerimientos
estAtiws
numericos
pueden incluir: 37 de 78 DMS 1
14labrDO
1
O Software
2.1.6
Interfaces
de Comunicacin 2.2 Requerimientos Funcionales
I
generalmente empiezan con "El sistema
deber
..."
I
l

El
niimero
de terminales o
clientes

soportadas El
nmero
de usuarios
simulMneos
soportados Cantidad y tipo de
informacidn
que manejar el sistema 2.4.1
Confiabilidad
38 de 78
DMS
1
14cibrRO
1 0
Direcci6n
de Finanzas Jefatura de
Servicios
de Coordinacin del Sistema de
Informacin
Financiera
m
Desarrollo y Mantenimiento de
Sobare
2.4.2
Disponi
biiidad
Hoja:
CMp:
Revisin: Fecha de
elaboracibn:
1

Fn
Inc
rnniieiimirntn.
dintirnirn~
nlirn&firna
a.
niiedc
inrliiir
nnr
1
L.,
'Y"
,
-y%.-.
,,
,,,"v.-'
-",,
""
..--,."..'~..---.r---.,T-.-..
,
r
-- ejemplo, el
ntirnero
de transacciones y tareas y la cantidad de
informacibn
que

sera
procesada en
ciertos
perodos de tiempo, para
operacones
normales
o en
pkos
da
subrecarga
de trabajo. Estos
reouerimieritos
deben ser
esweificados
de forma medible. Por
ejemplo:
"El
95% de las transacciones deben realizarse en
menos
de un segundo". Si no existen
requerimientos
mlnirnos
de rendimiento se debe
especifimr
en
esta
seccidn.
TarnbiBn
es
importante

indicar que los


limites
nurnkricos
que aplican a una
funcibn,
normalmente se especifican como parte de la
descripcibn
de
la
funcibn.
EspecificaciQn
del nivel de desempeo
del
&are
con respecto a la madurez, tolerancia a fallas y
rcuperacidn.
Se debe
espeflcar
la disponibilidad
requerida
para el sistema
1
completo
y10
para partes
especifms,
si
es el caso. 13.
1
2.4.3 Seguridad

1
Se debe especificar los factores de
proteccibn
del
soflware
de
2.4.4
Enciencia
2.4.5 Mantenimiento
acceso,
u&,
rnodificacibn
o
sliminacidn
de
infomaci6n,
por accidente o
rnalintmcionadamenk.
Requerimientos
especificas
podrian
incluir las necesidades de: Codificar cierta
informacibn.
Mantener
registros
histbrlcos
de
acceso
o
manipu

tacibn
de datos. Asignar ciertas funciones
an
rnbdulas
diferentes. Restringir la
comunicacidn
entre diferentes
fireas
del programa.
Verificacbn
de integridad de datos para
informacidn
critica.
Especificacin
del nivel de
desempefio
del software con respecto al tiempo y a
la
utilizacidn
de recursos. Por ejemplo, tiempo promedio de respuesta, tiempo
maximo
de respuesta, transacciones por segundo,
nomero
de usuario o transacciones concurrentes, uso
de
recursos
(ej.
Memoria, disco, comunicaciones, etc.).
Descripcibn
de los elementos que facilitaran la comprensin y la

realizacidn
de las modificaciones futuras del
somare.
Por
eiem~la.
estndares
de
codifri?gciri.
convencibn
para
nombres, 16.
17.
18.
2.4.6
Portabilidad
librerlai,
utilarias
de
mantenirnienh.
'
Descri~cidn
de
las
caracterlsticas
del
soffware
aue
permitan
su
2.4.7

Interoperabildad
2.4.8
Reusabilidad
. .
tmnsf@rencio
de un ambiente a otro. Capacidad de dos o
m8s
sistemas o componentes puedan
intercambiar
infarmacin
y usarla.
Propiedad
de
todo
producto o
subproclucto
de software o parte de
BI
para que pueda aprovecharse o utilizarse
por
varios usuarios como producto
Rnal
o en el
desarrolla
del propio
somre
o la
realizacibn
de
@ros

productos
de software.

41
de
78
DMS
t
14iabr120
1
0
Direccibn
de
Finanzas
Jefatura
de
Sewicios
de
Corirdirihn
del
Sistema
I
nformciiin
Finandeira
Desamllo
y
Mantenimiento
de

SQfbm
Anexo
3.
lnstnrdfio
del formato:
Plan
de Pruebas de Sistema
JIH1QD
UWI
313kP1
IHIVIUUUIW~I
W-4
tul
I1ClU
CUIl~WtlVU
WI
I
L,
digitos.
Ernpezanh
cada
afio
desde tino. Por
ejm
plo:
Hoja:
Wigo:
Revivisin:
Fecha
de

elaboracibn:
Clave
del formato:
DMS-A2.7
Debe
a:notarse
Ipdbr
el
nomera
de solicitud cambio o mantenimiento
que
asignar$
cada AP. Debiendo seguir la
siguente
nomonglatufa:
CLIcir
A-1
CI;.-.CI--LIAA~
st1
L.'~--M
*-ainfiCim
nhn
A No.
1.
Tipos de
prueba
Generales. Integridad de base de datos e
informacibn.
Las bases de datos y los procesos de base de datos deben ser evaluados como un
subcisterna.

Esta prueba debe probar los


subsistemas
independientemente de la
interface
de usuario.
Prueba
funcional. Esta prueba
se
enfoca a identifica que el sistema cumpla
con
loa
requerimientos
definidos, esta es una
prueba
de caja negra que se
basa
en los resultados obtenidos a travs de la
interfaz
gt&ftca.
Prueba de
interCaz
de
usuario.
Verifica
la
ineraiccibn
con el software, asegurando que el usuario cuenta con el acceso y
navegacidn
adecuada para las funciones de
la

aiglicaci~n.
Ademas
revisa que tos objetos de
inlerfaz
gdffca,
se
comportan
de
manera adecuada y cumplen
con
los
esandares
de
h
orgariizaci6n
o de la industria. Pruebas de rendimiento. Se verifica el desempeo
de
la
aplicacidn
para cumplir con
los
requerimientos
establecidos,
por ejemplo, tiempo de respuesta, numero de transacciones procesadas por unidad
de tiempo,
etc.
Pruebas de carga. Se verifica la
funcionalidad
del sistema, en
diferenles

situaciones de carga de trabajo esperada o


m8s
all
del
limite.
Se
verifica
tiempo de respuesta, nmero de transacciones procesadas,
etc.
Para
pims
de carga,
carga
alta
$osteni&,
airnuiacibn
rta
carga en un periodo de
tiempo,
ej. Cierre mensual,
cumportamiento
de las cargas en diferentes
configuraciones
de
equipo. Dnde dice:
No.
Folio
2.
Tio
de

Prueba
Para
el
aso
de
un
proyecto
nuevo
se
substituyo
par
el
id
del
pmyecio.
DE~CRIPCION
IJE
PRUEBAS Considerar
la
lisia
de
que
se anexa
par&
decidir
tas
pruebas de sistema
que
se
consideradn.

realizando la misma
transaccitin
a la
ves,
ancho de banda disponible. Algunas de estas pruebas pueden haberse considerado e
n pruebas de
funcionalidad
(si es un requerimiento de la
aplicacidn)
o pruebas de carga (al haber
probadQ
situaciones de
carga
fuera de los limites esperados, .
...
. .
..
. . , .. .. ej.
Numero
de
usuarios
Conectados
mas
alia
aei
limite
esperado).
Pruebas de control de
acceso

y
seguridad.
Pruebas
de niveles de acceso a la
aplicacidn,
a fin de
verificar
que el nivel de acceso es adecuado
para
los datas o funciones de negocio,
segh
se requiera. Pruebas de seguridad a nivel sistema que aseguren que
sblo
los
usuarias
autarizados
tienen acceso al sistema y son capaces
de
accesar
la
aplicacibn
a travs del los canales apropiados. Pruebas de falla y
recuperacibn.
Permiten
asegurar
que
el sistema es capaz
ds
recuperarse ante
una

falla de
software
o
hardware
con la consecuente
perdida
de integridad en los datos.
Se
prueba
que existan los
mecankmos
adecuados de respaldo y
recuperacibn
de
informaeibn,
o de
autocorreccdn
de transacciones que no fueron completadas,
identificacibn
de datos inconsistentes en la base de datos y su respectiva correccin. Pruebas de
configuracidn.
Verifican
que la
aplicacibn
se comporta adecuadamente en diferentes plataformas de
hatdware
o
software
para
las

cuales fue realizada.


incluyendo
uso de
drferentes
versiones de
sistema
operativo,
marcas
de
browsers,
etc.
Pruebas de
instalacibn.
Verifica que la
aplicacidn
y sus actual
iaaciones
sean instaladas
adecuadamente.
42 de 78 DMS 1
141ab~/20
10
Direccin de Finanzas Jefatura de Servicios de Coordinacin del Sistema da Hoja:
Cbdigo:
441abr12010
10.
Fecha Fin
Indicar
fechas
fin para los eventos de prueba

par
este
plap.
3. 4. 5. 6. 7. Informacin Financiera Desarrollo y
Mantenimiento
de
Software
Revisibn:
Fecha de
elaboradi5n:
Criterios a Satisfacer ID
Componente
a
Probar
Nombre del Componente Caso de Prueba
Resultado
Esperado Indicar la tolerancia a fallas o
criterios
para decidir si los
pFDductos
son
satisfactorios en esta prueba. Considerar
1s
importancia
de
cubrir
ldentificador
del
curnponente
a probar.

Nombre
del componente a probar. Caso de Prueba relacionado, Describir
el
resultado esperado.
CALENDARIWI~N
8. 9. Prueba Fecha Inicio Nombre de la
prueba
de sistema a probar.
tndicar
fechas de inicio para los eventos de prueba
contemplados
por este
plan.
Siguiendo el siguiente formato:
dd/mmlaaaa,
en dnde:
dd:dla,
mm:dia
y
aaaa:afio.
1
Por ejemplo:
1

Anexo 4. Manual de Usuario 44 de 78


DMS
1
141abr12010

-.
Oireccin
de Finanzas Jefatura de Servicios de
Coordinacidn
del
Sistema de
Infomacidn
Financiera Desarrollo y Mantenimiento de Software Hoja:
Cbdigo:
Revisibn:
Fecha de
elaboracibn:

3mmw-oiliwr
n
w-w5
'm- *
Ilwiot-aV-r'r%"-"C"YLYy&RL
o.
m
Q
-m--BSXE
Huja:
&diga:

Revhi&n:
Fecha
de
elabomcih;
1
Direccidn
de
Finanzae
Jefatura
de
S%viciDs
de
Coorriiha&.bn
del
STisfema
de
hthrmai&
Financie&
Qemllsr
y
Maritenirnimto
do
Sdftwan
45
de
78
WS
3
&br/201O

. .
Direc~ign
os
Finanras
Jefatm
de
SmicSos
de
GodnacIdn
del
Sistema de
lnfomaCtbn
Finmiera
ihwrmtt~
y
Mantenimientb
de
Software
Hoja:
cwig?:
Revisibn:
Fwba
#e
elabumin:
w
de
78 DMS
1
14/abr/"k10

Direebpi
&
Finmas
*a;
rt%3
de76
JeWws
d&StVW
dh
Cuordtnacibn
del
Sistema
,
m
aids
Irifmm
Fi*#mn:
'i
Anexo 5.
Arifisis
y Diseo

Drmibn
de Finanzas Hoja: 49 de 78 Jefatura de
Servicios

de
Coordinacibn
del Sistema de
Codgo:
DMS Informacin Financiera
Revisibn:
v-E
m
[
Desarrollo y Mantenimiento de Software
I
1
Fecha de elaboracin:
1
141abr12010
Anexo 5. Instructivo del formato:
AnBlisis
y
Diseno
Clave
del
formato:
DMSdA3.2
Debe
anotarse
Indicar el numero de solicitud cambio o
mantenmiento
que
asignar&
cada

AP,
Debiendo seguir
la
siguiente
nommglatura:
Siglas del
sistemaModulo-afio-nmero
consecutivo con 4
digitas.
Empezando
cada
ano
desde uno. Por ejemplo:
SPEPM-2010-0001
Para el caso de un
proyecto
nuevo
se substituye por
el
Id del
Pm@oO
Contiene la
estructura
tnbrna
del
sistema, es decir la
descomposicibn
del sistema en
subsisIemas.
Asl

como la
identifmcibn
de los componentes
que
integran los
subsistemas
y las relaciones de
interaccidn
entre ellos. Se recomienda que este documento se utilice como un
indiw
de todos
los
cumponentes
del sistema que sirvan para evidenciar dicha
estructura.
Se indica el
esandar
de
codificacin
a
modularidad
de
forma
gdfica,
con la que se trabajad para el
desarrollo
de cada uno de los
cbmponentes,
segun sea el caso. En caso de ser un sistema nuevo,
especificar

esta
seccibn
. El diagrama describe la arquitectura
flsica
y
organizacidn
de los servidores,
asi
coma tipos de dientes que accedern al
rnbdulo.
Contiene la descomposicin
del
sistema
en
subsistemas.
As
corno la
identificacibn
de los componentes que integran los
subsistemas
y las relaciones de
interaceibn
entre ellos. Normalmente se realiza mediante un diagrama
de
descomposi~ibn
TOPDOWN.
Contiene
el
detalle de los componentes que permita de manera evidente su

construccin
y prueba en el
ambienb
de
progrmaci0n..
No.
1. 2. 3.
4.
5. 6. Donde dice: No. Folio
7.
Arquitectbnica
1.1. Arquitectura
Ldgica
1.2. Arquitectura
Flsica
1.3,Estrkicturalnternadel
sistema 2. Detallada

Estructura
de
menos
Diagriamas
de
Ngivegecidn
del sistema
Gu
las
de
estila En esta
subseccibn

se detallan los siguientes puntos


para
el
alndlisis
y desarrollo del sistema: 50 de 78 DMS
1
f
4labrl2010
Direccidn
de Finanzas Jefatura de
Servicios
de
Coofdinacidn
del Sistema de Informacin Financiera
DesarrolIo
y Mantenimiento de
Software
8.
Casos
de Uso detallados
ExpliwMn
detallada
de pantallas, incluyendo validaciones
Diagrama$
de clases En
esta
subseccibn
se
detalla
el

diagrama que a
contihuacin
w
enlista
para
analisia
y
desarrollo
del
sistema:
Hoja:
Cdigo:
FSevtvEsidn:
Fecha de elaboracin: 2.2. Vista
Lbgica
1
Diagrarnas
Entidad
Relacidn
2.4.
Vista
de
Datos
Diagramas
de
secuencidcolabraci~n
En
esta
subseccibn
se

detallan los elementos que a


continuacidn
se
entista
para
analicis
y desarrollo del sistema: 13.
1
Valida
EL,
RPI
[ Nombre, puesto y
firma
del
Cliente
y
Respor
11. 12.
1
.
1
Pruebas
que
vatidb.
Elabord
(AN,DI)
Verifico
(RE) Diccionario de datos Nombre, puesto y firma del
Analista

y
Disenador.
Nombre, puesto y
firma
del Revisor
que
verificd.

Anexo
6.
Rcsgiitm
de
Rastreo
DESARROLLO
51
de 78
DMS
t
't
4iabr120
1
0
DreMdn
da Finanzas
Jefaturq
de
SeNicbs
de!
Cosrdinaibn

dd
SkIerna
de
Infomacibn
Financiera
Desarrollo
y Mantenimiento de
Software
reducto+
de ,
.dllct,
1
c:!::::
~rabaio
Prueba
'
Hoja:
Cdigo:
Revbibn:
Fecha
de
daboraddn:

EVRLUACION
oa
iupacro
I
\proliciuin
del
Cambios

.M
Anexo 6. Instructivo del formato: 53 da 78 DMS 1 1
4ia
brl20
1
O
Direccidn
de Finanzas Jefatura de Servicios de
Coordinadbn
del Sistema de
Infurmacibn
Financiera Desarrollo y Mantenimiento de
SofMare
Clave del formato: Registro de Rastreo Hoja:
Cdigo:
Revisidn:
Fecha de elaboracin:
DMS-A3.2
nomenglatura:
Siglas del
cistemaModulo-aiio-nmero
consecutivo con 4
digitos.
Empezando cada
aAo
desde uno. Por ejemplo:
SPEPM-2010-0001
Debe anotarse

Seccin
dedicada para el control del requerimiento, desde su registro y seguimiento, has
ta su cierre o
wncelacidn.
Las columnas de la
Definicion
Inicial se
llenan
durante la No. A. Donde dice: MATRIZ DE REQUERIMIENTOS Etapa de
Analisis
del Proyecto. Indicar
.el
niirnero
de solicitud cambio o mantenimiento que asignar cada AP. Debiendo seguir la sigui
ente
l.
(
Por ejemplo:
I
DEFINICI~N
INICIAL No. Folio 2. Considerar
Requerimientos
Derivados, tanto Funcionales bas,
Instakcion,
Fecha de Registro
Para
el caso
de
un
proyecb
nuevo se

enumeran
todos los
reguierlmientos
levantados para dicho
proyecto
de acuerdo al
producto
"
Fecha en
la
que
se
registra el requerimiento. Siguiendo el
siguiente
formato:

9.
lnterfaz
Interna Productos o Componentes Funcionales
Internos,
Relacionados
(R):
Dependientes (D}, Precedentes
(P)
6
Siguienk(S)
Considerar
interfaces
ftsicas,
funcionales y de ambiente.

10.
lnterfaz
Externa Productos o Componentes Funcionales Externos.
Relacjonados
(R
),
Dependientes
(D),
Precedentes (P)
b
Siguientes (S)
Direccibn
de Finanzas Hoja: Jefatura de
Sewicios
de
Coordinacibn
del Sistema de
Cdigo:
l
nforrnacibn
Financiera
Revisih:
Desarrollo y Mantenimiento
de
Soffwar@
Fecha de elaboracin: Considerar
interfaces
fisicas,
funcionales y de ambiente.
ANAUSIS

Esta
columna
se llena durante ta etapa de Anlisis del 54 de 78
DMS
1
14/abr12010
Requerimiento. 11. Productos de Trabajo del Describir tos productos de trabajo,
relacionados al Segundo Nivel Requerimiento, que lo estn detallando durante
la
etapa de
andlisis.
Corresponde al nivel de
Esp2ciftcacitin
de Requerimientos y Casos de Uso.
DISE~O
Los componentes de Tercer
Nivel
se llenan durante la etapa de
Diseo
del Requerimiento 12. Productos de
Trabgjo
del Describir los productos de trabajo, relacionados al Tercer Nivel Requerimien
to, que lo
asan
detallando durante la etapa de
diseno.
Corresponda
al
nivel de Diseno
Detaitado
(Diagramas

de Clase, Estado, Secuencia, Flujo,


B.D.,
Arquitectura,
etc)
DESARRQLLO
Se definen los Productos de Trabajo que definen los Casos de Prueba relacionados
al
Requerrn
bnta.
13. Productos
de
Trabajo de Se definen
los
Productos de Trabajo que definen los Cacos Casos de
Prueba
de Prueba relacionados
al
Requerimiento. 14. Productos de Trabajo
del
Es todo Producto de Trabajo,
relacionado
al Requerimiento, Cuarto
Nivel
que contiene
el
Miga
de
dssrrollo.
CAMBIOS AL REQUERIMIENTO
Cambios

a los
requerirnientus
o
cambios
par mantenimiento a
los
sistemas que ya estn en
produmbn,
los
cuales
debieron
ingresar por
medio
de la "Solicitud de Cambio o

55 de
78
DMS
1
14/abr/2QIU
Hoja:
CW$m
Revisibn:
Fecha de
e1abaraCibn:
l%SI%
Hdja
de
Wmon
de Cambios".

S&n
dedfcada
para
Itevar
el
control
de los cambios
solcitados
a los requerimientos.
Seccan
para
el
mgisfro
del
mbb,
se
rmka
al
ihki
que
se
detecta
el
cambio
a1
requerimiento
a
rnantenirniento,
Clave. de
ta

Solicitud que contiene toda la


inbmaciQn
relacionada
aI
cambio.
Productos
de
hbja
afectados.
Si
es
un
Cambio
a
un
Requerimiento,
indicar
b
Clave del
B.
24.
25.
26.
[Jirei=ci6n
de Finanzas Jefatura de Servicios de
Caordinocibrr
del
Sistema
de
Informacbn

Fnianciera
&sarro110
y
Mantenimiento
de
SofMare
Administmcibn
de
Catnhias
Siuiendo
el siguiente
formato:
Objetivo
i'
Descrip&n
del
Cambia
/
Nuevo
WeqkisirniEntO
Tipo
de Solicitud o
cambio
Estdtus
1
EVALUACION
DE
IMPACTO 32.
REGISTRO
DE

SOLlCtTUD
rnbmo.
Dwipcbn
general del
cambio.
Tipo
de
mrnbicr
pudiendo ser.
%porte,
Defecto,
Cambia, Otro.
Esiatus
del
Cambio: En
Fraceso,
Diferida, Aprobada, Rechazada, Cerrada o Cancelada.
l?~sultado
de
!a
evaluacion
del
impacto.
Resultado de
la
aprobaudh
del
cambio.
Pudiendo
ser

SVNQ.
Dicho
cornRB
debe&
estar conformada
por
la
mlxima
i~itorhdad
&t
&res,
hP,
RCIMG,
RL
y CL
coma
rnlnima.
Prioridad
de
1a
atencibn
al
cambio.
Pudiendo
ser; Alta, Media
o
Bala.
Esfueran
mqurido
para

al
carnbis.
Nombre
del
responsable
del cambio al
rquerimierito.
Los
nombres
de
lbs
resprisables
se
deben
actualizar
en la hoja "Listastr.
Nombre
del
usuario
que
solicita
J
cambio.
I
Los
nambres
de los solicitantes se deben
actualizar
en
ta

hoja 27.
28.
29.
30. 31.
I
21,
22.
23.
1
Agrobacibn
del Grupo de Cambios Prioridad
Esfueno
Respmhle
Solicitante
I
Fecha de
Saticitud
S~ll&ud
de Cambio
Producto
de Trabajo Clave
del
Req
"Listas".
Fecha en
quese
solicita
el
cambio,
Siguiendo

el
siguiente
formato:
ddfmrn/aaa>
en
dbnde:
dd:dCa,
rnrn:dia
y
aaiaa:Mri.
Por ejemplo:

1
Direr&i&n
de
Finanzas Hoja: 56
de
78
J&atkir&
de
SarviciQPl
de
Coordinacilin
de!
Sistema
de
Cbdigo:
DMS
inforinac~n

Financigra
Revisidn:
i
m
Oesarroito
y
ManMnirnbnta
de
Software
Fecha da
dabaracibn:
q41abrD010
l4tabr@ID
34.
Fecha
Ptanseda
Fecha
en
ta
que
se
planea
e!
fin del cambio.
de
Fin
Siguiendo
e4
siguiente formato:
dd/mm/aaaa,

en
dbnde4:
dd:dia,
rnm:dia
y
aaaa:aRo.
Pw
ejempk:
~4iabr2010
35.
Fecha
de
Check
out
Fecha en que se toma
dd
repct~itoil
el
producto
de
trabajo
a
modificar.
Sguiendo
el siguiente
f~m9to:
ddlrmnlaaaa,
en
dbW:
dd:di%,

rnrn:dia
y
aa@:aflo.
Por ejemplo:
74labrQ09
0
Fe&
de Check
in
Fecha en que se toma
del
repcisitgrio
el
pmducta
de
@abajo
a
modificar.
Siguiendo el
siguiente
fomiata:
ddlrrirnfaaaa,
en
d6nde:
dddia,
mm:dia
y
aaaa:aPio.
Por
ejernpb:

t4/&rf20
10 36.
FPI@~
~eal
inicio
Fecha
en
la
que
se
inicia realmente el
crrnbio.
Siuiendo
al
siguierile
formato:
ddlmmlaaaa,
en
dwde:
dd:dia,
mm:dFa
y
aziera:eh

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