Estándares para el análisis, diseño, codificación, pruebas

06-SDA-P06-I01/Rev.00
Instructivo de Diseño y Desarrollo de
Software
06-SDA-P06-I01/Rev.00
Introducción
El presente documento contiene las líneas generales para organizar la
oficina de proyectos y un área de mejora de procesos.
Contiene también líneas generales para mantener los procesos optimizados.
06-SDA-P06-I01/Rev.00
Oficina de Proyectos
Administración de Proyectos
Consideraciones generales.
La Dirección de Gobierno Digital, de la Subsecretaría de Desarrollo
Administrativo y Tecnológico del Gobierno del Estado de Sonora tiene la
responsabilidad de concentrar los proyectos de esta Subsecretaría y
seleccionar a los proveedores de desarrollo (en caso de ser necesario). Por
tal motivo, la administración de los proyectos consiste en seguir los planes
de trabajo, así como recibir y verificar los productos entregados.
Por tal motivo la orientación de la oficina de proyectos será la de mantener
y controlar la información de todos los proyectos que tenga a su cargo.
Tablero de Control.
El tablero debe indicar la dependencia, proyecto, responsable interno,
responsable proveedor y el estado del proyecto.
El estado del proyecto se debe obtener a partir de los planes de trabajo y
los entregables.
El tablero debe indicar los entregables aceptados y los que están
pendientes.
Comunicación.
Una de las principales tareas de la oficina de proyectos es la de mantener
un flujo continuo con los responsables que cuenten con proyectos en
ejecución.
Para mantener la comunicación eficientemente, con los responsables de los
proyectos es necesario establecer un modo de comunicarse estándar y
06-SDA-P06-I01/Rev.00
eficiente, este puede ser correo electrónico, teléfono, fax, etc. Lo
importante es establecer el medio adecuado a cada necesidad (Ver sección
de Políticas de este documento).
Recepción de Entregables.
Es muy importante definir los procesos y establecer las actividades
necesarias para la recepción de los entregables del proyecto.
Siempre debe haber un responsable de la recepción y un procedimiento
acordado con el proveedor, la Dependencia o Entidad.
Las líneas generales de recepción son las siguientes:

Tener acordado cuál o cuáles serán los entregables a recibir.

Tener definido por escrito los criterios de aceptación. Normalmente
se documentan por cada entregable en forma de lista de
verificación.

Se establece un tiempo para la aceptación del entregable. En ese
período se debe valida los entregables.

En la fecha de aceptación se le entrega al proveedor o Dependencia
una carta de aceptación o de no conformidad.

En caso de no conformidad, deben especificarse los motivos por lo
que el entregable no fue aceptado.
Una vez que un entregable fue aceptado, el proveedor, la Dependencia o la
Entidad, se liberan de la responsabilidad y toda modificación o ajuste será
visto como un cambio.
06-SDA-P06-I01/Rev.00
Levantamiento de Requerimientos.
El levantamiento inicial de requerimientos de negocio es responsabilidad de
la Dirección de Gobierno Digital. Por lo que en este caso la administración
de los proyectos es más específica.
Todos los levantamientos deben tener un responsable, un plan de
entrevistas acordado con el cliente y un entregable definido.
Se debe realizar un plan de trabajo a partir del plan de entrevistas y la
carga de trabajo del responsable del levantamiento.
Debe existir un procedimiento definido para realizar el levantamiento y
formatos estándar de documentación.
La aceptación de los levantamientos debe ser realizada por el Responsable
de la Dependencia o Entidad y por el Director de Gobierno Digital.
Revisión.
Para llevar a cabo la revisión del análisis,
diseño realizados por el
Ingeniero de Proyectos o Ingeniero de Proyectos Web, el Jefe de la Oficina
de Proyectos aplica a dichos documentos el checklist “Revisión de Análisis y
Diseño”. Una vez que se ha realizado esta revisión se documentan los
hallazgos y observaciones para llevar a cabo las acciones correctivas por
parte del responsable del análisis, diseño.
Verificación.
Para llevar a cabo la verificación, es conveniente que el Jefe de la Oficina
de Proyectos aplique las pruebas de verificación.
06-SDA-P06-I01/Rev.00
Las pruebas de verificación (también conocidas como pruebas de calidad)
pueden incluir:





Probar los equipos bajo condiciones que simulen las de operación
real.
Probar los programas para asegurar que se siguen los estándares
apropiados y que desempeñan las funciones esperadas.
Asegurar que la documentación sea la adecuada y esté completa.
Verificar que los sistemas sean capaces de operar bajo condiciones
normales, pero también bajo potenciales condiciones inesperadas.
Asegurar que se cuente con las debidas medidas de seguridad y que
estas se ciñan a las normas establecidas.
Los resultados de la verificación, deben quedar evidenciados en el Formato
“Resultado de la Verificación del Análisis, Diseño y Desarrollo”. De existir
alguna observación, el verificador deberá documentarla en este formato.
Validación.
Una vez realizadas las revisiones y verificaciones pertinentes, se efectúan
la validación del análisis, diseño en conjunto con el enlace responsable de
la dependencia. Los resultados quedan asentados en el Formato “Validación
de Resultados”.
Control de Cambios.
Es indispensable tener un Formato para la “Solicitud de Cambios”, que el
proveedor pueda aceptar formalmente e incluir en el plan de trabajo.
Los cambios son uno de los principales factores que hacen fallar un
proyecto. Son responsabilidad de quien lo solicita y de quien lo acepta.
Sin embargo sea cual sea el número de cambios, la oficina siempre debe
tener control de ellos. Un solo canal para recibirlos de las Dependencias o
Entidades y un solo medio para hacerlo llegar al Proveedor.
Por cada cambio aceptado por el proveedor se debe tener la fecha en la
que se realizará y el impacto que tendrá en todo el proyecto.
06-SDA-P06-I01/Rev.00
Mejora Continua
Documentación de Procesos.
Todas las actividades de levantamiento de requerimientos deben estar
documentadas.
La documentación de los procesos debe hacerse en formatos estándar y
deben estar puestos en algún sitio accesible a todos los involucrados en el
área.
Los procesos documentados deben coincidir con las actividades que se
realizan en la práctica.
Métricas.
Las métricas ayudan a conocer el desempeño del proceso.
Se deben elegir las métricas más adecuadas y un procedimiento para
recolectarlas y analizarlas.
A continuación se listan algunos ejemplos de métricas:



Tiempo en el levantamiento de requerimientos de negocio.
Número de cambios en los proyectos.
Número de proyectos abiertos.
Los responsables de los levantamientos y de la oficina de proyectos son
también los responsables de la recolección de las métricas.
Mejora de Procesos.
A partir de los resultados de las métricas y de los comentarios de las
Dependencias y los proveedores, la oficina de proyectos debe ir
actualizando los procesos.
06-SDA-P06-I01/Rev.00
Políticas.
Levantamientos.

Al momento de notificarse de un nuevo levantamiento, la oficina de
proyectos es la responsable de verificar la ocupación de sus recursos
para dar una fecha exacta en la cual se iniciaría con dicho
levantamiento. Las notificaciones se harán mediante oficios que
lleguen a la Subsecretaría de Desarrollo Administrativo y
Tecnológico, Dirección de Gobierno Digital de parte de la
Dependencia que lo solicita ó bien a través de una instrucción
directa por parte del Subsecretario de Desarrollo Administrativo y
Tecnológico en caso de ser proyectos de la Subsecretaria.

La oficina de proyectos debe asignar para cada levantamiento, un
responsable directo para la correcta ejecución en tiempo y forma.

La forma de generación de la clave del levantamiento será de la
siguiente manera: indicar que se trata de un levantamiento
anteponiendo las siglas LE, abreviar las siglas de la dependencia o
entidad en un mínimo de 3 y máximo de 5 letras, indicar el número
consecutivo para esa dependencia; mismo que deberá inicializarse al
comenzar un nuevo año. Poner la fecha de inicio del levantamiento.
Ejemplo de una clave: LE-SDAT-01/29-FEB-2012.

Cada encargado de un levantamiento debe generar un plan de
trabajo el cual debe mantener actualizado.

Los cambios en los planes de trabajo (cancelaciones de citas) deben
ser colocados en el Formato para el Control de Incidencias.

Los encargados directos de un levantamiento deben reportar a la
oficina de proyectos todas las incidencias que afecten
negativamente el desempeño del proyecto y proyectos relacionados.

Es responsabilidad del encargado de un levantamiento, recolectar y
registrar las métricas establecidas. La fecha de inicio, fecha de fin,
el número de entrevistas, problemas, oportunidades o metas y el
número de casos de uso.
06-SDA-P06-I01/Rev.00

Para dar por finalizado un levantamiento es necesario obtener un
oficio de aceptación del interesado, aprobando el resultado del
trabajo realizado.

Los defectos encontrados en la revisión de la Dependencia o Entidad,
deben ser corregidos y revisados en un lapso máximo de 7 días
hábiles, para su entrega final.

Al dar por finalizado un levantamiento la oficina de proyectos debe
liberar los recursos para asignaciones posteriores.
Proyectos en ejecución.

Es responsabilidad de la oficina de proyectos mantener y controlar la
información de todos los proyectos que se encuentren a su cargo,
con el fin de garantizar la correcta ejecución de los mismos.

Es responsabilidad de las Dependencias y proveedores del Gobierno
entregar un plan de trabajo y un reporte de avance periódico de los
proyectos que se encuentren a su cargo. El reporte de avance debe
incluir el nombre del proyecto, el nombre del administrador del
proyecto, las tareas que se han cumplido, hallazgos que no
corresponden al plan de trabajo, las tareas que se debieron haber
realizado y no se llevaron a cabo y las tareas por realizar en el
siguiente período (avance)

Es responsabilidad de la oficina de proyectos, establecer un plan de
comunicación para cada proyecto que se encuentre en ejecución
manteniendo
un
flujo
continuo
de
información.
El Plan de comunicación debe especificar los reportes de avance (por
medio de correo), la forma de entrega de los productos de software
(papel, correo, etc.), el aviso de los ajustes al plan (retrasos) y la
aceptación o no conformidad (corrección).

Las dependencias y proveedores deben reportar a la oficina de
proyectos todas las incidencias que afecten negativamente el
desempeño del proyecto y proyectos relacionados.

Es responsabilidad de la oficina de proyectos contar con un
administrador de proyectos que funja como la contraparte del
administrador responsable del desarrollo del sistema que puede ser
la dependencia o cuando se asigne a un proveedor. El administrador
06-SDA-P06-I01/Rev.00
de proyectos debe ser designado por la oficina de proyectos y este
puede pertenecer al departamento de sistemas de la dependencia o
al equipo de sistemas de la Dirección de Gobierno Digital.

Es responsabilidad de los administradores de proyectos de la oficina
de proyectos aceptar o rechazar los productos de software. En caso
de ser rechazados se emitirá un documento de no conformidad
indicando en la misma las razones por las que el producto no fue
aceptado. En caso de ser aceptado, se emite uno de aceptación.
Estándares.

Todas las actividades del departamento son planeadas y
documentadas. Planear los entregables, levantamientos, actualizar
tablero de control.

Los productos resultantes de un levantamiento, deben ser la base
para la generación de una licitación o convocatoria del producto o
servicio.
06-SDA-P06-I01/Rev.00
Mejora Continua
Políticas.

Las políticas de la Dirección de Gobierno Digital deberán ser
revisadas por lo menos una vez al año para su mejora continua.

Se deben reportar y documentar de forma periódica y puntual, todo
hallazgo encontrado durante la ejecución de un proyecto para su
corrección. El hallazgo indica que nos faltó o en qué estamos
fallando para analizarlo y modificar el proceso.

El personal que detecte y documente un hallazgo de no conformidad,
es el responsable directo de darle seguimiento hasta su finalización.

Se deben analizar las métricas recolectadas, con el fin de optimizar
el proceso de levantamiento de requerimientos y seguimientos de
proyectos.
06-SDA-P06-I01/Rev.00
Elaboración de Manuales de Usuario
Para la elaboración de un manual de usuario se deberán de
integrar los siguientes puntos.
1) Nombre del Sistema: Nombre del sistema al que se refiere el manual.
2) Versión del Sistema: La versión del sistema en el manual nos permitirá
mantener un control sobre las modificaciones que han afectado al sistema
original.
3) Tipo de manual: Se especifica el tipo de manual al que se hace
referencia, ya que este nos permitirá tener un control en nuestros
manuales además de una fácil identificación.
4) Poner una Imagen: Es recomendable ilustrar el Manual con una imagen
representativa del sistema (opcional).
5) Fecha de elaboración: Es importante el incluir la fecha de elaboración,
ya que representa un punto de referencia y control.
6) Nombre y puesto de la persona que lo elaboró: Incluir el nombre y
puesto de la persona que realizo el manual.
7) Índice del contenido del manual: Deberá contar con un índice y/o
contenido del manual para facilitar su manejo e identificación de los
puntos importantes, ya que normalmente solo se busca un punto en
específico y con el índice es fácil identificarlo.
7.1. Presentación o Introducción: Breve descripción general del
manual.
7.2. Generalidades del Sistema:
I. Descripción del producto: Describe las secciones que
integran el sistema, la seguridad y sus alcances.
II. Botones Generales usados en el Sistema: Mostrar con
imágenes todos los botones explicando su funcionamiento
dentro del sistema.
III. Ayudas del Sistemas: Describir las diferentes formas en las
que se puede tener ayuda al momento de estar trabajando
dentro del sistema (opcional).
7.3 Entrada y salida del sistema.
06-SDA-P06-I01/Rev.00
I. Entrada al sistema: Explicar detalladamente las pantallas
principales que aparecen al momento de entrar, se
recomienda ilustrar con imágenes las ventanas para un mejor
entendimiento, lo cual puede ser:
I.I. Por medio de un ICONO, que representa el acceso
directo al sistema (opcional).
I.II Explicando al usuario la ruta en la que se encuentra
el archivo ejecutable (en caso que aplique).
II. Salida del sistema: En esta sección se explicara la forma de
cómo salir del sistema, describiendo detalladamente las
pantallas principales que aparecen al momento de salir, se
recomienda ilustrar con imágenes las ventanas para un mejor
entendimiento.
7.4 Uso de la Aplicación:
I. Ventana o Pantalla: Hacer uso de imágenes o capturas de
pantalla, para describir el uso y funcionamiento de cada uno
de los elementos que conforman cada programa del modulo.
7.5 Glosario de términos:
En esta sección se incluirá una lista con el significado de los
términos, conceptos o tecnicismos, usados en este manual y que no
son del dominio público (opcional).
7.7. Anexos: Este punto se utilizará en caso de ser necesario.
7.8 Encabezado y Pie de Página:
Información representativa en cada una de las hojas de nuestro
manual, ya que pueden incluir datos importantes como el nombre de
dicho manual, el número de la versión, fecha de modificación y el
número de página, entre otros, esto permitirá al usuario entre otras
cosas la rápida navegación e identificación de temas (opcional).
06-SDA-P06-I01/Rev.00