“Los proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniería tradicional en la naturaleza lógica del producto software.
Recordemos que el software se desarrolla, no se fabrica en un sentido clásico. En todos los proyectos de ingeniería la buena calidad se adquiere mediante un buen diseño, pero en el caso del software, la etapa de construcción incide pobremente en su calidad, no así en la construcción de hardware o de una obra civil. Otra diferencia es que el software no se estropea, el paso del tiempo o males del entorno no inciden en el aumento de la tasa de fallas.
Así, no se puede gestionar un proyecto de desarrollo de software como si se tratara de un proyecto de fabricación.
La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software, porque cubre todo el proceso de desarrollo. Para conseguir un proyecto de software fructífero se debe comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir.”
Para lograr determinar claramente las bases, trataremos de analizar los pasos de una forma consecuente, que nos permita un mayor entendimiento del objeto de esta investigación, iniciando con la determinación de los requerimientos de unos sistemas, alcanzados mediante la interacción con el usuario hasta la documentación final e implementación del mismo.
Análisis y determinación de los Requerimientos
Es una de las etapas más importantes a la hora de desarrollar software, pues en esta se definen las utilidades del software y se pretende identificar las necesidades del usuario, para de esta forma satisfacerlas.
La tarea de obtener los requerimientos puede parecer bastante sencilla, sin embargo, la tarea de interactuar con el usuario, comprenderlo puede resultar bastante complejo, no entender exactamente lo que quiere un usuario puede llevarnos a fracasar en el proyecto.
En esta etapa se realizan observaciones, entrevistas, y evaluaciones del sistema anterior. Para poder crear un software o un nuevo sistema, tenemos que conocer a cabalidad el sistema que se usa actualmente, tomando en cuenta todos los problemas que se dan y cuáles son las dificultades de este; para posteriormente presentar una idea que solucione todos los contratiempos que se dan actualmente. Por lo tanto, solamente vamos a poder desarrollar un producto de calidad, si conocemos el sistema con el que se viene trabajando hasta el momento. Reconocer los problemas y darles solución.
La IEEE separa el análisis de los requerimientos en dos:
Funcionales
Son los requerimientos que van ligados a las funcionalidades del software, le dan la utilidad.
No Funcionales
Son todos los requerimientos que no son cruciales para el funcionamiento del software, o pueden variar, generalmente son detalles como de interfaz. No significa que los requerimientos no funcionales no sea importantes, porque un programa con una mala interfaz no es bien aceptada por el cliente. Pero estos requerimientos no forman parte de las funciones del software.
Por ejemplo, en un sistema contable, un requerimiento funcional sería registrar los asientos diarios, mientras que un requerimiento no funcional puede ser tener una barra de menú para ver las opciones de forma ordenada.
La labor de identificar los requerimientos debe estar muy ligada al usuario, y es un proceso en el cual se van refinando poco a poco, hasta poder tener una visión clara de las necesidades del cliente, así como lo que debemos hacer para desarrollar el software.
Es importante que lo requerimientos y especificaciones técnicas sean aprobadas por el usuario, de modo que estemos seguros de ir por buen camino.
En esta etapa de análisis se debe hacer todo lo posible por encontrar discrepancias con el usuario, como pantallazos sin funcionalidad y hasta manuales de usuario, para que este vea desde su perspectiva como funcionará el software, esto evitará que en una etapa avanzada del desarrollo nos demos cuenta de que eso no era lo que quería el usuario.
Proceso de Diagramación
Una vez, que hemos logrado obtener las necesidades reales del cliente o usuario, mediante la interacción con el mismo o revisando la documentación propia del negocio, procedemos a plasmarlo mediante diferentes diagramas que nos ayuden a comprender no solo la lógica del negocio sino como lo podemos convertir en un software.
Diagramas de Gestión del Negocio
Los diagramas de Gestión del Negocio son los que nos permiten abstraer el problema al cual deseemos desarrollar un software, al punto de una descomposición total, con el objetivo comprender a cabalidad un sistema y así evitar posibles errores de interpretación.
Diagramas de Flujos de Datos
Es una técnica gráfica mediante la cual describimos el flujo de la información y la transformación de los datos. Los DFD son ideales para lograr una compresión esquematizada del funcionamiento del negocio, sin la necesidad de plantearlo como un sistema.
Gracias a estos diagramas, logramos tener una mayor claridad de la lógica del negocio objeto del diseño de software, lo que a la larga nos puede significar evitarnos malas interpretaciones de la gestión del negocio y asi brindar un producto de software ideal y ajustado a las necesidades del cliente.
En el ejemplo de abajo, podemos observar el DFD del proceso de una solicitud de compra hasta la aprobación para poder iniciar el procedimiento en una sección de proveeduría:
Diagrama de Mandala
Son representaciones gráficas en matrices de tres por tres, cuyo objetivo es abstraer diseños de sistemas y mostrarlos con una secuencia de importancia y orden.
La idea de Mandala es organizar los procesos por importancia, por lo que en el cuadro central, colocaremos el proceso madre o que represente a todos los demás procesos que se ingresen en la matriz, de igual manera los procesos se puede descomponer en nuevas matrices. Para tener una mayor comprensión. Al igual que los DFD logramos tener una mayor claridad de la lógica del negocio objeto del diseño de software y asi optimizar nuestro diseño, gracias a la abstracción que le dimos al problema.
A continuación podemos observar un ejemplo de cómo se estructuro el sistema de compras con los diagramas de Mandala.
Casos de Uso
Es una técnica para plasmar requisitos potenciales de un sistema o una actualización de software. Dichos casos de usos surgen ante situaciones posibles y/o escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.
Los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. Se da con normalidad que se utilice a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. Importante es señalar que los casos de uso no deben representar relaciones entre dos usuarios sino la interacción directa con el usuario.
El ejemplo de abajo representa de manera muy sencilla para representar un posible caso de uso:
Diagramas de Actividad
Un diagrama de actividad es la representación interna (mayor detalle) de un caso de uso, en el cual se trata de representar a detalle toda la actividad que comprende dicho caso de uso.
Se debe usar diagrama de actividad en situaciones donde todos o la mayoría de los eventos representan la finalización de acciones generadas internamente (esto es, flujo de control procedural). Este tipo de diagrama no es adecuado en situaciones donde ocurren eventos asincrónicos.
El ejemplo de abajo podemos observar un ejemplo sencillo de un diagrama de actividad:
Modelos de Bases de Datos
Los modelos de Bases de Datos son métodos que describen en un lenguaje formal la forma en que se estructura la base de datos. En estos se aplican los modelos de bases de aplican los modelos de datos.
Los modelos de bases de datos pueden ser representaciones físicas o lógicas. Dos de los modelos más usados son el modelo entidad relación y el relacional.
Modelo entidad Relación
Es una representación lógica de la base de datos, nos muestra la forma en que se relacionan las diferentes entidades entre sí, el diagrama entidad- relación (E-R) nos sirve como un mapa para ver la forma en que estará estructurada nuestra base de datos.
Modelo Relacional
La construcción de este modelo puede tomar como referencia el modelo E-R, a diferencia del anterior donde solamente se muestra el desarrollo lógico de los datos el modelo relacional contiene los datos, y es el que se ingresa directamente en el Sistema Gestor de Base de Datos.
Diagramas de Diseño y/o Codificación
Cuando hemos superado el proceso del modelado de la base de datos y los diagramas de gestión del negocio, asumimos que nuestra abstracción y entendimiento del sistema actual esta lo más claro posible, es ahí cuando podemos pasar al nivel del diseño de la aplicación, por lo que antes de empezar la codificación se realizan diversos diagramas, con el fin de que el código que se vaya a digitar, tenga un estructura lógica, coherente y fácil de comprender, lo que directamente facilitara el mantenimiento del sistema en un caso futuro.
Diagramas de Clases
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos.
Se implementan durante el proceso de desarrollo del software, con lo que se consigue de alguna forma, lograr una estructura comprensible del código de programación.
Diagramas de Flujos
Ayudan a representar algoritmos mediante diagramas, con lo que se logra descomponer una estructura del programa esquematizándola y obteniendo una mayor representación de la solución.
Una característica importante de los diagrama de Flujo, es que si está completo y correcto, el paso del mismo a un Lenguaje de Programación es relativamente simple y directo.
Estándares y normas de programación
Antes de iniciar la codificación del sistema, es necesario establecer estándares y normas para la programación, ya que por lo general los sistemas nos los codifica una sola persona, obviamente dependiendo del tamaño del software. Es por esta razón que se estable las estructuras básicas de cómo se debe programar, por ejemplo:
Nombre de la entidad/tabla
El NOMBRE_DE_ENTIDAD/TABLA tendrá como máximo 30 caracteres, estará escrito en mayúscula, no se utilizarán tildes, ni “ñ” (si fuera necesario se debe reemplazar por una “n” o “ni”). Si el NOMBRE_DE_ENTIDAD/TABLA está compuesto por más de una palabra se utilizará el carácter raya baja “_” como separador de palabras.
Formato del nombre de la entidad/tabla
El NOMBRE_DE_ENTIDAD/TABLA debe respetar el siguiente formato PREFIJO_NOMBRE:
PREFIJO: Es el código de aplicación, según el Catálogo de Aplicaciones, a la cual pertenece la entidad/tabla.
Nombre del atributo
El NOMBRE_DEL_ATRIBUTO tendrá como máximo 30 caracteres, no se utilizarán tildes, ni “ñ” (si fuera necesario se debe reemplazar por “n” o “ni”). Si el NOMBRE_DEL_ATRIBUTO está compuesto por más de una palabra se utilizará el carácter raya baja “_” como separador de palabras.
Codificación y/o Diseño del Sistema
Sistema Gestor de Base de Datos
Los Sistemas Gestores de Base de Datos o SGBD, son aplicaciones muy específicas dedicadas al manejo y creación de las bases de datos. Los diferentes SGBD nos ayudan en temas como seguridad, integridad y consultan. Algunos breves ejemplos de Gestores de Bases de Datos son:
MySQL
Es un SGBD desarrollado con software libre, pero si se quiere usar en productos privados se debe adquirir una licencias especial. Es compatible con muchos lenguajes de programación. Es ideal para aplicaciones web, por ser muy ágil en las consultas. Es multiplataforma y se dice que tiene conectividad muy segura.
Oracle
Es uno de las SGBD más completos que existen, y hasta hace poco tiempo dominaba el mercado empresarial. Es escalable, multiplataforma, estable y soporta transacciones. Pero es uno de los SGBD más caros del mercado.
Microsoft Access
Es una pequeña aplicación creada por Microsoft para entorno personal o de pequeñas empresas. Es sencillo de usar, y puede ser consultada por otros programas. Permite crear relaciones de tablas, formularios, consultas e informes.
Plataformas de programación
JAVA
Es un lenguaje de programación orientado a objetos, actualmente la mayoría de su librería es software libre, cuenta con tres ediciones, la J2SE para uso estándar de pequeñas aplicaciones, J2ME para aplicaciones móviles, y la J2EE versión para uso empresarial a gran escala. Se dice que es un lenguaje simple, multiplataforma, multihilos y seguro.
C++:
Es un lenguaje de programación bastante conocido y empleado, existen muchos tutoriales en línea para apoyarse a la hora de implementarlo. Pero es un lenguaje muy complejo y no es recomendando en ambiente web.
Microsoft .NET:
Solamente funciona en el sistema operativo de Microsoft Windows, y es de ambiente propietario, se pretende crear un lenguaje de programación que sea rápido y fácil, pero tiene dependencia de la plataforma en la que trabaja.
Aspectos Finales del Software
Documentación
Es este campo, debemos documentar todo al propio desarrollo del software y de la gestión del proyecto, todas las modelaciones y/o diagramas que se hayan hecho, pruebas, manuales de usuario, manuales técnicos, entre otros, todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Cabe destacar que una vez que los sistemas se les ha realizado una correcta documentación, se logra guardar las experiencias de la aplicación, lo cual nos puede permitir en un futuro, reutilizar procesos que ya hayan sido implementados, pero más importante, el hecho de tener documentos que nos describan nuestra experiencia en sistemas anteriores, lo que nos ayudara a diseñar mejores sistemas en el futuro.
Manuales de Usuario
Es una parte clave del sistema, ya que si deseamos desligarnos del usuario, podemos hacerlo con manuales entendibles y que integren en un documento toda la funcionalidad de un sistema. Por su importancia, los manuales no son opcionales en un proyecto de software.
Capacitación
Este proceso, es uno de los más importantes en la hora de la implementación del sistema, ya que se le indicara a los usuarios del sistema la funcionalidad del sistema y como le deben sacar provecho al misma.
Cabe destacar que se puede capacitar a los usuarios finales, los cuales son los que le darán un uso diario y continuo a la aplicación, como a capacitadores, este último punto es de mucha importancia cuando son sistemas que por su tamaño, es más recomendable capacitar a un grupo de personas con cierta facilidad para hacer comprender a los usuarios finales la funcionalidad del sistema.
Consideraciones sobre la Administración del Proyecto; Etapa de Desarrollo del Software.
Parte de las bases del desarrollo de software, es realizar una gestión organizada e integra de los procesos que se vayan a ejecutar en el proyecto, ya que una administración correcta de los recursos, tanto económicos, equipo, personal y todos los demás, nos pueden llevar a una ejecución eficiente y eficaz del software.
Para comprender como funciona la gestión de proyectos en el diseño de software y el cual también es una base muy importante del mismo, se presenta un diagrama en el cual podemos apreciar cómo se ven inmersos directamente los procesos de la gestión de proyectos en el diseño del software.
En el diagrama de abajo, podemos observar esquematizadamente todo lo que hemos descrito en el trabajo, solo que ahora se le incluyen los aspectos de la gestión de proyecto, en donde podemos apreciar la planeación, dirección, control, desarrollo e implementación del los procesos, todos, funciones de un administrador de proyectos, en los que se le hace mucho énfasis en la planeación y control, ya que nos permitirá darle un seguimiento con la oportunidad de corregir posibles errores antes de se hagan más grandes y requieran más trabajo.
Conclusión
A nivel académico muchas veces dejamos de lado muchos aspectos importantes del desarrollo del software, y simplemente nos dedicamos a digitar código. Los cierto es que a nivel profesional debemos tener en cuenta muchos aspectos para crear un sistema de calidad y que cumpla con las expectativas del usuario o cliente.
Etapas tan básicas como una correcta obtención de requerimientos es fundamental, y es parte crucial en el desarrollo de cualquier sistema de información que desee implementar. Una vez cubierta esta etapa, la realización de diagramas nos brindan un panorama completo de la situación y un plano claro de cómo comenzar a construir.
Todo lo que inicia bien termina bien, si cumplimos fielmente todos los pasos necesarios para el desarrollo del software entonces tendremos un producto de calidad que se amolde a las necesidades y exigencias del mercado. Teniendo existo en nuestros proyectos de desarrollo.
