Antologia Fundamentos de Desarrollo de Sistemas PDF

ANTOLOGÍA MATERIA: Fundamentos de desarrollo de sistemas CARRERA: Ingeniería en sistemas computacionales CLAVE DE LA ASIGNATURA: SCM - 0413 CLAVE DEL PLAN: ISIC - 2004 - 296

Compilación hecha por: M.C. Verónica Amezcua Magallón

1

Índices

Índice 1. Conceptos Introductorios. .................................................................... 1 1.1. Introducción a los Sistemas ................................................................. 1 1.1.1 Descripción general de sistemas .................................................. 2 1.1.2 Tipos de Sistemas .......................................................................... 4 1.1.3 Clasificación de Sistemas ............................................................. 5 1.2. Ciclo de vida de un proyecto de software. ........................................... 8 1.2.1. Planificación y gestión del proyecto. ........................................... 8 1.2.2. Determinación de requerimientos................................................. 8 1.2.3. Análisis y diseño. ........................................................................... 9 1.2.4. Programación. .............................................................................. 10 1.2.5. Pruebas e implantación. .............................................................. 10 2. Introducción a la ingeniería de software ........................................... 11 2.1. Definición de ingeniería de software. ............................................. 13 2.2. Historia de la ingeniería de software. ............................................. 14 2.3. Características del software. .......................................................... 16 2.4. Mitos del software. ........................................................................... 17 2.5. Capas de la ingeniería de software. ............................................... 18 2.6. El proceso de software. ................................................................... 19 2.7. Software de calidad. ........................................................................ 21 2.8. Factores de calidad y productividad. ............................................. 26 3. Paradigmas de la ingeniería de software. ......................................... 35 3.1. El enfoque estructurado. ................................................................. 36 3.1.1. Diagramas de flujos de datos. ..................................................... 36 3.1.2. Diccionarios de datos. ................................................................. 46 3.1.3. Diseño de módulos. ..................................................................... 48 3.1.4. Descomposición de procesos. .................................................... 52 3.2. El enfoque orientado a objetos. ...................................................... 61 3.2.1. Análisis. ......................................................................................... 61 3.2.2. Diseño. .......................................................................................... 65 4. Modelos de proceso de software ....................................................... 67 4.1. Modelo de cascada. ......................................................................... 67 4.2. Modelo espiral. ................................................................................. 69 4.3. Modelo incremental. ........................................................................ 71 4.4. Proceso de desarrollo unificado..................................................... 74 4.5. Proceso software personal.................................................................. 77 5. Técnicas, herramientas y estudios previos. ..................................... 80 5.1. Técnicas de recopilación de información. ..................................... 80 5.1.1 Entrevista. ........................................................................................ 80 5.1.2 Cuestionario. ................................................................................... 84 5.1.3 Recopilación y análisis de documentos........................................ 86 5.1.4 Observación y técnica “STROBE”. ................................................ 88 5.2. Herramientas CASE....................................................................... 90 5.2.1 Estructuradas. ................................................................................. 92 5.2.2 Orientadas a Objetos. ..................................................................... 93 5.3. Desarrollo de prototipos. ..................................................................... 96 6. Diseño y arquitectura de productos de software. ................................ 105 6.1. Descomposición modular.................................................................. 105

Índices

6.2. Arquitecturas de dominio específico................................................ 108 6.2.1 Diseño de software de arquitectura multiprocesador. ............... 108 6.2.2 Diseño de software de Arquitectura Cliente/Servidor ................ 109 6.2.3 Diseño de software distribuido .................................................... 117 6.2.4 Diseño de software de tiempo real. ............................................. 121 Bibliografía: .................................................................................................. 129 Webgrafía: ..................................................................................................... 129 http://www.monografías.com/trabajos11/teosis/teosis.shtml/ ......................... 129 http://www.rosenblueth.mx/InterFAR/Vol1Num3/doc/Vol1Num3-49.htm........ 129 http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/anexos/fluj o.htm 129

http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/ca p2.htm#DE ....................................................................................................... 129

Anexos: ......................................................................................................... 130 Anexo 1: Datos de la asignatura (programa y retícula) ......................................................... 130

Índices

Índice de figuras Figura 1: Descripción general de sistemas.................................................... 2 Figura 2: Sistema de operaciones para una tienda departamental ............. 3 Figura 3: Sistema de operaciones para una granja....................................... 4 Figura 4: Capas de ingeniería de software (Pressman 6° ed.) .................... 19 Figura 5: Principales elementos de SQA ..................................................... 24 Figura 6: Gama de paradigmas de ingeniería de software ......................... 35 Figura 7: Ejemplo de DFD recepción de pedidos ........................................ 37 Figura 8: Ejemplo de nombre inválido de procesos ................................... 39 Figura 9: Ejemplos de nombre válido de procesos..................................... 39 Figura 10: Diagrama de contexto .................................................................. 45 Figura 11: Diagrama de nivel 0...................................................................... 45 Figura 12: Principales componentes ............................................................ 49 Figura 13: Símbolos estándar de modelado ................................................ 49 Figura 14: Primer caso ................................................................................... 50 Figura 15: Segundo caso ............................................................................... 51 Figura 16: Tercer caso ................................................................................... 52 Figura 17: Tabla de decisiones. .................................................................... 57 Figura 18: Ejemplo de una tabla de decisiones ........................................... 59 Figura 19: Ejemplo de una tabla reducida.................................................... 60 Figura 20: Ejemplo de una tabla de decisiones imposible. ........................ 61 Figura 21: Modelo de cinco capas ................................................................ 62 Figura 22: Tipos de objetos ........................................................................... 63 Figura 23: Modelo en cascada ...................................................................... 67 Figura 24: Modelo en espiral ......................................................................... 70 Figura 25: Ejemplo del modelo incremental ................................................ 71 Figura 26: 1er. incremento............................................................................. 72 Figura 27: 2do. incremento............................................................................ 73 Figura 28: 3er. incremento............................................................................. 73 Figura 29: Ventajas ........................................................................................ 82 Figura 30: Desventajas .................................................................................. 82 Figura 31: Bloques de construcción CASE.................................................. 91

Índices

Índice de tablas Tabla 1: Resumen de la primera y segunda era del software..................... 15 Tabla 2: Resumen de tercera y cuarta era del software .............................. 15 Tabla 3: Ejemplo de bitácora ......................................................................... 29 Tabla 4: Computación de métricas de punto de funciones ........................ 30 Tabla 5: Número medio de LDC para construir un punto de función. ....... 33

Unidad 1: Conceptos introductorios

UNIDAD 1.- Conceptos introductorios. Objetivo Educacional El estudiante identificará los diferentes tipos de sistemas de software que existen y comprenderá las fases del ciclo de vida de un proyecto de software.

1. Conceptos Introductorios. ¿Qué es un sistema? Es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común. • • • • • •

Un conjunto de componentes o elementos Dinámicamente relacionados Formando una actividad Para alcanzar un objetivo Operando sobre datos/energía/materia Para proveer información/energía/materia Introducción a los Sistemas Nuestra sociedad esta rodeada de sistemas. Una organización es un sistema. Sus componentes –mercadotecnia, manufactura, ventas, compras, contabilidad, personal, etc.- trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los accionistas de la compañía. Cada uno de los componentes es a su vez un sistema. El departamento de contabilidad esta formado quizá por cuantas por pagar, cuentas por cobrar, facturación, auditoria entre otros. Por ejemplo, cualquier persona experimenta sensaciones físicas gracias a un complejo sistema nervioso formado por el cerebro, la médula espinal, los nervios y las células sensoriales especializadas que se encuentran debajo de la piel; estos elementos funcionan en conjunto para que el sujeto experimente sensaciones de frío, calor, comezón, etc. Para alcanzar sus objetivos los sistemas interaccionan con su medio ambiente, el cual esta formado por todos los objetos que se encuentran fuera de su frontera.

1

Unidad 1: Conceptos introductorios

Los sistemas que interactúan con su medio ambiente reciben entradas y producen salidas y se denominan sistemas abiertos. En contraste, aquellos que no interactúan con su medio ambiente se conocen como sistemas cerrados. Todos los sistemas actuales son abiertos. La información proporcionada al comparar los resultados con los estándares recibe el nombre de retroalimentación. Descripción

Ambiente

general

Entradas Información Energía Recursos Materiales

Transformación o procesamiento

de Salidas Información Energía Recursos Materiales

sistemas

Ambiente

Retroalimentación Figura 1: Descripción general de sistemas •

Entrada o insumo o impulso (input): es la fuerza de arranque del sistema, que provee el material o la energía para la operación del sistema.

•

Salida o producto o resultado (output): es la finalidad para la cual se reunieron elementos y relaciones del sistema. Los resultados de un proceso son las salidas, las cuales deben ser coherentes con el objetivo del sistema. Los resultados de los sistemas son finales, mientras que los resultados de los subsistemas con intermedios. Procesamiento o procesador o transformador (throughput): es el fenómeno que produce cambios, es el mecanismo de conversión de las entradas en salidas o resultados. Generalmente es representado como la caja negra, en la que entran los insumos y salen cosas diferentes, que son los productos.

•

•

Retroacción o retroalimentación o retroinformación (feedback): es la función de retorno del sistema que tiende a comparar la salida con un criterio preestablecido, manteniéndola controlada dentro de aquel estándar o criterio.

2

Unidad 1: Conceptos introductorios •

Ambiente: es el medio que envuelve externamente el sistema. Está en constante interacción con el sistema, ya que éste recibe entradas, las procesa y efectúa salidas. La supervivencia de un sistema depende de su capacidad de adaptarse, cambiar y responder a las exigencias y demandas del ambiente externo. Aunque el ambiente puede ser un recurso para el sistema, también puede ser una amenaza.

Ejemplos:

•Fluctuaciones •Entregas Tardías •Recesión •Rotación de personal •Terrenos •Mano de obra •Edificio, •Equipo, •Etc. Insumos

Proceso de conversión

•Productos •Servicio al cliente

•Niveles de inventario •Eficiencia de mano de obra •Volumen de ventas Figura 2: Sistema de operaciones para una tienda departamental

3

Unidad 1: Conceptos introductorios

•Clima •Inflación •Controles gubernamentales

•Fallas en equipo •Terrenos •Mano de obra •Edificios •Equipo •Habilidades del •Agricultor •Etc.

Proceso de conversión

Productos

•Granos •Leche •Crema •Etc.

•Niveles de inventario •Eficiencia de mano de obra •Volumen de ventas

Insumos

Figura 3: Sistema de operaciones para una granja

Tipos de Sistemas Los sistemas en cuanto a su constitución, pueden ser físicos o abstractos: •

Sistemas físicos o concretos: compuestos por equipos, maquinaria, objetos y cosas reales.

•

Sistemas abstractos: compuestos por conceptos, planes, hipótesis e ideas. Muchas veces solo existen en el pensamiento de las personas. En cuanto a su naturaleza, pueden ser cerrados o abiertos: 4

Unidad 1: Conceptos introductorios

•

Sistemas cerrados: no presentan intercambio con el medio ambiente que los rodea, son herméticos a cualquier influencia ambiental. No reciben ningún recurso externo y nada producen que sea enviado hacia fuera. En rigor, no existen sistemas cerrados. Se da el nombre de sistema cerrado a aquellos sistemas cuyo comportamiento es determinístico y programado y que opera con muy pequeño intercambio de energía y materia con el ambiente. Se aplica el término a los sistemas completamente estructurados, donde los elementos y relaciones se combinan de una manera peculiar y rígida produciendo una salida invariable, como las máquinas.

•

Sistemas abiertos: presentan intercambio con el ambiente, a través de entradas y salidas. Intercambian energía y materia con el ambiente. Son adaptativos para sobrevivir. Su estructura es óptima cuando el conjunto de elementos del sistema se organiza, aproximándose a una operación adaptativa. La adaptabilidad es un continuo proceso de aprendizaje y de auto-organización. Los sistemas abiertos no pueden vivir aislados. El sistema abierto interactúa constantemente con el ambiente en forma dual, o sea, lo influencia y es influenciado. El sistema cerrado no interactúa. El sistema abierto puede crecer, cambiar, adaptarse al ambiente y hasta reproducirse bajo ciertas condiciones ambientales. El sistema cerrado no. Es propio del sistema abierto competir con otros sistemas, no así el sistema cerrado. http://www.monografías.com/trabajos11/teosis/teosis.shtml/

Clasificación de Sistemas Sistemas de Transacciones: Son sistemas para procesar gran cantidad de datos para transacciones rutinarias. Son llamados TPS cuyas siglas corresponden a Transaction Processing System. Un ejemplo es la Corporación Financiera Internacional (CFI), cuyo sistema de transacciones funciona de la siguiente manera: El CFI busca inversores interesados en los países más desarrollados y el capital proveído por éstos, es transferido a empresas privadas de países subdesarrollados cuyo capital privado no basta.

5

Unidad 1: Conceptos introductorios

Sistemas de Conocimiento: Dan soporte a los trabajos de profesionistas, para colaborar y coadyuvar a crear un nuevo conocimiento que contribuya a la organización o a toda la sociedad. KWS, knowledge work system, o sistema de manejo de conocimiento. Un ejemplo es el de aplicaciones como Photoshop, la cual ayuda a diseñadores gráficos en crear su arte publicitario por medio de poderosas herramientas con las cuales se puede manipular y modificar distintos tipos de gráficos y fotografías. Sistemas Expertos: AI, artificial intelligence, o inteligencia artificial. Un famoso sistema experto es MYCIN, el cual es un sistema experto para la realización de diagnósticos, el cual aconseja a los médicos en la investigación y determinación de diagnósticos en el campo de las enfermedades infecciosas de la sangre. El sistema MYCIN, al ser consultado por el médico, solicita primero datos generales sobre el paciente: nombre, edad, síntomas, etc. Una vez conocida esta información por parte del sistema, el Sistema Experto plantea unas hipótesis. Para verificar la hipótesis el sistema consulta a la base de conocimientos, y también haciendo una serie de preguntas al usuario. Con las respuestas que recibe, el MYCIN verifica o rechaza las hipótesis planteadas. Sistemas de Apoyo a Grupos: GDSS, group decission support system, o sistemas de apoyo a decisiones de grupo. Un sistema GDSS es el Vision Quest, el cual permite realizar junta electrónicas. Cualquiera puede conducir una junta electrónica y el sistema puede ser usado de manera distribuida. Las juntas se pueden realizar con los participantes en el mismo lugar o diferentes lugares, al mismo tiempo o a distintos tiempos. Sistema de ejecutivos: ESS, executive support system, o sistemas de apoyo a ejecutivos. Un ejemplo es el sistema denominado Commander EIS que permite representaciones a todo color y un menú imaginativo que puede aprenderse intuitivamente, con variaciones y excepciones que son destacadas mediante colores. Los usuarios pueden acceder datos mediante una pantalla táctil, ratón o teclado y pueden agrandar 6

Unidad 1: Conceptos introductorios

las imágenes para mayores niveles de detalle, ya sea navegando por sí mismos o siguiendo caminos previamente definidos. Permite a la organización hacer el seguimiento de los parámetros de la calidad y factibilidad de las medidas tomadas para cada motor a reacción por tipo de cliente. Sistemas de automatización de oficina. Estos sistemas dan soporte a los trabajadores y no crean conocimiento nuevo sino que usan la información para analizarla o diseminarla formalmente en toda la organización, se forma de documentos como: normas de la organización; manuales de procedimientos científicos, técnicos y administrativos, etc. Sistemas de información gerencial. Sistemas que generan espectros estadísticos instantáneos del estado que guarda la empresa. Sistemas de información de apoyo a operaciones. Sistemas que son de consulta, a manera de asistentes de apoyo de consulta, decisión en el accionar del trabajo diario. Sistemas de navegación documental. Sistemas especializados de gestión documental, son la base de las áreas de consulta de bibliotecas virtuales. Sistemas de publicidad. Basados principalmente en el potencial de comunicación interactivo de Internet. Sistemas de servicios a clientes. Son los que en los últimos años han generado una revolución sorprendente, que innovó la forma de vivir en sociedad. (Kendall 6°ed.)

7

Unidad 1: Conceptos introductorios

1.2. Ciclo de vida de un proyecto de software. Es un enfoque por fases para el análisis y diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo específico de actividades del analista y el usuario 1.2.1. Planificación y gestión del proyecto. En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de identificar problemas, oportunidades y objetivos. Los usuarios, los analistas y los administradores de sistemas son los involucrados en esta fase. Las actividades consisten en entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado es un informe de viabilidad que incluye una definición del problema y un resumen de los objetivos. A continuación la administración debe decidir si se sigue adelante con el proyecto propuesto. Si el grupo de usuarios no cuenta con fondos suficientes, si desea atar problemas distintos, o si la solución a estos no amerita un sistema de cómputo, se podría sugerir una solución diferente y el proyecto de sistemas se cancelaría. 1.2.2.

Determinación de requerimientos.

Entre las herramientas que se utilizan para determinar requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos de oficina, al igual que métodos de amplio alcance como la elaboración de prototipos. En esta fase los implicados son el analista y los usuarios, por o general trabajadores y gerentes de áreas de operaciones. El analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades por lo que necesita conocer los detalles de las funciones del sistema actual: el quién ( la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el 8

Unidad 1: Conceptos introductorios

momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. Al término de esta fase el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados. 1.2.3.

Análisis y diseño.

Análisis Para analizar las necesidades del sistema el analista hace uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio. A partir de estos se desarrollan diccionarios de datos que enlistan todos los datos utilizados en el sistema, así como sus respectivas especificaciones. Existen otros métodos para el análisis de decisiones como son: español estructurado, tablas y árboles de decisión. En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. Si la administración de la empresa considera factible laguna de las recomendaciones, el analista sigue adelante. Cada problema de sistemas es único, y nunca existe sólo una solución correcta. La manera de formular una recomendación o solución depende de las cualidades y la preparación profesional de cada analista. Diseño En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de los datos que aseguran que ingresen al sistema de forma correcta. Además, el analista facilita la entrada eficiente de datos al sistema de información mediante técnicas adecuadas de diseño de formularios. 9

Unidad 1: Conceptos introductorios

Esta fase incluye también el diseño de la interfaz del usuario, de archivos o bases de datos que almacenaran gran parte de los datos indispensables para los encargados de tomar las decisiones en la organización. Es muy importante que el analista interactúe con los usuarios para diseñar la salida que satisfaga sus las necesidades de información. Finalmente debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos, y producir paquetes de especificaciones de programa para los programadores. 1.2.4.

Programación.

El analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los diagramas de NassiShneiderman y el seudocódigo. El analista se vale de una o más de estas herramientas para comunicar al programador lo que requiere programar. 1.2.5.

Pruebas e implantación.

Pruebas Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los problemas antes de que se entregue a los usuarios. Una parte de las pruebas las realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realizan una serie de pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual. Implantación En esta fase se capacita a los usuarios en el manejo del sistema, además el analista tiene que planear una conversión de archivos de formatos anteriores a los nuevos, o la construcción de una base de datos, la instalación de equipo y la puesta en producción del nuevo sistema. (Kendall y Kendall y 6°. ed.)

10

Unidad 2: Introducción a la ingeniería de software

UNIDAD 2.-

Introducción a la ingeniería de software

Objetivo Educacional El alumno comprenderá los elementos que integran la Ingeniería de Software y el aseguramiento de la calidad.

2.

Introducción a la ingeniería de software

Durante las primeras tres décadas de la informática, el principal desafío era el desarrollo del hardware de las computadoras, de forma que se redujera el costo de procesamiento y almacenamiento de datos. A lo largo de la década de los ochenta, los avances de microelectrónica han dado como resultado una mayor potencia de cálculo a la vez que una reducción del costo. Hoy el problema es diferente. El principal desafío es mejorar la calidad y reducir el costo de las soluciones basadas en computadora. Para controlar los costos del hardware, los gestores instituyeron controles formales y estándares técnicos. Exigían un análisis y diseño completo antes de que algo se construyera. Medían el proceso para determinar dónde podían hacer mejoras. Dicho sencillamente, aplicaban los controles, métodos y herramientas que reconocemos como ingeniería del hardware. Mientras que desgraciadamente el software no era más que un añadido. En los primeros días, para la programación existían pocos métodos formales y pocas personas los usaban. El programador aprendía normalmente su oficio mediante prueba y error. El mundo del software era bastante indisciplinado. Por lo que muchos aprendices técnicos se hacían las siguientes preguntas: ¿Por qué lleva tanto tiempo terminar los programas? ¿Por qué es tan elevado el costo? ¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes? Estas y muchas preguntas son manifestación del carácter del software y de la forma en que se desarrolla. Problema que ha llevado a la adopción de la ingeniería de software.

11

Unidad 2: Introducción a la ingeniería de software

La potencia de las grandes computadoras de la era de los ochenta está hoy disponible en una computadora personal. Las enormes capacidades de procesamiento y almacenamiento del hardware moderno representan un gran potencial de cálculo. El software es el que nos facilita utilizar y explotar este potencial. Actualmente el software ha superado al hardware como clave del éxito de muchos sistemas basados en computadora. Tanto si se utiliza la computadora para llevar un negocio, controlar o manufacturar un producto, monitorear un paciente, dirigir un satélite espacial, etc., el software es factor que marca la diferencia. La diferencia entre una compañía y su competidora es la suficiencia y oportunidad con que maneja su información. Y el software es la herramienta especialmente indicada para esto. El diseño de un producto de software “amigable al usuario” es la diferencia entre productos competidores que tengan funciones similares. Crisis Del Software Los problemas del desarrollo del software se caracterizan por los siguientes aspectos:

•

La planificación y estimación de costos son frecuentemente muy imprecisas. • La “productividad” de la comunidad dedicada al desarrollo de software no corresponde con la demanda de sus servicios y • La calidad de la Ingeniería de software no llega a ser a veces ni aceptable. Tales problemas son sólo las manifestaciones más visibles de otras dificultades del software:

•

No tenemos tiempo de recoger datos sobre el proceso de desarrollo de software. Sin datos históricos como guía, la estimación no ha sido buena y los resultados previstos muy pobres. • La insatisfacción del cliente con el sistema “terminado” se produce frecuentemente. Los proyectos se desarrollan sólo con una vaga indicación de los requisitos del cliente. La comunicación entre el cliente y el que desarrolla el software es muy escasa. • La calidad es normalmente escasa.

12

Unidad 2: Introducción a la ingeniería de software

•

El software existente puede ser muy difícil de mantener. Criterio muy importante en la aceptación del software. Sin embargo todos estos problemas pueden corregirse, la clave esta en dar un enfoque de ingeniería al desarrollo de software. 2.1.

Definición de ingeniería de software.

Para considerar el creciente problema de la tecnología del Ingeniería de software, se convocó en 1968 a una reunión de trabajo en Alemania Oriental; en esa junta y en la siguiente en Italia, se estimuló el interés general hacia los aspectos técnicos y administrativos utilizados en el desarrollo y mantenimiento de productos de Ingeniería de software. El término Ingeniería del software fue usado por primera vez en dicha reuniones. Una de las primeras definiciones de ingeniería de software fue la propuesta en la primera conferencia importante dedicada al tema. “El establecimiento y uso de principios de ingeniería, orientados a obtener software económico que sea fiable y funcione de manera eficiente sobre máquinas reales”. (Fritz Bauer) Más definiciones: La Ingeniería del Software es la aplicación práctica y sistemática del conocimiento científico a: (Boehm) •

la producción de programas correctos, que se desarrollan a tiempo y dentro de las estimaciones de presupuesto, • y a la correspondiente documentación para desarrollarlos, usarlos y mantenerlos. “Una disciplina que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza”. (Sommerville 2002)

Aunque se han propuesto muchas definiciones, todas refuerzan la importancia de una disciplina de ingeniería para el desarrollo de software. 13

Unidad 2: Introducción a la ingeniería de software

Ya que esta ingeniería tiene alto consumo de recursos humanos requiere de habilidades técnicas y de un gran consumo administrativo. La Ingeniería del relacionadas con:

Software

se

fundamenta

en

técnicas

Ciencia de la computación, programación, ingeniería, administración, matemáticas, economía,... La ciencia de la administración asigna los fundamentos para la administración del proyecto. Los sistemas deben desarrollado y mantenidos en tiempo y dentro de un régimen de estimación de costos; la economía, por su parte, brinda los fundamentos para la estimación de recursos y el costo del control. 2.2.

Historia de la ingeniería de software.

a) Primera Era. Durante los primeros años de desarrollo de las computadoras, el hardware sufrió muchos cambios, mientras que el software se contemplaba como un añadido. Para la programación existían pocos métodos sistemáticos. El desarrollo de software se realizaba sin ninguna planificación. La mayor parte del hardware se dedicaba a la ejecución de un único programa que, a su vez, se dedicaba a una aplicación especial. Se utilizaba en la mayoría de los sistemas una orientación por lotes. El software como producto (programas desarrollados para ser vendidos) estaba en su infancia. La mayoría del software se desarrollaba y se utilizaba por la misma persona u organización. La misma persona lo escribía, lo ejecutaba y, si fallaba, lo depuraba. Debido a este entorno personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien, y la documentación normalmente no existía. b) Segunda Era. Los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre máquina. Los sistemas de tiempo real podían recoger, analizar y transforma datos de múltiples fuentes, 14

Unidad 2: Introducción a la ingeniería de software

controlando así los procesos y produciendo salidas en milisegundos en lugar de minutos. Los avances en los dispositivos de almacenamiento en línea condujeron a la primera generación de sistemas de gestión de base de datos. El software se caracterizó también como producto y surgen “las casas de software”. El software se desarrollaba para tener una amplia distribución en el mercado. c) Tercera Era. Se caracterizó por la llegada y el amplio uso de los microprocesadores y las computadoras personales, las cuales han sido el catalizador del gran crecimiento de muchas compañías de software. Mientras que las ventas de computadoras personales se estabilizaron hacia la mitad de los ochentas, las ventas de productos de software han continuado creciendo. d) Cuarta Era. En la que nos encontramos ahora. Las técnicas orientadas a los objetos están desplazando rápidamente a enfoques más convencionales en muchas áreas de aplicación. Las técnicas de cuarta generación para el desarrollo de software están cambiando la forma en que algunos segmentos de la comunidad informática construyen los programas de computadora. PRIMERA ERA Orientación por lotes Software a medida Distribución limitada

SEGUNDA ERA Multiusuario Base de datos Software como producto Tiempo real

Tabla 1: Resumen de la primera y segunda era del software

TERCERA ERA Hardware de bajo costo Incorporación de inteligencia Impacto en el consumo

CUARTA ERA Tecnologías orientadas a objetos Sistemas expertos Redes neuronales

los

Tabla 2: Resumen de tercera y cuarta era del software

15

Unidad 2: Introducción a la ingeniería de software

2.3.

Características del software.

Hace veinte años del 1 por 100 de la gente podía describir de forma inteligente lo que significaba “software de computadora”. Para poder comprender lo que es el software (y en consecuencia la ingeniería del software), Es importante examinar las características que lo diferencian de otras cosas que los hombres pueden construir. Cuando se construye hardware, el proceso creativo humano (análisis, diseño, construcción, prueba) se traduce finalmente en una forma física. Si construimos una nueva computadora, nuestro boceto inicial, diagramas formales de diseño y prototipo de prueba, evolucionan hacia un producto físico (pastillas VLSI, tarjetas de circuitos impresos, fuentes de poder, etc.). Pero el software es el elemento del sistema que es lógico, en lugar de físico. Por lo tanto tiene unas características considerablemente distintas a las del hardware. 1. El software se desarrolla, no se fabrica en un sentido clásico. Aunque existen similitudes entre el desarrollo de Ingeniería de software y la construcción del hardware, ambas actividades son diferentes. En las dos la buena calidad se adquiere mediante un buen diseño. Ambas actividades dependen de las personas, pero la gente dedicada y el trabajo realizado es completamente diferente. Ambas actividades requieren la construcción de un “producto”, pero los métodos son no son iguales. 2. El Ingeniería de software no se “estropea”. El hardware exhibe relativamente muchos fallos al principio de su vida (atribuibles a defectos en el diseño o a la fabricación); una vez corregidos los defectos, la tasa de fallos baja a un nivel estacionario donde permanece durante un cierto periodo. Sin embargo conforme pasa el tiempo, los fallos vuelven a presentarse a medida que el Hardware es expuesto a los efectos acumulativos de la suciedad, la vibración, los malos tratos, las temperaturas y otros muchos males externos. Y el hardware empieza a estropearse.

16

Unidad 2: Introducción a la ingeniería de software

El Ingeniería de software no es susceptible a estos males del entorno. Los defectos no detectados harán que falle durante las primeras etapas de su vida. Sin embargo una vez que se corrigen estos bajan a un nivel estacionario. El Ingeniería de software no se estropea, se deteriora. El Ingeniería de software durante su vida sufre cambios (mantenimiento) que hace que se introduzcan nuevos defectos, y conforme se solicitan nuevos cambios se crean nuevos fallos por lo que el nivel mínimo comienza crecer y el Ingeniería de software se va deteriorando debido a los cambios. 3. La mayoría del Ingeniería de software se construye a medida, en vez de ensamblar componentes existentes. Con pocas excepciones, no existen catálogos de componentes de Ingeniería de software. Se puede comprar Ingeniería de software ya desarrollado, pero sólo como una unidad completa, no como componente que puedan reensamblarse en nuevas programas. 2.4.

Mitos del software.

Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software. Mitos De Gestión Los gestores con responsabilidad sobre el software, como los de la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. Mito. Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas; después de todo, les compramos las computadoras más nuevas. Mito. Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido.

17

Unidad 2: Introducción a la ingeniería de software

Mitos Del Cliente Un cliente puede ser una persona del despacho del al lado, del grupo técnico del piso de abajo, del departamento de ventas, etc. Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente quede insatisfecho. Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas, podemos dar los detalles más adelante. Mito. Los requisitos del proyecto cambian continuamente, peor los cambios pueden acomodarse fácilmente, ya que el software es flexible. Mitos De Los Desarrolladores Los mitos en la que aún creen muchos desarrolladores se han fomentado durante cuatro décadas de cultura informática. Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Mito. Lo único que se entrega al terminar el proyecto es el programa funcionando. El reconocimiento de las falacias de los mitos del software es el primer paso hacia la formulación de soluciones prácticas para el desarrollo del mismo. 2.5.

Capas de la ingeniería de software.

La ingeniería de software surge de la ingeniería de sistemas y de hardware. Abarca tres elementos clave: proceso, métodos y herramientas, que facilitan al gestor controlar el proceso de desarrollo del de software y suministrar a los que la practiquen las bases para construir software de alta calidad de una forma productiva. Los métodos indican cómo construir técnicamente el software. Incluyen las tareas de: planificación y estimación de 18

Unidad 2: Introducción a la ingeniería de software

proyectos, análisis de los requisitos del sistema, diseño de estructuras de datos, algoritmos, codificación, prueba y mantenimiento. Las herramientas suministran un soporte automático o semiautomático para los métodos. Cuando las herramientas se integran de forma que la información que cree una de ellas pueda usarla otra, se dice que se ha establecido un sistema para el soporte del desarrollo del software, que con frecuencia se denomina ingeniería del software asistida por computadora. El proceso es el pegamento que junta los métodos y las herramientas y facilita un desarrollo racional y oportuno del Ingeniería de software de computadoras. El proceso del software forma la base para el control de la gestión de los proyectos de software y establece el contexto en el cual se aplican los métodos técnicos, se generan los productos del trabajo (modelos, documentos, datos, reportes, formatos, etcétera), se establecen los fundamentos, se asegura la calidad, y el cambio se maneja de manera apropiada.

Herramientas Métodos Procesos

Un enfoque de calidad

Figura 4: Capas de ingeniería de software (Pressman 6° ed.)

2.6.

El proceso de software.

Un marco de trabajo establece la base para un proceso de software completo al identificar un número pequeño de actividades 19

Unidad 2: Introducción a la ingeniería de software

del marco de trabajo aplicables a todos los proyectos de software, sin importar tamaño o complejidad. Además abarca un conjunto de actividades sombrilla aplicables a lo largo del proceso del software. Actividades del marco de trabajo del proceso general: Comunicación: Esta implica una intensa colaboración y comunicación con los clientes; además abarca la investigación de requisitos y otras actividades relacionadas. Planeación: Establece un plan para el trabajo de la ingeniería del software. Describe las tareas técnicas que deben realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un programa de trabajo. Modelado: Abarca la creación de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlos. Construcción: Combina la generación del código y la realización de pruebas necesarias para descubrir errores en el código. Despliegue: El software se entrega al cliente, quien evalúa el producto recibido y proporciona información basada en su evaluación. Estas cinco actividades genéricas son útiles durante el desarrollo de programas pequeños, la creación de grandes aplicaciones en la red, y en la ingeniería de sistemas basados en computadoras grandes y complejas. Los detalles del proceso del software serán muy diferentes en cada caso, pero las actividades dentro del marco permanecerán iguales. El marco de trabajo descrito en la visión general de la ingeniería de software lo completa una serie de actividades sombrilla. Las actividades típicas en esta categoría incluyen: Seguimiento y control del proyecto de software: permite que el equipo de software evalúe el progreso comparado con el plan del proyecto y así tomar las acciones necesarias para mantener el programa.

20

Unidad 2: Introducción a la ingeniería de software

Gestión del riesgo: evalúa los riesgos que pudieran afectar los resultados del proyecto o la calidad del producto. Aseguramiento de la calidad del software: define y conduce las actividades requeridas para asegurar la calidad del software. Revisiones técnicas formales: evalúa los productos del trabajo de la ingeniería del software en un esfuerzo encaminado a descubrir y eliminar los errores antes de que éstos se propaguen hacia la siguiente acción o actividad. Medición: define y recolecta mediciones del proceso, el proyecto y el producto para ayudar al quipo a entregar software que satisfaga las necesidades del cliente; se puede usar en conjunto con todas las otras actividades del marco de trabajo o actividades sombrilla. Gestión de la configuración del software: maneja los efectos del cambio a través del proceso del software. Gestión de la reutilización: define los criterios para la reutilización de productos de trabajo (se incluyen componentes del software) y establece mecanismos para la creación de componentes reutilizables. Preparación y producción del producto de trabajo: abarca las actividades requeridas para crear productos de trabajo como modelos, documentos, registros, formatos y listas. La aplicación inteligente de cualquier modelo del proceso del software debe reconocer que la adaptación (al problema, proyecto, equipo y a la cultura organizacional) es esencial para el éxito de esta actividad. 2.7.

Software de calidad.

Considerar la calidad del software como importante debe concretarse en entender inicialmente el concepto de “calidad del software”, crear el conjunto de actividades para su implantación, llevar a cabo tales actividades en todo proyecto, utilizar métricas para desarrollar estrategias que mejoren el proceso del software y, como consecuencia, mejoren la calidad el producto final.

21

Unidad 2: Introducción a la ingeniería de software

Una consecuencia indirecta y más importante de no contar con la administración de la calidad es el “inventar el hilo negro” cada vez que se inicia un proyecto de software, se hacen retrabajos, particularmente a niveles abstractos, por ejemplo el no aplicar un método o metodología específica. El uso de estándares ha permitido un entendimiento más claro, o por lo menos, más consistente y un primer acercamiento entre los actores participantes de la industria del software; y dicha tendencia tenderá a incrementarse drásticamente en los siguientes diez años. Aunque el aseguramiento de calidad se llega a considerar importante en el desarrollo de software, se trata con postergamiento y/o con insuficiencia de prioridad y recursos. De tal forma que los proyectos de software terminan fuera de calendario, con aplicaciones no completamente satisfactorias o en un fracaso rotundo. El aseguramiento de calidad (SQA – Software Quality Assurance* *) tiene en sí costos, riesgos y complicaciones. Un programa de aseguramiento de calidad muy complejo o demandante, puede al igual que un proyecto de software, fallar; por lo que se sugiere comenzar con un plan más sencillo que pueda operar y poco a poco ir evolucionando. Uno de los primeros pasos es comprender el concepto de calidad en el software y su administración, la cual contempla el poder establecer metas, actividades y productos entregables, así como, el proceso requerido para lograrlos y una estrategia de desarrollo. La calidad del software Muchas entidades de desarrollo desean producir software de alta calidad, pero ¿qué es la calidad del software? En términos generales podemos definir la calidad del software como “un atributo de los sistemas de software que tienen concordancia con los requisitos definidos explícita e implícitamente”. Entre los principales objetivos del SQA son la confiabilidad, el desempeño, la funcionalidad y el reuso. Y entre los principales 22

Unidad 2: Introducción a la ingeniería de software

elementos para la aplicación de pruebas están la experiencia, guías y estándares, métricas, revisiones, pruebas y el reuso. Las actividades del aseguramiento de la calidad del software contemplan aquellas tareas del proceso de desarrollo de software que buscan asegurar el diseño, desarrollo y distribución de una aplicación exitosa u otra forma de tecnología de software. Ocurre durante todo el proceso de desarrollo, y cada persona involucrada en este proceso tiene un impacto en la calidad de la aplicación resultante, es importante concentrarse que el aseguramiento de la calidad no es una actividad separada que puede obtenerse fuera de la organización. El SQA, como actividad de protección en el proceso de desarrollo, comprende procedimientos para la aplicación efectiva de métodos y herramientas, revisiones técnicas formales, técnicas y estrategias de prueba, dispositivos paka-yoke (es una técnica de calidad desarrollada por el ingeniero japonés Shigeo Shingo en los años 1960´s, que significa "a prueba de errores), procedimientos de control de cambios, procedimientos de aseguramiento de ajuste a los estándares y mecanismos de medida e información. Los principales elementos del SQA son los siguientes: 1. 2. 3. 4.

5.

6.

Definición y experiencia Guías y estándares Métricas Revisiones • Autorevisiones • Revisiones informales • Revisiones de paso • Inspecciones Pruebas • Unitarias • Módulo • Integración • Sistemas Análisis y Reporteo

23

Unidad 2: Introducción a la ingeniería de software

Figura 5: Principales elementos de SQA

Aunque algunas de las actividades de SQA deben ser realizadas por los desarrolladores e ingenieros de software, puede establecerse un grupo SQA en la organización. Las principales actividades de este grupo son: establecer un plan de SQA para los proyectos; participar en el desarrollo de la descripción del proceso de software del proyecto; revisar las actividades de ingeniería de software para verificar su ajuste al proceso definido; auditar los productos de software designados para verificar el ajuste con los definidos como parte del proceso; asegurar que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con un procedimiento establecido y registrar lo que no se ajuste a los requisitos, e informar a los superiores. Asimismo, coordina el control y administración de cambios, aunado a recopilar y analizar las métricas del software. Uno de los elementos importantes del proceso de SQA son las revisiones técnicas, las cuales se constituyen en reuniones conducidas por personal técnico para personal técnico, donde se analizan detalladamente los productos generados, los eventos que surgen en forma imprevista, etc. Para esta etapa el uso de métricas es esencial. Una rama importante de esta disciplina es el SQA estadístico, donde los datos históricos permiten una mejora continua tanto del producto generado en el proyecto, como de proyectos posteriores. Es importante aseverar que la ingeniería de pruebas es otro factor fundamental para el SQA. Muchas de las actividades a realizar deben estar incorporadas al proceso de desarrollo utilizado por la organización; cabe recalcar 24

Unidad 2: Introducción a la ingeniería de software

que primeramente la organización deberá tener definido su proceso o procesos de desarrollo de software. Aunado a ello, si existen herramientas automatizadas que dan soporte al SQA para probar aplicaciones y componentes de éstas, registrando y ejecutando casos de prueba, así como generándolos en forma automática se logra conseguir una productividad alta. Estándares Dado que la calidad del software está presente en todo su proceso de desarrollo, y siendo más precisos, en su ciclo de vida; la presencia de estándares asociados directa e indirectamente son abundantes. ISO (International Standard Organization) ha aportado estándares para la industria del software. Algunos de los más importantes son: 1. ISO 9001. Quality Systems-Model for Quality Assurance in Design, Development, Production, Installation and Servicing. 2. ISO 9000-3. Guidelines for Application of ISO 9001 to the Development, Supply and Maintainance of Software. 3. ISO 9004-2. Quality Management and Quality Systems Elements. Por otro lado, existen estándares internacionales para la administración de proyectos, la cual incrementa en gran medida el obtener productos de software de calidad entre ellos tenemos: 1. CMM Capability Maturity Model. Modelo que permite catalogar a las organizaciones con el nivel de capacidad de madurez de su proceso de desarrollo. 2. TSP Team Software Process. Permite calificar el proceso de desarrollo que se lleva a cabo en los equipos de trabajo o desarrolladores. 3. PSP Personal Software Process. Certifica a un individuo o desarrollador en el nivel de madurez de su proceso de desarrollo. 4. SPICE Software Process Improvement and Capability Determination. Se conforma como el estándar emergente orientado a la mejora continua del proceso de desarrollo de software. Sin embargo, los estándares mencionados recaen en el ámbito formal, particularmente requiriendo tiempos y costos excesivos para pequeñas organizaciones. Para tal efecto, un área 25

Unidad 2: Introducción a la ingeniería de software

emergente en este sentido, orientados a la entrega rápida de resultados, tenemos a los Métodos Ágiles, entre los cuales el más representativo es la Programación Extrema. Algunos contraponen los métodos ágiles contra los formales (CMM, PSP, SPICE, etc.); sin embargo, pueden considerarse los primeros como un punto de partida a los segundos. (Pressman, 5ª ed) http://www.rosenblueth.mx/InterFAR/Vol1Num3/doc/Vol1Num3-49.htm

2.8.

Factores de calidad y productividad.

Para conseguir un proyecto de software fructífero debemos comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, los hitos que hay que recorrer, el esfuerzo (costo) a consumir y el plan a seguir. La gestión del proyecto de software proporciona es conocimiento. Empieza antes que comience el trabajo técnico y culmina sólo en el momento en que se abandona el software. Dado que la gestión del proyecto de software es algo tan importante para el éxito del proyecto, sería razonable suponer que todos los líderes de proyectos saben hacerlo y que todos los desarrolladores saben cómo trabajar dentro de los límites establecidos. Desafortunadamente, la mayoría no lo saben. En los siguientes párrafos se presenta una visión general de los elementos clave de la gestión del proyecto de software. Comienzo del proyecto de software. El desarrollador y el cliente deben ponerse de acuerdo para definir el ámbito y los objetivos del proyecto. Los objetivos identifican los fines globales del proyecto sin considerar como se llegará a esos fines. El ámbito identifica las funciones primordiales que debe llevar a cabo el software y, lo que es muy importante, intenta limitar esas funciones de manera cuantitativa. Una vez que entendidos los objetivos y el ámbito del proyecto, se han de seleccionar el mejor enfoque, dadas las restricciones impuestas por las fechas tope de entrega, los límites presupuestarios, la disponibilidad del personal, etc.

26

Unidad 2: Introducción a la ingeniería de software

Medición y métricas En la mayoría de los desafíos técnicos, la medición y las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso se mide para intentar mejorarlo, y el producto se mide para intentar mejorar su calidad. Estas métricas han sido desarrolladas para proporcionar a los gestores y a los técnicos una mejor comprensión del proceso de la ingeniería del software y del producto que se genera. Estimación Una de las actividades cruciales del proceso de gestión de proyectos de software es la planificación. Cuando se planifica un proyecto de software se tienen que obtener estimaciones de esfuerzo humano requerido (normalmente en personas-mes), de la duración cronológica del proyecto (en fechas) y del costo (en dólares). Pero ¿Cómo se hace? En muchos casos, las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un nuevo proyecto es similar en tamaño y función a un proyecto pasado, es probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente el mismo tiempo y que cueste aproximadamente lo mismo que el trabajo anterior. Pero ¿qué pasa si el proyecto es totalmente distinto? Entonces, puede que la experiencia no sea suficiente. Se han desarrollado varias técnicas de estimación para el desarrollo de software. Aunque cada una tiene sus puntos fuertes y sus puntos débiles, todas tienen en común los siguientes atributos. • Se ha de establecer de antemano el ámbito del proyecto. • Como base para la realización de estimaciones, se usan las métricas del software (mediciones del pasado). • El proyecto se desglosa en partes más pequeñas que se estiman individualmente. Es recomendable aplicar varias técnicas diferentes de estimación, utilizando unas para verificar los resultados de las otras.

27

Unidad 2: Introducción a la ingeniería de software

Métricas para la productividad y la calidad del software La medición es fundamental para cualquier disciplina de ingeniería y la ingeniería de software no es la excepción. Las métricas del software se refieren a un amplio rango de medidas para el software de computadoras. Dentro del contexto de la planificación del proyecto, nos preocupamos principalmente por las métricas de productividad y calidad. Medición del software La medición es muy común en el mundo de la ingeniería. Medimos potencias de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruido, etc. La lista es interminable, desgraciadamente, la medición se aleja de lo común en el mundo de la ingeniería de software. Encontramos dificultades en ponernos de acuerdo sobre que medir y cómo evaluar las medidas. Hay varias razones por las que medir el software: 1. Para indicar la calidad del producto. 2. Para evaluar la productividad de la gente que desarrolla el producto. 3. Para evaluar los beneficios (en términos de calidad y productividad) derivados del uso de nuevos métodos y herramientas de ingeniería de software. 4. Para establecer una línea de base para la estimación. 5. Para ayudar a justificar el uso de nuevas herramientas. Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas (por ejemplo, la longitud de un tornillo) y medidas indirectas (por ejemplo, la calidad de los tornillos producidos, medida por el porcentaje de tornillos rechazados). Las métricas del software pueden ser catalogadas de forma parecida. Entre las medidas directas del proceso de ingeniería de software se encuentran el costo y el esfuerzo aplicado. Entre las medidas directas del producto se encuentran las líneas de código (LDC) producidas, la velocidad de ejecución, el tamaño de memoria y los defectos observados en un período de tiempo. Entre las medidas indirectas del producto se encuentran funcionalidad,

28

Unidad 2: Introducción a la ingeniería de software

calidad, complejidad, mantenimiento, etc.

eficiencia,

fiabilidad,

facilidad

de

El costo y esfuerzo requeridos para construir software, el número de líneas de código y otras medidas directas son relativamente fáciles de obtener, siempre que se haya establecido un convenio específico de medidas. La calidad y funcionalidad son más difíciles de evaluar y sólo se pueden medir de forma indirecta. Métricas orientadas al tamaño Se utilizan para obtener mediadas directas del resultado y la calidad de la ingeniería del software. Son medidas directas del software y del proceso por el cual se desarrolla. Si una organización de software mantiene un registro sencillo, se puede crear una tabla de datos orientados al tamaño. Ejemplo: Proyecto Esfuerzo aa-01 cc-04 ff-03

24 62 43

$

KLDC

168 440 134

12,1 27,2 20,2

Págs. doc. 365 1224 1050

Errores

Gente

29 86 64

3 5 6

Tabla 3: Ejemplo de bitácora

Con los datos contenidos en la tabla se pueden desarrollar, para cada proyecto, un conjunto de métricas sencillas de productividad y calidad orientadas al tamaño.

Productividad = KLDC/personas-mes

Calidad = errores/KLDC

Además se pueden medir otras métricas interesantes:

Costo = Dólares/KLDC

29

Unidad 2: Introducción a la ingeniería de software

Documentación = Páginas de documentación/KLDC Métricas orientadas a la función Las métricas del software orientadas a la función son medidas indirectas del software y del proceso por el cual se desarrollan. En lugar de calcular las LDC, las métricas orientadas a la función se centran en la “funcionalidad” o “utilidad” del programa. Esta métrica sugiere una medida de productividad denominada Punto de función.

Los puntos de función se calculan rellenando la tabla que se muestra enseguida: Parámetro de medida Número de entradas de usuario Número de salidas de usuario Número de peticiones de usuario Número de archivos Número de interfaces externos

Cuenta

Simple

Medio

Complejo

x

3

4

6

x

4

5

7

x

3

4

6

x

7

10

15

x

5

7

10

Total

Cuentatotal

Tabla 4: Computación de métricas de punto de funciones

Se determinan cinco características del ámbito de la información y los cálculos aparecen indicados en la posición apropiada de la tabla. Los valores del ámbito de la función están definidos de la siguiente manera.

30

Unidad 2: Introducción a la ingeniería de software

Número de entradas de usuario: Se cuenta cada entrada de usuario que proporciona al software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas de las peticiones, que contabilizan por separado. Número de entradas de usuario: Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Número de peticiones al usuario: Una petición está definida como una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. Número de archivos: Se cuenta cada archivo maestro lógico (o sea, una agrupación lógica de datos que puede ser una parte de una gran base de datos o un archivo independiente). Número de interfaces externas: Se cuentan todas las interfaces legibles por la máquina (por ejemplo, archivos de datos en disco) que son utilizados para transmitir información a otro sistema. Cuando han sido recogidos los datos anteriores, se asocia un valor de complejidad de a cada cuenta. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada es simple, media o compleja. No obstante la determinación de la complejidad es algo subjetivo. Para calcular los puntos de función, se utiliza la siguiente relación. PF = Cuenta-total x [0.65 + 0.01 x SUM(Fi)] Donde Cuenta-total es la suma de todos los parámetros de medias de la tabla. Fi (i = 1 hasta 14) son los “valores de ajuste de complejidad” basados en las respuestas a las cuestiones señaladas a continuación. 1. Requiere el sistema copias de seguridad y de recuperación fiables. 2. Se requiere comunicación de datos. 3. Existen funciones de procesamiento distribuido. 31

Unidad 2: Introducción a la ingeniería de software

4. Es crítico el rendimiento. 5. Será ejecutado el sistema en un entorno operativo existente y fuertemente utilizado. 6. Requiere el sistema entrada de datos interactiva. 7. Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas o variadas operaciones. 8. Se actualizan los archivos maestros de forma interactiva. 9. Son complejas las entradas, las salidas, las peticiones o los archivos. 10. Es complejo el procesamiento interno. 11. Se ha diseñado el código para ser reutilizable. 12. Están incluidas en el diseño la conversión y la instalación. 13. Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones. 14. Se ha diseñada la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario. Los valores constante de la ecuación y los factores de peso aplicados a las cuentas de ámbito de información han sido de terminados empíricamente. Una vez calculados los puntos de función, se usan de forma análoga a las LDC como medida de la productividad, de la calidad y otros atributos del software. Productividad = PF/personas-mes Calidad = errores/PF Costo = Dólares/PF

Documentación = Páginas de documentación/PF La relación entre líneas de código y puntos de función depende del lenguaje de programación que se utilice para implementar el software y la calidad del diseño. La siguiente lista proporciona estimaciones informales del número medio de líneas de código requerido para construir un punto de función en varios lenguajes de programación.

32

Unidad 2: Introducción a la ingeniería de software

Lenguaje de programación Ensamblador COBOL FORTRAN Pascal Ada Lenguajes orientados a objetos Lenguajes de cuarta generación (L4G9 Generadores de código

LDC/PF (media) 300 100 100 90 70 30 20 15

Tabla 5: Número medio de LDC para construir un punto de función.

Integración de las métricas dentro del proceso de la ingeniería de software es muy importante. La mayoría de los que desarrollan software no miden y, desgraciadamente, la gran mayoría tiene pocas ganas de hacerlo. El problema es cultural. El intentar reunir medidas donde nadie las ha reunido anteriormente se encuentra frecuentemente con una cierta resistencia. ¿Por qué es tan importante medir el proceso de ingeniería del software y producto (software) que produce? la respuesta es relativamente obvia. Si no medimos, no hay forma de determinar si estamos mejorando. Y si no estamos mejorando estamos perdidos. La medición es una de tantas medicinas que pueden ayudar a curar el mal del software ya que proporciona beneficios a nivel estratégico, a nivel de proyecto y a nivel técnico. Mediante la obtención y la evaluación de medidas de calidad y de productividad, los directivos de gestión pueden establecer objetivos significativos para mejorar el proceso de ingeniería del software. Pero, para establecer estos objetivos de mejora, se tiene que entender el estado actual del desarrollo del software. Por eso, la medición se utiliza para establecer una línea base del proceso a partir del cual se puedan evaluar las mejoras. Mediante el establecimiento de una línea base para las métricas, se pueden obtener beneficios a nivel estratégico, de proyecto y técnico. La línea base consiste en datos recogidos de anteriores proyectos de desarrollo de software y puede ser tan sencilla como la tabla en la que se registran los datos del proyecto como el nombre, esfuerzo, páginas documentadas, errores, gente, etc. Además de simples medidas orientadas al tamaño o a la función.

33

Unidad 2: Introducción a la ingeniería de software

Para que sea una ayuda efectiva, la línea base tiene que poseer los siguientes atributos: 1. Los datos deben ser razonablemente precisos, han de evitarse suposiciones de proyectos anteriores. 2. Los datos deben obtenerse de tantos proyectos como sea posible. 3. Las medidas deben ser consistentes (por ejemplo las LDC deben interpretarse de igual forma para todos los proyectos.) 4. Las aplicaciones deben ser similares a la que vaya a ser estimada. (Pressman 4° y 6° ed. )

34

Unidad 3: Paradigmas de la ingeniería de software

UNIDAD 3.- Paradigmas de la ingeniería de software. Objetivo Educacional Comprenderá la diferencia de aplicar un enfoque estructurado vs. orientado a objetos en el desarrollo de un proyecto de software.

3. Paradigmas de la ingeniería de software. La ingeniería de software esta compuesta por una serie de pasos de abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos. Gama de paradigmas de la ingeniería de software, algunos con enfoque estructurado y otros orientados a objetos:

Figura 6: Gama de paradigmas de ingeniería de software

35

Unidad 3: Paradigmas de la ingeniería de software

3.1. El enfoque estructurado. 3.1.1. Diagramas de flujos de datos. Modelado de las Funciones del Sistema. Diagrama de Flujo de Datos. Ilustra las funciones que el sistema debe realizar. Podría describirse como ¿qué transformaciones debe llevar a cabo el sistema? ¿Qué entradas se Transforman en qué salidas? Entre otras. Los diagramas de flujo de datos consisten en procesos, agregados de datos y terminadores: Los procesos se representan por medio de círculos, o 'burbujas' en el diagrama. Representan las funciones individuales que el sistema lleva a cabo. Las funciones transforman entradas en salidas. Los flujos se muestran por medio de flechas curvas, son conexiones entre los procesos y representa la información que dicho proceso necesita como entrada o genera como salida. Los agregados de datos se representan por medio de dos líneas paralelas o mediante una elipse. Muestran colecciones de datos que el sistema debe recordar por un período de tiempo. Cuando los diseñadores de sistema y programadores terminen de construir el sistema, estos serán archivos o bases de datos. Los terminadores muestran la entidad externa con la que el sistema se comunica, típicamente son individuos; grupos de personas; organizaciones externas; otros sistemas, etc. (Edward Yourdon)

36

Unidad 3: Paradigmas de la ingeniería de software

Figura 7: Ejemplo de DFD recepción de pedidos

El diagrama de flujo de datos proporciona una visión global de los componentes funcionales del sistema, pero no da detalles de estos. Para mostrar detalles acerca de que información se transforma y como se transforma, se ocupan dos herramientas textuales de modelado adicionales: el Diccionario de Datos y la Especificación de Procesos. ¿Qué es un Diagrama de Flujo? Es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por conductos y tanques de almacenamiento de datos. Proporciona un punto de vista de un sistema, el orientado a funciones.

37

Unidad 3: Paradigmas de la ingeniería de software

Podemos encontrarlo en la literatura con los siguientes sinónimos: • Carta de burbujas. • DFD (abreviatura que usaremos). • Diagrama de burbujas. • Modelo de proceso. • Diagrama de flujo de trabajo. • Modelo de función. • Una imagen de lo que sucede. Guía para la construcción de un DFD. Algunas de estas reglas ayudan a no elaborar un DFD erróneo (como incompleto o inconsistente). Además puede ayudarle a que aumentar las probabilidades de que el usuario lo lea con mas cuidado. Las Reglas incluyen las siguientes:

•

Elegir nombres con significado para los procesos, flujos, almacenes y terminadores. • Numerar los procesos. • Redibujar el DFD tantas veces como sea necesario estéticamente. • Evitar los DFD demasiado complejos. • Asegurarse de que el DFD sea internamente consistente y que también lo sea con cualquier DFD relacionado con él. • Elegir nombres con significado para los procesos, flujos, almacenes y terminadores • Un proceso en un DFD puede identificar una función que se está llevando a cabo, o puede identificar como se está llevando a cabo identificando a la persona o grupo; en este último caso identifique la tarea que se realiza no nombres de personas. • Etiquete los procesos de manera que se puedan identificar las funciones que el sistema está llevando a cabo. Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un objeto. Es decir, elegir un verbo activo y un objeto apropiado para formar una frase descriptiva para el proceso.

38

Unidad 3: Paradigmas de la ingeniería de software

Ejemplos de nombres de procesos:

• • • •

CALCULAR TRAYECTORIA DE PROYECTIL. PRODUCIR INFORME DE INVENTARIO. VALIDAR NUMERO TELEFONICO. ASIGNAR ESTUDIANTE A LA CLASE.

Figura 8: Ejemplo de nombre inválido de procesos

Pedro nombre inválido para un proceso.

Figura 9: Ejemplos de nombre válido de procesos

Resultará fácil utilizar verbos y objetos específicos si el proceso es relativamente simple y está bien definido. Sin embargo, 39

Unidad 3: Paradigmas de la ingeniería de software

aún en casos sencillos hay tentación por utilizar nombres ambiguos como: HACER, MANEJAR y PROCESAR. Cuando se utilizan verbos tan elásticos (con significados para cubrir casi cualquier situación) a menudo significa que el analista no está seguro de cual función se está llevando a cabo o que se han agrupado diversas funciones que en realidad no debieran agruparse. Estos son algunos nombres de proceso no adecuados: HACER ALGO. MANEJAR ENTRADAS. ENCARGARCE DE PROCESOS. EDICIÓN GENERAL. Los nombres de procesos (al igual que los nombres de flujos y terminadores) deben provenir de un vocabulario que tenga algún significado para el usuario. Esto sucederá de manera muy natural si el DFD se dibuja como resultado de una serie de entrevistas con los usuarios y si el analista tiene algún entendimiento mínimo de la materia de aplicación. Debe tener en cuenta dos precauciones:

•

Evitar en lo posible el uso de abreviaturas y acrónimos específicos con los que están familiarizados los clientes (Ej. Consigue copia de la forma 107, forma rosada y se la manda a José una vez llena). Una buena forma de evitarlo es elegir (como LLENAR) y objetos (como FORMA 107) que tendría sentido para alguien que trabaje en la misma industria, pero en una organización diferente. • Si el DFD lo dibuja alguien con conocimientos en programación habrá tendencia a utilizar terminología orientada a la programación, tal como RUTINA, PROCEDIMIENTO, FUNCION, aunque muchos términos no tienen significado para el usuario. Evite usarlos a menos que el usuario los maneje. Numerar los procesos. Es una buena forma de referirse a los procesos de un DFD. No importa como se haga esta numeración, de izquierda a derecha, de arriba abajo, mientras haya constancia en la forma de aplicar los números. Lo que deberá tener en cuenta es que para algunos lectores del DFD la numeración implicará secuencia, podría preguntarle ¿la burbuja 1 sucede primero y luego la 2?. Esto no es así en absoluto, 40

Unidad 3: Paradigmas de la ingeniería de software

el modelo de DFD es una red de procesos asincrónicos que se intercomunican; representan la manera en que en realidad muchos sistemas operan. Alguna secuencia podría implicarse por la presencia por la presencia o secuencia de datos (Ej. Puede resultar que la burbuja 2 no pueda realizar su función hasta que no reciba datos de la burbuja1) pero el esquema de numeración no tiene nada que ver con eso. Entonces, para que numerar los procesos; primero para poder referirnos en una discusión a una burbuja por su número en vez de por su nombre. En segundo lugar, y más importante aún, los números se convierten en base para la numeración jerárquica cuando se introduzcan diagramas de flujos por niveles. Redibujar el DFD estéticamente.

tantas

veces

como

sea

necesario

En un proyecto real de análisis de sistema, el DFD se dibujará tantas veces como se necesite antes de: ser técnicamente correcto, ser aceptable para el usuario, estar lo suficientemente bien dibujado como para que no embarazoso mostrarlo a la dirección de la organización. ¿Qué hace estéticamente agradable un DFD? Tamaño y forma de las burbujas, procure que estas sean similares en tamaños para no crear confusiones acerca de importancia de un proceso en el proyecto. Otras organizaciones preferirán óvalos en vez de círculos. Flujos Curvos vs. Rectos, sería lo ideal conocer que opción prefiere el observador; para muchos será lo mismo para otros no, lo mismo sucede con las flechas cruzadas. Evitar los DFD demasiado complejos. El propósito de un DFD es modelar de manera precisa las funciones que deberán llevar a cabo un sistema y las interacciones entre ellas. Otro propósito de este es ser leído y comprendido, no sólo por quien construye el modelo sino también por los usuarios que participan. Entonces el diagrama deberá: ser fácilmente entendido, fácilmente asimilado y placentero a la vista.

41

Unidad 3: Paradigmas de la ingeniería de software

Una regla importante a tener en cuenta es la de no crear DFD con demasiados procesos, flujos, almacenes y terminadores. Por lo general no debiera haber más de media docena de procesos, flujos, almacenes y terminadores relacionados en un mismo diagrama. Otra regla dice que el DFD deberá caber fácilmente en una hoja normal. Asegurarse de que el DFD sea internamente consistente y que también lo sea con cualquier DFD relacionado con él. Las principales reglas para asegurar la consistencia de un DFD son:

•

Evite sumideros infinitos, burbujas que tienen entradas pero no salidas. • Evite burbujas de generación espontánea, que tienen salidas sin tener entradas; son generalmente erróneas. • Cuidado con flujos y procesos no etiquetados, suele indicar falta de esmero; pero peor aún confusión respecto a la información que contienen. • Cuidado con almacenes de solo lectura o solo escritura, esta regla es similar a la de los procesos de solo entradas o solo salidas, los almacenes comunes deben tener tanto entradas como salidas. La única excepción son los almacenes externos que sirve de interfaz entre el sistema y algún terminador externo. DFD por Niveles. Anteriormente se sugirió que debían evitarse los DFD demasiado complejos, pero si el sistema es intrínsecamente complejo y tiene decenas o incluso cientos de funciones que modelar ¿qué debemos hacer? La respuesta es organizar el DFD global en una serie de niveles de modo de que cada uno proporcione sucesivamente más detalles sobre una porción del nivel anterior. El DFD de primer nivel consta de solo una burbuja, que representa el sistema completo; los flujos de datos muestran las interfaces entre el sistema y los terminadores externos (junto con los almacenes externos que podría haber). Este DFD se conoce como Diagrama de Contexto.

42

Unidad 3: Paradigmas de la ingeniería de software

El DFD que sigue del diagrama de contexto se conoce como la figura 0. Representa la vista de más alto nivel de las principales funciones del sistema, al igual que sus principales interfaces. Los números en las burbujas sirven también para relacionar una burbuja con el siguiente nivel de DFD, que la describe más a fondo. Ejemplo: la burbuja 3 de la figura 0 se asocia con un DFD inferior, conocido como figura 1, las burbujas de la figura 1 se numeran 3.1, 3.2, 3.3, etc. Si una burbuja tiene nombre (debe tenerlo), este se utiliza en la figura de nivel inmediato inferior como nombre de la figura. Ejemplo: si la burbuja 2.2, se llama CALCULAR IMPUESTO DE VENTA, entonces la figura 2.2, que parte la burbuja 2.2 en más detalle debe etiquetarse ‘figura 2.2: CALCULAR IMPUESTO DE VENTA’. Esta es una buena manera de organizar un DFD bastante grande en un grupo de piezas manejables. Ahora, existen aspectos importantes que debemos conocer al trabajar con niveles: ¿Cuántos niveles debe tener un DFD? Como se dijo antes en la construcción de DFD no complejos; cada DFD debe tener en lo posible, hasta 6 burbujas y almacenes relacionados. Si se ha partido un sistema grande en tres niveles, pero sus DFD de nivel más bajo contiene 20 burbujas, entonces falta un nivel más por lo menos. Existe otro consejo para la miniespecificación de proceso de una burbuja de nivel más bajo y es que sino podemos escribirla razonablemente en una hoja, entonces es muy compleja y necesitamos un nivel más. ¿Existen reglas acerca del número de niveles de un sistema típico? En un sistema simple, se encontraran probablemente dos o tres niveles; uno mediano, tendrá generalmente de tres a seis niveles y uno grande, tendrá de cinco a ocho niveles. Recuerde que, él número total de burbujas tiene un crecimiento exponencial a medida que descendemos de nivel.

43

Unidad 3: Paradigmas de la ingeniería de software

¿Deben partirse todas las partes del sistema con el mismo nivel de detalle? No, algunas partes del sistema pueden ser más complejas que otras y pueden requerir uno o más niveles de partición. ¿Cómo se muestran estos niveles al usuario? Muchos usuarios querrán ver solo un diagrama: un usuario ejecutivo de alto nivel puede querer ver solo el diagrama de contexto, otro más operacional solo la parte que lo involucra. Pero si alguien desea ver con más detalle el sistema, entonces tendrá sentido mostrar los diagramas de manera descendente; comenzando con el diagrama de contexto hasta el nivel más bajo de detalle. ¿Cómo asegurarse de que los niveles de DFD serán consistentes entre sí? Este suele ser un tema crítico ya que en un gran proyecto podrían estarse encargando distintas personas de cada nivel. Para asegurarnos existe una regla sencilla: los flujos de datos que entran y salen de una burbuja en un nivel dado deben corresponder con los que entran y salen en toda la figura en el nivel inmediato inferior que la describe. ¿Cómo se muestran los almacenes en los distintos niveles? Aquí la redundancia se introduce deliberadamente. La regla es mostrar el almacén más alto donde sirve de interfaz entre dos o más burbujas; luego mostrarlo en cada diagrama de nivel inferior que describa más a fondo dicha burbuja de interfaz. Ahora, como corolario decimos: los almacenes locales que utilicen solo las burbujas en una figura de menor nivel, no se muestra en el nivel superior; puesto que se incluye de manera implícita en un proceso de un nivel inmediato superior. http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/anexos/fluj o.htm

44

Unidad 3: Paradigmas de la ingeniería de software

Ejemplo de DFD por niveles.

Figura 10: Diagrama de contexto

Figura 11: Diagrama de nivel 0

45

Unidad 3: Paradigmas de la ingeniería de software

Figura 3.6: Diagrama de nivel 1

3.1.2. Diccionarios de datos. ¿Porque se necesita un Diccionario de Datos en un proyecto de desarrollo de sistemas? No posee el atractivo gráfico de los diagramas; pero sin él, el modelo de los requerimientos del usuario no puede considerarse completo. Es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos internos. El diccionario de datos define los datos haciendo lo siguiente:

•

Define el significado de los flujos y almacenes que se muestran en el DFD. • Describe la composición de agregados de paquetes de datos que se muestran a lo largo de flujos, paquetes complejos (ej. Domicilio de un cliente), que pueden descomponerse en unidades más elementales (como ciudad, estado y código postal). • Describe la composición de los datos en los almacenes. • Especifica los valores y unidades relevantes de piezas elementales de información en los flujos de datos y en los almacenes de datos.

46

Unidad 3: Paradigmas de la ingeniería de software

•

Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad – relación. Notación del Diccionario de Datos. Existen muchos esquemas de notación comunes utilizados por los analistas de sistemas. El que se muestra a continuación es uno de los comunes y utiliza varios símbolos sencillos: = esta compuesto de +y ( ) optativo (puede estar presente o ausente) {} iteración [ ] seleccionar una de varias alternativas ** comentario @ identificador campo clave para almacén | separa opciones alternativas en la construcción Como mostrar el diccionario de datos al usuario. El diccionario de datos lo crea el analista durante el desarrollo del modelo del sistema, pero el usuario debe ser capaz de leerlo y entenderlo para poder verificar el modelo. La aceptación del usuario de la notación del diccionario, es todo un tema; puesto que esta se ve algo matemática; pero el número de símbolos que el debe aprender es muy pequeño. Es muy difícil en realidad que el usuario quiera verificar el diccionario de datos; lo más probable es que verifique que el diccionario es correcto en conjunto con el DFD. Implantación del Diccionario de Datos. Ahora le sugerimos solo algunos de los tantos aspectos que es necesario recordar para la construcción de un buen Diccionario de Datos. Muchos dependen de la herramienta que estemos utilizando para la confección.

•

Puede verse forzado a limitar los nombres de los datos a una cierta longitud. En este caso utilice abreviaturas representativas y claras. • Puede que no le permita utilizar símbolos como – y deba utilizar _. O pude que le exija utilizar prefijos en todos los nombres. 47

Unidad 3: Paradigmas de la ingeniería de software

•

Puede verse obligado a asignar atributos físicos (como número de bytes, etc.). • No utilice acentos, muchas herramientas hacen distinción; al igual que de mayúscula y minúscula. • Puede que esté obligado a no dejar espacios en blanco entre palabras, en estos casos utilice guión bajo (_). Ejemplo Diccionario de Datos: NOMBRE del cliente = tratamiento de cortesía o titulo + nombre + apellido Tratamiento de cortesía o título = [Sr. | Srta. | Sra. | Dr. | Prof.] Nombre = {carácter valido} Apellido = {carácter valido} Carácter válido = [A - Z| a -z| ´| - |] http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/cap2.htm# DE

3.1.3. Diseño de módulos. Diseño de módulos o Diagramas de Estructuras. Estos diagramas muestran tanto jerarquía funcional como las interfaces de los datos entre los componentes. Los principales componentes son:

• •

El rectángulo. Las flechas.

El rectángulo en un diagrama de estructura no representa una declaración sino que representa un módulo. Las flechas que conectan los módulos representan llamados de sub- rutinas; la notación implica que una sub- rutina terminará o regresará a donde se llamó cuando termine de realizar su función. Además, existen aquí dos tipos adicionales de flechas con un círculo en uno de sus extremos, que representan la transferencia de datos y la transferencia de información de control.

48

Unidad 3: Paradigmas de la ingeniería de software

Figura 12: Principales componentes

Los módulos dan una idea clara y sintética de la función que realiza. La lectura de los diagramas de estructura se realiza de izquierda a derecha y de arriba hacia abajo. Dependiendo de la herramienta que se utilizando para el diseño, se permite utilizar una u otra simbología; aquí se presentan símbolos que podríamos llamarlos estándar de modelado que se agregan a los anteriores.

Figura 13: Símbolos estándar de modelado

Cada Diagrama de Estructura, representa una burbuja del DFD. Por lo tanto es necesario que antes de pasar a confeccionar el diagrama tengamos en cuenta las siguientes consideraciones. La confección del diagrama de estructura debe confeccionarse luego de haber realizado el modelamiento explicado en la parte introductoria de este capítulo, lo que implica revisión, análisis y confección de los diagramas ya terminados en la etapa de análisis. 49

Unidad 3: Paradigmas de la ingeniería de software

Se debe tener en cuenta que la lógica de cada diseñador se expresa en la confección del diagrama de estructura, por lo tanto se irá desde los más secuenciales hasta los más estructurados; por lo tanto se puede decir que hay normas estrictas que indican una única forma de realizarse lo importante es que lo mismos sean claros, consistentes y representen realmente las rutas que seguirá luego el código del sistema mismo. De esta manera podrá ser entendido por el cliente, aunque este no querrá verlo, pero si debe ser entendido por otro colega si fuera necesario; al igual que un plano puede ser comprendido por otro arquitecto, esa es la idea. Seguidamente se presentan tres ejemplos de diagrama de estructura, el primero figura 14 representa la pantalla principal del sistema con su menú principal, primer caso: un diagrama principal refiriéndose a cada opción del sistema como página, el segundo figura 15 es el diagrama de una opción de menú, segundo caso: un diagrama principal refiriéndose a cada opción del sistema de manera más específica. Se debe tener en cuenta que en el modelado cada opción del sistema es conocida como página. El tercero Figura 16: un diagrama específica una opción completa del sistema, tercer caso.

Figura 14: Primer caso

50

Unidad 3: Paradigmas de la ingeniería de software

Figura 15: Segundo caso

51

Unidad 3: Paradigmas de la ingeniería de software

Figura 16: Tercer caso

http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/anexos/estructura.htm

3.1.4. Descomposición de procesos. No se hará aquí una investigación profunda, puesto que no es nuestro eje central, pero se resaltarán las principales características del tema. ¿Qué es la descomposición del proceso? La descomposición o especificación del proceso es la descripción de lo que sucede en cada burbuja primitiva de nivel más bajo en un DFD. También se las conoce como Miniespecificación. El propósito de una descomposición del proceso es bastante claro: define lo que debe hacerse para transformar entradas en salidas. Es una descripción detallada de la política de negocios del usuario que cada burbuja lleva a cabo.

52

Unidad 3: Paradigmas de la ingeniería de software

Deberá cumplir con los siguientes requerimientos: • La descomposición del proceso debe expresarse de una manera que puedan verificar tanto el usuario como el analista. Por esto se evita el lenguaje narrativo como herramienta de descomposición, suele confundir cuando expresa condiciones booleanas compuestas (combinadas con AND, OR y NOT). • El proceso debe descomponerse en una forma que pueda ser comunicada efectivamente al público amplio que este involucrado. Puede suceder con tablas de decisiones, con el lenguaje estructurado o con otras herramientas de descomposición; en gran medida dependerá del humor o la personalidad de los usuarios con los usuarios con los que trate. La confección de la descomposición del proceso es una tarea difícil, puesto que el usuario suele describir la descomposición en términos en los que la lleva a cabo en la actualidad. Su trabajo será destilar de esto la esencia de lo que dicha política es no como se lleva a cabo hoy en día. Una buena herramienta no debe imponer (o implicar) decisiones de diseño e implantación arbitraria. Herramientas Principales de Descomposición de Proceso. 1. Lenguaje Estructurado (español, ingles, etc.). 2. Pre/Post condiciones. 3. Tablas de Decisión. a) Lenguaje Estructurado. Es el lenguaje español (ingles u otro) con estructura. Es un subconjunto de todo el idioma con importantes restricciones sobre el tipo de frases que pueden utilizarse y la manera en que puedan juntarse dichas frases. Los verbos deben elegirse de un pequeño grupo de verbos orientados a la acción como: Conseguir (o aceptar o leer). Dividir. Poner (o mostrar o escribir). Calcular. Encontrar (buscar o localizar). 53

Unidad 3: Paradigmas de la ingeniería de software

Borrar. Sumar. Encontrar. Restar. Validar. Multiplicar. Mover. Reemplazar. Fijar. Ordenar. Los objetos (el tema de las frases imperativas sencillas) deben consistir solo en datos definidos en el diccionario o en términos locales. Los términos locales son aquellos que se definen explícitamente en una descomposición de proceso individual, son solo conocidos, relevantes y con significado dentro de dicha descomposición de proceso. Un ejemplo es un cálculo intermedio que se produce para una salida final del proceso. El lenguaje estructurado permite que se combinen frases en unas cuantas formas limitadas que se toman de las construcciones de la programación estructurada.

•

La construcción SI-ENTONCES-OTRO se utiliza para describir frases alternativas que se deben realizar según el resultado de la decisión binaria. • La construcción CASO se utiliza para describir frases alternativas que se efectuarán basándose en los resultados de una decisión multivaluada. • La construcción HACER-MIENTRAS se usa para describir una frase que deberá llevarse a cabo repetitivamente hasta que alguna condición booleana se haga verdadera. Una variante es REPITEHASTA. Desventaja. La principal desventaja del lenguaje estructurado es que si el analista compone una descomposición de proceso demasiado compleja para ser entendida y verificada por el usuario, entonces falló. Para evitar esto se sugieren las siguientes reglas:

54

Unidad 3: Paradigmas de la ingeniería de software

•

Restrinja la descomposición de proceso a una página de texto (66 líneas), si ocupa más de una página seguramente el proceso es muy complejo y debe partirse en un nivel más. • No permita más de tres niveles de anidamiento. • Evite confusión en los niveles de anidamiento utilizando sangrías. Ejemplo: Gran-total=0 HACER-MIENTRAS haya mas pedidos que procesar Total_de_pedidos = 0 LEER el siguiente pedido de PEDIDOS HACER-MIENTRAS haya mas artículos en el pedido Total_de_pedidos = Total_de_pedidos + numero_de_articulos FIN HACER MOSTRAR numero_de_pedido, Total_de_pedidos Gran_total = gran_total + total_de_pedidos FIN HACER MOSTRAR gran_total b) Pre/Pos condiciones. Las pre/pos condiciones son una manera conveniente de describir la función que debe realizar el proceso, sin decir mucho del algoritmo que se utilizará. Uno de los aspectos que la haría útil es cuando el analista está razonablemente seguro de que existen muchos algoritmos distintos que podrían utilizarse. Las pre- condiciones describen todas las cosas que deben darse antes de que el proceso pueda comenzar a ejecutarse. Describirán lo siguiente:

• • •

Que entradas se encuentran disponibles. Que relación debe existir entre las entradas. Que relación debe existir entre entradas y almacenes de datos. • Que relaciones deben existir entre diferentes almacenes o dentro de un almacén dado.

55

Unidad 3: Paradigmas de la ingeniería de software

De manera similar, las post- condiciones describen lo que debe darse cuando el proceso ha concluido. Típicamente describen:

• •

Las salidas que generará o producirá el proceso. Las relaciones que existirán entre los valores de salida y los valores originales de entrada al proceso. • Las relaciones que existirán entre los valores de salida y los valores en uno o varios de los almacenes. • Los cambios que se hayan dado en los almacenes. Ejemplo de descomposición narrativa. Precondición 1 El comprador llega con un número_de_cuenta que Corresponde con un número de cuenta en CUENTAS, Cuyo código_de_status se pone en "válido". Postcondición 1 Se produce una factura con número_de_cuenta y monto_de_venta Precondición 2 La precondición 1 falla por algún motivo (el numero_de_cuenta no se encuentra en CUENTAS, o él código_de_status no es "valido") Postcondición 2 Se produce un mensaje de error. http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/anexos/flujo.htm

c) Tablas de Decisión. Una tabla de decisiones es una tabla de renglones y columnas que contiene cuatro cuadrantes. El cuadrante superior izquierdo contiene la condición, el cuadrante superior derecho opciones a la condición. La mitad inferior de la tabla contiene las acciones que se van a tomar (en el extremo izquierdo) y las reglas para ejecutar las acciones (en el derecho). Cuando una tabla de decisiones se utiliza 56

Unidad 3: Paradigmas de la ingeniería de software

para determinar las acciones que se llevaron a cabo, la lógica sigue el sentido del reloj, comenzando en el extremo superior izquierdo.

TABLA DE DECISIONES Condiciones y acciones Reglas

Condiciones

Alternativas de la condición

Acciones

Registro de las acciones

Figura 17: Tabla de decisiones.

Para construir tablas de decisión, el analista necesita definir el tamaño máximo de la tabla, eliminar cualquier situación imposible, inconsistencia o redundancia y simplificar la tabla mejor posible. Los siguientes pasos proveen al analista de un método sistemático para el desarrollo de tablas de decisiones: Determine el número de condiciones que pudieran afectar la decisión. Combine renglones que se sobrepongan. El número de condiciones será igual al número de renglones presentes en la mitad superior de la tabla de decisiones. • Determine el número de acciones posibles que puedan realizarse. Este será igual al número de renglones de la parte inferior de la tabla de decisiones. • Determine el número de opciones para cada condición. En la forma más sencilla, habrá dos alternativas (S o N) para cada condición. En una tabla de tipo extendida, puede llegar a haber muchas opciones para cada condición. • Calcule el número máximo de columnas de la tabla de decisiones multiplicando el número de alternativas para cada condición. Si fueran cuatro condiciones y dos alternativas (S o N) para cada una de las condiciones, habría dieciséis posibilidades: •

57

Unidad 3: Paradigmas de la ingeniería de software

Condición 1:

2 alternativas

Condición 2:

X 2 alternativas

Condición 3:

X 2 alternativas

Condición 4:

X 2 alternativas ---------------------16 posibilidades • Llene las alternativas de la condición. Comience con la primera condición y divida el número de columnas con el número de alternativas para tal condición. En el ejemplo, al haber 16 columnas y 2 opciones (S y N), 16 entre 2, 8. Luego, elija una de las opciones y escriba S en cada una de las 8 columnas. Concluya anotando N en las 8 columnas restantes, tal y como sigue: Condición 1

SSSSSSSNNNNNNNN

Repita lo anterior para cada una de las condiciones, utilizando un subconjunto de la tabla: Condición 1 Condición 2 Condición 3 Condición 4

SSSSSSSSNNNNNNNN SSSSNNNN SSNN SN

Y continúe el patrón para cada condición: Condición 1 Condición 2 Condición 3 Condición 4

SSSSSSSSNNNNNNNN SSSSNNNNSSSSNNNN SSNNSSNNSSNNSSNN SNSNSNSNSNSNSNSN

Concluya la tabla insertando una X donde las reglas sugieran cierta acción. •

Combine las reglas donde se aparenta que una alternativa no implique diferencias en la salida; por ejemplo: •

58

Unidad 3: Paradigmas de la ingeniería de software

Condición 1 SS Condición 2 SN --------------------------------Acción 1 XX lo cual puede expresarse como: Condición 1 S Condición 2 __ -----------------------------------Acción 1 X El guión ( __ ) significa que la condición 2 puede ser S o N y la acción aún así podrá llevarse a cabo. Verifique la tabla para situaciones imposibles, contradicciones y redundancias. •

Vuelva arreglar las condiciones y las acciones (o aún las reglas) si esto redunda en una mayor compresión. •

La tabla 18 es un ejemplo de una tabla de decisiones que se desarrolló por medio de los pasos planteados con anterioridad. •

En este ejemplo una compañía intenta mantener una significativa lista de correos de sus clientes. El objetivo es enviar catálogos a aquellos clientes que adquirían mercancía.

Condiciones y acciones

Reglas 12345678

El cliente ordena del catálogo de otoño El cliente ordena del catálogo de invierno El cliente ordena del catálogo especial

SSSSNNNN SSNNSSNN SNSNSNSN

Envío del catálogo de Navidad de este año X X X X Envío del catálogo especial XX Envío de ambos catálogos XX

Figura 18: Ejemplo de una tabla de decisiones

59

Unidad 3: Paradigmas de la ingeniería de software

La tabla de decisiones contempla tres condiciones (C1: clientes que ordenan del catálogo de otoño, C2: clientes que ordenan del catálogo de Navidad y C3: clientes que ordenan del catálogo de especialidades). Cada uno de ello tiene dos opciones (S o N). Hay tres acciones que realizar: A1: enviar el catálogo de navidad del presente año; A2: enviar el nuevo catálogo de especialidades; A3: enviar ambos catálogos. La tabla de decisiones se examinará para ver si es posible reducirla. Es posible combinar algunas de las reglas, tal y como se muestra en la figura 19. Las reglas 2, 4, 6, y 8 pueden combinarse, ya que todas ellas tienen dos cosas en común: Nos indica que enviemos el catálogo de Navidad para este año (acción 1) • La opción para la condición 3 siempre es N. •

Condiciones y acciones

Reglas 1' 2' 3'

--El cliente ordena del catálogo de otoño El cliente ordena del catálogo de invierno S - El cliente ordena del catálogo especial SNN Envío del catálogo de Navidad de este año Envío del catálogo especial Envío de ambos catálogos

X X X

Figura 19: Ejemplo de una tabla reducida

Es esencial certificar la integridad y la precisión de las tablas de decisiones. En el desarrollo de las tablas de decisiones se pueden presentar cuatro problemas principales: tablas incompletas, situaciones imposibles, contradicciones y redundancias. Un ejemplo de una situación imposible se muestra en la tabla 20 La regla 1 no es factible, ya que una persona no puede ganar más de $50.00 por año y menos de $2.00 al mismo tiempo.

60

Unidad 3: Paradigmas de la ingeniería de software

Condiciones y acciones

Reglas 1234

Salario > $50.00/año Salario