Metodologia de Desarrollos Informaticos V613

VERSION: 6
METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

INFORMATICOS
FECHA ACTUALIZACION: Agosto de 2008
CODIGO MANUAL: INFP001009
INDICE
1. OBJETIVOS.................................................................................................................... 2
2. CICLO DE VIDA DEL SISTEMA PARA MAPFRE SEGUROS........................................2
2.1. ETAPA DE DEFINICION........................................................................................................................2
2.1.1. Fase de conceptualización. ..................................................................................................4
2.1.2. Fase de Análisis de Requerimientos. .................................................................................................4
2.1.3. Fase de Análisis de Impacto. .............................................................................................................4
2.2. ETAPA DE ANALISIS Y DESARROLLO.............................................................................................5
2.2.1. Fase de diseño. ...................................................................................................................................5
2.2.2. Fase de codificación. ........................................................................................................................7
2.2.3. Fase de prueba. ..................................................................................................................................7
2.2.4. Fase de implantación. ......................................................................................................................13
2.2.5. Procedimiento de Ejecución de Scripts, Creación y Compilación de Objetos en Producción.........14
2.2.6. Monitoreo a los cambios sobre el código fuente..............................................................................15
2.2.7. Fase de seguimiento. ........................................................................................................................15
3. PROCEDIMIENTO PARA EL MANTENIMIENTO PREVENTIVO Y CORRECTIVO DE
APLICACIONES................................................................................................................16
4. Metodología Para el Mantenimiento Preventivo de Aplicaciones..................................17
4.1. Metodología Para el Mantenimiento Correctivo de Aplicaciones...........................................................18
4.2. Metodología de cómo proceder a una Solicitud de acuerdo al tipo de problema....................................19
5. METODOLOGIAS......................................................................................................... 21
5.1. MODELO EN CASCADA PURA .........................................................................................................21
5.2. MODELO EN ESPIRAL.........................................................................................................................22
5.3. MODELO DE PROTOTIPADO EVOLUTIVO.....................................................................................23
5.4. MODELO DE ENTREGA POR ETAPAS.............................................................................................24
6. EVIDENCIAS................................................................................................................. 26
7. METODOLOGÍA PARA LA ADMINISTRACION DE CAMBIOS A APLICACIONES
SOPORTADAS POR TERCEROS....................................................................................27
7.1 DEFINICION .........................................................................................................................................27
7.2 AUTORIZACIÓN DEL DESARROLLO................................................................................................27
7.3 PRUEBAS................................................................................................................................................27
7.4 PUESTA EN PRODUCCION..................................................................................................................27
7.5 SEGUIMIENTO.......................................................................................................................................28
1
VERSION: 6

INFORMATICOS
1. OBJETIVOS
Dotar a la Compañía de soluciones informáticas de calidad y a la medida de sus

necesidades, que generen diferencias competitivas y le permita optimizar su desempeño
operativo y sus procesos de gestión empresarial.
Definir una Metodología de Desarrollo para toda la organización con lineamientos técnicos
claros y precisos que sirva de apoyo a los equipos definidores y desarrolladores en la
implementación de los requerimientos de usuario, de una manera rápida, óptima, eficiente
y que disminuya los riesgos inherentes a los procesos tecnológicos.
Garantizar a través de la intervención de los usuarios finales en las fases de definición y

pruebas, el cumplimiento de los requerimientos establecidos para cada proyecto de
acuerdo a las necesidades de la organización.
Establecer claramente las evidencias a través de las cuales los usuarios y los informáticos
formalizarán la ejecución de cada una de las fases de desarrollo del proyecto, así como la
interacción y los convenios de acuerdo que se fijen para el cumplimiento de los
requerimientos.
2. CICLO DE VIDA DEL SISTEMA PARA MAPFRE SEGUROS
El ciclo de vida es el conjunto de actividades que comprende el desarrollo de un proyecto

de sistemas desde los requerimientos del usuario, pasando por su instrumentación,
puesta en producción y su mantenimiento.
El ciclo de vida establece el orden especifico de las diferentes etapas del desarrollo, los
puntos de control y seguimiento y los entregables de cada fase, (ver Formato Ciclo de vida).
A continuación se detallan las dos grandes etapas que deben cumplirse en el desarrollo
de proyectos de soluciones informáticas de MAPFRE Seguros. Así mismo dentro de cada
una de ellas se especifican las fases que las componen y que a su vez conforman el ciclo
de vida del sistema:
2.1. ETAPA DE DEFINICION
La etapa de definición se centra sobre el que. Esto es, durante la definición el equipo
responsable realiza la conceptualización del negocio y de la solución informática,
identifica que información ha de ser procesada, que función y rendimiento se desea, que
interfases han de establecerse, que restricciones de diseño existen y que criterios de
validación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los
requisitos clave del sistema y del software.
2
VERSION: 6

INFORMATICOS
Las fases que se llevan a cabo en la etapa de definición son:
3
VERSION: 6

INFORMATICOS
2.1.1. Fase de conceptualización.

El usuario final debe realizar un documento escrito en el cual se plasman los
requerimientos y/o necesidades, que según su criterio deben ser implementados en el
sistema, explicando claramente el concepto del negocio y detallando lo que desea
implementar en el sistema. Este entregable se denomina Definición Preliminar, y como
mínimo debe contener: Nombre del proyecto, Objetivo, Alcance. Este documento debe ser
elaborado con el apoyo del Área de operaciones, para garantizar que se contemplen los
cambios que puedan derivar sobre los procesos, normas y políticas de la compañía. En el
caso de cambios menores se aceptará como definición el envío de correo electrónico con
la descripción de la necesidad. Se consideran cambios menores los desarrollos de bajo
impacto en el sistema y cuyo tiempo de realización puede variar entre uno y cinco días.
2.1.2. Fase de Análisis de Requerimientos.

En esta fase se determinan e identifican los diferentes aspectos técnicos y/o situaciones
de procedimiento que inciden directa o indirectamente en el funcionamiento de las
aplicaciones existentes. Se deben relacionar las actividades o tareas a realizar para evitar
situaciones de conflicto o problemas operativos con otras módulos del sistema durante el
transcurso del desarrollo o incluso después de la puesta en producción garantizando una
perfecta interrelación entre los mismos. Las tareas que surgen de esta fase se incluyen en
el documento de Especificación de Requisitos (ver Formato 1) y en el se pueden plantear,
de ser necesario, una o varias alternativas de solución, las cuales serán discutidas en la
siguiente fase con el usuario para determinar la solución adecuada. Esta actividad es
realizada por el Área de informática. En los proyectos que involucren armado de
productos, el Formato de Definición de Producto hará las veces de Especificación de
Requisitos para el módulo de Emisión y Siniestros (ver Formato Armado Emisión),(ver
Formato Armado Siniestros).
2.1.3. Fase de Análisis de Impacto.

Es el proceso mediante el cual los responsables de informática y el área usuaria realizan
un estudio y refinamiento de las especificaciones hechas en la Fase de
Conceptualización, realizando una revisión detallada de cada una de las funcionalidades
que se desean dentro del proyecto, considerando los siguientes aspectos para cada una
de ellas, la especificación de la función del sistema, análisis del impacto que el desarrollo
pueda generar sobre otros módulos, sobre el sistema en general y el establecimiento de
las restricciones de diseño que debe considerar el software y la estructura y/o
requerimientos de hardware a utilizar.
El desarrollo de esta fase se realiza a través de reuniones entre el responsable

informático y el usuario con el objeto de identificar alternativas, proponer elementos de
solución, evaluar los diferentes enfoques y especificar un conjunto preliminar de requisitos
de la solución. Producto de las reuniones, de ser necesario el área usuaria debe realizar
los ajustes correspondientes sobre el documento inicial de definición, una vez esto se
realice el área informática debe elaborar un documento con fundamento en el formato de
especificación de requisitos (ver Formato 1) diseñado para tal fin, que reúna todas las
especificaciones y acuerdos de servicio pactados con el usuario así como los tiempos de
4
VERSION: 6

INFORMATICOS
duración de cada una de las actividades, documento que debe llevar la firma de
aprobación del usuario y el cual servirá como medio de control de entrega, alcances y
calidad del producto una vez ha sido construido.
Puntos a tener en cuenta para la realización de las reuniones:
Deben asistir tanto el área usuaria como informáticos, siempre debe asistir el líder del
área usuaria o su delegado.
Se debe sugerir una agenda que sea lo suficientemente formal para que cubra todos los
puntos importantes.
Se debe invitar siempre al área de operaciones.
Como resultado de esta fase, queda como registro el documento definitivo de

requerimientos de usuario.
2.2. ETAPA DE ANALISIS Y DESARROLLO
La etapa de desarrollo se centra en el cómo. Esto es, durante esta fase, el responsable
informático de la instrumentación describe como han de diseñarse las estructuras de
datos y la arquitectura de la solución, como han de implementarse los detalles de
programación, como ha de traducirse el diseño a un lenguaje de programación y como ha
de realizarse la prueba, implantación y seguimiento del proyecto.
Las fases que se llevan a cabo en la etapa de Desarrollo son:
2.2.1. Fase de diseño.

El diseño es el proceso en el que se establecen los fundamentos para el desarrollo del
software. El diseño es la única forma mediante la cual podemos traducir con precisión los
requisitos del cliente en un producto o sistema acabado. El diseño de software sirve
como base de todas las posteriores fases del desarrollo y de la etapa de mantenimiento.
Sin diseño se tiene un alto riesgo de construir un sistema inestable, un sistema que falle
cuando se realicen pequeños cambios; un sistema que pueda ser difícil de probar; un
sistema cuya calidad no puede evaluarse en las etapas iniciales del desarrollo sino hasta
el final cuando queda muy poco tiempo para ello y conlleva a costos por encima de lo
presupuestado.
Los pasos que comprende el diseño son los siguientes:
Diseño de Datos. Este debe contener el modelo entidad relación y el diccionario de

datos de los diferentes objetos (tablas, vistas, índices, secuencias, etc.) que la
solución requiere. En el caso de la creación o modificación de la estructura de un
objeto existente, se debe definir los atributos y longitud de los campos, los constraints
de los mismos; se debe establecer el dimensionamiento, la llave primaria, índices y los
campos mínimos con los cuales deben ser creados (Cod_cia, cod_user, Fec_Actu y
5
VERSION: 6

INFORMATICOS
Fec_Baja cuando se trate de tablas maestras (parámetros)), todo esto según

corresponda al objeto que se este diseñando. Dado que nuestro sistema cuenta con
múltiples bases de datos, en el modelo, los objetos deben hacer referencia a la base
de datos que pertenecen, Para ello se debe apoyar en el formato de Diseño de Datos,
(ver Formato 2).
Especificación de Programa. Tiene por fin, precisar para cada una de las
funcionalidades del Software a desarrollar, las entradas, procesos y salidas de cada
uno de los programas / objetos que integran la solución. En este se debe explicar los
detalles más importantes y/o relevantes de los programas de manera clara, precisa y
sin ambigüedad. Para ello se debe apoyar en el formato de especificación de
programas, (ver Formato 3).
Diseño de la interfaz. Este paso comprende la elaboración de prototipos de

pantallas y formularios, prototipos de salidas impresas y el diseño de archivos planos
de entrada/salida. En los dos últimos nos apoyaremos en el uso de formatos creados
para la definición de los mismos, (ver Formato 4) para el diseño de pantallas y
formularios se deben seguir las directrices que a continuación se relacionan.
Directrices para el diseño de pantallas y formularios. Se sugieren tres categorías:
Interacción general
Ser consistente
Ofrecer una realimentación significativa (interfaz interactiva)
Preguntar por la verificación de cualquier acción destructiva no trivial
Permitir una vuelta atrás fácil en la ejecución de la mayoría de las acciones
Reducir la cantidad de información que debe ser memorizada entre acciones
Buscar la eficiencia en el diálogo, el movimiento y el pensamiento
Proteger el sistema de los errores de usuario que puedan afectarle causándole
algún fallo.
Categorizar las actividades con base en su función y organizar la distribución de
la pantalla convenientemente
Las opciones de menú sean consecuentes con la función
Proporcionar facilidades de ayudas
Utilizar verbos de acción simples o frases verbales cortas para nombrar las
ordenes
Visualización de la información
Mostrar solo aquella información que sea relevante en el contexto actual

No abrumar al usuario con datos, utilizar un formato de presentación que permita
una asimilación rápida de la información
Utilizar etiquetas consistentes, abreviaciones estándar y colores predecibles
Permitir al usuario mantener el contexto visual
Producir mensajes de error significativos
6
VERSION: 6

INFORMATICOS
Utilizar mayúsculas y minúsculas, tabulaciones y agrupaciones de texto para

ayudar la comprensión
Considerar la geografía disponible en la pantalla y utilizarla eficientemente
Entrada de datos
Minimizar el número de acciones de entrada de datos que debe realizar el
usuario
Mantener la consistencia entre la información visualizada y los datos de entrada
Permitir al usuario personalizar la entrada de datos
Desactivar ordenes que sean inapropiadas en el contexto actual
Permitir al usuario controlar el flujo interactivo, el usuario debe poder evitar
acciones innecesarias y salir de situaciones de error sin tener que abandonar el
programa.
Proporcionar ayuda en todas las acciones de entrada de datos
Eliminar las entradas innecesarias.
Requerimientos de Hardware y Software. En este punto se especifican los recursos de

Hardware y Software que son necesarios para la instrumentación de la solución
informática con los cuales se amplia o modifica la plataforma tecnológica actual. Es de
anotar que no todos los proyectos requieren ampliación y/o modificación de la plataforma,
con lo cual la realización de este punto dependerá de ello. Como evidencia se deja el
formato de Especificación de Requisitos, (ver Formato 1)
Como resultado de la fase de diseño adicionalmente se debe dejar como evidencia el plan
y/o cronograma de actividades del proyecto. Si este proyecto afecta la ejecución de otro u
otros proyectos, se debe dejar constancia escrita con el visto bueno del líder del Área
usuaria.
2.2.2. Fase de codificación.

Es el proceso mediante el cual se plasma el diseño en el lenguaje de programación
elegido. Para llevar a cabo esta labor, los analistas, a partir de la especificación de
programa, diseño de datos y de interfaz, y apoyados en los Manuales de Estilo de
programación siguiendo las recomendaciones y directrices que en el se especifican,
realizan la escritura del código fuente. En esta fase es fundamental tener en cuenta las
recomendaciones que se dan más adelante en cuanto a afinamiento de aplicaciones.
El resultado de esta fase es el código fuente desarrollado.
2.2.3. Fase de prueba.

Una vez que el software ha sido implementado, debe ser probado para descubrir los
defectos que puedan existir en la función, en la lógica y en la implementación.
Para realizar la prueba se debe tener en cuenta dos aspectos fundamentales:
7
VERSION: 6

INFORMATICOS
La configuración del software que incluye la especificación de requisitos del software, la
especificación del diseño y el código fuente.
Una configuración de prueba que incluye un plan y procedimiento de prueba del cual
queda como evidencia un documento (Ejecución de Pruebas).
El plan y procedimiento de pruebas tanto informático como de usuario deben quedar

escritos y aprobados por el usuario y el director del proyecto, como evidencia del proceso,
(ver Formato 5).
Durante el proceso de pruebas se deben realizar las siguientes actividades:
Prueba de Unidad. Se centra en la verificación de cada uno de los cambios y/o

modificaciones realizados en los programas del módulo. Usando la descripción del
diseño detallado como guía, se prueban los caminos de control importantes, con el fin
de descubrir errores dentro del ámbito del módulo. El responsable de esta actividad es
el analista de informática sin la participación del usuario. Estas pruebas se hacen con
datos normales y con datos extremos.
Prueba de Regresión. Una vez terminada la prueba de unidad debemos centrarnos

en verificar que cada una de las funcionalidades previamente existentes en cada uno
de los programas y/o o módulos modificados no hayan sufrido ningún cambio o
alteración. Esta prueba esta a cargo del analista de informática.
Prueba de Integración. Una vez que ha sido garantizado el correcto funcionamiento

de cada uno de los componentes del módulo y la consistencia y validez de la
información suministrada por estos; hay que garantizar de la misma forma que la
interacción entre los componentes del módulo y a su vez entre este con los demás
módulos del sistema, no causa inconvenientes sobre el funcionamiento general de la
aplicación. Para ello es necesario apoyarse con los analistas expertos de cada
modulo, con el fin de identificar los posibles inconvenientes que se podrían ocasionar
por la puesta en marcha del proyecto. El responsable de esta actividad es el líder
informático del proyecto con el apoyo de los analistas expertos y los analistas que
realizaron el desarrollo, en esta actividad no participa el usuario.
Para la realización de las anteriores pruebas se debe seguir el procedimiento que

se describe a continuación:
Entorno Base de Desarrollo y Base Cero (Analistas)
1.Planificar la prueba. Crear el entorno e trabajo para realizar las pruebas

necesarias, de acuerdo al plan de pruebas.
2.Confección de un lote de prueba. Selección de datos coherentes y/o

consistentes que permita la realización de la prueba así como la valoración de los
resultados esperados. Esto debe reflejarse en el plan. En los casos en donde se
requiera trasladar información de producción a base de pruebas, se deben seguir
8
VERSION: 6

INFORMATICOS
los lineamientos establecidos en INFP001011_Manual Procedimiento para migración de

datos de Producción a los ambientes de Prueba y/o Desarrollo , el cual regula el
tratamiento de la confidencialidad de la información de nuestros clientes.
3.Ejecución de la prueba. Se debe realizar la prueba teniendo en cuenta que pase

por los arreglos hechos y a la vez probar que no se afecten los módulos alternos.
4.Verificación de la información generada afectada por el desarrollo.
5.Realizar scripts de validación para garantizar la calidad e integridad de la base

de datos.
6.Armado de scripts para el traslado del desarrollo a otros entornos (Traslado 0).
Estos scripts deben ser preparados para pasar los cambios y/o programas al
entorno de Base cero, y los mismos servirán para una vez finalizadas las pruebas
de usuario, llevar los mismos al entorno de producción.
Prueba de Validación. Es la prueba realizada por el usuario, mediante la cual

debe confirmar que se cumplan los objetivos del proyecto plasmados en el
documento de definición y en el análisis de requerimientos, así como el correcto
funcionamiento del sistema. El registro de las actividades de validación debe
quedar consignado en el formato de ejecución de pruebas, así como la aprobación
de las mismas y de puesta en producción (ver Formato 5).
Para la realización de la prueba de validación se debe seguir el siguiente

procedimiento:
Entorno Base Pruebas (Usuarios)

Una vez culminadas las anteriores fases, continuamos con la prueba final de
usuario, las cuales serán coordinadas por el Director de Aplicaciones de la unidad
respectiva en Informática y programadas en unión con él o los analistas
encargados del desarrollo y los usuarios finales; en esta programación se fijarán
los puntos cruciales sobre los cuales el usuario debe hacer énfasis al momento de
realizar sus pruebas, para realizar esta actividad se deben apoyar en el formato de
ejecución de pruebas (ver Formato 5).
9
VERSION: 6

INFORMATICOS
1.Planificar la prueba
Deben existir los usuarios creados para las pruebas respectivas. Se debe
informar al área dueña del requerimiento para que asigne el usuario que
realizara las pruebas. Para realizar esta actividad se deben apoyar en el
formato de ejecución de pruebas (ver Formato 5).
2.Solicitar la confección de un lote de prueba al usuario.

Tener en la base de pruebas datos que serán traídos de la base de
producción para que el usuario pueda trabajar o en su defecto que el usuario
los genere.
3.Ejecución de la prueba.
La responsabilidad del usuario, es seguir al pie de la letra el plan establecido
de pruebas y con base en este se debe generar un semáforo con todos los
problemas. Dependiendo del problema se debe asignar un color, para que con
este, informática establezca las prioridades a trabajar.
Rojo: Error que obliga a la corrección inmediata, para que el usuario

pueda dar su visto de aprobación al desarrollo que se está probando.
Amarillo: Error considerado no grabe y que no impide la puesta en

producción del desarrollo. Este tipo de error implica un nuevo acuerdo con
el usuario para su corrección.
Verde: Significa que las pruebas han sido exitosas y a total satisfacción
del usuario.
En caso de que las pruebas den como resultado Rojo o Amarillo, el usuario
debe especificar claramente, la razón de su calificación, es decir especificando
la forma correcta de como debió actuar el sistema y por que.
Como documento soporte de las pruebas se debe diligenciar el formato de

ejecución de pruebas, entregado al analista responsable y/o Director de
Aplicaciones. (ver Formato 5).
4.Verificación de la información generada/afectada por la prueba.

Una vez terminada la prueba se deben ejecutar los procesos de validación de
información. En caso de detectar inconsistencias de información, que no
hubiera percibido el usuario en sus pruebas, se debe informar de la situación al
mismo, hacer las correcciones necesarias y generar unas nuevas pruebas, de
acuerdo al punto 3.
10
VERSION: 6

INFORMATICOS
5.Solicitud de la aprobación por parte del usuario una vez que no exista ningún
error. El usuario a través del formato de ejecución de pruebas debe formalizar la
aceptación de las mismas y la fecha de puesta en producción del desarrollo.
6.Pruebas del Sistema. Dependiendo de la complejidad del desarrollo y su

afectación sobre las Bases de datos y/o procesos, el responsable informático y el
Director de aplicaciones establecerán las pruebas de Sistemas que se requerirían
para el desarrollo en cuestión, basados en el apartado de Prueba de Sistema,
mencionado a continuación.
7.Solicitud de traslado a entorno de producción. Una vez del visto bueno del
usuario se procederá al paso de los programas y/o tablas afectada a la base de
producción a partir de la base de pruebas.
Prueba de Sistema. Partiendo del hecho que el software como tal solamente es
un elemento dentro del sistema de información, se debe garantizar que su
integración con los demás componentes del sistema (hardware, base de datos,
sistema operativo, redes, etc.) es adecuada, a través de diferentes pruebas cuyo
propósito es ejercitar intensivamente el sistema total una vez integrado y previo a
la puesta en producción. Entre otras, las pruebas que se deben realizar son:
Prueba de recuperación. Es una prueba del sistema que fuerza el fallo del
software de muchas formas (Ej. Caída de la base de datos) y verifica que la
recuperación se lleva a cabo apropiadamente.
Prueba de seguridad. Su objetivo es verificar que los mecanismos de protección
incorporados en el sistema lo protegerán, de hecho, del ingreso no autorizado.
Prueba de resistencia. Están diseñadas para enfrentar a los sistemas con

situaciones anormales, de tal forma que demande recursos en cantidad, frecuencia
o volúmenes anormales, con el objeto de identificar los límites del sistema
(Consumo de recurso en disco).
Prueba de rendimiento. Esta diseñada para probar el rendimiento del software

en tiempo de ejecución dentro del contexto de un sistema integrado (Afinamiento
de aplicaciones).
Afinamiento de Aplicaciones
Después de garantizar las pruebas de integración en el sistema hay que
garantizar que esa información la podamos obtener de manera rápida y oportuna,
y para esto es fundamental un adecuado afinamiento de los programas, utilizando
herramientas que nos brinden una valiosa ayuda como lo son explain plan y tk-
prof, etc., las cuales aportan información precisa de la manera en que se están
accesando las tablas, el tipo de consulta realizada, índice usado, el tiempo de cpu
empleado, el número de registros seleccionados vs tiempo empleado etc.
Procedimiento: Afinamiento de Aplicaciones.
11
VERSION: 6

INFORMATICOS
12
VERSION: 6

INFORMATICOS
Software Nuevo
Cualquier instrucción que involucre un acceso a la BD deberá estar debidamente

afinada.
El afinamiento consiste en revisar el plan de ejecución procurando que el
optimizador tome el método de acceso menos costoso.
Se deberá revisar los índices de cada tabla, con el fin de buscar la mejor forma
de realizar cualquier acceso.
Se deberá revisar el número de registros de cada tabla, tratando de ubicar las
tablas más grandes, puesto que ellas serán las que consuman más recursos.
Si no existe un índice adecuado, deberá considerarse la posibilidad de crearlo.
Para esto, deberá usarse la fórmula del 4%. (Ver Concepts Manual).
Desde las fases de análisis y diseño de soluciones informáticas se deberá tener
en cuenta el afinamiento como parte fundamental y buscar la mejor manera de
accesar la base.
Deberá plantearse soluciones informáticas que permitan accesar la BD de una
manera sencilla.
Se debe tener en cuenta que todas las instrucciones DML utilizan un plan de
ejecución para accesar la BD, y que dependiendo de éste, la instrucción será más
o menos optima.
Recuerde que existen 15 métodos de acceso (Ver Concepts Manual cap. 13) que
van desde el menos costoso (registro por rowid) hasta el más costoso (full scan
sobre la tabla).
Cuando se tenga acceso por rango (range scan) se deberá procurar limitar al
máximo el rango.
En instrucciones que involucren join entre tablas y que se presente “nested
loops”, siempre deberá colocarse de primero en el from aquella tabla (outer
table) que tenga la menor cantidad de registros y de segunda (inner table) aquella
que tenga más registros, pero necesariamente deberá indexarse por los campos
incluidos en la condición del join.
Para visualizar el plan de ejecución de una instrucción DML utilice la instrucción
explain plan.
Si la instrucción que se está analizando contiene una vista recuerde que este
objeto es una tabla “virtual” y que se arma a partir de una selección de información
de tablas reales, por lo tanto, se deberá analizar el plan de ejecución de la
instrucción que genera la vista.
Luego de verificar que el plan de ejecución de la vista es adecuado, se deberá
analizar el número de registro que contiene, puesto que si el resultado es grande
(promedio 3.000 filas), se deberá considerar la posibilidad de cambiar este
elemento (la vista), por otra alternativa (buscar directamente en las tablas
involucradas), debido a que esta información se obtendrá de manera “secuencial”
(full scan).
13
VERSION: 6

INFORMATICOS
Software ya implementado en Real.
Si va a afinar un programa específico, coloque la instrucción de seguimiento al

comienzo del mismo: set sql-trace = true.
Si va a afinar todo un módulo o varios programas, active los parámetros de
seguimiento requeridos (sistema operativo y base de datos) para un usuario que
normalmente ejecute los programas en mención, de tal manera que todos los
programas que él ejecute se les realice seguimiento.
Las anteriores operaciones generan archivos que contienen valores estadísticos
de utilización de recursos por cada uno de las fases de las instrucciones DML
(parse, execute, fetch).
Esta información deberá transformarse en información entendible mediante la
herramienta tkprof que genera estadísticas de utilización de recursos por fase y
los planes de de ejecución, con sus respectivos métodos de acceso por cada
instrucción DML.
Dicha información deberá analizarse, con el fin de encontrar un método de
acceso que disminuya el costo de la instrucción.
La instrucción DML deberá modificarse obligándola a tomar el método de acceso
indicado.
Ejecute dicha instrucción por fuera del programa y verifique que el resultado sea
el esperado, es decir, que no altere la información de debería obtenerse.
En el caso en que el análisis de la información de seguimiento no arroje una
alternativa de mejoramiento, el paso a seguir es analizar la lógica del programa
para tratar de ubicar alternativas de mejoramiento.
Además deberá buscarse cualquier instrucción que pueda cambiarse y mejorar
el rendimiento global del programa, es decir, instrucciones que incluyan vistas, or,
join, etc.
2.2.4. Fase de implantación.

Para aprobar la puesta en producción del proyecto, el usuario enviará un correo
electrónico anexando el formato de ejecución de pruebas (ver Formato 5) debidamente
diligenciado. Una vez el usuario final ha confirmado la aprobación del proyecto y este ha
sido puesto en producción, se deben realizar tres tareas, la primera es diligenciar en su
totalidad la encuesta de satisfacción por parte de usuario líder, para la cual se apoyará en
el formato, (Ver Formato 6), copia de este, será entregado a la Gerencia de Informática y a
la Dirección encargada de procesar esta información, las otras dos tareas se pueden
llevar a cabo en paralelo, la segunda de ellas es la capacitación a los usuarios finales,
esta labor puede ser realizada directamente por el área informática o a través del área de
operaciones dependiendo de la magnitud del proyecto, la tercera es la coordinación con el
área de tecnología en la instalación y publicación (Accesos a Datos y Programas) del
proyecto, este proceso puede involucrar tareas tales como:
Ejecución de scripts para creación y/o modificación de objetos.

Ejecución de scripts de migración de datos, de la base de pruebas a la base de
producción y/o de bases externas al sistema que se esta implantando.
14
VERSION: 6

INFORMATICOS
Ejecución de scripts de instalación de programas en menús, Jobs, programas,

traslados de reglas, creación de datos variables
Traslado de programas a producción
Creación y/o modificación de los procedimientos de ejecución de Jobs y del árbol de
jobs
Accesos a Datos y Programas
Todos los puntos mencionados anteriomente, relacionados con la puesta en producción,

deben ser realizados de acuerdo al siguiente procedimiento.
2.2.5. Procedimiento de Ejecución de Scripts, Creación y Compilación de Objetos en

Producción.
Con el fin de poder mantener un mejor control y registro de los cambios y/o nuevas
implementaciones que se realizan en el sistema, en lo que se refiere a datos, objetos,
tablas, programas, etc. es importante que se sigan las directrices enunciadas a
continuación:
En Mantis, están disponibles cuatro tipificaciones de cambios:
a) Objetos: Su utilizará para relacionar creación o modificación de objetos de base

de datos: tablas, indices, procedures, packages, triggers, etc.
b) Programas: Se refiere a la creación/modificación de parámetros o puesta en real

y traslados de programas (inp, pco, javas, pco, rdf, etc), y a la ejecución de los
mismos (tareas, programas, Jobs, etc.), siempre y cuando se requiera ejecutar en
ocasiones diferentes a la programación normal.
c) Parámetros del Sistema: Para modificar cambios sobre niveles de control

técnico, o sobre tablas restringidas para la ejecución de scripts ejecutados por los
operadores.
d) Ejecución de Scripts: Para realizar el traslado de información de tablas maestras

que han sido alimentadas y validadas en el ambiente de pruebas Of0, así como el
traslado de Listas de Valores, Opciones de Menú, Etiquetas, Códigos de Error,
Menús, Perfiles y cualquier otra información que haya sido preparada para el
proceso de pruebas y se considere pertinente llevar a producción.
De acuerdo con las necesidades del proyecto el analista líder del desarrollo, debe
informar a través de Mantis de acuerdo al instructivo publicado en Docushare las
incidencias que se requieran según la tipificación descrita, estas serán autorizadas por el
Director a cargo del proyecto, en ausencia de este por otro Director y/o Analista Master
Designado, o en su defecto por la Gerencia.
El área de tecnología es la responsable de la ejecución de los scripts y la puesta de los

cambios en real de acuerdo con la incidencia informada en Mantis, así mismo a través de
15
VERSION: 6

INFORMATICOS
esta herramienta los Analistas y Directores podrán validar el resultado de la ejecución.

Dicha autorización forma parte de la documentación del proyecto (Ver Instructivo Mantis).
2.2.6. Monitoreo a los cambios sobre el código fuente

Como parte de las labores de control de cambios en el código fuente que deben ejercer
los directores a los diferentes objetos que son modificados a raíz de los desarrollos
llevados a cabo por los analistas, se establece hacer una revisión de forma aleatoria,
seleccionando un conjunto de objetos escogidos según criterio y/o decisión del Director a
cargo, según el nivel de impacto, o proyecto para comprobar que en estos no existan
inclusiones de código que no corresponda con las reglas del negocio, o que evidencien
una vulnerabilidad de la seguridad de la información o riesgo de fraude o alteración
impropia de los datos. Esta labor se realizará a través del siguiente procedimiento:
a) El área de tecnología dispondrá de una carpeta en la cual están incluidos los objetos
que han sido modificados diariamente, generando un archivo (log), donde se registran las
diferencias del código modificado, contra la versión original. Se generará un archivo para
cada mes con la acumulación de los objetos modificados en ese periodo.
b) Esta información será la base para el monitoreo aleatorio por parte de los directores.
c) El director deberá revisar y validar por lo menos 20 objetos dejando constancia de su

verificación y de los resultados en la Planilla de Control de Cambios diseñada para tal
efecto, Dichas planillas quedarán depositadas en una carpeta física resguardada por cada
Director.
2.2.7. Fase de seguimiento.

Es vital garantizar la calidad de los proyectos que desarrollamos por tal motivo es
necesario realizar seguimiento a los programas que son puestos en producción con el fin
de poder detectar algún imprevisto no encontrado durante la fase de pruebas, así como al
funcionamiento de los programas y del sistema. Este proceso de debe realizar durante un
periodo que puede ir desde dos semanas hasta dos meses, dependiendo de la
complejidad del proyecto, para tal fin se deben utilizar los validadores ya desarrollados,
scripts de comprobación de datos utilizados durante el periodo de pruebas. Esta fase se
da por terminada con la entrega de dichos scripts, la documentación y la capacitación
correspondiente al equipo de mantenimiento.
Debe existir un plan de seguimiento, un informe para valorar que efectivamente se haya
cumplido.
Procedimiento para cambios de Emergencia
Se consideran cambios de emergencia las modificaciones de carácter urgente y que

exigen ser realizadas con inmediatez. Estos surgen por solicitud de las áreas usuarias y
están en cabeza de los gerentes, quienes deben solicitarlo a través de correo dirigido a la
gerencia o a las direcciones de informática. Es función de la Gerencia de Informática
16
VERSION: 6

INFORMATICOS
determinar el carácter de cambio de emergencia y autorizar la realización del mismo por

medio de correo.
Dada la naturaleza de este tipo de cambios, el procedimiento para su ejecución debe ser
ágil, lo que puede implicar no seguir todos los pasos establecidos en la metodología y en
consecuencia, una vez realizado el desarrollo no se tendrá registro de todos los
entregables exigibles para los proyectos y/o cambios menores (ver aparte de
EVIDENCIAS).
3. PROCEDIMIENTO PARA EL MANTENIMIENTO PREVENTIVO Y CORRECTIVO DE

APLICACIONES
Objetivo: Brindar a la Compañía, herramientas que garanticen el correcto funcionamiento de los

sistemas de información con los cuales cuenta, garantizando alta calidad en el desempeño de los
mismos y en la información suministrada por estos.
Dotar a la Organización un equipo informático, con alta capacidad de análisis, facilidad para la
detección y corrección de errores.
PROCEDIMIENTO
El CENTRO DE ATENCION A USUARIOS (C.A.U), se encargará de atender todas las

solicitudes que tengan que ver con problemas Tecnológicos y/o Informáticos, de las
Unidades de Generales, Vida, Credimapfre y Ecuador.
Se utilizara Mantis (Mantenimientos Informático de Solicitudes) como un esquema

centralizado para el registros de requerimientos o solicitudes informáticas de nuestros Clientes
Internos y Externos, con fin de dar solución a sus problemas informáticos y/o tecnológicos.
Cualquier problema Informático y/o tecnológico que se reporte a través de una llamada
telefónica, correo electrónico, será registrada como solicitud en Mantis por el operador del
C.A.U., con una serie de datos básicos relevantes para hacer seguimiento. Vale la pena
señalar que la solicitud puede se reportada directamente por la aplicación MANTIS,
cumpliendo igualmente con los requisitos anteriores.
Los analistas de mantenimiento de la Gerencia de Informática, solo atenderán los casos

radicados por medio de una solicitud colocada a través de los mecanismo indicados en el
párrafo anterior.
Establecer claramente el problema. Es fundamental suministrar la mayor cantidad de

información posible, especificando con precisión la naturaleza del problema, indicando en que
sistema y Compañía se produjo el error, anexando los documentos (pólizas, pagarés,
propuestas, etc.) del problema y los pantallazos que permita visualizar con exactitud el error
presentado en el sistema.
Las solicitudes serán revisadas y analizadas previamente por el ingeniero responsable del
proceso, basado en la experiencia y el conocimiento priorizará y estimará el tiempo de solución
17
VERSION: 6

INFORMATICOS
asignándolas a los analistas de mantenimiento, los cuales recibirán una notificación vía correo
electrónico desde la herramienta Mantis (mantis@mapfre.com.co).
4. Metodología Para el Mantenimiento Preventivo de Aplicaciones.
Entiéndase como mantenimiento preventivo, todas aquellas incidencias, errores o fallas detectadas
de manera anticipada por los analistas de informáticas, es decir que las mismas, son detectadas
antes que el usuario final se percate de ellas. Estas anomalías en el sistema son detectadas a
través de la ejecución de Validadores o cuadres automáticos, que realizan testeo sobre la
integridad de la información de nuestras bases de datos. Estas validaciones son el producto de
iniciativas y necesidades surgidas o detectadas propiamente por el área de Informática.
Para la ejecución de estos validadores, se siguen los siguientes pasos:
Definir aspectos críticos y relevantes en el sistema para poderlos validar, aspectos tales como
cuadres de valores e integridad de datos.
Elaborar programas en PL/SQL para analizar la integridad y consistencia de la Base de datos.
Actualización constante de los validadores, aprovechando las inconsistencias reportadas por los
usuarios del sistema, a través del CAU y los errores detectados por los mismos miembros de la
Gerencia De Informática.
Entrega a la dirección de Tecnología de los programas Validadores nuevos para su ejecución,

para lo cual se ha elaborado un Job el cual tiene periodicidad semanal.
Realizar análisis y diagnostico diario de cada una de las incidencias reportadas por los
validadores, de tal forma que se pueda realizar una clasificación de los errores arrojados por estos,
según el grado de gravedad que cada uno presente y el número de incidencias que cada validación
arroje.
Realizar la programación de la solución de cada caso, teniendo en cuenta el diagnostico de cada

problema, permitiendo a través de este diagnostico priorizar la ejecución de las actividades
Al priorizar las actividades se debe tener en cuenta, la gravedad del problema, el número de
casos por problema o error, la fecha de la última operación afectada, la facilidad de implementar la
solución, urgencias por cierres o clientes que esperan solución.
 Para resolver una incidencia detectada a través de los validadores, el analista de informática
debe colocar una solicitud en Mantis, tal como lo haría un usuario final, es decir debe en-
tregar todos los detalles que permitan identificar la naturaleza del problema, la herramienta
Mantis a su vez envía automáticamente un correo electrónico notificando el cambio realizado
a la persona responsable del módulo y al Auditor de Sistemas.
Al momento de colocar una solicitud de este tipo, los usuarios finales responsables de la
realización de las pruebas del módulo del área en cuestión, serán avisados por Mantis, al respecto
18
VERSION: 6

INFORMATICOS
de la colocación de una de una de estas solicitudes. Para que estén enterado, de este tipo de
cambios y puedan al finalizar su corrección dar su visto bueno al respecto.
Los problemas sencillos deben ser resueltos rápidamente, evitando así que se conviertan en
graves, al postergar su solución por pretender resolver problemas complejos que consuman mucho
tiempo
Resolver de manera definitiva e integral los problemas detectados y diagnosticados, tanto en la

Base de Datos como en los programas.
La autorización de este tipo de cambios en Real, son otorgadas por el Director a cargo del área,
en ausencia de este por otro Director y/o Analista Master Designado o en su defecto por la
Gerencia.
Un vez resueltos los incidentes (trasladados a Real), se debe obtener por parte del área usuaria el
visto bueno sobre la realización o implantación de los mismos.
La gerencia de informática entrega formalmente, mediante un medio físico, una relación de los
scripts reportados durante el mes por mantenimiento preventivo ó cambios de emergencia a la
persona responsable de cada módulo, quien a su vez firma una planilla de recibo de la
información.
Los programas validadores deben ser enviados semanalmente (fin de semana), de tal manera
que constantemente se haga seguimiento a cada uno de los errores, a los que estos programas
realizan seguimiento.
4.1. Metodología Para el Mantenimiento Correctivo de Aplicaciones.
Entiéndase como mantenimiento correctivo, todas aquellas incidencias, errores o fallas detectadas
por los usuarios que utilizan los elementos de TI, al momento de realizar cualquier operación en
particular sobre alguno de estos.
Para el mantenimiento correctivo, se siguen los siguientes pasos:
El analista de mantenimiento debe ingresar a Mantis para verificar las solicitudes asignadas por el
Ingeniero Master, es trabajo del analista analizar y entender claramente el problema que se ha
reportado en cada una de las solicitudes, si el problema no es claro, se debe reclasificar dejando la
solicitud en estado (Ampliar Información), esta solicitud quedara nuevamente bajo la
responsabilidad del operador telefónico del CAU, para que realice un complemento de la
información o la retorne al Analista de Mantenimiento.
Priorizar la solución de las solicitudes, teniendo en cuenta, la gravedad del problema, el número
de casos inconsistentes presentes en la Base de Datos, la fecha de la última operación afectada, la
facilidad de implementar la solución, urgencias por cierres o clientes que esperan solución.
Solución de incidencia por script. La creación de Script, modificación de objetos, ejecución de

programas para solución a una solicitud deben ser reportadas por el analistas de mantenimiento en
19
VERSION: 6

INFORMATICOS
Mantis y autorizadas por el Director a cargo del área, en ausencia de este por otro Director y/o
Analista Master Designado o en su defecto por la Gerencia.
Realizar scripts para validación de la Base de Datos, este proceso se origina después de analizar
el error y determinar que pueden existir más casos relacionados con el problema origen, se debe
realizar un testeo a la base de datos determinando la fecha mas antigua y la mas reciente, con el
objeto de determinar desde cuando se viene presentando el error y cual fue la última vez que
ocurrió.
Una vez resuelta la solicitud, el analista de mantenimiento debe describir en forma clara la
solución dada y capacitar de ser necesario al operador telefónico del CAU, clasificar la incidencia
(por palabra clave para identificar el error) y el tiempo real de solución, en horas y fracción de
hora.
Seguimiento a soluciones: es responsabilidad del operador telefonico del C.A.U., verificar las
solicitudes que se encuentran en estado resuelto y explicar con claridad la solución dada al usuario
que la reporto, bien sea positiva o negativa, respecto al inconveniente por el cual se originó, esta
respuesta se dará mediante una llamada telefónica o un correo electrónico. Una solicitud se dará
por cerrada cuando el usuario que colocó el reporte queda satisfecho con la solución dada al
problema.
Realizar seguimiento de errores, garantizando que no se vuelvan a presentar. Enriquecer y

complementar los programas validadores, con las nuevas incidencias reportadas a través del CAU
y con los scripts realizados para detección de los errores reportados.
Explicar y enseñar con claridad la operativa y procedimiento correcto de aquellas solicitudes que
no son por problemas del sistema, sino desconocimiento tanto del usuario como del Analista del
CAU.
La persona responsable de Area debe entregar a la Gerencia de Informática, un informe semanal
(primer día hábil), las estadísticas de las solicitudes recibidas, indicando tiempo promedio de
respuesta, número de solicitudes pendientes por módulo, número de solicitudes resueltas al mes
etc.
Entregar los informes mensuales, para seguimiento de solicitudes y capacitación de usuarios, a la

Gerencia de Informática y Dirección del área.
4.2. Metodología de cómo proceder a una Solicitud de acuerdo al tipo de problema
Error operativo del usuario: Su solución deberá ser inmediata, indicando al usuario la causa
del error y la forma correcta de realizar la operación, efectuando una capacitación directa al
usuario.
Error de procedimiento o que requiera de la intervención del área de Dirección General
(Tesorería, Siniestros, Gerencia Técnica, etc.): La operación realizada por el usuario es
correcta, pero se presenta inconveniente, respecto al procedimiento o la decisión de cómo
realizarse la operación; depende del área usuaria, la solicitud será remitida al funcionario
responsable de dar la solución.
Error del programa de computador: Se solicitará al usuario una descripción exacta de la
situación, para lo cual deberá indicar con claridad como actúo el sistema y como debería haber
20
VERSION: 6

INFORMATICOS
actuado. Además, de ser posible, el número de documento, la operación que estaba

realizando, el producto, etc. La solicitud será grabada en el sistema para que la Subgerencia
de Informática la analice y dé la solución respectiva.
Problemas de equipo: Se Solicitará al usuario una descripción exacta de la situación, para lo
cual deberá indicar con claridad el equipo afectado (Terminal, PC, impresora, módem, UPS,
Canal de Comunicaciones, Canal de Voz etc.). Además de ser posible, el problema exacto que
presenta el equipo.
El tiempo de respuesta de las solicitudes recibidas dependerá de la calidad y veracidad de la
información suministrada.
21
VERSION: 6

INFORMATICOS
5. METODOLOGIAS
Una vez establecido el ciclo de vida para los desarrollos de MAPFRE Seguros, cabe
mencionar que desde el punto de vista estratégico es posible realizar algunos ajustes a
dicho ciclo para afrontar algunos de los proyectos dependiendo de las características del
mismo, su magnitud, calidad de la definición, posibilidades de cambios en la definición,
recursos disponibles y necesidades de la organización. Por lo anterior, a continuación se
detallan algunas de las metodologías que se podrán utilizar en MAPRE Seguros en donde
se especifica, para cada una de ellas, las situaciones bajo las cuales es aconsejable optar
por una u otra, para su elección tenga en cuenta que:
El modelo de ciclo de vida que se selecciona influye tanto en el éxito del proyecto como
en cualquier otra decisión de planificación.
El modelo de ciclo de vida asegura que cada paso conlleve a acercarse a la consecución
del objetivo.
De acuerdo con el modelo seleccionado se puede aumentar la velocidad de desarrollo,
mejorar la calidad, el control y el seguimiento, minimizar el gasto y riesgos, o mejorar las
relaciones con el cliente interno.
5.1. MODELO EN CASCADA PURA
Es un modelo que progresa a través de una secuencia ordenada de pasos partiendo del
concepto inicial del software hasta la prueba, implantación y seguimiento del sistema. El
proyecto realiza una revisión al final de cada etapa para determinar si esta preparado para
pasar a la siguiente. Cuando se determina que una etapa no esta lista, permanece en esa
etapa hasta que se pueda pasar a la siguiente.
El modelo en cascada esta dirigido por documentos: los productos principales del trabajo
que se pasan de etapa en etapa son los documentos, las etapas del modelo son
secuenciales.
Se Recomienda Cuando:
Se tiene una definición estable del producto
Cuando se esta trabajando con metodología técnicas conocidas (Manuales de Armado,
Formatos de definición de consultas y reportes, etc).
Se construye una versión de mantenimiento bien definido de un producto existente.
Se esta migrando un producto existente un nueva plataforma.
Los requerimientos de calidad dominan sobre los requerimientos de costo y planificación.
Si se dispone de personal poco cualificado o inexperto porque presenta el proyecto con
una estructura que ayuda a minimizar el esfuerzo inútil.
22
VERSION: 6

INFORMATICOS
No Se Recomienda Cuando:
Hay dificultades en especificar claramente los requerimientos al comienzo del proyecto.
Se necesita flexibilidad para la realización de cambios en el transcurso del proyecto.
Se necesita mostrar resultados rápidamente, este modelo solo presenta resultados al
final del proyecto. Esto puede dar la sensación de desarrollo lento incluso sin ser verdad.
Se requiere un desarrollo rápido dado que puede generar una cantidad excesiva de
documentación difícil de mantener cuando se presenten cambios en el desarrollo del
proyecto o una vez puestos en producción.
Existen tres alternativas para minimizar las debilidades que tiene el modelo de ciclo de
vida de cascada pura, estas son:
1.Cascada con fases solapadas. Consiste en realizar el desarrollo de la metodología

permitiendo el solapamiento de una fase con otra, avanzando sobre las diferentes etapas
sin haber dado por concluidas las anteriores, de forma tal que por ejemplo se puede tener
adelantado el diseño global y el detallado sin haberse terminado el análisis de
requerimientos.
2.Cascada con subproyectos. En esta variación de la metodología se permite una vez

se tienen el concepto de software, el análisis de requerimientos y el diseño global,
subdividir el proyecto en subproyectos y aplicando a cada uno de ellos el resto de la
metodología de cascada, una vez cada subproyecto se termine, estos se deben integrar
en la fase de pruebas.
3.Cascada con reducción de riesgos. En esta alternativa se sugiere el uso de una

espiral (Se explica en la siguiente metodología) para el análisis de requerimientos y el
diseño global.
5.2. MODELO EN ESPIRAL
El modelo de espiral es un modelo de ciclo de vida orientado a riesgos que divide un

proyecto de software en mini proyectos. Cada mini proyecto se centra en uno o más
riesgos importantes hasta que todos estén controlados. El concepto riesgo se puede
entender como requerimientos poco comprensibles, arquitecturas poco comprensibles,
problemas de ejecución importantes, problemas tecnológicos, limitaciones de tiempo, etc.
Después de controlar todo los riesgos más importantes, el modelo en espiral finaliza del
mismo modo que el ciclo de vida en cascada. Se parte de una escala pequeña en medio
de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos y
continuación se establece una aproximación a la siguiente iteración, cada iteración
supone que el proyecto pasa a una escala superior.
23
VERSION: 6

INFORMATICOS
Cada iteración consiste en la ejecución de los siguiesen pasos:
1.Determinar objetivos, alternativas y límites.

2.Identificar y resolver riesgos.
3.Evaluar las alternativas.
4.Generar las entregas de esta iteración y comprobar que son correctas.
5.Planificar la siguiente iteración.
6.Establecer un enfoque para la siguiente iteración si se decide ejecutarla.
Hay poca identificación de requerimientos
Poca comprensión sobre la arquitectura
Se necesita generar un amplio desarrollo (Proyectos de mediano y largo plazo)
El proyecto requiere un análisis minucioso de riesgos
Se trata de un proyecto con poca sofisticación
Se trata de un proyecto de corto plazo con planificación determinada
5.3. MODELO DE PROTOTIPADO EVOLUTIVO
Es un ciclo de vida en el que se desarrolla el concepto del sistema a medida que avanza
el proyecto, normalmente se comienza con el desarrollo de los aspectos más visibles del
sistema se presenta al usuario y se continua con el desarrollo del prototipo basándose en
la retroalimentación que se recibe en algún punto usted y el usuario se ponen de acuerdo
en que esta es la versión definitiva del proyecto y en este punto se completan los trabajos
pendientes y se entrega el prototipo y el trabajo final.
Los requerimientos cambian con rapidez
El cliente es reacio a especificar el conjunto de los requerimientos
Cuando el usuario y usted no logran identificar de forma apropiada el área de aplicación
Cuando los desarrolladores no están seguros de la arquitectura o los algoritmos
adecuados a utilizar
Se requieren signos visibles de progreso
24
VERSION: 6

INFORMATICOS
Se trata de un proyecto de corto plazo
Se trata de un proyecto con poca sofisticación
Se requiere una estimación de tiempos confiable de lo que se tardaría en crear un
producto aceptable (Se puede fijar un tiempo de duración del proyecto, pero existe un
riesgo alto de que este varíe).
Existe un riesgo adicional con esta metodología que consiste en que esta aproximación
puede ser utilizada como excusa para realizar el desarrollo con el modelo de codificar y
corregir sin hacer análisis de requerimientos real, diseño real, y código pensado para
mantenimiento real.
5.4. MODELO DE ENTREGA POR ETAPAS
En este modelo el software se muestra al usuario en etapas refinadas sucesivamente, en

cada etapa se conoce exactamente lo que se va a construir antes de proceder a su
desarrollo, se debe asegurar que las etapas que se planifican sean significativas para el
usuario y que el trabajo se distribuya dentro del personal de tal forma que se pueda
completar el trabajo a tiempo con fecha limite, en este modelo se realizan entregas
sucesivas al usuario a lo largo del proyecto. Se atraviesan los pasos del modelo en
cascada pasando por la definición del concepto de software, análisis de requerimientos y
creación del diseño global del programa completo que se intenta construir, a continuación
se procede a realizar el diseño detallado codificación, depuración y prueba dentro de cada
etapa.
Se requiere realizar entregas de funcionalidades útiles al usuario antes de terminar el
proyecto. Dependiendo de la planificación de desarrollo se puede entregar las
funcionalidades más importantes al usuario, para que este inicie la utilización del software
antes de la finalización del proyecto.
Se requiere la entrega de signos tangibles de progreso.
Existe alta presión sobre la planificación del desarrollo del proyecto.
Se trata de grandes proyectos de mediano y largo plazo
No existe una adecuada planificación a nivel técnico y de gestión, esto puede generar
inconvenientes para la conclusión del proyecto y para la integración del software.
En proyectos de corto plazo.
Se tiene poca identificación de requerimientos.
Es importante realizar una buena planificación de cada etapa para no caer en el error de
desarrollar en las primeras etapas componentes que dependen de aquellos que se
desarrollaran en las posteriores.
25
VERSION: 6

INFORMATICOS
VENTAJAS E INCONVENIENTES DEL CICLO DE VIDA

Capacidad De Modelo De Ciclo De Vida Cascada Pura Espiral Prototipado Entrega Por Etapas
Evolutivo
Trabaja Con Poca Identificación De Los Malo Excelente Excelente Malo
Requerimientos
Trabaja Con Poca Comprensión Sobre La Malo Excelente Malo/Medio Malo
Arquitectura
Genera Un Sistema Altamente Fiable Excelente Excelente Medio Excelente
Genera Un Sistema Con Amplio Desarrollo Excelente Excelente Excelente Excelente
Gestionar Riesgos Malo Excelente Medio Medio
Estar Sometido A Una Planificación Medio Medio Malo Medio
Predefinida
Requiere Poco Tiempo De Gestión Malo Medio Medio Medio
Permite Modificaciones A Medio Camino Malo Medio Excelente Malo
Ofrece A Los Usuarios Signos Visibles De Malo Excelente Excelente Medio
Progreso
Ofrece A Las Directivas Signos Visibles De Medio Excelente Medio Excelente
Progreso
Requiere Poca Sofistificación Para Los Medio Malo Malo Medio
Directivos Y Desarrolladores
RECOMENDACIONES SOBRE ESTIMACION DE TIEMPOS DE PROYECTOS
1.Evite Las Estimaciones De Improviso: La mejor política es simplemente no dar una

estimación de improviso, nunca se sabe lo lejos que va a llegar y es inútil intentar poner
condiciones.
2.Reserve Tiempo Para la Estimación y Planifíquela: Si se está estimando un proyecto

grande trate la estimación como si fuera un mini proyecto y tome el tiempo necesario para
planificar la actividad de estimación, de forma que se pueda hacer bien.
3.Use Datos De Proyectos Anteriores: El uso de datos documentados de proyectos

anteriores similares, contribuye a reducir el retraso de la planificación y el coste.
4.Use Estimaciones Basadas en el Desarrollador: Las estimaciones hechas por los

desarrolladores involucrados en el proyecto, son mas precisas que las hechas por
estimadores ajenos.
5.Estime Por Consenso: Cada miembro del equipo tiene que realizar la estimación de
una parte del proyecto de forma individual y luego en una reunión se comparan y/o
ajustan las estimaciones.
6.Estime a un Bajo Nivel de Detalle: Debemos basar la estimación en el examen

detallado de las actividades del proyecto, en general cuanto mas detallado sea el examen
mas precisa será la estimación.
7.No Omita Tareas Comunes: A continuación se muestran una lista de tareas que
normalmente se omiten: Recortes, Conversión de datos (migración), Instalación,
Personalización, Gestión del programa de prueba beta (pruebas informáticas),
Demostración del programa a los usuarios, Espera de reuniones para control de cambios,
26
VERSION: 6

INFORMATICOS
Trabajos de mantenimiento en los sistemas existentes durante el proyecto, Soporte

técnico de los sistemas existentes durante el proyecto, corrección de defectos,
Administración relacionada con el seguimiento de defectos, Coordinación con el grupo de
mantenimiento (capacitar), Coordinación con el área de tecnología, Soporte para la
documentación de usuarios, Revisión de documentación técnica, Integración, Días
Festivos, Vacaciones, Días de baja por enfermedad, Reuniones de la empresa y
departamentales y Formación
8.Use Herramientas de Estimación de Software: En proyectos grandes las

herramientas de estimación de software proporcionan una estimación mas precisa y una
menor incidencia en los retrasos y el coste que los métodos de estimación manual.
6. EVIDENCIAS
A manera de guía a continuación se relacionan los documentos entregables durante cada

una de las fases y los cuales deberán ser impresos y archivados en una carpeta soporte
del proyecto.
(*1) Las fechas programadas para los proyectos y cambios menores figuraran dentro del
cronograma general de tareas de cada Dirección.
(*2) El código fuente queda depositado dentro de la base de datos y/o en los directorios
de fuentes.
(*3) La elaboración del manual de usuarios y la actualizaciones de los mismos está a

cargo del Área de Procesos.
(*4) La elaboración de los manuales de procedimiento y la actualización de los mismos

está a cargo del Área de Procesos.
27
VERSION: 6

INFORMATICOS
7. METODOLOGÍA PARA LA ADMINISTRACION DE CAMBIOS A APLICACIONES

SOPORTADAS POR TERCEROS
Se entiende por aplicaciones soportadas o desarrolladas por terceros todas las soluciones
adquiridas a través de proveedores externos y cuyo soporte o mantenimiento es realizado
directamente por ellos.
7.1 DEFINICION
Todos los ajustes, modificaciones o implementaciones que se realicen sobre aplicativos

soportados por terceros deben contar con una especificación o documento de definición
que enmarque la necesidad planteada o funcionalidad que se requiere sobre dicho
aplicativo. Esta definición puede ser enviada por correo electrónico o algún medio que
permita evidenciar la solicitud.
Las solicitudes que se promuevan en este sentido deben ser enviadas por el usuario líder
o dueño del aplicativo, es decir, el responsable designado, y de estas se informará al
área de sistemas, con el fin de poder hacer una evaluación de la pertinencia y alcance.
7.2 AUTORIZACIÓN DEL DESARROLLO
Con base en el documento de definición, el proveedor deberá entregar una propuesta

formal que como mínimo incluirá aspectos económicos, técnicos, tiempo estimado o
cronograma y tiempo de seguimiento. La autorización de este desarrollo estará en cabeza
del área usuaria en consenso con informática. Deberá quedar evidencia física del aval de
informática a través de un acta o correo enviado al líder del área usuaria responsable del
cambio, así como de la aprobación del desarrollo por parte del área usuaria.
7.3 PRUEBAS
Dependiendo del impacto del cambio a realizar informática en acuerdo con el área usuaria
determinará la necesidad o no de establecer un ambiente de pruebas, esto dado que hay
cambios que afectan funcionalidades mínimas que no requieren ambiente especial de
pruebas y solo con la autorización escrita del usuario el cambio se coloca en producción.
En caso de determinarse la necesidad del ambiente de pruebas, una vez el proveedor
informa acerca de la terminación del desarrollo se procederá establecer el ambiente de
pruebas idóneo, el cual podrá ser proporcionando por el mismo proveedor o según sea el
caso se podrá configurar en la infraestructura de Mapfre.
Para efectos de la realización de la prueba se deberán seguir los lineamientos indicados

en este documento en el aparte sobre Fase de Pruebas en donde se hace referencia al
formato 5 que quedará como evidencia de este proceso.
7.4 PUESTA EN PRODUCCION
28
VERSION: 6

INFORMATICOS
Concluida de forma satisfactoria la fase de pruebas y ajustes y mediante el visto bueno

del usuario, (vía correo electrónico), se procederá a llevar los cambios al ambiente de
producción. Esta labor será realizada por el área de Tecnología con el soporte del
proveedor.
7.5 SEGUIMIENTO
Se debe acordar con el proveedor un periodo de seguimiento incluido en la propuesta en

el cual se validarán la calidad de las funcionalidades implementadas en términos de
desempeño y operación. El tiempo puede variar según el impacto de los cambios y será
acordado entre Informática, el área usuaria y el proveedor. Una vez terminado este
periodo y cumplidas las expectativas fijadas en la solicitud inicial, se dejará como
evidencia un acta en donde se registre el recibo a satisfacción por parte de Mapfre.
29

Metodologia de Desarrollos Informaticos V613

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologia de Desarrollos Informaticos V613

Cargado por

Copyright:

Formatos disponibles

VERSION: 6

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

Dotar a la Compañía de soluciones informáticas de calidad y a la medida de sus

Garantizar a través de la intervención de los usuarios finales en las fases de definición y

2. CICLO DE VIDA DEL SISTEMA PARA MAPFRE SEGUROS

El ciclo de vida es el conjunto de actividades que comprende el desarrollo de un proyecto

2.1. ETAPA DE DEFINICION

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

Las fases que se llevan a cabo en la etapa de definición son:

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

2.1.1. Fase de conceptualización.

2.1.2. Fase de Análisis de Requerimientos.

2.1.3. Fase de Análisis de Impacto.

El desarrollo de esta fase se realiza a través de reuniones entre el responsable

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

Puntos a tener en cuenta para la realización de las reuniones:

Como resultado de esta fase, queda como registro el documento definitivo de

2.2. ETAPA DE ANALISIS Y DESARROLLO

Las fases que se llevan a cabo en la etapa de Desarrollo son:

2.2.1. Fase de diseño.

Los pasos que comprende el diseño son los siguientes:

Diseño de Datos. Este debe contener el modelo entidad relación y el diccionario de

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

Fec_Baja cuando se trate de tablas maestras (parámetros)), todo esto según

Diseño de la interfaz. Este paso comprende la elaboración de prototipos de

Directrices para el diseño de pantallas y formularios. Se sugieren tres categorías:

Mostrar solo aquella información que sea relevante en el contexto actual

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

Utilizar mayúsculas y minúsculas, tabulaciones y agrupaciones de texto para

Requerimientos de Hardware y Software. En este punto se especifican los recursos de

2.2.2. Fase de codificación.

El resultado de esta fase es el código fuente desarrollado.

2.2.3. Fase de prueba.

Para realizar la prueba se debe tener en cuenta dos aspectos fundamentales:

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

El plan y procedimiento de pruebas tanto informático como de usuario deben quedar

Durante el proceso de pruebas se deben realizar las siguientes actividades:

Prueba de Unidad. Se centra en la verificación de cada uno de los cambios y/o

Prueba de Regresión. Una vez terminada la prueba de unidad debemos centrarnos

Prueba de Integración. Una vez que ha sido garantizado el correcto funcionamiento

Para la realización de las anteriores pruebas se debe seguir el procedimiento que

1.Planificar la prueba. Crear el entorno e trabajo para realizar las pruebas

2.Confección de un lote de prueba. Selección de datos coherentes y/o

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

los lineamientos establecidos en INFP001011_Manual Procedimiento para migración de

3.Ejecución de la prueba. Se debe realizar la prueba teniendo en cuenta que pase

4.Verificación de la información generada afectada por el desarrollo.

5.Realizar scripts de validación para garantizar la calidad e integridad de la base

Prueba de Validación. Es la prueba realizada por el usuario, mediante la cual

Para la realización de la prueba de validación se debe seguir el siguiente

Entorno Base Pruebas (Usuarios)

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

2.Solicitar la confección de un lote de prueba al usuario.

Rojo: Error que obliga a la corrección inmediata, para que el usuario

Amarillo: Error considerado no grabe y que no impide la puesta en

Como documento soporte de las pruebas se debe diligenciar el formato de

4.Verificación de la información generada/afectada por la prueba.

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005

6.Pruebas del Sistema. Dependiendo de la complejidad del desarrollo y su

Prueba de resistencia. Están diseñadas para enfrentar a los sistemas con

Prueba de rendimiento. Esta diseñada para probar el rendimiento del software

METODOLOGIA DE DESARROLLOS FECHA ELABORACION: Octubre de 2005