CAPÍTULO 1

CAPÍTULO 1

INGENIERÍA DEL SOFTWARE

En cualquier problema relacionado con la informática en general es necesario considerar dos aspectos fundamentales: el hardware y el software. Aunque ambos se han desarrollado de forma paralela, los problemas que presenta el software en vez de solucionarse se han ido incrementando. Las razones de los mismos son las siguientes:

§ La existencia de un hardware muy sofisticado hace que exista una mayor independencia entre software y hardware dejando atrás la capacidad de construir software que explote de forma eficiente este hardware.

§ Demanda muy elevada del software que resulta insatisfecha.

§ Actividad de mejora y mantenimiento del software insatisfecha también debido a la rápida evolución del entorno.

Para solucionar estos problemas se ha recurrido a la proposición de un conjunto de pautas, reglas, heurísticas, modelos a seguir de forma ordenada y perfectamente registrada en el proceso de desarrollo de software a los que se le han llamado Ingeniería del Software.

Una definición de Ingeniería del Software sería la siguiente:

Una disciplina tecnológica y administrativa dedicada a la producción sistemática de los productos de programación, que son desarrollados y modificados a tiempo, y dentro de un presupuesto definido.

De esta definición podemos obtener los siguientes objetivos:

§ Construir software de calidad.

§ Aumentar la productividad del proceso de desarrollo.

§ Mejorar la satisfacción personal de las personas implicadas.

§ Disminuir costes en producción y almacenamiento.

§ Acabar con las leyendas.

1.1. LA INGENIERÍA DEL SOFTWARE

La ingeniería del software está por delante de la programación clásica desde el punto de vista administrativo (punto que no se tiene en cuenta en la programación clásica).

Sin la realización de un estudio previo de un problema de cierta envergadura ni la planificación del desarrollo de la solución puede que se presenten una serie de problemas que generen un coste mayor del previsto. La IS se encarga de intentar evitar estos imprevistos.

Las diferencias entre software y otros tipos de productos son:

§ El software no se deteriora con el tiempo.

§ El software no se fabrica sino que se desarrolla.

§ El software es algo intangible y difícil de medir o cuantificar, aunque existen algunos parámetros que permiten, de alguna forma, medirlo como pueden ser el número de líneas de código, reusabilidad. . .

§ Si se considera que el software está libre de errores, éste no está sometido a la influencia de su entorno y son las modificaciones a las que se somete las que originan errores.

§ El mantenimiento de un producto software es complejo.

Estas características y otras muchas originan una gran cantidad de problemas en el proceso de desarrollo que se deben resolver, algunos de ellos son:

§ La planificación y estimación de los recursos previstos son muy imprecisos, desbordándose las estimaciones en la mayoría de los casos. (Leyes de Murphy :P)

§ La productividad no se corresponde con las necesidades de los clientes.

§ La calidad de los productos no es la adecuada, llegando al mercado, en muchos casos, con errores.

Estos problemas hacen que sea necesario el uso de procedimientos de IS para el desarrollo software. Por tanto otra definición de IS sería la siguiente:

El establecimiento y uso de principios de ingeniería robustos, orientados a obtener económicamente software que sea fiable y funcione efectivamente sobre máquinas reales.

Se puede apreciar que la IS está formada por tres elementos:

§ Los Métodos:

Suministran información de cómo construir el software, abarcando una gran variedad de actividades como planificación y estimación de costes, análisis de requisitos. . .

§ Las Herramientas:

Sirven de soporte al proceso de producción, suministrando útiles automáticos o semiautomáticos para la ejecución de los métodos.

§ Los Procedimientos:

Nexos de unión entre herramientas y métodos facilitando el desarrollo racional y a tiempo del software. Definen la secuencia en la que se deben aplicar los métodos, la información requerida.

Una nueva definición de IS sería:

Un conjunto determinado de métodos que utiliza un conjunto de herramientas bajo un conjunto de procedimientos.

1.2. PARADIGMAS DE LA INGENIERÍA DEL SOFTWARE

En los últimos años se están desarrollando paradigmas de distintas naturalezas, por lo que el gestor debe elegir el más adecuado para su producto software a desarrollar.

1.2.1. PARADIGMA DEL CICLO DE VIDA CLÁSICO

También denominado Modelo en cascada. El proceso de desarrollo software se realiza en fases secuenciales: una fase comienza cuando la previa ha concluido. Las fases de las que consta son las siguientes:

§ Ingeniería y análisis de sistemas:

Actividad encargada del estudio del sistema global. En esta fase se extraen los requisitos globales a nivel de sistema, las relaciones que mantiene con otros subsistemas y el propio subsistema software es estudiado a un nivel de abstracción elevado.

§ Análisis de requisitos del software:

Fase analista en la que se debe recoger toda la información sobre el software a desarrollar y el problema a solucionar. En esta fase se deberá conocer el dominio de la información que manejará el software, el procesamiento de dicha información, su rendimiento y las interfaces E/S.

§ Diseño:

Etapa en la que se traducen los requisitos recogidos en la fase anterior en una especificación formal especificando estructuras de datos, arquitectura del sistema software, interfaz y procedimientos. En esta fase se crean una serie de documentos que entran a formar parte de la configuración del software.

§ Codificación:

Traducción de las especificaciones formales anteriores a una especificación entendible por el hardware. Si los documentos anteriores son correctos, en esta fase lo único que se realiza es una traducción entre formatos de especificación.

§ Prueba:

Fase cuyo objetivo es verificar que todas las partes del producto software generado en la fase anterior producen una salida adecuada esperada a partir de unos datos de entrada.

§ Mantenimiento:

Un producto software puede necesitar cambios. En esta fase se llevan a cabo dichos cambios, y pueden afectar a cualquiera de las fases anteriores produciendo, por tanto, modificaciones en la documentación.

Éste es el paradigma más ampliamente usado aunque presenta una serie de inconvenientes:

§ Los proyectos raramente siguen este flujo secuencial.

§ Es difícil establecer todos los requisitos en fases muy tempranas del proceso de desarrollo.

§ No se tiene información del producto hasta que no se ha completado el proceso de desarrollo o nos encontramos en las ´ultimas etapas.

1.2.2. PARADIGMA DEL PROTOTIPO

Se construye un prototipo que facilita al ingeniero del software la creación de un modelo del producto a seguir. Este modelo puede tomar las siguientes formas:

§ Prototipo en papel que describa la interacción hombre/máquina.

§ Prototipo operativo que implemente algunas de las operaciones requeridas.

§ Programa que presente toda la información deseada, pero con algunas características a mejorar en el nuevo trabajo de desarrollo.

Etapas y actividades a realizar en este paradigma para el desarrollo software:

§ Recogida y refinamiento de requisitos:

Se realiza por el ingeniero y el cliente y se definen objetivos globales viendo qué áreas van a necesitar una mayor profundización en su análisis.

§ Diseño rápido:

Para representar los aspectos del software visibles para el usuario del producto.

§ Construcción del prototipo:

Diseño de un prototipo del producto que se utiliza para volver a la fase de análisis de requisitos para refinar y ampliar las especificaciones iníciales o realizar un nuevo diseño y construir un nuevo prototipo.

§ Evaluación y refinamiento de requisitos:

Con el prototipo creado se debe optar por:

1. Considerarlo como producto final.

2. Destruirlo total o parcialmente y construir un producto final en base al paradigma clásico en el que algunas fases ya se han desarrollado y otras deberán revisitarse.

VENTAJAS E INCONVENIENTES CON RESPECTO AL MODELO EN CASCADA

Ventajas:

§ El cliente participa de forma activa.

§ El cliente está viendo el producto desde el primer momento.

§ Los productos se adaptan mejor a los subsistemas de las organizaciones donde se van a instalar.

Inconvenientes:

§ El ingeniero deberá controlar la impaciencia del cliente por terminar el producto.

§ Si un prototipo se considera como producto final de forma prematura puede producir un bajo desempeño debido a las restricciones físicas impuestas al crear dicho prototipo.

1.2.3. PARADIGMA EN ESPIRAL

Pretende resolver los inconvenientes de los paradigmas anteriores combinando las características favorables de ellos e incluyendo un nuevo elemento llamado análisis de riesgo. Etapas de las que consta:

§ Planificación:

Se determinan los objetivos o problemas a solucionar, así como las diferentes alternativas para alcanzarlos y las restricciones impuestas.

§ Análisis de riesgo:

Se realiza un análisis de cada una de las alternativas especificadas en la planificación.

§ Ingeniería:

Se lleva a cabo la construcción del producto final gracias a toda la documentación generada en las etapas anteriores.

§ Evaluación del cliente:

El cliente evalúa cada uno de los sistemas que se le van presentando a lo largo del proceso.

Se trata de un modelo en el que se producen una serie de iteraciones cada una con un modelo cada vez más depurado del producto final y en la que se produce un análisis de riesgo precedido por la toma de decisión tras su evaluación consistente en “seguir adelante” o “cancelar el proyecto”.

Este paradigma es el enfoque más realista para el desarrollo software. Presenta las siguientes ventajas:

§ Permite al ingeniero y al cliente conocer los riesgos en cada nivel de evolución del producto.

§ Usa la creación de prototipos para la reducción del riesgo.

§ Mantiene el enfoque sistemático del modelo en cascada pero incorporado en un proceso iterativo.

§ Requiere una consideración directa de los riesgos, lo que permite descubrir posibles errores o riesgos.

1.2.4. PARADIGMA DRA (DESARROLLO RÁPIDO DE APLICACIONES)

Modelo de desarrollo software lineal secuencial que enfatiza un ciclo de desarrollo estrechamente corto mediante un enfoque de construcción basado en componentes.

Si se utiliza para aplicaciones de sistemas de información se considerará las siguientes fases:

§ Modelado de gestión.

§ Modelado de datos.

§ Modelado de proceso.

§ Generación de aplicaciones.

§ Pruebas y entrega.

Si se considera una aplicación de gestión de manera que pueda completar cada una de sus funciones componentes en menos de tres meses, consideraremos que es un candidato a aplicarle el DRA.

Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un sólo modelo conjunto.

Desventajas:

§ Para proyectos grandes requiere un gran número de recursos.

§ Requiere un fuerte compromiso tanto por los desarrolladores como por los clientes para realizar las rápidas actividades.

§ Necesita sistemas modularizables y que no posean altos riesgos técnicos.

1.2.5. PARADIGMA INCREMENTAL

Modelo que se acomoda a un producto que evoluciona con el tiempo.

Combina elementos del modelo secuencial lineal con la filosofía iterativa de construcción de prototipos. Cada secuencia lineal produce un incremento en el nivel de desarrollo software.

Fases de que consta:

1. Un primer incremento en el que se diseña un producto esencial en el que se considera un mínimo de requisitos básicos.

2. El cliente evalúa el trabajo realizado y o lo considera como producto final y aquí acaba el ciclo, o decide realizar un refinamiento del mismo y se continúa.

3. Se desarrolla un plan para el incremento siguiente, se lleva a cabo y se vuelve al paso dos.

Presenta una diferencia con el modelo en prototipo y es que se produce una entrega del producto en cada incremento.

Es un desarrollo útil cuando la dotación de personal es insuficiente para una implementación completa en la fecha establecida como límite de finalización.

1.2.6. COMBINACIÓN DE PARADIGMAS

En la mayoría de las ocasiones los paradigmas deben combinarse para aprovechar las ventajas que cada uno de ellos ofrece.

En todos los casos el proyecto comienza con la determinación de los objetivos, alternativas y restricciones (recolección de requisitos).

Si la información es completa y el sistema se puede especificar completamente se usará el modelo en cascada. Si los requisitos son inciertos se podrá usar el modelo del prototipo para el desarrollo de un prototipo que podrá evolucionar al ciclo de vida clásico en la etapa de prueba. Además pueden ser usados las T4G. En cualquier caso el desarrollo software comprenderá tres fases genéricas:

§ Fase de definición:

Se centra sobre el QUÉ, es decir, en intentar identificar la información que ha de ser procesada, la función y el rendimiento que se desea, las interfaces, las restricciones de diseño y los criterios de validación.

Generalmente esta fase se compone de tres actividades:

1. Análisis del sistema: Define el papel de cada elemento del sistema.

2. Planificación del proyecto: Se realiza el análisis de riesgo asignando recursos, estimando costes, definiendo tareas a realizar. . .

3. Análisis de requisitos: Se describe el ámbito del software, la información requerida, su procesamiento y su objetivo.

§ Fase de desarrollo:

Se centra en el C´ OMO, es decir, en intentar diseñar las estructuras de datos, la estructura y arquitectura del software, para pasarlas a un lenguaje de programación y hacerle una serie de pruebas para verificar su exactitud. Actividades que se realizan en esta fase:

1. Diseño del software: Traducción de las especificaciones del análisis a representaciones que describan la estructura de datos, interfaz, algoritmos. . .

2. Codificación: Traducción de las especificaciones anteriores a una especificación entendible por la computadora.

3. Prueba: Ver que el programa funciona de forma correcta.

§ Fase de mantenimiento:

Se centra en los cambios asociados a la corrección de los errores detectados en las pruebas o cambios de requisitos y/o entorno.

1.3. PLANIFICACIÓN DEL PROYECTO SOFTWARE

La falta de planificación suele ser fuente de retrasos, incremento de costes. . .Para evitar estos problemas es necesario una planificación cuidadosa y, aunque en fases iníciales suele ser difícil puesto que no se tiene información suficiente para realizarla y quedará incompleta, conviene hacerla. Es una planificación preliminar. Será necesario, por tanto, realizar revisiones temporales que supondrán una modificación de la planificación.

La planificación del proyecto consta de tres etapas:

1. Definición del problema.

2. Desarrollo de una estrategia de solución.

3. Proceso de desarrollo.

1.3.1. DEFINICIÓN DEL PROBLEMA

Está orientada a que el cliente comprenda en que consiste el proyecto y se trata de un desarrollo de un enunciado breve del problema, en el que se incluirán las restricciones, situación actual y los objetivos.

Esta definición requiere un entendimiento completo del dominio y de su entorno, obteniendo esta información gracias a una serie de entrevistas con el cliente.

Una vez conocido el problema se debe proponer una solución computacional aceptada social (la solución va a suponer una disminución en el personal, y la función es asumible por el mismo) y económicamente (aunque no se produzca una disminución en el personal se va a poder realizar muchas más funciones). Después se deben determinar las funciones principales del sistema y de los subsistemas que la componen (operadores, personal de mantenimiento, usuarios, hardware. . .). Además hay que establecer los OBJETIVOS, que son los logros a alcanzar y sirven para establecer el marco de referencia para el proyecto de desarrollo del producto. Estos se aplican tanto al proceso de desarrollo como a los productos finales, pudiendo ser tanto cuantitativos como cualitativos. Los REQUISITOS especifican las capacidades que debe tener un producto para la solución del problema. Éstos se establecen en base a la funcionalidad, rendimiento, hardware, personal, interfaces. . .

Debido a la dificultad que tiene la especificación de los requisitos y objetivos en esta fase, éstos se suelen expresar en términos de atributos de calidad.

1.3.2. DESARROLLO DE UNA ESTRATEGIA DE SOLUCIÓN

Pretende resolver el problema de “elección de la primera solución propuesta” para proponer y valorar posteriormente varios métodos de solución.

Estos métodos serían todos los que tenemos a nuestro alcance. Se descartan los menos eficientes indicando por qué y se elige la solución más óptima.

1.3.3. ANÁLISIS DE RIESGO

Para solucionar las incertidumbres generadas en las primeras fases del desarrollo de un producto software se realiza el análisis de riesgos que permite garantizar una buena gestión del proyecto. Este análisis consta de cuatro actividades básicas:

§ Identificación del riesgo:

Se realiza una enumeración y clasificación por categorías de los riesgos de un proyecto en concreto.

§ Prevención de riesgos:

Intenta evaluar dos aspectos de cada uno de los riesgos:

1. Posibilidad de que el riesgo sea real.

2. Consecuencias asociadas con el riesgo, suponiendo que se origina el problema que lo genera.

§ Evaluación del riesgo:

Cuenta con un conjunto de triadas riesgo, probabilidad y coste para identificar los distintos puntos de ruptura de la forma:

Riesgo = { ri, ρi, ci }

Es necesario definir una serie de niveles de referencia. Cuando se alcanza uno de estos niveles se dice que se ha llegado a un punto de ruptura y será necesario tomar una decisión como puede ser seguir o abandonar el proyecto.

§ Plan de gestión y supervisión:

Actividad en la que se documenta el trabajo realizado con parte del análisis de riesgos, siendo utilizada por el gestor del proyecto como parte de la planificación del proyecto global.

1.3.4. RECURSOS PARA EL DESARROLLO DEL PROYECTO

§ Recursos humanos:

Son los más importantes y los que generan más problemas en el proceso de planificación y desarrollo del software. En necesario especificar tanto la posición orgánica como su especialización. El número de personas necesarias puede ser variable a lo largo de la ejecución del proyecto y sólo puede ser determinado tras realizar una estimación del esfuerzo de desarrollo mediante técnicas de estimación de esfuerzos.

§ Recursos hardware:

Un recurso es considerado como tal si pertenece a una de las siguientes categorías:

- El sistema de desarrollo: Computadora y periféricos.

- El sistema de explotación: Donde se explotará el software desarrollado.

- Otros elementos hardware necesarios para el desarrollo o la explotación.

§ Recursos software:

Software utilizado durante el proceso de desarrollo. Algunas herramientas software son:

- Herramientas orientadas a código.

- Herramientas de metodología.

- Herramientas de cuarta generación.

Si en el proceso de desarrollo hace falta un recurso software, en la elección de este recurso es necesario considerar que:

§ Si el software existe es más barato comprarlo que hacerlo

§ Si el software existente requiere alguna modificación es conveniente estimar el coste de la misma puesto que podría exceder al del desarrollo del mismo.

1.4. PLANIFICACIÓN TEMPORAL DEL PROYECTO SOFTWARE

Comprende varias tareas importantes entre las que se encuentra la de definir un modelo para el ciclo de vida del producto. Se va a realizar por alguno de los paradigmas de la IS y puede ser visto desde dos perspectivas: con una fecha de entrega inamovible o con un margen de holgura.

La planificación temporal consiste en ajustar el conjunto de tareas que deben llevarse a cabo a un calendario más o menos rígido.

Raramente se ajusta el tiempo de desarrollo del producto al previsto, desbordándolo en la mayoría de los casos, por lo que es necesario llevar a cabo un seguimiento y control de las previsiones realizadas.

1.4.1. PARALELISMO DE TAREAS

Cuando más de una persona está involucrada en un proyecto, puede que varias actividades puedan llevarse a cabo en paralelo. Debido a que estas tareas pueden realizarse de forma asíncrona, el planificador debe determinar la dependencia entre las tareas para asegurar el progreso continuo del proyecto hasta su terminación.

Cada referencia o meta parcial del proyecto es colocada a intervalos regulares y se alcanza una vez la documentación ha sido revisada satisfactoriamente.

1.4.2. DISTRIBUCIÓN DE ESFUERZOS

Va a depender del proyecto, aunque una distribución muy recomendada es la siguiente:

Fase	Esfuerzo Total
Análisis y diseño	40%
Codificación	20%
Prueba y depuración	40%

1.4.3. MÉTODOS DE PLANIFICACIÓN TEMPORAL

La planificación de un proyecto software es similar a la de cualquier otro tipo de proyecto pudiéndosele aplicar técnicas PERT o CPM.

Características comunes de los métodos de planificación:

§ Identificar las tareas que determinan la duración del proyecto.

§ Establecimiento de estimaciones de tiempo para tareas individuales de acuerdo con modelos estadísticos.

§ Calcular los tiempos límite que definen un espacio temporal para cada tarea.

Para cada tarea se deberá determinar una serie de tiempos que permitan calcular holguras, caminos críticos. . . Son los siguientes:

§ Tiempo “early”: Lo más pronto que puede comenzar una tarea suponiendo que todas las tareas se han ejecutado en su tiempo mínimo.

§ Tiempo “last”: Lo más tarde que puede comenzar una tarea sin que se retrase el tiempo mínimo de finalización del proyecto.

§ Tiempo final más temprano: Suma del comienzo más temprano y la duración de la tarea.

§ Tiempo final más tardío: Suma del comienzo más tardío y la duración de la tarea.

A partir de estos datos, como se ha dicho anteriormente, se van a poder calcular holguras y caminos críticos (formados por actividades con holgura cero).

Debería tenerse en cuenta además el esfuerzo necesario para llevar a cabo el mantenimiento, pero es una tarea difícil de programar en esta fase de desarrollo del proyecto.

1.4.4. PLANIFICACIÓN ORGANIZATIVA

Consiste en la asignación de personal para la ejecución de distintas tareas. Este personal se clasifica en tres grupos:

§ Democráticos.

§ Jerarquía administrativa.

§ Jefe principal.

Se van a establecer grupos de trabajo cuyo esquema genérico sería:

§ Un ingeniero sénior encargado de la planificación y revisión de todas las actividades del grupo.

§ Personal técnico que va dirigir el análisis y las actividades de desarrollo.

§ Un ingeniero junior que puede ser reemplazable y que podrá desempeñar funciones tanto del ingeniero sénior como del personal técnico.

1.4.5. PLAN DE PROYECTO SOFTWARE

Se produce como la culminación de la etapa de planificación, proporcionando una línea base de información de costes y de planificación temporal que se utilizará a lo largo del ciclo de vida del software. Así, se trata de un documento que se dirige a una audiencia inversa y que debe tener las siguientes características:

§ Debe comunicar el alcance y los recursos a los gestores del software, al personal técnico y al cliente.

§ Definir riesgos y sugerir técnicas de aversión al riesgo.

§ Proporcionar una aproximación global al desarrollo de software para toda la gente involucrada en el proyecto.