EL SOFTWARE

1.1.        

El software no es sólo código, sino también las especificaciones del diseño, los datos tratados y la documentación que permite el desarrollo, instalación y mantenimiento. Estrictamente, se puede definir como Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad deseada. Estructuras de datos que facilitan a las instrucciones manipular adecuadamente la información. Documentos que describen el desarrollo, uso, instalación y mantenimiento de los programas.

1.2. DEFINICIONES

Definición 1: Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software [Zelkovits, 1978].

Definición 2: Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación necesaria requerida para desarrollar, operar(funcionar) y mantenerlos [Bohem, 1976].

Definición 3: Ingeniería del Software trata del establecimiento de los principios y métodos de la Ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales [Bauer, 1972].

Definición 4: La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de Ingeniería al software [IEEE, 1993].

1.3. CARACTERÍSTICAS DEL SOFTWARE

v El software presenta varias características.

v Es un elemento lógico, no físico, en contraposición con el hardware.

v Se desarrolla, no se fabrica. La fabricación consiste fundamentalmente en ensamblar componentes, punto al que no se ha llegado ni siquiera con la programación orientada a objetos.

v No se estropea, se deteriora. Con el tiempo, el hardware se va estropeando por la presencia de componentes físicos. El software, al carecer de ellos, se deteriora, no estropea, aumentando el mantenimiento que necesita. Es el caso, por ejemplo, del llamado _código heredado_.

v El número de fallos sigue una curva teórica en la que, en la denominada fase inicial inmediatamente posterior a la implantación, se detectan muchos fallos que, con el tiempo, se van corrigiendo, de forma que cada vez se detectan menos. Aun así, sigue siendo necesario un mantenimiento para corregirlos, especialmente cuando existe un gran volumen de cambios, como sucede en el software de gestión.

v Pero en la realidad, cada vez que se resuelven un número determinado de errores se publica una nueva versión sobre la que se detectan más, y, después de aparecer varias, la curva real supera bastante a la teórica, necesitando cada vez más mantenimiento.

v La mayoría se construye a medida en vez de ensamblar componentes existentes.

1.4. LA INGENIERÍA DEL SOFTWARE: DEFINICIONES, ELEMENTOS Y OBJETIVOS GENERALES

La Ingeniería del Software estudia dicho métodos, técnicas, etc., para resolver el problema del desarrollo del software, y se puede definir de la siguiente forma: La Ingeniería del Software es una disciplina que integra métodos, técnicas y herramientas para el desarrollo de software de computadora.

Sus elementos son:

· Métodos: Conjunto de tareas ordenadas para conseguir un _n. Los métodos se desarrollaron para cada una de las fases del desarrollo (análisis, diseño, implementación, etc.), y un conjunto de varios con una filosofía común componen una metodología.

· Técnicas: Ayudan con las dificultades para llevar a cabo lo que se indica en los métodos.

· Herramientas: Programas que mecanizan los métodos y las técnicas.

Y sus objetivos fundamentales son desarrollar software de calidad y de forma productiva.

1.5. VISIÓN GENERAL DEL PROCESO DE LA INGENIERÍA DEL SOFTWARE

El ciclo de vida del software se divide en varias fases desde que nace hasta que muere:

Planificación: Se identifica el proyecto, se le da nombre y se define el alcance.

Desarrollo: Se desarrolla e implanta.

Mantenimiento: Desde que se implanta hasta que se abandona.

1.5.1. Fase de planificación

Se realiza un inventario de todas las actividades que se realizan en una empresa y se agrupan por proyectos estableciendo una correspondencia entre éstos y las áreas organizativas.

También se discute la arquitectura hardware, la topología de red, el lenguaje de programación, etc., y se da una prioridad a cada proyecto.

Se concluye con un documento denominado _Plan de Sistemas de Información_. Como anotación, se puede comentar que no se encuentra entre las normas ISO debido a que se realiza una vez cada período muy grande de tiempo (una vez cada década o incluso más).

1.5.2. Fase de desarrollo

Se llevan a cabo las tareas hasta tener el proyecto funcionando. Conlleva varias actividades, análisis, diseño, construcción, pruebas e implantación.

1.5.3. Fase de mantenimiento

Su objetivo es la obtención de una nueva versión de un sistema debido a peticiones de cambio que los usuarios realizan por un problema detectado, o por la necesidad de una mejora del mismo, para acomodarlo a los cambios de su entorno externo o para conseguir una mayor adecuación a los requisitos, mayor eficiencia, o simplemente recoger nuevas funcionalidades no expresadas en la fase de definición del sistema.

Comprende el mantenimiento:

Correctivo: Cambia el software para corregir los defectos.

Evolutivo: Introduce mejoras en el software.

Adaptativo: Modifica el software para acomodarlo a los cambios de su entorno externo.

Perfectivo: Lleva al software más allá de sus requisitos funcionales originales.

1.6. SITUACIÓN ACTUAL DE LA INGENIERÍA DEL SOFTWARE

A principios del siglo XXI, se plantean tres problemas esenciales:

v El reto de lo heredado

Existe demasiado software antiguo que es fundamental para empresas de hoy y que, al deteriorarse, posee un mayor índice de fallos y necesita un mantenimiento muy alto.

v El reto de la heterogeneidad

El software debe correr en muchas arquitecturas y sobre sistemas operativos distintos. Esto afecta a la fiabilidad del software, es más fácil que falle.

v El reto de la entrega

Se necesitan aprender técnicas, herramientas, etc., para ser más productivos y entregarlos proyectos a tiempo. Sin embargo, este aprendizaje reduce el tiempo que se puede dedicar al desarrollo.

1.7. APLICACIONES DEL SOFTWARE

Las siguientes áreas del software indican la amplitud de las aplicaciones potenciales:

Software de Sistemas: El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas y se caracteriza por una fuerte interacción con el hardware de la computadora; una gran utilización por múltiples usuarios; una operación concurrente que requiere una planificación, una compartición de recursos y una sofisticada gestión de procesos.

Software de Tiempo Real: El software que mide/analiza/controla sucesos del mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolecta y da formato a la información recibida del entorno externo, un componente de análisis que transforma la información recibida del entorno externo, un componente de análisis que transforma la información según lo requiera la aplicación, un componente de control/salida que responda al entorno externo y un componente de monitorización que coordina todos los demás componentes, de forma tal que pueda mantenerse la respuesta en tiempo real.

Software de Ingeniería y Científico: El software de Ingeniería y Científico está caracterizado por los algoritmos de manejo de números. Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de los lanzadores espaciales y desde la biología molecular a la fabricación automática.

Software Empotrado: El software Empotrado reside en memoria de solo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (p. Ej.: el control de las teclas de un horno de microondas).

Software de Computadoras Personales: El mercado del software de computadoras personales ha germinado en la pasada década. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras de negocios y personales, y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

El software se ha convertido en el elemento clave de la evolución de los sistemas y  productos informáticos. En las pasadas cuatro décadas, el software ha pasado de ser una resolución de problemas especializadas y una herramienta de análisis de información, a ser una industria por si misma. Pero la temprana cultura e historia de la programación ha creado un conjunto de problemas que persisten todavía. El software se ha convertido en un factor que limita la evolución de los sistemas informáticos. El software se compone de programas, datos y documentos. Cada uno de estos elementos compone una configuración que se crea como parte del proceso de la Ingeniería del Software. El intento de la Ingeniería del Software es proporcionar un marco de trabajo para construir software con mayor calidad.

1.8. ¿CÓMO INTERVIENE LA INGENIERÍA DEL SOFTWARE?

1.8.1. Ingeniería de software. Es una disciplina que integra métodos, herramientas y procedimientos para el desarrollo de programas con la intención de brindar el apoyo en la toma de decisiones.

Modelo de control básico

Entradas Sistema Salidas

Nota: aquí se debe utilizar una experiencia previa.

2. METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Las Metodologías de Desarrollo de Software surgen ante la necesidad de utilizar una serie de procedimientos, técnicas, herramientas y soporte documental a la hora de desarrollar un producto software.

2.1. MÉTODO CASCADA

La versión original del modelo en cascada, fue presentada por Royce en 1970, aunque son más conocidos los refinamientos realizados por Boehm [1981], Sommerville [1985] y Sigwart y col. [1990]. En este modelo, el producto evoluciona a través de una secuencia de fases ordenadas en forma lineal y permitiendo iteraciones al estado anterior.

· En un modelo en cascada, un proyecto progresa, a través de una secuencia ordenada de pasos partiendo de la especificación de requerimientos.

 · El método realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente etapa, por ejemplo, desde el análisis de requerimientos hasta el diseño.

· Cuando la revisión determina que el proyecto no está listo para pasar a la siguiente, permanece en la etapa actual hasta que esté preparado.

· Ayuda a localizar errores en las primeras etapas del proyecto.

· Para un proyecto de desarrollo rápido, el modelo en cascada puede suponer una cantidad excesiva de documentación cantidad.

El número de etapas suele variar, pero en general suelen ser:

DOCUMENTACIÓN

· Análisis de requisitos del sistema

· Análisis de requisitos del software

· Diseño preliminar

· Diseño detallado

· Codificación y pruebas

· Explotación (u operación) y mantenimiento

Las características de este modelo son:

· Cada fase empieza cuando se ha terminado la anterior.

· Para pasar a la fase posterior es necesario haber logrado los objetivos de la fase anterior

· Es útil como control de fechas de entregas.

· Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto.

2.2. MÉTODO CODIFICAR Y CORREGIR

· El modelo Codificar y Corregir (Code- and-fix) es un modelo poco útil, pero sin embargo bastante común.

· Cuando se utiliza éste método.- se empieza con una idea general de lo que se necesita construir.

· Se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo.

Ventajas

· No conlleva ninguna gestión; no se pierde tiempo en la planificación, en la documentación, en el control de calidad, en el cumplimiento de los estándares, o en cualquier otra actividad que no sea codificación pura.

· Requiere poca experiencia cualquier persona que haya escrito alguna vez un programa está

Familiarizada con éste modelo. Calidad, ni identificación de riesgos

Desventajas

· El modelo resulta peligroso para otro tipo de proyectos que no sean pequeños.

· No proporciona medios de evaluación de la sea codificación pura..

· Si al llevar tres cuartas partes de la codificación descubre que el diseño es incorrecto, no hay otra, solución que desechar el trabajo y comenzar de nuevo.

2.3. MÉTODO DESARROLLO EN ESPIRAL

El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra.

Cada ciclo de desarrollo se divide en cuatro fases:

1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.

2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.

3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará depende del riesgo identificado para esa fase.

4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.

Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.

El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

En cada Cuadrante del Método Espiral se realiza las siguientes actividades:

· Planificación: Determinación de objetivos, alternativas, restricciones, y elaboración del plan de desarrollo para el ciclo actual.

· Análisis de Riesgos: Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto.

· Ingeniería: Desarrollo del producto siguiendo un modelo del ciclo de vida o cascada, prototipo, etc.

· Evaluación por el cliente: valoración de resultados.

2.4. MÉTODO PROTOTIPO DE SISTEMAS

El uso de prototipos se centra en la idea de ayudar a comprender los requisitos que plantea el usuario, sobre todo si este no tiene una idea muy acabada de lo que desea. También pueden utilizarse cuando el ingeniero de software tiene dudas acerca de la viabilidad de la solución pensada.

 Se desarrolla prototipos cuando:

· Un prototipo en sistemas de información es un modelo operable, que tiene todas las características necesarias, pero que es ineficiente debido a que los programas fueron hechos a la carrera con el objetivo de ser funcionales, en vez de ser eficientes.

· La elaboración de prototipos de sistemas de información es una técnica valiosa para la recopilación rápida de información específica acerca de los requerimientos de información de los usuarios.

· La velocidad es esencial para la elaboración satisfactoria del prototipo en su sistema de información. El prototipo debe llevarse menos de una semana para ensamblarse y lo preferible son dos o tres días.

Al usar prototipos, las etapas del ciclo de vida clásico quedan modificadas de la siguiente manera:

· Análisis de requisitos del sistema

· Análisis de requisitos del software

· Diseño, desarrollo e implementación del prototipo

· Prueba del prototipo.

· Refinamiento iterativo del prototipo

· Refinamiento de las especificaciones del prototipo

· Diseño e implementación del sistema final

· Explotación (u operación) y mantenimiento de Software.

3. LA COMPLEJIDAD INHERENTE AL SOFTWARE

Como sugiere Brooks. “la complejidad del software es una propiedad esencial, no accidental”. La complejidad de los sistemas informáticos hace a veces necesario el desarrollo de proyectos software de decenas de miles de líneas de código. Esto no puede ser abordado directamente, empezando a programar sin más. Es necesario analizar qué es lo que tenemos que hacer, cómo lo vamos a hacer, cómo se van a coordinar todas las personas que van a intervenir en el proyecto y cómo vamos a controlar el desarrollo del mismo de forma que al final obtengamos los resultados esperados. Las metodologías convencionales de Ingeniería de Software tienen mecanismos robustos para hacer un análisis de necesidades y diseño de los sistemas, poco han evolucionado con la tecnología en lo relacionado con el diseño computacional.

Este trabajo propone la inclusión de la tecnología orientada a objetos, en todas las etapas del ciclo de desarrollo del sistema, para disminuir la complejidad. Al llegar a la implementación, los resultados obtenidos se transcriben al lenguaje de programación elegido, cambiando la sintaxis en que se expresa el modelo, más no la semántica.

3.1. COMPLEJIDAD DEL DOMINIO DEL PROBLEMA

Cuando los problemas del mundo real se desean resolver con modelos de sistemas computacionales, trae consigo una cantidad indefinida de requisitos que compiten entre sí y algunas veces se contradicen. Dar funcionalidad a un sistema es difícil e incluso comprender los requerimientos como: facilidad de uso, rendimiento, costo, capacidad de supervivencia, fiabilidad, son parte de la complejidad externa que infiere determinantemente en la complejidad interna del sistema.

Bajo este contexto nace la importancia de la relación entre desarrolladores y usuarios del sistema. Habitualmente los usuarios suelen tener dificultades en expresar sus necesidades e ideas. Esto se da en ocasiones por falta de conocimiento del ámbito de cada uno de los grupos. Los usuarios y los desarrolladores tienen perspectivas diferentes sobre la naturaleza del problema.

Contar con herramientas que permitan plasmar estos requisitos de forma clara para ambos grupos es uno de los retos de la Ingeniería de Software.

3.2. DIFICULTAD DE ADMINISTRAR EL PROCESO DE DESARROLLO

Es difícil contar con un sistema donde su característica sea la simplicidad en el desarrollo del software.

La mayoría de los grandes sistemas contienen un alto número de código que impide dar un mantenimiento óptimo a los programas. Cuando los equipos de desarrollo son grandes y heterogéneos la administración de las actividades se hace complicada debido a que se desarrollan por muchos equipos de trabajo.

Hoy en día, tanto el hardware como el software, deben ser capaces de contar con una arquitectura abierta, reusabilidad, facilidad de reconfiguración, aplicación de estándares y diseño modular. Estas características permiten escribir menos códigos y poder reutilizar el software, en un software diferente al que fue diseñado originalmente. La adición debe ser transparente para el sistema receptor.

3.3. LA FLEXIBILIDAD QUE SE PUEDE ALCANZAR A TRAVÉS DEL SOFTWARE.

El software ofrece la flexibilidad al desarrollador para expresar y representar procesos triviales y complejos del conocimiento humano en un sistema computacional. Esta propiedad no debe producir cambios en los procedimientos y prácticas de las entidades.

El sistema debe ser suficientemente flexible para incorporarse a las actividades de las entidades y hacerlas más eficientes, sin causar gastos que eleven el precio de los sistemas.

Por ejemplo, una organización puede tener una diversidad de sistemas de comunicación en su estructura organizacional, el sistema computacional de apoyo a la administración debe ser lo suficientemente flexible para trabajar y/o compatibilizar con cualquier sistema de comunicaciones (transmisión de datos) existente.

Por lo tanto, el software no debe forzar al cliente a comprar sistemas de comunicaciones adicionales para poder operar sin problemas.

3.4. LOS PROBLEMAS DE CARACTERIZAR EL COMPORTAMIENTO DE SISTEMAS DISCRETOS

En una aplicación de gran tamaño puede haber cientos o hasta miles de variables, así como más de un flujo de control. El conjunto de todas estas variables, sus valores actuales, y la administración del sistema son procesos que constituyen el estado actual de la aplicación. Al ejecutarse el software en computadoras digitales, se tiene un sistema con estados discretos.

En contraste, a los sistemas analógicos (vgr. El movimiento de una pelota lanzada al aire) son sistemas continuos.

Pequeños cambios en las entradas siempre producirán cambios consecuentemente pequeños en las salidas”. Por el contrario, los sistemas discretos por su propia naturaleza tienen un número finito de estados posibles. Todos los eventos externos a un sistema de software tienen la posibilidad de llevar a ese sistema a un nuevo estado, y más aún, la transición de estado a estado no siempre es determinista. En las peores circunstancias, un evento externo puede corromper el estado del sistema, porque sus diseñadores olvidaron tener en cuenta ciertas interacciones entre eventos.

4. FACTORES EN LA CALIDAD DEL SOFTWARE

4.1. Definición de Calidad

“La calidad es la suma de todos aquellos aspectos o características de un producto o servicio que influyen en su capacidad para satisfacer las necesidades, expresadas o implícitas” (ISO 8402)

Terminología (ISO 8402) Definición de Calidad “El conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas” ISO 8402

4.2. Control de la calidad del software.

Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en dos objetivos fundamentales: mantener bajo control un proceso – eliminar las causas de los defectos en las diferentes fases del ciclo de vida

En general son las actividades para evaluar la calidad de los productos desarrollados

4.3. Garantía de calidad:

El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad.

4.4. Factores que determinan la calidad del software

Se clasifican en tres grupos:

4.4.1. Operaciones del producto: características operativas

– Corrección (¿Hace lo que se le pide?)

• El grado en que una aplicación satisface sus especificaciones y consigue los objetivos encomendados por el cliente.

– Fiabilidad (¿Lo hace de forma fiable todo el tiempo?)

• El grado que se puede esperar de una aplicación lleve a cabo las operaciones especificadas y con la precisión requerida.

– Eficiencia (¿Qué recursos hardware y software necesito?).

• La cantidad de recursos hardware y software que necesita una aplicación para realizar las operaciones con los tiempos de respuesta adecuados

– Integridad (¿Puedo controlar su uso?)

– Facilidad de uso (¿Es fácil y cómodo de manejar?)

• El esfuerzo requerido para aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir resultados.

4.4.2. Revisión del producto: capacidad para soportar cambios

– Facilidad de mantenimiento (¿Puedo localizar los fallos?)

• El esfuerzo requerido para localizar y reparar errores

– Flexibilidad (¿Puedo añadir nuevas opciones?)

• El esfuerzo requerido para modificar una aplicación en funcionamiento

– Facilidad de prueba (¿Puedo probar todas las opciones?)

• El esfuerzo requerido para probar una aplicación de forma que cumpla con lo especificado en los requisitos.

4.4.3. Transición del producto: adaptabilidad a nuevos entornos

– Portabilidad (¿Podré usarlo en otra máquina?).

• El esfuerzo requerido para transferir la aplicación a otro hardware o sistema operativo.

– Reusabilidad (¿Podré utilizar alguna parte del software en otra aplicación?)

• Grado en que partes de una aplicación pueden utilizarse en otras aplicaciones

– Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?

• El esfuerzo necesario para comunicar la aplicación con otras aplicaciones o nsistemas Informáticos.

Factores de calidad del Software (McCall).

• Organiza los Factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto.

Ø Operación del producto

Ø Revisión del producto

Ø Transición del producto

5. REQUERIMIENTOS Y ESPECIFICACIÓN DEL SOFTWARE

5.1. Propósito

Permitir establecer las bases de acuerdo entre usuarios en lo que al proyecto de software se refiere.

· Ayudar a los usuarios finales del software a entender exactamente qué es lo que el cliente de software desea.

5.2. Determinación de los requerimientos

Aquí se debe hacer lo siguiente:

· Recopilación de información

· El analista debe comprender las funciones del negocio.

· Tener informe sobre personas, objetivos y procedimientos.

· Investigar datos relevantes.

· El Analista comprende que información necesitan los usuarios para trabajar.

Por ello intervienen:

· Herramientas:

· Entrevista.

· Cuestionario.

· Comportamiento de los tomadores de decisión.

· Prototipos.

Involucrados:

· Analista.

· Usuarios.

· Administradores de las operaciones.

El analista necesita:

Los detalles de las funciones actuales del sistema.

· ¿Quién? Personas

· ¿Qué? Actividad del negocio, etc.

· ¿Dónde? Ambiente

· ¿Cuándo? En qué momento