UNIVERSIDAD AUTÓNOMA DE ZACATECAS Francisco García Salinas. Unidad Académica de Ingeniería Eléctrica

Transcripción

1 UNIVERSIDAD AUTÓNOMA DE ZACATECAS Francisco García Salinas Unidad Académica de Ingeniería Eléctrica Programa de Ingeniería en Comunicaciones y Electrónica Proceso de Producción de Software en una Empresa Reporte de Trabajo Que para obtener el título de: Ingeniero en Comunicaciones y Electrónica Presenta: Manuel Veyna Lamas Zacatecas, Zac. Febrero de 2007

2 Dedicatoria A Dios Por darme la vida y haberme regalado salud y tantas oportunidades en esta vida, así como una familia maravillosa. A mis Padres Ramiro Veyna Bañuelos, Julia Lamas Veyna Por su incansable vida de trabajo duro y sacrificio para hacer de mí y de mis hermanos y hermana personas de bien, dándonos escuela, educación, y sobre todo cariño y apoyo, viendo que nada nos faltara en las diferentes etapas de nuestro crecimiento y formación, aun a costa de seguir sacrificando su tiempo y trabajo. Gracias papá Ramiro, Gracias mamá Julia. A mis hermanos Raúl, Sonia y Javier Que siempre han estado cerca de mí y me han apoyado en todos los momentos y en las diferentes etapas y decisiones que he pasado en la vida, saben que igualmente cuentan con el mío, pues contar con esta familia tan unida es un gran obsequio que Dios nos ha dado y quiera él que se conserve por mucho tiempo. A mis Amigos Por haberlos conocido y haber aprendido de todos ellos diferentes cosas tanto profesionales como personales, y por su apoyo brindado en las diversas ocasiones en que los necesité. A mis Profesores Por ser una guía en mi formación académica y su espíritu para resolver las dudas y problemas planteados en mis estudios, y especialmente a los que me enseñaron y dieron el ejemplo de que con trabajo dedicado y cuidadoso se obtienen los mejores resultados.

3 ii Índice de Contenidos Tabla de Ilustraciones... iii Introducción... 1 Fase 1: Análisis de las Necesidades y Levantamiento de información... 5 Definir el Alcance... 7 Levantamiento de Información... 7 Análisis de Factibilidad... 9 Fase 2: Diseño del Sistema Conceptualización de los procesos Diagrama E-R Normalización de las Tablas Relaciones entre las tablas Cardinalidad Flujo de Información Diagrama Conceptual Diagrama de Flujo de Datos Reglas del Negocio Prototipo Fase 3: Desarrollo Diccionario de Datos Archivos Programas Documentación y Ayudas Pruebas del Sistema Pruebas Generales Unitarias Pruebas de Estrés Pruebas Integrales (Incluyendo Sistemas Externos) Capacitación a Usuario Pruebas por parte del usuario Fase 4: Implementación Situaciones para las que hay que prepararse Fase 5: Soporte y Mantenimiento del Sistema Otras consideraciones para los desarrollos de sistemas Estandarización Sistema de menús y/o seguridad en opciones Especialización del Departamento de Sistemas Conclusiones Bibliografía... 63

4 iii Tabla de Ilustraciones Ilustración 1. Ciclo de Vida del Desarrollo de Sistemas... 3 Ilustración 2. Formato de Requerimiento a Sistemas. Nuevo Sistema... 6 Ilustración 3. Representación de Entidad con sus campos principales Ilustración 4. Diagrama de Relaciones entre Tablas Ilustración 5. Diagrama de Relaciones entre Tablas con Cardinalidad Ilustración 6. Diagrama Entidad-Relación del Proyecto Ilustración 7. Diagrama Conceptual Ilustración 8. Diagrama de Flujo de Datos Ilustración 10. Diccionario de Datos en Forma Alfabética Ilustración 11. Diccionario de Datos organizado por Archivo Ilustración 12. Formato de Requerimiento a Sistemas. Cambios al Sistema... 56

5 Introducción En una compañía de gran tamaño que tiene su propio departamento de sistemas, o en una compañía cuyo giro es la fabricación de software, resulta siempre de gran importancia tener definido un procedimiento o método para el desarrollo de sistemas, pues de no tenerlo puede ser difícil llevar a cabo con éxito las metas que se fijan, además de pasar por una serie de dificultades que normalmente podrían evitarse o resolverse fácilmente con una metodología adecuada. El objetivo de utilizar una metodología para el desarrollo de sistemas es tener una línea a seguir durante las diferentes fases del ciclo de vida del desarrollo de sistemas, pues no es posible que un programador se siente frente a la computadora a codificar aplicaciones sin tener claro el panorama completo de lo que se va a realizar, sino que por el contrario, hay que seguir con una serie de pasos establecidos que nos llevarán a que el proceso de codificación sea el más rápido de todos, ya que no es el único que se realiza en la creación de sistemas. Mediante el empleo de una metodología adecuada tendremos la oportunidad de Analizar, Planear, Ejecutar y Medir las etapas de cualquiera de los proyectos que se emprendan, mediante el apego lo más cercano posible a las directrices que se marcan, estando siempre en posibilidad de plantear soluciones para la correcciones en las desviaciones que pudieran ocurrir al tratar de alcanzar un objetivo. Existen varias estrategias o métodos para el desarrollo de sistemas, las cuales las principales son: Proceso de Producción de Software en una Empresa 1

6 Método del desarrollo del Análisis estructurado. Método del prototipo de sistemas. Método del ciclo de vida. Por mencionar brevemente, la estrategia del análisis estructurado se utiliza cuando se desarrollan grandes sistemas, realizando la división del sistema global en módulos que son funcionalmente independientes. Se divide en: Descripción Gráfica. Utiliza símbolos o iconos para crear un modelo gráfico del sistema, sin introducir procesos manuales o informatizados, archivos, etc. Diagramas de Flujo de Datos. Se muestran en forma gráfica las fuentes y los destinos de los datos, así como los procesos que ocurren entre ellos. Diccionario de datos. Es una lista de todos los elementos incluidos en el conjunto de los diagramas de flujo de datos que describen un sistema, almacenando detalles y descripciones de estos elementos. La estrategia del Prototipo consiste en crear inicialmente una versión del sistema que pueda operar y realizar las funciones que se espera resolver. Luego este sistema se presentará a los usuarios que lo han de utilizar y se le harán las pruebas para determinar el desempeño y funcionalidad, haciendo las correcciones o adiciones para complementarlo y dejar una versión satisfactoria del sistema. Del resultado de las pruebas se podrá determinar si se vuelve a desarrollar el prototipo, si se continúa haciendo las mejoras hasta obtener una versión definitiva y llegar a su implantación, o se abandona el proyecto. Proceso de Producción de Software en una Empresa 2

7 La estrategia del Ciclo de Vida del Desarrollo de Sistemas se compone de varias etapas o fases que se ilustran en la siguiente figura: Ilustración 1. Ciclo de Vida del Desarrollo de Sistemas Este reporte de trabajo se enfoca en una metodología específica basada principalmente en la estrategia del Ciclo de Vida del Desarrollo de Sistemas (SDLC), utilizada durante mi trayectoria como programador y analista de sistemas en Grupo Modelo, siendo ésta una empresa grande cuyo giro principal es la producción y venta de cerveza, y que cuenta con su propio departamento de producción de software. También Proceso de Producción de Software en una Empresa 3

8 se presenta una aplicación práctica de un ejemplo ilustrativo en el cual se van siguiendo los diferentes pasos que componen esta metodología, pues no se trata de repetir una vez más la teoría que dicen los libros de texto, sino de mostrar cómo se desarrollan ejemplos reales de aplicación. Este ejemplo se desarrolló en el lenguaje visual Delphi, ya que no se cuenta con un equipo AS/400 para la creación de la aplicación en esta plataforma. Proceso de Producción de Software en una Empresa 4

9 Fase 1: Análisis de las Necesidades y Levantamiento de información El paso inicial para el desarrollo de sistemas es una solicitud o requerimiento para la informatización de alguna tarea con el objetivo de reducir el tiempo de ejecución de la misma y/o guardar registros electrónicos con el fin de poder explotarlos posteriormente a través de consultas, así como la obtención de informes en forma impresa de una manera rápida y organizada. En esta etapa el paso inicial es la recepción de un requerimiento mediante un formato preestablecido ya sea en forma impresa o en forma electrónica, en el cual se indicará de la forma más clara y completa el objetivo que se pretende cumplir mediante el desarrollo de una aplicación, ya sea un sistema completo, un módulo o alguna consulta, reporte o proceso en particular, para que el analista de sistemas o líder de proyectos tenga la idea lo más exacta posible del alcance de la solicitud. Otra causa para la implantación de nuevos sistemas es adaptarse a las nuevas tecnologías cuando la organización busca adaptarse a los cambios en los procesos de su negocio, así como la ampliación del mismo, como lo es crear una nueva compañía, sucursales, etc. Proceso de Producción de Software en una Empresa 5

10 Ilustración 2. Formato de Requerimiento a Sistemas. Nuevo Sistema Proceso de Producción de Software en una Empresa 6

11 Definir el Alcance Luego de recibir y analizar el requerimiento, resulta de vital importancia acercarse con el usuario solicitante, para llevar a cabo un análisis más minucioso de las partes que compondrán la aplicación a desarrollar, las reglas de negocio, validaciones específicas, relación con otros módulos o sistemas, algoritmo del cálculo de los procesos, qué hacer en casos de excepciones a las reglas o situaciones especiales. Esto es con el objetivo de definir el alcance y limitaciones que se tendrán, pues esto debe establecerse desde un principio para evitar malos entendidos y posteriores reclamaciones por parte del solicitante de que le faltan componentes a lo que solicitó, o bien, hacer trabajo que no era necesario, que aunque podría resultar beneficioso para el solicitante del sistema, sería un gasto no necesario de recursos, ya sea humanos y/o económicos, y en el caso de empresas que fabrican software para comercializarlo, se refleja en la pérdida/reducción de utilidades. Levantamiento de Información Esta fase del levantamiento de información la debemos efectuar al principio de todo proyecto para entender cómo funciona y conocer a fondo el negocio que se pretende automatizar o rediseñar en un sistema de cómputo. La primera tarea a realizar es determinar con exactitud cómo se hace un proceso actualmente, cuáles son los datos de entrada, y de éstos cuáles serán de captura manual o de obtención mediante algún dispositivo, cuáles se encuentran ya almacenados en algún archivo existente ya sea dentro del mismo sistema o alguno externo, y el formato en Proceso de Producción de Software en una Empresa 7

12 que se encuentran, con el fin de prever también algún proceso obtención de datos y conversión a un mismo formato. Resultará de gran utilidad acudir al área o usuario que realiza el proceso para conocer en vivo los movimientos que realizan y darse una idea más clara de la forma de operar tanto en la obtención de sus datos como en los resultados que arroja. Las entrevistas con el usuario son fundamentales, pues siendo él el experto podrá aclarar todas las dudas que surjan para el entendimiento de un proceso. En una forma práctica, se hace una mancuerna o equipo de trabajo en esta fase entre el usuario y el analista de sistemas, logrando con esto una comunicación efectiva y eficaz de qué se requiere y cómo se requiere. Una herramienta de gran utilidad es el Diagrama de Flujo de Datos para ilustrar de una manera fácil y rápidamente comprensible del proceso actual o real para tener una idea clara del cómo se trabaja ahora, y darse cuenta de los puntos que podrían resolverse o modificarse para optimizar el proceso. El Diagrama de Flujo de Datos se explicará más adelante. Enseguida se plantea cómo se quiere que funcione el mismo proceso pero ya con el nuevo sistema, es decir, para obtener un comparativo de cómo se hace actualmente y cómo se propone que se hará después. Aquí veremos lo que se requiere como salida una vez que funcione el sistema. Esto no es propiamente realizar el diseño del sistema, sino mas bien plantear qué problemas existen, si los hay, y como se desearía trabajar con la ayuda de un nuevo sistema. Proceso de Producción de Software en una Empresa 8

13 Esta diferencia en la forma de operar es precisamente la tarea a resolver mediante el desarrollo e implantación de un sistema informatizado, con lo cual se determinan los procesos a realizar, tanto en la captura de datos como en los cálculos y datos a obtener y guardar. Puede ser que el sistema se componga de varios procesos que pueden estar ligados unos con otros formando una interrelación entre todos ellos, lo cual se debe tomar en cuenta en todo momento para que todos los componentes se diseñen de tal forma que puedan interactuar unos con otros, y de esta forma establecer también las reglas para el manejo de los mismos recursos, archivos y datos. Cuando ocurre esta situación la recomendación o regla a seguir es que hay tratar de que los diferentes módulos puedan funcionar o instalarse de manera independiente, o con los mínimos cambios o configuraciones, pues dependiendo del tamaño del proyecto puede requerirse que se vaya instalando en partes debido al proceso de arranque inicial y comportamiento al iniciar la operación en producción, así como su monitoreo en paralelo respecto al sistema anterior. Análisis de Factibilidad Una situación a considerar, es que con un nuevo sistema de información puede ser que sea necesaria una reingeniería, en otras palabras, un cambio en la forma de realizar las operaciones, pues habrá casos en que no tenga mucho sentido seguir haciendo lo mismo pero capturando en una computadora adicional a lo que se hace en papel, ya que de lo que se trata es de agilizar las operaciones, y de obtener más Proceso de Producción de Software en una Empresa 9

14 información para procesarla y explotarla obteniendo resultados que antes no se tenían o se podían lograr. En esta parte del proceso es donde se realiza el análisis de costo/beneficio de llevar a cabo la tarea solicitada. Para determinar si es o no factible el desarrollo del proyecto solicitado, debemos contestar a las siguientes preguntas: Qué beneficios se obtienen para la organización que lo solicita? Qué se perderá si no se lleva a cabo? Cuál es el costo que se requiere para realizarlo? Lo hacemos o lo compramos? Para dar respuesta a la primera pregunta, se debe justificar plenamente por parte del departamento solicitante, pues el destinar recursos humanos y posiblemente monetarios significará un esfuerzo para la planeación y seguimiento del proyecto. Pero por otra parte, también debemos tomar en cuenta las repercusiones que habría en caso de que no se lleva a cabo el proyecto, o por lo menos si no se realiza en un tiempo inmediato, por lo que se tendrá que evaluar si es solamente algo que el usuario está solicitando para ahorrarse alguna captura de una actividad que ya lleva mucho tiempo haciendo sin un nuevo sistema, y es posible o no destinar los recursos para hacerlo, o se trata de algo que requiere para cumplir sin posibilidad de cambiarlo, como puede ser un requerimiento de la autoridad, por ejemplo, cambios en alguna ley de impuestos, laboral, contable, etc. Estos últimos, por lo general, se dan con un plazo establecido y limitado que no puede posponerse. Puede haber casos, como ocurre en el sector privado, que las empresas realizan cambios o innovaciones en sus procesos, a los cuales no se podrá negar su Proceso de Producción de Software en una Empresa 10

15 cumplimiento, en este caso realmente sería revisar cuándo se puede realizar, o en su caso, modificar la planeación del departamento para dar la prioridad que corresponda. Cuando se refiere a sistemas de tamaño grande o considerable, y en la que se vea afectada alguna parte operativa del proceso como involucrar la conexión con otro tipo de interfase o maquinaria, haya que cambiar la logística, la plataforma del sistema, etc. implica realizar un análisis del costo tanto de recursos humanos como del costo económico para implantarlo. Para realizar estas consideraciones, el primer paso es determinar si nuestro departamento de sistemas cuenta con los suficientes recursos humanos necesarios para terminar en tiempo y además si están calificados para este desarrollo o requerirán de alguna capacitación, y el tiempo y costo que ésta implicaría. Ya que esto estará principalmente en función de la importancia y del tiempo otorgado para la entrega del proyecto, ahora la pregunta clave es: Lo hacemos o lo compramos? Si luego de analizar estos factores que se acaban de mencionar se determina que no es posible llevarlo a cabo por el departamento interno de sistemas, entonces se deberá considerar recurrir a una fuente de out-sourcing. El out-sourcing consiste en que se contratan los servicios de un proveedor externo que se encargará de llevar a cabo el proyecto, pudiendo incluir las etapas desde el análisis de necesidades y diseño del sistema, o solamente desde la programación para adaptar e implantar un sistema ya existente. Proceso de Producción de Software en una Empresa 11

16 Para este proceso se deberá llevar a cabo una selección de los proveedores que se conozcan o se recomienden para reunirlos y exponerles el proyecto que se pretende realizar. Un buen criterio para determinar a cuáles proveedores convocar es tomar en cuenta el prestigio y experiencia que tienen, y mediante referencias de otras compañías en las que han prestado algún servicio. En esta serie de reuniones se les dará a conocer el análisis y levantamiento de información realizados anteriormente, para que estén en posibilidad de realizar su análisis técnico y posteriormente presenten su propuesta, la cual deberá ser analizada en el aspecto económico, funcional y el tiempo de entrega esperado. Proceso de Producción de Software en una Empresa 12

17 Fase 2: Diseño del Sistema Conceptualización de los procesos Luego de tener el levantamiento de información de las diferentes áreas que realizan procesos en el conjunto global del sistema, ahora hay que definir qué trabajos se realizarán por personas y cuáles por la máquina, y especificar los suficientes detalles para permitir su interpretación y su realización física. El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. La fase del Diseño del Sistema comprende cuatro etapas: El Diseño Arquitectónico. Define la relación entre cada uno de los elementos estructurales del programa, es decir, se refiere a la identificación de los subsistemas y módulos que conforman un sistema y la infraestructura de control y comunicación. Esta etapa es de las primeras partes del diseño pues se realiza en paralelo o enseguida de la determinación de las especificaciones. El Diseño de la Interfaz. Describe cómo se comunica el Software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. Para las interfaces entre sistemas o bases de datos diferentes, se recomienda que se realice la comunicación mediante archivos intermedios para la transferencia de Proceso de Producción de Software en una Empresa 13

18 información, pues aunque los sistemas interactúen entre sí al estar trabajando, siempre alguno va a requerir algún mantenimiento, por lo que si se utilizan directamente los archivos del otro sistema, se corre el riesgo de que se quede bloqueado algún archivo, y si la organización es grande o alguno de estos sistemas opera las 24 horas, será difícil que liberen la base de datos para realizar los cambios programados. La interfaz de salida se ha de diseñar de manera que cada usuario pueda visualizar o imprimir solamente la información que le corresponda, ya que existen jerarquías y niveles de puestos que desempeñan diferentes funciones, los cuales trabajarán diferentes tipos de datos de la organización, por lo que hay que pensar por ejemplo que la información confidencial deberá ser restringida y protegida. En general se pueden utilizar dos formas para otorgar la seguridad sobre las opciones del sistema: - Sistema de Menús de opciones por usuario, habilitando o deshabilitando las opciones otorgadas a cada usuario en particular. - Sistema de seguridad por Perfiles, un usuario podrá tener uno o más perfiles, los cuales tendrán permisos configurados de acuerdo a las tareas a realizar. El Diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa. Esta etapa de estudio y diseño tiene como finalidad determinar los siguientes puntos: - Cómo trabajará el sistema propuesto una vez que se ha estudiado en conjunto con los usuarios. Proceso de Producción de Software en una Empresa 14

19 - Qué personal utilizará y cómo estará organizado. - Qué cantidad y clase de equipo será necesario. - Cuáles serán los costos de operación del nuevo sistema. El diseño de los datos. Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. Se refiere a las especificaciones de los campos y cómo se guardarán estos en los archivos, y para estos aplicarles condiciones especiales, si les aplican, dependiendo si van a guardar detalles de las transacciones, datos históricos, o información de referencia. Enseguida se mostrará cómo construir el diagrama Entidad-Relación para el diseño de la base de datos. Diagrama E-R El Diagrama Entidad-Relación es la representación de las tablas que componen el sistema, así como la relación que existe entre ellas. A través de este diagrama nos podemos dar cuenta de todas las tablas que tenemos que afectar o actualizar al realizar algún cambio en un registro, ya que nos muestra todas las dependencias entre las distintas entidades. Proceso de Producción de Software en una Empresa 15

20 El primer paso es entonces realizar en un diagrama la representación de las tablas del sistema a desarrollar, comenzando con las entidades principales, para luego continuar con las tablas secundarias o resultantes de las relaciones entre las tablas principales. Las tablas o entidades se representan gráficamente como unos rectángulos en los que en su cuerpo se describe el nombre de l archivo y lo que contiene. Enseguida se representan los campos de la llave del archivo, que puede ser uno o más de uno, dentro de un óvalo relacionado mediante una línea hacia el rectángulo del archivo. Dentro de cada óvalo se anota el nombre de cada campo y se subrayan. Se pueden representar otros campos importantes del archivo que aunque no sean llave pueden tener cierta relevancia como documentación y que es necesario tener en cuenta en las siguientes etapas del desarrollo. Véase la siguiente figura: Ilustración 3. Representación de Entidad con sus campos principales Normalización de las Tablas El resultado del modelado de un sistema, utilizando herramientas como el diagrama E-R y el modelo relacional es una base de datos que contiene tablas con sus respectivos atributos; el hacer esto de una forma arbitraria y sin utilizar técnicas que Proceso de Producción de Software en una Empresa 16

21 aseguren la correcta relación entre ellas puede llevar a una conceptualización errónea en el diseño de la base de datos, generando problemas como: redundancia de información, ambigüedad en los datos, incapacitad para representar cierta información o pérdida de información. Es decir, no basta generar un conjunto de tablas a través de un E-R sino que deben ser validados los atributos utilizando la técnica de normalización. Normalización es una técnica formal y estandarizada de diseño de base de datos, que permite establecer niveles de seguridad para que el diseño no posea redundancia ni problemas de información. Estos niveles son conocidos como Formas Normales, los cuales están basados en el concepto de Dependencia Funcional. En los siguientes ejemplos las formas normales serán explicadas de una manera práctica. Los niveles de normalización son los siguientes: 1FN 2FN 3FN BCNF 4FN 5FN Primera Forma Normal Segunda Forma Normal Tercera Forma Normal Boyce Code Normal Form Cuarta Forma Normal Quinta Forma Normal Estas formas normales son dependientes una de otra en la secuencia que se enumeran, y que se ilustra en la siguiente figura: Proceso de Producción de Software en una Empresa 17

22 Como se aprecia en el dibujo, la 2FN es dependiente de la 1FN, es decir, que para que una tabla esté en la 2FN debe estar en 1FN, o por ejemplo, para que una tabla esté en BCNF primero debe estar en 3FN, y así sucesivamente. La normalización es un proceso de descomposición de atributos de una tabla no normalizada en varias tablas normalizadas, y está en función del nivel de normalización que se quiera aplicar, por ejemplo: Como se puede observar en la figura, la normalización produce una descomposición de la tabla o tablas originales, lo que implica que un diseño que esté normalizado aumente la cantidad de tablas, por lo que al no poseer redundancia, el Proceso de Producción de Software en una Empresa 18

23 proceso de producir información requiere el acceso a varias tablas del sistema y no a una, por lo que es importante determinar el justo medio para no degradar el rendimiento (performance) de los sistemas que accedan la base de datos. 1FN Primera Forma Normal (Atributos atómicos) Se dice que un diseño está en primera forma normal si todos sus atributos son atómicos, es decir, no pueden ser descompuestos en atributos mas simples. Un ejemplo tradicional es el nombre del empleado, que se divide en nombres, apellido paterno y apellido materno. Si no se hace esta descomposición, no se podrían realizar consultas por los apellidos o los nombres. Otro ejemplo clásico de esta forma normal es el siguiente: Domicilio (no es atómico) Calle Número Exterior Número Interior Colonia Municipio/Delegación Proceso de Producción de Software en una Empresa 19

24 2FN Segunda Forma Normal (Eliminación de dependencias parciales eliminación de catálogos) Un diseño se encuentra en segunda forma normal, si y sólo si se encuentra en 1FN y si todos los atributos que no participan en la llave son determinados o dependen totalmente de la llave. Ejemplo: En la tabla anterior partimos de una tabla que se encuentra en 1FN, y vemos que la llave primaria de la tabla MOVIMIENTOS es un número de empleado y concepto, todos los atributos son determinados por el número de empleado y concepto, excepto el nombre del concepto que solamente es determinado por el número de concepto, lo que implica que éste debe ser separado a otra tabla. En este caso en la descomposición de la tabla MOVIMIENTOS se elimina el atributo Nombre de Concepto y se crea una tabla que se llama Catálogo de conceptos, en la cual se incluye el atributo eliminado Nombre de concepto, así como el atributo que lo determina, que en este caso es e Concepto, y que será la llave de la nueva tabla. Proceso de Producción de Software en una Empresa 20

25 3FN Tercera Forma Normal (Eliminación de dependencias transitivas Llaves foráneas) Un diseño se encuentra en tercera forma normal si y sólo si éste se encuentra ya en segunda forma normal y no existen dependencias transitivas sobre la llave primaria. Para el ejemplo, haremos la consideración sobre lo que es una dependencia funcional: un atributo Y es dependiente funcional de X, si para cada valor de X hay un valor específico de Y, es decir, si conozco X por lo tanto conozco Y, pero si conozco Y no necesariamente se puede conocer X. Y se expresa de la siguiente manera: X Y, cuando se da este caso por sí solo, X es la llave primaria de la tabla, y Y es un atributo que no participa en la llave primaria. Si tenemos una tabla EMPLEADO, con atributos N, W, X, Y, Z y tenemos las siguientes dependencias funcionales: N W N X N Y N Z Existe una dependencia transitiva N Z ya que y N Y Y Z Por lo tanto, por transitividad existe esta dependencia N Z, denominada dependencia transitiva. Esta dependencia está prohibida en la tercera forma normal. A continuación se describe un ejemplo que permita explicar esto de forma mas detallada: Proceso de Producción de Software en una Empresa 21

26 La tabla EMPLEADO no se encuentra en 3FN ya que Nombre de Departamento depende del atributo Departamento y Número de empleado determina a Departamento, (el departamento en el que trabaja el empleado), por lo que es conveniente separar en otra tabla (DEPARTAMENTOS) el nombre del departamento de la tabla original EMPLEADO. Es importante destacar que el atributo Nombre Departamento no depende de la llave primaria de la tabla. BCNF Forma Normal de BOYCE-CODD (Eliminación de llaves candidatas) Esta forma normal es hasta cierto punto especial y fue diseñada por Boyce Codd para distinguir una nueva 3FN de la anterior, es decir, para corregir un problema de la 3FN. Se dice que un diseño está en BCNF si y sólo si se encuentra en 3FN y cada determinante (es decir, un atributo o conjunto de atributos que hacen único a un registro) es una llave candidata. Ahora, se habla de llave candidata y no de llave primaria. El Proceso de Producción de Software en una Empresa 22

27 motivo de introducir BCNF es que la definición original de 3FN no es satisfactoria cuando un caso maneje una o más llaves candidatas que se solapan. Una llave candidata es un atributo o atributos que pueden intensificar si así se define a un registro en particular de la tabla. Para explicarlo es mejor con un ejemplo: Supongamos que tenemos la siguiente tabla: Esta tabla puede contener dos llaves: 1. Número de proveedor y número de parte 2. Nombre de proveedor y número de parte En este caso el número de proveedor y nombre de proveedor fungen como llave candidata y la pregunta es: Están en BCNF? La respuesta es que no, porque hay dos determinantes (número de proveedor y nombre de proveedor, las cuales no son llaves primarias de la tabla PEDIDO, ya que nombre de proveedor determina a un número de proveedor y viceversa. Para la solución de este caso hay que decidir cuál de las dos determinantes va a utilizarse (una de las dos) como parte de la llave primaria de la tabla PEDIDO, quedando dos posibles soluciones válidas: Proceso de Producción de Software en una Empresa 23

28 4FN Cuarta Forma Normal (Eliminación de dependencias multivaluadas Maestro-Detalle) Un diseño está en cuarta forma normal si y sólo si ya se encuentra en BCNF y no contiene dependencias funcionales multivaluadas. Una dependencia funcional multivaluada X Y, significa que si conozco el valor de X determino varios valores de Y (dos o más), por ejemplo: Considerando una factura de venta, los datos generales de una factura son: 1. X Número de factura 2. Y Fecha de la factura 3. V Número de cliente 4. Z Artículos que se están vendiendo 5. W Cantidad del artículo vendido Tenemos las siguientes dependencias funcionales: 1. X Y 2. Y V Tenemos las siguientes dependencias funcionales multivaluadas: 3. X Z 4. XZ W Proceso de Producción de Software en una Empresa 24

29 Analizando las dependencias funcionales, se encuentra que X determina funcionalmente a Y y V y en forma multivaluada a Z, por lo que la descomposición se hace de la siguiente manera: De tal forma que se separa la dependencia multivaluada X Z en una tabla adicional, que finalmente y por coincidencia es representada por la dependencia multivaluada: XZ W. En resumen, el objetivo de la cuarta forma normal es eliminar las dependencias multivaluadas, lo que hace que nuestro diseño sea más paramétrico y no limitado a tener una cantidad fija de n atributos que representan lo mismo, como por ejemplo artículo1, artículo2, artículo3, artículo15, suponiendo que en la facturación tuviéramos hasta 15 líneas de detalle. Existen situaciones en las cuales se justifica el no utilizar normalización hasta 4NF, por ejemplo, cuando se tienen atributos que son multivaluados pero la cantidad de valores está en función de meses u otro parámetro que sabemos que es fijo por su naturaleza (que no puede aumentar o disminuir en función de la aplicación en particular), por lo tanto Proceso de Producción de Software en una Empresa 25

30 en este caso sí se permite que sea multivaluada para un mejor desempeño. Esto es muy representativo con los ejemplos de información histórica por año en donde se utilizan arreglos de 12 posiciones para representar un dato determinado en cada uno de los 12 meses del año y que se sabe que los meses no pueden variar y que siempre serán 12, pero en contraparte cuando la cantidad de atributos iguales está en función de la aplicación es conveniente normalizar a 4FN y no limitar el diseño a un número determinado de valores estimado. 5FN Quinta Forma Normal Un esquema de relaciones R está en 5FN con respecto a un conjunto D de dependencias funcionales, de valores múltiples y de producto, si para todas las dependencias de productos en D se cumple por lo menos una de estas condiciones: (R1, R2, R3,... Rn) es una dependencia de producto trivial. * Toda Ri es una superllave de R. La quinta forma normal se refiere a dependencias que son extrañas. Tiene que ver con tablas que pueden dividirse en subtablas, pero que no pueden reconstruirse. No la detallamos por su dudoso valor práctico, y que conduce a una gran división de tablas. Relaciones entre las tablas Luego de normalizar las tablas y llegado a su diseño final, se establecerán las relaciones entre ellas; esto significa cómo se relaciona un registro de una tabla con otro u otros de las otras tablas. Esto surge de acuerdo a las reglas de negocio del sistema, y Proceso de Producción de Software en una Empresa 26

31 puede que aún surjan nuevas tablas, que pueden ser relaciones entre algunas de las inicialmente definidas, que pueden ser virtuales o reales. Las relaciones virtuales se diagraman solamente con fines ilustrativos de diseño, y las relaciones reales son nuevas tablas necesarias de crear pues supone el almacenamiento de datos cuando uno o más registros de una tabla se relacionan con uno o más registros de otra. Además, sirve como base para tener en cuenta todas las afectaciones necesarias que debe realizar una aplicación. Los Tipos de relaciones pueden ser de varios tipos: Uno a uno. Significa que un registro de una tabla le corresponde uno y sólo uno de otra tabla. Uno a muchos. Significa que a un registro de una tabla de corresponde uno o varios registros de otra tabla. Muchos a Muchos. Normalmente da lugar a una nueva tabla, o tabla relación, que surge cuando un registro de una tabla puede tener más de un registro coincidente en otra tabla, y viceversa. Recursiva. Es cuando la existencia de un registro se valida contra otro registro de la misma tabla. Proceso de Producción de Software en una Empresa 27

32 Ilustración 4. Diagrama de Relaciones entre Tablas Cardinalidad La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad. De acuerdo a los tipos de relaciones, se puede indicar en forma más específica, cuando así se requiere, el número exacto de registros que podría haber en algún extremo de la relación, por ejemplo, puede que sea obligatorio que exista por lo menos un registro, o puede que no sea necesario que exista un mínimo, etc. Enseguida se ilustran algunos ejemplos: Proceso de Producción de Software en una Empresa 28

33 Ilustración 5. Diagrama de Relaciones entre Tablas con Cardinalidad A continuación se muestra el Diagrama Entidad Relación de un Sistema para Compras y Almacén, cuyo objetivo es llevar el control de las existencias, movimientos y las compras de los artículos de partes y refacciones que en este se manejan. Se presenta una versión reducida en el presente trabajo únicamente con el objetivo de presentar en forma ilustrativa y general la información que se debería contemplar, pero para desarrollar el sistema completo se tendrá que especificar con el debido detalle, por ejemplo, para el catálogo de proveedores se le complementaría el Teléfono, el Nombre del Contacto o Representante, datos como su Cuenta Contable, Cuenta Bancaria, etc., de igual manera con los otros archivos. Proceso de Producción de Software en una Empresa 29

34 Ilustración 6. Diagrama Entidad-Relación del Proyecto Proceso de Producción de Software en una Empresa 30

35 Flujo de Información En todo sistema se manejan datos que se reciban a través de una interfaz de entrada, como puede ser el teclado de las terminales, la interfaz de un dispositivo, o a través de alguna transferencia electrónica. Estos datos serán transformados a través de procesos con el objetivo de convertirlos en información útil, que se podrá almacenar y obtener una salida a través de otro dispositivo que puede ser la misma terminal, reportes impresos, señales a otros dispositivos, etc. Este camino que siguen los datos a través del sistema es el flujo de los datos, el cuál será útil representar para dar una idea más clara del camino que siguen a través de las diferentes etapas del proceso. Diagrama Conceptual Un diagrama conceptual nos muestra los conceptos presentes en el dominio del problema. Un concepto para este caso, en términos de la programación es un objeto del mundo real, es decir, es la representación de cosas del mundo real y NO de componentes de software. En él no se definen operaciones (o métodos); en este modelo se pueden mostrar los conceptos, los atributos de los conceptos (opcionalmente) y la relación o asociación entre ellos. Informalmente podríamos decir que un concepto es una idea, cosa u objeto. Para descubrirlos debemos analizar los sustantivos en las descripciones textuales del dominio del problema, es decir, de la descripción del sistema, de los Requerimientos y de los Casos de Uso. Proceso de Producción de Software en una Empresa 31

36 Enseguida se muestra el diagrama conceptual para el diseño de un sistema de Vale Electrónico para los departamentos de Almacén y de Compras, el cual tiene por objetivo que los diferentes departamentos que conforman la compañía puedan consultar desde su lugar de trabajo la existencia de los diferentes materiales y refacciones que se utilizan en su trabajo diario, así como poder realizar las solicitudes del material desde su lugar para que les sea reservado ese material, y una vez que lleguen al almacén esté listo para surtírselos. Ilustración 7. Diagrama Conceptual Proceso de Producción de Software en una Empresa 32

37 Por otra parte, todas las transacciones de los diferentes materiales y refacciones se registrarán en forma electrónica para llevar el registro exacto de sus existencias y movimientos. Finalmente, ya no siendo parte del trabajo práctico, se plantea la posibilidad de un módulo en el sistema para implementar un sistema de compras, que funcionaría de la siguiente forma: Al llegar la existencia de un artículo a su mínimo o por debajo de éste, automáticamente se creará en el sistema de compras una requisición para la compra de este artículo. El departamento de compras se encargará de cotizar con diferentes proveedores el artículo, para buscar la mejor opción de compra. La gerencia o alguien con la autoridad adecuada asignará el mejor proveedor, y a éste se le realizará la compra. Al recibir el material, se actualizará la existencia del artículo en el almacén, y se generará un pasivo para que el departamento de Cuentas por Pagar se encargue del trámite del pago. Aquí los departamentos o áreas que realizan alguna operación en el proceso se muestran como columnas, aunque se podría representar también como renglones; y las operaciones que se van realizando se van conectando mediante flechas que indican la dirección en que fluyen los datos, ilustrando de esta forma la secuencia en que se realizan los procesos. Proceso de Producción de Software en una Empresa 33

38 Diagrama de Flujo de Datos Una forma de representar gráficamente el flujo de la información a través del sistema así como las transformaciones que se realizan mientras la información fluye, es por medio de una técnica llamada Diagrama de Flujo de Datos (DFD). El Diagrama de Flujo de Datos es un modelo que describe los flujos de datos, los procesos que cambian o transforman los datos en un sistema, las entidades externas que son fuente o destino de los datos (y en consecuencia los límites del sistema) y los almacenamientos o depósitos de datos a los cuales tiene acceso el sistema, permitiendo así describir el movimiento de los datos a través del sistema. En otras palabras, es una herramienta que permite visualizar un sistema como una red de procesos funcionales conectados entre sí, ilustrando todo el flujo de la información desde que se genera hasta que se obtiene la salida definitiva o se llega a su estatus final. Los DFD no sólo se pueden utilizar para modelar sistemas de proceso de información, sino también como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios, pues se pueden diagramar los procesos de nivel más general hasta otros niveles, de acuerdo al grado de detalle del proceso que se requiere representar. Proceso de Producción de Software en una Empresa 34

39 Ilustración 8. Diagrama de Flujo de Datos (Despacho del Vale Electrónico) Para el ejemplo, se muestra un Diagrama de Flujo de Datos para el proceso de Compra de materiales para un almacén, desde que se detecta que hace falta en el almacén, hasta que se genera su orden de pago. En síntesis, el Diagrama de Flujo de Datos describe: Los lugares de origen y destino de los datos (los límites del sistema), Los canales por donde circulan los datos. Las transformaciones a las que son sometidos los datos (los procesos internos), Los lugares en los que se almacenan los datos dentro del sistema. Proceso de Producción de Software en una Empresa 35

40 Reglas del Negocio El sistema propuesto se llamará Vale Electrónico, pues la intención es que las áreas de la organización puedan solicitar un material al almacén vía sistema, al cual al crearla se validará que haya existencia disponible del artículo solicitado, de no ser así, se desplegará un mensaje con esta indicación. Al capturar una solicitud, se reservará en el almacén esta cantidad para que no pueda ser solicitada por alguien más. Si no hay cantidad disponible, no se podrá capturar una nueva solicitud, mostrando el mensaje correspondiente. Al despachar el artículo, se descontará la cantidad de la existencia del artículo y se generará la transacción de salida. Si la existencia del artículo llega por debajo de su mínimo establecido, se disparará automáticamente una requisición hacia Compras, para que cotice el artículo con los diferentes proveedores. La gerencia tendrá una opción para autorizar la mejor cotización, fincando así el pedido a un proveedor. Cuando se reciba el material, se generará una transacción de entrada por compra, y se adicionará la cantidad del pedido a la existencia del artículo. Proceso de Producción de Software en una Empresa 36

41 Prototipo Antes de comenzar con la fase de codificación por parte de los programadores, es necesario realizar un prototipo de cómo se verá la aplicación ya funcionando. Si se utiliza la estrategia para el desarrollo de sistemas del Ciclo de Vida, realizar el prototipo no se refiere a la creación del sistema funcional como tal para su evaluación y pruebas, sino que puede ser un documento en Word o Power Point por ejemplo, o algún otro software para este propósito, en el que se mostrarán las principales pantallas de la aplicación y los componentes que la conforman, dando la explicación de operaciones que se realizarán, así como los menús y árbol de navegación para llegar a cada una de ellas. Basándose en el prototipo en este formato, se podrá revisar con los usuarios solicitantes y con los involucrados en el desarrollo de las aplicaciones si se cumplirán las expectativas de lo que se requiere, y hacer las posibles modificaciones y ajustes para tener completamente claro y definido el rumbo a seguir cuando se llegue a la etapa de codificación, pues ya se tendrá definido el entregable, cómo deberá verse y las especificaciones de cómo deberá funcionar. Proceso de Producción de Software en una Empresa 37

42 Pantalla Principal: Consulta de Proveedores: Proceso de Producción de Software en una Empresa 38

43 Consulta de Artículos: Captura de Solicitudes de Material: Proceso de Producción de Software en una Empresa 39

44 Fase 3: Desarrollo Diccionario de Datos Lo primero a realizar es la generación del Diccionario de Datos, cuando la plataforma de programación así lo soporta o requiere. El Diccionario de Datos es un archivo que contiene la definición de cada campo que existirá en los archivos del sistema, para no tener que definirlos cada vez en cada archivo que los utilice. Puede darse el caso de que de acuerdo a la plataforma y/o al diseño de la programación, resulte que en dos o más archivos utilizados al mismo tiempo por un programa contengan el mismo campo, creando alguna confusión a la hora de su utilización, por lo que es factible hacer que ese campo tenga nombres similares pero no iguales en diferentes archivos. Esto facilitaría la solución rápida de cuestiones técnicas, que aunque pueden resolverse con más líneas de código, resulta más sencillo y por lo tanto eficiente manejarlo como si se tratara de dos variables diferentes, pues en realidad lo son por ser datos de distintos archivos. Para la plataforma AS/400 el Diccionario de datos se crea a través del Archivo de Referencia de Campos conocido como FRF (por sus siglas en inglés de Field Reference File). Cuando se crean los archivos físicos, se les pone la directiva del FRF al cual hacer la referencia para tomar las propiedades de los campos. Proceso de Producción de Software en una Empresa 40

45 Para la creación de un Archivo de Referencia de Campos en la plataforma AS/400 se tienen dos alternativas: 1.- Crear una lista alfabética con la definición de todos los CAMPOS que se manejarán en el sistema. Ilustración 9. Diccionario de Datos en Forma Alfabética Proceso de Producción de Software en una Empresa 41

46 2.- Crearlo en forma similar a la estructura de los archivos de la base de datos del sistema. Ilustración 10. Diccionario de Datos organizado por Archivo Proceso de Producción de Software en una Empresa 42

47 La primera forma nos dirá en forma rápida el contenido del campo una sola vez, pero la segunda forma tiene la ventaja de que se puede localizar fácilmente en cuántos y cuáles archivos se encuentra determinado campo cuando se requiere por ejemplo cambiarlo de tamaño o determinar dónde se guarda para realizar todas las afectaciones necesarias en una aplicación. Archivos Para la definición de la estructura de los archivos es de suma importancia hacer la referencia al Diccionario de Datos, ya que de omitirlo podría resultar en que un campo tuviera diferente tipo o tamaño en diferentes archivos, creando así un conflicto a la hora de codificar los programas. Como reglas básicas para la creación de archivos, su llave debe cumplir con las siguientes características: Ser única e irrepetible, ya sea que se forme por uno o más campos. Además no se deben permitir valores nulos. Debe ser indexada (cuando según la plataforma lo permita o requiera) Utilizar el tamaño adecuado de forma que no quede de un tamaño excesivo, lo cual podría repercutir en la velocidad del manejo de las operaciones. Una buena práctica es que en primer lugar se creen los archivos que son los catálogos y entidades principales que componen el sistema, pues dependiendo de su tamaño o de la plataforma, puede que tome determinado tiempo la creación de todas las Proceso de Producción de Software en una Empresa 43

48 tablas, por lo que se puede sacar ventaja de que se pueden ir creando los programas de Altas, Bajas y Cambios de aquellos, mientras se sigue con la creación de los otros archivos. Además, creando las tablas y sus programas de mantenimiento en este orden, se podrá tener un sistema funcional en menor tiempo, que incluso podría mostrarse como prototipo al comité de sistemas o usuario solicitante, para que aún pueda hacer algunos comentarios y ajustes de última hora, y que serían menores y más rápidos de resolver antes de que el sistema esté completamente terminado. Programas Determinar el número de programas que compondrán un sistema no es una tarea sencilla,; dependerá de la plataforma y el lenguaje de programación con los que se trabaje para determinar cuáles tipos de programas pueden generarse en forma automática y cuáles hay que realizar completamente en forma manual. En el RPG del AS/400 todos los programas se tienen que crear manualmente, pues no genera programas de lista, ni formularios automáticos. En general para cada archivo que resulta se requiere un programa para su mantenimiento u operación, dependiendo de la información que contiene. En el caso de catálogos, normalmente se requiere de un programa de mantenimiento para Altas, Bajas y Cambios, y un Programa de Selección de registros (éste último dependiendo si la plataforma o lenguaje de programación no lo genera automáticamente). Proceso de Producción de Software en una Empresa 44

49 Para archivos de operación, normalmente transaccionales, se requerirá de programas de Altas, Bajas y Cambios que ya son de tamaño y complejidad mas grande, pues se tienen que hacer validaciones según las reglas de negocio, revisión con otros archivos, cálculos, llamados a procesos, etc., según las especificaciones dadas. Por otra parte, se hace la lista de programas auxiliares y/o de enlace hacia otros sistemas, tales como validación de fechas en cierto formato, validación de los datos de alguna transacción, cálculo de n días a partir de una fecha determinada, determinación del estatus de cierto registro en una tabla, por mencionar algunas de las operaciones repetitivas que es mejor codificar en un programa por separado y no hacer esta programación en varias aplicaciones. El beneficio de separar estas tareas repetitivas en programas independientes es que pueden ser llamadas desde cualquier programa que ya está planeado, o cualquiera que se cree en el futuro, así como por aplicaciones externas que pudieran hacer uso de la misma rutina. Así, si por alguna disposición se requiere cambiar alguno de estos cálculos, bastará con modificar un solo programa en lugar de tener que actualizar varios programas principales, amén de la tarea de buscar cuántos y cuáles realizan ese proceso. Esto último sería bastante costoso en cuanto a tiempo, ya que además de identificar cada uno de los programas, habrá que realizarles las pruebas correspondientes para verificar que arrojan los mismos resultados, y si ocurren varios cambios en el cálculo en cuestión, este trabajo implicará mucho esfuerzo, lo cual se podría resolver de la forma de reutilización de código que se acaba de mencionar. Proceso de Producción de Software en una Empresa 45