Informática Aplicada a la Gestión Pública.   Facultad de Derecho

1. Ejemplo esquemático de informatización de una empresa

Puntos a considerar:

- Sector de actividad

- Situación actual

- Necesidades de "software"

- Necesidades futuras de "software"

- Equipos industriales en uso

- Nuevas tecnologías en equipos

- Ordenadores comerciales que se precisan

- Ordenadores industriales que se precisan

- Personal que va a manejar los equipos

- Personal que va a mantener los equipos

- Acceso por parte de los clientes

Se toma como ejemplo una nueva industria de productos con base en la harina de maíz, y según costumbres y recetas de países latinoamericanos. El objetivo es la fabricación y venta tanto al por mayor como al público en el sureste de España.

Sector de actividad: alimentación, un sector con muchas empresas pequeñas, aunque el mayor volumen de ventas lo consiguen unas pocas grandes empresas.

Situación actual: se parte de la creación de la empresa, por parte de dos socias latinoamericanas, Marisol, colombiana experta en asuntos de panadería, sobre todo con harinas; y doña Cielito Lindo, experta socióloga y politóloga, además de sus amplios conocimientos como adivina especializada en tarot, entre otras muchas maguferías. Marisol aporta sus amplios concomientos en harinas, así como en riesgos profesionales (debido a sus estudios de Terapia Ocupacional), mientras que doña Cielito lindo aporta su gran experiencia en mercadeo (marketing) sobre todo en catas de productos alimenticios, además dadas sus grandes dotes de adivina, se sabrá siempre como actuar en la empresa, pues de antemano sabremos que errará en sus predicciones al 100%. Otra característica a considerar es que esta socia también es una teleadicta (por motivos sociológicos) de ls programas "basura" de las cadenas de televisión españolas y una gran jugadora a las cartas en el entorno Windows.

Necesidades de software: en principio son amplias las necesidades, seguidamente se indican

Programa de gestión económica
Programa de gestión de almacén
Programa de gestión de ventas al por mayor
Programa de terminales punto de vanta (TPV) para venta al público
Programa de gestión de nóminas
Programa de gestión de los equipos industriales
Programa de desarrollo de la gestión de página web y ventas por internet
Programa de gestión de comunicaciones entre los diversos puntos de la empresa


Necesidades futuras de "software": dado que es un sector sin previsión de grandes cambios, en este apartado no se contempla variación en los próximos cinco años.

Equipos industriales en uso: dado que la empresa es de nueva creación, todo el equipamiento es nuevo, recién adquirido, consta de:

- Cámara frigorífica
- Mezcladora de harinas
- Amasadora de harinas
- Sistemas de pesado
- Horno de flujo contínuo con extrusión
- Horno convencional
- Empaquetadora en envases de plástico
- Envadora en cajas

Nuevas tecnologías en equipos: dado que la conservación de alimentos es esencial si se desea vender fuera de la zona de producción, se propone la compa de equipamiento moderno para en un futuro envasar los productos con tecnologías de conservación innovadoras. Lo cual puede servir de ventaja sobre la competencia, por ejemplo con el lanzamiento del revolucionario producto ArepaUHP.

Ordenadores comerciales que se precisan: En función de la implantación de la empresa las necesidades serán variables, por lo que se considera inciar la actividad con una fábrica y una tienda de venta al público, además de una red de pequeños comercios que distribuirían la mayor parte de la producción. De forma que en principio se considera adecuado disponer de cuatro equipos de sobremesa, conectados en red y con una impresora de agujas y una láser color. Se eligen ordenadores compatibels con el estándar del mercado, con microprocesador Pentium, montados por Blas Romero de la empresa Inforsureste. EL sistema operativo elegido es Suse Linux 11. También se precisa un ordenador portátil, se elije un Fujitsu-Siemens Lifebook, con sistemas operativos Windows XP y Suse Linux 11.

Ordenadores industriales que se precisan: dado que en el proceso habitual de eleboración de los productos de la empresa intervienen ordenadores ubicados en ambientes agresivos, se precisan ordenadores industriales con homologación IP65 como mínimo. Se seleccionan de la marca Komtron, compatibles con el estándar del mercado y con sistemas operativos Linux y Windows CE.

Programa de terminales punto de vanta (TPV) para venta al público: por motivos de fiablidad y servicio se seleccionan las TPV marca IBM.

Personal que va a manejar los equipos: Las personas que van a manejar los equipos tiene distintos niveles de cualificación:

Los comerciales no tienen casi idea de informática, por lo que rpecisan formación básica y específuca de los programas que van a usar. En la fábrica se encuentran dos técnicos de grado medio con conocimientos suficientes, por lo que sólo será preciso un curso específico sobre los programas que gestionan la maquinaria.

El personal de contabilidad y gestión de almacen ya tiene conocimientos, por lo que no necesitan ampliarlos.

Personal que va a mantener los equipos: dado que la emrpesa es de pequeña dimensión, el mantenimiento se subcontratará.

Acceso por parte de los clientes: como la empresa está orientada hacia los productos nuevos en España, es fundamental la presencia en internet, no sólo bajo la vertiente puramente comercial, sino para efectuar ventas al público en general y también para el Comercio B2B. Así que se hace imprescindible el disponer de una página web, con variso niveles de acceso. Dada la envergadura del proyecto y además los elevados requisitos de seguridad que se precisan se subcontratará la creación y mantenimeinto de la página web.

Una vez estructurado todo lo necesario, se ha de usar una metodología de desarrollo, como ejemplo se citan seguidamente las más habituales:

2. Metodologías de desarrollo en Ingeniería del Software

El software es un elemento lógico, por lo que tiene unas características muy diferentes a las del hardware:

• El software se desarrolla, no se fabrica en el sentido clásico de la palabra. Ambas actividades se dirigen a la construcción de un "producto", pero los métodos son diferentes. Los costes del software se encuentran en la ingeniería, esto implica que los proyectos no se pueden gestionar como si lo fueran de fabricación. A mediados de la década de 1980, se introdujo el concepto de "fábrica de software", que recomienda el uso de herramientas para el desarrollo automático del software.


• Si se representa gráficamente la proporción de fallos en función del tiempo, para el hardware se tiene la figura conocida como "curva de bañera". Al principio de su vida hay bastantes fallos (normalmente por defectos de diseño y/o fabricación), una vez corregidos se llega a un nivel estacionario (bastante bajo). Sin embargo conforme pasa el tiempo, aparecen de nuevo, por efecto de: mala calidad, suciedad, malos tratos, temperaturas extremas y otras causas. El hardware empieza a estropearse.


• El software no se estropea. La gráfica de fallos en función del tiempo, tendría forma de caída desde el principio, hasta mantenerse estable por tiempo casi indefinido. El software no es susceptible a los males del entorno que provocan el deterioro del hardware. Los efectos no detectados harán que falle el programa durante las primeras etapas de su vida, sin embargo una vez corregidas, no se producen nuevos errores. Aunque no se estropea, si puede deteriorarse. Esto sucede debido a los cambios que se efectúan durante su vida.


• Cuando un componente hardware se estropea, se cambia por otro que actúa como una "pieza de repuesto", mientras que para el software, no es habitual este proceso, lo cual significa que el mantenimiento de los programas es muy complejo.


• La mayoría del software se construye a medida, en vez de ensamblar componentes previamente creados. Por contra en el hardware se dispone de todo tipo de circuítos integrados, para fabricar de manera rápida un equipo completo. Los ingenieros de software no disponen de esta comodidad, aunque ya se están dando los primeros pasos en esta dirección, que facilitaria tanto el desarrollo de aplicaciones informáticas.

La formalización del proceso de desarrollo se define como un marco de referencia denominado ciclo de desarrollo del software o ciclo de vida del desarrollo del software o ciclo de vida del desarrollo. Se puede describir como, "el período de tiempo que comienza con la decisión de desarrollar un producto software y finaliza cuando se ha entregado éste", e incluso es habitual que se incluya el mantenimiento a lo largo de toda la vidad útil. Este ciclo, por lo general incluye las fases:

• Requisitos
  
• Diseño
  
• Implantación
  
• Prueba
  
• Instalación
  
• Aceptación
  
• Mantenimiento
  

En la siguiente figura cada área está asociada a una actividad específica del desarrollo, y se le asigna un porcentaje de incidencia (que suele variar en cada caso) en el costo del desarrollo que corresponde al número en ella inscrito. El área designada operaciones comprende las actividades comúnmente asociadas al desarrollo de sistemas de información administrativos, mientras que el resto corresponde a actividades asociadas al desarrollo de software como producto.



El ciclo de desarrollo software se utiliza para estructurar las actividades que se llevan a cabo en el desarrollo de un producto software. A pesar de que no hay acuerdo acerca del uso y la forma del modelo, este sigue siendo útil para la comprensión y el control del proceso.

Seguidamente se exponen las distintas aproximaciones de desarrollo de software, en función del tipo de ciclo de vida:

A) Aproximación convencional

Se introdujo por Winston Royce en la década de 1970, como una técnica rígida para mejorar la calidad y reducir los costos del desarrollo de software. Tradicionalmente es conocido como "modelo en cascada", porque su filosofía es completar cada paso con un alto grado de exactitud, antes de iniciar el siguiente.

Esquemáticamente se puede representar de la siguiente forma, con las siguienets etapas:

FACTIBILIDAD: Definir un concepto preferente para el producto de software y determinar su factibilidad de ciclo de vida y superioridad frente a otros conceptos.

REQUERIMIENTOS: Elaborar una especificación completa y validada de las funciones requeridas, sus interfaces y el rendimiento del producto de software.

DISEÑO: Elaborar una especificación completa y validada de la arquitectura global hardware-software, de la estructura de control y de la estructura de datos del producto, así como un esquema de los manuales de usuarios y planes de test.

DISEÑO DETALLADO: Elaborar una especificación completa y verificada de la estructura de control, de la estructura de datos, de las interfaces de relación, dimensionamiento y algoritmos claves de cada componente de programa (rutina con un máximo de 100 instrucciones fuentes).

CODIFICACION: Construir un conjunto completo y verificado de componentes de programas.

INTEGRACION: Hacer funcionar el producto de software compuesto de componentes de programa.

IMPLEMENTACION: Hacer funcionar el sistema global hardware-software incluyendo conversión de programas y datos, instalación y capacitación.

OPERACION Y MANTENCION: Hacer funcionar una nueva versión del sistema global.

TRANSICION: Realizar una sucesión limpia de este a otros eventuales productos.

En cada caso, "verificación" tienen la acepción: establecer la verdad de la correspondencia entre un producto de software y su especificación. Es decir: ¿ESTAMOS CONSTRUYENDO CORRECTAMENTE EL PRODUCTO?

Los principales problemas que se han detectado en esta aproximación son debidos a que se comienza estableciendo todos los requisitos del sistema:

• En muchas ocasiones no es posible disponer de unas especificaciones correctas desde el primer momento, porque puede ser difícil para el usuario establecer al inicio todos los requisitos.
  
  
• En otras hay cambio de parecer de los usuarios sobre las necesidades reales cuando ya se ha comenzado el proyecto, siendo probables los verdaderos requisitos no se reflejen en el producto final
  
  
• Otro de los problemas de esta aproximación es que los resultados no se ven hasta muy avanzado el proyecto, por lo tanto la realización de modificaciones, si ha habido un error, es muy costosa.
  

Esta aproximación es la más empleada por los ingenieros informáticos, aunque ha sido muy criticada, y de hecho se ha puesto en duda su eficacia. Entre los problemas que se pueden encontrar con este modelo, se tienen:

• Los proyectos raras veces siguen el modelo secuencial que se supone. Los cambios pueden causar confusión.
  
  
• Es difícil disponer en principio de todos los requisitos. Este modelo presenta dificultades en el momento de acomodar estas incertidumbres.
  
  
• La versión operativa de los programas no está disponible hasta que el proyecto está muy avanzado. Un error importante puede ser desastroso, si se descubre al final del proceso.
  
  
• Los responsables del desarrollo siempre se retrasan innecesariamente. Algunos integrantes del equipo de desarrollo han de esperar a otros para completar tareas pendientes.
  

B) Aproximación prototipo

Es habitual que en un proyecto software no se identifiquen los requisitos detallados de entrada, procesamiento o salida. En otros casos no se está seguro de la eficiencia de un algoritmo, o de la forma en que se ha de implantar la interface hombre-máquina.

En casos así, lo habitual es construir un prototipo, que idealmente sirviera como mecanismo para identificar los requisitos del software. Esta aproximación consiste en realizar la fase de definición de requisitos del sistema en base a estos tres factores:

• Un alto grado de iteración
  
• Un muy alto grado de participación del usuario
  
• Un uso extensivo de prototipos
  

Las premisas clave de esta aproximación son:

• Que los prototipos constituyen un medio mejor de comunicación que los modelos en papel
  
  
• Que la iteración es necesaria para canalizar, en la dirección correcta, el proceso de aprendizaje. Esta aproximación se enfoca a mejorar la efectividad del proceso de desarrollo y no a mejorar la eficacia de ese proceso.
  
  
• El problema, es que los usuarios finales, ven lo que parece ser una versión de trabajo del software, sin considerar que no es la versión definitiva y por lo tanto no se han considerado aspectos de calidad o facilidad de mantenimiento. Cuando se les dice, que el producto es a partir de entonces cuando se debe de empezar a "fabricar", no lo entiende y empieza de nuevo con ajustes, lo cual hace este proceso muy lento.
  

C) Aproximación evolutiva

En esta aproximación el énfasis está en lograr un sistema flexible y que se pueda expandir de forma que se pueda realizar muy rápidamente una versión modificada del sistema cuando los requisitos cambien.

Se diferencia de la aproximación anterior, en que en esta los requisitos cambian continuamente, lo cual implicaría en el caso previo que las iteraciones no tendrían fin.



D) Aproximación incremental

Es un concepto muy parecido al de desarrollo evolutivo, y frecuentemente comprendido en la aproximación del desarrollo evolutivo. Se comienza el desarrollo del sistema para satisfacer un subconjunto de requisitos especificados. Las últimas versiones prevén los requisitos que faltan. De esta forma se logra una rápida disponibilidad del sistema, que aunque incompleto, es utilizable y satisface algunas de las necesidades básicas de información.

La diferencia con la aproximación anterior es que en este caso cada versión parte de una previa sin cambios pero con nuevas funciones, mientras que la aproximación evolutiva cada vez se desarrolla una nueva versión de todo el sistema.

Un ejemplo de este paradigma se tiene en el desarrollo de una aplicación sencilla, como es un editor de textos. En el primer incremento se podría desarrollar con un reducido conjunto de funciones, como las funciones básicas de gestión de archivos. En un segundo incremento, se puede incluir la gestión avanzada de textos. Y en un tercer incremento se pondría la corrección ortográfica.

E) Aproximación espiral

Nace con el objetivo de captar lo mejor de la aproximación convencional y de la de prototipo, añadiendo un nuevo componente, el análisis de riesgos.


Esquemáticamente se puede ilustrar mediante una espiral, con cuatro cuadrantes que definen actividades.

En la primera vuelta de la espiral se definen los objetivos, las alternativas y las restricciones y se analizan y se identifican los riesgos. Si como consecuencia del análisis de riesgo se observa que hay incertidumbre sobre el problema entonces en la actividad correspondiente a la ingeniería se aplicará la aproximación prototipo cuyo beneficio principal es el de reducir la incertidumbre de la naturaleza del problema de información y los requerimientos que los usuarios establecen para la solución a ese problema.

Al final de esta primera vuelta alrededor de la espiral el usuario evalúa los productos obtenidos y puede sugerir modificaciones. Se comenzaría avanzando alrededor del camino de la espiral realizando las cuatro actividades indicadas a continuación. En cada vuelta de la espiral, la actividad de ingeniería se desarrolla mediante la aproximación convencional o ciclo de desarrollo en cascada o mediante la aproximación de prototipos.

• Actividades
  
  
• Acciones
  
  
• Planificación Determinación de alternativas, identificación y resolución de riesgos
  
  
• Ingeniería
  
  
• Desarrollo y verificación del producto de siguiente nivel
  
  
• Evaluación del cliente
  
  
• Valoración de los resultados del proceso de desarrollo
  

F) Aproximación basada en transformaciones

Con la aparición de las herramientas CASE junto con los generadores de código, el ciclo de desarrollo software en cascada ha cambiado a un ciclo de vida basado en transformaciones.

CASE (Computer Aided Software Engineering), en castellano "Ingeniería de software Asistida por Computadora", es un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información.

La utilización de herramientas CASE afecta a todas las fases del ciclo de vida del software. Este ciclo de vida se puede considerar como una serie de transformaciones. Primero se definen los requisitos del sistema, seguidamente existe un proceso de transformación que hace que la especificación se convierta en un diseño lógico del sistema. Posteriormente, este sufre otro proceso de transformación para lograr un diseño físico, es decir que responda a la tecnología destino.

La tecnología CASE propone que estos procesos de transformación sean lo más automatizables posible. Sus ventajas son:

• Posibilidad de comprobación de errores en etapas iniciales de desarrollo
  
  
• Posibilidad de realizar el mantenimiento en el ámbito de especificación
  
  
• Soporte de rastreabilidad de los requisitos
  
  
• Soporte de reusabilidad
  
  
• Potencia la especificación orientada al problema
  
  

G) Programación extrema

La Programación Extrema (PX), mejor conocida por su nombre en inglés "Extreme Programming" (XP), es una de las llamadas Metodologias Agiles de desarrollo de software más exitosas de los tiempos recientes. Cada día se genera incontable información sobre el tema, generalmente en inglés; fue formulada por Kent Beck, autor del primer libro sobre la materia,"Extreme Programming Explained: Embrace Chang".

Los aspectos fundamentales del método son:

• Desarrollo iterativo e incremental
• Pruebas unitarias continuas,
• Programación por parejas de personas
• Frecuente interacción del equipo de programación con el cliente
• Corrección de todos los errores antes de añadir nueva funcionalidad.
• Refactorización del código
• Propiedad del código compartida
• Simplicidad en el código

Un ejemplo de un caso en el que se aplicó esta metodología fue en la identificación mediante el ADN de las víctimas del atentado del 11 de septiembre de 2001 en Nueva York (EE.UU.)