MODELOS DE PROCESO DE SOFTWARE

             CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

1.   MÉTODO DEL CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS.

Comienza cuando la administración o algunos miembros del personal encargado de desarrollar sistemas, detectan un sistema de la empresa que necesita mejoras.

En criterio personal, puedo considerar que no sólo es necesario para sistemas ya existentes, también puede aplicarse para nuevos proyectos en los cuales se conozcan con claridad los requerimientos.

Requerimientos del sistema de información predecibles: se utiliza para sistemas en los cuales sus requerimientos se pueden determinar por inspecciones simples o no muy complicadas;

Manejable como proyecto: ¿?.

Requiere que los datos se encuentren en archivos y base de datos: es decir, que ya existan datos de procesos del sistema. Puede ser que el sistema exista como tal de forma manual, y existan datos ya almacenados en documentos físicos;

Gran volumen de transacciones y procesamiento: cuando los datos a procesar son muy grandes.

Requiere de la validación de los datos de entrada: que los datos suministrados entren con una máscara o formato adecuado.

Abarca varios departamentos: un ejemplo pueden ser el departamento de producción, ventas o facturación, compras, etc. Si se quiere hacer un proyecto en uno de los departamentos, es posible que este afecte alguno de los otros departamentos, por lo cual lo convierte en un método adecuado para ese tipo de proyecto.

Tiempo de desarrollo largo: se utiliza para proyectos que pueden llegar a durar más de un año en su desarrollo y puesta en marcha. Podemos considerar que para un proyecto de dos a tres meses tal vez no se ajuste bien.

Desarrollo por equipos de proyecto: por ser software demasiado grande, por el tiempo quizás no sea posible realizarlo por un grupo pequeño, lo que requerirá la formación de varios grupos de proyectos con actividades diferentes.

Quizás parte de proyectos estén ya en el desarrollo cuando otras se encuentren en el análisis.

Se inicia con la petición de una persona que puede ser un administrador, empleado o especialista en sistemas. A partir de aquí pasa a los siguientes puntos:

A.     INVESTIGACIÓN PRELIMINAR.

i.    Aclaración de la solicitud.

Debe realizar una aclaración de qué es en realidad lo que el usuario quiere. Muchas veces el propio usuario no comprende lo que se quiere es preciso realizar una aclaración, lo que puede generar una cita personal o por medio de una llamada telefónica.

ii.   Estudio de factibilidad.

Qué tan factible se el desarrollo de software, para lo cual se analizan lo siguiente:

1.   Factibilidad técnica.

Uno sería el equipo para el proyecto, si es el adecuado o se necesita integrar mayor personal, como también si es necesaria una capacitación.

La tecnología de software es la adecuada, en caso contrario cual sería la adecuada y si el personal se encuentra capacitado para ella. Las tecnologías de software adecuadas para un proyecto deben ser dadas por las personas que se consideran Arquitectos.

Arquitecto: para el desarrollo de software, podemos considerar que es el que define cuales son las tecnologías que se deben definir para una aplicación. Es por eso que el arquitecto debe andar investigando que aplicativos salen al mercado, para escoger el que mejor se ajuste a las necesidades.

2.   Factibilidad económica.

Como todo software, su desarrollo representa un costo, costo que con el tiempo se debe ver reflejado en ganancia. Si el beneficio generado en un tiempo determinado es positivo, podríamos considerar conveniente la realización. En caso que el costo sea mayor que el beneficio, no es conveniente su desarrollo.

Sobre si existe dinero para el proyecto, eso se da en la aprobación de la solicitud.

3.   Factibilidad operacional.

Ver sí por parte de los usuarios se llevará acabo un uso por el software a realizar, si no lo vas a utilizar, para que lo desarrollas.

Es muy común en los proyectos recibir un poco de resistencia para la utilización del nuevo proyecto. Considero que esa responsabilidad la debe tomar también la administración y buscar medidas para que el uso sea utilizado.

iii.  Aprobación de la solicitud.

Dos términos, deseable y factibles.  Muchos proyectos son solicitados para su desarrollo, pero sólo los más importantes son los que se realizan. Por lo cual la administración debe tomar ese paso.

Cuando ya se haya aprobado, se debe estimar su costo, aunque ya eso lo debe tener la administración para poder establecer la prioridad a ejecutar de todos los que estén. También se debe después de la aprobación estimar el tiempo como las necesidades del personal. Con esta información la administración puede asignarle un orden de prioridad de todos los que existen.

Referente al tiempo, la mayor parte de los proyectos presentan problemas en el cronograma, lo que genera muchas veces el doble de tiempo de lo que se planeó. Esto puedo darse muchas veces por no realizar un análisis y diseño adecuado.

En conclusión: costo + tiempo + necesidades del personal y otras = posibilidad de ubicar el proyecto en una lista ordenado por prioridades.

B.      DETERMINACIÓN DE LOS REQUERIMIENTOS DEL SISTEMA.

Es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras. El estudio da una evaluación que me permite ver los métodos utilizados y si es necesario realizar ajustes.

Es esta etapa es muy importante tener comunicación constante con los empleados o los expertos en los procesos, ya que son ellos los que nos proporcionan los requerimientos.

Se deben realizar preguntas o consultas a lo expertos en los procesos, que nos permitan obtener opiniones sobre por qué ocurren las cosas, soluciones que ellos proponen e ideas para cambiar el proceso, si lo consideran. Esto se pueden dar mediante lo siguiente: cuestionarios, entrevistas, revisión de manuales y reportes existentes.

Con la información obtenida, el analista puede ver cuales son las características que tendrá el nuevo sistema.

C.     DISEÑO DEL SISTEMA.

Aquí se realiza el diseño lógico más no el físico que es el que se refiere al desarrollo del mismo.

No es más que los detalles que permitirán que el nuevo sistema cumpla con los requerimientos obtenidos en la etapa de análisis.

Podemos identificar o diseñar los reportes, formularios, base de datos, “procedimientos, funciones”, etc. Para ello se pueden utilizar cierto tipo de herramientas que nos permiten realizar ese diseño, por ejemplo, en la base de datos podíamos utilizar a DBDesigner que nos permite crear un modelo relacional de la base de datos a utilizar. En los formularios o formas, podemos utilizar un procesador de texto o imágenes que nos ofrezca facilidad, como también podemos utilizar el mismo Framework, tomando fotos a las pantallas.

La información terminada en esta etapa, debe pasar a la siguiente.

Durante el desarrollo, son los de Diseño de Sistema los encargados de responder cualquier pregunta sobre el diseño.

D.     DESARROLLO DE SOFTWARE.

Estos son los encargados de instalar el software cuando se ha comprado a tercero, o al desarrollo si se considera conveniente.

Se suele en empresas grandes tener un grupo dedicado al desarrollo, aunque también en ciertos casos considerarán conveniente contratar a terceros.

En empresas pequeñas es más común que contraten a tercero que compren software ya empaquetados.

Los programadores son responsables, cuando sea necesario, como funciona el código fuente.

También son responsables de la documentación, es decir del manual de sistema e incluso el manual de usuario.

E.      PRUEBA DE LOS SISTEMAS.

Es el proceso mediante el cual se usa de manera experimental con el objetivo de encontrar problemas. En muchos casos se prueba con varios usuarios, e incluso se hace simulaciones de uso para probar como se desempeña con un número grande de usuarios consultando.

Los encargados de realizar las pruebas son personas ajenas a los desarrolladores, ya que puede darnos una mayor satisfacción.

Una prueba se considera satisfactoria, sólo cuando encuentra errores.

Dos pruebas de software conocidas son la de la Caja Blanca y la de la Caja Negra. La primera se encarga de realizar una inspección línea a línea del código fuente, algo que muchas veces resulta tedioso y puede llegar a demorar más de lo esperado. La prueba de la Caja Negra, es la encargada de ver los resultados arrojados por los formularios, es la prueba de software más utilizada.

Es recomendable si se manejan los Try … Cath … Exceptions, mandar mensajes que permitan identificar el procedimiento y formulario utilizado, esto con el objetivo que cuando el usuario encargado de realizar la prueba, o la persona que ya se encuentra en su uso definitivo, informe del error con datos que nos permitan resolver el problema con un menor esfuerzo en encontrarlo.

F.      IMPLANTACIÓN Y EVALUACIÓN.

Es el proceso de instalar el nuevo equipo (en caso necesario), entrenar a los usuarios, entrenar a los usuarios, instalar la aplicación, la base de datos y construir todos los archivos de datos necesarios para utilizarla como su configuración.

Se recomienda dejar el software trabajando en paralelo con el viejo sistema (no importa si se llevaba de forma manual), esto con el sentido de ir comparando los datos, lo que podemos considerarla también una prueba de sistema a largo plazo.

Se considera la implantación un proceso de constante evolución, debido a que involucra el mantenimiento y las actualizaciones que surjan durante el tiempo de vida del software en la empresa.

Desafortunadamente la evaluación del sistema no siempre recibe la atención que merece, pero si se realiza como debe ser, puede  darnos datos que nos ayuden a mejorar el programa.

La Evaluación se utiliza para identificar puntos débiles y fuertes. Ocurre en las siguientes dimensiones.

i.    Evaluación operacional.

Facilidad de uso, tiempo respuesta: qué tan fácil es el uso de una opción, por ejemplo, la forma de insertar imágenes en las diferentes versiones de Word.

Lo adecuado de los formatos de información: si los reportes o el estilo de los datos son los adecuados, o se están almacenando datos en un formato no adecuado. Puede ser por ejemplo, el número de decimales a utilizar, el símbolo empleado para la separación de miles o decimales, los formatos de fecha, etc. Otro ejemplo puede ser el archivo plano que suelen enviar las empresas a las entidades bancarias con el objetivo de pagar el sueldo a sus empleados, ya que los datos deben tener un orden adecuado impuesto por el banco.

Confiabilidad global: qué tan confiable son los datos, en caso negativo se debe hacer las correcciones necesarias.

Nivel de utilización: en algunos programas se almacena de forma automática, el número de pulsaciones hechas a cada opción, con el objetivo de ver cual es la razón del no uso de estas. Muchas veces realizan un movimiento del botón a otra parte del formulario, y comparan después de un tiempo determinado, si el uso ha aumentado.

ii.   Impacto organizacional.

Impacto competitivo: cómo ha mejorado el nivel competitivo de la empresa con relación a las demás.

Impacto interno y externo del flujo de información: la información, que es como la sangre para las organizaciones, que tanto ha mejorado ese flujo.

Eficiencia operacional: si los recursos internos que se necesitaban para realizar las funciones, es menor con el nuevo sistema.

Beneficios de la organización en áreas como costos, ingresos y ganancias: que ganancias ha generado en los costos e ingresos. Es decir, si los costos son menores.

iii.  Opinión de los administradores.

Actitud de los administradores y usuarios acerca del software.

iv.  Desempeño del desarrollo.

Evaluación del desarrollo en aspectos tales como el tiempo y esfuerzo concuerdan con los estándares (lo que se consideró).