Mara Andrea Mora Araya

Anlisis y Sistemas ICdigo 827

Diseo

de

Gua de estudio

Revisin filolgica Fiorella Monge Lezcano Diagramacin Produccin acadmica y asesora metodolgica Encargado de ctedra Kay Guilln Daz Roberto Morales Hernndez Esta gua de estudio ha sido confeccionada en la UNED, en el 2010, para ser utilizada en la asignatura Anlisis de sistemas I, cdigo 827, que se imparte en el programa de Diplomado en Informtica. Universidad Estatal a Distancia Vicerrectora Acadmica Escuela de Ciencias Exactas y Naturales Kay Guilln Daz

PRESENTACIN

Esta gua es presentada como medio de apoyo para la lectura del libro de texto del curso de Anlisis y Diseo de Sistemas I, cdigo 827, del plan de estudios del Diplomado en Informtica, de la Universidad Estatal a Distancia. Procura despertar en el o la estudiante la curiosidad por descubrir las funciones de un o una analista de sistemas, interno o externo a la organizacin, as como, conocer los diferentes tipos de sistemas y metodologas utilizadas, actualmente, en el mercado laboral para el desarrollo de proyectos informticos. Es preciso crear conciencia de que si no se realiza un buen trabajo en el anlisis y diseo de un proyecto, el resultado no ser otra cosa que el fracaso, lo que implicara no solo un posible despido, si no la prdida de una inversin de, probablemente, miles de dlares o hasta la quiebra total de una organizacin. Lo anterior puede sonar exagerado, y hasta dramtico, pero es una realidad. Las grandes compaas gastan mucho de su capital invirtiendo en software y esperan que este sea de mucha calidad y cumpla las expectativas de los usuarios. Este, y otros temas relacionados con el anlisis y diseo de sistemas, es parte de lo que se aprender con el estudio del libro.

G ENERALIDADES DEL CURSO Este curso se imparte dentro del rea de Ingeniera Informtica, particularmente en el Diplomado de Informtica, cdigo 82, como parte de la carga acadmica del III bloque del programa de estudio.

Se recomienda que el estudiante, al momento de matricularlo, ya haya aprobado los siguientes cursos: Lgica para la computacin (3071), Introduccin a la Programacin (831), Programacin Intermedia (824), o tener experiencia en lenguajes de programacin orientada a objetos.

S OBRE EL MATERIAL PARA EL CURSO Se utilizar el texto de Kendall, E. Kenneth y Kendall, E. Julie (2011). Anlisis y Diseo de Sistemas. 8a. Edicin. Mxico: Pearson Educacin de Mxico, S. A. de C.V. La tabla 1 muestra los temas que presenta el diseo curricular con los respectivos captulos del libro, que deben ser estudiados para cubrir cada uno.

Tabla 1 Distribucin de lecturas por temas de estudioTema del diseo curricular Tema 1: El proceso del software Correspondencia en el libro Captulo 1: Captulo 4: Captulo 6 Tema 2: La ingeniera del software Captulo 7: Sistemas, roles y metodologa de desarrollo Recopilacin de informacin: mtodos interactivos Modelado gil y prototipos Uso de diagramas de flujo de datos Pginas 1-20 103-123 155-183 193-218

Captulo 8:Tema 3: Diseo del software orientado a la informacin Captulo 9:

Anlisis de sistemas mediante el uso de diccionarios de datosEspecificaciones de los procesos y decisiones estructuradas

228-248259-274 441-475 485-508 515-551

Captulo 14: Interaccin humanocomputadora Tema 4: Estrategia, tcnica y mtrica para prueba del software Captulo 15: Diseo de procedimientos precisos de entrada de datos Captulo 16: Aseguramiento e implementacin de la calidad

Tambin, a lo largo de la gua, se har uso de otro libro, con el fin de complementar el texto del curso: Pressman, R. (2010). Ingeniera del Software. Un enfoque prctico.7. Edicin. Mxico: Editorial McGraw-Hill. El estudiante debe hacer uso de forma paralela a esta gua de la orientacin para el curso: Alvarado Zamora, Jorge (2009). Orientaciones para el curso de Anlisis de Sistemas I. EUNED. S ECCIONES DE CADA TEMA Cada uno de los temas de esta gua de estudio est formado por las siguientes secciones: Sumario Sntesis Objetivos Introduccin Gua de lectura para el material de estudio Informacin complementaria (opcional) Ejercicios de autoevaluacin Respuestas a los ejercicios de autoevaluacin Lista de referencias

Sumario Presenta la lista de los subtemas que se refieren a aspectos especficos del tema general.

SntesisTiene como finalidad brindar una conceptualizacin general de lo que trata cada subtema. Objetivos Expone los objetivos especficos que se espera usted alcance luego del estudio de sus distintos subtemas. Introduccin Aproxima al estudiante al contenido del tema. Gua de lectura para el material de estudio Presenta la lista de los temas por desarrollar con sus respectivos nmeros de pgina del libro de texto. Para su fcil ubicacin, se utilizar el siguiente icono:

.

Conceptos claves Su objetivo es poner a disposicin del alumno una serie de palabras y la definicin con la que deben ser entendidas dentro de esta gua. Se distinguirn por el siguiente icono:

Informacin complementaria Profundiza en algn tema ya tratado en la gua, mediante grficas y ejemplos concretos, en caso de que la autora lo consideren necesario. S identificar mediante el siguiente icono:

Ejercicios de autoevaluacin Con el propsito de que usted realice una autoevaluacin de lo estudiado y del aprendizaje obtenido, cada tema incluye una seccin llamada Ejercicios de autoevaluacin, que selecciona algunos de los conceptos tratados en cada subtema del material, a fin de que los resuelva y compare con las respuestas que acompaan a dichos ejercicios. Para su fcil reconocimiento, se utilizar este icono:

Respuestas a los ejercicios de autoevaluacin Presenta las respuestas a los ejercicios de autoevaluacin. Lista de referencias

Brindar una lista de referencias que podr consultar para ampliar cada uno de los temas. Ser sealado por el siguiente icono:

Otros iconos que se pueden utilizar a lo largo de la gua

Actividades

Actividad virtual

Ejemplos o casos

Investigar

Refiere a actividades, ejercicios y tareas sobre el tema tratado.

Indica actividades para realizar en algn multimedia adicional, Internet, o alguna de las plataformas de aprendizaje en lnea de la Uned.

Seala ejemplos o casos de carcter ilustrativo relacionados con los contenidos.

Refiere a procesos de investigacin ms complejos.

Mapa conceptual Sugiere como actividad especfica la realizacin de un mapa conceptual.

Bsqueda Sugiere una bsqueda adicional, por parte del estudiante, de materiales con contenido adicional.

Atencin Se utiliza para llamar su atencin sobre algn punto de singular peso para su proceso de aprendizaje.

Vocabulario Enlista el vocabulario o palabras claves utilizadas en el tema desarrollado.

CONTENIDOPresentacin .................................................................................................................................................3Generalidades del curso ............................................................................................................................................................................... 4 Sobre el material para el curso ..................................................................................................................................................................... 4 Secciones de cada tema ................................................................................................................................................................................ 6

Contenido .................................................................................................................................................. 11 Objetivos ................................................................................................................................................... 15 Tema 1 El proceso de software................................................................................................................. 16Sumario ....................................................................................................................................................................................................... 16 Objetivos ..................................................................................................................................................................................................... 16

1.

El proceso de software ............................................................................................................................................ 17 1.1. Proceso de software y cmo se caracteriza ............................................................................................ 17 Tipos de sistemas...................................................................................................................................................... 17 Roles de los analistas............................................................................................................................................... 17 Ciclo de vida del desarrollo de sistemas ......................................................................................................... 19 Herramientas CASE .................................................................................................................................................. 20 Cmo decidir que mtodo de desarrollo elegir............................................................................................ 23 1.2. Modelos de proceso prescriptivo ............................................................................................................... 24 Modelo en cascada.................................................................................................................................................... 24

Modelos de proceso incremental....................................................................................................................... 25 Modelos de proceso evolutivo ............................................................................................................................ 25 Modelos concurrentes ............................................................................................................................................ 27 1.3. Actividades propias de un proyecto de desarrollo de software ................................................... 33 1.4. Desarrollo rpido .............................................................................................................................................. 34 1.4.1 Prototipos ......................................................................................................................................................... 34 1.4.2 Desarrollo rpido de aplicaciones.......................................................................................................... 36 1.4.3 Modelado gil .................................................................................................................................................. 36 1.4.4 Scrum.................................................................................................................................................................. 37 1.5. La ingeniera de software en la prctica ................................................................................................. 38Ejercicios de autoevaluacin....................................................................................................................................................................... 39 Respuesta a los ejercicios de autoevaluacin ............................................................................................................................................. 41

Tema 2 La ingeniera de software .............................................................................................................. 45Sumario ....................................................................................................................................................................................................... 45 Sntesis ........................................................................................................................................................................................................ 45 Objetivos ..................................................................................................................................................................................................... 45

2.

La ingeniera de software...................................................................................................................................... 46 2.1. Conceptos y principios para la ingeniera del software ................................................................... 46 Conceptos de la ingeniera de software .......................................................................................................... 46

Principios de la ingeniera y software.............................................................................................................. 47 2.2. Aspectos de la ingeniera de sistemas que corresponden especficamente al rea de ingeniera .......................................................................................................................................................................... 49 2.3. Modelo de anlisis y los elementos necesarios para soportarlo ................................................... 50 2.4. Ingeniera de diseo y los conceptos que permiten darle un ambiente robusto en su realizacin......................................................................................................................................................................... 55Ejercicios de autoevaluacin....................................................................................................................................................................... 60 Respuesta a los ejercicios de autoevaluacin............................................................................................................................................. 62

Tema 3 Diseo del software orientado a la informacin ...................................................................... 67Sumario ....................................................................................................................................................................................................... 67 Sntesis ........................................................................................................................................................................................................ 67 Objetivos ..................................................................................................................................................................................................... 67

3.

Diseo del software orientado a la informacin ......................................................................................... 68 3.1. Conceptos que acompaan el modelado de diseo ............................................................................ 68 3.2. Necesidad de un diseo arquitectnico ................................................................................................... 68 Especificaciones de procesos ............................................................................................................................... 70 Espaol estructurado .............................................................................................................................................. 70 Tablas de decisin .................................................................................................................................................... 71 rboles de decisin .................................................................................................................................................. 71 3.3. Concepto de componente en el diseo arquitectnico...................................................................... 72

3.4. Diseo a nivel de componentes................................................................................................................... 72 Cohesin ....................................................................................................................................................................... 73 Acoplamiento ............................................................................................................................................................. 74 Realizacin del diseo a nivel de componentes .......................................................................................... 74 3.5. Diseo de la interfaz de usuario ................................................................................................................. 75 3.6. Tipos de Interfaces de usuario .................................................................................................................... 77 3.7. Lineamientos para el diseo del dilogo................................................................................................. 79Ejercicios de autoevaluacin....................................................................................................................................................................... 81 Respuesta a los ejercicios de autoevaluacin ............................................................................................................................................. 82

Tema 4 Estrategia, tcnica y mtrica para la prueba del software ........................................................ 85Sumario ....................................................................................................................................................................................................... 85 Sntesis ........................................................................................................................................................................................................ 85 Objetivos ..................................................................................................................................................................................................... 85

4.

Estrategia, tcnica y mtrica para la prueba del software ...................................................................... 86 4.1. Anlisis, diseo y evaluacin para la interfaz de los sistemas ....................................................... 86 4.2. Estrategias que existen sobre los diferentes tipos de prueba ....................................................... 90 4.3. Estrategias de prueba y tcnicas definidas para el diseo de casos de prueba ..................... 94

Ejercicios de autoevaluacin....................................................................................................................................................................... 96 Respuesta a los ejercicios de autoevaluacin ............................................................................................................................................. 98

Lista de referencias ................................................................................................................................. 101

Objetivo general

OBJETIVOS

Al concluir el estudio de este curso, el estudiante estar preparado para: Brindar los conocimientos, las destrezas y las tcnicas necesarias para analizar y modelar los procesos sujetos de estudio en el desarrollo de sistemas. Objetivos especficos 1. Analizar el proceso de software por medio del marco de trabajo, que facilita la ingeniera del software. 2. Aplicar los conceptos, mtodos y tcnicas para el desarrollo de software. 3. Disear el software orientado a la informacin para satisfacer los requerimientos definidos por el cliente. 4. Aplicar las herramientas de anlisis y diseo e n estrategia, tcnica y mtrica.

TEMA 1 EL PROCESO DESOFTWARE

S UMARIO Captulo 1: Sistemas, roles y metodologa de desarrollo. Captulo 4: Recopilacin de informacin: mtodos interactivos. Captulo 6: Modelado gil y prototipos. Sntesis La ingeniera de software es toda una ciencia y sirve para crear sistemas de informacin y mantenerlos. Todo sistema debe tener un propsito y una metodologa de desarrollo para lograrlo. Durante la lectura de este tema, el estudiante aprender los diferentes tipos de sistemas, las estrategias y los modelos existentes para crear dicho software y darle mantenimiento. Adems, estudiaremos tambin las actividades de la ingeniera de software en la prctica. O BJETIVOS Al finalizar el estudio de este captulo, entre otras habilidades, usted ser capaz de: 1. Analizar el proceso de software por medio de un marco de trabajo, que facilita la ingeniera de software.

1. EL PROCESO DE SOFTWARE1.1. PROCESO DE SOFTWARE Y CMO SE CARACTERIZA El proceso de desarrollo de software consiste en un conjunto de actividades adaptables que permiten al equipo de trabajo elegir las acciones y las tareas adecuadas para desarrollar un sistema en particular con la idea de entregar un producto de forma oportuna y de alta calidad.TIPOS DE SISTEMAS

de software, porque permite a los ingenieros de software especializados en anlisis buscar, identificar y resolver los problemas (Kendall y Kendall, 2011, p. 8) de los usuarios.ROLES DE LOS ANALISTAS

Existen diferentes tipos de sistemas, los cuales se muestran con mayor detalle en la figura 1.1.

Uno de las especializaciones que un ingeniero de software puede escoger es la de analista de sistemas quien es el que evala en forma sistemtica cmo interactan los usuarios con la tecnologa y cmo operan las empresas, para lo cual examinan los procesos de entrada/salida de los datos y la produccin de informacin con la intencin de mejorar los procesos organizacionales (Kendall y Kendall, 2011, p. 6). Si un proyecto cuenta con un anlisis y un diseo previo del problema a desarrollar, de seguro la finalizacin del proyecto ser exitosa. Por esto, la participacin activa del analista de sistemas es indispensable. Este puede jugar diferentes papeles dependiendo del proyecto y la organizacin. En la figura 1.2 se muestran los tipos de roles y los involucrados para cada uno.

Para conocer ms a fondo cada uno de estos tipos de sistemas, se recomienda revisar el libro en las pginas de la 2 a la 4. Al conocer la variedad de sistemas existentes, se logra entender la necesidad del anlisis y diseo

Sistema

Operacional

Automatizacin de oficinas y trabajo de conocimiento

Informacin Administrativa Soporte de decisiones Sistemas expertos

Soporte decisiones en grupo Trabajo colaborativo

Funcin

Crea u obtiene datos masivamente

Permite tomar esos datos para analizarlos y brindar apoyo

Utiliza esos datos ya analizados para tomar decisiones en la organizacin

Ayuda a mejorar el entorno de los ejecutivos y sus decisiones grupalmente

Ejemplo

Inventario de materiales

Hacer grficos estadsticos con el resumen del inventario

Dispara alertas que indican los resultados del inventario a los encargados

Por medio de red, cada ejecutivo externa su opinin y llegan a conclusiones

Fuente: Kendall y Kendall (2011). Figura 1.1 Tipos de Sistemas

CICLO DE VIDA DEL DESARROLLO DE SISTEMASConsultor

Usuarios del sistema de informacin

Las actividades que realiza el analista de sistemas estn determinadas por el Ciclo de Vida del Desarrollo de Sistemas (SDLC, por sus siglas en ingls), el cual consiste en una metodologa de fases para el anlisis y diseo, de acuerdo con la cual los sistemas se desarrollan mejor al utilizar un ciclo especfico de actividades del analista y los usuarios (Kendall y Kendall, 2011, p. 8).Experto de soporte

Agente de cambio

Analista de sistemas

La figura 1.3 del libro, en la pgina 8, muestra las siete fases del ciclo de vida de desarrollo de sistemas

Usuarios y proyectos

Adminsitrador de proyectos

Fuente: Kendall y Kendall (2011). Figura 1.2. Roles del o la Analista de Sistemas

Revisar el material de texto en las pginas de la 9 a la 13, donde cada una de las fases de este ciclo de vida de desarrollo de sistemas estn bien explicadas.

HERRAMIENTAS CASE

Las herramientas de Ingeniera de Software Asistida por Computadora (CASE, por sus siglas en ingls) son herramientas utilizadas por los analistas que utilizan la metodologa SDLC para mejorar el trabajo rutinario a travs del uso de soporte automatizado. As, la CASE se utiliza para aumentar la productividad, comunicarse con los usuarios de una manera ms efectiva e integrar el trabajo que realizan en el sistema, desde el inicio hasta el fin del ciclo de vida (Kendall y Kendall, 2011, p. 14). La figura 1.5 muestra los pasos para un adecuado ciclo de vida de un sistema utilizando Herramientas CASE superiores en todas las etapas. Las Herramientas CASE inferiores son utilizadas para creacin de cdigo y tienen las siguientes etapas: Identificacin de requerimientos: para crear una solucin informtica, como comnmente llamamos a los sistemas

computacionales, necesitamos investigar cul es la problemtica u oportunidad de mejora (por esto el trmino solucin), que se est presentado en la organizacin. El analista de sistemas inicia su tarea al investigar la situacin actual de la empresa, pero es una tarea imposible de realizar sin ayuda de los usuarios. El problema surge cuando, a veces, estos no saben transmitir de manera adecuada sus necesidades, y se destacan las cualidades del analista al contar con la capacidad de extraer lo que requiere de los usuarios. Para cumplir con la tarea de recopilar los requerimientos, conocer a los involucrados del proyecto, sus necesidades, inconformidades, ideas, entre otros, se pueden utilizar tcnicas como entrevistas y cuestionarios (se profundizar acerca de esto ms adelante).

Identificacin del problema y recopilacin de requerimientos Estructuracin de la Informacin Diseo del Sistema Desarrollo y Documentacin Pruebas y Mantenimiento Implementacin y Evaluacin

Identificar involucrados Identificar con ayuda de los involucrados los requerimientos Ordenar la informacin recopilada Priorizarla y diagramarla Diseo de la Interfaz Grfica Diseo de la Base de datos Programacin del sistema Documentacin interna y de usuario Control de Calidad Mantenimiento de por vida Capacitacin del sistema Evaluacin del sistema por medio de cuestionarios

Fuente: Kendall y Kendall (2010). Figura 1.5. Ciclo vida desarrollo de software utilizando herramientas CASE

Estructuracin de la Informacin: al terminar la investigacin exhaustiva de la situacin real de la organizacin y sus participantes, se obtiene como resultado los objetivos del sistema. Si los objetivos obtenidos no coinciden con las necesidades del usuario, los resultados pueden ser fatales para el proyecto. Diseo del sistema: como dicen por ah: todo entra por la vista y en los sistemas informticos no es la excepcin. El sistema puede ser, funcionalmente hablando, muy robusto, soportar grandes cantidades de datos y tener funcionalidades que le brinden valor agregado al usuario, pero si no tiene una buena interfaz grfica y es altamente amigable, puede ser que el usuario se rehse al cambio y quiera seguir con su forma tradicional de hacer sus labores. Desarrollo y documentacin: en esta etapa participan los programadores,

quienes son los constructores del cdigo del sistema, pero ellos hacen lo que los analistas de sistemas les han indicado, de acuerdo a la recopilacin de la informacin. Dentro de sus funciones est documentar el desarrollo realizado, de forma tan clara y estandarizada, que si otro programador se incorporara a mitad del proyecto pueda entender el panorama del sistema con solo leer la documentacin. Prueba y mantenimiento: las pruebas son parte del control de calidad que se le dar a nuestro producto final. El mantenimiento de un software es como el mantenimiento del carro, indispensable para su correcto funcionamiento y de por vida. Implementacin y evaluacin: Una institucin gubernamental adquiri un sistema informtico administrativo bastante costoso y actualmente slo lo

utilizan para cargar datos, cuando necesitan generar reportes, grficos o dar seguimiento a los procesos para tomar decisiones, lo pasan a Excel y desde ah lo analizan. Lo peor del caso es que el sistema brinda todas las facilidades para generar reportes, grficos y dar seguimiento a los procesos. El problema que se identifica anteriormente es la falta de una correcta capacitacin de las funcionalidades del sistema. En el momento en que el software es liberado al usuario, este debe ser evaluado, luego de una capacitacin previa para que puedan dar su aceptacin o rechazo, es en este momento donde se lleva a cabo el proceso de realimentacin. En esta etapa nos damos cuenta si el software efectivamente cumple las expectativas del cliente.CMO DECIDIR QUE MTODO DE DESARROLLO ELEGIR

metodologas implican caractersticas que no estn marcadas en la figura, esto porque dicha caracterstica no sobresale tanto. Por ejemplo, desarrollar bajo la metodologa gil implica costos, pero son an mayores los costos en los que incurre la organizacin si decide utilizar la metodologa SDLC.Mucha Presenta avances del Planeacin Riesgoso sistema (Tiempo y (Subsistemas) Costo)

Metodologa

SDLC GIL ORIENTADA A OBJETOSFuente: Kendall y Kendall (2011). Figura 1.6. Diferencias entre las metodologas de desarrollo.

La figura 1.6 muestra algunas diferencias importantes entre las metodologas de desarrollo estudiadas en este libro. Algunas

Otra caracterstica importante de mencionar son los riesgos provocados cuando se desarrolla bajo la metodologa gil, esto por la cantidad de versiones que deben mantenerse en el histrico y en la integracin con la siguiente versin puede quedarse algo por fuera o desatar nuevos errores.

La metodologa gil, al igual que la metodologa orientada a objetos, tiene la gran virtud de poder presentar al usuario avances del sistema que se est desarrollando, de forma tal que cuando el producto est terminado, ser mucho ms probable que el cliente obtenga lo solicitado. Adems, le permite al usuario corroborar que realmente se est trabajando. 1.2. MODELOS DE PROCESO PRESCRIPTIVO En el desarrollo de software, los modelos de proceso prescriptivo son utilizados para organizar y para dar una estructura de trabajo al equipo encargado de la construccin del sistema. Todos los modelos del proceso del software pueden incluir las actividades estructurales generales descritas en el punto anterior, pero cada uno pone distinto nfasis en ellas y define en forma diferente el flujo de proceso que invoca cada actividad estructural (as como

acciones y tareas de ingeniera de software) (Pressman, 2010, p. 33). Existen diferentes modelos de proceso, se presentan a continuacin:MODELO EN CASCADA

Tambin llamado modelo de ciclo de vida clsico, es un enfoque secuencial para desarrollo de sistemas. Es utilizado cuando los requerimientos de software estn muy bien definidos y tienen una estabilidad razonable (Pressman, 2010, p. 34). Inicia con la especificacin de los requerimientos por parte del cliente, seguido de la planeacin, modelado, construccin y finaliza con el despliegue, como se muestra en la figura 1.7. No es utilizado con mucha frecuencia en la actualidad ya que en ocasiones deben posponerse actividades para finalizar otras tareas que son dependientes. Adems, el desarrollo de software se ha convertido en un trabajo de constantes cambios, por lo que este modelo se vuelve inapropiado para esta labor.

MODELOS DE PROCESO INCREMENTALComunicacin incio del proyecto recabar los requerimientos Planeacin estimacin programacin seguimiento Modelado anlisis diseo Construccin cdigo pruebas Despliegue entrega asistencia retroalimentacin

Este modelo combina elementos de los flujos de proceso lineal y paralelos (Pressman, 2010, p. 35). Es utilizado cuando los requerimientos del sistema estn bien definidos, pero el alcance del proyecto imposibilita un desarrollo lineal. Se emplea tambin cuando hay una necesidad de hacer una entrega funcional a los usuarios de forma rpida. Dicha funcionalidad puede ir incrementndose con entregas posteriores de software. Vase la figura 1.8.MODELOS DE PROCESO EVOLUTIVO

Los modelos de proceso evolutivos son iterativos y se caracterizan porque permiten desarrollar versiones de software cada vez ms completas. Los modelos ms comunes son: hacer prototipos y el modelo espiral.HACER PROTOTIPOS

Fuente: Pressman (2010, p. 34). Figura 1.7. El modelo cascada

Es utilizado cuando los requerimientos del nuevo sistema no estn muy claros. Ms adelante daremos una explicacin ms detallada sobre este proceso. Vase figura 1.9.

Funcionalidad y caractersticas del software

Comunicacin Planeacin Modelado (anlisis, diseo) Construccin (cdigo, prueba) Despliegue (entrega, retroalimentacin) Incremento # 2 Incremento # 1

Incremento # n

Entrega del n-simo incremento Entrega del segundo incremento Entrega del primer incremento

Calendario del proyecto

Fuente: Pressman (2010. p. 36). Figura 1.8. Modelo incremental hacer un desarrollo rpido de versiones cada vez ms completas (Pressman, 2010, p. 39). Vase figura 1.10.

MODELO ESPIRAL

Es un modelo de proceso evolutivo que combina la naturaleza iterativa de hacer prototipos con aspectos controlados y sistemticos del modelo de cascada. Este modelo tiene el potencial para

Plan rpido Comunicacin Modelado Diseo rpido

estructurales de la ingeniera de software pueden existir de manera concurrente, pero hallarse en diferentes estados. Vase figura 1.11.

Comunicacin Despliegue Entrega y retrolimnetacin Construccin del prototipo

Planeacin Estimacin Programacin Anlisis de riesgo

Fuente: Pressman (2010, p.37). Figura 1.9. Hacer prototiposMODELOS CONCURRENTES

Despliegue Entrega Retroalimentacin Construccin Cdigo Prueba

Modelado Anlisis Diseo

Tambin llamado ingeniera concurrente. Permite al equipo de desarrollo representar elementos iterativos y concurrentes de cualquiera de los modelos de proceso descritos anteriormente, porque todas las actividades

Fuente: Pressman (2010, p. 39). Figura 1.10. Modelo espiral

Inactivo

En desarrollo

Cambios en espera

Representa el estado de una actividad o tarea de la ingeniera de software

La informacin respecto a los modelos de proceso prescriptivo puede ser ampliada en el captulo 2 de Pressman (2010). Ingeniera de Software: Un enfoque prctico.

En revisin En evaluacin

Alcance mnimo

Terminado

Como se observ en todas las figuras, los modelos inician con la fase de comunicacin, la cual la lleva a cabo el equipo de trabajo que normalmente est formado por los desarrolladores, analistas, arquitectos de software y los usuarios. Esta comunicacin es clave en el proceso de anlisis del problema y recoleccin de los requerimientos del sistema. Esta informacin puede ser adquirida de varias maneras:ENTREVISTAS

Fuente: Pressman (2010, p.41). Figura 1.11. Un elemento del modelo de proceso concurrente

Una de las tcnicas ms utilizadas para la recopilacin de informacin son las entrevistas, las cuales, como analistas, nos permiten obtener la opinin del usuario y lo que siente sobre el

estado actual del sistema, los objetivos de la organizacin y los personales, y los procedimientos informales para interactuar con las tecnologas de informacin (Kendall y Kendall, 2011, p. 103). En la siguiente figura se muestran los pasos para realizar una entrevista:1 Entrese de los antecedentes 5 Decida sobre el tipo de preguntas y su estructura

En las entrevistas se pueden realizar dos tipos de preguntas: abiertas o cerradas, cada una de las cuales tiene ventajas, desventajas y ciertos atributos que nos ayudan a tener un panorama ms claro sobre el sistema que necesita el usuario.

2 Establezca los objetivos de la entrevista

Se recomienda al estudiante revisar la figura 4.5 de la pgina 107 del para ver un ejemplo de tipos de preguntas. Las preguntas pueden ser organizadas de tres formas diferentes: Estructura de pirmide: se ordenan de especficas a generales. Estructura de embudo: la entrevista inicia con preguntas amplias y termina con preguntas especficas. Estructura en forma de diamante: combina la estructura embudo y pirmide.

4 Prepare al entrevistado

3 Decida a quin entrevistar

Fuente: Kendall y Kendall (2011). Figura 1.12. Pasos para realizar una entrevista

Al finalizar el proceso de entrevista se procede con la realizacin del informe, el cual se lleva a cabo de manera escrita y en l se capturan los datos, lo ms pronto posible con la idea de asegurar su calidad. Una vez que han sido incluidos, se debe verificar la informacin en conjunto con el usuario para asegurar que se comprendi el problema.

realizacin del correspondiente informe al final de cada entrevista. Esto, generalmente, tomar mucho tiempo, lo que implica tambin dinero. El libro menciona una solucin para esta problemtica llamada diseo de aplicacin conjunta (JAD), donde se crea una sesin de trabajo en la que participen todos los involucrados. El JAD es mejor cuando todo el equipo de trabajo se puede comprometer a asistir. Es preferible realizarlo en una ubicacin fuera del sitio de desarrollo y recomendable que tarde de dos a cuatro das. La idea de realizar esta prctica en un lugar extrao es evitar las distracciones. Al igual que con las entrevistas, el diseo de aplicacin conjunto tiene los beneficios y las desventajas, las cuales deben ser revisadas en el libro de texto.USO DE CUESTIONARIOS

Para obtener mayor informacin sobre las entrevistas, revise el libro de las pginas 103 a la 110.DISEO DE APLICACIN CONJUNTA

Para obtener verdaderos resultados de las entrevistas, es necesario obtener informacin de todos los involucrados en el desarrollo del sistema, como los usuarios finales, ejecutivos, administradores, etc. Para ello, es necesario repetir la lista de pasos para la creacin de una entrevista con cada entrevistado, as como la

Son muy utilizados porque permiten medir con mayor precisin una situacin especfica.

Algunas de las caractersticas de los cuestionarios se mencionan en la figura 1.13.Se puede aplicar el mismo cuestionario para todos los encuestados.

Se determinan los rangos de valoracin de las respuestas de las encuestas.

hay muchas personas involucradas en el proyecto, se desee realizar un estudio que permita medir la opinin general de los usuarios antes de que el proyecto de desarrollo del sistema tome una direccin especfica, y quiera asegurar que se identificaron y consideraron todos los problemas del sistema existente. A diferencia de la entrevista en el cuestionario, no se puede controlar el contexto, por lo que las preguntas deben ser muy claras y su flujo se debe anticipar a las preguntas del encuestado. Adems, el cuestionario debe ser planeado con mayor detalle. En el cuestionario se pueden utilizar tanto preguntas abiertas como cerradas. En la figura 4.12 de la pgina 117 de Kendall y Kendall (2011), se presenta las ventajas de utilizar uno u otro tipo de preguntas.

Se obtienen resultados ms precisos.

Es ms sencillo visualizar los resultados obtenidos en forma grfica.

Fuente: Kendall y Kendall (2011). Figura 1.13. Caractersticas de los Cuestionarios Segn Kendall y Kendall (2011) es apropiado aplicar un cuestionario cuando las personas que van a ser interrogadas no estn concentradas en un solo lugar,

La figura 1.14 muestra las reglas para disear un buen cuestionario, ya sea web o en papel. Tome en cuenta que a la hora de aplicar un cuestionario, es de suma importancia seguir los lineamientos acerca del lenguaje que se va a utilizar. Verificar la informacin de las pginas 116 a la 118 del libro. Hay dos formas de escalas de medicin de cuestionarios que utilizan los analistas: Escalas nominales: utilizadas para clasificar cosas. Escalas de intervalo: los intervalos entre cada uno de los nmeros son iguales, lo que permite realizar operaciones matemticas con los datos obtenidos en el cuestionario dando como resultado un anlisis ms completo. Las escalas pueden ser de validez y de confiabilidad, pero hay que ser cuidadoso en su diseo para evitar alguno de estos problemas: indulgencia, tendencia central o efecto halo.Incluya mucho espacio en blanco.

Incluya mucho espacio para escribir o teclear respuestas.

Facilite a los encuestados la accin de marcar con claridad sus respuestas.

Mantenga un estilo consistente.

Fuente: Kendall y Kendall (2010). Figura 1.14. Pasos para realizar cuestionario en papel o la web En los cuestionarios, segn Kendall y Kendall (2011), no hay una forma definida para ordenar las preguntas, por lo que es mejor seguir los siguientes pasos:

1. Coloque primero las preguntas que sean importantes para los encuestados. 2. Agrupe elementos de contenido similar. 3. Introduzca primero las preguntas menos controversiales (p. 121). Respecto a la administracin de los cuestionarios, es clave la definicin del conjunto de encuestados para obtener un muestreo razonable. Adems, el mtodo elegido para la administracin depender del tipo de negocio al que le sea aplicado.

1.3. ACTIVIDADES

PROPIAS

DE

UN

PROYECTO

DE

DESARROLLO DE SOFTWARE

Aunque hay gran cantidad de tipos de sistemas, existen una serie de actividades estructurales que son aplicables a cualquier tipo de proyecto de software. Segn Pressman (2010), dichas actividades son las siguientes: comunicacin: es vital, entre los integrantes del equipo de desarrollo y con los futuros usuarios del sistema (clientes), ya que la calidad del software depender de la recoleccin preliminar de los requerimientos; planeacin: la creacin de un plan del futuro proyecto es de gran importancia, ya que esto permitir determinar las tareas tcnicas a realizar, productos a desarrollar, programar actividades, recursos que se requieren y establecer riesgos que podran acontecer mientras se desarrolla el proyecto;

Para tener una visin ms clara acerca de la informacin de los cuestionarios se recomienda revisar la el libro desde la pgina 114 a la 122.

Costo del desarrollo

modelado: la creacin de un boceto preliminar del software a desarrollarse permite al analista y al programador tener una idea general de cmo se ver arquitectnicamente, cmo se ajustan entre s las partes constituyentes y otras caractersticas ms (Pressman, 2010, p. 13).; construccin: es la generacin del cdigo y pruebas del sistema; y despliegue: consiste en la entrega del producto al cliente para que lo evale y de su retroalimentacin. 1.4. DESARROLLO RPIDO El desarrollo rpido consiste en entrega rpida de software funcional. Con esta metodologa, el cliente debe ser parte del equipo de trabajo de desarrollo y tiene la ventaja de que puede aplicarse a cualquier proceso de software. Cada vez que se habla de desarrollo rpido o gil, implcitamente se piensa en costos. La

figura 1.15 muestra cmo este tipo de desarrollo baja drsticamente los costos.

Costo del cambio con el empleo de procesos convencionales de software

Costo del cambio con el uso de procesos giles Costo idealizado del cambio con el uso de un proceso gil

Avance de la programacin del desarrollo

Fuente: Pressman (2010, p. 57). Figura 1.15. Cambio de los costos como funcin del tiempo transcurrido en el desarrollo1.4.1 PROTOTIPOS

Las metodologas giles tienen sus races en los prototipos, por lo que se inicia con el detalle de ellos mismos. En la figura 6.1, pgina 156 del libro, podemos observar que existen cuatro

tipos de prototipos los cuales sirven para una situacin especfica. Son una alternativa para el Ciclo De Vida de Desarrollo de Sistemas (SDLC), ya que este presenta algunas quejas: el largo tiempo requerido para pasar por todo el proceso y el hecho de que los requerimientos de los usuarios cambian con el tiempo. Tambin, pueden ayudar a los analistas a recortar el tiempo que tardan en recolectar los requerimientos y en hacer entrega de un sistema funcional. Segn el libro, en caso de que se decida utilizar el desarrollo de prototipos se deben seguir los siguientes lineamientos: 1. 2. 3. 4. Trabajar en mdulos administrables. Crear el prototipo con rapidez. Modificar el prototipo. Hacer nfasis en la interfaz de usuario (Kendall y Kendall, 2011, p. 159).

Tabla 1.1. Ventajas y desventajas de los prototipos Ventajas Permite cambios durante las primeras etapas de desarrollo. Desventajas Puede ser bastante difcil administrar la creacin de un prototipo como un proyecto dentro del esfuerzo ms grande del sistema. Los usuarios y analistas del sistema pueden adoptar un prototipo como un sistema completo.

Oportunidad de detener un desarrollo en un sistema que no est funcionando. Oportunidad de desarrollar un sistema que cumpla mejor con las necesidades y expectativas de los usuarios.

La tabla 1.1 muestra ventajas y desventajas de los prototipos:

Fuente: Kendall y Kendall (2011).

1.4.2 DESARROLLO RPIDO DE APLICACIONES

Es importante conocer las caractersticas de la empresa para la cual se est trabajando y qu tipo de sistema se desarrollar porque esto permitir saber cul es la metodologa de desarrollo que se debe aplicar. El desarrollo rpido de aplicaciones (RAD) es muy acertado cuando la organizacin cambia peridicamente, porque permite al personal involucrado estar en una constante realimentacin de los cambios. El RAD se divide en tres fases. La primera corresponde a la planeacin de los requerimientos que es donde se identifican los objetivos y requerimientos. La segunda, corresponde al taller RAD donde se realiza un proceso cclico de dos actividades: trabajo con usuarios para disear el sistema y la construccin. La ltima es la de implementacin, donde se introduce el nuevo sistema. Respecto al SDLC, el RAD acorta el proceso de desarrollo con la idea de responder de manera ms pronta los requerimientos de los usuarios,

como se puede observar en la figura 6.5 en la pgina 165 del libro. Es importante estudiar en el libro de texto las condiciones necesarias para poder desarrollar un sistema bajo la metodologa RAD y las desventajas que esta tiene.1.4.3 MODELADO GIL

Las siguientes son las actividades bsicas del desarrollo gil: codificar, probar, escuchar, y disear.

Cada una de estas requiere de esfuerzo y recursos que ayuden a completar el proyecto. En la figura 6.7, en la pgina 172 del libro, se resume toda la informacin referente a las actividades, recursos, prcticas y valores del modelado gil.

1.4.4 SCRUM

Revisar el material de la pgina 166 a 174, donde se explica con mayor detalle toda la informacin referente al modelado gil.

Es una metodologa gil que se basa en el trabajo en grupo. Dicha metodologa requiere de un plan, el cual puede ser modificado conforme avanza el proyecto, El equipo de de sistemas trabaja dentro de un perido estricto de 30 das (Kendall y Kendall, 2010, p. 174).

Fuente: Pressman (2010). Figura 1.21. Flujo del proceso Scrum

1.5. LA INGENIERA DE SOFTWARE EN LA PRCTICA La esencia de la prctica de la ingeniera de software se puede describir en cuatro pasos: Entender el problema: esta tarea es clave para el desarrollo de software que verdaderamente represente un valor agregado para el usuario, ya que es la base del desarrollo de todo el sistema. En esta etapa prctica de la ingeniera es relevante la comunicacin entre todos los participantes del equipo de trabajo (desarrolladores, analistas, arquitectos software, administradores proyectos, usuarios). Planear la solucin: una vez que se ha entendido el problema, el siguiente paso es planear detenidamente cmo se va a solucionar, o sea, cmo se van a realizar las tareas, cmo se van a integrar las partes del sistema y, tambin, verificar si

se puede reutilizar algn material, patrn de diseo o cdigo que permita agilizar el proceso de construccin. Ejecutar el plan: cuando se ha planeado como llevar a cabo todas las tareas, se procede con la ejecucin de las mismas. En algunas ocasiones, se tendr que modificar el plan inicial, porque es muy probable que, conforme se avance, se presenten cambios, ya sea porque son propuestos por el usuario o porque el proyecto lo requiera. Examinar la exactitud del resultado: una vez que el desarrollo est listo se procede a realizar la comprobacin de los requerimientos del sistema por medio de pruebas de parte de los desarrolladores y de los usuarios, para estar seguros de que el sistema realiza las tareas requeridas de manera correcta.

E JERCICIOS DE AUTOEVALUACIN Captulo1 2. Enliste las diferencias entre OAS y KWS. 4. Cul es la diferencia entre MIS y DSS? 6. Enliste los problemas de interaccin grupal para los cuales se disean los sistemas de soporte de decisiones en grupo (GDSS) y los sistemas de trabajo colaborativo asistido por computadora (CSCWS). 9. Cite las ventajas de montar aplicaciones a la web. 12. Mencione las ventajas de utilizar las tcnicas de anlisis y diseo de sistemas para trabajar con los sistemas de informacin computarizados para empresas. Captulo 4 1. Qu informacin hay que buscar en las entrevistas? 4. Cundo es apropiado usar preguntas abiertas en las entrevistas? 6. Cundo es apropiado usar preguntas cerradas en las entrevistas? 12. Haga una lista de las situaciones que garantizan el uso de JAD en vez de las entrevistas personales en la organizacin. 15. Cules tipos de informacin busca el analista de sistemas mediante el uso de cuestionarios o encuestas?

25. Cundo debe el analista usar escalas de intervalo? 34. Cules consideraciones son necesarias cuando los cuestionarios estn basados en la web? Captulo 6 1. Qu significa el trmino prototipo deparches? 6. Haga una lista de las ventajas y desventajas de usar prototipos para sustituir el SDLC tradicional.

R ESPUESTA A LOS EJERCICIOS DE AUTOEVALUACIN Captulo 1 2. Las diferencias entre AOS y KWS son: AOS: brindan apoyo a las personas que trabajan con datos no para crear conocimiento, sino para analizar la informacin y transformar los datos o manipularlos de cierta forma antes de compartirlos o diseminarlos de manera formal a travs de la organizacin y, algunas veces, ms all. Ejemplo: Procesadores de palabras, hojas de Excel. KWS: brindan apoyo a profesionales como ingenieros y cientficos al ayudarlos a crear conocimiento y a integrarlo a su organizacin. 4. Las diferencias entre MIS y DSS: Ambos producen informacin que se utiliza para toma de decisiones, pero los DSS estn ms enfocados a brindar respaldo en todas las fases del sistema. 6. Los problemas de interaccin grupal son: escasez de participacin por temor a los represalias por expresar un punto de vista impopular o polmico, y la dominacin por parte de miembros del grupo con facilidad de palabra y la toma de decisiones mediante el pensamiento grupal. 9. Las ventajas de montar aplicaciones en la web son: aumenta el nmero de usuarios que se enteran de la disponibilidad de un servicio, producto, industria, persona, grupo, los usuarios tienen la posibilidad de acceder las 24 horas del da,

se puede mejorar la utilidad y capacidad de uso del diseo de la interfaz, y se puede expandir un sistema globalmente en vez de permanecer en el entorno local, con lo cual se puede establecer contacto con personas en ubicaciones remotas sin preocuparse por la zona horaria en la que se encuentren. 12. Las ventajas de utilizar las tcnicas de anlisis y diseo de sistemas para trabajar con los sistemas de informacin computarizados para empresas son que utiliza los lenguajes existentes para hacer que las pginas web funcionen en forma ms parecida a un programa de aplicacin de escritorio. Un ejemplo de una tcnica de anlisis y diseo de sistemas para trabajar con sistemas de informacin es Ajax. Captulo 4 1. La informacin que hay que buscar en las entrevistas es: opiniones del entrevistado, lo que siente sobre el estado actual del sistema, los objetivos de la organizacin y los personales, y los procedimientos informales para interactuar con las tecnologas de la informacin. 5. Es apropiado usar preguntas abiertas en las entrevistas cuando es necesario conocer los detalles, romper el hielo con el entrevistado, se est relacionado sentimentalmente con el tema y necesita expresar sus sentimientos, y se debe obtener realimentacin del entrevistado. 6. Es apropiado usar preguntas cerradas en las entrevistas cuando se necesita obtener datos precisos, comparar las entrevistas, ahorrar tiempo y limitarle la respuesta al entrevistador. 12. Las situaciones que garantizan el uso de JAD en vez de las entrevistas personales en la organizacin son:

los grupos de usuarios estn inquietos y desean algo nuevo; la cultura de la organizacin apoya los comportamientos de solucin de problemas conjuntos entre varios niveles de empleados; los analistas pronostican que la cantidad de ideas generadas mediante las entrevistas cara a cara no ser tan abundante como el nmero de ideas posibles mediante un ejercicio de grupo extendido; Y el flujo de trabajo permite la ausencia de personal clave durante un periodo de dos a cuatro das. 15. Los tipos de informacin busca el analista de sistemas mediante el uso de cuestionarios o encuestas son: cuantificar lo que encontr en las entrevistas; determinar qu tan difundido o limitado est realmente un sentimiento expresado en una de las entrevistas; y detectar problemas y llevar a la mesa de discusin cuestiones importantes antes de programar las entrevistas. 25. El analista usa escalas de intervalo cuando es necesario realizar operaciones matemticas para obtener un anlisis ms completo. 34. Las consideraciones necesarias cuando los cuestionarios estn basados en la web son: las tasas de respuesta van a ser un poco ms bajas, ya que se olvidan, las pierden, etc.; en cuanto al diseo, debe ser igual que las que se realizan en papel; y utilizar formato de entrada de datos, esto porque existen distintas maneras de capturar las respuestas.

Captulo 6 1. El trmino prototipo deparches es un sistema funcional construido por parches, no es eficiente y sirve solo para que el usuario se d una idea que como ser cuando funcione adecuadamente. 6. Ventajas y desventajas de usar prototipos para sustituir el SDLC tradicional. Ventajas: Recorta efectivamente el tiempo entre el proceso de averiguar los requerimientos humanos de informacin y la entrega de un sistema funcional. Se podran solucionar algunos de los problemas implicados con la identificacin precisa de los requerimientos de informacin de los usuarios. Sirven como mtodo adicional especializado para averiguar los requerimientos de informacin de los usuarios a medida que interactan con los prototipos y proveen retroalimentacin para el analista. Desventajas: Dar forma al sistema al sistema antes de comprender perfectamente el problema o la oportunidad pertinente. Al usar prototipos como alternativa, se podra producir un sistema que sea aceptado por ciertos grupos especficos de usuarios, pero que sea inadecuado para la necesidad del sistema en general.

TEMA 2 LA INGENIERADE SOFTWARE

S UMARIO Captulo 7: Uso de diagramas de flujo de datos. Captulo 8: Anlisis de sistemas mediante el uso de diccionarios de datos. S NTESIS En la prctica de la ingeniera de sistemas existen una serie de principios, conceptos, metodologas y herramientas que nos ayudan a planear y desarrollar software de calidad. Adems de los principios fundamentales, existen otros generales y actividades que apoyan el proceso de anlisis y desarrollo de programas. En este tema, referente a la ingeniera de software, estudiaremos con mayor detalle el uso de diagramas de flujo de datos y el anlisis de sistemas mediante el uso de estos. O BJETIVOS Al finalizar el estudio de este captulo, entre otras habilidades, usted ser capaz de 1. Aplicar los conceptos, mtodos y tcnicas para el desarrollo de software.

2. LA INGENIERA DE SOFTWARE2.1. CONCEPTOSSOFTWARE Y PRINCIPIOS PARA LA INGENIERA DEL

CONCEPTOS DE LA INGENIERA DE SOFTWARE

Como estudiamos en el tema 1, en el proceso del software hay diferentes tipos de sistemas, los cuales tienen un ciclo de vida y se desarrollan bajo la metodologa ms apropiada para el sistema en cuestin. Todo este proceso es propio de lo que llamamos ingeniera del software. Pero antes, es necesario conocer algunos trminos que nos ayudarn a tener una idea ms completa acerca del anlisis de sistemas. Software: es un conjunto de instrucciones (programas de cmputo) que cuando se ejecutan proporcionan las caractersticas, funcin y desempeo buscados. Son estructuras de datos que permiten que los programas manipulen de forma adecuada la informacin (Pressman, 2010, p. 3).

Ingeniera de software: La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software; es decir, la aplicacin de la ingeniera de software (Pressman, 2010, p. 11). Proceso de desarrollo de software: Es un enfoque adaptable que permite que las personas que hacen el trabajo (el equipo de software) busquen y elijan el conjunto apropiado de acciones y tareas para el trabajo (Pressman, 2010, p. 12). Diagramas de flujos de datos: Es una tcnica del anlisis estructurado que le permite al analista de sistemas ensamblar una representacin grfica de los procesos de datos a travs de la organizacin (Kendall y Kendall, 2011, p. 193).

Diccionarios de datos: El diccionario de datos es una obra de consulta de informacin sobre los datos (es decir, metadatos) (Kendall y Kendall, 2011, p. 228).PRINCIPIOS DE LA INGENIERA Y SOFTWARE

En la ingeniera de software, adems de los conceptos anteriores, existe una serie de principios que ayudan en la aplicacin del proceso de software y, que a su vez, asegura, por medio de mtodos y herramientas eficaces de ingeniera, la elaboracin de sistemas de calidad. De acuerdo con la figura 2.1, existen dos tipos fundamentales de principios: los que guan el proceso y los que guan la prctica. Ambos son importantes indistintamente de los mtodos de anlisis, diseo, construccin y validacin y verificacin que se utilicen.

En el caso de los principios fundamentales, estos pueden ser utilizados con cualquier modelo de software prescriptivo que se utilice: lineal o iterativo, prescriptivo o gil. Los principios que guan la prctica nos ayuda a cumplir con el objetivo general de la ingeniera de software: Entregar a tiempo el software operativo de alta calidad que contenga funciones y caractersticas que satisfagan las necesidades de todos los participantes (Kendall y Kendall, 2011, p. 85).

Cada uno de los principios anteriores se puede estudiar con ms detalle en el captulo 4 del libro Ingeniera de software, Un enfoque prctico. 7a. edicin, de Roger S. Pressman.

Principios que guan el procesoSer gil En cada etapa, centrase en la calidad Estar listo para adaptar Formar un equipo eficaz Establecer mecanismos para la comunicacin y coordinacin Administrar el cambio Evaluar el riesgo Crear productos de trabajo que agreguen valor para otros

Principios que guan la prcticaDivide y vencers Entender el uso de la abstraccin Buscar la coherencia Centrarse en la transferencia de informacin Construir software que tenga modularidad eficaz Buscar y utilizar patrones Cuando sea posible , representar el problema y su solucin desde varias perspectivas diferentes Tener en mente que alguien dar mantenimiento

Fuente: Pressman (2010). Figura 2.1. Principios fundamentales de la Ingeniera de software

2.2. ASPECTOSINGENIERA

DE LA INGENIERA DE SISTEMAS QUE ESPECFICAMENTE AL REA DEHerramientas Mtodos Proceso Compromiso con la calidad

CORRESPONDEN

La figura 2.2 muestra la ingeniera de software como una tecnologa con varias capas, donde el compromiso con la calidad es la base de esta. Para lograr la excelencia del producto que desarrollamos, podemos apoyarnos en la administracin de la calidad total, Six Sigma y otras filosofas de calidad que sern abarcadas ms adelante en este material. La capa de proceso es el fundamento de la ingeniera, ya que define la estructura a seguir. Segn Pressman (2010) el proceso forma la base para el control de la administracin de proyectos de software, establece el contexto en el que se aplican los mtodos tcnicos, se generan productos de trabajo (modelos, documentos, datos, reportes, formatos, etc.), se establecen puntos de referencia, se asegura la calidad y se administra el cambio de manera apropiada (p. 12).

Fuente: Pressman (2010), p. 12. Figura 2.2. Capas de la ingeniera de software La capa de mtodos se refiere al conjunto de las siguientes tareas: 1. 2. 3. 4. 5. comunicacin, anlisis de requerimientos, modelacin del diseo, construccin del sistema, pruebas y apoyo.

La capa de herramientas se refiere, precisamente, a las automatizadas y semiautomatizadas que apoyan el proceso y los mtodos.

Adems de los principios fundamentales vistos antes, existen otros que son los que guan toda actividad estructural de las propias del proceso de software, como la comunicacin, la planeacin, la construccin, el modelado, y el despliegue. Las actividades anteriores se realizan de forma iterativa, ya sea para desarrollar un sistema complejo o sencillo. Adicional a las actividades estructurales de la ingeniera de software, existen otras que la apoyan tales como seguimiento y control del proyecto de software, administracin del riesgo, aseguramiento de la calidad del riesgo, revisiones tcnicas, medicin, administracin de la configuracin del software, administracin de la reutilizacin, preparacin y produccin.

2.3. MODELO DE ANLISIS Y LOS ELEMENTOS NECESARIOSPARA SOPORTARLO

La figura 2.3 muestra los elementos necesarios para soportar el modelo de anlisis.Modelos basados en el escenario por ejemplo, cosas de uso historias de usuario Modelos de clase por ejemplo, diagramas de clase diagramas de colaboracin

Requerimientos del software

Modelos de comportamiento por ejemplo, diagramas de estado diagramas de secuencia

Modelos de flujo por ejemplo, DFD modelo de datos

Fuente: Pressman (2010, p. 131). Figura 2.3. Elementos que soportan el modelo de anlisis

Los Diagramas de Flujo de Datos (DFD), son herramientas del anlisis y diseo de sistemas que permiten al analista tener una visin completa de los procesos de una empresa y como se relacionan nos dan las siguientes ventajas: 1. No hay que comprometerse demasiado pronto con la implementacin tcnica del sistema. 2. Permite comprender con ms detalle la capacidad de interrelacin de los sistemas y subsistemas. 3. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de DFD. 4. Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos necesarios (Kendall y Kendall, 2011). Existen cuatro smbolos bsicos que se utilizan para graficar el movimiento de los datos en los DFD. La figura 2.4 muestra cada uno de los smbolos y su significado.

Smbolo

Significado

Ejemplo

Entidad

Estudiante

Flujo de datos

Informacin nuevo estudiante

Proceso

2.1 Crear registro de estudiante

Almacn de datos

D 3

Archivo maestro de estudiantes

Fuente: Kendall y Kendall (2011, p. 194). Figura 2.4. Los cuatro elementos bsicos que se utilizarn en los diagramas de flujo de datos, sus significados y ejemplos.

Para desarrollar los diagramas de flujos de datos es necesario seguir las reglas bsicas que estn descritas en el libro (en la pgina 195). En la figura 2.5 se presentas los diferentes diagramas que forman un DFD.

Cuando se generan DFD es muy comn cometer errores, porque a veces se pueden dar situaciones como las siguientes: el usuario no tiene muy claro el proceso, o hay problemas de comunicacin entre el usuario y el analista.

DFDDiagrama de Contexto: nivel ms alto de un DFD, contiene solo un proceso que es el que representa el sistema Diagrama 0 (procesos padre): es la expansin del diagrama de contexto, puede incluir hasta 9 procesos Diagramas Hijos: el diagrama 0 puede expandirse para crear un diagrama hijo ms detallado.

Dado lo anterior, es mejor, una vez que se ha desarrollado un diagrama, revisar la lista de comprobacin de errores para verificar que entendimos perfectamente el proceso. Revise el libro desde la pgina 198 a la 200. Recordemos, que cuanto ms pronto corrijamos los errores del diseo, ms barato ser el desarrollo de un sistema en tiempo y dinero. Los DFD se clasifican en lgicos y fsicos. El analista obtiene una serie de ventajas durante el proceso de anlisis con la creacin de estos diagramas, una de estas es que est demostrado que los sistemas a los que se les desarrollan DFD lgicos son ms estables.

Fuente: Kendall y Kendall (2011) Figura 2.5. Diagramas que forman un diagrama de flujo de datos

Cuando se realiza la particin de un DFD hay que analizar cada proceso para determinar si debe ser manual o automatizado, y agrupar los procedimientos automatizados en una serie de programas de computadora (Kendall y Kendall, 2011, p. 206).

En el texto, los autores dicen que hay seis motivos para particionar los DFD. La figura 2.6 muestra cada uno de esos motivos.

Distintos grupos de usuarios

Seguridad

Sincronizacin

Motivos Particionar DFDConsistencia de los datos Tareas similares

Eficiencia

Fuente: Kendall y Kendall (2011). Figura 2.6. Motivos de particionamiento de un DFD

Revise el ejemplo de las pginas 207 a la 213 del libro, donde se crea un DFD de un sistema con mucho detalle.

En este momento se le da mucha importancia al conocimiento de estructura y utilizacin de archivos en formato XML, por lo que se recomienda, al final de este tema, revisar el libro.

Una vez que el analista tiene listos los diagramas de flujo de datos, puede empezar a construir el diccionario de datos que es utilizado por los analistas de sistemas para guiarse a travs del anlisis y diseo (Kendall y Kendall, 2011, p. 228). Los diccionarios de datos ayudan a mantener limpios y consistentes los datos. Adems de las razones anteriores ayudan a proveer documentacin, eliminan la redundancia, validan la integridad y precisin del DFD. Son un punto de partida para el desarrollo de pantallas e informes y sirven para crear archivos XML (lenguaje de marcado extensible, del ingls eXtensible Markup Language).

Se recomienda estudiar la figura 8.1 en la pgina 229 del libro, donde se muestra cmo se relacionan los diccionarios de datos con los diagramas de datos.

El diccionario de datos est compuesto por cuatro categoras (Kendall y Kendall, 2011): 1. Los flujos de datos: entradas y salidas del sistema.

2. Las estructuras de datos lgicas y fsicas: producen una vista de los elementos que forman la estructura de datos. 3. Los elementos de datos: se definen una nica vez de acuerdo con una serie de caractersticas. 4. Almacenes de datos: almacena cada registro estructural nico.

2.4. INGENIERAREALIZACIN.

DE DISEO Y LOS CONCEPTOS QUE

PERMITEN DARLE UN AMBIENTE ROBUSTO EN SU

El diseo de software es una de las fases ms importantes de la ingeniera de software ya que a travs de este proceso se evala su calidad. Segn Pressman, el diseo de software se ubica en el rea tcnica de la ingeniera de software y se aplica sin importar el modelo del proceso que se utilice. El diseo de software comienza una vez que se han analizado y modelado los requerimientos, es la ltima accin de la ingeniera de software dentro de la actividad de modelado y prepara la etapa de construccin (generacin y prueba del cdigo) (2010, p. 184). Y agrega que Hay tres caractersticas que sirven como gua para evaluar un buen diseo: Verificar que se implementan todos los requerimientos del modelo de requerimientos.

En las pginas 238 a la 241 se explica detalladamente cmo crear un diccionario de datos.

El diccionario de datos se usa para crear pantallas, informes o formularios, pero para que este se pueda aprovechar al mximo, lo mejor es que sea automatizado, interactivo, en lnea, evolutivo y, adems, debe estar enlazado a varios programas de sistemas para que se est actualizando continuamente.

El diseo debe ser gua fcil de interpretar para los que generan cdigo, para los que lo prueban y para los que posteriormente darn el mantenimiento. El diseo proporciona un panorama completo del software (Pressman, 2010, p. 186).

abstraccin de datos para un objeto llamado puerta sera procedimiento abrir, el cual agrupa un conjunto de atributos que describen la puesta, como lo son: tipo, direccin del abatimiento, mecanismo de apertura, peso, dimensiones, entre otros (p. 189). Arquitectura: Es la estructura de la organizacin de los componentes de un programa (mdulos), la forma en que estos interactan y la estructura de los datos que utilizan. Una meta del diseo de software es obtener una aproximacin arquitectnica de un sistema (p.190). Patrones: Un patrn de diseo describe una estructura de diseo que resuelve un problema en particular del diseo dentro de un contexto especfico y entre fuerzas que afectan la manera en que se aplica y en la que se utiliza dicho patrn. El objetivo de los patrones de diseo es proporcionar una descripcin que permita a un diseador

Existen algunos conceptos de diseo de software que permiten dar un ambiente robusto, ya sea para realizar un desarrollo tradicional o uno orientado a objetos. A continuacin, se detallan los conceptos ms importantes del diseo de software. Estas definiciones fueron tomadas del libro Pressman, R. S. (2010), Ingeniera de Software, pero es bueno revisar otros materiales referentes al anlisis de sistemas para tener una idea ms amplia de estos contenidos. Abstraccin: Una abstraccin de datos es un conjunto de stos con nombre que describe a un objeto de datos Un ejemplo de un nombre procedimiento de una

determinar 1) si el patrn es aplicable al trabajo en cuestin, 2) si puede volverse a usar(con lo que se ahorra tiempo de diseo) y 3)sirve como gua para desarrollar un patrn distinto en funciones o estructura (p. 191). Divisin de problemas: Es un concepto de diseo que sugiere que cualquier problema complejo puede mantenerse con ms facilidad si se divide en elementos susceptibles de resolverse u optimizarse de manera independiente (p. 191). Modularidad: Es la manifestacin ms comn de la divisin de problemas. El software se divide en componentes con nombres distintos y abordables por separado, en ocasiones llamados mdulos, que se integran para satisfacer los requerimientos del problema (p. 191)

Ocultamiento de informacin: El principio de ocultamiento de informacin sugiere que los mdulos se caractericen por decisiones de diseo que se oculten (cada una) de las dems. En otras palabras, deben especificarse y disearse mdulos, de forma que la informacin (algoritmos y datos) contenida en un mdulo sea inaccesible para los que no necesiten de ella (p. 192). Independencia funcional: El concepto de independencia funcional es el resultado directo de la separacin de problemas y de los conceptos de abstraccin y ocultamiento. La independencia funcional se logra desarrollando mdulos con funciones miopes que tengan aversin a la interaccin excesiva con otros mdulos. Dicho de otro modo, debe disearse software de modo que cada mdulo resuelva un subconjunto especfico de requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del programa. La independencia funcional es una clave para el

buen diseo y ste es la clave de la calidad del software (p. 193). De este concepto de independencia funcional se desprenden otros dos conceptos que son importantes: La cohesin: Es un indicador de la fortaleza relativa funcional de un mdulo. El acoplamiento: Es el indicador de la independencia relativa entre mdulos (p. 193).

En el diseo de software se busca que los sistemas tengan mdulos cohesivos y que exista el mnimo acoplamiento posible.

Refinamiento: Un programa se elabora por medio del refinamiento sucesivo de los detalles del procedimiento. Se desarroll una jerarqua con la descomposicin de un enunciado macroscpico de la funcin (abstraccin del procedimiento) en forma escalonada hasta llegar a los comandos de lenguaje de programacin. La abstraccin y el refinamiento son conceptos complementarios. La primera permite especificar internamente el procedimiento y los datos, pero elimina la necesidad de que los extraos conozcan los detalles de bajo nivel. El refinamiento ayuda a revelar estos detalles a medida que avanza el diseo. Ambos conceptos permiten crear un modelo completo del diseo conforme ste evoluciona (p. 194). Aspectos: es una representacin de una preocupacin de interferencia. En un contexto ideal, un aspecto se implementa como mdulo (componente) separado y no como fragmentos de software dispersos o

regados en muchos componentes. Para lograr esto, la arquitectura del diseo debe apoyar un mecanismo para definir un aspecto: un mdulo que permita implementar la preocupacin en todas aquellas con las que interfiera (p.194). Rediseo: Es una tcnica de organizacin que simplifica el diseo (o cdigo) de un componente sin cambiar su funcin o comportamiento, pero que s mejora su estructura interna (p.195). Conceptos de diseo orientado a objetos: El paradigma orientado a objetos se utiliza en la ingeniera de software moderna y algunos de los conceptos que estn familiarizados con ste son: clases y objetos, herencia, mensajes y poliformismo, entre otros (p.195).

Estos conceptos son vistos con mayor detalle en los cursos introductorios de programacin. En caso de que todava no haya tenido la oportunidad de estudiar estos temas a fondo, se le recomienda buscar informacin acerca de ellos para tener una idea ms completa de lo que significan y su funcin.

E JERCICIOS DE AUTOEVALUACIN Captulo 7 2. Cules son las cuatro ventajas de usar una metodologa de flujo de datos en vez de las explicaciones narrativas del movimiento de datos? 4. Qu es un diagrama de flujo de datos a nivel de contexto? Comprelo con un DFD de nivel 0. 9. Cul es la diferencia entre los diagramas de flujo de datos fsico y lgico? 11. Mencione cinco caractersticas que se incluyen en un diagrama de flujo de datos fsico y que no se encuentran en un diagrama de flujo de datos lgico. 14. Mencione las principales secciones de un caso de uso. 16. Qu es el particionamiento y cmo se utiliza?

Captulo 8 1. Defina diccionario de datos y metadatos. 3. Qu informacin est contenida en el repositorio de datos? 4. Qu es un registro estructural? 6. Cules son las diferencias bsicas entre las entradas en el diccionario de datos preparadas para los almacenes de datos, la estructura de datos y los elementos de datos? 8. Cul es la diferencia entre estructuras de datos lgicas y fsicas? 9. Describa la diferencia entre elementos base y derivados 10. Cmo se relacionan las entradas en el diccionario de datos con los niveles en un conjunto de diagramas de flujo de datos? 13. Cules son los principales beneficios de usar un diccionario de datos?

R ESPUESTA A LOS EJERCICIOS DE AUTOEVALUACIN Captulo 7 2. Las cuatro ventajas de usar los DFD son: a. No hay que comprometerse demasiado pronto con la implementacin tcnica del sistema. b. b. Permite comprender con ms detalle la capacidad de interrelacin de los sistemas y subsistemas. c. c. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de diagramas de flujo de datos. d. d. Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos necesarios. 4. Un diagrama de flujo de datos a nivel de contexto es el diagrama ms general de un sistema, que incluye las entradas bsicas, el sistema general y las salidas. El diagrama de contexto es el nivel ms alto en un DFD y contiene solo un proceso, el cual representa todo el sistema. El diagrama no contiene almacenes de datos y es bastante simple de crear. Los diagramas de nivel 0 es una expansin del diagrama de contexto. Estos diagramas incluyen los principales almacenes de datos del sistema y todas las entidades externas. 9. Las diferencias entre los diagramas de flujo lgicos y los fsicos son las siguientes: el diagrama de flujo lgico se enfoca en la empresa y cmo opera. No se preocupa por la forma en que se construye el software. Describe los eventos de la empresa que se llevarn a cabo, adems de los datos requeridos y producidos por cada evento, mientras el diagrama de flujo fsico muestra

cmo se implementar el sistema incluyendo hardware, software los archivos y las personas involucradas en el sistema. 11. Cinco caractersticas que se incluyen en un diagrama de flujo de datos fsico y que no se encuentran en un diagrama de flujo de datos lgico son las siguientes: a. b. c. d. contienen procesos manuales, contienen procesos de agregar, eliminar, modificar y actualizar registros, contiene procesos para introducir y verificar datos, contienen procesos de validacin para asegurar que se introduzcan los datos con precisin, y e. se utilizan los nombres de archivos reales para guardar datos. 14. Las principales secciones de un caso de uso son las siguientes: la actividad y su desencadenador, su entrada y su salida. 16. El particionamiento es el proceso de examinar un diagrama de flujo de datos y se utiliza para determinar cmo se debe dividir el DFD en colecciones de procedimientos manuales y colecciones de programas de computadora.

Captulo 8 1. Un diccionario de datos corresponde a una obra de consulta de informacin sobre los datos (es decir, metadatos); se compila por los analistas de sistemas para guiarse a travs del anlisis y diseo. Como documento, el diccionario de datos recopila y coordina trminos de datos especficos, adems de confirmar lo que significa cada trmino para distintas personas en la organizacin. 3. La informacin que est contenida en el repositorio de datos es la siguiente: Informacin sobre los datos que mantiene el sistema, incluyendo flujos de datos, almacenes de datos, estructuras de registros, elementos, entidades y mensajes. Lgica de procedimiento y casos de uso. Diseo de pantallas e informes. Relaciones de datos como la forma en que una estructura de datos est vinculada con otra. Requerimientos del proyecto y entregables finales del sistema. Informacin administrativas del proyecto, como calendarios de entrega, logros, cuestiones que hay que resolver y usuarios del proyecto.

4. Un registro estructural es un registro que se definen una nica vez pero que pueden ser utilizados en varios sistemas. Ejemplos: ciudad, direccin, nombre. 6. Las diferencias bsicas entre las entradas en el diccionario de datos preparadas para los almacenes de datos, las estructuras de datos y los elementos de datos son las siguientes: Almacenes de datos: se crean almacenes de datos para cada entidad de datos distinta que se piense guardar. Es decir, cuando se agrupan los elementos base del flujo de datos para

formar un registro estructural, se crea un almacn de datos para cada registro estructural nico. Todos los elementos base deben estar guardados en el sistema y si es posible tambin se guardan los elementos derivados. Estructuras de datos: Cuando se definen las estructuras de datos por primera vez, se incluyen solo los elementos de datos que el usuario puede ver, por ejemplo: nombre, direccin, telfono, entre otros. Elementos de datos: Cada elemento de datos se debe definir una vez en el diccionario de datos y tambin se puede introducir previamente en el formulario de descripcin de un elemento.

8. La diferencia entre estructuras de datos lgicas y las fsicas es la siguiente: el diseo lgico refleja con precisin el modelo mental de la forma en que el usuario ve el sistema y son una base para disear las estructuras fsicas. Las estructuras fsicas contienen todos los elementos adicionales necesarios para implementar el sistema. 9. La diferencia entre elementos base y derivados es la siguiente: un elemento base es el que se teclea al sistema en un principio (ejemplos: nombre de un cliente, direccin, ciudad.). Los elementos derivados se crean a travs de los procesos como resultado de un clculo o una serie de instrucciones de toma de decisiones (ejemplo: el sueldo lquido). 10. Cmo se relacionan las entradas en el diccionario de datos con los niveles en un conjunto de diagramas de flujo de datos? Las entradas en el diccionario de datos se relacionan con los niveles en un conjunto de diagramas de flujo de datos de la siguiente forma: el analista puede crear un flujo de datos Diagrama 0 despus de las primeras entrevistas y, al mismo tiempo, crear las entradas preliminares en el diccionario de datos. Por lo general, estas entradas consisten en los

nombres de los flujos de datos que se encuentran en el diagrama de flujo de datos y sus correspondientes estructuras de datos. 13. Los principales beneficios de usar un diccionario de datos son los siguientes: nos puede ahorra muchas horas, ya que esta fuente de consulta permite a los analistas guiarse a travs del anlisis y diseo. Adems, son valiosos por su capacidad de realizar referencias cruzadas con los elementos de datos para permitir los cambios necesarios de en todos los programas que compartan un elemento comn. Esta es la nica fuente comn en la organizacin para responder preguntas y resolver disputas sobre cualquier aspecto de la definicin de los datos. Un diccionario actualizado puede constituir un excelente marco de referencia para los esfuerzos de mantenimiento en sistemas con los que no estemos familiarizados. Los diccionarios de datos automatizados pueden servir como referencias tanto para las persona como para los programas.

TEMA 3 DISEO DELSOFTWARE ORIENTADO A LA INFORMACIN

S UMARIO Captulo 9: Especificaciones de los procesos y decisiones estructuradas Captulo 14: Interaccin humano-computadora S NTESIS En este tema, dedicado al diseo del software orientado a la informacin, vamos a estudiar conceptos que acompaan el modelado de diseo arquitectnico y por qu este es necesario. Hablaremos acerca de tcnicas de toma de decisiones y como estas apoyan la elaboracin del diseo arquitectnico. Adems, revisaremos qu es un componente, su proceso, diseo, y el diseo de interfaces de usuario. O BJETIVOS Al finalizar el estudio de este captulo, entre otras habilidades, usted ser capaz de 1. Disear el software orientado a la informacin para satisfacer los requerimientos definidos por el cliente.

3. DISEO DEL SOFTWARE ORIENTADOA LA INFORMACIN3.1. CONCEPTOSDISEO QUE ACOMPAAN EL MODELADO DE

interacta el software y la naturaleza de esa interaccin. Esto se logra a partir del modelado de requerimientos y de toda la informacin recogida durante ese proceso.

En el tema anterior asimilamos los diferentes conceptos del proceso de diseo de software, pero, adems de estos, existen otros elementos que tienen que ver propiamente con el modelado del diseo: despliegue, diseo arquitectnico, de la interfaz y el nivel de componentes. 3.2. NECESIDAD DE UN DISEO ARQUITECTNICO El diseo arquitectnico de un sistema es uno de los temas dominantes en la ingeniera de software y en este apartado vamos a estudiar el porqu. Como ya se ha mencionado, en la etapa de diseo la meta es obtener una aproximacin arquitectnica del sistema. Para lograrlo, es necesario que al iniciar el diseo arquitectnico se definan las entradas externas con las que

El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e iteraciones (Pressman, 2010, p. 217). Las siguientes propiedades deben especificarse como parte del diseo de la arquitectura: Propiedades estructurales: Este aspecto de la representacin del diseo arquitectnico define los componentes de un sistema (mdulos, objetos, filtros, etc.) y la manera en que estn agrupados e interactan unos con otros. Por ejemplo, los objetos se agrupan para que encapsulen tanto datos como el procedimiento que los

manipula e interacten invocando mtodos (Pressman, 2010, p. 190). Propiedades extrafuncionales: La descripcin del diseo arquitectnico debe abordar la forma en que la arquitectura del diseo satisface los requerimientos de desempeo, capacidad, confiabilidad, seguridad, y adaptabilidad, as como otras caractersticas del sistema (Pressman, 2010, p. 190). Familias de sistemas relacionados: El diseo arquitectnico debe basarse en patrones repetibles que es comn encontrar en el diseo de familias de sistema similares. En esencia, el diseo debe tener la capacidad de reutilizar bloques de construccin arquitectnica (Pressman, 2010, p. 190).

continuacin, en la figura 3.1, hasta lograr una estructura arquitectnica del software completa.

Representacin del sistema en contexto

Descripcin de las instancias del sistema

Definicin de arquetipos

Refinamiento de la arquitectura hacia los componentes

Fuente: Pressman (2010). Figura 3.1. Proceso de diseo arquitectnico de un sistema.

Adems de las especificaciones de las propiedades anteriores, se realiza, durante la etapa de diseo arquitectnico del sistema y de manera iterativa, el proceso que se presenta a

Segn Pressman (2010), el diseo arquitectnico y la arquitectura de software consisten en miles de decisiones, tanto grandes como pequeas. Algunas de estas se toman en una etapa temprana del diseo y tienen un efecto profundo en todas las dems acciones. Otras, se dejan para ms adelante, con lo que se eliminan las restricciones prematuras que llevaran a una mala implementacin del estilo arquitectnico.ESPECIFICACIONES DE PROCESOS

Las especificaciones de proceso cumplen con un formato establecido y vinculan a un proceso con su respectivo diagrama de flujo y con el diccionario de datos, lo que permite al programador o a los analistas hacer una regresin del sistema ya construido a los requerimientos que lo iniciaron (Kendall y Kendall, 2011).

Las especificaciones de procesos y decisiones estructuradas apoyan el diseo arquitectnico, ya que explican la lgica de la toma de decisiones y las frmulas que transformarn la entrada del proceso en su salida. De acuerdo con Kendall y Kendall (2011), las especificaciones de procesos tienen tres objetivos: reducir la ambigedad del proceso, obtener una descripcin precisa de lo que se va a lograr, y validar el sistema de diseo.

Hay tres tcnicas de decisin estructuradas: espaol estructurado, tablas de decisin y rboles de decisin. Revisar figura 9.1, pgina 261, del libro.

ESPAOL ESTRUCTURADO

Esta tcnica se utiliza cuando las decisiones que se deben toman no son muy complejas y cuando el proceso involucra frmulas o iteraciones. La tcnica de espaol estructurado tiene una serie de convenciones IF-THEN-ELSE.

TABLAS DE DECISIN

RBOLES DE DECISIN

Son una herramienta del proceso de anlisis. Ayudan a expresar un problema o situacin sin ambigedad, ya que presenta para todas las posibles situaciones que se pueden presentar todas las acciones que pueden ser tomadas para llevarlas a cabo. Ejemplos de situaciones donde son tiles: mantenimientos de listas (de clientes, proveedores, inventarios), compra de materiales, entre otros.

Cuando se presentan procesos donde las decisiones son muy complejas es mejor utilizar un rbol de decisiones Los rboles de decisiones son tiles cuando es imprescindible mantener una cadena de decisiones en una secuencia especfica. El rbol del analista no contiene probabilidades y resultados. En el anlisis de sistemas, los rboles se utilizan principalmente para identificar y organizar las condiciones y acciones en un proceso de decisin completamente estructurado (Kendal y Kendall, 2011, p. 271).

La figura 9.7, en la pgina 267 del libro, muestra el formato estndar utilizado para representar una tabla de decisin.

Revise el ejemplo que da el libro en la pgina 269 y 270, donde se aplica el mtodo esquemtico para desarrollar tablas de decisin.

Revise las condiciones para dibujar un rbol de decisin y, adems, las ventajas que este presenta sobre las tablas de decisiones en las pginas de la 272 a la 273.

3.3. CONCEPTO

DE

COMPONENTE

EN

EL

DISEO

3.4. DISEO A NIVEL DE COMPONENTES Existen, de acuerdo con Pressman (2010), algunos principios bsicos en este tipo de diseo de sistemas orientados a objetos: abierto-cerrado, sustitucin de liskov, inversin de la dependencia, segregacin de la interfaz, equivalencia de la liberacin de la reutilizacin, cierre comn, y reutilizacin comn. Los anteriores principios ayudan a crear diseos arquitectnicos ms fciles de cambiar con menos impacto.

ARQUITECTNICO

Un componente en el diseo arquitectnico es un bloque de construccin de software de cmputo (Pressman, 2010, p. 235).

Al referirse a componentes se est hablando de uno o varios mdulos que precisamente componen un sistema. La modularidad en los sistemas de cmputo es importante, ya que esta nos ayuda a crear software en paralelo; varios programadores se encargan cada uno de una seccin del si