Revocada por la resolucion



Descargar 2.5 Mb.
Página9/35
Fecha de conversión24.05.2018
Tamaño2.5 Mb.
1   ...   5   6   7   8   9   10   11   12   ...   35

9. SALIDAS

Reportes que genera el aplicativo modificado.



10. REGISTROS

Si se inicia el procedimiento con base en una solicitud presentada por el usuario que requiere el mantenimiento, se relaciona la solicitud en el libro general de correspondencia en donde se registra el número de oficio de la solicitud, la fecha de la solicitud, el funcionario encargado de realizar la tarea, el oficio de respuesta y la correspondiente fecha. De igual manera, se debe crear un registro de modificaciones en donde deben aparecer: la dependencia usuaria de la aplicación, el módulo que se va a modificar, la fecha de la solicitud o de conocimiento del requerimiento, fecha de inicio del cronograma de actividades y fecha final del mismo.


11. BASES DE AUTOCONTROL

Verificación de la necesidad planteada para establecer si el mantenimiento debe realizarse

Establecer si se trata de una norma que lo está estableciendo para asignarle mayor prioridad

Verificación de la aceptación por parte del usuario

Verificación de que los cambios hechos en el sistema son los que debieron hacerse

Verificación de resultados luego de ponerse en producción la aplicación modificada.

Capacitación final a los usuarios

Actualización Manuales Técnicos y de usuarios


12. ANEXOS

No aplica.


13. ACTIVIDADES

DEPENDENCIA QUE LO SOLICITA

13.1 Conocimiento de la necesidad de modificación de programas: Se efectúa bien sea por intermedio de una solicitud escrita o verbal del usuario que requiere la modificación del software o por entrada en vigencia de una norma que regula cambios que se deben realizar.

JEFE OFICINA DE SISTEMAS

13.2 Reparto del caso a un funcionario de la Oficina de Sistemas, de acuerdo con la complejidad del asunto se le entrega a un funcionario teniendo como criterio su conocimiento del tema y la experiencia que tenga en su desempeño.

PROFESIONAL OFICINA DE SISTEMAS

13.3 Estudio de la modificación de software: El funcionario encargado efectúa un estudio previo del estado en que se encuentra el aplicativo, emite un concepto de la complejidad de la modificación y sus implicaciones técnicas, elabora un cronograma de actividades que refleja de qué manera se va a llevar a cabo la modificación en el tiempo e informa al jefe de la Oficina de Sistemas los pormenores de la solución planteada.

SECRETARIA OFICINA DE SISTEMAS

13.4 Informe al usuario: Dependiendo de la complejidad de la modificación es posible que con este informe se dé por atendido el requerimiento en cuyo caso se dará como archivado el asunto. De lo contrario, se debe informar a los usuarios en las dependencias involucradas la manera como la Oficina de Sistemas hace los respectivos cambios en el software y lo libera para ser usado.

PROFESIONAL OFICINA DE SISTEMAS

13.5 Modificación del aplicativo: El funcionario encargado de las modificaciones, teniendo como base el cronograma, ejecuta las tareas programadas en el equipo de desarrollo dejando evidencia del estado anterior en el cual se encontraban los programas y estructuras de tablas y usando datos de prueba que deben ser solicitados al área de producción. Finalmente, realizará las actualizaciones de los manuales respectivos.

GRUPO DE PRUEBAS

13.6 Pruebas del aplicativo: En ambiente de desarrollo y con presencia del usuario que hará uso del programa modificado, y de un representante de la Oficina de Control Interno, se deben realizar pruebas de consistencia del software que deben dar como resultado la aceptación de las modificaciones y que el comportamiento del programa es el esperado. Si existe alguna objeción por parte del usuario o de la Oficina de Control Interno, se deberá dejar constancia y el funcionario encargado de la modificación deberá volver al paso anterior; de lo contrario, se dará por aceptado el nuevo programa.

COORDINADOR AREA DE DESARROLLO Y ADMINISTRADOR DEL SISTEMA

13.7 Paso del programa a producción: Una vez probado el programa en ambiente de desarrollo y realizadas las pruebas respectivas, deberá llenarse un formato de solicitud de paso del programa al ambiente de producción que será diligenciado por parte del funcionario encargado de la modificación con el visto bueno del Jefe de la Oficina de Sistemas. El paso se llevará a cabo de acuerdo con el procedimiento establecido para tal efecto.

SECRETARIA OFICINA DE SISTEMAS

13.8 Informe final al usuario: Una vez se haya puesto el programa modificado en ambiente de producción, se informará a las dependencias que hacen uso de él y se dará por archivado el caso.
14. INDICADORES

Número de modificaciones presentadas en un período de tiempo por módulo (nMP).

Número de modificaciones presentadas y atendidas en un período de tiempo por módulo (nMA).

Tiempo promedio de duración en días de una modificación: está dado por la sumatoria de la duración en días de cada una de las modificaciones en un período de tiempo (nd) sobre el número de modificaciones atendidas (nMA).


DEPENDENCIA: Oficina de Sistemas

PROCESO: Mantenimiento de sistemas de información

PROCEDIMIENTO: Mantenimiento de sistemas Contratados

CODIGO: OS-MS-009

REVISO: Jefe de Oficina

APROBO: Carlos Arturo Gómez Pavajeau

FECHA: 2 de Marzo 2001


1. OBJETIVO

Mantener actualizados los aplicativos contratados mediante la modalidad de outsourcing con base en las necesidades planteadas por la Procuraduría General de la Nación, frente a los cambios que se presentan bien sea de normatividad o de procedimiento.



2. CLIENTES

Las dependencias que los utilizan y los ciudadanos que se relacionan con los procesos que atienden clientes externos.


3. ALCANCE

El procedimiento se aplica a todos los programas contratados por la entidad e involucra a cada una de las dependencias que interactúan con el sistema.


4. RESPONSABILIDADES

El procedimiento involucra a la dependencia que solicitó el mantenimiento, a todos los usuarios que usan el aplicativo y a los usuarios externos que solicitan información relacionada con el sistema o que hacen parte a través de él bien sea en calidad de solicitante, signatario, implicado, autoridades administrativas, etc.


5. REFERENCIAS

Leyes que reglamentan el proceso, resoluciones del señor Procurador General de la Nación y normas que le sean aplicables.


6. DEFINICIONES

No aplica.


7. FORMATOS A UTILIZAR

Modelo de Solicitud de Mantenimiento

Modelo de acta de aceptación del usuario

Modelo de paso de programas a producción


8. CONDICIONES GENERALES

La modificación por parte del contratista puede hacerse en sus propias instalaciones o en las instalaciones de la Oficina de Sistemas, cuando dentro del desarrollo del sistema se les ha ubicado en un lugar con condiciones específicas, pero en todo caso debe adelantarse la modificación del software en un equipo de desarrollo y sin ningún acceso a los datos ni a los programas que está usando el usuario en ese momento.

Cuando dentro del contrato, el contratista debe entregar los programas fuentes, éste deberá dejar constancia del estado en que se encontraban los programas y las estructuras, antes de la modificación y en estos casos deberá adelantarse la correspondiente modificación en los equipos dentro de las instalaciones de la Oficina de Sistemas.
9. SALIDAS

Reportes generados por la aplicación modificada.

Reporte de modificaciones que debe contener el nombre del programa, la ubicación física, fecha de modificación, descripción de la modificación, tablas o estructuras modificadas y nombre de quien efectuó esta tarea.
10. REGISTROS

Si se inicia el procedimiento con base en una solicitud presentada por el usuario que requiere el mantenimiento, se relaciona la solicitud en el libro general de correspondencia en donde se registra el número de oficio de la solicitud, la fecha de la solicitud, el funcionario encargado de realizar la tarea, el oficio de respuesta y la correspondiente fecha. De igual manera, se debe crear un registro de modificaciones a sistemas contratados, en donde deben aparecer: la dependencia usuaria de la aplicación, el módulo que se va a modificar, la fecha de la solicitud o de conocimiento del requerimiento, fecha de inicio del cronograma de actividades y fecha final del mismo.


11. BASES DE AUTOCONTROL

Verificación de la necesidad

Determinar con el contrato si el mantenimiento debe hacerlo el contratista

Verificar el resultado que arroja el sistema después de efectuada la modificación

El contratista nunca debe tener acceso al área del producción del sistema

Capacitación al usuario

Actualización de los manuales respectivos

Recibido a satisfacción por parte del usuario


12. ANEXOS

No aplica.


13. ACTIVIDADES

DEPENDENCIA QUE LO SOLICITA

13.1. Conocimiento de la necesidad de modificación de programas: Se efectúa bien sea conocido por intermedio de una solicitud escrita o verbal del usuario que requiere la modificación del software o por entrada en vigencia de una norma que regula cambios que se deben realizar.

JEFE OFICINA DE SISTEMAS

13.2. Reparto del caso a un funcionario de la Oficina de Sistemas: De acuerdo con la complejidad del asunto, se le entrega a un funcionario teniendo como criterio su conocimiento del tema y la experiencia que tenga en su desempeño. Debe existir por lo menos dos (2) personas en la Oficina de Sistemas que conozcan la funcionalidad de cada una de las áreas (administrativa y funcional) y de los sistemas que facilitan el desarrollo de cada una de sus actividades. Estas personas son las encargadas de la interacción entre la Procuraduría y el contratista, bajo la coordinación del Jefe de la Oficina de Sistemas.

PROFESIONAL OFICINA DE SISTEMAS

13.3. Estudio de la modificación de software: El funcionario encargado efectúa un estudio previo del estado en que se encuentra el aplicativo, determinando de esta manera si la modificación requerida se encuentra enmarcada dentro del contrato de diseño del sistema. De lo contrario, ésta debe ser ejecutada por personal técnico de la Oficina de Sistemas y debe seguir los pasos descritos en el procedimiento de modificaciones de software desarrollado internamente. Si debe ser ejecutada por la firma contratista, se debe dar traslado del requerimiento a ésta.

CONTRATISTA DEL SISTEMA

13.4. Respuesta del contratista: En un término no mayor a diez (10) días calendario, el contratista deberá informar las implicaciones técnicas de la modificación y entregar el respectivo cronograma de actividades.

SECRETARIA OFICINA DE SISTEMAS

13.5. Informe al usuario: Dependiendo de la complejidad de la modificación, es posible que con este informe se dé por atendido el requerimiento en cuyo caso se dará como archivado el asunto. De lo contrario, se debe informar a los usuarios en las dependencias involucradas de acuerdo a la respuesta dada por el contratista.

CONTRATISTA DEL SISTEMA

13.6. Modificación del aplicativo: El contratista, teniendo como base el cronograma, ejecuta las tareas programadas en las instalaciones de la Oficina de Sistemas, si éste tiene asignado un sitio para tal fin, o en sus instalaciones.

GRUPO DE PRUEBAS

13.7. Pruebas del aplicativo: En ambiente de desarrollo y con la presencia del usuario que hará uso del programa modificado, y de un representante de la Oficina de Control Interno, se deben realizar pruebas de consistencia del software que deben dar como resultado la aceptación de que las modificaciones fueron las deseadas y que el comportamiento del programa es el esperado. Si existe alguna objeción por parte del usuario o de la Oficina de Control Interno, se deberá dejar constancia y el contratista deberá volver al paso anterior; de lo contrario, se dará por aceptado el nuevo programa.

CONTRATISTA Y ADMINISTRADOR DEL SISTEMA

13.8. Paso del programa a producción: Una vez probado el programa en ambiente de desarrollo y realizadas las pruebas respectivas, deberá llenarse un formato de solicitud de paso del programa al ambiente de producción que será diligenciado por parte del contratista con el visto bueno del Jefe de la Oficina de Sistemas. El paso se llevará a cabo de acuerdo con el procedimiento establecido para tal efecto.

SECRETARIA OFICINA DE SISTEMAS

13.9. Informe final al usuario: Una vez se haya puesto el programa modificado en ambiente de producción, se informará a las dependencias que hacen uso de él y se dará por archivado el caso.
14. INDICADORES

Número de modificaciones presentadas en un período de tiempo por módulo (nMP).

Número de modificaciones presentadas y atendidas en un período de tiempo por módulo (nMA).

Tiempo promedio de duración en días de una modificación: está dado por la sumatoria de la duración en días de cada una de las modificaciones en un período de tiempo (nd) sobre el número de modificaciones atendidas (nMA)


DEPENDENCI: Oficina de Sistemas

PROCESO: Desarrollo de sistemas de información

PROCEDIMIENTO: Estudio de soluciones en el mercado

CODIGO: OS-010

REVISO: Jefe de Oficina

APROBO: Carlos Arturo Gómez Pavajeau

FECHA: 2 de Marzo 2001


1. OBJETIVO

Apoyar la toma de decisiones frente a la necesidad de adquirir un nuevo sistema de información.


2. CLIENTES

Las dependencias que hayan planteado el requerimiento o aquellas que hayan sido definidas como clientes destinatarios del sistema dentro del Plan de Desarrollo Informático de la entidad.


3. ALCANCE

El procedimiento se aplica a las empresas que puedan ofrecer la solución que está buscando la entidad, así como a las dependencias que involucra el nuevo sistema.


4. RESPONSABILIDADES

El procedimiento involucra a las empresas que estén en condiciones de ofrecer el producto para satisfacer el requerimiento, la Junta de Licitaciones y al Comité evaluador.


5. REFERENCIAS

Leyes que reglamentan el proceso de contratación (Ley 80/93), resoluciones del señor Procurador General de la Nación y normas que le sean aplicables.



6. DEFINICIONES

No aplica.


7. FORMATOS A UTILIZAR

Modelo de solicitud de requerimiento

Modelo de autorización de estudio de mercado

Modelo de cuadro de evaluación


8. CONDICIONES GENERALES

Si de antemano se conoce que el sistema que está requiriendo la entidad es de características muy particulares y con una alta probabilidad de que no existe en el mercado algo que pueda satisfacer tales necesidades, el estudio se puede orientar hacia la verificación de situaciones similares en entidades que tengan alguna coincidencia en cuanto a la funcionalidad de la Procuraduría General de la Nación como por ejemplo los demás organismos de control.

Tratándose de Sistemas que sean la razón de ser de la entidad y que manejen áreas críticas se debe tener especial cuidado en la observación de otras experiencias para no caer en los mismos errores en que normalmente incurre la administración pública. De ser posible, se puede buscar en el país o fuera del mismo para encontrar la mejor solución y la mejor firma que pueda ofrecer resultados óptimos, en condiciones económicas favorables y en el menor tiempo posible.
9. SALIDAS

Documento del estudio de mercado

Concepto que permite tomar la decisión final
10. REGISTROS

Registro de la solicitud en el libro de correspondencia si ésta surge de un planteamiento expreso de alguna dependencia.


11. BASES DE AUTOCONTROL

Verificación del requerimiento dentro del Plan de Desarrollo Informático

Verificación de que no se esté adelantando otro estudio sobre el mismo caso o se esté desarrollando o acondicionando un sistema ya existente en la entidad

Verificación de referencias a las firmas a las cuales se les adelante el estudio


12. ANEXOS

No aplica.


13. ACTIVIDADES

OFICINA DE SISTEMAS O DEPENDENCIA SOLICITANTE

13.1. Conocimiento del requerimiento: Es posible que se conozca por solicitud de alguna dependencia que esté interesada, pero lo ideal es que surja en forma proactiva del Plan de Desarrollo Informático, pues de esta manera se pueden canalizar los esfuerzos de la entidad por modernizarla en lo que respecta a tecnología informática.

ASESOR OFICINA DE SISTEMAS

13.2. Análisis del requerimiento: En esta etapa se analiza si el requerimiento obedece a una necesidad sustancial o si hace parte de algún proyecto en ejecución o que va a desarrollarse en el futuro. Si hace parte de un sistema ya planteado, se informa al usuario sobre el avance del mismo y el momento en que se suplirá su necesidad, en este caso se dará por archivado el caso. De no ser así, se estudia su viabilidad dentro del Plan de Desarrollo Informático de la entidad.

PROFESIONAL OFICINA DE SISTEMAS

13.3. Establecimiento de los términos de referencia: Se deben establecer los términos técnicos del producto, los requerimientos técnicos de hardware, número de licencias y qué población de la entidad beneficia.

GRUPO INTERDISCIPLINARIO

13.4. Investigación en el mercado: Mediante esta etapa se establece si existe en el mercado un producto que satisfaga las necesidades y se dimensionan los oferentes, la capacidad del software, las condiciones comerciales y económicas. De no existir por lo menos una empresa que solucione el requerimiento o que esté dispuesta a hacer los ajustes para ponerlo en funcionamiento, este proyecto debe ser evaluado en términos del desarrollo de un nuevo sistema de información, bien por la contratación externa o el desarrollo interno, y seguirá los pasos del procedimiento descrito para estos casos. Si esto ocurre, se dará por archivado el estudio que servirá como base para el procedimiento para el cual se envíe (contratación o desarrollo interno).

GRUPO INTERDISCIPLINARIO

13.5. Solicitud de cotizaciones: Con base en los términos técnicos se solicitan tres (3) cotizaciones a empresas diferentes con el fin de establecer un marco de referencia desde el punto de vista económico y de facilidades del producto.

PROFESIONAL OFICINA DE SISTEMAS

13.6. Análisis técnico del producto: Con base en la metodología de calificación de productos de software, se establecerá la calificación del producto y si fuese necesario, se efectuarán visitas a las compañías o se solicitará una demostración con presencia del usuario que requiere la solución. De esta etapa debe dar como resultado el concepto técnico de cuál es la oferta que más se ajusta a las necesidades de la Procuraduría General de la Nación y se deberá dejar constancia de ello.

SECRETARIA OFICINA DE SISTEMAS

13.7. Envío del concepto técnico a la Secretaría General: Finalmente, se enviará el respec-tivo concepto técnico a la Secretaría General para que se solicite el certificado de disponibilidad presupuestal y se continúe con el proceso de adquisición del producto. En el momento de la adquisición ingresa por alguno de los procedimientos de atención de servicios informáticos.
14. INDICADORES

Número de requerimientos de nuevos sistemas (nRP) presentados.

Número de requerimientos de nuevos sistemas atendidos en un período de tiempo (nRA).

Indicador de efectividad en el período: Está dado por nRA/nRP.

Número de requerimientos de nuevos sistemas (nRPM) presentados y que fueron contratados en el mercado.

Número de requerimientos de nuevos sistemas (nRPE) presentados y que fueron no contratados en el mercado. Está dado por nRPnRPE

DEPENDENCIA: Oficina de Sistemas

PROCESO: Desarrollo de Sistemas de información

PROCEDIMIENTO: Contratación del desarrollo de sistemas de información

CODIGO: OS-DS-011

REVISO: Jefe de Oficina

APROBO: Carlos Arturo Gómez Pavajeau

FECHA: 2 de Marzo 2001


1. OBJETIVO

Seleccionar en forma objetiva y transparente el contratista y garantizar que el desarrollo contratado cumpla con los requerimientos establecidos para el sistema de información.


2. CLIENTES

Las dependencias que requieren el nuevo Sistema, la Oficina de Control Interno, la Oficina de Sistemas, Oficina Jurídica, la Secretaría General y los proponentes.


3. ALCANCE

El procedimiento se aplica a todas las empresas que presenten propuestas para la adquisición del Sistema de Información, y es válido para el Comité de Desarrollo Tecnológico de la entidad (es una propuesta) que estará integrado de la siguiente manera:

El Procurador General de la Nación o su delegado, quien lo presidirá.

La Secretaría General

El Jefe de la Oficina de Planeación.

El Jefe de la Oficina de Sistemas actuará como secretario del Comité, con voz pero sin voto.

También es aplicable este procedimiento a la Oficina de Sistemas, la Oficina de Control Interno y todas las dependencias que participen en dicho proceso.
4. RESPONSABILIDADES

El procedimiento involucra a las empresas proponentes, al Comité de Desarrollo Tecnológico y la Junta de Licitaciones.


5. REFERENCIAS

Leyes que reglamentan el proceso de contratación (Ley 80/93), resoluciones del señor Procurador General de la Nación y normas que le sean aplicables.


6. DEFINICIONES

No aplica.



7. FORMATOS A UTILIZAR

Modelo de solicitud de nuevo Sistema de Información

Metodología de desarrollo de Sistemas de Información

Modelo de términos de referencia

Modelo de evaluación de propuestas

Metodología para el desarrollo de proyectos de sistemas de información e ingeniería de software



8. CONDICIONES GENERALES

El procedimiento debe hacer parte de la documentación que se entrega al contratista y debe quedar expresamente escrito en el contrato que su cumplimiento es obligatorio.

El control de la validez del sistema debe ser la principal preocupación del grupo de gerencia del contrato y esto debe iniciar desde cuando se establecen los requerimientos para evitar a toda costa hacer un mal dimensionamiento del sistema y evite pérdidas de dinero a la entidad y en general a la administración pública.

Como los proyectos informáticos tienen un alto grado de riesgo, este punto debe ser tratado con suma importancia por la entidad y por cada uno de los participantes en el proyecto.

Bajo ninguna circunstancia se pueden aceptar estudios previos de parte de personal interno o externo que orienten hacia determinada solución que siempre tienen un sesgo implícito hacia algún proponente. Si esto se llegare a detectar, el funcionario que considere o que conozca esta situación deberá informar a las directivas para que adopten las medidas del caso y se denuncie disciplinariamente a quien intenta inducir a la entidad a tomar una mala decisión.
9. SALIDAS

Documento en cada fase del desarrollo

Documento final de requerimientos

Documento de Términos de Referencia

Actas de inicio y de terminación

Interfases del Sistema de Información

Reportes del Sistema

Manual de Instalación del Sistema

Manual Técnico del Sistema

Manual del usuario


10. REGISTROS

Registro de la solicitud en el libro de correspondencia si ésta surge de un planteamiento expreso de alguna dependencia, Certificado de Disponibilidad Presupuestal.



11. BASES DE AUTOCONTROL

Concepto del documento de análisis de requerimientos por un experto en el tema

Concepto del documento de términos de referencia por parte de un experto en el tema

Concepto jurídico del contrato por parte de un experto

Concepto de la Oficina de Control Interno sobre el sistema

Seguimiento a la ejecución del contrato

Satisfacción o rechazo del usuario

Productividad de la entidad con el nuevo sistema

Opinión pública



Compartir con tus amigos:
1   ...   5   6   7   8   9   10   11   12   ...   35


La base de datos está protegida por derechos de autor ©composi.info 2017
enviar mensaje

    Página principal