DEPARTAMENTO DE DISEÑO E IMAGEN - … · INTRODUCCION AL ANALISIS Y DISEÑO DE SISTEMAS ... 1.4.2...

ELABORÓ: UNIVERSIDAD TECNOLÓGICA REVISÓ: UNIVERSIDAD(ES) TECNOLÓGICA(S)

AUTORES: Lic. J.Cruz Salas Solis, Lic. Carlos Valdivia

REVISORES: APROBÓ: COMISION NACIONAL ACADÉMICA

DE TIC FECHA DE ENTRADA EN VIGOR:

Universidad Tecnológica de Puebla Tecnologías de la Información y Comunicación

Manual de Asignatura Basado en Competencias Profesionales

Introducción al Análisis y Diseño de Sistemas

Enero 2012

INTRODUCCION AL ANALISIS Y DISEÑO DE SISTEMAS

TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

2

INDICE

Contenido

INTRODUCCIÓN UNIDAD TEMÁTICA I FUNDAMENTOS DE LA ADMINISTRACIÓN DE PROYECTOS

DE TIC

1. 1.1 Planeación 9

1.1.1 Actividades asociadas a la Planificación del Proyecto 10

1.1.2 Recursos Humanos 10

1.1.3 Recursos o componentes de software reutilizables 11

1.1.4 Recursos de entorno 11

1.1.5 Estimación del proyecto de software 11

1.1.6 Diferentes modelos de estimación 12

1.1.6.1 Modelos Empíricos 12

1.1.6.2 Modelos COCOMO 12

1.1.6.3 Herramientas Automáticas de Estimación 13

1.1.6.4 Método de planeación de sistemas empresariales

(BSP)

13

1.1.6.5 Pasos para seguir para llevar a cabo un estudio BSP 14

1.1.6.6 Limitaciones de la metodología BSP 14

1.1.7 Método de planeación estratégica de arquitectura de

computadoras de Nolan, Norton & Co

14

1.1.8 Método de factores críticos del éxito 14

1.1.9 Uso de los diagramas de Gantt para la programación

de proyectos

14

1.1.10 Uso de Graficas de PERT 15

1.1.11 Determinación de requerimientos 15

l%20



3

1.1.12 Actividades de la determinación de requerimientos 16

1.1.13 Diseño lógico 16

1.1.14 Diseño físico 17

1.2 Fundamentos del análisis de requerimientos 18

1.2.1 Fundamentos del análisis de requerimientos 18

1.2.2 Análisis de Requerimientos 19

1.2.3 Tareas de Análisis 19

1.2.4 Principios del Análisis 21

1.2.5 El dominio de la Información 22

1.2.6 Partición 23

1.2.7 Visiones Lógicas y Físicas 23

1.2.8 Construcción de prototipos de Software 23

1.2.9 Un escenario para la construcción de prototipos 23

1.2.10 Especificación 25

1.2.11 Principios de Especificación 25

1.2.12 Métodos de Análisis de Requerimientos 27

1.2.13 Metodologías de Análisis de Requerimientos 28

1.2.14 Métodos de Análisis Orientados al Flujo de Datos 28

1.2.15 Diagramas de Flujos de Datos 29

1.2.16 Diccionarios de Datos 29

1.2.17 Descripciones Funcionales 30

1.2.18 Métodos Orientados a la Estructura de Datos 30

1.2.19 Desarrollo de Sistemas de Jackson 30



4

1.2.20 Requerimientos de las Bases de Datos 31

1.2.21 Características de las Bases de datos 31

1.3 Dirección 32

1.3.1 El paradigma de lo orientado a Objetos 33

1.3.2 La programación Orientada a Objetos 33

1.3.3 Fundamentos de lo Orientado a Objetos 34

1.3.4 El proceso unificado 35

1.3.5 Proceso Unificado y MSF; complementos tecnológicos 36

1.3.6 El ciclo de vida del software en el Proceso Unificado 38

1.3.7 Diseño Conceptual 39

1.3.8 Diseño Lógico 40

1.3.9 Diseño físico 43

1.4 Control 45

1.4.1 Las Métricas 46

1.4.2 MÉTRICAS DEL SOFTWARE 46

1.4.3 METRICAS COMO PLANEACION DE SISTEMAS 47

1.5 ACTIVIDAD 1 CONCEPTOS BASICOS 49

UNIDAD TEMÁTICA II ANÁLISIS DE REQUERIMIENTOS

2. ANALISIS DE REQUERIMIENTOS 52

2.1 TECNICAS DE RECOLECCION DE DATOS 52

2.2 ANALISIS DE REQUERIMIENTOS 56

2.3 MODELOS TRADICIONALES 59



5

2.3.1 Descomposición Funcional 59

2.3.2 Análisis Estructurado 59

2.3.3 Especificación Operacional 60

2.3.4 Análisis Orientado a Objetos 60

2.4 Otros modelos 61

2.5 CASOS DE USO 62

2.5.1 Como identificar los casos de uso 62

2.5.2 Diagrama de Casos de uso 63

2.5.3 DOCUMENTACION DE REQUISISTOS 65

2.6 ACTIVIDAD 2 66

UNIDAD TEMATICA 3 INTRODUCCION A LOS

MODELOS DE DESARROLLO

3. INTRODUCCION A LOS MODELOS DE DESARROLLO 68

3.1 INTRODUCCIÓN 68

3.2 Definición Ingeniería 68

3.3 Definición Software 69

3.4 MODELOS DE DESARROLLO DE SOFTWARE 70

3.5 MODELOS EN CASCADA 70

3.5.1 Modelo en Cascada1(Bennington 1956) 71

3.5.2 Modelo V (Ministerio de Defensa de Alemania, 1992) 72

3.5.3 MODELO EN ESPIRAL 74

3.5.4 MODELO DE PROTOTIPOS 75

3.5.5 MODELO DRA (FALTA INVESTIGAR DE ESTE TEMA) 76



6

3.5.6 MODELO XP 77

3.5.7 Ciclo de vida 79

UNIDAD TEMATICA 4 FUNDAMENTOS DE LA

PROGRAMACION ORIENTADA A OBJETOS (POO)

4.1 introducción y breve historia de la POO y los LPOO

83

4.1.1 definición de POO y caracterización de los LPOO

84

4.2. La base de objetos y clases

84

4.2. La base de objetos y clases

87

4.4. Las relaciones entre objetos: la agregación y la herencia

87

4.5. El ligamiento dinámico y el polimorfismo

92

4.6. Interacción basada en mensajes a objetos

95



7

INTRODUCCIÓN

El siguiente documento integra información acerca temas relacionados con la asignatura de Introducción al Análisis y Diseño de Sistemas. El objetivo principal del documento es brindar al alumno información que le permita trabajar sobre el diseño conceptual que recoja la semántica de un determinado universo de discurso, este proceso es muy creativo y no existe un procedimiento definido, sin embargo es posible seguir una serie de recomendaciones para facilitar el mismo. También le permite el alumno, conocer los fundamentos de la administración de Proyectos de TIC, Definir los Análisis de requerimientos, los modelos de desarrollo de software y una introducción a la Programación Orientada a Objetos POO. Además de propiciar la realización de trabajos futuros aplicados a su entorno, permitiéndoles solucionar problemas en función de los conocimientos adquiridos de automatización de sistemas. Además de motivar en él, el autoestudio, la investigación y la auto práctica.

Con la finalidad de que el alumno pueda aplicar algunos de los conocimientos adquiridos durante el desarrollo de la asignatura, en este manual se integran prácticas que le permitirán comprender conceptos y procesos de realización Análisis y Diseño de Sistemas. DESARROLLO El manual está compuesto por 4 unidades temáticas:

I. Fundamentos de la administración de proyectos de TIC II. Análisis de requerimientos

III. Introducción a los modelos de desarrollo (Proceso Unificado de Desarrollo) IV. Fundamentos de la POO

Cada uno de estas unidades cuenta con información que sustenta cada uno de los temas contenido en la unidad. Esta información en su mayoría ha sido colectada de libros, sitios de internet, para brindar al alumno información seria y de calidad. Se integran prácticas a los temas para fortalecer el aprendizaje significativo del alumno.



8

Unidad Temática I. Fundamentos de la administración de proyectos de TIC.

Objetivo: El alumno elaborará un plan considerando las etapas del proceso administrativo para un proyecto de desarrollo de software.

Temas Saber Saber hacer Ser

Planeación Identificar el proceso de la planeación para el desarrollo de software (objetivos, metas, recursos, actividades, tiempos, roles, políticas). Identificar una herramienta de gestión de proyectos.

Elaborar el plan de trabajo que desarrolle un proyecto de TIC, utilizando herramientas de gestión de proyectos.

Analítico Sistemático Coherente Visionario Capaz de comunicarse claramente Crítico Hábil para trabajar en equipo

Organización Identificar las funciones y tareas del equipo de trabajo que interviene en el proceso de desarrollo de software.

Asignar las tareas y funciones necesarias para el desarrollo de software.

Analítico Sistemático Coherente Visionario Capaz de comunicarse claramente Crítico Hábil para trabajar en equipo



9

Temas Saber Saber hacer Ser

Dirección Identificar las acciones pertinentes para orientar un proyecto de desarrollo de software.

Proponer las acciones de coordinación para el desarrollo del proyecto de software.

Líder Responsable Analítico Sistemático Crítico Honesto Ético Coherente Proactivo Hábil para el trabajo en equipo

Control Describir las diferentes métricas para la evaluación de proyectos de desarrollo de software.

Comparar los resultados obtenidos contra las métricas establecidas en el plan de trabajo.

Líder Responsable Analítico Sistemático Crítico Honesto Ético Coherente Proactivo Hábil para el trabajo en equipo Tolerante

Resultado de aprendizaje: Elaborará un documento con base en un escenario determinado, en el cual describa el plan para el

desarrollo de un proyecto de TIC que incluya:

Definición de objetivos, metas, recursos, actividades, tiempos, roles y políticas.

Organigrama y funciones de los miembros del equipo.

Métricas para el seguimiento y control del proyecto.



10

1 UNIDAD TEMATICA 1

1.1 PLANEACION

OBJETIVO: Identificar el proceso de la planeación para el desarrollo de software.

Los métodos formales de planeación se desarrollaron para ofrecer apoyo a los gerentes y ejecutivos en el proceso de desarrollo de sistemas de información que ayuden a alcanzar las metas de la organización mediante estos métodos se describen directrices a nivel organizacional para los sistemas de información de la empresa. Dentro de la Planeación de sistemas el analista debe incluir los siguientes aspectos: • Identificación de elementos clave de los que dependen las aplicaciones como su desarrollo. • Descripción de las relaciones entre estos elementos y la documentación de las necesidades actuales de información o el bosquejo de futuros planes de la empresa. 1.1.1 Actividades asociadas a la Planificación del Proyecto:

Ámbito del Software:

En esta etapa evalúa la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos. Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar más detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos detiempo de respuesta y procesamiento, identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes. El Ámbito se define como un pre‐requisito para la estimación y existen algunos elementos que se debe tomar en cuenta como es:

La Obtención de la Información necesaria para el software. Para esto el analista y el

cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los

puntos de interés para su desarrollo.

RECURSOS:

La Segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables.



11

Y en la parte más alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano). Cada recurso queda especificado mediante cuatro características:

• Descripción del Recurso.

• Informes de disponibilidad.

• Fecha cronológica en la que se requiere el recurso.

• Tiempo durante el que será aplicado el recurso.

1.1.2 Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñara cada profesional. 1.1.3 Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, esto es la creación y la reutilización de bloques de construcción de Software. Tales bloques se deben establecer en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para la también fácil integración. El Autor Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a medida que se avanza con la planificación:

• Componentes ya desarrollados.

• Componentes ya experimentados.

• Componentes con experiencia Parcial.

• Componentes nuevos.

1.1.4 Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de Software, incorpora Hardware y Software. El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena práctica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles. Muchas veces el desarrollo de las pruebas de validación de un proyecto de software para la composición automatizada puede necesitar un compositor de fotografías en algún punto durante el



12

desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software. 1.1.5 ESTIMACION DEL PROYECTO DE SOFTWARE.

En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento más caro de la mayoría de los sistemas informáticos. Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y pérdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo. Para realizar estimaciones seguras de costos y esfuerzos se tienen varias opciones posibles:

• Dejar la estimación para más adelante (obviamente se puede realizar una estimación al cien por

cien fiable después de haber terminado el proyecto).

• Basar las estimaciones en proyectos similares ya terminados.

• Utilizar técnicas de descomposición relativamente sencillas para generar las estimaciones de

costos y esfuerzo del proyecto.

• Desarrollar un modelo empírico para él cálculo de costos y esfuerzos del Software.

La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son métodos viables para la estimación del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas como comprobación de las otras. Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a construir y generar una estimación de su tamaño.

• Estimación basada en el Proceso.

Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como último paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software.



13

1.1.6 DIFERENTES MODELOS DE ESTIMACION.

1.1.6.1 Modelos Empíricos:

Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia. 1.1.6.2 Modelo COCOMO.

Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su nombre en Inglés (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm está constituida por los siguientes:

• Modelo I. El Modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo

deSoftware en función del tamaño del programa, expresado en las líneas estimadas.

• Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de

software en función del tamaño del programa y de un conjunto de conductores de

costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y

de los atributos del proyecto.

• Modelo III. El modelo COCOMO avanzado incorpora todas las características de la

versión intermedia y lleva a cabo una evaluación del impacto de los conductores de

costos en cada caso (análisis, diseño, etc.) del proceso de ingeniería de Software.

1.1.6.3 Herramientas Automáticas De Estimación.

Las herramientas automáticas de estimación permiten al planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren de una o más clases de datos. A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de desarrollo y riesgos asociados. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado. Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una



14

estimación más exacta. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la precisión de la estimación. Las tres metodologías más utilizadas para la planeación de sistemas de información son: • Método de planeación de sistemas empresariales (BSP). • Método de planeación estratégica de arquitectura de computadoras de Nolan, Norton & Co. • Método de factores críticos del éxito. 1.1.6.4 Método de planeación de sistemas empresariales (BSP):

Desarrollado originalmente por IBM para su propio uso y posteriormente ofrecido como una metodología general de planeación, bajo el enfoque BSP los datos son vistos como un recurso corporativo muy valioso ya que las empresas invierten millones de dólares en capturar, almacenar y preservar datos, este método se concentra en la identificación de los datos necesarios para poner en marcha una organización. 1.1.6.5 Pasos a seguir para llevar a cabo un estudio BSP:

• Formar un grupo de trabajo para realizar un estudio de los principales procesos que

entran en juego dentro de la organización. (Normalmente estos grupos están integrados

por altos ejecutivos y gerentes).

• Después de identificar los procesos sustantivos que dan vida a la organización, tales

como el desarrollo de productos, la fabricación, mercadotecnia y ventas, el equipo

define clases de datos (entre 30 y 60 categorías) para representar entidades de interés,

como clientes, proveedores y pedidos de productos.

• Se espera que la evaluación de las descripciones de los procesos de datos (reunidas por

el equipo BSP) junto con la información obtenida a través de entrevistas (realizadas por

analistas de sistemas) genere los siguientes resultados:

• Un marco de referencia que defina los sistemas y subsistemas para el manejo de la

información dentro de la organización.

• Recomendaciones para el manejo y el control de datos.

• Prioridades para el desarrollo de futuras aplicaciones de sistemas de información.

1.1.6.6 Limitaciones de la metodología BSP:

• No abarca futuros requerimientos de información estratégica que necesitara tener a

largo plazo organización.



15

• Consume demasiado tiempo para poder comprender los requerimientos de la

organización, incluyendo el tiempo necesario para formular un número considerable de

entrevistas con los gerentes.

• La tarea de analizar y sintetizar los datos obtenidos es todo un reto.

1.1.7 Método de planeación estratégica de arquitectura de computadoras de Nolan,

Norton & Co:

Enlaza la capacidad actual de la organización con sus necesidades futuras, este método recalca la necesidad de desarrollar una fuerte infraestructura técnica para que sirva como plataforma para el desarrollo de aplicaciones. 1.1.8 Método de factores críticos del éxito:

Con este método lo que se pretende es identificar las áreas que son claves para la supervivencia de la organización y asegurar su incorporación a los sistemas de información. 1.1.9 Uso de los diagramas de Gantt para la programación de proyectos:

Mediante el uso de dichos diagramas se programan actividades, esencialmente es un diagrama que contiene barras que representan cada una de las actividades, y cuya longitud representa la duración de la actividad respectiva. Un diagrama de Gantt de una dimensión es un calendario, siendo una técnica muy usada para la planeación de las actividades que se desarrollan en serie pero cuando las actividades que pueden llevarse de manera simultánea son varias resulta apropiado un diagrama de Gantt bidimensional. La ventaja principal del diagrama de Gantt es su sencillez, el analista de sistemas no solo encontrara fácil esta metodología, sino que también contara con un excelente instrumento de comunicación con los usuarios finales. Otra ventaja del uso de los diagramas de Gantt es que las barras que representan las actividades se dibujan a escala, esto es el tamaño de una barra indica la duración relativade la actividad. 1.1.10 Uso de graficas PERT.

PERT son las siglas de ProgramEvaluation and ReviewTechniques, se desarrolló a fines de la década de los 50 para utilizarlo en el proyecto del submarino nuclear polares. En PERT un proyecto se representa por una red de nodos y flechas, que luego se evalúa, tanto para determinar cuáles son las actividades críticas y mejorar su programación sifuera necesario, como para revisar el avance del proyecto una vez que se ha iniciado.



16

PERT es útil cuando pueden realizarse varias actividades paralelamente, las actividades que se representan como barras en el diagrama de Gantt, ahora se representan medianteflechas. La longitud de las flechas carece de relación con la duración de las actividades representadas, los nodos circulares se denominan eventos y pueden contener números,letras o cualquier otra designación. Los nodos sirven para:

• Reconocer que una actividad se ha concluido.

• Indicar que actividades necesitan concluirse antes de iniciar otra (precedencia).

• La gráfica PERT permite:

• Identificación fácil del orden de la procedencia.

• Identificación fácil de la ruta crítica y de las actividades críticas.

• El cálculo sencillo de la duración de la holgura.

1.1.11 DETERMINACION DE REQUERIMIENTOS.

Es el estudio de un sistema para conocer cómo trabaja y evaluar la forma en queinteractúan los métodos empleados y si es necesario o posible realizar ajustes. Un requerimiento es una característica que debe incluirse en un nuevo sistema, esto puede ser la inclusión de determinada forma para capturar o procesar datos, producir información, controlar una actividad de la empresa o brindar soporte a la gerencia. Es así como la determinación de requerimientos vincula el estudio de un sistema existente con la recopilación de detalles relacionados con él. Para identificar los requerimientos de información dentro de la empresa, pueden utilizarse diversos instrumentos, los que incluyen: el muestreo, él estudio de los datos y formas usadas por la organización, la entrevista, los cuestionarios, la observación de la conducta de quien toma las decisiones, así como de su ambiente, y también el desarrollo de prototipos. En esta etapa el analista hace todo lo posible por identificar que información requiere el usuario para desempeñar sus tareas, con lo cual el analista logra tener una imagen de la organización y objetivos de la empresa. 1.1.12 ACTIVIDADES DE LA DETEMINACION DE REQUERIMIENTOS.

La determinación de requerimientos se realiza a través de tres grandes actividades: • Anticipación de requerimientos: La experiencia de los analistas en un área en particular y el

contacto con sistemas en un ambiente similar al que se encuentra bajo investigación, le permite

anticipar ciertos problemas o características y requerimientos para el nuevo sistema.



17

• Investigación de requerimientos: En esta actividad los analistas estudian el sistema actual con la

ayuda de varias herramientas y habilidades (análisis de flujo de datos y análisis de decisión) y

documentan sus características para más adelante emprender el análisis.La investigación de

requerimientos depende de las técnicas para encontrar datos e incluyen métodos para

documentar y describir las características del sistema.

• Especificaciones de requerimientos:Es esta etapa se analizan los datos que describen el sistema

para determinar qué tan bueno es su desempeño, que requerimientos se deben satisfacer y las

estrategias para alcanzarlos, esta actividad tiene tres partes relacionadas entre si:

• Análisis de datos basados en hechos reales: Se examinan los datos recopilados durante el

estudio, incluidos en la documentación de flujo de datos y análisis de decisiones, para examinar

el grado de desempeño del sistema y si cumple con las demandas de la organización.

• Identificación de requerimientos esenciales: Son las características que deben incluirse en el

nuevo sistema y que van desde detalles de operación hasta criterios de desempeño.

• Selección de estrategias para satisfacer los requerimientos: Son los métodos que serán

utilizados para alcanzar los requerimientos establecidos y seleccionados. Estos forman la base

para el diseño de sistemas, los cuales deben cumplir con la especificación de requerimientos.

1.1.13 Diseño lógico.

En esta etapa del ciclo de desarrollo de los sistemas el analista usa la información que recolecto con anterioridad y elabora el diseño lógico del sistema de información, el analista diseña procedimientos precisos de captura de datos, con el fin de que los datos que se introduzcan sean correctos, también diseña accesos efectivos al sistema de información, mediante el uso de las técnicas de diseño de formas y pantallas. Una parte del diseño lógico del sistema de información es el diseño de la interfaz con el usuario. La interfaz conecta al usuario con el sistema, como ejemplo de interfaz se tienen: el uso de teclado, el uso de menús en la pantalla, el mouse etc. La etapa de diseño también incluye el diseño de los archivos o la base de datos que almacena los datos requeridos por quien toma las decisiones en la organización. El esquema lógico es una fuente de información para el diseño físico. Además, juega un papel importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros cambios que se realicen sobre los programas de aplicación o sobre los datos, se representen correctamente en la base de datos. Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un punto de inicio y se van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje en el que el diseñador va comprendiendo el funcionamiento de la empresa y el significado de los datos que maneja. El diseño conceptual y el diseño lógico son etapas clave para conseguir un sistema que funcione correctamente.



18

1.1.14 Diseño Físico.

El diseño físico es el proceso de producir la descripción de la implementación de la base de datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un acceso eficiente a los datos. Para llevar a cabo esta etapa, se debe haber decidido cuál es el SGBD que se va a utilizar, ya que el esquema físico se adapta a él. Entre el diseño físico y el diseño lógico hay una realimentación, ya que algunas de las decisiones que se tomen durante el diseño físico para mejorar las prestaciones, pueden afectar a la estructura del esquema lógico. En general, el propósito del diseño físico es describir cómo se va a implementar físicamente el esquema lógico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto consiste en:

• Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas.

• Determinar las estructuras de almacenamiento y los métodos de acceso que se van a utilizar

para conseguir unas prestaciones óptimas.

• Diseñar el modelo de seguridad del sistema

1.2 ORGANIZACION

OBJETIVO: Identificar las funciones y tareas del equipo de trabajo que interviene en el proceso de desarrollo de software. 1.2.1 FUNDAMENTOS DEL ANÁLISIS DE REQUERIMIENTOS

Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es la etapa más crucial del desarrollo de un proyecto de software. La IEEE los divide en funcionales y no funcionales: Funcionales: Condición o capacidad de un sistema requerida por el usuario para resolver un problema o alcanzar un objetivo. No Funcionales: Condición o capacidad que debe poseer un sistema par satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto. Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los requerimientos



19

de los mismos. Independientemente de lo bien diseñado o codificado que esté, un programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo. La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, El ámbito del programa, establecido inicialmente durante la ingeniería del sistema, es refinado en detalle. Se analizan y asignan a los distintos elementos de los programas las soluciones alternativas. Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación de requerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la función y comportamiento de los programas en detalles concretos, El que desarrolla el software actúa como interrogador, consultor y el que resuelve los problemas. El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan los cambios por mala interpretación o falta de información. El dilema con el que se enfrenta un ingeniero de software puede ser comprendido repitiendo la sentencia de un cliente anónimo: "Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir". 1.2.2 Análisis de Requerimientos

El análisis de requerimientos es la tarea que plantea la asignación de software a nivel de sistema y el diseño de programas (Figura 1). El análisis de requerimientos facilita al ingeniero de sistemas especificar la función y comportamiento de los programas, indicar la interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe cumplir el programa. El análisis de requerimientos permite al ingeniero refinar la asignación de software y representar el dominio de la información que será tratada por el programa. El análisis de requerimientos de al diseñador la representación de la información y las funciones que pueden ser traducidas en datos, arquitectura y diseño procedimental. Finalmente, la especificación de requerimientos suministra al técnico y al cliente, los medios para valorar la calidad de los programas, una vez que se haya construido.



20

Figura 1

1.2.3 Tareas del Análisis

El análisis de requerimientos puede dividirse en cuatro áreas: 1.‐ Reconocimiento del problema 2.‐ Evaluación y síntesis 3.‐ Especificación 4.‐ Revisión. Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los programas que se usó para generar las estimaciones de la planificación. A continuación, debe establecerse la comunicación necesaria para el análisis, de forma que se asegure el reconocimiento del problema. Las formas de comunicación requeridas para el análisis se ilustran en la Figura 2. El analista debe establecer contacto con el equipo técnico y de gestión del usuario/cliente y con la empresa que vaya a desarrollar el software. El gestor del programa puede servir como coordinador para facilitar el establecimiento de los caminos de comunicación. El objetivo del analista es reconocer los elementos básicos del programa tal como lo percibe el usuario/cliente.



21

Figura 2

La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del análisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todas las funciones del programa, establecer las características de la interface del sistema y descubrir las ligaduras del diseño, Cada una de las tareas sirve para descubrir el problema de forma que pueda sintetizarse un enfoque o solución global. Las tareas asociadas con el análisis y especificación existen para dar una representación del programa que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente desarrolla una especificación de requerimientos del software completamente por sí mismo. Esto se presenta raramente en el mundo real. En el mejor de los casos, la especificación se desarrolla conjuntamente entre el cliente y el técnico. Una vez que se hayan descrito las funcionalidades básicas, comportamiento, interface e información, se especifican los criterios de validación para demostrar una comprensión de una correcta implementación de los programas. Estos criterios sirven como base para hacer una prueba durante el desarrollo de los programas. Para definir las características y atributos del



22

software se escribe una especificación de requerimientos formal. Además, para los casos en los que se desarrolle un prototipo se realiza un manual de usuario preliminar. Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana del proceso de desarrollo, Pero de hecho, este borrador del manual de usuario fuerza al analista a tomar el punto de vista del usuario del software. El manual permite al usuario / cliente revisar el software desde una perspectiva de ingeniería humana y frecuentemente produce el comentario: "La idea es correcta pero esta no es la forma en que pensé que se podría hacer esto". Es mejor descubrir tales comentarios lo más tempranamente posible en el proceso. Los documentos del análisis de requerimiento (especificación y manual de usuario) sirven como base para una revisión conducida por el cliente y el técnico. La revisión de los requerimientos casi siempre produce modificaciones en la función, comportamiento, representación de la información, ligaduras o criterios de validación. Además, se realiza una nueva apreciación del plan del proyecto de software para determinar si las primeras estimaciones siguen siendo válidas después del conocimiento adicional obtenido durante el análisis. 1.2.4 Principios del Análisis

En la pasada década, se desarrollaron varios métodos de análisis y especificación del software. Los investigadores han identificado los problemas y sus causas y desarrollando reglas y procedimientos para resolverlos. Cada método de análisis tiene una única notación y punto de vista. Sin embargo, todos los métodos de análisis están relacionados por un conjunto de principios fundamentales: El dominio de la información, así como el dominio funcional de un problema debe ser representado y comprendido. El problema debe subdividirse de forma que se descubran los detalles de una manera progresiva (o jerárquica) Deben desarrollarse las representaciones lógicas y físicas del sistema. Aplicando estos principios, el analista enfoca el problema sistemáticamente. Se examina el dominio de la información de forma que pueda comprenderse su función más completamente. La partición se aplica para reducir la complejidad. La visión lógica y física del software, es necesaria para acomodar las ligaduras lógicas impuestas por los requerimientos de procesamiento, y las ligaduras físicas impuestas por otros elementos del sistema. 1.2.5 El dominio de la Información

Todas las aplicaciones del software pueden colectivamente llamarse procesamiento de datos. Este término contiene la clave de lo que entendemos por requerimientos del software. El software se construye para procesar datos; para transformar datos de una forma a otra; esto



23

es, para aceptar entrada, manipularla de alguna forma y producir una salida. Este establecimiento fundamental de los objetivos es verdad tanto si construimos software por lotes para un sistema de nóminas, como software empotrado en tiempo real para controlar el flujo de la gasolina de un motor de automóvil; el dominio de la información contiene tres visiones diferentes de los datos que se procesan por los programas de computadoras: 1) el flujo de información; 2) el contenido de la información y 3) la estructura de la información. Para comprender completamente el dominio de la información, deben considerarse cada una de estas tres partes. El flujo de la información representa la manera en la que los datos cambian conforme pasan a través de un sistema. Refiriéndonos a la Figura 3, la entrada se transforma en datos intermedios y más adelante se transforma en la salida.

Figura 3

1.2.6 Partición

Normalmente los problemas son demasiado grandes y complejos para ser comprendidos como un todo. Por esta razón, tendemos a particionar (dividir) tales problemas en partes que puedan ser fácilmente comprendidas, y establecer interfaces entre las partes, de forma que se realice la



24

función global. Durante el análisis de requerimientos, el dominio funcional y el dominio de la información del software pueden ser particionados. En esencia la partición descompone un problema en sus partes constituyentes. Conceptualmente, establecemos una representación jerárquica de la función o información y luego partimos el elemento superior mediante: 1) incrementando los detalles, moviéndonos verticalmente en la jerarquía, o 2) descomponiendo funcionalmente el problema, moviéndonos horizontalmente en la jerarquía. 1.2.7 Visiones Lógicas y Físicas

La visión lógica de los requerimientos del software presenta las funciones que han de realizarse y la información que ha de procesarse independientemente de los detalles de implementación. La visión física de los requerimientos del software presenta una manifestación del mundo real de las funciones de procesamiento y las estructuras de información. En algunos casos se desarrolla una representación física como el primer paso del diseño del software. Sin embargo la mayoría de los sistemas basados en computador, se especifican de forma que se dictan ciertas recomendaciones físicas. 1.2.8 Construcción de Prototipos de Software

En análisis debe ser conducido independientemente del paradigma de ingeniería de software aplicado. Sin embargo, la forma que ese análisis tomara puede variar. En algunos casos es posible aplicar los principios de análisis fundamental y derivar a una especificación en papel del software desde el cual pueda desarrollarse un diseño. En otras situaciones, se va a una recolección de los requerimientos, se aplican los principios de análisis y se construye un modelo de software, llamado un prototipo, según las apreciaciones del cliente y del que lo desarrolla. Finalmente, hay circunstancias que requieren la construcción de un prototipo al comienzo del análisis, puesto que el modelo es el único mediante el que los requerimientos pueden ser derivados efectivamente. 1.2.9 Un escenario para la construcción de prototipos

Todos los proyectos de ingeniería de software comienzan con una petición del cliente. La petición puede estar en la forma de una memoria que describe un problema, un informe que define un conjunto de objetivos comerciales o del producto, una petición de propuesta formal de una agencia o compañía exterior, o una especificación del sistema que ha asignado una función y comportamiento al software, como un elemento de un sistema mayor basado en computadora. Suponiendo que existe una petición para un programa de una de las formas dichas anteriormente, para construir un prototipo del software se aplican los siguientes pasos: PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo.



25

Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es esencial que: 1) el cliente participe en la evaluación y refinamiento del prototipo, y 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna.

Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo. PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos. Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos. PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado. PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede aún aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre‐máquina usando una serie de hojas de historia. PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicación y sugiere modificaciones. Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales. PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción. El paradigma de construcción del prototipo puede ser conducido con uno o dos objetivos en mente: 1) el propósito del prototipo es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de programación, o 2) el propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus méritos y amos crean problemas. 1.2.10 Especificación



26

No hay duda de que la forma de especificar tiene mucho que ver con la calidad de la solución. Los ingenieros de software que se han esforzado en trabajar con especificaciones incompletas, inconsistentes o mal establecidas han experimentado la frustración y confusión que invariablemente se produce. Las consecuencias se padecen en la calidad, oportunidad y completitud del software resultante. Hemos visto que los requerimientos de software pueden ser analizados de varias formas diferentes. Las técnicas de análisis pueden conducir a una especificación en papel que contenga las descripciones gráficas y el lenguaje natural de los requerimientos del software. La construcción de prototipos conduce a una especificación ejecutable, esto es, el prototipo sirve como una representación de los requerimientos. Los lenguajes de especificación formal conducen a representaciones formales de los requerimientos que pueden ser verificados o analizados. 1.2.11 Principios de Especificación

La especificación, independientemente del modo en que se realice, puede ser vista como un proceso de representación. Los requerimientos se representan de forma que conduzcan finalmente a una correcta implementación del software. Baltzer y Goldman proponen ocho principios para una buena especificación: PRINCIPIO #1. Separar funcionalidad de implementación.

Primero, por definición, una especificación es una descripción de lo que se desea, en vez de como se realiza (implementa). Las especificaciones pueden adoptar dos formas muy diferentes. La primera forma es la de funciones matemáticas: dado algún conjunto de entrada, producir un conjunto particular de salida. La forma general de tales especificaciones es encontrar [un/el/todos] resultado tal que P (entrada), donde P representa un predicado arbitrario. En tales especificaciones, el resultado a ser obtenido ha sido expresado enteramente en una forma sobre el que (en vez de como). En parte, esto es debido a que el resultado es una función matemática de la entrada (la operación tiene puntos de comienzo y parada bien definidos) y no está afectado por el entorno que le rodea. PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas orientado al proceso.

Considerar una situación en la que el entorno sea dinámico y sus cambios afecten al comportamiento de alguna entidad que interactúe con dicho entorno. Su comportamiento no puede ser expresado como una función matemática de su entrada. En vez de ello, debe emplearse una descripción orientada al proceso, en la cual la especificación del que se consigue mediante la especificación de un modelo del comportamiento deseado en términos de respuestas funcionales, a distintos estímulos del entorno. PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el software es una componente.

Un sistema esta compuesto de componentes que interactúan. Solo dentro del contexto del sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de



27

una componente específica. En general, un sistema puede ser modelado como una colección de objetos pasivos y activos. Estos objetos están interrelacionados y dichas relaciones entre los objetos cambian con el tiempo. Estas relaciones dinámicas suministran los estímulos a los cuales los objetos activos, llamados agentes, responden. Las respuestas pueden causar posteriormente cambios y, por tanto, estímulos adicionales a los cuales los agentes deben responder. PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el sistema opera.

Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser especificado. Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un sistema compuesto de objetos que interactúan, pasivos y activos, de los cuales el sistema especificado es una agente, Los otros agentes, los cuales son por definición inalterables debido a que son parte del entorno, limitan el ámbito del diseño subsecuente y de la implementación. De hecho, la única diferencia entre el sistema y su entorno es que el esfuerzo de diseño e implementación subsecuente opera exclusivamente sobre la especificación del sistema. La especificación del entorno facilita que se especifique la interfaz del sistema de la misma forma que el propio sistema, en vez de introducir otro formalismo. PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo.

La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo de diseño o implementación. Debe describir un sistema tal como es percibido por su comunidad de usuario. Los objetivos que manipula deben corresponderse con objetos reales de dicho dominio; los agentes deben modelar los individuos, organizaciones y equipo de ese dominio; y las acciones que ejecutan deben modelar lo que realmente ocurre en el dominio. Además, debe ser posible incorporar en la especificación las reglas o leyes que gobiernan los objetos del dominio. Algunas de estas leyes proscriben ciertos estados del sistema (tal como "dos objetos no pueden estar en el mismo lugar al mismo tiempo"), y por tanto limitan el comportamiento de los agentes o indican la necesidad de una posterior elaboración para prevenir que surjan estos estados. PRINCIPIO #6. Una especificación debe ser operacional.

La especificación debe ser completa y lo bastante formal para que pueda usarse para determinar si una implementación propuesta satisface la especificación de pruebas elegidas arbitrariamente. Esto es, dado el resultado de una implementación sobre algún conjunto arbitrario de datos elegibles, debe ser posible usar la especificación para validarestos resultados. Esto implica que la especificación, aunque no sea una especificacióncompleta del como, pueda actuar como un generador de posibles comportamientos,entre los que debe estar la implementación propuesta. Por tanto, en un sentido extenso,la especificación debe ser operacional. PRINCIPIO #7. La especificación del sistema debe ser tolerante con la completitud yaumentable.

Ninguna especificación puede ser siempre totalmente completa. El entorno en el queexiste es demasiado complejo para ello. Una especificación es siempre un modelo, unaabstracción, de alguna situación real (o imaginada). Por tanto, será incompleta. Además, alser formulad



28

existirán muchos niveles de detalle. La operacionalidad requeridaanteriormente no necesita ser completa. Las herramientas de análisis empleadas paraayudar a los especificadores y para probar las especificaciones, deben ser capaces detratar con la incompletitud. Naturalmente esto debilita el análisis, el cual puede serejecutado ampliando el rango de comportamiento aceptables, los cuales satisfacen laespecificación, pero tal degradación debe reflejar los restantes niveles de incertidumbre. PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada. Los principios anteriores tratan con la especificación como una entidad estática. Estasurge de la dinámica de la especificación. Debe ser reconocido que aunque el principal propósito de una especificación sea servir como base para el diseño e implementación de algún sistema, no es un objeto estático precompuesto, sino un objeto dinámico que sufre considerables modificaciones. Tales modificaciones se presentan en tres actividades principales: formulación, cuando se está creando una especificación inicial; desarrollo, cuando la especificación se esta elaborando durante el proceso iterativo de diseño e implementación; y mantenimiento, cuando la especificación se cambia para reflejar un entorno modificado y/o requerimientos funcionales adicionales. 1.2.12 Métodos de Análisis de Requerimientos

Las metodologías de análisis de requerimientos combinan procedimientos sistemáticos con una notación única para analizar los dominios de información y funcional de un problema de software; suministra un conjunto de heurísticas para subdividir el problema y define una forma de representación para las visiones lógicas y físicas. En esencia, los métodos de análisis de requerimientos del software, facilitan al ingeniero de software aplicar principios de análisis fundamentales, dentro del contexto de un método bien definido. La mayoría de los métodos de análisis de requerimientos son conducidos por la información. Estos es, el método suministra un mecanismo para representar el dominio de la información. Desde esta representación, se deriva la función y se desarrollan otras características de los programas. El papel de los métodos de análisis de requerimientos, es asistir al analista en la construcción de "una descripción precisa e independiente" del elemento software de un sistema basado en computadora. 1.2.13 Metodologías de Análisis de Requerimientos

Las metodologías de análisis de requerimientos facilitan al analista la aplicación de los principios fundamentales del análisis de una manera sistemática. Características Comunes Aunque cada método introduce nueva notación y heurística de análisis, todos los métodos pueden ser evaluados en el contexto de las siguientes características comunes:



29

1. Mecanismos para el análisis del dominio de la información 2. Método de representación funcional 3. Definición de interfaces 4. Mecanismos para subdividir el problema 5. Soporte de la abstracción 6. Representación de visiones físicas y lógicas Aunque el análisis del dominio de la información se conduce de forma diferente en cada metodología, pueden reconocerse algunas guías comunes. Todos los métodos se enfocan (directa o indirectamente) al flujo de datos y al contenido o estructura de datos. En la mayoría de los casos el flujo se caracteriza en el contexto de las transformaciones (funciones) que se aplican para cambiar la entrada en la salida. El contenido de los datos puede representarse explícitamente usando un mecanismo de diccionario o, implícitamente, enfocando primero la estructura jerárquica de los datos. Las funciones se describen normalmente como transformaciones o procesos de la información. Cada función puede ser representada usando una notación específica. Una descripción de la función puede desarrollarse usando el lenguaje natural, un leguaje procedimental con reglas sintácticas informales o un lenguaje de especificación forma. 1.2.14 Métodos de Análisis Orientados al Flujo de Datos

La información se transforma como un flujo a través de un sistema basado en computadora. El sistema acepta entrada de distintas formas; aplica un hardware, softwarey elementos humanos para transformar la entrada en salida; y produce una salida endistintas formas. La entrada puede ser una señal de control transmitida por untransductor, una serie de números escritos por un operador humano, un paquete deinformación transmitido por un enlace a red, o un voluminoso archivo de datosalmacenado en memoria secundaria. La transformación puede comprender una sencillacomparación lógica, un complejo algoritmo numérico, o un método de inferencia basadoen regla de un sistema experto. La salida puede encender un sencillo led o producir uninforme de 200 páginas. En efecto, un modelo de flujo de datos puede aplicarse acualquier sistema basado en computadora independientemente del tamaño ocomplejidad. Una técnica para representar el flujo de información a través del sistema basado en computadora se ilustra en la figura 4. La función global del sistema se representa comouna transformación sencilla de la información, representada en la figura como unaburbuja. Una o más entradas. Representadas como flechas con etiqueta, conducen latransformación para producir la información de salida. Puede observarse que el modelopuede aplicarse a todo el sistema o solo a un elemento de software. La clave es representar la información dada y producida por la transformación.



30

Figura 4

1.2.15 Diagramas de Flujos de Datos

Conforme con la información se mueve a través del software, se modifica mediante una serie de transformaciones. Un diagrama de flujos de datos (DFD), es una técnica grafica que describe el flujo de información y las transformaciones que se aplican a los datos, conforme se mueven de la entrada a la salida. La forma básica de un DFD se ilustra en la figura 5. El diagrama es similar en la forma a otros diagramas de flujo de actividades, y ha sido incorporado en técnicas de análisis y diseños propuesto por Yourdon y Constantine, DeMarco y Gane y Sarson. También se le conoce como un grafo de flujo de datos o un diagrama de burbujas.

Figura 5

1.2.16 Diccionario de Datos

Un análisis del dominio de la información puede ser incompleto si solo se considera el flujo de datos. Cada flecha de un diagrama de flujo de datos representa uno o más elementos de información. Por tanto, el analista debe disponer de algún otro método para representar el contenido de cada flecha de un DFD. Se ha propuesto el diccionario de datos como una gramática casi formal para describir el contenido de los elementos de información y ha sido definido da la siguiente forma: El diccionario de datos contiene las definiciones de todos los datos mencionados en el DFD, en una especificación del proceso y en el propio diccionario de datos. Los datos compuestos (datos que pueden ser además divididos) se definen en términos de sus componentes; los datos elementales (datos que no pueden ser divididos) se definen en términos del significado de cada uno de los valores que puede asumir. Por tanto, el diccionario



31

de datos esta compuesto de definiciones de flujo de datos, archivos [datos almacenados] y datos usados en los procesos [transformaciones]... 1.2.17 Descripciones Funcionales

Una vez que ha sido representado el dominio de la información (usando un DFD y un diccionario de datos), el analista describe cada función (transformación) representada, usando el lenguaje natural o alguna otra notación estilizada. Una de tales notaciones se llama ingles estructurado (también llamado lenguaje de diseño del programa o proceso (LDP)). El inglés estructurado incorpora construcciones procedimentales básicas – secuencia, selección y repetición‐ junto con frases del lenguaje natural, de forma que pueden desarrollarse descripciones procedimentales precisas de las funciones representadas dentro de un DFD. 1.2.18 Métodos Orientados a la Estructura de Datos

Hemos ya observado que el dominio de la información para un problema de software comprende el flujo de datos, el contenido de datos y la estructura de datos. Los métodos de análisis orientados a la estructura de datos representan los requerimientos del software enfocándose hacia la estructura de datos en vez de al flujo de datos. Aunque cada método orientado a la estructura de datos tiene un enfoque y notación distinta, todos tienen algunas características en común: 1) todos asisten al analista en la identificación de los objetos de información clave (también llamados entidades o ítems) y operaciones (también llamadas acciones o procesos); 2)todos suponen que la estructura de la información es jerárquica; 3)todos requiere que la estructura de datos se represente usando la secuencia, selección y repetición; y 4) todos dan una conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de programa. Como los métodos orientados al flujo de datos, los métodos de análisis orientados a la estructura de datos proporcionan la base para el diseño de software. Siempre puede extenderse un método de análisis para que abarque el diseño arquitectural y procedimental del software. 1.2.19 Desarrollo de Sistemas de Jackson

El desarrollo de sistema de Jackson (DSJ) se obtuvo a partir del trabajo de M.A. Jackson sobre el análisis del dominio de la información y sus relaciones con el diseño de programas y sistemas. En palabras de Jackson: "El que desarrolla el software comienza creando un modelo de la realidad a la que se refiere el sistema, la realidad que proporciona su materia objeto [del sistema]..." Para construir un DSJ el analista aplica los siguientes pasos:



32

Paso de las acciones y entidades. Usando un método muy similar a la técnica de análisis orientada al objeto, en este paso se identifican las entidades (persona, objetos u organizaciones que necesita un sistema para producir o usar información) y acciones (los sucesos que ocurren en el mudo real que afectan a las entidades). Paso de estructuración de las entidades. Las acciones que afectan a cada entidad son ordenadas en el tiempo y representadas mediante diagramas de Jackson (una notación similar a un árbol). Paso de modelación inicial. Las entidades y acciones se representan como un modelo del proceso; se definen las conexiones entre el modelo y el mundo real. Paso de las funciones. Se especifican las funciones que corresponden a las acciones definidas. Paso de temporización del sistema. Se establecen y especifican las características de planificación del proceso. Paso de implementación. Se especifica el hardware y software como un diseño. Los últimos tres pasos del DSJ están muy relacionados con el diseño de sistemas. 1.2.20 Requerimientos de las Bases de Datos

El análisis de requerimientos para una base de datos incorpora las mismas tareas que el análisis de requerimientos del software. Es necesario un contacto estrecho con el cliente; es esencial la identificación de las funciones e interfaces; se requiere la especificación del flujo, estructura y asociatividad de la información y debe desarrollarse un documento formal de los requerimientos. Un tratamiento completo del análisis de las bases de datos va más allá del ámbito de este paper. 1.2.21 Características de las bases de datos

El termino base de datos se ha convertido en uno de los muchos tópicos del campo de las computadoras. Aunque existen muchas definiciones elegantes, definiremos una base de datos como: una colección de información organizada de forma que facilita el acceso, análisis y creación de informes. Una base de datos contiene entidades de información que están relacionadas vía organización y asociación. La arquitectura lógica de una base de datos se define mediante un esquema que representa las definiciones de las relaciones entre las entidades de información. La arquitectura física de una base de datos depende de la configuración del hardware residente. Sin embargo, tanto el esquema (descripción lógica) como la organización (descripción física) deben adecuarse para satisfacer los requerimientos funcionales y de comportamiento para el acceso al análisis y creación de informes. 1.3 DIRECCION



33

OBJETIVO: Establecer las acciones pertinentes para orientar un proyecto de desarrollo de software. Según la definición del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo". Según el mismo autor, "un producto de software es un producto diseñado para un usuario". En este contexto, la Ingeniería de Software (SE del inglés Software Engineering) es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software", que en palabras más llanas, se considera que "la Ingeniería de Software

es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo‐efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo‐efectivos" [Cota 1994]. El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad" [Jacobson 1998].El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo" [Jacobson 1998]. El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida

delsoftware que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define le alcance del proyecto y desarrolla un caso de negocio. La elaboración define un plan del proyecto, especifica las características y fundamenta la arquitectura. La construcción crea el producto y la transición transfiere el producto a los usuarios. Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de información. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO. El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnología OO. Una de las especificaciones más importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o UML (del inglés UnifiedModelingLanguage) como un estándar, que junto con el Proceso Unificado están consolidando la tecnología OO. Para mayor información consulta las siguientes direcciones electrónicas:

• Carnegie Mellon's Software EngineeringInstitute (SEI) donde encontrarás información

y documentos relacionados con la Ingeniería de Software, análisis y diseño, metodologías,

métricas, certificación, calidad (CMM), seguridad (CERT),

• etc.



34

• TheRationalEdge e‐Magazine Es una revista electrónica donde mensualmente se publican

artículos sobre la importancia de la ingeniería en el software, con experiencias de la industria

• Herramientas de Ingeniería de Software Aquí encontrarás información sobre las

herramientas líderes que implementan la ingeniería de software, desde el modelado de

sistemas con UML hasta el proceso unificado que tiene que ver con la administración de

proyectos.

1.3.1 El Paradigma de lo Orientado a Objetos

Antes de analizar los pasos del proceso de desarrollo de software se expondrán los conceptos fundamentales del paradigma que guía la tecnología OO. Existen conceptos ligados en torno a la tecnología orientada a objetos: el paradigma, los principios, el análisis y el diseño, mismos que a continuación se comentan. 1.3.2 La Programación Orientada a Objetos

La Programación Orientada a Objetos (OOP por sus siglas en inglés de ObjectOriented

Programming) como paradigma, "es una forma de pensar, una filosofía, de la cual surge una cultura nueva que incorpora técnicas y metodologías diferentes. Pero estas técnicas y metodologías, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontológica: el universo computacional está poblado por objetos, cada uno responsabilizándose por sí mismo, y comunicándose con los demás por medio de mensajes" [Greiff 1994]. Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodología (colección de características para la ingeniería de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP más a una metodología, que al paradigma. De aquí que "el interés en la OOP radica más en los mecanismos que aporta para la construcción de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994]. La Programación Orientada a Objetos desde el punto de vista computacional "es un método de implementación en el cuál los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarquía de clases unidas vía relaciones de herencia" [Greiff 1994]. 1.3.3 Fundamentos de lo Orientado a Objetos

El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad



35

(propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto. En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menorgrado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modeloque se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

• Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza

algunos de los detalles o propiedades del sistema, mientras suprime otros.

• Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a

sus características esenciales.

• Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de

módulos coherentes e independientes.

• Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.

• Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos

no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy

restringida.

• Concurrencia. Es la propiedad que distingue un objeto que está activo de uno que no lo está.

• Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el

tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir)

y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue

creado). Según [Booch 1986], los beneficios del enfoque OO son:

• Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes

de programación basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal,

C++, CLOS, Ada, [y recientemente Java].

• Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseños

completos.

• Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son

más resistentes al cambio en especificaciones y tecnología.

El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad.



36

Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor, si su única función es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actúan entre sí mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, éste tomará las acciones para ejecutar o no el mensaje, de manera apropiada. Greiff(1994) comenta que el Análisis Orientado a Objetos (OOA por sus siglas en inglés de ObjectOrientedAnalysis) "es un método de análisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema". Según Booch, el Diseño Orientado a Objetos "es un método de diseño abarcando el proceso de descomposición orientado a objetos y una notación para representar ambos modelos lógico y físico tal como los modelos estáticos y dinámicos del sistema bajo diseño". En cuanto a las metodologías OO, diremos que hay un gran número de métodos orientado a objetos actualmente. Muchos de los métodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientación a objetos. Algunos de la metodología más conocidas y estudiadas hasta antes del UML según Jacobson son: • Object‐Oriented Design (OOD), Booch. • Object Modeling Technique (OMT), Rumbaugh. • Object Oriented Analysis (OOA), Coad/Yourdon. • Hierarchical Object Oriented Design (HOOD), ESA. • Object Oriented Structured Design (OOSD), Wasserman. • Object Oriented Systems Analysis (OOSA), Shaler y Mellor. • Responsibility Driven Design (RDD), Wirfs‐Brock, entre otros. Actualmente las metodologías más importantes de análisis y diseño de sistemas han confluido en lo que se es el UML, bajo el respaldo del Object Management Group. 1.3.4 El Proceso Unificado

El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational", donde confluyen 'los tres amigos' como se llaman a sí mismos o los tres grandes OO: Grady Booch, James Rumbaugh e Ivar Jacobson [M&R 1998].



37

El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guíaarquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a losrequerimientos y a la arquitectura. El proceso describe qué entregables producir, cómodesarrollarlos y también provee patrones. El proceso unificado es soportado porherramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas. 1.3.5 Proceso Unificado y MSF; complementos tecnológicos

Según M&R, "más que una metodología, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guían a una organización sobre comoensamblar los recursos, el personal y las técnicas necesaria para asegurar que suinfraestructura tecnológica y sus soluciones cumplan los objetivos de negocio. MSFmantiene una relación clara entre los objetivos de negocio y las implementacionestecnológicas". "MSF se puede utilizar por sí mismo o con otras herramientas y técnicas como el ProcesoRational [Proceso Unificado] para planear, construir y administrar el desarrollo desoluciones de negocio a la medida" [M&R 1998]. "El proceso Unificado es un proceso de desarrollo de software configurable que se adaptaa proyectos que varían en tamaño y complejidad. Se basa en muchos años de experienciaen el uso de la tecnología de objetos en el desarrollo de software de misión crítica en unavariedad de industrias. Uno de los componentes clave es el UML" [M&R 1998]. MSF proporciona las técnicas ligadas a la tecnología y el Proceso Unificado la guía detallada para el desarrollo de software minimizando los riesgos. El Proceso Unificado ha adoptado un enfoque que se caracteriza por:

• Interacción con el usuario continúa desde un inicio

• Mitigación de riesgos antes de que ocurran

• Liberaciones frecuentes

• Aseguramiento de la calidad

• Involucramiento del equipo en todas las decisiones del proyecto

• Anticiparse al cambio de requerimientos

El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel dereuso. MSF considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa [M&R 1998]:



38

• Arquitectura de Negocios ‐ Describe como opera un negocio. Desarrolla una imagen clara

de los procesos de flujo de trabajo de la organización y de cómo son apoyados por una

infraestructura tecnológica basada en servicios.

• Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para

diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes

back‐end de alto valor.

• Arquitectura de Información – Define qué información es necesaria para apoyar el proceso

de negocios y como poner esa información eficientemente en manos de quienes que la

necesitan sin crear islas de datos inaccesibles ni sistemas redundantes.

• Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de

herramientas, bloques de construcción de aplicaciones, servicios de infraestructura,

componentes de conectividad de red y plataformas cliente servidor.

El Modelo de Equipo de MSF muestra como estructurar equipos de alto desempeño para crear soluciones más rápido, mejor y más baratas. El Modelo de Equipo de MSF se basa en las formas de organizar equipos para crear los propios productos de Microsoft. Hace énfasis en las comunicaciones claras y en un equipo de iguales con papeles y responsabilidades claras en todo el proyecto. La calidad del producto se asegura por cada miembro del equipo. El Proceso Unificado proporciona más detalle y guía para algunos de los roles en el proyecto. Una vista arquitectónica es "una descripción simplificada (una abstracción) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva" [Booch 1998]. Según el mismo autor, las características primordiales del Proceso Unificado son:

• Iterativo e incremental

• Centrado en la arquitectura

• Guiado por casos de uso

• Confrontación de riesgos

El Proceso Unificado es un proceso porque "define quién está haciendo qué, cuándo lo hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software" [Jacobson 1998]. Según [Booch 1998], los conceptos clave del Proceso Unificado son: Fase e iteraciones ¿Cuándo se hace? Flujos de trabajo de procesos (actividades y pasos) ¿Qué se está haciendo? Artefactos (modelos, reportes, documentos) ¿Qué se produjo? Trabajador: un arquitecto ¿Quién lo hace?)



39

1.3.6 El ciclo de vida del software en el Proceso Unificado

Las fases del ciclo de vida del software son: concepción, elaboración, construcción y transición. La concepción es definir el alcance del proyecto y definir el caso de uso. La elaboración es proyectar un plan, definir las características y cimentar la arquitectura. La construcción es crear el producto y la transición es transferir el producto a sus usuarios [Booch 1998].

Figura 6. Estructura del Proceso Unificado

Según [Microsoft 1997], el diseño de software se realiza a tres niveles: conceptual, lógico y físico.



40

Figura 7. Arquitectura lógica de tres capas de una aplicación cliente/servidor

Para mayor información consulta la siguiente dirección electrónica:

• Herramientas de Ingeniería de Software Aquí encontrarás información sobre las herramientas

líderes que implementan la ingeniería de software, desde el modelado de sistemas con UML

hasta el proceso unificado que tiene que ver con la administración de proyectos.

• SourceForge.net Es una base de datos de proyectos de software de código abierto u open

source software.

Un ingeniero de software necesita de herramientas, entre ellas las herramientas de Rational son las más avanzadas, pero son muy costosas. También puede utilizar las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de código abierto y aún están de desarrollo. Utiliza las que más te sean de utilidad. 1.3.7 Diseño Conceptual

El diseño conceptual se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas:

• Identificar los usuarios y sus roles

• Obtener datos de los usuarios

• Evaluar la información

• Documentar los escenarios de uso

• Validar con los usuarios

• Validar contra la arquitectura de la empresa



41

Una forma de obtener estos requerimientos es construir una matriz usuarios‐actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quién, qué, cuándo, dónde y por qué de la solución. 1.3.8 Diseño Lógico

El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. Un objeto de negocios es la encapsulación de un servicio que abstrae las cualidades esenciales de algo de interés. Un servicio es una unidad con capacidad de cómputo. Un servicio debe satisfacer lo siguiente:

• Ser seguro, lo que equivale a un uso correcto y con autorización

• Ser válido, qué tareas o reglas se pueden aplicar

• Manejar excepciones, informando al cliente

• Contar con un catálogo de servicios que constituye un repositorio de servicios.

• Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los módulos

operen como unidades completas de trabajo. Las tareas de verificación incluyen:

• Una verificación independiente:

o Pre y post condiciones

o Lógica y funcionalidad individual

• Una verificación dependiente:

o Verificación de dependencias

o Que operan como una unidad específica de trabajo

El diseño lógico comprende las siguientes tareas: • Identificar y definir los objetos de negocio y sus servicios • Definir las interfases • Identificar las dependencias entre objetos • Validar contra los escenarios de uso • Comparar con la arquitectura de la empresa • Revisar y refinar tanto como sea necesario Para definir los objetos de negocios y sus servicios se puede usar la técnica de análisis



42

nombre‐verbo de los escenarios de uso. También se puede emplear la técnica sujetoverbo‐ objeto directo. En estas técnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Una interface tiene las siguientes partes:

• Nombre

• Precondiciones, lo que debe estar presente antes de ejecutarse

• Postcondiciones, estado final

• Capacidad o funcionalidad (SQL, pseudocódigo, función matemática)

• Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realización de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente:

• Identificar los eventos disparadores (triggers)

• Determinar cualquier dependencia (existencial o funcional)

• Determinar cualquier problema de consistencia o secuencia

• Identificar cualquier regulación de tiempo crítica

• Considerar algún problema organizacional (transacciones)

• Identificar y auditar los requerimientos de control

• Determinar lugares y dependencias a través de la ubicación

• Determinar cuando el servicio que controla la transacción es dependiente de los servicios

contenidos en otros objetos de negocio

La validación del modelo lógico debe ser tal que éste sea:

• Completo – debe representar todos los escenarios de uso,

• Correcto – el comportamiento lógico debe corresponder con el comportamiento conceptual, y

• Claro – los objetos de negocio y servicios no deben ser ambiguos

En el diseño lógico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología cambiando únicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario (userservices) controlan la interacción. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinación de éstos. Generalmente involucra una



43

interface gráfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interacción con la aplicación. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. Un servicio de usuario incluye un contenido (qué se necesita comunicar al usuario) y una forma (cómo se comunica el contenido) cuando es necesaria la comunicación. Los servicios de negocio (bussinesservices) convierten datos recibidos de los servicios de datos y de usuario en información (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Las tareas de los servicios de negocio son:

• Dar formato a los datos

• Obtener y mover datos desde y hasta los servicios de datos

• Transformar los datos en información

• Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la

transacción.

Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categorías como las siguientes:

• Declaración del esquema y su evolución (estructuras de datos, tipos, acceso indexado, SQL,

APIs)

• Respaldo y recuperación (recuperación de datos si un evento falla)

• Búsqueda y Lectura (búsquedas, compilación, optimización y ejecución de solicitudes, formación

de un conjunto de resultados)

• Inserción, actualización y borrado (procesar modificaciones consistentemente transaccional).

Una transacción es atómica (ocurre o no), consistente (preserva integridad), aislada (otras

transacciones ocurren antes o después) y durable (una vez completada, ésta sobrevive).

• Bloqueo (permite al acceso concurrente a los datos)

• Validación de datos (verifica la integridad del dominio, triggers y gateways para verificar el

estado de los datos antes de aceptarlos, manejo de errores)

• Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios)

• Administración de la conexión (mecanismos básicos para establecer una sesión de los servicios

de datos). Establecer una conexión involucra: una identificación, la colocación y provisión de

datos, tiempo de sesión, el tipo de interacción (conversacional, transaccional, multiusuario,

monousuario).

• Distribución de datos (Distribuye información, a múltiples unidades de recuperación, bases de

datos heterogéneas, según la topologías de la red).



44

1.3.9 Diseño físico

El diseño físico traduce el diseño lógico en una solución implementable y costo‐efectiva o económica. El componente es la unidad de construcción elemental del diseño físico. Las características

de un componente son:

• Se define según cómo interactúa con otros

• Encapsula sus funciones y sus datos

• Es reusable a través de las aplicaciones

• Puede verse como una caja negra

• Puede contener otros componentes

En el diseño físico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico) y la agregación y contención (un componente puede reusar utilizando técnicas de agregación y contención, sin duplicar código). El diseño físico debe involucrar:

• El diseño para distribución – debe minimizarse la cantidad de datos que pasan como parámetros

entre los componentes y éstos deben enviarse de manera segura por la red.

• El diseño para multitarea – debe diseñarse en términos de la administración concurrente de dos

o más tareas distintas por una computadora y el multithreadingo múltiples hilos de un mismo

proceso)

• El diseño para uso concurrente – el desempeño de un componente remoto depende de si está

corriendo mientras recibe una solicitud.

• El diseño con el manejo de errores y prueba de eventos:

o Validando los parámetros‐ a la entrada antes de continuar con cualquier proceso.

o Protegiendo recursos críticos –manejar excepciones para evitar la falla o terminación sin

cerrar archivos, liberar objetos sincronizados o memoria.

o Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en

las bases de datos.

o Debugging – crear una versión para limpiar errores.

o Protección integral de transacciones de negocios – los errores deben regresarse al

componente que llama.



45

Figura 8. Arquitectura física de tres capas de la aplicación cliente/servidor

El diseño físico comprende las siguientes tareas:

• Definir los componentes

• Refinar el empaquetamiento y distribución de componentes

• Especificar las interfases de los componentes

• Distribuir los componentes en la red

• Distribuir los repositorios físicos de datos

• Examinar la tolerancia a fallas y la recuperación de errores

• Validar el diseño físico

De las tareas anteriores la más importante es la distribución de los datos que pueden ser centralizados, una partición, un extracto o una réplica. Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos.



46

Una partición de datos es una segmentación de la base de datos maestra. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposición entre particiones. En una partición horizontal cada hilera existe en una sola base de datos. En una partición vertical cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porción de la base de datos maestra. No se permite la actualización. Se usa un timestampo etiqueta de tiempo para indicar qué tan viejos son los datos. Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local. No se permiten actualizaciones en la base de datos réplica y en la base de datos maestra a la vez, por lo que debe de haber sincronización entre ambas. El diseño físico está íntimamente ligado a una alternativa tecnológica. Ante la acelerada evolución tecnológica es importante considerar los estándares del momento y las tendencias ya que una mala decisión implicará un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back‐end como un servidor robusto multitareas y multithreadingy el front‐end como un cliente muy delgado que no acapare al servidor comunicándose entre sí en una plataforma internet con protocolos estándar en redes heterogéneas.

1.4 CONTROL

OBJETIVO: Describir las diferentes métricas para la evaluación de proyectos de desarrollo de software

• Una métrica es un instrumento que cuantifica un criterio.

• Una estructura de proyecto que sirve de guía al equipo de¬ trabajo e involucra a los usuarios y a

los puestos directivos en su desarrollo y en sus puntos decisivos.

• Un conjunto de productos finales a desarrollar.¬

• Las diferentes responsabilidades y funciones de los miembros¬ del equipo de proyecto y de los

usuarios.

• Una serie de técnicas que ayudan a llevar a cabo los pasos¬ anteriores.



47

Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad. 1.4.1 Las Métricas

En la mayoría de los desafíos técnicos, 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 para intentar mejorarlo, el producto se mide para intentar aumentar su calidad. El principio, podría parecer que la necesidad de la medición e s algo evidente. Después de todo es lo que nos permite cuantificar y por consiguiente gestionar de forma más efectiva. Pero la realidad puede ser muy deferente. Frecuentemente la medición con lleva una gran controversia y discusión. La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos por mencionar algunos aspectos. Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería del software. Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas. Hay varias razones para medir un producto. 1. Para indicar la calidad del producto. 2. Para evaluar la productividad de la gente que desarrolla el producto. 3. Par evaluar los beneficios en términos de productividad y de calidad, derivados del uso de nuevos métodos y herramientas de la 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 o de formación adicional. Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y medidas indirectas. Medidas Directas. En el proceso de ingeniería se encuentran el costo, y el esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado periodo de tiempo. Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc. 1.4.2 MÉTRICAS DEL SOFTWARE

Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.



48

• MÉTRICAS TÉCNICAS: Se centran en lasa características de software pro ejemplo: la complejidad

lógica, el grado de modularidad. Mide la estructura del sistema, el cómo esta hecho.

• MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los

requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se

adapte a los requisitos que me pide el cliente.

• MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del

software. Es decir que tan productivo va a ser el software que voy a diseñar.

• MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma

que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de

la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal

que va hará el sistema.

• MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y

cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se

desarrolla, si una organización de software mantiene registros sencillos.

• MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el

cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran

en la funcionalidad o utilidad del programa.

Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad del software. 1 ‐ Inicio del Plan: Determina el arranque formal del plan de sistemas, con el apoyo del nivel más alto de la organización. 2 ‐ Definición y Organización: Detalla y concreta la descripción del PSI asignando un calendario y recursos humanos al mismo 3 ‐ Estudio información relevante: Se analiza información de interés para el correcto desarrollo del plan de sistemas 4 ‐ Identificación Requisitos: Obtiene la especificación de requisitos que deben tener los sistemas de información analizados por el plan de sistemas. 5 ‐ Estudio S.I. Actuales: Obtiene una valoración de la situación actual. 6 ‐ Diseño modelo: Identifica y define los S.I. Que van a dar soporte a los procesos afectados por el Plan de Sistemas de Información 7 ‐ Arquitectura tecnológica: Se propone la arquitectura tecnológica que dé soporte al modelo de información y sistemas de información. 8 ‐ Definición plan: Se elabora y detalla el plan de sistemas de información: definición de proyectos, actividades, calendario y recursos para implementar los sistemas de información e infraestructura tecnológica



49

9 ‐ Revisión y aprobación: Se somete el plan a la revisión última y aprobación de la dirección. 10 – documentación: Catálogo de requisitos

• Arquitectura de información

• Modelo de información

• Modelo de sistemas de información

• Arquitectura tecnológica

• Plan de acción

• Plan de proyectos

• Plan de mantenimiento

Fases de la métrica: 1.4.3 METRICAS COMO PLANEACION DE SISTEMAS

LOS OBJETIVOS PRINCIPALES DE LAS MÉTRICAS

�Comprender mejor la calidad del producto �Estimar la efectividad del proceso �Mejorar la calidad del trabajo realizado en el nivel del proyecto. DESVENTAJAS DE LAS METRICAS

Uno de los problemas que tienen las métricas es que no existe un esquema de criterios generalmente aceptado (un estándar). Como no hay acuerdo en los criterios involucrados,abundan las propuestas de métricas que abordan la calidad con criterios propios. Otro problema de las métricas es que no proporcionan información por sí solas y a veces en vez de claridad aportan confusión a la contraparte del modelador dentro del proceso. Esto se debe a que muchas métricas no guardan relación con los intereses de las partes, y el indicador de la calidad de un esquema se construye generalmente con todas ellas. CARACTERISTICAS DE LAS METRICAS

Localización: La localización es una característica del software que indica la forma que se concentra la información dentro de un programa. Encapsulamiento: define el encapsulamiento como “el empaquetamiento (o enlazado) de una colección de elementos. Entre los ejemplos de encapsulamiento de bajo nivel(software convencional) se cuentan los registros y matrices, y los subprogramas (porejemplo, procedimientos, funciones, subrutinas y párrafos) son mecanismos de nivelmedio para el encapsulamiento”. El encapsulamiento influye en las métricas cambiando elobjetivo de la medida, que pasa de ser un único módulo a ser un paquete de datos(atributos) y de módulos



50

de procesamiento (operaciones). Además, el encapsulamientoimpulsa a la medida hasta un nivel de abstracción más elevado. Ocultamiento de información: El ocultamiento de información suprime los detalles operativos de un componente de un programa. Tan sólo se proporciona la informaciónnecesaria para acceder a ese componente o a aquellos otros componentes que deseenacceder a él. Herencia: La herencia es un mecanismo que hace posible que los compromisos de un objeto se difundan a otros objetos. La herencia se produce a lo largo de todos los nivelesde la jerarquía de clases. Abstracción: La abstracción es un mecanismo que permite al diseñador centrarse en los detalles esenciales de algún componente de un programa (tanto si es un dato como si es un proceso) sin preocuparse por los detalles de nivel inferior. 1.5 ACTIVIDAD 1 CONCEPTOS BASICOS

NOMBRE DE LA ACTIVIDAD 1: Plan para el desarrollo de un Proyecto de TI UNIDAD TEMÁTICA: I. Fundamentos de la administración de

proyectos de TI

TEMAS: 1.1 Planeación 1.2 Organización 1.3 Dirección. 1.4 Control.

OBJETIVO DE LA PRÁCTICA: El estudiante elaborará el plan para el desarrollo de un proyecto de un sistema TI específico.

TIEMPO DE LA PRÁCTICA: 8:00Hrs FECHA DE

ENTREGA:

DESCRIPCIÓN:

El alumno elaborará un documento donde describa el plan de proyecto para la construcción de un software específico.

MATERIALES Y EQUIPOS:

Papel,manual y computadora.

PROCEDIMIENTO: Por equipo realiza los siguientes pasos:

1) Investigará y analizará la problemática proporcionada por el profesor y

realizará el estudio de factibilidad, donde al final argumentará si es viable o

no el software a desarrollar. Elaboren un documento de una cuartilla donde

explique el porqué de su respuesta.

2) Definan lo siguiente para su proyecto y equipo:

a) Objetivos

b) Metas



51

c) Recursos

d) Actividades

e) Tiempos

f) Roles

g) Organigrama y funciones de los miembros del equipo

h) Métricas para el seguimiento y control del proyecto.

3) Introduzca la información necesaria en Project u otro software, para poder

gestionar el plan de proyecto y además obtener los diagramas de Gantt y

Pert, para poder representar las secuencias de actividades y el

cronograma.

4) Elaboré otro documento Word, donde contenga el total de los puntos 2 y 3.

5) Entreguen al profesor(a) en la fecha asignada en esta actividad, ambos

documentos para su evaluación.

RESULTADOS Y ANÁLISIS:

1) Documento de estudio de factibilidad. Revisar archivo proporcionado

anteriormente.

2) Documento de Plan de Proyecto para el desarrollo de un software

especifico.

CONCLUSIÓN

REFERENCIAS

Antología de la materia

RÚBRICA DE ACTIVIDAD 1 INDICADOR O

VARIABLE DESCRIPCIÓN PORCENTAJE

ACTITUD (SER)

Puntualidad El alumno presenta su trabajo dentro de la tolerancia establecida.

5

Procedimiento de organización

en equipo

La organización y comunicación en el equipo permitió generar óptimos resultados.

5

DESEMPEÑO

Trabajo en equipo

Emitieron como equipo la justificación de la viabilidad del desarrollo del proyecto

10

Trabajo en equipo

Definen correctamente el objetivo o los objetivos 5



52

Trabajo en equipo

Definen correctamente las metas 5

Trabajo en equipo

Definen correctamente los recursos 5

Trabajo en equipo

Definen correctamente las actividades 10

Trabajo en equipo

Definen correctamente los tiempos 5

Trabajo en equipo

Definen correctamente los roles 5

Trabajo en equipo

Grafica correctamente el Organigrama 5

Trabajo en equipo

Define correctamente las funciones de cada equipo 5

Trabajo en equipo

Seleccionan y definen las métricas para el seguimiento y control del proyecto

5

Trabajo en equipo

Presentan de forma adecuada los diagramas Gantt y Pert.

15

PRODUCTO Estudio de factibilidad

Contiene el estudio de factibilidad 5

Plan de proyecto

El documento elaborado contiene cada punto solicitado en la actividad.

10

TOTAL

100



53

2 UNIDAD TEMATICA 2 ANALISIS DE REQUERIMIENTOS

OBJETIVOS:

• Describir las técnicas de recolección de datos.

• Describir las posibles fuentes de error en el proceso de recolección de datos

• Identificar las técnicas usadas para la recolección de datos en ejemplos que se le presenten.

• Seleccionar la técnica de recolección de datos que es conveniente emplear en ejemplos que se

le presenten

INTRODUCCION RECOLECCION DE DATOS. La recolección de datos es un proceso meticuloso y difícil, pues requiere un Instrumento de medición que sirva para obtener la información necesaria para estudiar un aspecto o el conjunto de aspectos de un problema. Para el diseño del instrumento hay que tomar en cuenta: Características del informante: Conocerlas permitirá adecuar el contenido y redacción de las preguntas a su nivel cultural, grado de cooperación e información que esté en condiciones de proporcionar. Tiempo disponible para efectuar la recolección: El tiempo disponible para efectuar la recolección puede influir en la extensión del instrumento y el grado de control que se pueda realizar sobre la calidad de los datos que se obtengan. Para decidir qué instrumento se va a utilizar se consideran tres aspectos fundamentales: I. Fuente de origen de los datos

II. Técnica de recolección a utilizar III. Control de los errores que se puedan cometer. ¿Por qué recolectamos datos?

Lo primero que debemos preguntarnos antes de preparar la recolección de datos es: “¿Por qué estamos recolectando datos?, ¿Qué estamos planeando hacer con los datos?". Una respuesta podría ser, mejorar la forma en que realizamos nuestro trabajo, de tal manera que podemos utilizar mejor nuestros recursos para proveer mejores productos y servicios.

2.1 TECNICAS DE RECOLECCION DE DATOS

1) Observación:



54

La observación directa del fenómeno en estudio es una técnica bastante objetiva de recolección; con ella puede obtenerse información aún cuando no existía el deseo de proporcionarla y es independiente de la capacidad y veracidad de las personas a estudiar; por otra parte, como los hechos se estudian sin intermediarios, se evitan distorsiones de los mismos, sin embargo, debe cuidarse el entrenamiento del observador, para que la observación tenga validez científica. Modalidades de la observación: La observación puede adoptar diferentes modalidades:

• Según los medios utilizados ó clasificación:

o Observación Estructurada: Se observan los hechos estableciendo de antemano qué

aspectos se han de estudiar.

o Observación no estructurada: Consiste en recoger y anotar todos los hechos que

sucedan en determinado momento sin poseer guía alguna de lo que se va a observar.

• Según el papel o modo de la participación del observador:

o Observación participante: Consiste en la participación directa del observador con la

comunidad, el grupo o la situación determinada.

o Observación no participante: El observador permanece ajeno a la situación que observa.

• Según el número de observadores:

o Individual: es la que realiza una sola persona, es obvio que el investigador se centra en

lo que observa.

o Colectiva: es una observación en equipo, puede realizarse de las siguientes maneras:

todos observan lo mismo o cada uno observa un aspecto diferente.

Ventajas:

o ‐ Los hechos se estudian sin intermediarios

o ‐ Se obtiene información independientemente del deseo que tengan los sujetos de

proporcionarla.

o ‐ Los fenómenos se estudian en el momento en que ocurren

o ‐ Es independiente de la capacidad de la persona para suministrar la información o de la

veracidad de ésta.

o ‐ No depende de la memoria del observado

Desventajas:

o ‐ No sirve para estudiar muestras grandes

o ‐ Es una técnica muy costosa pues requiere de observadores altamente entrenados y calificados.



55

o ‐ No ofrece información sobre acontecimientos pasados, actividades futuras o manifestaciones

subjetivas

o ‐ Si la persona se siente observada puede cambiar su conducta habitual

o ‐ El procesamiento de los resultados, por la variedad de información recolectada, es de difícil

cuantificación.

Aspectos a Considerar.

Podemos reflexionar sobre varios aspectos de este medio o ‐ ¿Qué observar?

o ‐ ¿A quiénes observar?

o ‐ ¿Para qué observar?

o ‐ ¿Por qué observar?

o ‐ ¿Quién observará?

o ‐ ¿Qué clases hay de observación?

o ‐ ¿Qué instrumentos, en su caso, se pueden utilizar para

ciertas clases de observación?

o ‐ ¿Dónde observar?

o ‐ ¿Qué limitaciones de eficacia y de ética se dan en la

observación?

o ¿Qué observar?

2) La Entrevista:

En la entrevista una persona (el encuestador) solicita información a otra (el sujeto investigado o encuestado) para obtener datos sobre un problema específico, es decir, debe haber un intercambio verbal entre dos personas. La entrevista puede ser:

• Estructurada: cuando el entrevistador elabora una lista de preguntas las cuales plantea siempre

en igual orden (existe un formulario preparado).

• No estructurada: el investigador hace preguntas abiertas, no estandarizadas, por lo cual esta

técnica deja mayor libertad a ambas partes, sin embargo, tiene el inconveniente de que dificulta

el procesamiento de los datos recogidos. Para obtener datos válidos en la entrevista deben

cuidarse los siguientes aspectos:

• El contacto inicial entre el encuestador y el encuestado: debe existir una relación cordial y

agradable al solicitar la información.

• La manera de formular las preguntas: deben evitarse los tecnicismos.

• Evitar cambiar la pregunta y sugerir respuestas



56

Ventajas:

‐ Permite estudiar gran número de personas ‐ Permite captar manifestaciones subjetivas de los entrevistados por su comportamiento en el momento de la entrevista ‐ Permite preguntar sobre acontecimientos pasados y/o futuros. ‐ Menos costoso que la observación ‐ Puede complementarse con la observación directa ‐ Las respuestas son precisas y esto permite que los datos obtenidos sean susceptibles de cuantificación y tratamiento estadístico ‐ Permite aclarar y repetir preguntas ‐ Pueden notarse discordancias en las respuestas Desventajas: ‐ Depende de la memoria y el deseo de participación de los entrevistados ‐ Se pueden obtener resultados diferentes según el tipo de preguntas y la manera de formularlas ‐ La ausencia de secreto puede influir en la veracidad o deseo de proporcionar las respuestas ‐ Requiere preparación del entrevistador.

3) El Cuestionario:

Puede considerarse como una entrevista por escrito, las preguntas son formuladas por escrito y no se requiere la presencia del entrevistador. Ventajas:

‐ Es una técnica muy económica pues requiere de menos personas y menos tiempo para abarcar a una gran población ‐ Existe menos riesgo de distorsión de las respuestas pues generalmente, son anónimos. ‐ No influye en las respuestas el aspecto u opiniones personales del entrevistador. ‐ Proporciona mayor libertad al responder Desventajas:

‐ Depende de la memoria y el deseo de participación de los encuestados ‐ Puede existir un alto porcentaje de preguntas sin contestar ‐ Se debe cuidar la redacción de las preguntas para que sean entendidas por igual por todos los individuos sometidos a estudio ‐ Presenta problemas con la recolección del formulario, sobre todo si se trabaja con grupos muy extensos y se utiliza el servicio de correo.



57

‐ Puede haber dificultad para realizar el control y verificación de la información.

2.2 ANALISIS DE REQUERIMIENTOS

Objetivos

• Conocer las principales actividades de la ingeniería de requerimientos y sus relaciones.

• Presentar diversas técnicas para la obtención y análisis de requerimientos.

• Conocer la importancia de la validación de requerimientos y cómo se utilizan las revisiones de

éstos en este proceso.

• Entender por qué es necesaria la administración de requerimientos y cómo ayuda a otras

actividades de la ingeniería de requerimientos.

Una vez terminada la recolección de datos, se pasa a la siguiente fase que es el análisis de los requerimientos. Durante este análisis de requerimientos, a veces llamados extracción ó exploración de los requerimientos que Involucre el trabajo técnico de grupo con los clientes para averiguar el dominio de la aplicación, los servicios que el sistema debe proporcionar y las restricciones operacionales propias del sistema, al igual que involucrar a los usuarios finales, administradores, ingenieros de mantenimiento, etc., quienes son llamados líder especialista “stakeholders”. Definición de Ingeniería de Requerimientos: etapas de la ingeniería de requerimientos, técnicas para la recolección de datos, language extended lexicon, modelo de escenarios, los casos de uso, diagramas de casos de uso, relaciones include. Comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diverso requisitos de los inversores, que pueden entrar en conflicto entre ellos. Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [Rational]. Un requerimiento de software puede ser definido como: una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un objetivo. Los buenos requisitos (requerimientos) deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc. – Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para satisfacer un contrato, especificación, estándar, u otra documentación formal. ¿Qué son Requerimientos?

• Los requerimientos de usuario representan el conjunto completo de resultados a ser obtenidos

utilizando el sistema.



58

• Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer más todas las

restricciones sobre la funcionalidad.

• Los requerimientos forman un modelo completo, representando el sistema total a algún nivel de

abstracción.

Rol de Requerimientos

• Si un producto no es lo que el cliente o los usuarios quieren, entonces la calidad de la

construcción es irrelevante.

• El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios que se necesita de

un sistema. Proveer los requerimientos forma parte de un lenguaje que todos comprenden, ya

que todos están involucrados, incluyendo los clientes.

• El primer y básico rol de los requerimientos es por lo tanto la comunicación.

¿Cómo identificamos los Requerimientos?

• Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de

interlocución con usuarios o clientes.

• Este puede desarrollarse utilizando cualquiera de una variedad de técnicas como entrevistas

(método de entrevistas, Interview Method) para intercambiar opiniones,Método de Desarrollo

de Aplicaciones conjunta (JointApplicationDevelopment, or JAD Se centra en el marco de trabajo

conjunto del usuario y del profesional de tecnologías de información. JAD centra la atención en

la estructuración de las sesiones de trabajo, donde cada uno escucha lo que los demás tienen

que decir, eliminado tiempos de espera entre preguntas y respuestas, así como muchos de los

problemas de las reuniones tradicionales, Tormenta de ideas (brainstorming) puede ser una

forma efectiva de generar montones de ideas sobre un asunto específico para luego determinar

que idea –o ideas‐ presenta la mejor solución. El brainstorming resulta más provechoso cuando

se hace en grupos de entre 8 y 12 personas y en un ambiente relajado, prototipo (Prototyping)

en este modelo, algunas de las capacidades del nuevo sistema son construidas con el,

cuestionarios mínimo de formalidad y control para ser ejecutadas por el usuario para que los

requerimientos puedan ser determinados con seguridad, cuestionarios (checklist) y casos de

uso.

• Cuando los requerimientos se logran redactar a un significativo nivel de detalle, tendremos listo

el documento denominado “Especificación de Requerimientos”.

Requerimientos Funcionales Describen la funcionalidad o los servicios que se espera proveerá el sistema (verbos). Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del



59

usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. Validación de requisitos: Proceso que tiene como misión demostrar que la definición de los requisitos define realmente el sistema que el usuario necesita. Problemas del análisis de requerimientos

• Los especialistas (stakeholders) no saben realmente lo que quieren • Éstos expresan requerimientos en sus términos propios • Diferentes especialistas pueden tener requerimientos en conflicto • Los factores políticos y organizacionales pueden influir en los requerimientos del sistema • Los requerimientos cambian durante el proceso de análisis. Y pueden surgir nuevos especialistas

• El proceso de la Ingeniería de Requisitos

Las Actividades del Análisis de Requerimientos son: 1.‐ Levantamiento: Obtener Requerimientos 2.‐ Análisis: Revisar requerimientos y resolver inconsistencias o contradicciones 3.‐Especificacion: redacción y modelamiento 4.‐ Validación: visto bueno del cliente/usuario



60

2.3 MODELOS TRADICIONALES

Para entender mejor las técnicas que son utilizadas para llevar a cabo el análisis de requerimientos, hay que diferenciar 4 grandes perspectivas sobre las cuales se puede llevar a cabo este proceso.

2.3.1 Descomposición Funcional

Esta estrategia consiste en definir el comportamiento requerido (requerimientos) como una relación entre entradas y salidas de software. Se procede idealmente con una estructura top‐down (arriba hacia abajo), identificando primero la funcionalidad del sistema como un todo. Después se procede a descomponer esta funcionalidad en un conjunto de funciones y subfuncionalidades. El resultado es una estructura jerárquica y de las funciones o funcionalidades y la definición de las interfaces funcionales. La ventaja de la descomposición funcional es que la especificación es escrita en el lenguaje y concepto de quienes implementan. Esto fomenta una buena comunicación de los requerimientos hacia los diseñadores y codificadores. La traducción al diseño y la codificación es sencilla debido a que la especificación de los requerimientos está escrita en términos del espacio de la solución que se necesita.

2.3.2 Análisis Estructurado

Este modelo está basado en la premisa que expone que las dificultades accidentales pueden ser enfrentadas con una aproximación sistemática del análisis del problema usando:

• Un modelo conceptual común para describir todos los problemas.

• Un conjunto de procedimientos que sugieran la dirección general del análisis y brinden un orden

de pasos para el mismo.

• Una serie de pautas o soporte heurístico de decisiones acerca de problema y su especificación.

• Una serie de criterios para evaluar la calidad del producto.

Dentro de las prácticas comunes del análisis estructurado están los diagramas de flujo y los diccionarios de datos. Para tratar los problemas de comunicación y comprensióndel espacio del problema, este tipo de herramientas utilizan un conjunto deestructuras conceptuales –una representación gráfica de la especificación en términosde de estas estructuras‐ basándose en la hipótesis que la descomposición delproblema en términos de datos que el sistema maneja será más clara y menosinclinada al cambio que otra basada en las funciones que el sistema debe realizar.



61

Está técnica ha evolucionado y es ampliamente utilizada dentro del análisis de requerimientos pero también es criticada debido a sus falencias. Uno de los aspectosmás criticados es que este tipo de análisis no provee suficiente asistencia ni guías. Losanalistas tienen dificultad para decidir las partes del problema que deben sermodeladas y cómo deben ser modeladas... Esto conlleva a pensar que el análisisestructurado no facilita la formulación de un SRS (Software RequirementSpecification)o documento de especificación de requerimientos de software que sea claro y con losatributos suficientes para satisfacer a todos los participantes del proyecto.

2.3.3 Especificación Operacional

Este modelo se enfoca principalmente en solucionar dos de los dilemas más importantes que rodean a los requerimientos. El primero, es que las personas queestán involucradas en el proceso de desarrollo no saben que desean construir, sinohasta que lo construyen. El segundo dilema, es el problema que se encuentra inmersoen el paso que implica pasar de una especificación de requerimientos a un diseño quesatisfaga esa especificación. Entre más cercana esté la especificación del diseño, mejory más fácil será la transición entre estas actividades, pero así mismo entre más cercanas son, las decisiones de diseño se convierten en decisiones prematuras. Los elementos claves para una especificación operacional son: • Un lenguaje de especificación formal. • Un motor que permita obtener especificaciones correctas escritas en el lenguaje ya mencionado. Esta aproximación también debería incluir un soporte automatizado para el análisis de las propiedades de la especificación formal y métodos para trasformar dicha especificación en su correspondiente implementación.

2.3.4 Análisis Orientado a Objetos

Este modelo basa sus principios en realizar modelos de la información y el diseño orientado a objetos. Las técnicas del AOO (análisis orientado a objetos) difieren del análisis estructurado en la forma en que se descomponen los problemas en sus partes, y los métodos a través de los cuales se descubren las relaciones entre dichas partes. En este enfoque, el analista descompone el problema en un conjunto de objetos que interactúan entre sí, basados en las entidades y relaciones que existen en el dominio del problema. Un objeto encapsula un conjunto de datos, procesos y estados relacionados. En general, los componentes del AOO son los objetos, sus datos y servicios que prestan, y las relaciones que tienen con otros objetos. Este método representa muy bien el comportamiento del dominio de la aplicación que se desea realizar, pero no es soportado por un modelo conceptual que muestre el comportamiento del dominio del negocio. Otro serio problema, es que la generalidad de esta aproximación se desvía más en el desarrollo de la aplicación y no permite concluir el objetivo específico de obtener un SRS completo.



62

2.4 OTROS MODELOS

Existen aproximaciones basadas en preceptos de las diferentes perspectivas, que satisfacen algunas de las actividades del análisis de requerimientos, donde se propone la utilización de grafos, en este caso dirigidos; en el análisis y descomposición de requerimientos No Funcionales (RNF). En este caso, el autor sugiere que los RNF representen metas a ser satisfechas. Cada meta debe ser descompuesta en subsecuentes submetas y estas a su vez descompuestas de igual manera hasta que se encuentren operacionalización; estas son elementos que representan acciones o atributos que claramente identifican lo que es necesario para satisfacer la meta principal. Esta estructura permite el análisis de interdependencias y la detección de conflictos entre los RNF. Buena Especificación de Requerimientos • Un resultado primario de esta administración es la Especificación de Requerimientos, la cual define y documenta en forma completa el comportamiento externo del sistema a ser construido. Caracterizándose por: – Definidos sin ambigüedad – Son completos – Tienen consistencia – Especifica el origen – Evita detalles de diseño – Están enumerados Beneficios de una Buena Administración de Requerimientos • Mejor control de proyectos complejos. • Mejora en la calidad del software y en la satisfacción del cliente. • Reducción en los retrasos y en los costos del proyecto. • Mejora en la comunicación del equipo. • Facilita la conformidad con estándares y regulaciones. Recolección de objetivos del sistema: Es la primera actividad que se debe llevar a cabo en esta fase. En ella, se busca identificar los objetivos del sistema, que corresponden a los requerimientos del sistema descritos en un nivel de descripción de negocio o Identificación de objetivos iníciales: consiste en extraer los objetivos del sistema, a partir del análisis de la documentación existente o de entrevistas realizadas a los stakeholders. El análisis de documentación existente se realiza examinando, ya sea las entrevistas realizadas a los usuarios del sistema en búsqueda de palabras (verbos) que



63

representen una acción; o, analizando cómo expresan sus requerimientos en forma de operaciones, procesos o diagramas de flujo, en cualquier documento (normalmente informal) que exista acerca del dominio del negocio donde la aplicación será desarrollada. • Descomposición de los objetivos del sistema en requerimientos de usuario: esta actividad persigue como objetivo el descomponer los objetivos previamente establecidos, en requerimientos más detallados (requerimientos de usuario), enfocados en la funcionalidad del negocio sobre el cual se está trabajando. Esta etapa es realizada para cada uno de los objetivos de negocio identificados en la fase anterior. Para las empresas que no cuenten con un proceso maduro, y se encuentren en lo niveles inferiores; se recomienda el uso de escenarios y/o casos de uso. Para cada una de estas herramientas, se analizarán algunas de las estrategias que se pueden utilizar para llevarlas a cabo.

2.5 CASOS DE USO

Casos de uso Un caso de uso es una herramienta que sirve para representar la forma como un cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en la cual, los elementos interactúan, a estas acciones se les llama operaciones o Casos de uso. Casos de uso Un caso de uso es una herramienta que sirve para representar la forma como un cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en la cual, los elementos interactúan, a estas acciones se les llama operaciones o Casos de uso. El caso de uso es una serie de cosas, es una técnica de análisis de sistemas, es una técnica para recopilar requerimientos, puede ser usada como estrategia de desarrollo o conducción de proyectos de sistemas (Use case driving proyects), y su aplicación se ha vuelto muy importante. El creador de los Casos de uso Ivar Jackobson se unió a Grady Booch y James Rambaugh en Rational Rose, para trabajar en lo que hoy conocemos como UML.

2.5.1 Como identificar los casos de uso

1. ¿Cuales son las tareas y responsabilidades de cada actor? 2. ¿Algún actor creará, almacenará, cambiará, borrará o leerá información del sistema?



64

3. ¿Qué Casos de Uso crearán, almacenarán, cambiarán, borrarán o leerán esta información? 4. ¿Es necesario que un Actor informe al sistema sobre cambios externos? 5. ¿Es necesario que un Actor sea informado sobre ciertas incidencias del sistema? 6. ¿Qué Casos de Uso darán soporte y mantendrán el sistema? 7. ¿Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales documentados? Los casos de uso se utilizan básicamente en el proceso de modelado de sistemas, partiendo de una percepción o perspectiva que nos plantea el paradigma de la orientación a objetos, y en este caso el análisis y diseño orientados a objetos. UML por sus siglas en ingles (Unified Modeling Languaje) el cual a su vez se compone de muchas otras herramientas, básicamente diagramas como: Diagramas de Clase, Diagramas de Secuencia, de Colaboracíón, Transición de Estados, Diagramas de Actividad, Componentes, Deployment, entre otros. Todas ellas usadas a lo largo de las etapas o ciclo de vida del proceso de desarrollo de un sistema.

2.5.2 Diagrama de Casos de uso

El diagrama de casos de uso forma parte del conjunto de herramientas del UML y es muy simple elaborar un diagrama de este tipo. Básicamente se conforma de dos figuras elementales el actor y el caso de uso. Un actor que puede ser una persona, pero en particular el rol que desempeña dentro del sistema o entorno que estemos analizando, se representa con un muñequito. Un caso de uso, que es una meta, acción, función, o tarea que desarrolla uno o varios actores y se representa con un elipse.

La aplicación principal de los casos de uso es en el proceso de análisis y diseño pero de manera

particular en la definición de requerimientos del usuario. Es una excelente herramienta de

comunicación debido a la Sencillez de su elaboración así como su comprensión. En teoría

los usuarios deberían conocer como hacer sus propios casos de uso, pero eso solo es en "teoría".



65

Si quisiéramos aprender a modelar sistemas orientados a objetos por medio de Casos de Uso, ¿cuales serían los pasos a seguir? es decir, ¿existe una forma generalmente aceptada que nos diga el 'como', para realizarlos? Identificar actores. Los actores son mejor dicho, los roles que un usuario o usuarios del sistema llevan a cabo en algún momento del tiempo. También pueden ser otros sistemas con los que el 'sistema' en proceso de modelado tiene interacción. Ejemplo: Para un sistema de ventas (directas y por catalogo), nuestros actores pueden ser: Vendedor, Cliente, Supervisor de Ventas. Identificar Metas (Metas, objetivos generales o responsabilidades). Todos los actores en el entorno a modelar tienen metas u objetivos, o en su defecto responsabilidades, o en su defecto, acciones que desean realizar u obtener del sistema. Por ejemplo: Para el sistema de Ventas, el Vendedor tiene como meta, objetivo o responsabilidad (Ofrecer productos, Cerrar Venta, Ganar mucho dinero vía Cobrar comisiones). Obtener o identificar los Casos de Uso a partir de las Metas. Las metas son importantes porque a partir de su identificación pasamos a realizarlas y estas se convierten en los Casos de Uso, de esta forma tan sencilla obtenemos la información de funcionalidad que requiere nuestro sistema. Especificar cada Caso de Uso. Una vez identificados seguimos a especificarlos uno a uno, es probable que en el inter, de esos sencillos pasos algunos casos de uso desaparezcan o



66

se fusionen con otros, por ambigüedades detectadas o por detalles que se hayan escapado durante el proceso. Es importante recordar que de eso se trata el modelado, no es indispensable que quede al cien por ciento el modelo desde la primera vez, por eso hay que hacerlo en iteraciones o ciclos. La especificación de los casos de uso contiene varias partes, las fundamentales son Nombre, Descripción, Actores, Flujo Principal y Flujos Alternos. Este grupo de elementos constituyen lo que se conoce como plantilla (Template), y nos podemos encontrar un sin numero de plantillas en la red. Por ejemplo ésta: Un caso de uso se forma de varios elementos, tiene una estructura, aunque no estandarizada oficialmente, el uso repetitivo en diferentes ámbitos, nos permite conocer algunos de esos formatos o plantillas, las cuales por lo general cuentan de lo siguiente:

• Id. Clave o número de control del Caso de Uso

• Nombre. Es el Caso de Uso en si

• Descripción. Aquí detallamos lo que el caso de uso resuelve con base a su objetivo primordial.

• Actores. En esta sección especificamos el actor o actores principales y los actores

secundarios o auxiliares en el caso de uso. Podemos detallar su nombre, una breve

• descripción y en que otros casos de uso intervienen si se desea. Aunque

• preferentemente esta especificación se puede hacer por separado en otro documento.

• Pre‐condiciones. Las reglas o condiciones que se deben cumplir antes de que sea

iniciado el caso de uso. Por ejemplo, usuario firmado (logged), pago realizado, etc.

• Post‐condiciones. Condiciones que se deben cumplir cuando termine el caso de uso.

• Flujo Principal En la secuencia de pasos del flujo principal, podemos usar texto

solamente numerando cada paso, podemos usar un diagrama de flujo,

un diagrama de secuencia, o una grafica de estados para efectos de dar claridad.

• Variaciones. Aquí listamos los pasos

Extensiones.

• Requerimientos no funcionales. Cualquier elemento indispensable para la

realización del caso de uso, que no tenga impacto en la funcionalidad.

• Diagrama de Contexto. Nos ilustra el alcance del caso de uso, entradas y salidas generales.

• Diagrama de Navegación. Este diagrama nos ayuda a ilustrar el flujo entre las

pantallas (prototipo) que tendrá el sistema para el caso de uso.

2.5.3 DOCUMENTACION DE REQUISISTOS

Las decisiones tomadas durante la etapa de ingeniería de un proyecto son críticas para

asegurar el mejor producto para el cliente en términos de calidad, presupuesto y plazos.



67

Se definen estrategias y procedimientos en una etapa inicial a través del diseño de

un detallado plan de ejecución de proyecto y su ingeniería.

Se recomienda documentar un ejemplo de la información que susténtala documentación de

los requisitos y las especificaciones con que debe contar este vital documento para

indicar los tiempos y costos que se llevara el sistema.

2.6 ACTIVIDAD 2

NOMBRE DE LA ACTIVIDAD 1: Plan para el desarrollo de un Proyecto de TI UNIDAD TEMÁTICA: II. Análisis de Requerimientos.

TEMAS: 2.1Tecnicas de recolección de datos 2.2 Análisis de requerimientos 2.3 casos de uso.

OBJETIVO DE LA PRÁCTICA: El estudiante recompilara los primeros requerimientos de un desarrollo de software.

TIEMPO DE LA PRÁCTICA: 6:00 Hrs FECHA DE

ENTREGA: 22 de Febrero de 2012

DESCRIPCIÓN:

El alumno elaborará un diagrama de caso de uso, para el análisis de los requerimientos del sistema, en base a la recolección de los datos y los primeros requisitos identificados.


Papel, manual y computadora.


6) Recolección de datos. Selecciones una técnica y en base a esta, creen

una herramienta para la recolección de datos. Justifica tu selección.

Para esto, involucre el trabajo técnico de grupo con los clientes para

averiguar el dominio de la aplicación, los servicios que el sistema debe

proporcionar y las restricciones operacionales propias del sistema, al igual

que involucrar a los usuarios finales, administradores, ingenieros de

mantenimiento, etc., quienes son llamados líder especialista “stakeholders”

7) Análisis y recopilación de requerimientos. Diseñen un diagrama de caso de

usos que representen la información obtenida del punto anterior. (página

58).

8) Especificar al menos un caso de uso del diagrama anterior, utilizando una

plantilla.

9) Elabora un documento en Word donde incluyas los puntos anteriores.




68

CONCLUSIÓN

REFERENCIAS


RÚBRICA DE ACTIVIDAD 1

INDICADOR O


ACTITUD (SER)


5


en equipo


5

DESEMPEÑO

Trabajo en equipo

Seleccionaron y justificaron la técnica de la recolección de los datos.

10

Generaron los resultados esperados a utilizar la herramienta

10

Trabajo en equipo

Analizaron y diseñaron correctamente el diagrama de caso de uso.

20

Trabajo en equipo

Elaboraron de forma correcta la especificación de un caso de uso.

20

PRODUCTO

Estudio de factibilidad

Elaboración de la herramienta de la recolección de datos.

10

Plan de proyecto

Diagrama de casos de uso 10

Plantilla de un casos de uso 10

TOTAL

100



69

3 UNIDAD TEMATICA 3 INTRODUCCION A LOS MODELOS DE DESARROLLO

3.1 INTRODUCCIÓN

La Ingeniería de Software surge como la aplicación de modelos y formas

de la ingeniería tradicional a la práctica de construir productos de software;

situación que ha condicionado su accionar al tener como norte las precisiones y seg

uridades que en otros ámbitos tiene la ingeniería.

Históricamente han surgido varios enfoques que buscan abordar de manera

sistemática, la planificación, análisis, diseño e implementación de los

proyectos de

desarollo de software, sean estos de gran escala y pequeñas aplicaciones, software

a la medida o productos de software. Cada uno de estos enfoques tiene su

raíz en el

preconcepción dominante en su época y, sobre todo, en la búsqueda incesante de m

ejoras a los enfoques precedentes.

Antes de entrar en materia revisando algunos de los modelos de desarrollo es impo

rtante precisar algunos conceptos básicos. La ingeniería de Software es una discipli

na o área de la informática que ofrece métodos y técnicas para desarrollar

y mantener software de calidad que resuelven problemas de todo tipo.

3.2 Definición Ingeniería

La ingeniería es el estudio y la aplicación de las distintas ramas de la

tecnología. El profesional en este ámbito recibe el nombre de ingeniero.

La actividad del ingeniero supone la concreción de una idea en la realidad.

Esto quiere

decir que, a través de técnicas, diseños y modelos, y con el conocimiento provenie

nte de las ciencias, la ingeniería puede resolver problemas y satisfacer necesidades

humanas.

La ingeniería también supone la aplicación de la inventiva y del

ingenio para desarrollar una cierta actividad. Esto, por supuesto, no

implica que no se utilice el método científico para llevar a cabo los planes.



70

3.3 Definición Software

Es el conjunto de los programas de cómputo, procedimientos,

reglas, documentación y

datos asociados que forman parte de las operaciones de un sistema de computación

. [Std. 729, IEEE]

El software no son solo programas, sino todos los documentos asociados y

la configuración de datos que se necesitan para hacer que estos programas

operen de

manera correcta. Un sistema de software consiste en diversos programas independi

entes, archivos de configuración que se utilizan para ejecutar estos programas, un

sistema de documentación que describe la estructura del sistema, la documentación

para el usuario que explica como utilizar el sistema y sitios web que permitan a los

usuarios descargar la información de productos recientes. [Sommerville, 2004]

El software de computadora es el producto que los

ingenieros de software construyen y después mantienen en el largo plazo. El

software se forma con (1) las instrucciones (programas de computadora) que

al ejecutar se proporcionan las características,

funciones y el grado de desempeño deseados; (2)

las estructuras de datos que permiten

que los programas manipulen información de manera adecuada; y (3) los

documentos que describen la operación y uso de los programas. [Pressman, 2005]

Principales áreas de estudio y/o investigación

• Métodos y Metodologías de Desarrollo de Software

• Procesos de Desarrollo de Software

• Gestión de Proyectos de Software

• Medición y Estimación de Software

• Ingeniería de Requisitos / Requerimientos

• Ingeniería de Software Empírica

• Gestión de Riesgos



71

• Usabilidad de Software

• Evaluación de Software

• Métricas de Software

• Calidad de Software

• Métodos Formales

• Ingeniería Web

•

3.4 MODELOS DE DESARROLLO DE SOFTWARE

Los métodos o modelos de la ingeniería de software. Suministran el cómo

construir técnicamente el software. Los métodos abarcan un amplio espectro de

tareas que incluyen: planificación y estimación de proyectos, análisis de los requerimientos del

sistema y del software, diseño de procedimientos algorítmicos, codificación, prueba y mantenimiento. Los modelos de la ingeniería de software introducen frecuentemente una notación especial orientada al lenguaje o gráfica y a un conjunto de criterios para la calidad del software.

La ingeniería de software tiene varios modelos, paradigmas de desarrollo en los cuales se puede apoyar para la realización de software. En esta unidad se revisarán cuatro de los más utilizados:

• Modelo en Cascada

• Modelo en Espiral

• Prototipos

• DRA

• Modelo XP

Y en la última parte se abordará uno de los modelos más utilizados en la actualidad: el Proceso Unificado de Desarrollo

3.5 MODELOS EN CASCADA

El modelo en cascada es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software de tal forma que el inicio de cada etapa debe espera a la finalización de la inmediatamente anterior. Un ejemplo de una metodología de desarrollo en cascada es: 1. Análisis de requisitos 2. Diseño del Sistema



72

3. Diseño del Programa 4. Codificación 5. Pruebas 6. Implantación 7. Mantenimiento De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

3.5.1 Modelo en Cascada1(Bennington 1956):

El más conocido, está basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe



73

comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación. Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Desventajas:

• Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay

iteraciones y se crean problemas en la aplicación del paradigma.

• Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos.

El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que

pueden existir al comienzo de muchos productos.

• El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará

disponible una versión operativa del programa. Un error importante no detectado hasta que el

programa este funcionando puede ser desastroso.

La ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

3.5.2 Modelo V (Ministerio de Defensa de Alemania, 1992):

El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolución del mismo.



74

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior. Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada. Desventajas:

• El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al

final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la

implementación, lo que puede traer como consecuencia un

• “roll‐back” de todo un proceso que costó tiempo y dinero.

• El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa

que en la realidad puede ocurrir.

• Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo,

lo que disminuye el riesgo.



75

A pesar de todo lo antes mencionado, definitivamente se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada.

3.5.3 MODELO EN ESPIRAL

Desarrollado por B. Boehm, básicamente, la idea es Desarrollo Evolutivo, usando el Modelo de Cascada para cada etapa; está orientado a evitar riesgos de trabajo. No define en detalle el sistema completo a la primera. Los desarrollares deberían solamente definir las mas altas prioridades. El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo. El proceso se representa como una espiral más que como una secuencia de actividades con vuelta hacia atrás Es decir: cada iteración integra el resultado anterior Cada vuelta en la espiral representa una fase del proceso. Cada fase supone un avance en el proceso de desarrollo No hay “etapas” fijas tradicionales, ligadas a actividades como la especificación o diseño. Cada vuelta en la espiral determina las actividades a realizar.



76

3.5.4 MODELO DE PROTOTIPOS

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada proceso o salida. El paradigma de construcción de prototipos (figura 1.4) comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido que se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo, el prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar.



77

El prototipo puede servir como “primer sistema” pero se recomienda tirar debido a que la construcción de prototipos también puede ser problemática por las siguientes razones:

1. Con la prisa de hacer que funcione el prototipo no se ha tenido en cuenta la calidad del software

global o la facilidad de mantenimiento a largo plazo.

2. El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo

funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de programación

inadecuado.

3.5.5 MODELO DRA (FALTA INVESTIGAR DE ESTE TEMA)

El modelo DRA (Desarrollo Rápido de Aplicaciones) Figura 1.5 es una adaptación a “alta velocidad” del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA, permite al equipo de desarrollo crear un “sistema completamente funcional dentro de periodos cortos de tiempo”.



78

3.5.6 MODELO XP

Programación Extrema (XP)

El método XP (Programación extrema) define un conjunto de prácticas óptimas (ver figura 1) para el desarrollo de aplicaciones (3) en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, esto nos interesa mucho, pues el usuario final es el que mejor definirá (desde nuestro punto de vista) el curso del proyecto Mediateca.



79

La selección de esta metodología fue atendiendo a las Características de XP, las cuales incluyen 4 componentes importantes que se adaptan a nuestro proyecto:

• Pruebas Unitarias (Testing): Son las pruebas que se realizan a los principales procesos de

tal manera que se adelantan al futuro, con lo cual se hacen valoraciones de las fallas posibles

obteniendo con ello los errores potenciales.

• Refabricación: se basa en la reutilización de código, para lo cual se crean patrones

(prototipos) o modelos estándares, siendo más flexibles al cambio.

• Programación en pares: una particularidad de esta metodología es que propone la

programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto

en una misma estación de trabajo. Esta característica es particularmente valiosa para nosotros,

ya que en el diseño y programación de las páginas habrá pares de personas cuyo trabajo será

apoyado mutuamente.

Los fundamentos que debemos tomar en cuenta son:

• La comunicación (entre los usuarios y los desarrolladores)

• La simplicidad, al desarrollar y codificar los módulos del sistema

• La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios

finales



80

Por lo tanto será importante tener en cuenta algunas consideraciones para el buen desempeño de este trabajo:

• Empezar por un prototipo inicial añadiendo la funcionalidad con retroalimentación continua

• Los cambios se convertirán en parte sustantiva del proceso

• No se introducirá funcionalidades antes que sean necesarias

• El cliente o el usuario se convierte en miembro de equipo

3.5.7 Ciclo de vida

Ciclo de vida de un proyecto XP

Para entender la planeación de la metodóloga que seleccionamos es necesario

entender su ciclo de vida lo que implica en cada etapa, por ello se especifica de

manera general lo que consiste cada etapa (4).



81

El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la

Entrega, Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.

• Exploración

En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas o unos cuantos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología. • Planificación de la Entrega (Release)

En esta fase el cliente establece la prioridad de cada historia de usuario y los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. Esta fase dura unos pocos días. Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se



82

pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación. • Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de

Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores. • Producción

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación (por ejemplo, durante la fase de mantenimiento). • Mantenimiento

Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevasiteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. • Muerte del Proyecto

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. El mérito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.



83

Figura 1. Las prácticas se refuerzan entre sí



84

4 UNIDAD TEMATICA 4 FUNDAMENTOS DE LA POO

Objetivos de aprendizaje

Se pueden identificar tres objetivos fundamentales de esta lección para el alumno:

1 Introducir el paradigma de la POO como el principal en la actualidad. 2 Destacar sus características y profundizar en los conceptos básicos subyacentes. 3 Estudiar muestras de código en Java como el LPOO elegido para la realización de la práctica y de este modo conectar las partes práctica y teórica del tema.

4.1 INTRODUCCIÓN Y BREVE HISTORIA DE LA POO Y LOS LPOO

En un sentido general se puede considerar la orientación a objetos como un marco para la ingeniería del

software basado en objetos y clases. Abarca desde los principios del análisis de un problema hasta el final

de su implementación y su dominio de aplicación también es muy amplio. Según varios autores, el

interés por la OO surgió en el contexto de la crisis del software de los años 70 (la falta de reusabilidad de

software). Al hablar de la OO, se suelen identificar las siguientes ventajas:

La POO y los LPOO juegan un papel importante dentro de las tecnologías OO. Según la literatura, el

término objeto emergió paralelamente en varios campos de la Informática a principios de los años 70,

para hacer referencia a nociones superficialmente distintas aunque relacionadas. La identificación de la

importancia de la composición de sistemas en niveles de abstracción, la ocultación de información y el

desarrollo de mecanismos de tipos de datos abstractos en los años 70 tuvieron una gran influencia en el

desarrollo de la POO, aunque existe cierta polémica sobre como exactamente estos avances dieron lugar a

lo que hoy en día se considera como POO. El LPOO Simula apareció en 1962 (y más tarde Simula67 en

1967) y, aunque no fue muy utilizado, ha sido reconocido como el primer LPOO, incorporando los

conceptos de clase y objeto.

El concepto de POO propiamente dicho fue presentado por Alan Kay, uno de los inventores de

Smalltalk (el primer LPOO popular), algunos años más tarde:

Se trata de una caracterización muy general que no se puede aplicar a muchos de los LPOO más



85

utilizados hoy en día. Smalltalk tenía estas características y fue concebido con el objetivo de ser un LPOO

dinámico, que permitiera la adición de nuevas clases, objetos y comportamiento sobre la marcha. En las

actas del congreso HOPL II editadas en 1993 por la ACM (Association of Computing Machinery), Kay

definió la POO en términos de una célula que permite el flujo de información en las dos direcciones, pero

en la cual lo que está dentro está oculto desde fuera. En 1985 apareció el LPOO Eiffel, diseñado para

mejorar la productividad y calidad de programas OO, pero no fue muy utilizado.

Para que la POO se estableciera como un paradigma era necesario que los programadores lo

adoptaran. Por eso fue muy efectiva la modificación de un LP ya existente para incorporar los conceptos

(y beneficios) de la POO, sin perder la posibilidad de reutilizar código fuente, como ocurrió con C++ (que

es una extensión de C que incluye los conceptos OO). Otros LP han sido expandidos también para

incorporar estos conceptos: Modula2 se convirtió en Modula3, Ada en Ada95, Lisp en CLOS (Common

Lisp Object System) – vía Flavors, COBOL en Object COBOL, etc. Como ejemplos de LPOO de nueva

creación se pueden destacar Python, Java y C#. Actualmente se pueden identificar unos 140 LPOO que se

usan de alguna forma u otra.

Otra manera de ver la POO es como la evolución natural de la programación imperativa, desde la

programación sin estructura, pasando por la programación procedimental y modular. En primer lugar, la

programación sin estructura es la más sencilla y cada programa consiste en una secuencia de

instrucciones que operan sobre datos globales o comunes a todas las partes del programa. Lo que ocurre

es que, según va creciendo el programa, van surgiendo problemas. Por ejemplo, si se necesita la misma

secuencia de instrucciones en varias partes del programa, hay que copiarla. Para evitar este problema, se

empezaron a extraer estas secuencias, a darles un nombre, y a ofrecer una técnica para llamarlas y

devolver el flujo de control desde ellas al programa principal junto con los resultados. Así aparecieron los

procedimientos y funciones y la programación procedimental. Con la incorporación del paso de

parámetros y procedimientos dentro de otros, se podían escribir programas con más estructura y menos

probabilidades de errores. Así, en vez de ver un programa como una secuencia de instrucciones, se podía

contemplar como una secuencia de llamadas a procedimientos. La extensión natural de este tipo de

programación consistió en agrupar en módulos procedimientos comunes a varios programas, y así surgió

la programación modular. En ella cada módulo tiene sus propios datos y estado, que se modifican con las

llamadas al módulo. Por último, como se verá a continuación, la POO soluciona algunos de los problemas

de la programación modular: puede haber simultáneamente múltiples versiones de un mismo objeto y

cada una es responsable de su propia creación y destrucción.

4.1.1 DEFINICIÓN DE POO Y CARACTERIZACIÓN DE LOS LPOO

Es muy difícil definir la POO y listar todos los LPOO existentes porque hay diferencias de opinión sobre

lo que significa exactamente el término POO y sobre cuáles son las características de un lenguaje de este

tipo. Sin entrar en este debate, basta proporcionar una definición general de POO y a continuación

describir las características principales que se suelen relacionar con los LPOO, para comprender sendos

conceptos1:



86

Una vez definida la POO se pueden identificar las características principales que definen a los LPOO

según la mayoría de los autores:

A continuación se procede a explicar cada una de estas cinco propiedades.

4.2. LA BASE DE OBJETOS Y CLASES

Objetos

Los objetos son la base de la POO. El mundo está lleno de objetos: el perro, la mesa, la televisión, la

bicicleta, etc. y todos ellos tienen dos características: estado y comportamiento. Por ejemplo, los perros

tienen estado (raza, edad, sexo, color, nombre, etc.) y comportamiento (ladran, muerden, saltan, mueven

la cola, etc.). También las bicicletas tienen estado (marca, número de marchas, etc.) y comportamiento

(frenan, aceleran, etc.).

Además, se puede usar los objetos de software para representar conceptos abstractos, como por ejemplo,

el evento generado por el sistema operativo cuando un usuario mueve el ratón o presiona una tecla del

teclado.

Clases

Se puede pensar en una clase como una plantilla, y en un objeto, como una instancia de la clase.

Representación de una estructura de datos abstracta junto con las operaciones que se pueden realizar con

ella.

Dentro de lo que es el estado del objeto cabe distinguir entre las variables de instancia (datos distintos en

cada instancia; por ejemplo, el color de la bicicleta) y las variables de clase (datos comunes a todas las

instancias; por ejemplo, el nombre de la empresa que construye todas las bicicletas BH). También debe

hacerse la distinción entre métodos de instancia (que trabajan con el estado de una instancia de la clase) y

métodos de clase (que funcionan igual en todas las instancias).



87

De la misma manera que las empresas pueden aprovechar las características de las bicicletas a la hora de

construir otras nuevas (no sería eficiente empezar desde cero cada vez que se quiere producir un nuevo

modelo), en la POO se puede aprovechar el hecho de que los objetos son de una cierta clase para crear

otros nuevos.

Como una clase describe un conjunto de objetos con características y comportamientos idénticos, se

puede pensar en una clase como si fuera un tipo. La diferencia estriba en que un programador define una

clase para un problema en concreto y no está obligado a usar un tipo existente, vinculado más bien con la

estructura de la máquina que con el problema. Una vez definida una clase, debe representar una unidad

de código útil que se pueda volver a usar en el futuro. No es fácil de conseguir al principio, pero con la

experiencia se pueden producir clases así.

Objetos vs. clases

En algunos círculos se usa el término objeto solamente para hacer referencia a las instancias de una clase

y en otros, a la clase en sí. Sin embargo, para que pueda existir una clase como instancia de otra, debe

introducirse el concepto de metaclase.

Se pueden distinguir cuatro tipos de relaciones entre los términos objeto, clase y metaclase en los LPOO:



88

Comparación

objeto/clase/metaclase

Tipo Elementos Definición LPOO

1 Objeto Se considera las clases como objetos Self

2

Objeto Clase Los objetos son instancias de las clases

pero no se puede acceder a las clases

desde los objetos

C++

3

Objeto Clase

Metaclase

Los objetos son instancias de las clases y

las clases de las metaclases. Se puede

acceder a las clases desde los objetos

Java

4

Objeto Clase

Metaclase

Metaclase clase

Los objetos son instancias de las clases y

las clases de las metaclases. Se puede

acceder a las clases desde los objetos. Aquí

(a diferencia del tipo 3) la clase de una

metaclase no es sí mismo.

Smalltalk

4.3. EL ENCAPSULAMIENTO Y LA OCULTACIÓN DE INFORMACIÓN

Se suele confundir los conceptos de ocultación de información y encapsulamiento, en parte porque los

autores más conocidos del mundo de la POO tienen definiciones e interpretaciones distintas y solapadas.

Se proponen las siguientes:

Como puede verse, si la ocultación de información fuera lo mismo que el encapsulamiento, entonces

todos los datos y comportamientos encapsulados en un objeto estarían también ocultos, y normalmente

no es así.

El encapsulamiento y la ocultación de información aportan dos ventajas a los desarrolladores de

software:

4.4. LAS RELACIONES ENTRE OBJETOS: LA AGREGACIÓN Y LA HERENCIA

Un objeto solo no es muy útil, sino que lo es cuando está relacionado con otros objetos. En general puede



89

haber cuatro tipos de relaciones entre los objetos: relaciones de instanciación, asociación, agregación y de

herencia. Se ha visto antes que un objeto es una instancia de alguna clase y, por lo tanto, las relaciones de

instancia son del tipo: “es un/a”. Un objeto está asociado con otro si lo usa a través de mensajes que le

envía; por eso se llaman relaciones de uso o asociación. Aquí se tratan los otros dos tipos de relaciones.

Las relaciones de agregación son relaciones del tipo: “tiene un/a” (en el caso de un coche: tiene un motor,

suspensión, etc.). Se puede distinguir entre dos tipos de objetos formados por agregación: un objeto

monolítico y uno compuesto:

Se puede saber bastante acerca de un objeto por su clase. Con el ejemplo de la bicicleta, aunque uno no

sepa qué es una “penny-farthing2”, si sabe que es un tipo de bicicleta, sabrá que tiene ruedas, manillar,

sillín y pedales. De forma similar, la POO permite que se definan las clases en términos de otras clases.

Por ejemplo, las bicicletas de montaña, de carrera y tándems, son todos tipos de bicicleta y, por lo tanto,

según la terminología OO son subclases de la clase Bicicleta. Y Bicicleta es su superclase. La herencia

representa relaciones de: “es un tipo de”.

La manera en que se puede definir una clase u objeto como extensión de otra clase u objeto.

Todas las subclases heredan el estado (en términos de las declaraciones de variables) y los métodos de la

superclase. Aun así, las subclases no se limitan al estado y comportamiento dado por la superclase, sino

que pueden añadir nuevas variables y métodos a los que hereden. Por ejemplo, un tándem tiene dos

sillines y dos pares de pedales, y una bicicleta de montaña tiene neumáticos gruesos.



90

Modelo de bicicleta inventado entre 1870 y 1875; véase www.inet-shibata.or.jp/~HSbicycles/ HISTORY1.htm.

Las subclases también pueden sobrecargar los métodos heredados para proporcionar implementaciones

especializadas de estos métodos. Por ejemplo, en el caso de una bicicleta de montaña con un conjunto de

marchas distinto del de la bicicleta de paseo, será necesario sobrecargar el método cambioDeMarcha para

que el ciclista pueda utilizar las nuevas marchas.

No hay límite en cuanto a las capas de herencia; el árbol de herencia o jerarquía de clases puede ser

tan profunda como sea necesaria. Y los métodos y variables son heredados en los niveles inferiores. Y en

general, cuanto más abajo en la jerarquía esté la clase, más especializado será su comportamiento.

La mayoría de los LPOO ofrecen herencia de clases, pero hay otros, como Self y JavaScript, que

permiten herencia de objetos, e incluso hay lenguajes como Python y Ruby que permiten las dos formas.

Aquí se tratará la herencia de clases porque es la más común, pero cabe mencionar brevemente que la

herencia de objetos permite extender el comportamiento de objetos en el tiempo de ejecución. Dentro de

la herencia de clases hay que distinguir entre la herencia de implementación y de sub-tipo:



91

La distinción más importante que se puede mencionar entre la utilización de la herencia por los LPOO es

la existente entre la herencia simple y la múltiple. El segundo tipo permite la herencia de más de una

clase a la vez cuando se define una clase nueva. Por ejemplo, puede haber una clase que defina las

características y comportamientos de los motores, así que se podría definir una nueva clase Motocicleta,

que sería una subclase de la clase Bicicleta y también de la clase Motor.

La herencia múltiple puede parecer que sea un rasgo esencial para un LPOO para casos como el

ejemplo que se acaba de presentar. Pero la herencia múltiple introduce algunas complicaciones en el

LPOO que la ofrece: problemas como los conflictos de nombres de clases y las ambigüedades requieren

mecanismos en un LPOO para evitarlos, lo que a su vez añade complejidad al lenguaje. Eiffel es un

lenguaje que se conocido por la manera en que proporciona herencia múltiple en términos de un control

estricto sobre la selección de los rasgos que se pueden heredar y los cambios de nombre necesarios. C++,

en comparación, no proporciona herencia múltiple con la misma flexibilidad, lo que puede llevar a

algunos a pensar que este tipo de herencia es peligrosa e innecesariamente compleja.

Ya se ha podido ver que el tema de la herencia múltiple es más sutil que la mera elección de si un

LPOO la proporciona o no. Un lenguaje puede ofrecer diferentes formas de herencia simple, como por

ejemplo, la de sub-tipos y la de implementación. Se ha visto que tanto C++ como Eiffel tienen los dos

tipos, tanto en la forma simple como en la múltiple. Y Java, por ejemplo, no proporciona la herencia

múltiple de ninguna forma pero sí la simple, de dos formas:

1 La extensión de clases (utilizando la palabra clave extends) que permite una combinación de la herencia de implementación y de sub-tipos. 2 La implementación de una interfaz (utilizando la palabra clave interfaz) que ofrece la herencia de sub-tipos.

Cabe mencionar que la herencia de sub-tipos tiene mucha menos importancia en los LPOO dinámicos

porque el control de tipos no es generalmente relevante, así que se prefiere la herencia múltiple de

implementación sobre la herencia múltiple de sub-tipos (aun así, la mayoría de estos lenguajes

consideran que cualquier clase que hereda de otra es su sub-tipo). La herencia ofrece los siguientes

beneficios:

Finalmente, hay que distinguir entre la herencia estática, que es lo que se suele encontrar en la mayoría de

los lenguajes, y la herencia dinámica, que permite cambiar la clase padre3 en el tiempo de ejecución.

Aunque no se suele ver ésta en muchos LPOO, puede ser útil cuando el conjunto de características de un

objeto (o clase) cambie radicalmente durante su vida. Por ejemplo, un objeto ventana tendrá un conjunto

de características cuando esté abierta, y otras distintas cuando está minimizada como un icono.



92

Clases genéricas o parametrizadas

La conversión de un objeto de una clase base a una más abajo en la jerarquía de clases (lo que se llama

especialización [downcasting]), lo cual se hace con bastante frecuencia al sacar objetos de contenedores

genéricos, es una operación costosa y también potencialmente peligrosa, porque incluso en los LPOO con

comprobación estricta de tipos no se pueden garantizar los contenidos del contenedor. Una solución es

utilizar las clases genéricas o parametrizadas, que se refieren a una manera de parametrizar una clase con

tipos de datos específicos. Un ejemplo típico es la clase Pila, que es parametrizada por el tipo de los

elementos que contiene. Así se puede comprobar que no hay problemas de tipo a la hora de compilar la

clase Pila y que permanece suficientemente genérico para tratar cualquier tipo de elementos.

La ventaja de los tipos parametrizados es que permiten que los LPOO con un sistema de tipos

estáticos mantengan su seguridad de tipos al compilar los programas, manteniendo casi la misma

flexibilidad que los LPOO dinámicos.

Se puede decir que la ausencia de clases genéricas en Java representa una grave limitación en su

sistema de tipos. En realidad, la mayoría de objetos en un programa existen dentro de algún tipo de

contenedor, y como en Java los contenedores no tienen tipo, se puede decir que su sistema de tipos no

ofrece ninguna ventaja sobre las alternativas dinámicas.

Evidentemente, los LPOO dinámicos no requieren tipos parametrizados para permitir la

programación genérica. Los tipos se comprueban en el tiempo de ejecución.

Clases abstractas e interfaces o protocolos de interfaces

Las clases abstractas y las interfaces son dos maneras de especificar de antemano una parte del

comportamiento de una clase.

En cuanto a las interfaces, por ejemplo, un lenguaje natural es una interfaz entre seres humanos, las reglas

de comportamiento entre dos equipos de fútbol es una interfaz que permite la realización de un partido y

un mando a distancia es una interfaz entre una persona y una televisión.

En la POO un protocolo de interfaz (o simplemente interfaz en el caso del LPOO Java) es un

mecanismo que objetos no relacionados pueden usar para interaccionar entre ellos. Por ejemplo, la clase

Bicicleta va a definir lo que puede hacer una bicicleta pero solamente en términos de su comportamiento

habitual (es decir, como funcionan normalmente las bicicletas). Pero una bicicleta puede interaccionar con

el mundo de muchas otras maneras que no tienen nada que ver con su función principal.



93

Por lo tanto, en vez de imponer relaciones entre clases de objetos que son fundamentalmente distintos (y potencialmente no conocidos a la hora de escribir el programa de gestión), lo que se hace es establecer un protocolo en la forma de una interfaz que defina (pero no implemente) los métodos que necesita tener cualquier objeto para funcionar con el programa de gestión (por ejemplo, métodos para fijar y ver el precio, asignar y ver el número de serie, etc.). Por lo tanto, si se quiere usar una bicicleta como objeto de gestión para este programa, hay que implementar la interfaz relevante, es decir, tener métodos que controlen el precio y la asignación de un número de inventario, etc.

Las interfaces sirven para definir un protocolo de comportamiento para cualquier punto en la

jerarquía de clases y, en general, se pueden ver las siguientes ventajas de las interfaces para un programa

OO:

Se puede ver que las clases abstractas permiten la implementación del código para un método si se

quieren controlar los aspectos de implementación, ya que una interfaz no puede incluir detalles de

implementación.

4.5. EL LIGAMIENTO DINÁMICO Y EL POLIMORFISMO

Un método con ligamiento dinámico se denomina un método virtual. El principio del ligamiento

dinámico se usa para implementar el polimorfismo. Véanse las definiciones de estos conceptos:



94

En términos generales, capacidad de una entidad de tener varias formas según el contexto.

Específicamente en la POO, habilidad de definir un método en clases distintas según sus necesidades.

A la hora de trabajar con jerarquías de clases, muchas veces es deseable tratar un objeto de una clase

específica como uno de la clase base (llamado generalización [upcasting]), porque así no es necesario

escribir código que depende de una clase concreta. Es una técnica muy potente, porque nos permite usar

el polimorfismo para llamar a un método (que subsume de alguna forma todas las clases en la jerarquía)

y el objeto se comportará de una manera coherente con su estructura, sin que tengamos que comprobar la

estructura explícitamente. Por ejemplo, un objeto que sepa dibujarse en una interfaz visual. Si no fuera

por esta técnica, tendríamos que añadir código explícito para hacer la comprobación (por ejemplo: if o

case) e implementar cada versión correspondiente, lo que no produciría código muy robusto porque

estaría afectado por la adición de nuevas clases. A continuación se puede ver una clasificación del

polimorfismo:



95

En el LPOO Java el polimorfismo por inclusión y de sobrecarga de métodos son estándar. La sobrecarga

de operadores no está permitida.

La utilización correcta de la sobrecarga de operadores puede resultar en código que se entiende mejor. Si

no, puede producir programas crípticos. En los LPOO que incluyen la sobrecarga de operadores hace

falta dos cosas para evitar la ofuscación:

1 Todas las operaciones tienen que tener la forma de mensajes a objetos, para que todos los operadores sean llamadas a métodos. 2 Las operadores tienen que tener una forma funcional equivalente, para que la utilización de una llamada al método se comporte igual, independientemente de si se trata de un infijo, prefijo o posfijo (por ejemplo, 1 + 2 debe ser igual a 1. + (2)).

Las ventajas que ofrece el polimorfismo son las siguientes:

Tanto Java como C++ permiten el polimorfismo.



96

4.6. INTERACCIÓN BASADA EN MENSAJES A OBJETOS

La funcionalidad compleja y útil de un programa OO no proviene de un sólo objeto, que no suele ser

muy útil, sino de la interacción y comunicación entre varios objetos. Por ejemplo, una bicicleta colgada de

una percha en el garaje no sirve de nada. Es solamente cuando se combina con otra entidad (un ser

humano) e interacciona con él que ocurre un comportamiento interesante.

Los objetos de software interaccionan y se comunican entre ellos utilizando los mensajes. Cuando

un objeto O1 quiere realizar uno de los métodos del objeto O2, O1 envía un mensaje a O2. Muchas veces el

objeto recipiente necesita más información para poder realizar el método y esta información se envía con

el mensaje como parámetros.

Los mensajes aportan dos beneficios:



97

Ejemplificación a través de un programa OO y ejercicios

Esta lección termina con un sencillo programa OO que muestra algunos de los principios presentados en

este texto. Estúdielo y realice los ejercicios que aparecen a continuación:

Comente el programa ejemplo del apartado anterior identificando los aspectos de la POO destacados en

este texto que se encuentran allí.

1 ¿En qué ocasiones se debería contemplar la utilización de instancias de clases en vez de heredarlas? 2 Desarrolle un sencillo programa OO (sin detallar el código de cada método) para el juego de cartas mus presentando el diseño como el ejemplo anterior.

ACTIVIDAD 3

NOMBRE DE LA ACTIVIDAD 3: Plan para el desarrollo de un Proyecto de TI UNIDAD TEMÁTICA: IV. Fundamentos de la POO

TEMAS: 4.2. Diagramas de caso de Uso



98

4.3 Diagramas de clases OBJETIVO DE LA PRÁCTICA: El alumno realizará el diagrama de clases y casos de

uso para documentar el análisis orientado a objetos del sistema.

TIEMPO DE LA PRÁCTICA: 6:00 Hrs FECHA DE

ENTREGA: 27 de Marzo de 2012

DESCRIPCIÓN:

El alumno en base al análisis de la POO, elaborará un diagrama de caso de uso y un diagrama de clases del proyecto asignado.


Papel, manual y computadora.


10) Revisar los requerimientos del software y los conceptos de la POO

11) Diseñen un diagrama de caso de usos que representen la información

obtenida del punto anterior.

12) Diseñen un diagrama de caso de usos que representen la información

obtenida del punto anterior.

13) Elabora un documento en Word donde incluyas los puntos anteriores.


CONCLUSIÓN

REFERENCIAS


RÚBRICA DE ACTIVIDAD 3

INDICADOR O


ACTITUD (SER)


10


en equipo


10

DESEMPEÑO

Trabajo en equipo

Generaron los resultados esperados a utilizar la simbología adecuada propuesta por UML

15



99

Trabajo en equipo

Diseñaron correctamente en base a la POO el diagrama de caso de uso.

20

Trabajo en equipo

Elaboraron de forma correcta el diagrama de clases. 20

PRODUCTO

Presenta en formato indicado y incluye presentación 5

Diagrama de casos de uso 10

Diagrama de clases 10

TOTAL

100

DEPARTAMENTO DE DISEÑO E IMAGEN - … · INTRODUCCION AL ANALISIS Y DISEÑO DE SISTEMAS ... 1.4.2...

Documents

Transcript of DEPARTAMENTO DE DISEÑO E IMAGEN - … · INTRODUCCION AL ANALISIS Y DISEÑO DE SISTEMAS ... 1.4.2...