Metodología para el Desarrollo de Aplicaciones o Sistemas

Universidad Técnica Nacional Dirección de Gestión de Tecnologías de Información

Metodología para el Desarrollo de Aplicaciones o Sistemas

Capítulo 3. Implementación de Tecnologías de Información. Norma 3.2 implementación de Software

Versión 1.0 agosto 2015

Universidad Técnica Nacional Rectoría Dirección de Gestión de Tecnologías de Información

Tabla de contenidos

1. Justificación 2. Introducción 3. Actualización 4. Aprobación 5. Alcance 6. Historial de Actualización 7. Etapas para el Desarrollo de Aplicaciones

7.1 Investigación preliminar 7.2 Determinación de los requerimientos del sistema o aplicación

Determinación de objetivos y alcance Levantamiento de requerimientos funcionales Descripción básica del proceso Flujograma de procesos Documentos generados en la etapa de determinación de requerimientos

7.3 Diseño del sistema o aplicación 7.4 Desarrollo

Solicitar la creación de un repositorio de control de versiones Integración Creación de las estructuras de base de datos Programación de los formularios o pantallas Pruebas de la funcionalidad del sistema o aplicación Manuales de usuario y configuración Documentos generados en la etapa de desarrollo Implantación Instalación Entrega Capacitación Preparar datos a migrar Documentos generados en la etapa de implantación

7.5 Control de cambios Evaluación de satisfacción Seguridad Corrección de errores por competencia Elementos de referencia

Entradas en las bitácoras del Repositorio de Control de Versiones 8. Glosario 9. Sitios web para consulta 10. Representación gráfica de la metodología

Interrelación entre las etapas de desarrollo de la metodología

Página 2 de 37


Esquema de interrelación entre los UsuariosAplicación 11. Anexos

Anexo: Lista de comprobación de documentos a archivar Anexo: Determinación de objetivos y alcance Anexo: Levantamiento de requerimientos funcionales Anexo: Descripción básica del proceso Anexo: Solicitud de Modificaciones

Solicitud de Modificaciones. Nombre del módulo:_______________________________

1. Justificación Teniendo en cuenta el acuerdo 192014 de la Sesión Ordinaria No. 01 del Consejo

Universitario, celebrada el jueves 30 de enero del 2014, Acta No. 022014, que reza:

“Aprobar la solicitud planteada por la Rectoría y la Dirección General

Administrativa, así como por el Consejo de Decanos, y en consecuencia, declarar

como aspecto prioritario para el desarrollo de la Universidad, el desarrollo, la

adquisición y el mejoramiento de los sistemas de información y las bases de datos

que permitan brindar un servicio eficaz y eficiente a nuestros usuarios, y que

además facilite el proceso de toma de decisiones a nivel gerencial. Para el

cumplimiento de lo anterior se brindará el apoyo necesario en personal

especializado, infraestructura y presupuesto a la Dirección de Informática de la

Universidad Técnica Nacional, conforme al Plan Estratégico de Desarrollo

Informático, y la Hoja de Ruta que formule esa Dirección”.

Así como la sección 3.2 Implementación de software del Informe de Normas Técnicas en

Tecnologías de Información y Comunicaciones de la Contraloría General de la República, que dice:

“La organización debe implementar el software que satisfaga los requerimientos de

sus usuarios y soporte efectivamente sus procesos…”

Página 3 de 37


También lo mencionado en el Objetivo Estratégico Institucional correspondiente al Plan

Institucional de Desarrollo Estratégico 20112021 y una de las líneas de acción asignadas al mismo:

Establecer un sistema integrado de información y comunicación que garantice el

acceso oportuno, transparente y confiable a los datos institucionales. Línea de

acción: Desarrollar los sistemas o módulos informáticos necesarios para la

adecuada comunicación institucional.

Además de lo mencionado en los informes de Prioridad Universitaria:

Diseñar y aprobar la metodología del desarrollo de sistemas informáticos integrados,

necesarios para la adecuada gestión de la información institucional.

Se confecciona el siguiente documento: “Metodología para el Desarrollo de Aplicaciones o

Sistemas”, cuyo fin es normar los procesos involucrados en el desarrollo de aplicaciones o sistemas

en la Universidad Técnica Nacional.

Una Metodología de Desarrollo es un documento que explica los pasos generales que se

deben tener en cuenta a la hora de desarrollar aplicaciones o sistemas así como cualquier otro

elemento que se deba tener en consideración en el proceso de desarrollo.

2. Introducción Este documento reúne los procesos involucrados en el diseño, creación e implantación de

aplicaciones y sistemas de información para la Universidad Técnica Nacional (UTN).

La UTN cuenta con su servidor LAMP que alberga los sistemas informáticos universitarios

desarrollados por la Unidad de Sistemas de la Dirección de Gestión de Tecnologías de la

Información.

Página 4 de 37


Para el diseño, desarrollo e implantación de sistemas o aplicaciones en la UTN se utilizará la

metodología de Ciclo de Vida del Desarrollo de Sistemas, que permite el desarrollo rápido y ha sido

probada y utilizada en muchas ocasiones con éxito.

El método del ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que

los analistas, diseñadores y usuarios realizan para desarrollar e implantar sistemas de información.

Las etapas identificadas para el desarrollo de aplicaciones o sistemas en la UTN son las

siguientes:

1. Investigación preliminar. Se inicia con la solicitud de un nuevo sistema o aplicación. 2. Determinación de los requerimientos del sistema o aplicación. Identifica los

requerimientos del sistema o aplicación.

3. Diseño del sistema o aplicación. Se determinan los recursos necesarios para llevar a cabo

el sistema o aplicación, se establecen los rasgos definitivos del proyecto.

4. Desarrollo. Crea el sistema o aplicación y todo lo relacionado con el mismo. 5. Implantación. Puesta en marcha del sistema o aplicación. 6. Control de cambios. Corrección errores y desarrollo de nuevas funcionalidades para el

sistema o aplicación.

Se debe hacer uso de una lista de comprobación que contenga los elementos que se deben

archivar en físico. Ver Anexo: Lista de comprobación de documentos a archivar como ejemplo.

En la sección de Anexos se proponen formatos para la confección de la documentación

necesaria.

Es responsabilidad del Ingeniero de la aplicación o sistema, en adelante, el “Programador”,

recopilar y archivar la documentación generada durante todo el proceso de desarrollo del mismo, una

vez terminados los trabajos, el Programador deberá trasladar dicha documentación a la Jefatura de

Gestión Técnica de TI quién será la encargada de almacenar los documentos.

Para toda reunión que se lleve a cabo y esté relacionada con el desarrollo de algún sistema o

aplicación, el Programador deberá levantar una minuta y archivarla junto con el resto de la

documentación generada.

Página 5 de 37


Es responsabilidad del jefe inmediato de la Unidad de Sistemas de la Dirección de Gestión de

TI, velar porque esta metodología se encuentre actualizada con los nuevos requerimientos en la

forma de desarrollar sistemas en la UTN.

Será responsabilidad del ente superior de la Dirección de Gestión de TI, el indicar por medio

de una directriz, los lenguajes de programación, ambientes de desarrollo, marcos de trabajo,

modalidades y, si se considera necesario, los estándares de desarrollo de fuentes externas que se

utilizarán para el desarrollo de todo sistema o aplicación de la Universidad.

3. Actualización

La Metodología para el Desarrollo de Aplicaciones o Sistemas está a cargo de la unidad de Sistemas

correspondiente al área de Gestión Técnica.

4. Aprobación

El Metodología para el Desarrollo de Aplicaciones o Sistemas de la Universidad Técnica

Nacional debe ser aprobada por la Comisión de Institucional de Gestión Informática.

La presente versión se aprobó por la Comisión Institucional de Gestión Informática según el Acta No. 082015 de la sesión efectuada el día 05 de agosto 2015. ACUERDO 02082015

Para las actualizaciones de las diferentes versiones deberá ser aprobada por la Comisión

Institucional de Gestión Informática.

5. Alcance

El alcance de la Metodología para el Desarrollo de Aplicaciones o Sistemas abarca los

desarrollos en producción que se produzcan para la UTN.

Página 6 de 37


6. Historial de Actualización Versión Fecha Cambio Realizado Responsable

0.0A 01/05/2015 Propuesta de metodología David Villalobos C.

0.0A 03/06/2015 Revisión del área de Gestión Técnica

Luis Diego Fenández G. Carlomagno Gonzalez V. Luis F. Albertazzi R.

0.0A 17/07/2015 Revisión de la DGTI Jairo Bonilla Castro

0.0A 05/08/2015 Presentación de la Metodología a la CIGI

Luis Diego Fernández G.

1.0 00/00/2015 Aprobación de la metodología CIGI

7. Etapas para el Desarrollo de Aplicaciones

Página 7 de 37


7.1 Investigación preliminar

El proceso de desarrollo siempre inicia con la solicitud de un sistema de información.

Cuando se formule una solicitud, comienza la primera actividad en el desarrollo de sistemas o

aplicaciones que es la investigación preliminar y consta de tres fases:

● Aclaración de la solicitud.

● Estudio de factibilidad.

● Aprobación de la solicitud.

Aclaración de la solicitud:

Es común que las solicitudes provengan de personas que no están familiarizadas con el

desarrollo de sistemas por lo que no estén formuladas de manera clara. Por lo tanto, antes de

considerar el inicio de cualquier desarrollo de sistemas o aplicaciones, la solicitud debe examinarse

para determinar con precisión lo que el solicitante realmente está pidiendo.

Estudio de factibilidad Para la etapa de investigación preliminar, existen tres aspectos a considerar en cuanto al

estudio de factibilidad.

● Factibilidad técnica: debe responderse a la pregunta ¿puede realizarse con el equipo actual,

la tecnología de software existente y el personal disponible?. En el caso de necesitar nueva

tecnología, ¿cuál es la posibilidad de desarrollarla?

● Factibilidad económica: es necesario cuestionarse ¿los beneficios que se obtendrán serán

suficientes para justificar y aceptar los costos?, y si ¿los costos asociados a la decisión de no

desarrollar el sistema o aplicación son tan grandes que se debe aceptar el proyecto?

● Factibilidad operacional: una vez finalizado el desarrollo e implantado el sistema o

aplicación, ¿será utilizado?, ¿existirá resistencia al cambio por parte de los usuarios que dé

como resultado una disminución de los posibles beneficios?

Aprobación de la solicitud

Página 8 de 37


Es necesario reconocer que no todos los proyectos solicitados son deseables o factibles,

aquellos proyectos que sí lo son, deben ser incorporados en los planes de desarrollo de TI,

específicamente en el Plan Táctico de Tecnología de Información y Comunicación. Los desarrollos

se realizarán de acuerdo a su inclusión en el cronograma de actividades y la priorización y cambio de

la misma deberá ser aprobada por la CIGI.

7.2 Determinación de los requerimientos del sistema o aplicación

En la primera etapa de desarrollo, se debe tener en cuenta que los sistemas desarrollados

para la UTN tienen características especiales que los hacen diferentes a los sistemas tradicionales,

como por ejemplo: están integrados, utilizan un marco de desarrollo común, entre otras. En todo

momento el Programador es el responsable de velar por que se cumpla con lo indicado en este

documento.

Si para el desarrollo se designa un equipo de trabajo, el jefe inmediato de la Unidad de

Sistemas deberá nombrar a un miembro del equipo como encargado del desarrollo del sistema o

aplicación.

La etapa de análisis, es la etapa de investigación de los requerimientos funcionales así como

la determinación de los objetivos y alcances del sistema o aplicación a desarrollar, en todo momento

se debe tener en cuenta que el desarrollo debe cumplir con las necesidades y características de la

herramienta de desarrollo que la Dirección de Gestión de Tecnologías Informáticas indique.

Las fases de esta etapa son:

● Determinación de objetivos y alcance

● Levantamiento de requerimientos funcionales

● Descripción básica del proceso

● Flujograma de procesos

Determinación de objetivos y alcance

Por medio de esta fase, el Programador en conjunto con el usuario responsable, en adelante,

el “Responsable”, confecciona un documento con los elementos administrativos del sistema o

Página 9 de 37


aplicación, estos elementos son importantes porque ayudan a demarcar el camino a seguir durante el

proceso de análisis y desarrollo.

El Responsable deberá también asignar a uno o varios subalternos o, en su defecto, fungir el

rol de usuario experto quién será el encargado de brindar los insumos, información y explicar en

detalle los procesos y procedimientos necesarios para el correcto análisis, desarrollo y funcionalidad

del sistema o aplicación.

El documento debe de ser elaborado por el Programador y debe contestar a las siguientes

preguntas, además de las que él crea necesarias:

● ¿Para qué se necesita desarrollar el sistema o aplicación?

● ¿Cuál es el nombre del sistema o aplicación?

● ¿Quién es el Responsable del sistema o aplicación?

● ¿Quién o quiénes serán los usuarios expertos?

● ¿Qué objetivos se pretenden alcanzar con el sistema o aplicación?

● ¿Cuál es el alcance del proyecto?

● ¿Qué resultados se esperan obtener?

Levantamiento de requerimientos funcionales

Por medio de esta fase, el Programador determina las necesidades del nuevo sistema o

aplicación, lo hace aplicando un cuestionario a los usuarios finales. En la medida de lo posible, se

recomienda que el formulario sea completado por el usuario final y no por el Programador.

El cuestionario debe de ser elaborado y aplicado por el Programador y puede contener las

siguientes preguntas, además de las que él considere necesarias:

● ¿Qué información necesita almacenar?

● ¿Quién o quiénes deben ingresar esta información?

● ¿Qué información se necesita obtener?

● ¿Qué listados necesita generar?

● ¿Qué usuarios y roles tendrán permisos y accesos en el sistema o aplicación?

● ¿Existen datos que sea necesario migrar al nuevo sistema o aplicación?

Página 10 de 37


● ¿Cómo se debe procesar la información almacenada?

● ¿Cuál es el flujo de la información necesaria para el correcto funcionamiento del proceso?

● Comentarios.

● Además de cualquier otra que el Programador considere necesaria.

Es obligación del usuario experto, entregar la documentación que respalde el requerimiento

(cálculos, reportes, ejemplos) por escrito.

Una vez confeccionados los documentos sobre los requerimientos funcionales, el

Programador deberá de concertar una reunión con el Responsable y el usuario experto y les

presentará los documentos confeccionados. El Responsable deberá revisar y de firmar los

documentos haciendo constar que son claros y completos si así lo considere.

Descripción básica del proceso

En esta fase, el Programador confecciona una descripción básica del proceso a automatizar

por medio del sistema o aplicación y elabora un documento que resume la información brindada por

los usuarios finales.

El documento debe tener las siguientes características:

● Nombre del proceso.

● Responsable.

● Descripción del proceso.

● Finalidad del proceso.

● La información o datos que utiliza el proceso.

● ¿Quiénes proveen insumos al proceso?

● ¿Quiénes son los clientes del proceso?

● ¿Cómo inicia el proceso?

● ¿Cómo finaliza el proceso?

● Procesos relacionados.

● Actividades o subprocesos relacionados.

● Estimación del tiempo en horas que tomará desarrollar el requerimiento.

Página 11 de 37


Flujograma de procesos

En la fase de creación del flujograma se utilizan los siguientes elementos:

● Inicio / Final: se utiliza para demarcar el inicio y final del proceso. ● Entrada / Salida: se utiliza para denotar que hay un proceso de entrada o salida de datos. ● Conector: interconecta los elementos del flujograma y denota la dirección del flujo. ● Procesos: se utiliza para denotar la ejecución de un proceso.

En la Tabla 1 se muestra una descripción de las figuras que serán usadas:

Nombre Símbolo Descripción

Inicio / Final

Se utiliza para demarcar el inicio y final del proceso.

Entrada / Salida

Se utiliza para denotar que hay un proceso de

entrada o salida de datos.

Conector Interconecta los elementos del flujograma y denota

la dirección del flujo.

Proceso

Se utiliza para denotar la ejecución de un proceso.

Tabla 1. Figuras del flujograma de procesos.

Página 12 de 37


Documentos generados en la etapa de determinación de requerimientos

● Documentos de la determinación de objetivos y alcance. Ver anexo.

● Documentos del levantamiento de requerimientos funcionales. Ver anexo.

● Descripción básica del proceso. Ver anexo.

● Ejemplos de los listados que el sistema o aplicación debe generar.

● Flujograma de los procesos.

7.3 Diseño del sistema o aplicación

En esta etapa se producen los detalles que establecen la manera en la que el sistema o

aplicación cumplirá con los requerimientos solicitados e identificados durante la etapa de

determinación de requerimientos. Muchos se refieren a ésta como la etapa del diseño lógico en

contraste con la del desarrollo a la que se le denomina como diseño físico.

El Programador comienza el proceso de diseño identificando los reportes y demás salidas que debe

generar el sistema o aplicación, una vez hecho esto, se determinan con precisión los datos

específicos para cada reporte y salida.

Además, durante la etapa de diseño, también se debe indicar los datos de entrada, aquellos que

serán calculados y los que deberán almacenarse en la base de datos. Se describen también de

forma detallada los procedimientos de cálculos y los datos individuales.

7.4 Desarrollo

La Universidad cuenta con un módulo que consolida muchas de las tareas más comunes en

el desarrollo de otros módulos, sistemas o aplicaciones como, por ejemplo: generación de listados,

ejecución de consultas en la base de datos, envío de correos, monitoreo de errores, entre otras, es

por eso que el nuevo sistema o aplicación a desarrollar debe tener como dependencia el módulo UTN

(ver documentación aquí) y hacer uso de las funciones que sean requeridas. En circunstancias

Página 13 de 37

http://subversion.utn.ac.cr/UTN


normales, por ejemplo, el nuevo sistema o aplicación no puede implementar su propia lógica de

conexión a base de datos, debe hacer uso de la función que provea el módulo UTN para tal fin.

A continuación se analizan las fases que tiene esta etapa:

● Solicitar la creación de un repositorio de control de versiones

● Integración

● Creación de las estructuras de base de datos

● Programación de los formularios o pantallas

● Pruebas de la funcionalidad del sistema o aplicación

● Manuales de usuario y configuración

Durante todas las fases del desarrollo, se deben versionar los archivos generados.

Solicitar la creación de un repositorio de control de versiones

El primer paso en la creación de un sistema o aplicación es solicitar al encargado de

infraestructura que cree un repositorio nuevo en el servidor de control de versiones, esto con el fin de

que todos los archivos generados durante el desarrollo se puedan respaldar y llevar un control sobre

los cambios realizados en los mismos.

El encargado de infraestructura deberá proveer al Programador el nombre del repositorio

creado, así como las credenciales de acceso tanto para el Programador como para el equipo de

desarrolladores involucrados.

Integración

En todo momento se deben tener en cuenta los sistemas y aplicaciones desarrollados

previamente para evitar duplicar funciones, tareas o procesos. Esto con el fin de lograr que los

sistemas y aplicaciones Universitarios estén integrados y compartan la información necesaria.

En el caso que la integración tenga que hacerse con sistemas desarrollados por terceros,

dicha integración debe ser coordinada con el Administrador de Bases de Datos (DBA) ya que la

misma debe ser llevada a cabo por medio de la base de datos.

Página 14 de 37


Creación de las estructuras de base de datos

El tercer paso en el desarrollo del sistema o aplicación, es crear el Diagrama

EntidadRelación que represente a las tablas y las relaciones entre ellas, así como su cardinalidad. El

mismo debe ser creado en un archivo digital y en formato vectorial.

El Programador debe seguir las recomendaciones y estándares indicados por el

Administrador de Base de Datos adicionalmente, debe brindarle la información e insumos necesarios

para la creación de vistas y rutinas que cumplan la lógica que utilizará el sistema o aplicación para su

correcta funcionalidad.

Se debe tener en cuenta que lo que se requiere es que la lógica del sistema o aplicación sea

desarrollada por el motor de base de datos, tal como lo propone ModeloVistaControlador (MVC),

por lo que toda lógica del negocio debe ser implementada en el motor de base de datos por medio de

funciones y procedimientos. El DBA será el encargado de aprobar e implantar las funciones y

procedimientos almacenados creados por el Programador.

Cuando sea necesario, el Programador solicitará al DBA que realice una copia de los datos

almacenados en el servidor de producción (o parte de ellos) para que sean almacenados en la base

de datos de desarrollo y/o pruebas, esto con el propósito de poder realizar pruebas durante el

proceso de desarrollo.

Programación de los formularios o pantallas

Los formularios se encargan de realizar la interacción entre el usuario y los elementos de

base de datos creados (procedimientos, tablas, funciones).

Cada uno de los formularios deberá contar con una ayuda contextual para el usuario, en el

mismo se explicarán los elementos principales del uso y funcionalidades del formulario.

Página 15 de 37


Para mantener un estándar de programación, a continuación se describirá una serie de reglas

que se deben seguir para asignar nombres de variables y elementos de los formularios o pantallas

que permitan identificarlas fácilmente:

Los nombre de variables deben ser escritas en su totalidad con letras minúsculas y se

compondrán de la siguiente manera: gbl (únicamente si la variable es declarada de tipo global) o prv (únicamente si la variable es declarada de tipo privada), tipo de dato que contiene la variable (“int”

para entero, “lng” para entero largo, “bool” para datos booleanos, “ds” para dataset, “str” para

cadenas de texto, “dec” para decimal, “ary” para arreglos, “dte” para datos tipo fecha/hora, “db”

objetos de bases de datos, “row” contiene arreglo de filas de una consulta de SQL, etc.), un nombre

indicativo y significativo que identifique el dato que contenga la variable (si el nombre contiene más

de una palabra, se utilizará como separador el carácter raya baja [“_”]). Por ejemplo:

decsalario_empleado (variable normal), gblstrapellido_empleado (variable global).

Los nombres de funciones deberán ser escritos en su totalidad con letras minúsculas y tener

un nombre indicativo y significativo del proceso que realiza la función, en caso que el nombre

contenga más de una palabra, se utilizará como separador el carácter raya baja (“_”) . Por ejemplo:

cargar_provincias()

Los elementos de los formularios o pantallas deberán ser escritos en su totalidad con letras

minúsculas y se compondrán de la siguiente manera: tipo de componente del formulario o pantalla

(“frm” formulario, “txt” caja de texto, “cbo” combo, “lbl” etiqueta, “dtp” componente calendario, “rdb”

botón radio, “btn” botón, “chk” botón de selección, “mnu” opción de menú, “tbl” tabla, etc.), el carácter

raya baja (“_”), un nombre indicativo y significativo que identifique el uso del elemento en el formulario

o pantalla (si el nombre contiene más de una palabra, se utilizará como separador el carácter raya

baja [“_”]). Por ejemplo: chk_estudiante_trabaja, txt_nombre_estudiante

Pruebas de la funcionalidad del sistema o aplicación

En esta fase se realizan las pruebas y verificaciones necesarias para poder comprobar la

funcionalidad del sistema o aplicación, estas pruebas deben ser realizadas en el ambiente de

pruebas, así como en un ambiente de producción simulado, de esta manera se garantiza que no

habrá conflictos con los sistemas o aplicaciones ya desarrolladas.

Página 16 de 37


Las pruebas consisten en utilizar de manera experimental el sistema o aplicación realizando

una simulación del funcionamiento de una situación real con datos de pruebas para su procesamiento

y posterior revisión de resultados para asegurarse que el sistema o aplicación no tenga fallas y que

funciona de acuerdo con las especificaciones y en la forma que los usuarios esperan que lo haga.

Cuando así sea requerido, el Programador podrá solicitar al Responsable la aceptación formal

por escrito de uno o varios requerimientos, esto con el fin de garantizar el correcto desempeño del

proceso del desarrollo, para esto, el Programador le indicará al Responsable cómo debe proceder

para realizar las pruebas necesarias para la aceptación.

Se puede hacer la recomendación que en esta fase, varios usuarios utilicen el sistema para

que el Programador observe si tratan de emplearlo de formas no previstas.

Manuales de usuario y configuración

Es responsabilidad del Programador confeccionar el manual de usuario, en el que se explique

en detalle el uso y funcionalidad de cada parte del sistema o aplicación, así como el manual de

configuración que será utilizado por los administradores para realizar las configuraciones necesarias.

Documentos generados en la etapa de desarrollo

● Solicitud y respuesta de la creación del repositorio de control de versiones.

● Adjunta el documento con el diccionario de datos de las estructuras de base de datos creadas

por el DBA.

● Diagrama EntidadRelación de las tablas de la base de datos.

● Documento que compruebe las pruebas realizadas. Pueden ser los listados generados en la

fase de pruebas.

● Manuales de usuario y de configuración.

● Oficio de aceptación por parte del usuario Responsable.

Página 17 de 37


Implantación

Esta es la última etapa, y es donde se instala el sistema o aplicación en el ambiente de producción, para ello se deben seguir las siguientes fases:

● Instalación ● Entrega ● Capacitación ● Preparar datos a migrar

Instalación

Para esta fase se deben completar las siguientes tareas:

1. Coordinar con el encargado de infraestructura para que realice un respaldo de los sistemas en

producción (únicamente los desarrollados internamente) y que instale el nuevo sistema o

aplicación desde el repositorio de control de versiones.

2. Coordinar con el DBA para que se ejecute el script de creación de las estructuras de la base

de datos.

3. Se asignan los permisos y roles pertinentes al super usuario.

4. El Programador debe hacer pruebas para constatar que no hay conflictos con los otros

sistemas o aplicaciones existentes.

Entrega

Una vez completadas todas estas fases, el sistema o aplicación deberá ser entregada al

Responsable, para ello, se coordinará una reunión con los involucrados para detallar y corroborar el

correcto funcionamiento del sistema o aplicación, además se entregará un oficio de conclusión del

desarrollo.

Página 18 de 37


Capacitación

Es responsabilidad del Programador impartir la capacitación respectiva a los usuarios sobre el

uso del sistema o aplicación desarrollada, sin embargo, corresponde al Responsable coordinar los

aspectos administrativos como fechas, lugares, materiales, entre otros.

Preparar datos a migrar

Puede presentarse la situación en la que hay que migrar datos ya existentes al sistema o

aplicación, es por eso que dichos datos deben de ser solicitados por el DBA al Responsable y

prepararlos para que puedan ser migrados al nuevo sistema o aplicación.

Una vez migrados los datos, el Responsable debe emitir un oficio en que haga constar que los

datos migrados son consistentes y correctos.

Documentos generados en la etapa de implantación

● Solicitud de coordinación con el encargado de Infraestructura para instalar el nuevo sistema o

aplicación.

● Solicitud de coordinación con el DBA para la ejecución del script de las estructuras.

● Solicitud de coordinación con el DBA para la subida de datos a migrar.

● Oficio de entrega.

● Oficio del Responsable sobre la consistencia de los datos migrados.

● Oficio de aceptación por parte del Responsable.

7.5 Control de cambios

Un sistema o aplicación desarrollada por la Unidad de Sistemas de la Dirección de Gestión de

Tecnologías de Información nunca debe ser considerado como finalizado, esto porque siempre se

pueden presentar mejoras, correcciones o cambios, producto de la cambiante realidad Universitaria.

Página 19 de 37


Cada una de esas correcciones o cambios, incluyendo la confección inicial del sistema o

aplicación, son conocidos como control de cambios. La Universidad hace uso de los siguientes tipos:

● Creación inicial: es la programación inicial del sistema o aplicación. ● Modificación: consiste en realizar cualquier tipo de cambio en algún elemento o proceso del

sistema o aplicación de acuerdo a alguna solicitud del usuario..

● Mejora: consiste en ampliar y mejorar las funcionalidades del sistema o aplicación. ● Optimización: es la optimización de las opciones existentes en el sistema o aplicación. ● Corrección de errores: es la corrección de errores en el sistema o aplicación.

Para cualquier control de cambios se deben de seguir los pasos de análisis, desarrollo e

implantación descritos en los apartados anteriores. Cabe destacar que a excepción del control de

cambios de Creación inicial, los controles de cambios pueden carecer de documentación. La

ausencia o presencia de la documentación puede ser justificada en la Lista de comprobación de

documentos a archivar.

Evaluación de satisfacción

La unidad de Calidad de la Dirección de Gestión de TI es la responsable de realizar la

evaluación de satisfacción del cliente sobre el servicio de desarrollo prestado. Para ello deberá tomar

en cuenta elementos como:

● Pertinencia del tiempo consumido en el desarrollo.

● Usabilidad del sistema o aplicación desarrollado

● Opinión del Responsable.

● Opinión de los usuarios finales.

● Relación costo y beneficio del desarrollo.

● Seguridad.

● Logro de los objetivos.

● Valor Agregado que brinda el sistema o aplicación al desempeño de la unidad o dependencia.

● Evaluar el cumplimiento de los requisitos solicitados.

Página 20 de 37


Seguridad

Con la aplicación de esta metodología, principalmente con el uso de los estándares de

codificación, se garantiza razonablemente la seguridad contra ataques externos hacia el sistema o

aplicación.

Sin embargo, es responsabilidad de la unidad de Seguridad de la Dirección de Gestión de TI,

en su calidad de ente fiscalizador, hacer las pruebas necesarias para garantizar el nivel de seguridad

aceptable en el sistema o aplicación.

El Programador debe seguir las recomendaciones durante todo el proceso de desarrollo del

Oficial de Seguridad Informática así como hacer uso de las políticas, procedimientos y directrices que

normen la forma de garantizar el nivel de seguridad aceptable en el sistema o aplicación.

Corrección de errores por competencia

Como se explicó anteriormente, la Universidad cuenta con un módulo llamado UTN que

provee funciones misceláneas de uso común a través de todos los sistemas o aplicaciones

desarrolladas, una de esas funciones es la de monitoreo de errores en la Base de Datos, dichos

errores son comunicados automáticamente por correo electrónico a la cola de trabajo (OTRS) de la

unidad de Sistemas.

Cuando se extienda un reporte de este tipo, el Programador a cargo del sistema o aplicación

desarrollada, tiene la obligación de hacer las revisiones pertinentes y hacer la corrección del error así

como entregar la documentación generada a la Jefatura de Gestión Técnica de TI quién será la

encargada de almacenar los documentos.

Para todo lo anterior, se debe seguir lo descrito en la sección Control de cambios y utilizar el

tipo de cambio: Corrección de errores.

Página 21 de 37

http://otrs.utn.ac.cr/


Elementos de referencia

Se presentan a continuación una serie de elementos que ayudarán a mejorar la comprensión

de esta metodología.

Entradas en las bitácoras del Repositorio de Control de Versiones

Es requisito hacer uso de un repositorio de control de versiones para almacenar todos los

elementos relacionados con el desarrollo del sistema o aplicación, cada entrada en el log de cambios

debe ir con el siguiente formato: asterisco (*) (que denota una línea nueva), espacio en blanco, la

siguiente nomenclatura según corresponda: NEW, OPT o BUG (que representan los controles de

cambio: creación inicial y/o mejora, optimización y corrección de errores), dos puntos y luego un texto

corto que describa la tarea realizada. Por ejemplo:

* NEW: Se agrega el módulo de personal. * BUG: Se corrige el error de guardado de datos en el formulario de provincias. * OPT: Se mejora la velocidad del cálculo de la Planilla.

Se debe agregar una línea para cada cambio realizado, se debe ser claro y conciso en los

textos que se escriben en la bitácora.

8. Glosario ● Metodología: Es un conjunto de métodos principios o reglas que permiten enfrentar de forma

sistemática el desarrollo de un programa. ● Programador de la aplicación o sistema: Ingeniero en sistemas encargado de todo el

proceso de análisis y desarrollo del sistema o aplicación.

● Flujograma: es la representación gráfica de los procesos a desarrollar y la forma en la que

interactúan sus elementos.

● Etapa: cada una de los pasos a desarrollar en esta metodología. ● Fase: cada uno de los pasos a desarrollar en cada una de las etapas. ● Repositorio subversion: servidor donde se almacenan los archivos que son generados

durante la creación de un sistema o aplicación, su propósito es tener un control de versiones.

● Listado: es el reporte en pantalla o físico que genera el sistema o aplicación.

Página 22 de 37


● LAMP: siglas que simbolizan un sistema operativo tipo Linux junto con Apache, MySQL y

PHP.

● Apache: servidor web. ● MySQL: motor de base de datos usado en los desarrollos. ● PHP: lenguaje de programación utilizado en el desarrollo. ● Drupal: administrador de contenidos utilizado como marco de desarrollo. ● Requerimientos funcionales: son los requerimientos que denotan las partes fundamentales

del proceso a desarrollar.

● Responsable del sistema o aplicación: es la persona o dependencia que solicitó el desarrollo

del sistema o aplicación y tiene los privilegios de administrador sobre el mismo.

● Usuario experto: es un usuario experto en el proceso y procedimiento que se desea

automatizar y tiene un alto conocimiento del flujo y el tipo de información que se manipula.

● Super Usuario: es un usuario que cuenta con los mayores privilegios en el sistema o

aplicación y que no pertenece a la DGTI.

● Administrador: ● Usabilidad: es la facilidad con que las personas pueden hacer uso del sistema o aplicación. ● Módulo UTN: es un módulo especial creado por la UTN en el que se albergan muchas

funciones de uso misceláneo por otros módulos, sistemas o aplicaciones.

● Estructuras de base de datos: se refiere a todos los elementos que componen una base de

datos tales como tablas, rutinas, triggers y vistas.

● DDL: Data Definition Languaje, por sus siglas en Inglés, son las instrucciones para crear las

estructuras de base de datos.

● DML: Data Manipulation Languaje, por sus siglas en Inglés, son las instrucciones para hacer

selecciones, inserciones, borrado y actualizaciones de datos.

● Control de cambios: cada uno de los registros de cambios por lo que pasa el desarrollo de

un sistema.

● Fiscalizar: criticar y traer a juicio las acciones u obras de alguien. ● Diagrama EntidadRelación: herramienta para el modelado de datos que permite

representar las entidades relevantes de un sistema de información así como sus

interrelaciones y propiedades.

Página 23 de 37


9. Sitios web para consulta ● Sitio oficial de Drupal: http://drupal.org/

● Sitio oficial de la documentación del Drupal: http://api.drupal.org

● Sitio oficial de la documentación de MySQL: http://dev.mysql.com/doc/refman/5.1/en/

● Sitio oficial de la documentación de Subversión:

http://subversion.apache.org/docs/communityguide/

● Sitio oficial de la documentación de PHP: http://php.net/docs.php

● Descripción general de MVC:

10. Representación gráfica de la metodología El siguiente gráfico representa la relación que existe entre las parte funcionales del proceso

de desarrollo de sistema o aplicación y la metodología.

Página 24 de 37

http://drupal.org/

http://api.drupal.org/

http://dev.mysql.com/doc/refman/5.1/en/

http://subversion.apache.org/docs/community-guide/

http://php.net/docs.php


Interrelación entre las etapas de desarrollo de la metodología

Detalle de las etapas Investigación preliminar

● Aclaración de la solicitud

● Estudio de factibilidad

Página 25 de 37


● Aprobación de la solicitud

Determinación de los requerimientos del sistema o aplicación ● Determinación de objetivos y alcance

● Levantamiento de requerimientos funcionales

● Descripción básica del proceso

● Flujograma de procesos

Diseño del sistema o aplicación Desarrollo

● Solicitar la creación del repositorio de control de versiones

● Creación de las estructuras de base de datos

● Programación de los formularios o pantallas

● Pruebas de la funcionalidad del sistema o aplicación

● Manuales de usuario y configuración

● Documentos generados en la etapa de desarrollo

Implantación ● Instalación

● Entrega

● Capacitación

● Preparar datos a migrar

Control de cambios

Página 26 de 37


Esquema de interrelación entre los UsuariosAplicación

Página 27 de 37


11. Anexos Anexo: Lista de comprobación de documentos a archivar

Lista de cotejo. Nombre del módulo:_______________

Universidad Técnica Nacional Rectoría

Dirección de Gestión de Tecnologías de Información

Control de cambios

(Creación inicial, mejora, optimización, corrección de errores)

Número de consecutivo

Análisis

Documento Referencia Presente Comentarios

Documentos de la determinación de objetivos y alcance.

Documentos del levantamiento de requisitos.

Descripción básica del proceso.

Ejemplos de los listados que el módulo debe generar.

Flujograma de los procesos.

Desarrollo


Solicitud y respuesta

Página 28 de 37


de la creación del repositorio de control de versiones.

Script de creación de las estructuras de la base de datos debidamente aprobado por el DBA.

Documento con el diccionario de datos de las estructuras de base de datos creadas debidamente aprobado por el DBA.

Diagrama EntidadRelación de las tablas de la base de datos.

Documento que compruebe las pruebas realizadas. Pueden ser los listados generados en la fase de pruebas.

Manuales de usuario y de configuración.

Oficio de aceptación por parte del usuario Responsable.

Implantación


Solicitud de coordinación con el encargado de Infraestructura para instalar en nuevo

Página 29 de 37


módulo.

Solicitud de coordinación con el DBA para la ejecución del script de las estructuras.

Solicitud de coordinación con el DBA para la subida de datos a migrar.

Oficio de entrega.

Oficio del Responsable del módulo sobre la consistencia de los datos migrados.

Oficio de aceptación por parte del usuario Responsable.

Elaborado por:

Fecha:

Firma:

Recibido por:

Fecha:

Firma:

Página 30 de 37


Anexo: Determinación de objetivos y alcance Determinación de objetivos y alcance



Control de cambios



¿Cuál es el nombre del módulo?

¿Quién es el responsable del módulo?

¿Qué objetivos pretende lograr el módulo?

¿Cuál es el alcance del trabajo?

¿Qué productos se esperan?

Página 31 de 37


Fecha:

Elaborado por:

Firma:

Nota Al firmar el documento, se hace constar que la información es clara y completa.

Anexo: Levantamiento de requerimientos funcionales Levantamiento de requerimientos funcionales. Nombre del módulo:_______________



Control de cambios



¿Qué información necesita almacenar?

¿Quién debe ingresar esta información?

¿Qué listados espera que el módulo genere?

Página 32 de 37


¿Qué usuarios y roles tienen permisos sobre el módulo?

¿Existen datos que sea necesario migrar al nuevo módulo?

¿Cómo se debe procesar la información almacenada?

¿Cuál es el orden de los procedimientos a desarrollar?

Estimado de Tiempo en horas que tomará desarrollar el requerimiento.

Comentarios.

Página 33 de 37


Fecha:

Elaborado por:

Firma:

Aprobado por:

Fecha:

Firma:


Anexo: Descripción básica del proceso Descripción básica del Proceso. Nombre del módulo:_______________



Control de cambios



Responsable:

Descripción de proceso:

Finalidad del proceso:

Página 34 de 37


¿Quienes proveen insumos al proceso?

¿Quiénes son los clientes del proceso?

¿Cómo inicia el proceso?

¿Cómo finaliza el proceso?

Actividades o subprocesos realizados:

Procesos relacionados:

Página 35 de 37


Anexo: Solicitud de Modificaciones

Solicitud de Modificaciones. Nombre del módulo:_______________________________



Control de cambios

Modificaciones a (formulario,etc)...


Descripción de las modificaciones

Objetivos

Usuario que realiza la solicitud

Nombre y número de consecutivo del requerimiento a modificar.

Tiempo estimado para realizar la modificación.

Comentarios.

Página 36 de 37


Fecha:

Elaborado por:

Firma:

Aprobado por:

Fecha:

Firma:


Página 37 de 37

Metodología para el Desarrollo de Aplicaciones o Sistemas

Documents

Transcript of Metodología para el Desarrollo de Aplicaciones o Sistemas