You are on page 1of 28

DEL PROCESO DE

PROPUESTA PARA LA ESTANDARIZACION


DE LOS DESARROLLOS DE SOFTWARE
PASE A PRODUCCION

UNIVERSIDAD JOSE ANTONIO PAEZ


CEUJAP
CENTRO DE EXTENSION
DIPLOMADO DE INGENIERIA EN PROCESOS

DEL PROCESO DE
PROPUESTA PARA LA ESTANDARIZACION
DE LOS DESARROLLOS DE SOFTWARE
PASE A PRODUCCION

Autor:
Raul S. Franco M.

Coordinador:
Marcos Palacios

Informe final de Diplomatura

San Diego, Septiembre de 2015

UNIVERSIDAD JOSE ANTONIO PAEZ


CEUJAP
CENTRO DE EXTENSION
DIPLOMADO DE INGENIERIA EN PROCESOS

DEL PROCESO DE
PROPUESTA PARA LA ESTANDARIZACION
DE LOS DESARROLLOS DE SOFTWARE
PASE A PRODUCCION

Autor: Raul S. Franco M.


Coordinador: Marcos Palacios
A
no: 2015
RESUMEN
Este informe tiene como objetivo establecer el punto de inicio una estandarizacion
del proceso de pases a produccion de sistemas. Se traspasa la responsabilidad
al equipo de mantenimiento y se empiezan a dar los servicios establecidos en
el acuerdo de nivel de servicio, una vez que se ha aprobado el sistema. Para
ello es necesario que, despues de haber realizado las pruebas de implantacion y
de aceptacion del sistema, se disponga del entorno de produccion perfectamente
instalado en cuanto a hardware y software de base, componentes del nuevo sistema
y procedimientos manuales y automaticos. En funcion del entorno en el que se
hayan llevado a cabo las pruebas de implantacion y aceptacion del sistema, habra
que instalar los componentes del sistema total o parcialmente. Una vez que el
sistema ya esta en produccion, se le notifica al responsable de mantenimiento, al
responsable de operacion.
Palabras Claves: Desarrollo de Software, Pase a Produccion, Proceso.

Indice general
Resumen

III

Introducci
on

VII

I. El Problema
1.1. Planteamiento del Problema . . . . . . . . . . . . . . . . . . .
1.2. Justificacion e Importancia . . . . . . . . . . . . . . . . . . . .
1.3. Objetivos de la Investigacion . . . . . . . . . . . . . . . . . . .
1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . .
1.3.2. Objetivos Especificos . . . . . . . . . . . . . . . . . . .
1.4. Bases Teoricas . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1. Ingeniera de Software . . . . . . . . . . . . . . . . . .
1.4.2. Desarrollo de Software . . . . . . . . . . . . . . . . . .
1.4.3. Entorno de Desarrollo . . . . . . . . . . . . . . . . . .
1.4.4. Soporte Tecnico . . . . . . . . . . . . . . . . . . . . . .
1.4.5. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.6. Mejora Continua . . . . . . . . . . . . . . . . . . . . .
1.4.7. Project Management Body of Knowledge (PMBOK) .
1.4.8. Business Process Modeling Notation (BPMN) . . . . .
1.4.9. Fundamentos de la Gestion de Servicios de IT: Basado
ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
en
. .

II. La Propuesta
2.1. Dise
no de la Propuesta . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Condiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IV

1
1
2
3
3
3
4
4
4
5
6
6
6
6
7
7
8
8
8
8

2.3.1. Condiciones Basicas . . . . . . . . . . . . . . . . . . . . .


2.3.2. Condiciones Especificas . . . . . . . . . . . . . . . . . . . .
2.4. Prioridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5. Actores o Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1. Jefe de Implementacion . . . . . . . . . . . . . . . . . . . .
2.5.2. Equipo Implementador de Soporte . . . . . . . . . . . . .
2.5.3. Administrador de base de datos (DBA) . . . . . . . . . . .
2.5.4. Analista de Pruebas . . . . . . . . . . . . . . . . . . . . .
2.6. Descripcion del Procedimiento . . . . . . . . . . . . . . . . . . . .
2.7. Riesgos del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . .
2.8. Indicativos y Estadsticas . . . . . . . . . . . . . . . . . . . . . . .
2.9. Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10. Documentos y planes de gestion asociados al proceso de Puesta en
Produccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10.1. Documento de aceptacion del cliente o cierre de contrato .
2.10.2. Documento de Gestion de Incidentes . . . . . . . . . . . .

8
9
10
11
11
11
11
11
12
15
15
16
16
16
17

III.Conclusiones
Referencias Bibliograficas . . . . . . . . . . . . . . . . . . . . . . . . .

18
19

A. BPMN

20

Indice de figuras
1.1. Proceso de desarrollo de software. . . . . . . . . . . . . . . . . . .
1.2. Diferentes entornos de Desarrollo. . . . . . . . . . . . . . . . . . .

5
6

2.1. Diagrama de Flujo de Pases a Produccion. . . . . . . . . . . . . .

14

VI

Introducci
on
La siguiente propuesta busca proporcionar al area de Sistemas los procedimientos, polticas y normas requeridas para efectuar los pases a produccion de los
aplicativos que han sido desarrollados por el area de Desarrollo de Sistemas y los
cambios de informacion requeridos por los usuarios.
La presente propuesta tiene como objetivo la entrega y aceptacion del sistema
en su totalidad, y la realizacion de todas las actividades necesarias para el paso a
produccion del mismo. En primer lugar, se genera la estrategia de implantacion,
se estudia su alcance y, en funcion de sus caractersticas, se define un plan de
implantacion y se especifica el equipo que lo va a llevar a cabo. Conviene se
nalar
la participacion del usuario de operacion en las pruebas de implantacion, del usuario final en las pruebas de aceptacion, y del responsable de mantenimiento. Las
actividades previas al inicio de la produccion incluyen la preparacion de la infraestructura necesaria para configurar el entorno, la instalacion de los componentes,
la activacion de los procedimientos manuales y automaticos asociados y, cuando
proceda, la migracion o carga inicial de datos.
Ademas hay que determinar los servicios (y niveles para cada uno) que requiere
el sistema que se va a implantar, y el acuerdo que se adquiere una vez que se
inicie la produccion. Hay que distinguir entre servicios de gestion de operaciones
(servicios por lotes, seguridad, comunicaciones, etc.) y servicios al cliente (servicio
de atencion a usuario, mantenimiento, etc.) que se deben negociar en cuanto a
recursos, horarios, coste, etc. Se fija el nivel con el que se prestara el servicio
como indicador de la calidad del mismo. Conviene se
nalar que la implantacion
puede ser un proceso iterativo que se realiza de acuerdo al plan establecido para
el comienzo de la produccion del sistema en su entorno de operacion. Muchas de
VII

las tecnicas del area de produccion de la Ingeniera Industrial se han migrado al


desarrollo de software en muchos casos con buen exito, recientemente los conceptos
de manufactura esbelta y mejora continua, se han empezado a utilizar en el area
del desarrollo de software.
En este trabajo se desarrolla una propuesta para la estandarizacion del proceso de pase a produccion de los desarrollos de software. Ahora bien, la presente
propuesta de informe esta organizado de la siguiente manera:
Captulo I: En este captulo se establecio la problematica, la justificacion,
los objetivos y los basamentos teoricos de la propuesta.
Captulo II: Incluye la propuesta y dise
no desarrollado, detallando cada una
de los procedimientos establecidos para el proceso a estandarizar.
Captulo III: Las conclusiones derivadas de este informe de investigacion.
Por u
ltimo, se presenta la referencias bibliograficas.

VIII

Captulo I
El Problema
1.1.

Planteamiento del Problema

En los inicios de la era de la informacion, con la informatica se facilitaron los


trabajos repetitivos y monotonos del area administrativa. La automatizacion de
esos procesos trajo como consecuencia directa una disminucion de los costos y un
incremento en la productividad. Cuando se habla de un proceso para el desarrollo de software, se refiere a una estructura aplicada al desarrollo de un producto.
Existen varias definiciones similares aceptadas para software, pero la mas formal
la define como: un conjunto de programas de computo, procedimientos, reglas,
documentacion y datos asociados, que forman parte de las operaciones de un sistema de computacion. Por tal motivo se identifica el desarrollo de software como
la manera de mejorar los procesos y productividad del negocio, mejorando la velocidad y aumentando la calidad de los sistemas, Pressman (2010).
El desarrollo de una solucion para una empresa comprende varias fases: la primera es la identificacion de las necesidades del negocio acorde a la estrategia del
mismo, la siguiente es la identificacion de las reglas de negocio y de las fuentes de
datos, la tercera es el desarrollo de la solucion que permitira satisfacer estas necesidades, y por u
ltimo, esta la implementacion de esta solucion en los ambientes
productivos de la empresa.
Cuando se trabaja en un ambiente local desarrollando software, todo esta bien,

Captulo I. El Problema
pero cuando se tiene que poner en produccion el desarrollo, se tienen equipos de
trabajo involucrados, m
ultiples servidores y diferentes ambientes se puede tornar
un poco complicado y propenso a errores1 . Se define un pase a produccion como la
accion de poner una nueva version de software a disposicion de los usuarios reales
del mismo.
Formulaci
on del Problema
Debido al problema anterior expuesto se ha planteado como proyecto de informe final proponer el desarrollo para la estandarizacion de los pases a produccion
de los desarrollos de software.

1.2.

Justificaci
on e Importancia

En los u
ltimos a
nos las herramientas tecnologicas se han convertido en parte
saliente de nuestra vida cotidiana, es por ello que se hace cada vez mas importante contar con herramientas que satisfagan las necesidades de las personas que las
usan. Un aspecto a considerar en el planeamiento de un pase a Produccion es la
designacion de responsabilidades y roles necesario dentro del pase, muchas veces
necesitaremos el soporte de un especialista en Infraestructura, por lo que planificar la presencia del mismo es algo muy importante para no tener inconvenientes
durante el pase.
Algo que muchas veces no se tiene en cuenta es la participacion del Cliente en
la planificacion de la Implementacion. Es necesaria la participacion del cliente en
este proceso, pues nosotros podemos planificar ciertos tiempos para la realizacion
del Pase a Produccion, sin embargo el Cliente puede tener ciertas polticas internas que nosotros no hemos considerado y que podran retrasar la Implementacion.
1

Un error de software, com


unmente conocido como bug (((bicho))), es un error o fallo en

un programa de computador o sistema de software que desencadena un resultado indeseado.


Los errores mas comunes en el desarrollo de software son errores de codigo en lenguajes de
programaci
on y defectos de instalacion o programacion.

Captulo I. El Problema

Es necesario, ademas, antes del pase a ambientes Productivos del cliente, realizar un pase a un Ambiente de Desarrollo o Testing, el cual debe ser lo mas parecido
al ambiente Productivo Final, con tal de prevenir posibles fallas u omisiones en
la planificacion del pase a produccion.
Si tenemos en cuenta las consideraciones antes mencionadas realizaremos un
Pase a Produccion sin contratiempos y, por consiguiente, una implementacion exitosa.

1.3.
1.3.1.

Objetivos de la Investigaci
on
Objetivo General

Establecer y definir una propuesta para estandarizar el proceso de pase a


produccion de los desarrollos de software.

1.3.2.

Objetivos Especificos

Reconocer la situacion actual de los procedimientos de pase en produccion


de los desarrollo de software, a fin de desarrollar un marco referencial para
el desarrollo del proceso.
Establecer los parametros tecnicos de las operaciones involucradas en el
proceso de desarrollo de software.
Dise
nar una propuesta metodologica del proyecto definitivo u operativo.

Captulo I. El Problema

1.4.
1.4.1.

Bases Te
oricas
Ingeniera de Software

De acuerdo con Sommerville (2005), la Ingeniera del Software es la rama de


la ingeniera que crea y mantiene las aplicaciones de software usando tecnologas
y practicas de las ciencias de la computacion, manejo de proyectos, ingeniera, el
ambito de la aplicacion, y otros campos. Seg
un la definicion del IEEE2 , software
es la suma total de los programas de ordenador, procedimientos, reglas, la don
cumentacion asociada y los datos que pertenecen a un sistema de computo u
producto de software es un producto dise
nado para un usuario. En este contexto,
la Ingeniera de Software (SE del ingles Software Engineering) es un enfoque
sistematico del desarrollo, operacion, mantenimiento y retiro del software.
2

1.4.2.

Desarrollo de Software

Un proceso de desarrollo de software tiene como proposito la produccion eficaz y eficiente de un producto software que re
una los requisitos del cliente, Royce
(1970). Dicho proceso, en terminos globales se muestra en la Figura 1.1. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a
cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie de
desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido.
Un producto software es intangible y por lo general muy abstracto, esto dificulta
la definicion del producto y sus requisitos, sobre todo ando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difciles de
consolidar tempranamente.
2

El Instituto de Ingeniera Electrica y Electronica, en ingles Institute of Electrical and Elec-

tronics Engineers, es una asociaci


on mundial de tecnicos e ingenieros dedicada a la estandarizaci
on y el desarrollo en
areas tecnicas. Es la mayor asociacion internacional sin animo de lucro
formada por profesionales de las nuevas tecnologas, como ingenieros electricos, ingenieros en
electr
onica, cientficos de la computacion, ingenieros en computacion, matematicos aplicados,
ingenieros en biomedicina, ingenieros en telecomunicacion, ingenieros en mecatronica, etc.

Captulo I. El Problema
El proceso de desarrollo de software no es u
nico. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo.
Debido a esta diversidad, es difcil automatizar todo un proceso de desarrollo de
software.

Figura 1.1: Proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto


de actividades fundamentales que se encuentran presentes en todos ellos:
Especificacion de software.
Dise
no e Implementacion.
Validacion.
Evolucion.

1.4.3.

Entorno de Desarrollo

Una buena practica com


un en equipos de desarrollo es asegurar que los desarrolladores poseen su propio entorno donde trabajar. Un entorno es un espacio
tecnico que posee un alcance bien definido y respetado. La principal ventaja de
los entornos es que ayudan a reducir los riesgos debido a errores tecnicos que
puedan afectar de forma adversa a un grupo de personas mayor al absolutamente
necesario.
El modelo de desarrollo, testing y produccion es esencial para proveer los
controles y el balance necesario para ejecutar un entorno de produccion de alta

Captulo I. El Problema
disponibilidad de forma eficiente, Granados (2014).

Figura 1.2: Diferentes entornos de Desarrollo.

1.4.4.

Soporte T
ecnico

El soporte tecnico es un rango de servicios que proporcionan asistencia con el


hardware o software, Julie (2005). En general, el servicio de soporte tecnico sirve para ayudar a resolver los problemas que puedan presentaseles a los usuarios,
mientras hacen uso de servicios, programas o dispositivos.

1.4.5.

Proceso

De acuerdo con Lopez (2008), un proceso puede ser definido como un conjunto
de actividades enlazadas entre s que, partiendo de uno o mas inputs (entradas)
los transforma, generando un output (resultado). Un proceso es un conjunto de
actividades encadenadas logicamente que toman un insumo y le agregan valor con
sentido especfico para un Cliente o Grupo de Interes, generando as un resultado
o servicio .

1.4.6.

Mejora Continua

1.4.7.

Project Management Body of Knowledge (PMBOK)

La Guia del PMBOK es un estandar en la Administracion de proyectos desarrollado por el Project Management Institute (PMI). El PMBOK es una coleccion
de procesos y areas de conocimiento generalmente aceptadas como las mejores
practicas dentro de la gestion de proyectos. Es un estandar reconocido internacionalmente (IEEE Std 1490-2003) que provee los fundamentos de la gestion de
6

Captulo I. El Problema
proyectos que son aplicables a un amplio rango de proyectos, incluyendo construccion, software, ingeniera, etc. El PMBOK documenta y estandariza la informacion
y practicas generalmente aceptadas en la gestion de proyectos, proporcionando referencias basicas a cualquiera que este interesado en la gestion de proyectos. Posee
un lexico comun y una estructura consistente para el campo de la gestion de proyectos.

1.4.8.

Business Process Modeling Notation (BPMN)

BPMN es una notacion grafica estandarizada que permite el modelado de


procesos de un negocio en particular, inicialmente fue desarrollada por BPMI
(Business Process Management Initiative), que sufrio una fusion con OMG (Object Management Group). El objetivo principal del BPMN es el de proveer una
notacion estandar que permita el modelamiento del negocio, de tal forma que los
procesos sean entendibles, de una forma facil y sencilla, por los involucrados e
interesados del negocio. El modelado en BPMN se realiza mediante diagramas
simples y con un conjunto peque
no de elementos graficos.

1.4.9.

Fundamentos de la Gesti
on de Servicios de IT: Basado en ITIL

La Biblioteca de Infraestructura de Tecnologas de Informacion, frecuentemente abreviada ITIL (del ingles Information Technology Infrastructure Library), es
un marco de trabajo de las buenas practicas destinadas a facilitar la entrega de
servicios de tecnologas de la informacion (TI).Desarrollada a finales de 1980, la
Biblioteca de Infraestructura de Tecnologas de la Informacion (ITIL) se ha convertido en el estandar mundial en la Gestion de Servicios Informaticos. ITIL fue
desarrollada al reconocer que las organizaciones dependen cada vez mas de la
Informatica para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informaticos
de calidad que se correspondan con los objetivos del negocio, y que satisfagan los
requisitos y las expectativas del cliente.

Captulo II
La Propuesta
2.1.

Dise
no de la Propuesta

2.2.

Alcance

Se aplica a todos los programas o sistemas que van a pasar a formar parte de
los procesos regulares de los usuarios en el ambiente de produccion. Debera ser
aplicada por el personal de sistemas (equipo de desarrolladores, equipo de soporte,
administradores de base de datos, jefes de soporte y computacion).

2.3.
2.3.1.

Condiciones
Condiciones B
asicas

Los Pases a Produccion son solicitados nacen como un nuevo requerimiento.


Los Pases solicitados (programas, tablas, bases de datos, etc), deberan estar
debidamente probados y aprobados por el equipo de ambiente QA. Solamente se pasaran a produccion las solicitudes firmadas y/o autorizadas.
Todo Pase a Produccion se tramitara por correo electronico, cualquier peticion que no se realice a traves de correo en los terminos establecidos en este
8

Captulo II. La Propuesta


documento no sera tenida en cuenta.
Ning
un Pase a Produccion ameritara detener un servidor o los servicios que
este servidor proporciona a los usuarios durante las horas regulares de servicio. La necesidad sera determinada u
nicamente por el Jefe de Produccion
y caso por caso.
Durante procesos crticos para las operaciones del negocio, solamente los Pases a Produccion referidos a estos procesos seran ejecutados como urgentes.
Se hara la identificacion pertinente llegado el momento.

2.3.2.

Condiciones Especificas

Se revisa previamente que la documentacion necesaria este completa. Si falta


alg
un documento o informacion, el Pase a Produccion no se ejecuta.
Se revisan previamente las modificaciones o actualizaciones propuestas. Si
hay alguna diferencia entre lo propuesto y lo real, el Pase a Produccion no
se ejecuta.
Si un Pase a Produccion falla se regresan los programas, aplicativos, sistemas, tablas o bases de datos afectados utilizando el respaldo realizado.
Los Pases a Produccion relacionados con programas son ejecutados por el

Area
de Soporte, los movimiento en general de tablas y/o bases de datos ,
en caso de ser necesario se solicitara apoyo del Administrador de Bases de
Datos (pero siempre debera estar informado no importa el caso).
En el campo ASUNTO del correo correspondiente se exigira el numero del
pase y el numero de Ticket.
El cuerpo del correo debera incluir lo siguiente:
El n
umero de requerimiento (numero de pase).
El tipo de requerimiento (tipo de pase).
El nombre del requerimiento.

Captulo II. La Propuesta


El tiempo estimado de ejecucion y el momento sugerido de ejecucion
en caso de ser urgente o necesario durante el mismo da.
La informacion necesaria para la ejecucion del proceso debera estar en
el campo observacion del Sistema de Pases Automaticos.
El horario de pases a Produccion es el siguiente y solamente podra ser modificado con la autorizacion expresa de la Direccion de Sistemas. Se aceptan
de Lunes a Viernes en cualquier horario y se ejecutan luego finalizada la
jornada laboral. Una vez asegurado el backup de la BBDD respectiva.
La excepciones al horario de ejecucion de pases a produccion deben ser
visadas por el Director de Sistemas.

2.4.

Prioridad

Se debe establecer una secuencia en la que un cambio debe implantarse, teniendo en cuenta la urgencia con que sera atendido. A continuacion se definen los
distintos tipos de prioridades, que aplican tanto para la solicitud como para la
aceptacion del mismo:
Baja: Se le da prioridad baja a los cambios que pueden esperar por su
implantacion, debido a que no esta dirigido a corregir alg
un problema. Se
define como un cambio justificado que puede esperar al siguiente calendario
de actualizacion (siguiente release).
Media: Se habla de prioridad media cuando los cambios son requeridos
para adicionar funcionalidades, o modificar contenidos, es decir no afectan
en gran manera el servicio, pero esto no implica que se puedan postergar.
Alta: El cambio tiene una prioridad alta, si busca evitar que se afecte severamente la disponibilidad del servicio, o cuando corresponde a una necesidad
imperiosa del negocio.
Urgencia: Se dice que el cambio es urgente, cuando se busca evitar o solucionar la perdida del servicio. Este tipo de cambios deben ser implementados
inmediatamente a fin de corregir un problema que afecte seriamente la disponibilidad de un servicio crtico.
10

Captulo II. La Propuesta

2.5.
2.5.1.

Actores o Roles
Jefe de Implementaci
on

Es el encargado de evaluar y asignar tareas a equipo de analistas a su cargo


para el optimo cumplimiento de objetivos. Su principal rol es Coordinar proceso
de implementacion con las partes involucradas.

2.5.2.

Equipo Implementador de Soporte

Es el encargado para instalar, poner en funcionamiento, operar, dar soporte


a usuarios, realizar el diagnostico y el mantenimiento. Posee las competencias
profesionales y los conocimientos complementarios para un optimo desempe
no
profesional en la ocupacion.

2.5.3.

Administrador de base de datos (DBA)

Un administrador de bases de datos (tambien conocido como DBA, en ingles


database administrator) es aquel profesional que administra las tecnologas de
la informacion y la comunicacion, siendo responsable de los aspectos tecnicos,
tecnologicos, cientficos, inteligencia de negocios y legales de bases de datos. Entre
sus diversas tareas incluye implementar, dar soporte y gestionar bases de datos,
ademas de ser responsables de la integridad de los datos y la disponibilidad, entre
otras, Connolly (2008).

2.5.4.

Analista de Pruebas

Este rol identifica y define las pruebas necesarias, supervisa el proceso de


prueba necesario y los resultados de cada ciclo de prueba y eval
ua la calidad
global. El rol tambien representa a los interesados que no tienen una representacion
directa o regular en el proyecto. El analista de pruebas es encargado de realizar
las pruebas y determinar sus resultados, ademas de identificar la ideas de pruebas.
Por otro lado es responsable de dicha lista de ideas de pruebas y de velar por los
resultados de las pruebas, Kalpakjian (2002).

11

Captulo II. La Propuesta

2.6.

Descripci
on del Procedimiento

1. El jefe de implementacion solicita aprobacion al gerente general de IT para


realizar pase a produccion del desarrollo o actualizacion de software por
parte del equipo de computacion.
2. Se eval
ua la solicitud de pase a produccion por parte del gerente general o
comite de implementacion.
3. El ente encargado aprueba o niega la solicitud de pase a produccion.
4. Si la solicitud de pase es aprobada por parte del ente encargado, se sigue
a preparar el ambiente de produccion, esta tarea estara dirigida y sera responsable del jefe de implementacion.
5. El jefe de implementacion debera constar en un documento los recursos
responsables para la instalacion y configuracion del pase a produccion.
6. Una vez establecidos los recursos que participaran en el pase a produccion
se debera presentar la programacion de pase y a los recursos involucrados
que llevaran a cabo el mismo, el jefe de implementacion generara dicha
programacion en un documento como soporte.
7. El equipo establecido establecido estara dividido en 3 roles responsables
soporte, DBA y testing.
8. El equipo de soporte y DBA deberan validar y certificar la ficha de componentes, en la cual estara detallado los cambios a realizar en el pase a
produccion de desarrollo o actualizacion.
9. De ser positivo la certificacion de componentes, haciendo uso del manual de
instalacion y configuracion los responsables de soporte instalaran he implementaran el cambio en produccion. El DBA responsable correra los scripts
y configura la base de datos del proyecto si es el caso.
10. Los encargados verificaran que la instalacion y configuracion haya sido exitosa.

12

Captulo II. La Propuesta


11. Si la instalacion fue exitosa se procedera a que el analista realiza las pruebas
Post produccion necesarias que garanticen el correcto funcionamiento del
sistema.
12. Si las pruebas son exitosas el jefe de implementacion debera generar el informe de pruebas post pase a produccion, dando as por terminado el proceso
de pase.

13

Captulo II. La Propuesta


Diagrama de Flujo

Figura 2.1: Diagrama de Flujo de Pases a Produccion.


14

Captulo II. La Propuesta

2.7.

Riesgos del Proyecto

No contar con una lnea base respecto del proceso de gestion de puesta en
produccion.
No contar con uno de los integrantes del Equipo de Proyecto.
No configurar y/o certificar adecuadamente los ambientes,desarrollos o cambios en el tiempo requerido.
Poca disponibilidad de los involucrados en los procesos a modelar e implementar no brindando el apoyo y aporte requerido.
La falta de un estandar respecto a los tipos de tecnologas que se usan, pues
en produccion sera complicado contar con suficientes recursos de Hardware
para soportarlas.

2.8.

Indicativos y Estadsticas

Como resultado de aplicar este proceso podemos obtener diferentes ndices


estadsticos de la gestion de pases a produccion, dichos indicadores se presentan
a continuacion:
Tipos de cambio por
area: Determina el numero de los diferentes tipos
de cambio por area: cuantos se presentaron por solicitud del negocio (nuevo
desarrollo o modificacion), debido a un problema, debido a cambios de terceros (consecuencias de otros cambios) o cuales corresponden a una mejora
detectada internamente.
Cambios urgentes: Cantidad de cambios que no pasaron aprobacion en
reunion de cambio (por area).
Cumplimiento del tiempo planeado: Numero de cambios que cumplieron con los tiempos programados clasificados por area y prioridad.
Cantidad de cambios reversados: Numero de cambios que no lograron
entregase en produccion y fue necesario volver a la version original por area
y prioridad.
15

Captulo II. La Propuesta

2.9.

Beneficios

Reducci
on de Riesgo: El control y Administracion de un cambio minimiza
el riesgo de resultados inesperados debido a la introduccion de un cambio al
ambiente de produccion.
Reducci
on de Costos: Mantener los registros de los cambios contribuye a
la mejora continua de los procesos operacionales en el ambiente de produccion, y agiliza la resolucion de los problemas relacionados con los cambios.
Mejora de la agilidad en el servicio: Los procedimientos estructurados
en la implementacion de los cambios le permiten a las organizaciones alinearse rapida y efectivamente a los cambiantes requerimientos del negocio.
Mejora en la Calidad de los servicios: Una apropiada evaluacion de
impacto de los cambios previene cadas del servicio no planeadas, en consecuencia se incrementa la calidad de los servicios.

2.10.

Documentos y planes de gesti


on asociados
al proceso de Puesta en Producci
on

2.10.1.

Documento de aceptaci
on del cliente o cierre de
contrato

Este proyecto indica que, para una adecuada puesta en produccion de todas las
aplicaciones que se desarrollan, estas tienen que pasar por un proceso que permita
realizarles un seguimiento en el tiempo y se verifique su calidad de modo que se
satisfagan todas las expectativas del usuario final.
Este proceso supone una interaccion continua con los Gerentes de las empresas
y el Jefe de Proyecto de la aplicacion. Por ello se crea el documento de aceptacion
del cliente para dejar sentada y registrada la impresion de los Jefes de Proyecto
sobre el servicio recibido.Esta informacion es muy importante para poder seguir
planteando nuevas actividades que mejoren la gestion de la puesta en produccion
16

Captulo II. La Propuesta


de las aplicaciones.
Se entiende como cierre del contrato al documento que plasma la conformidad
del servicio recibido por los Jefes de Proyecto para poner en produccion la aplicacion que han desarrollado. Para evitar la repeticion de documentos y contenido
se considera como evidencia suficiente de cierre el Documento de aceptacion del
cliente en el cual ademas de indicar que el servicio de Puesta en produccion
ha concluido, ya que se entrega solo si la aplicacion se encuentra en produccion,
permite tambien registrar observaciones o sugerencias que ayudan a mejorar el
proceso.

2.10.2.

Documento de Gesti
on de Incidentes

La Gestion de Incidentes tiene como objetivo resolver cualquier incidente que


cause una interrupcion en el servicio de la manera mas rapida y eficaz posible. La
Gestion de Incidentes no debe confundirse con la Gestion de Problemas, pues a
diferencia de esta u
ltima, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio.
Sin embargo, es obvio, que existe una fuerte interrelacion entre ambas.
En este documento detallaremos los incidentes ocurridos durante el desarrollo
del proyecto de Gestion de Puesta en Produccion, se identificaran los problemas
y riesgos y cuales fueron las soluciones t manejos planteadas y ejecutados para
restaurar los servicios.

17

Captulo III
Conclusiones
La propuesta de estandarizacion presentada en este informe cumple con los
objetivos planteados, ya que ofrece una estructura organizada y segura para la
gestion de puesta en produccion de los desarrollos de software. Esto se logro mediante la implementacion de buenas practicas derivadas del estudio y aplicacion de
las diferentes bases teoricas consultadas. Como resultados se obtuvo una serie de
pasos funcionales a realizar para aplicar el proceso de gestion satisfactoriamente.
Las conclusiones derivadas son:
La implementacion de un proceso estructurado y definido para la Gestion de
la Puesta en Produccion es vital para lograr entregar un producto software
de calidad.
La definicion e implementacion de procesos para la Puesta en Produccion
aporta valor a las empresas al permitir que estas trabajen la entrega de
aplicaciones en un marco de trabajo estandarizado.
La definicion del proceso de la Gestion de Puesta en Produccion debe involucrar la opinion y aceptacion de todos los involucrados en esta para poder
lograr un mejor resultado.
Una de las dificultades que se pueden encontrar durante el proceso de puesta
en produccion es la implantar una cultura de desarrollo y reglas para el
proceso que anteriormente se llevaba a cabo de manera desordenada y sin
seguir ning
un tipo de reglas bien definidas.
18

Referencias Bibliogr
aficas
Granados L. (2014). Desarrollo de aplicaciones web en el entorno servidor.
MIC Editorial, Disponible en: https://books.google.co.ve/books?id=
OO91CQAAQBAJ&lpg=PT208&dq=entornos%20de%20desarrollo&pg=PP1#v=
onepage&q&f=false
Julie E (2005). Analisis y dise
no de sistemas. Pearson Educacion.
Kalpakjian, S (2002). Manufactura, ingeniera y tecnologa. Pearson Educacion,
Disponible en: https://books.google.co.ve/books?id=gilYI9 KKAoC
Lopez P. (2008). Procesos: Ingenieria de Procesos, su perfil y proyeccion Universidad EAFIT, Medellin.
Pressman R. (2005). Software Engineering: A Practitioners Approach McGrawHill Education, (7 ed), the University of California.
Royce W. (1970). Managing the developmento of large software systems: concepts
and technique, IEEE Westcon.
Sommerville I. (2005). Ingeniera del Software. Pearson Educacion, (7 ed), S.A,
Madrid.
Connolly T. (2008). Business Database Systems. Addison-Wesley, Disponible en:
https://books.google.es/books?id=-b2769W15RQC

Ap
endice A
BPMN

20