Mara Andrea Mora Araya

Anlisis y Sistemas I
Cdigo 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 estudio

Tema 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 datos

Especificaciones de los procesos y decisiones estructuradas

228-248
259-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.

Sntesis
Tiene 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.

CONTENIDO
Presentacin .................................................................................................................................................3
Generalidades 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................................................................................................................. 16

Sumario ....................................................................................................................................................................................................... 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 ................................................................................................. 38
Ejercicios de autoevaluacin....................................................................................................................................................................... 39 Respuesta a los ejercicios de autoevaluacin ............................................................................................................................................. 41

Tema 2 La ingeniera de software .............................................................................................................. 45

Sumario ....................................................................................................................................................................................................... 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......................................................................................................................................................................... 55
Ejercicios de autoevaluacin....................................................................................................................................................................... 60 Respuesta a los ejercicios de autoevaluacin............................................................................................................................................. 62

Tema 3 Diseo del software orientado a la informacin ...................................................................... 67

Sumario ....................................................................................................................................................................................................... 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................................................................................................. 79
Ejercicios de autoevaluacin....................................................................................................................................................................... 81 Respuesta a los ejercicios de autoevaluacin ............................................................................................................................................. 82

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

Sumario ....................................................................................................................................................................................................... 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 DE
SOFTWARE

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 SOFTWARE
1.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 SISTEMAS

Consultor

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 OBJETOS

Fuente: 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 INCREMENTAL

Comunicacin 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 prototipos

MODELOS 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 desarrollo
1.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 INGENIERA
DE 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 SOFTWARE
2.1. CONCEPTOS
SOFTWARE 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 proceso

Ser 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 prctica

Divide 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. ASPECTOS
INGENIERA

DE LA INGENIERA DE SISTEMAS QUE ESPECFICAMENTE AL REA DE

Herramientas 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 NECESARIOS

PARA 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.

DFD
Diagrama 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 DFD

Consistencia 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. INGENIERA
REALIZACIN.

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 DEL

SOFTWARE 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 ORIENTADO

A LA INFORMACIN
3.1. CONCEPTOS
DISEO 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 sistema y al final integran todas las partes. Adems, los sistemas que son diseados de forma modular son ms sencillos y fciles de mantener.

Se recomienda investigar ms a fondo cada uno de estos principios en el libro de Pressman (2010), de la pgina 239 a la 242, ya que pueden utilizarse como gua cuando se desarrolle cada componente de ese software.

Conforme avanza el diseo de un sistema de software, se aplican una serie de lineamientos prcticos a nivel de componentes, interfaces y dependencias y herencia. Componentes: se debe establecer convenciones en la nomenclatura de los componentes, que forman parte del modelo arquitectnico. Estos nombres deben hacer referencia al dominio del problema y a la vez deben tener algn significado para los participantes que vean el modelo arquitectnico. Por ejemplo, el nombre de una clase o componente puede ser CuentasCorrientes. Interfaces: Se recomienda en el caso de las interfaces representarlas por medio de una paleta, donde estas deben fluir del lado izquierdo del recuadro del componente y, adems, aparecer en el diseo solamente aquellas que sean relevantes para el componente que se est estudiando.

Dependencias y herencia: con las dependencias entre componentes deben ser representarlas por medio de interfaces. En el caso de la herencia es mejor modelar las dependencias de izquierda a derecha colocando las clases obtenidas abajo y las clases base arriba.

COHESIN

La cohesin implica que un componente o clase solo contiene atributos y operaciones que se relacionan de cerca uno con el otro y con la clase o componente de s (Pressman, 2010, p. 243). Hay tres tipos de cohesin: funcional, por capa y de comunicacin. Cuando las clases presentan estos tipos de cohesin, son ms fciles de implantar, probar y mantener. Como vimos en el tema anterior, es mejor manejar niveles altos de cohesin entre componentes.

ACOPLAMIENTO

El acoplamiento es la medicin cualitativa del grado en que las clases se conectan una con otra (Pressman, 2010, p. 244). Existen diferentes categoras de acoplamiento tales como acoplamiento de contenido, acoplamiento comn, acoplamiento de control, acoplamiento de molde, acoplamiento de datos, acoplamiento de rutina de llamada, acoplamiento de tipo de uso, acoplamiento de inclusin o importacin, y acoplamiento externo.

Los temas anteriores se pueden revisar ms a fondo en el libro de Pressman (2010), Ingeniera del software: Un enfoque prctico, en los captulos 8, 9 y 10.

REALIZACIN DEL DISEO A NIVEL DE COMPONENTES

El diseo arquitectnico transforma la informacin de los modelos de requerimientos a una representacin de diseo que de suficientes detalles para guiar la codificacin y pruebas del software. Los pasos por seguir en el diseo a nivel de componentes para un sistema orientado a objetos son los siguientes:

1. Identificar todas las clases de diseo que correspondan al dominio del problema

2. Identificar todas las clases de diseo que correspondan al dominio de la infraestructura

3.Elaborar todas las clases de diseo que no sean componentes reutilizables

4.Describir las fuentes persistentes de datos e identificar las clases requeridas para administrarlos

5.Desarrollar y elaborar representaciones del comportamiento para una clase o componente

6.Elaborar diagramas de despliegue para dar ms detalles de la implantacin

7.Redisear cada representacin del diseo en el nivel de componentes y siempre considerar alternativas

Fuente: Pressman (2010). Figura 3.2. Pasos para disear un componente orientado a objetos a la facilidad con que es utilizada la interfaz. Un sistema tiene buena usabilidad cuando ayuda a que el usuario cometa la menor cantidad de

3.5. DISEO DE LA INTERFAZ DE USUARIO En el diseo de interfaces de usuario hay un trmino muy importante: usabilidad. Se refiere

errores posibles y le permite realizar el proceso o tarea ms rpidamente. Lo anterior significa que entre mejor permita hacer una tarea una interfaz, mayor usabilidad tendr. En el diseo de HCI (Human Computer Interaction), es importante tener en cuenta las capacidades fsicas de los usuarios por lo que es importante considerar si alguno tiene una limitacin fsica ya que como analistas debemos ser capaces de compensar, ya sea la falta de algunos de los sentidos humanos (visin, odo y tacto) o algn impedimento (fsico, cognoscitivo o mental). Segn Kendall y Kendall (2011), existen una serie de buenas prcticas en la implementacin de HCI, que se muestran en la figura 3.3.

Hacer que la interfaz de usuario corresponda con la tarea

Hacer la interfaz de usuario eficiente

Proveer una retroalimentacin apropiada para los usuarios Generar consultas que se puedan utilizar Mejorar la productividad de los usuarios de computadora

Fuente: Kendal y Kendall (2011). Figura 3.3. Buenas prcticas en implementacin de HCI

3.6. TIPOS DE INTERFACES DE USUARIO Existen diferentes interfaces de usuario. El cuadro 1 explica cada una de ellas. Cuadro 1. Descripcin de tipos de interfaces Los usuarios pueden interactuar con la computadora mediante el uso de lenguaje natural. Son ideales para usuarios con algn tipo de discapacidad, aunque por sus problemas de implementacin, utilizacin de recursos de software y altos costos han mantenido el uso de estas interfaces al mnimo. Este tipo de interfaces permite una interaccin entre el usuario y la computadora. Inicialmente la computadora despliega una pregunta en pantalla, luego el usuario introduce una respuesta ya sea mediante una pulsacin de una tecla o con un clic del ratn, seguidamente la computadora procesa la informacin de acuerdo con la entrada recibida, normalmente avanzando a la siguiente pregunta. Un ejemplo de este tipo de interfaces son los asistentes de instalacin de software. Las interfaces de este tipo limitan al usuario a las opciones que se muestran en la pantalla. Tienen una ventaja y es que el usuario no necesita conocer con exactitud el sistema que va a utilizar, pero si la tarea que realizar. Existen varios tipos de mens, sin embargo su diseo depende del tipo de sistema. Los mens pueden ser anidados lo que ayuda a que la pantalla no se vea tan desordenada. Un ejemplo de este tipo de interfaz es la de un procesador de texto.

Leguaje natural

Preguntas y respuestas

Mens

Llenado de formularios

Estas interfaces consisten en formularios en pantalla o basados en Web que muestran los campos o parmetros necesarios para comunicarse con el usuario. Las pantallas tipo formulario sirven para mostrar qu informacin debe ser introducida y dnde hacerlo. El usuario puede desplazarse por cada uno de los campos hacia adelante, atrs, arriba o abajo. Las interfaces de lenguaje de comandos permiten a los usuarios controlar la aplicacin mediante una serie de pulsaciones de tecla, comandos, frases o alguna secuencia de estos tres mtodos. Estas interfaces ofrecen flexibilidad y control al usuario, pero tienen la desventaja de que no pueden ser utilizadas por usuarios inexpertos ya que para utilizarlas se requiere de la memorizacin de reglas de sintaxis.

Lenguaje de comandos

Son las llamadas GUI y permiten la interaccin entre la computadora y los Interfaces grficas de usuario usuarios por medio de una representacin grfica. Este tipo de interfaces (GUI) utiliza conos, controles o widgets adems de texto. Fuente: Kendal y Kendall (2011).

3.7. LINEAMIENTOS PARA EL DISEO DEL DILOGO Existen algunos puntos clave que para disear una buena comunicacin entre la computadora y el usuario. Los temas anteriores pueden ser revisado con mayor detalle en el libro, pginas 458 a la 459. Aparte de las buenas prcticas de diseo de HCI y los lineamientos para el diseo del dilogo, tambin el analista debe tener en cuenta incluir la realimentacin para los usuarios en el diseo de una interfaz, ya que esto nos puede ayudar a mejorar el desempeo del usuario con el sistema. Lo anterior se puede lograr si nosotros como analistas, en el momento de hacer el diseo de la interfaz, notificamos a los usuarios sobre el ingreso y formato correcto de datos notificaciones en retrasos de procesamientos de datos, asistentes, ayudas en lnea y foros, entre otros. En el caso del diseo de interfaces para comercio electrnico, aplicaciones web hbridas y pantallas de consultas, hay que tener ciertas consideraciones. En el caso de sistemas web o comercio electrnico, es importante que tenga

Comunicacin significativa

Mnima accin por parte del usuario

Operacin y consistencia estndar

Fuente: Kendal y Kendall (2011). Figura 3.4. Lineamientos para el diseo del dilogo humano-computadora

pantallas que sean de navegacin intuitiva o navegacin de un solo clic. Esto se logra al colocar mens con rollover, crear colecciones de vnculos jerrquicos, mapas de sitio en la pgina de inicio del sistema y, por ltimo, al colocar barras de navegacin interna en cada pgina. Para el caso de las aplicaciones hbridas (cuando se usan dos o ms API, Application Programming Interface) se puede utilizar un API para un sitio y combinarlo con otro para una nueva aplicacin web. Cuando se trata del diseo de interfaces de consultas, es importante tener en cuenta que seis son las ms comunes y que un buen diseo de cada una ayuda a reducir el tiempo que invierten los usuarios en realizarla

Es importante revisar el material respecto a los tipos de consulta existentes y los mtodos utilizados ms populares en las pginas de la 469 a la 473.

E JERCICIOS DE AUTOEVALUACIN Captulo 9 2. Defina lo que significa una decisin estructurada. 11. Cules son los principales usos de los rboles de decisin en el anlisis de sistemas? 14. Cules son las dos situaciones en las que debemos usar espaol estructurado? 15. Cules son las dos situaciones en las que funcionan mejor las tablas de decisin? 16. Cules son las dos situaciones en las que es preferible usar rboles de decisin? Captulo 14 1. Defina HCI. 5. Cules son las dos variables del modelo de aceptacin de la tecnologa (TAM)? 8. Mencione tres consideraciones fsicas de las que el diseo de HCI se ocupa. 10. Cules son los 5 objetivos para disear interfaces de usuario. 25. Cules son las siete situaciones que requieren realimentacin para los usuarios? 31. Describa dos tipos de diseos de sitios web para obtener retroalimentacin de los clientes 35. Elabore una lista con notacin abreviada de los seis tipos de consultas bsicas.

R ESPUESTA A LOS EJERCICIOS DE AUTOEVALUACIN Captulo 9 2. Una decisin estructurada es una secuencia de pasos, frmulas e iteraciones que pueden ser descritas mediante el mtodo de espaol estructurado, en el cual, la lgica se expresa en estructuras secuenciales, de decisin o en casos o iteraciones. 11. Los principales usos de los rboles de decisin en el anlisis de sistemas son los siguientes: identificar y organizar las condiciones y acciones en un proceso de decisin completamente estructurado. 14. Dos situaciones en las que debemos usar espaol estructurado son que haya muchas acciones repetitivas y que la comunicacin con los usuarios finales sea importante. 15. Dos situaciones en las que funcionan mejor las tablas de decisin son que se encuentre con combinaciones complejas de condiciones, acciones y reglas, y que requiera un mtodo que evite de manera efectiva las situaciones imposibles, redundancias y contradicciones. 16. Dos situaciones en las que es preferible usar rboles de decisin son la secuencia de condiciones y acciones crticas y que no todas las condiciones sean relevantes para todas las acciones (que las ramificaciones sean distintas).

Captulo 14 1. HCI es la abreviatura para interfaz humano computadora. Desde este enfoque podemos asegurar que nuestros sistemas se centran en el usuario, de manera que permitan satisfacer tanto las necesidades de estos como los de la organizacin. 5. Las dos variables del modelo de aceptacin de la tecnologa (TAM) son la utilidad percibida y la facilidad de uso percibida. 8. Tres consideraciones fsicas de las que el diseo de HCI se ocupa son los siguientes: i. ii. iii. iv. v. i. ii. iii. iv. visin: se est empezando a acostumbrar a disear pantalla e informes para las personas con discapacidad visual. odo: como analista se debe considerar el ruido al disear sistemas de oficina. tacto: se debe evaluar la utilidad de teclados y dems dispositivos de entrada. hacer que la interfaz de usuario corresponda con la tarea, hacer la interfaz de usuario eficiente, proveer una retroalimentacin apropiada a los usuarios, generar consultas que se puedan utilizar, y mejorar la productividad de los usuarios de computadora. acusar la aceptacin de la entrada, reconocer que la entrada est en el formato correcto, reconocer que la entrada no est en el formato correcto, explicar un retraso en el procesamiento,

10. Los cinco objetivos para disear interfaces de usuario son:

25. Las siete situaciones que requieren retroalimentacin para los usuarios son los siguientes:

v. vi. vii.

acusar el llenado de una solicitud, notificar que no se complet una solicitud, y ofrecer al usuario una retroalimentacin ms detallada.

31. Los dos tipos de diseos de sitios web para obtener realimentacin de los clientes: i. ii. i. ii. iii. iv. v. vi. iniciar el programa de correo electrnico del usuario con la direccin de correo electrnico del contacto de la empresa incluida automticamente en el campo para llevarlos a una plantilla de mensajes en blanco cuando haga clic en realimentacin. V (E,A) E (V,A) A (V,E) Todos los V (E, todos los A) Todos los E (V, todos los A) Todos los A (V, todas las E)

35. Lista con notacin abreviada de los seis tipos de consultas bsicas.

TEMA 4 ESTRATEGIA,
TCNICA Y MTRICA PARA LA PRUEBA DEL SOFTWARE

S UMARIO Captulo 15: Diseo de procedimientos precisos de entrada de datos Captulo 16: Aseguramiento e implementacin de la calidad S NTESIS En el siguiente tema vamos a hablar acerca del anlisis, diseo y evaluacin de las interfaces y de la importancia que tiene este proceso en el desarrollo de software. Adems, hablaremos del aseguramiento de la calidad del software y cmo las pruebas de software ayudan a este fin. O BJETIVOS Al finalizar el estudio de este captulo, entre otras habilidades, usted ser capaz de: 1. Aplicar las herramientas de anlisis y diseo en estrategia, tcnica y mtrica.

4. ESTRATEGIA, TCNICA Y MTRICA

PARA LA PRUEBA DEL SOFTWARE
4.1. ANLISIS,
DISEO Y EVALUACIN PARA LA INTERFAZ DE LOS SISTEMAS

El anlisis, diseo y evaluacin para una interfaz de un sistema es un proceso que comienza con la creacin de diferentes modelos del funcionamiento del sistema. Cuando se analiza y disea una interfaz de usuario, entran en juego cuatro diferentes modelos: modelo de usuario (encargado del software), modelo de diseo (ingeniero de software), modelo mental (usuario) y el modelo de implementacin (implementadores) (Pressman, 2010, p. 270). Tanto en el caso de modelo de usuario y de diseo son creados a partir de los requerimientos recogidos por el analista de sistemas. El modelo mental del usuario es la imagen del sistema que los usuarios finales llevan a la cabeza. El modelo de implementacin combina la manifestacin externa del

sistema basado en computadora con toda la informacin de apoyo que describe la sintaxis y semntica de la interfaz. Cuando el modelo de la implementacin y el modelo mental del usuario coinciden, quienes utilizan el software por lo general se sienten cmodos con ste y lo usan de manera eficaz (Pressman, 2010, p. 270). Para muchos usuarios la interfaz es el sistema, por lo que hay que tener mucho cuidado en su anlisis, diseo, proceso de construccin y evaluacin. Dado lo anterior, se ha convertido en un proceso iterativo, como se muestra en la figura 4.1.

Validacin de la interfaz

Anlisis y modelado de la interfaz

Construccin de la interfaz

Diseo de la interfaz

Fuente: Pressman (2010, p. 271). Figura 4.1. Proceso de diseo de la interfaz de usuario En la etapa de anlisis de la interfaz es donde se definen los perfiles de los usuarios que interactuarn con el sistema y las categoras de estos; se recogen los requerimientos, se analizan las tareas de los usuarios y cmo las realizan. Adems, se analiza el ambiente fsico dnde el usuario realizar el trabajo. Este proceso no se puede tomar a la ligera, porque toda la informacin recogida durante esta fase ser la base para el diseo de la interfaz. Esta etapa trata de definir todos los componentes de la pantalla (botones, campos, formas de navegacin, conos, colores, mens, manejo y control de errores, como avisos sobre formatos de campos o estado de procesos) que

ayudarn a que el usuario pueda realizar todas sus tareas de la mejor forma posible. La construccin de la interfaz normalmente inicia con la programacin de un prototipo, el cual se va refinando hasta lograr una pantalla, que contenga toda la informacin requerida para que el usuario pueda realizar su tarea de la mejor manera. Este es un trabajo que se realiza
Diseo preliminar

en conjunto entre el programador, el analista y el usuario. En la fase de validacin se evala la capacidad de la interfaz de implementar correctamente las tareas del usuario, la usabilidad y la aceptacin que esta tiene por parte de l. La figura 4.2 muestra el ciclo de evaluacin del diseo de la interfaz.
Construir el prototipo nmero 1 de la interfaz

Construir el prototipo nmero n de la interfaz

Se realizan las modificacines del diseo

El usuario evala la interfaz

El diseador estudia la interfaz

Fuente: Pressman (2010, p. 291). Figura 4.2. Ciclo de evaluacin del diseo de la interfaz

Para estudiar ms a fondo este tema, se les recomienda consultar el captulo 11 del libro de Pressman (2010), Ingeniera del software: Un enfoque prctico. Para que la fase de validacin de la interfaz sea un proceso fcil de realzar, existen una serie de aspectos que deben ser tomados en cuenta en el diseo para asegurar su calidad. Lo anterior se logra capturando datos de forma efectiva y eficiente. Para ello, aspectos como decidir qu datos se capturan, dejar que la computadora realice los trabajos repetitivos, evitar los pasos adicionales y cuellos de botella, una buena definicin del formulario de entrada de datos y la escogencia de un mtodo de entrada de datos, van a ser de mucha utilidad para alcanzar la meta de la ingeniera de software: desarrollar sistemas de alta calidad. Una forma de asegurar la calidad del software es cuidando la integridad de los datos y se logra validndolos en la entrada de la interfaz. Esto

nos asegura que se eliminen, lo ms pronto posible, la mayora de los problemas potenciales en los datos. Se pueden utilizar varias estrategias para llevar a cabo las pruebas de validacin de datos de entrada: prueba de datos flotantes, prueba de longitud de campo correcta, prueba de clase o composicin, prueba de rango de sensatez, prueba de valores invlidos, verificaciones de referencias cruzadas, prueba para comparar con datos almacenados, y configurar cdigos de autovalidacin (dgitos de verificacin).

La informacin anterior est muy bien desarrollada en el libro, desde la pgina 494 hasta la 503.

4.2. ESTRATEGIAS

QUE EXISTEN SOBRE LOS DIFERENTES

TIPOS DE PRUEBA

conocida por los analistas de sistemas para poder aplicar sus principios a los proyectos. Otras acciones que los analistas pueden realizar para mejorar la administracin de la calidad es seleccionar adecuadamente la metodologa, que se va a utilizar ya sea por medio de: recorridos estructurados, diseo y desarrollo de sistemas descendente, utilizacin de diagramas de estructura para disear sistemas modulares, y utilizacin de arquitectura orientada a servicios (SOA). Las metodologas de documentacin, como los manuales de procedimiento y el mtodo Folklore (documentacin de las costumbres, relatos dichos y formas artsticas), estn ligados al esfuerzo del aseguramiento de la calidad del software, ya que ayudan a que se pueda dar mantenimiento y mejorar los sistemas. La eleccin de una tcnica de diseo y documentacin, es una tarea clave del analista de sistemas. Algunos lineamientos que pueden

No podemos hablar de pruebas de software sin antes hablar de la calidad de este. La calidad se define como un Proceso eficaz de software que se aplica de manera que crea un producto til que proporciona valor medible a quienes lo producen y a quienes lo utilizan (Pressman, 2010, p. 340). La calidad del software persigue los siguientes factores: que sea intuitivo, eficiente, robusto (maneja errores) y rico (personalizada para el usuario). Existen diferentes metodologas de administracin de la calidad. Una de ellas es La administracin de la calidad total (TQM), la cual es esencial en todos los procesos de desarrollo de sistemas (Kendall y Kendall, 2011, p. 516). La metodologa Seis Sigma vino a cambiar el enfoque hacia la administracin de la calidad total. Sin embargo, es ms que solo una serie de pasos, es una filosofa y una cultura cuyo objetivo es eliminar todos los defectos. Debe ser

ayudar a seleccionar la tcnica apropiada para el sistema que se va a desarrollar son que esta sea compatible con la documentacin existente, sea comprendida por los dems en la organizacin, le permita regresar a trabajar en el sistema despus de haber estado alejado durante un periodo de tiempo, sea adecuada para el tamao del sistema en el que se est trabajando, permita una metodologa de diseo estructurado, si eso se considera ms importante que otros factores, y permita modificarla con facilidad (Kendall y Kendall, 2011, p. 526).

una manera de asegurar la calidad del software. Un sistema probado antes de ser entregado es ms barato, ya que el costo de corregir pulgas (defectos o fallas) en un sistema terminado y liberado es muy elevado. De hecho, en las empresas que tienen algn nivel de madurez de desarrollo de software dedican tiempo a calcular mtricas sobre el esfuerzo en tiempo y dinero que implica el proceso de mejoramiento del software. Cada participante del proceso del desarrollo de software desempea un rol distinto en los diferentes aspectos de este.

Una vez que el software se ha diseado y codificado, la prueba se vuelve una tarea importante para asegurar la calidad. El proceso de prueba se realiza durante el desarrollo del sistema con la idea de que nos ayude a encontrar problemas que no han sido descubiertos hasta ese momento. La prueba es

Revise la pgina 527 del libro, donde se explican los distintos roles en el proceso de prueba de software y sistemas.

La figura 4.3 muestra las estrategias de software que pueden ser aplicadas a cualquier tipo de sistema.

Prueba del sistema

Prueba de validacin

Prueba de integracin
Prueba de unidad

Cdigo Diseo Requerimientos

Ingeniera de sistema

Fuente: Pressman (2010, p. 387). Figura 4.3. Estrategia de pruebas Al igual que otros procesos de la ingeniera de software, las estrategias de prueba son iterativas, donde la prueba de unidad se concentra en cada parte del sistema, como se implement en el cdigo fuente. Con esto se asegura una cobertura completa y la deteccin temprana de errores. La prueba de integracin se centra en el diseo y construccin de la arquitectura del software, en esta estrategia se utilizan ms las tcnicas de diseo de casos enfocadas en entradas y salidas. La prueba de validacin verifica los requerimientos establecidos en los casos de uso contra el software que se construy, as, se asegura que al final el software cumple con todos las

necesidades que se plantearon al inicio. Por ltimo, en la prueba del sistema se corrobora el funcionamiento del software y otros elementos que se relacionan con este. Se revisa como un todo para verificar que los elementos se mezclaron correctamente. Se dice que el anterior es un proceso iterativo porque las pruebas de software nunca terminan. Lo que sucede, una vez que se ha liberado el software, es que la carga de la prueba pasa del ingeniero de software al usuario final (Pressman (2010, p. 388). Para que estas sean exitosas, hay una serie de aspectos a ser tomados en cuenta, tales como Una buena estrategia de prueba tambin valora otras caractersticas de la calidad, como la portabilidad el mantenimiento y la facilidad de uso. Los objetivos especficos de las pruebas deben enunciarse en trminos medibles. Los casos de uso que describen el escenario de interaccin pueden reducir el esfuerzo de prueba global al enfocar las pruebas en el uso real del producto.

Se recomienda que el equipo de software aprenda a probar en ciclos rpidos. La realimentacin generada a partir de estas pruebas de ciclo rpido puede usarse para controlar niveles de calidad y las correspondientes estrategias de prueba. El software debe poder diagnosticar cierta clase de errores. Adems, el diseo debe incluir pruebas automatizadas y pruebas de regresin. Usar revisiones tcnicas efectivas como filtro previo a la prueba. Realizar revisiones tcnicas para valorar la estrategia de prueba y los casos de prueba. Desarrollar un enfoque de mejora continuo. Las mtricas recopiladas durante las pruebas deben usarse como parte de un enfoque de control de proceso estadstico para la prueba del software (Pressman, 2010, pp. 388-389).

4.3. ESTRATEGIAS DE PRUEBA Y TCNICAS DEFINIDAS PARA

EL DISEO DE CASOS DE PRUEBA

Cuando se realizan pruebas, lo mejor es realizar siempre diferentes tcnicas de prueba en cada momento del desarrollo; adems, es recomendable que la prueba comience en los componentes y opere hacia afuera, o sea, hacia la integracin de todo el software. En el proceso de prueba se involucra el equipo de desarrollo de software y los usuarios finales del sistema. La idea es que al incluir a todos los interesados se pueda estar seguros de dos cosas: que se construy el producto correcto y que se hizo de la forma adecuada. Tanto la estrategia como los aspectos generales del proceso de pruebas descritos anteriormente, pueden ser utilizados con cualquier tipo de caso. Con el diseo de estos casos, lo que se intenta es realizar pruebas capaces de encontrar el mayor nmero de errores y defectos con la menor cantidad de esfuerzo y de tiempo. Existen dos tipos de caso de prueba: caja blanca y caja negra.

Pruebas de caja blanca: es una filosofa de diseo de casos de prueba que usa la estructura de control descrita como parte de diseo a nivel de componentes para derivar casos de prueba. Al usar los mtodos de prueba de caja blanca, se pueden derivar casos de prueba que: 1) garanticen que todas las rutas independientes dentro de un mdulo se revisaron al menos una vez, 2) revisen todas las decisiones lgicas en sus lados verdadero y falso, 3) ejecuten todos los bucles en sus fronteras y dentro de su fronteras operativas y 4) revisen estructuras de datos internas para garantizar su validez (Pressman, 2010, p. 414). Pruebas de caja negra: tambin llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del software; es decir, las tcnicas de caja negra le permiten derivar conjuntos de condiciones de entrada que revisarn por completo todos los requerimientos funcionales para

un programa. Las pruebas de caja negra intentan encontrar errores en las categoras siguientes: 1) funciones incorrectas o flotantes, 2) errores de interfaz, 3) errores en las estructuras de datos externas, 4) errores de comportamiento o rendimiento y 5) errores de inicializacin y terminacin (Pressman, 2010, p. 423). Existen diferentes tipos de caso de prueba dependiendo del tipo de software: Prueba de software convencional: pruebas de caja blanca, pruebas de ruta bsica, pruebas de estructura de control, pruebas de caja negra, pruebas basadas en modelos, y pruebas para entornos arquitectnicos y aplicaciones especializados.

Pruebas de aplicaciones orientadas a objetos pruebas de unidad en el contexto OO, pruebas de integracin en el contexto OO, y prueba de validacin en un contexto OO. Pruebas aplicaciones prueba de contenido, prueba de interfaz de usuario, prueba en el nivel de componente, pruebas de navegacin, pruebas de configuracin, pruebas de seguridad, y pruebas de rendimiento.

Todos estos temas referentes a estrategias y tipos de prueba estn muy bien desarrollados en los captulos 18, 19 y 20 del libro de Pressman (2010), Ingeniera del software: Un enfoque prctico.

E JERCICIOS DE AUTOEVALUACIN Captulo 15 1. Cules son los cuatro principales objetivos de la entrada de datos? 3. Defina el trmino cdigo de secuencia simple. 6. Defina el trmino cdigo de secuencia de bloque. 10. Defina el trmino cdigo de funcin. 12. Qu son los datos modificables? 13. Qu son los datos de diferenciacin? 29. Qu es una expresin regular? Captulo 16 1. Cules son las tres metodologas amplias para que el analista de sistemas obtenga calidad en los sistemas recin desarrollados? 7. Mencione las ventajas de tomar una metodologa descendente para el diseo. 8. Defina el desarrollo modular. 11. Qu es la arquitectura orientada a servicios? 15. Quin tiene como principal responsabilidad probar los programas de computadora? 16. Cul es la diferencia entre datos de prueba y datos reales?

19. Defina lo que significa un sistema distribuido. 20. Cul es el modelo cliente-servidor? 28. Defina los trminos seguridad fsica, lgica y conductual y d un ejemplo de cada una que ilustre las diferencias entre ellos.

R ESPUESTA A LOS EJERCICIOS DE AUTOEVALUACIN Captulo 15 1. Los cuatro principales objetivos de la entrada de datos son los siguientes: crear una codificacin significativa para los datos, disear metodologas eficientes de captura de datos, asegura una captura de datos completa y efectiva, y asegura la calidad de los datos por medio de la validacin.

3. El cdigo de secuencia simple es un nmero que se asigna a algo si necesita estar enumerado. No tiene relacin con los datos en s. Este nmero puede ser aleatorio o secuencial. 6. El trmino cdigo de secuencia de bloque es una extensin de los cdigos de secuencia. Los cdigos de secuencia en bloque se agrupan de acuerdo con las caractersticas comunes de los datos. 10. El trmino cdigo de funcin enuncia las funciones que el analista o programador desea que la computadora realice con los datos. La accin de explicar con detalle las actividades por realizar, se traducen en un cdigo corto numrico o alfabtico. 12. Los datos modificables son los que cambian o varan con cada transaccin. 13. Los datos de diferenciacin son los que diferencian en forma concisa el elemento especfico que se est procesando de los dems elementos. 29. Una expresin regular es un patrn que contiene smbolos que representan el tipo de datos que deben estar presentes en un campo.

Captulo 16 1. Tres metodologas amplias para que el analista de sistemas obtenga calidad en los sistemas recin desarrollados son las siguientes: recorrido estructurado, diseo y desarrollo de sistemas descendente, y uso de diagramas de estructura para disear sistemas modulares. 7. Las ventajas de tomar una metodologa descendente para el diseo son las siguientes: evitar el caos de disear un sistema todo a la vez, permite a los equipos separados de anlisis de sistemas trabajar en paralelo en subsistemas distintos, pero necesarios, lo que puede ahorrar mucho tiempo, y evita que los analistas de sistemas se enreden tanto en los detalles que pierdan la visin de lo que se supone debe hacer el sistema. 8. El desarrollo modular implica descomponer la programacin en porciones lgicas y manejables o mdulos. Tiene tres ventajas: los mdulos son ms fciles de escribir y depurar debido a que son prcticamente independientes, los mdulos son ms fciles de mantener y los mdulos son ms fciles de comprender. 11. La arquitectura orientada a servicios se encarga de crear servicios SOA individuales que no tengan ninguna asociacin o que estn dbilmente acoplados entre s. Cada servicio ejecuta una accin. Se puede decir que la arquitectura orientada a servicios es un grupo de servicios a los cuales podemos llamar para que provean funciones especficas. En vez de incluir llamados a otros servicios, un servicio puede usar ciertos protocolos definidos para poder comunicarse con otros.

15. La principal responsabilidad de probar los programas de computadora es de los analistas, programadores, usuarios y operadores. 16. La diferencia entre datos de prueba y datos reales es que los datos de prueba son creados por los programadores para correr las pruebas, pueden ser vlidos o invlidos, mientras que los datos reales son datos que se procesaron satisfactoriamente en el sistema anterior. 19. Un sistema distribuido es el que aprovecha la tecnologa de las telecomunicaciones y de administracin de bases de datos, para interconectar a las personas que manipulan algunos de estos de forma significativa, pero diferentes. Conforme se evalan el hardware y el software, el analista de sistemas tambin necesita considerar los costos y beneficios de emplear un sistema distribuido para satisfacer los requerimientos del usuario. 20. El modelo cliente-servidor es un modelo de diseo que se puede considerar como aplicaciones que se ejecutan en una red. En trminos bsicos, el cliente hace una solicitud y que el servidor la procesa. 28. Definiciones Seguridad fsica: se refiere a proteger el sitio donde se encuentra la computadora, su equipo y software a travs de medios fsicos. Un ejemplo es el uso de cmaras de video para vigilancia. Seguridad lgica: se refiere a controles lgicos de software. Ejemplo: Contraseas. Seguridad conductual: se refiere a las expectativas conductuales que estn implcitas en los manuales de polticas de las organizaciones e incluso en las salas de trabajo y los comedores. Ejemplo: hacer que el sistema registre el nmero de inicios de sesin fallidos.

LISTA DE
REFERENCIAS

Kendall, K. y Kendall, E. (2011). Anlisis y Diseo de Sistemas. Mxico: Editorial Prentice Hall. Pressman, R. (2010). Ingeniera del software: Un enfoque prctico. Mxico: Editorial Mc Graw Hill.