FUNDAMENTOS DE DESARROLLO DE SISTEMAS UNIDAD 1 - CONCEPTOS INTRODUCTORIOS 1.1.- INTRODUCCION A LOS SISTEMAS 1.1.1.

- DESCRIPCION GENERAL El desarrollo de sistemas se entiende como un ciclo de vida de software que se repite una y otra vez como consecuencia de que el desarrollo de sistemas siempre esta sujeto a mejora continua, ya que nunca se puede decir que un sistema esta desarrollado o que trabaja el 100% porque se estar sujeto a cambios imprevistos o actualizaciones continuas. 1.1.2.- TIPOS En cuanto a su constitucin pueden ser fsicos o abstractos. Sistemas fsicos o concretos: equipo, maquinaria, objetos y cosas reales. Sistemas abstractos: conceptos, planes, hiptesis e ideas, software. En cuanto a su naturaleza, pueden ser cerrados o abiertos. Cerrados: no presentan intercambio con el medio ambiente que los rodea, son hermticos a cualquier influencia ambiental. No reciben ningn recurso externo y nada produce que sean enviados hacia afuera. Abiertos: presentan intercambios con el ambiente, a travs de entradas y salidas. Su estructura es ptima cuando el conjunto de elementos del sistema, se organiza aproximndose a una operacin adaptativa. 1.2.3.- CLASIFICACIN Los sistemas de informacin son desarrollados con propsitos diferentes dependiendo de la necesidad del negocio. Sistemas de procesamiento de transacciones (TPS).- funcionan a nivel operacional de la organizacin. Son sistemas de informacin computarizados desarrollados para procesar gran cantidad de datos para transacciones rutinarias de los negocios, tales como nomina e inventario. Sistemas de automatizacin de oficina y sistemas de manejo de conocimiento (OAS) y (KWS).- dan cabida al trabajo a nivel de conocimiento. Los (OAS) dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la informacin para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organizacin y algunas veces mas all de ella. Los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como cientficos, ingenieros y doctores, les ayudan a crear un nuevo conocimiento que contribuya a la organizacin o a toda la sociedad Sistemas de informacin gerencial (MIS).- no remplazan a los sistemas de procesamiento de transacciones, sino que todos los MIS incluyen procesamiento de transacciones, son sistemas

de informacin computarizada que trabajan debido a la interaccin resuelta entre gerentes y computadoras. Requieren que las gerentes, el software y el hardware trabajen al unsono. Sistemas de apoyo a decisiones (DSS) y sistemas de informacin gerencial (MIS).- el DSS es similar al sistema de informacin gerencial tradicional en que amos dependen de una BDD como fuente. Un sistema de apoyo a decisiones se aparta del sistema de informacin gerencial en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisin actual todava es del dominio del tomador de decisiones. 1.2.- CICLO DE VIDA DE UN PROYECTO DE SOFTWARE El ciclo de vida de desarrollo de sistemas (SDLC) es un enfoque por fases del anlisis y diseo que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo de vida especifico de actividades del analista y del usuario. Los analistas no estn de acuerdo con que tantas fases exactas hay en el ciclo de vida del desarrollo de sistemas, pero, por lo general, alaban su enfoque organizado. 1.2.1.- PLANEACIN Y GESTIN DEL PROYECTO (IDENTIFICACIN DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS) En la primera fase del ciclo de vida del desarrollo de sistemas el analista tiene que ver con la identificacin de problemas, oportunidades y objetivos. Esta etapa es crtica para el xito del resto del proyecto, debido a que nadie quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado. La primera fase requiere que el analista observe honestamente lo que esta sucediendo en un negocio. Luego, junto con los dems miembros de la organizacin, el analista hace resaltar los problemas. Las oportunidades son situaciones que el analista considera que pueden ser mejoradas por medio del uso de sistemas de informacin computarizados. La identificacin de objetivos es tambin un componente importante de la primera fase. En primer lugar el analista debe descubrir lo que esta tratando de hacer el negocio. Luego ser capaz de ver si algn aspecto de la aplicacin de sistemas de informacin puede ayudar para que el negocio alcance sus objetivos atacando problemas especficos u oportunidades. Las personas involucradas en la primera fase son los usuarios, analistas y administradores de sistemas que coordinan el proyecto. Las actividades de esta fase consisten en entrevistas a los administradores de los usuarios, sumarizacin del conocimiento obtenido, estimacin del alcance del proyecto y documentacin de los resultados. La salida de esta fase es un estudio de factibilidad que contiene una definicin del problema y la sumarizacin de los objetivos. 1.2.2.- DETERMINACION DE LOS REQUERIMIENTOS DE INFORMACION. Entre las herramientas utilizadas para definir los requerimientos de informacin en el negocio se encuentran: muestreo e investigacin de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboracin de prototipos.

Se puede ver que varios de los mtodos para determinar los requerimientos de informacin involucran la interaccin directa con los usuarios. Esta fase sirve para formar la imagen que el analista tiene de la organizacin y sus objetivos. Las personas involucradas en esta fase son los analistas y los usuarios, tpicamente los administradores de las operaciones y los trabajadores de las operaciones. El analista de sistemas necesita saber los detalles de las funciones actuales del sistema: quien (las personas que estn involucradas), que (la actividad del negocio), donde (el ambiente donde se lleva a cabo el negocio), cuando (en que momento) y como (de que manera se desarrollan los procedimientos actuales) del negocio bajo estudio. El analista debe preguntar porque el negocio usa el sistema actual. Al termino de esta fase, el analista debe comprender el porque de las funciones del negocio y tener informacin completa sobre las personas, objetivos, datos y procedimientos involucrados. 1.2.3.- ANLISIS Y DISEO ANALISIS DE LAS NECESIDADES DEL SISTEMA. Nuevamente, herramientas y tcnicas especiales ayudan para que el analista haga las determinaciones de los requerimientos. Una herramienta de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones del negocio en forma grafica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, as como sus especificaciones, si son alfanumricos y que tanto espacio ocupan cuando se imprimen. En esta punto de ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistema que sumariza lo que ha sido encontrado, proporciona anlisis de costo / beneficio de las alternativas y hace recomendaciones sobre lo que debe ser hecho (en caso de haberlo). Si alguna de las recomendaciones es aceptable para la administracin, el analista continua sobre su curso. Cada problema de sistema es nico y nunca hay una sola solucin correcta. La manera en que se formula una solucin o recomendacin depende de la capacidad y entrenamiento profesional individual de cada analista. DISEO DEL SISTEMA RECOMENDADO En esta fase, el analista usa la informacin recolectada anteriormente para realizar el diseo lgico del sistema de informacin. El analista disea procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de informacin sean correctos. Parte del diseo lgico del sistema de informacin es disear la interfaz de usuario. La interfaz conecta al usuario con el sistema y es, por lo tanto, extremadamente importante. La fase de diseo tambin incluye el diseo de archivos o bases de datos que guardaran la mayor parte de los datos necesarios para los tomadores de decisiones de la organizacin. Una base de datos bien organizada es la base para todos los sistemas de informacin. En esta fase el analista tambin trabaja con los usuarios para disear la salida (ya sea en pantalla o impresa) que satisfaga sus necesidades de informacin. Por ultimo el analista debe disear procedimientos de control y respaldo para proteger al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener diseos de entrada y salida, especificaciones de archivos y detalles de procesamiento, y tambin puede incluir arboles o tablas de decisin,

diagramas de flujo de datos, un diagrama del sistema y los nombres y funciones de cualesquier de las rutinas de cdigo que hayan sido escritas. 1.2.4.- DESARROLLO Y DOCUMENTACION DEL SOFTWARE (PROGRAMACIN) En la cuarta fase del ciclo de vida del desarrollo de sistemas el analista trabaja con los programadores para desarrollar cualquier software original que se necesite. Algunas de las tcnicas estructuradas para l diseo y documentacin de software incluyen diagramas estructurados, el mtodo HIPO, diagramas de flujo, diagramas Nassi-Schneiderman y WarnierOrr y pseudocdigo. El analista de sistemas usa uno o ms de estos dispositivos para comunicar al programador lo que necesita ser programado. Durante esta fase el analista tambin trabaja con los usuarios para desarrollar documentacin efectiva para el software, incluyendo manuales de procedimientos. La documentacin le dice al usuario la manera de usar el software y tambin qu hacer si se suceden problemas con el software. Los programadores tienen un papel principal en esta fase conforme disean, codifican, y eliminan errores de sintaxis de los programas de computadora. Para asegurar la calidad, un programador puede realizar ya sea un diseo o un ensayo del cdigo, explicando las partes complejas del programa a un equipo de otros programadores. 1.2.5.- PRUEBAS E IMPLEMENTACIN PRUEBAS Y MANTENIMIENTO DEL SISTEMA Antes de que pueda ser usado, el sistema de informacin debe ser probado. Es mucho menos costoso encontrar problemas antes de que el sistema sea entregado a los usuarios. Algunas pruebas son realizadas por los programadores solos, y otras por los analistas de sistemas junto con los programadores. Primero se ejecuta una serie de pruebas para que destaquen los problemas con datos de ejemplo y eventualmente con datos reales del sistema actual. El mantenimiento del sistema y de su documentacin comienza en esta fase y es efectuado rutinariamente a lo largo de la vida del sistema de informacin. Mucho del trabajo rutinario del programador consiste en el mantenimiento, ya que los negocios gastan gran cantidad de dinero en dicho mantenimiento. Muchos de los procedimientos sistemticos que emplea el analista a lo largo del ciclo de vida del desarrollo del sistema pueden ayudar a asegurar que el mantenimiento se mantenga al mnimo. IMPLEMENTACIN Y EVALUACIN DEL SISTEMA En esta fase, el analista ayuda a implementar el sistema de informacin. Esto incluye el entrenamiento de los usuarios para que manejen el sistema. Algn entrenamiento es hecho por los proveedores pero la supervisin del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversin suave del sistema antiguo al nuevo. Este proceso incluye la conversin de archivos de formatos antiguos a nuevos o la construccin de una base de datos, la instalacin de equipo y la puesta del nuevo sistema en produccin. La evaluacin se muestra como parte de esta fase final de ciclo de vida del desarrollo de sistemas, principalmente para efectos de discusin. De hecho, la evaluacin se realiza durante cada fase. Un criterio principal que debe ser satisfecho es si los usuarios pretendidos ya estn usando el sistema.

Debe hacerse notar que a veces los sistemas trabajan en forma cclica. Cuando un analista termina una fase del desarrollo del sistema y pasa a la siguiente, el descubrimiento de un problema puede obligar a que el analista regrese a la fase anterior y modifique el trabajo que all hizo. Por ejemplo, durante la fase de prueba el programador puede descubrir que el programa no trabaja correctamente, ya sea debido a que no se escribi cdigo para apoyar determinadas partes del diseo del sistema o aquel diseo fue incompleto. En cualquier caso deben ser modificados los programas, y el analista puede tener que cambiar algunos de los materiales del diseo del sistema. A su vez, esto puede necesitar que el analista se rena con el usuario y vuelva a investigar como funciona una actividad especfica del negocio. UNIDAD 2 INTRODUCCION A LA INGENIERIA DE SOFTWARE 2.1.- DEFINICIN DE LA INGENIERA DE SOFTWARE. Segn Fritz Bauer, la ingeniera de software es el establecimiento y uso de principios robustos de la ingeniera a fin de obtener econmicamente software que sea fiable y que funcione eficientemente sobre maquinas reales. Segn el instituto de ingenieros elctricos y electrnicos (IEEE) la ingeniera del software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de ingeniera al software. 2.2.- HISTORIA DE LA INGENIERIA DEL SOFTWARE Hoy en dia el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehculo para entregarlo. Como producto, hace entrega de la potencia informtica que incorpora el hardware informtico, o ms ampliamente, una red de computadoras que es accesible por hardware local. Si reside dentro de un telfono celular u opera dentro de una computadora central, el software es un transformador de informacin, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo informacin que puede ser tan simple como un solo bit, o tan complejo como una presentacin en multimedia. Como vehculo utilizado para hacer entrega del producto, el software acta como la base de control de la computadora (sistemas operativos), la comunicacin de informacin (redes) y la creacin y control de otros programas (herramientas de software y entornos). El papel del software informtico ha sufrido un cambio significativo durante un periodo de tiempo superior a 50 aos. Enormes mejoras en rendimiento del hardware, profundos cambios de arquitecturas informticas, grandes aumentos de memoria y capacidad de almacenamiento y una gran variedad de opciones de entrada y salida han conducido a sistemas ms sofisticados y ms complejos basados en computadora. Aos 1950.- existencia de sistemas por lotes, software de manera artesanal, evolucin en el hardware, bulbos a transistores. Aos 1960.- concepto de Bases de Datos, reduccin de precio y tamao del hardware, auge de transistor a circuito integrado, incrementa rendimiento del hardware, sistemas multi-usuarios. Aos 1970.- programacin estructurada, nacen las redes, CI = microprocesador, inteligencia artificial, ingeniera del software, sistemas distribuidos, internet. Aos 1980.- redes neuronales, sistemas operativos multitareas, procesadores Pentium, PC, SGBD, paradigmas del desarrollo, programacin orientada a objetos. Aos 1990.- arquitectura cliente servidor, entornos de programacin, desarrollo web, interfaz grafica de usuarios (GUI), sociedades virtuales, trabajo en lneas, crece multimedia.

2.3.- CARACTERSTICAS DEL SOFTWARE El software es un elemento del sistema que es lgico, en lugar de fsico. Por tanto el software tiene unas caractersticas considerablemente distintas a las del hardware: 1.- El software se desarrolla, no se fabrica en un sentido clsico Aunque existen similitudes entre el desarrollo del software y la constitucin del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseo, pero la fase de construccin del hardware puede introducir problemas de calidad que no existen (o son fcilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relacin entre las personas dedicadas y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construccin de un producto pero los enfoques son diferentes. 2.- El software no se estropea El software no es susceptible a los males del entorno que hacen que el hardware se estropee. Los defectos no detectados harn que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corrigen (suponiendo que no se introducen nuevos errores) el ndice de fallos es nulo. La implicacin es clara el software no se estropea pero se deteriora. Durante su vida, el software sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos y por consiguiente el software se va deteriorando. Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software. Cuando un componente de hardware se estropea se sustituye por una pieza de repuesto. No hay piezas de repuesto para el software. Cada fallo en el software indica un error en el diseo o en el proceso mediante el que se tradujo el diseo a cdigo maquina ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware. 3.- Aunque la industria tiende a ensamblar componentes, la mayora del software se construye a medida. Consideremos la forma en la que se disea y se construye el hardware de control para un producto basado en computadora. El ingeniero de diseo construye un sencillo esquema de la circuitera digital, hace algn anlisis fundamental para asegurar que se consigue la funcin adecuada y va al armario donde se encuentran los catlogos de componentes digitales. Despus de seleccionar cada componente, puede solicitarse la compra. Los componentes reutilizables se han creado para que el ingeniero pueda concentrarse en elementos verdaderamente innovadores de un diseo. En el mundo del hardware, la reutilizacin de componentes es una parte natural del proceso de ingeniera. En el mundo del software es algo que solo ha comenzado a lograrse en una escala amplia. Los componentes reutilizables modernos encapsulan tanto datos como procesos que se aplican a los datos, permitiendo al ingeniero de software crear nuevas aplicaciones a partir de las partes reutilizables.

2.4.- MITOS DEL SOFTWARE Muchas de las causas de la crisis del software se pueden encontrar en una mitologa que surge durante los primeros aos del desarrollo del software. A diferencia de los mitos antiguos, que a menudo proporcionaban a los hombres lecciones dignas de tener en cuenta, los mitos del software propagaron informacin errnea y confusin. Los mitos del software tienen varios atributos que los hacen insidiosos; por ejemplo, aparecieron como declaraciones razonables de hechos (algunas veces conteniendo elementos verdaderos), tuvieron un sentido intuitivo y frecuentemente fueron promulgados por expertos que estaban al dia. Mitos de gestin. Los gestores con responsabilidad sobre el software, como los gestores en la mayora de las disciplinas, estn normalmente bajo la presin de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad, igual que se agarra al vacio una persona que se ahoga, un gestor de software se agarra frecuentemente a un mito del software, aunque tal creencia solo disminuya la presin temporalmente. Mito.- mi gente dispone de las herramientas de desarrollo mas avanzadas, despus de todo, les compramos las computadoras mas modernas. Realidad.- se necesita mucho ms que el ltimo modelo de computadora grande o de PC para hacer desarrollo de software de gran calidad. Las herramientas de ingeniera de software asistida por computadora (CASE) son mas importantes que el hardware para conseguir buena calidad y productividad, aunque la mayora de los desarrolladores del software todava no las utilicen eficientemente. Mito.- si fallamos en la planificacin, podemos aadir mas programadores y adelantar el tiempo perdido. Realidad.- el desarrollo de software no es un proceso mecnico como la fabricacin. En palabras de Brooks aadir gente a un proyecto de software retrasado lo retrasa aun ms. Cuando se aaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hacen que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede aadirse gente, pero solo de una manera planificada y bien coordinada. Mitos del cliente.- un cliente que solicita una aplicacin de software puede ser una persona del despacho de a lado, un grupo tecnico de la sala de abajo, el departamento de ventas o una compaa exterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala informacin. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el que desarrolla el software. Mito.- una declaracin general de los objetivos es suficiente para comenzara escribir los programas. Podemos dar los detalles mas adelante. Realidad.- una mala definicin inicial es la principal causa de trabajo baldo en el software. Es esencial una descripcin formal y detallada del mbito de la informacin, funciones, comportamiento, rendimiento, interfaces, ligaduras del diseo, y criterios de validacin. Estas caractersticas pueden determinarse slo despus de una exhaustiva comunicacin entre el cliente y el analista. Mito.- los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fcilmente, ya que el software es flexible.

Realidad.- es verdad que los requisitos del software cambian, pero el impacto del cambio vara segn el momento en que se introduzca. Si se pone cuidado al dar la definicin inicial, los cambios solicitados al principio pueden acomodarse fcilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el coste. Cuando los cambios se solicitan durante el diseo del software, el impacto en el coste crece rpidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de trabajo del diseo. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseo; es decir, coste adicional. Los cambios en la funcin, rendimiento, interfaces u otras caractersticas, durante la implementacin pueden tener un impacto importante sobre el coste. Cuando se solicita al final de un proyecto, los cambios pueden producir un orden de magnitud ms caro que el mismo cambio pedido al principio. Mitos de los desarrolladores.- los mitos en los que aun creen muchos desarrolladores se han ido fomentando durante 50 aos de cultura informtica. Durante los primeros das del desarrollo del software, la programacin se vea como un arte. Las viejas formas y actitudes tardan en morir. Mito.- una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad.- alguien dijo una vez cuanto mas pronto se comience a escribir cdigo, mas se tardara e terminarlo. Los datos industriales indican que entre el 60 y el 80 por ciento de todo el esfuerzo dedicado a un programa se realizar despus de que se le haya entregado al cliente por primera vez. Mito.- hasta que no tengo el programa ejecutndose, realmente no tengo forma de comprobar su calidad. Realidad.- desde el principio del proyecto se puede aplicar uno de los mecanismos ms efectivos para garantizar la calidad del software: la revisin tcnica formal. La revisin del software es un filtro de calidad que se ha comprobado que es ms efectivo que la prueba, para encontrar ciertas clases de defectos en el software. Mito.- lo nico que se entrega al terminar el proyecto es el programa funcionando. Realidad.- un programa que funciona es solo una parte de una configuracin del software que incluye muchos elementos. La documentacin proporciona el fundamento para un buen desarrollo y, lo que es ms importante, proporciona guas para la tarea de mantenimiento del software. 2.5.- CAPAS DE LA INGENIERIA DEL SOFTWARE La ingeniera del software es una tecnologa multicapa, cualquier enfoque de ingeniera debe apoyarse sobre un compromiso de organizacin de calidad. Herramientas Mtodos Proceso Un enfoque de calidad Figura 2.1. Capas de la ingeniera del software.

El fundamento de la ingeniera del software es la capa de proceso. El proceso de la ingeniera del software es la unin que mantiene juntas las capas de tecnologa y que permite un desarrollo racional y oportuno de la ingeniera del software. El proceso define un marco de trabajo para un conjunto de reas clave de proceso que se deben establecer para la entrega efectiva de la tecnologa de la ingeniera del software. Las reas claves del proceso forman la base del control de gestin de proyectos del software y establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. Los mtodos de la ingeniera del software indican como construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera del software dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. Las herramientas de la ingeniera del software proporcionan un enfoque automtico o semiautomtico para el proceso y para los mtodos. Cuando se integran herramientas para que la informacin creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniera del software asistido por computadora (CASE). La ingeniera del software comprende un proceso, mtodos tcnicos y de gestin, y herramientas. 2.6.- EL PROCESO DEL SOFTWARE. Un proceso del software se puede caracterizar como se muestra en la figura 2.2. Se establece un marco comn del proceso definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos proyectos del software, con la independencia de su tamao o complejidad. U numero de conjuntos de tareas cada uno es una coleccin de tareas de trabajo de ingeniera del software, hitos de proyectos, productos de trabajo, y puntos de garanta de calidad que permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de proteccin tales como garanta de calidad del software, gestin de configuracin del software y medicin abarcan el modelo de proceso. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso. Marco de trabajo comn del proceso Actividades del marco de trabajo Conjuntos de tareas Tareas Hitos, entregas Puntos SQA Actividades de proteccin Figura 2.2. El proceso del software.

2.7.- SOFTWARE DE ALTA CALIDAD Algunas caractersticas de calidad fundamentales en todo producto de programacin son: utilidad, claridad, confiabilidad, eficiencia y economa.

Utilidad: Que satisfaga las necesidades del usuario, ya que con frecuencia no desempean las funciones esperadas debido principalmente a una pobre comunicacin con el cliente.

Confiabilidad. Capacidad de un programa para desempear una funcin requerida bajo ciertas condiciones durante un tiempo especifico. El grado de confiabilidad deseado en un producto depende del costo de las fallas.

Claridad. Los productos de software deben ser escritos con claridad y ser fciles de entender tanto internamente como externamente, ya que las pruebas y actividades de mantenimiento consumen gran cantidad del presupuesto del proyecto.

Econmico. El producto debe ser costeable en su desarrollo, mantenimiento y uso. Un software debe operar normalmente usando menos tiempo o recursos humanos o materiales de los que se requieran antes de tenerlo.

El instituto de la ingeniera del software (CEI) ha desarrollado un modelo completo de un amplio proceso basado en un conjunto de capacidades de software y de sistemas que deben de estar presentes conforme las organizaciones alcanzan diferentes grados de capacidad y madurez.

Nivel 0: Incompleto. El rea del proceso (por ejemplo, la gestin de requisitos) an no se realiza o todava no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad. Nivel 1: Realizado. Todas las metas especficas de rea del proceso (como las defini la IMCM) han sido satisfechas. Las tareas de trabajo requeridas para producir el producto especfico han sido realizadas. Nivel 2: Administrado. Todos los criterios del nivel 1 han sido satisfechos. Adems, todo el trabajo asociado con el rea de proceso se ajusta a una poltica organizacional definida; toda la gente que ejecuta el trabajo tiene acceso a recurso adecuados para realizar su labor; los clientes estn implicados de manera activa en el rea de proceso, cuando esto se requiere; todas las tareas de trabajo y productos estn monitoreadas, controlados y revisados; y son evaluados en apego a la descripcin del proceso

Nivel 3: Definido. Todos los criterios del nivel 2 se han cumplido. Adems, el proceso est adaptado al conjunto de procesos de estndar de la organizacin, de acuerdo

con las polticas de adaptacin de esta misma, y contribuye a la informacin de los productos del trabajo, mediciones y otras mejoras del proceso para los activos del proceso organizacional. Nivel 4: Administrativo en forma cuantitativa. Todos los criterios del nivel 3 han sido cumplidos. Adems, el rea del proceso se controla y mejora mediante mediciones y evaluacin cuantitativa. Los objetivos cuantitativos para la calidad y el desempeo del proceso estn establecidos y se utilizan como un criterio para administrar el proceso. Nivel 5: Mejorado. Todos los criterios del nivel 4 han sido satisfechos. Adems, el rea del proceso se adapta y mejora mediante el uso de medios cuantitativos (estadsticos) para conocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del rea del proceso que se est considerando.

2.8.- FACTORES DE CALIDAD Y PRODUCTIVIDAD PROCESO DEL SOFTWARE PERSONAL (PSP) Cada desarrollador usa distintos procesos para construir un software, estos pueden ser no eficientes o exitosos o tambin pueden cambiar a diario, pero existe un proceso. WATTS HUMPHREY dice que para cambiar un proceso inefectivo se tiene que pasar por cuatro fases y estas requieren capacitacin e instrumentacin. PSP resalto la medida personal al profesional de la planeacin, tambin hace responsables al profesional de la planeacin del proyecto y la calidad de todos los productos. Existen 5 actividades de marco de trabajo que son: 1. Planeacin: Aqu se selecciona los requisitos y se desarrolla el tamao y la estimacin de los recursos. Estas mediciones se anotan en las plantillas y al final se identifican las tareas de desarrollo y se crea un programa del proyecto. 2. Diseo de alto nivel: Se analizan los factores externos y se construyen prototipos cuando hay incertidumbre. 3. Revisin del diseo de alto nivel: Se aplican los mtodos de verificacin a los errores que se descubrieran en el diseo. 4. Desarrollo: Se refina y revisa el diseo y se verifica el cdigo y se compila, adems todas las mediciones se guardan para los resultados de trabajo. 5. Anlisis de resultados: Aqu se determina la efectividad del proceso, analizando todos los datos que se tienen. El PSP destaca que cada ingeniero tiene la necesidad de identificar los errores y de entender la importancia y los tipos de errores que suelen cometerse.

UNIDAD 3 PARADIGMAS DE LA INGENIERIA DEL SOFTWARE 3.1.- EL ENFOQUE ESTRUCTURADO

3.1.1.- DIAGRAMAS DE FLUJOS DE DATOS El DFD (Data Flow Diagram) surgi de la necesidad de un nuevo mtodo de especificacin sencillo de implantar, fcil comprensin y comunicacin. El DFD fue desarrollado por De Marco en los aos 70s y fue popularizado por Yourdan. Es un mtodo de especificacin utilizado hasta la fecha. Para empezar se puede preguntar Que son los diagramas de flujos de Datos? Un diagrama de flujo de datos (DFD) es una representacin grfica de los procesos que se realizan con los datos en su organizacin, con el uso de tan solo cuatro smbolos, se puede crear una descripcin grafica de los procesos que, con el tiempo, contribuirn a desarrollar una slida documentacin del sistema. En seguida mencionan las ventajas sobre las explicaciones descriptivas en relacin con la forma en que los datos se mueven a travs del sistema: 1. Libertad para emprender la implementacin tcnica del sistema en las primeras etapas. 2. Comprensin ms profunda de la interrelacin entre sistemas y subsistemas. 3. Comunicacin con los usuarios sobre el conocimiento del sistema actual mediante diagramas de flujos de datos. 4. Anlisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. La ventaja ms grande es la libertad conceptual para utilizar los cuatro smbolos, los DFDs hacen nfasis en el procesamiento o la transformacin conforme estos pasan por una variedad de procesos. En los DFDs lgicos no hay distincin entre procesos manuales o automatizados. Los procesos tampoco se representan grficamente en orden cronolgico. En vez de ello, se agrupan solo si el anlisis detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y los procesos automatizados tambin se pueden agrupar. Simbologa En los diagramas de flujos de datos se usan cuatro smbolos bsicos para graficar el movimiento de los datos: Un cuadrado doble, una flecha, un rectngulo con esquinas redondeadas(o una burbuja) y un rectngulo abierto (cerrado en el lado izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 a continuacin. Con la combinacin de estos cuatro smbolos se puede describir grficamente un sistema completo y varios subsistemas.

El cuadrado doble se usa para describir una entidad externa (otro departamento, un negocio, una persona o una maquina) que puede enviar datos al sistema o recibirlos de el. La entidad externa, o solo entidad, tambin se llama origen o destino de datos, y se considera externa al sistema descrito. A cada entidad se le asigna un nombre adecuado. Aunque interacta con el sistema, se considera fuera de los lmites de este. La misma entidad se podra usar ms de una vez en un diagrama de flujo de datos en particular para evitar que las lneas se crucen en el flujo de datos. La flecha muestra el movimiento de los datos de un punto a otro, con la punta de la flecha sealando hacia el destino de los datos. Los flujos de datos que ocurren simultneamente se pueden describir mediante flechas paralelas. Una flecha tambin puede se debe describir con un nombre, debido a que representan los datos de un apersona, lugar o cosa. Rectngulo con esquinas redondeadas se usa para mostrar la presencia de un proceso de transformacin. Los procesos siempre denotan un cambio en los datos o una transformacin de estos; por lo tanto el flujo de datos que sale de un proceso siempre se designa de forma diferente al que entra en el. Los procesos representan trabajo que se realiza en el tema y se deben nombrar usando uno de los formatos siguientes: Se le debe asignar un nombre claro ya que este permite reconocer fcilmente lo que hace un proceso.

1. A los procesos de alto nivel asigna el nombre del sistema. Por ejemplo: SISTEMA DE CONTROL DE VENTAS. 2. Para nombrar un subsistema principal, se usa un nombre como SUBSISTEMA DE INFORMACION DE VENTAS O SISTEMAS DE CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET. 3. Para los procesos detallados se usa un formato de sustantivo-verbo-adjetivo. El sustantivo indica cual es el resultado principal del proceso, tal como INFORME O REGISTRO. El verbo describe el tipo de actividad, tal como CALCULAR, VERIFICAR, PREPARAR, IMPRIMIR O AGREGAR. El adjetivo describe el resultado especfico que se produce tal como NUEVO PEDIDO o

INVENTARIO. Ejemplos de nombres de procesos son CALCULAR IMPUESTOS DE VENTAS, VERIFICAR ESTADOS DE CUENTA DEL CLIENTE, PREPARAR FACTURA DE ENVIO, IMPRIMIR INFORME DE NUEVOS PEDIDOS, ENVIAR CONFIRMACION AL CLIENTE POR CORREO ELECTRONICO, VERIFICAR SALDO DE TARJETA DE CREDITO Y AGREGAR REGISTRO DE INVENTARIO. A un proceso se le debe de asignar un nmero de identificacin nico y exclusivo, que indique su nivel en el diagrama. Podra haber varios flujos de datos que entren y salgan de cada proceso. Los procesos con solo un flujo de entrada y salida se deben examinar en busca de flujos de datos perdidos.

El rectngulo abierto representa un almacn de datos. Estos smbolos se dibujan con el espacio suficiente para que quepan las letras de identificacin como se muestra en la figura. En los diagramas de flujo de datos lgicos no se especifica el tipo de almacenamiento a un lugar. En este punto el smbolo del almacn de datos simplemente muestra un lugar de depsito para los datos que permite examinar, agregar y recuperar datos. El almacn de datos podra representar un almacn manual, tal como un gabinete de archivo, un archivo o una base de datos de computadora. A los almacenes de datos se les asigna un nombre debido a que representan a una persona, lugar o cosa. Los almacenes de datos temporales, tales como papel borrador o un archivo temporal de computadora, no se incluyen en el diagrama de flujo de datos. Para identificar el nivel del almacn de datos, a cada uno asgnele un nmero de referencia nica, tal como D1, D2, D3 etc.

Desarrollo de diagramas de flujos de datos Los diagramas de flujos de datos se pueden y deben dibujar de manera sistemtica. Primero se deben visualizar los flujos de datos desde una perspectiva jerrquica de arriba a bajo. En seguida se describen los pasos a seguir. Lista de actividades Para empezar un diagrama de flujo de datos, se debe sintetizar la narrativa(o historia) del sistema de la organizacin en una lista con las cuatro categoras de entidad externa, flujo de datos, procesos, y almacn de datos. Esta lista a su vez ayudara a determinar los lmites del sistema que describir. Una vez que se haya recopilado una lista bsica de elementos de datos se empieza a dibujar el diagrama de contexto. Creacin de diagrama de contexto Con un enfoque jerrquico de arriba hacia abajo para diagramar el movimiento de los datos, los diagramas van de lo general a lo especfico. Aunque el primer diagrama ayuda a entender el movimiento bsico de los datos, lo general de su naturaleza limita su utilidad. El diagrama de contexto inicial debe de mostrar un panorama global que incluya las entradas bsicas, el sistema general y las salidas. Este diagrama ser el mas general, con una visin muy superficial del movimiento de los datos en el sistema y una visualizacin lo mas amplia posible del sistema. El diagrama de contexto es el nivel ms alto en un diagrama de flujo de datos y contiene un solo proceso, que representa a todo el sistema. Al proceso se le asigna el numero cero. En este diagrama se muestran todas las entidades externas, as como los flujos de datos principales que van desde y hacia dichas entidades. El diagrama no contiene ningn almacn de datos. Es bastante simple la creacin ya que se conocen las entidades externas y el flujo de datos desde y hacia ellas. Dibujo del diagrama 0 (el siguiente nivel) Al ampliar los programas se puede lograr un mayor detalle que con los diagramas de contexto. Las entradas y salidas especificadas en el primer diagrama permanecen constantes en todos los diagramas que le siguen. Sin embargo, el resto del diagrama original se amplia para incluir de tres a nueve procesos y mostrar almacenes de datos y nuevos flujos de datos de menor nivel. Cada diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs para representar subprocesos, en este paso se empiezan a completar los detalles del movimiento

de los datos. El manejo de excepciones se ignora en los primero dos o tres niveles del diagrama de flujo de datos.

El diagrama cero es la ampliacin del diagrama de contexto y puede incluir hasta nueve procesos, esto se hace porque si se agregan ms procesos producir un diagrama difcil de entender. Por lo general, cada proceso se numero con un entero, empezando en la esquina superior izquierda del diagrama y terminando en la esquina inferior derecha. En el diagrama cero se incluyen los principales almacenes de datos del sistema (que representan a los archivos maestros) y todas las entidades externas. La figura 3.2 representa grficamente el diagrama de contexto y el diagrama cero. Debido a que un diagrama de flujo de datos es bidimensional (en lugar de lineal), se puede empezar en cualquier punto del diagrama e ir hacia delante o hacia atrs. Si no esta seguro de lo que podra incluir en cualquier punto, tome una entidad externa, un proceso o un almacn de datos diferente y empiece a dibujar el flujo a partir de l: 1. Empezamos con el flujo de datos de una entidad en el lado de la entrada. Se hacen preguntas como: Qu sucede con los datos que entran en el sistema? Se almacenan? Esta entrada es para varios procesos?

2. Trabajamos hacia atrs a partir de un flujo de datos de salida. Examinamos los campos de salida de un documento o pantalla. (Este enfoque es ms sencillo si se han creado prototipos.) Se pregunta sobre cada campo de la salida: "De dnde viene?" o "Se calcula o almacena en un archivo?" Por ejemplo, cuando la salida es un RECIBO DE NOMINA, el NOMBRE DEL EMPLEADO y la DIRECCION se podran localizar en un archivo EMPLEADO, las HORAS TRABAJADAS podran encontrarse en un REGISTRO DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se tendran que calcular. Cada archivo y registro estara conectado al proceso que produce el recibo de nmina. 3. Examinamos el flujo de datos desde o hacia un almacn de datos. Se pregunta: "Qu procesos ponen los datos en el almacn?" o "Qu procesos usan los datos?" Observamos que un almacn de datos utilizado en el sistema en el que se esta trabajando podra ser producido por un sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya ningn flujo de datos hacia el almacn de datos. 4. Analizamos un proceso bien definido. Vea qu entrada de datos necesita el proceso y qu salida produce. Se hace un vnculo la entrada y la salida con los almacenes de datos y las entidades adecuadas. 5. Tome nota de cualquier rea confusa en donde no est seguro de lo que se debe incluir o de la entrada o la salida que se requiera. Al conocer las reas problemticas podr realizar una lista de preguntas para las entrevistas de seguimiento con los usuarios clave.

Creacin de diagramas hijos (niveles ms detallados) Cada proceso del Diagrama cero se puede, a su vez, ampliar para crear un diagrama hijo ms detallado. El proceso del Diagrama cero a partir del cual se realiza la ampliacin se llama proceso padre, y el diagrama que se produce se llama diagrama hijo. La regla principal para crear diagramas hijos, es el equilibrio vertical, estipula que un diagrama hijo no puede producir salida o no puede recibir entrada que el proceso padre no produzca o reciba tambin. Todos los flujos de datos hacia dentro o hacia fuera del proceso padre se deben mostrar fluyendo hacia dentro o hacia fuera del diagrama hijo. Al diagrama hijo se le asigna el mismo numero que a su proceso padre en el Diagrama cero. Los procesos del diagrama hijo se numeran usando el numero del proceso padre, un punto decimal y un solo numero para cado proceso hijo. Con esto se puede localizar una serie de

procesos a travs de muchos niveles de ampliacin. Si el diagrama cero presenta los procesos 1, 2 y 3 los diagramas hijos 1, 2 y 3 estarn en el mismo nivel. Por lo regular las entidades no se muestran en los diagramas hijos debajo del diagrama cero. El flujo de datos que coincide con el flujo padre se llama flujo de datos de interfaz y se representa con una flecha que parte de un rea vaca del diagrama hijo. Si el proceso padre tiene un flujo de datos conectado a un almacn de datos, tambin el diagrama hijo podra incluir el almacn de datos. Adems, este diagrama de nivel inferior podra contener almacenes de datos que no se muestran en el proceso padre. Por ejemplo se podran incluir un archivo que contenga una tabla de informacin, como una tabla de impuestos, o un archivo que conecta dos procesos del diagrama hijo. En un diagrama hijo se podran incluir un flujo de datos de nivel inferior, como una lnea de error, aunque no se podra hacer lo mismo en el proceso padre. Los procesos se podran ampliar o no ampliar, dependiendo de su nivel de complejidad. Cuando no se amplia un proceso, se dice que es funcionalmente primitivo y se llama proceso primitivo. En la figura 3.3 se ilustran niveles detallados de un diagrama de flujos de datos hijo.

Revisin de Errores en lo diagramas Cuando se dibujan diagramas de flujos de datos se pueden cometer varios errores comunes como los siguientes: 1. Olvidar incluir un flujo de datos o apuntar con una flecha en la direccin incorrecta. Un ejemplo es un proceso dibujado que muestra todos sus flujos de datos como entrada o salida. Cada proceso transforma datos y debe recibir una entrada y producir una salida. Este tipo de error ocurre generalmente cuando el analista olvida incluir un flujo de datos o coloca una flecha que apunta en la direccin incorrecta. 2. Conectar directamente entre s almacenes de datos y entidades externas. Los almacenes de datos y las entidades externas no se deben conectar entre s; slo se deben conectar con un proceso. Un archivo no interacta con otro archivo sin la ayuda de un programa o una persona que mueva los datos. Las entidades externas no trabajan directamente con los archivos. Dos entidades externas conectadas directamente indican que desean comunicarse entre s. Esta conexin no se incluye en el diagrama de flujo de datos a menos que el sistema facilite la comunicacin. La elaboracin de un informe es un ejemplo de esta clase de comunicacin. Sin embargo, es necesario interponer un proceso entre las entidades para producir el informe.

3. Asignar nombres incorrectos a los procesos o al flujo de datos. Es necesario revisar el diagrama flujo de datos para asegurar que cada objeto o flujo de datos tenga un nombre adecuado. Un proceso debe indicar el nombre del sistema o usar el formato sustantivo-verbo-adjetivo. Cada flujo de datos se debe describir con un sustantivo. 4. Incluir ms de nueve procesos en un diagrama de flujo de datos. La inclusin de demasiados procesos origina un diagrama confuso difcil de entender y obstaculiza la comunicacin en lugar de facilitada. Si en un sistema existen ms de nueve procesos, agrupe en un subsistema algunos de los procesos que trabajan en conjunto y pngalos en un diagrama hijo, 5. Omitir un flujo de datos. Examine su diagrama en busca de flujo lineal, es decir, flujo de datos en el cual cada proceso tiene slo una entrada y una salida. El flujo de datos lineal no es muy comn, excepto en los diagramas de flujo de datos hijos muy detallados, su presencia normalmente indica que al diagrama le falta algn flujo de datos. 6. Crear una separacin (o ampliacin) desequilibrada en los diagramas hijos. Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida que el proceso

padre, Una excepcin a esta regla son las salida menores, como las lneas de error, que se incluyen solamente en el diagrama hijo.

En seguida se sintetizan los pasos para desarrollar eficazmente diagramas de flujo de datos, usando un enfoque jerrquico de arriba a bajo: 1. Haga una lista de las actividades del negocio y sela para determinar lo siguiente: Entidades externas Flujos de datos Procesos Almacn de datos

2. Crear un diagrama de contexto que muestre las entidades externas y los flujos de datos desde y hacia el sistema. No muestre ejemplos ni almacenes de datos detallados. 3. Dibujar el diagrama 0(el siguiente nivel). Muestre procesos, pero que sean generales. En este nivel muestre almacenes de datos. 4. Cree un diagrama hijo para cada uno de los procesos del Diagrama 0 5. Revise que no haya errores y asegrese de que sean significativos los nombres que haya asignado a cada proceso y flujo de datos. 6. Desarrolle un diagrama de flujo de datos fsico a partir del diagrama de flujo de datos lgico. Distinga entre los procesos manuales y automatizados, describa los archivos reales y los informes por nombre y agregue controles para indicar cuando se completan los procesos o cuando ocurren errores. 7. Ahora se hace una particin el diagrama de flujo de datos fsico separando o agrupando sus partes con el propsito de facilitar la programacin y la implementacin.

Particionamiento de los diagramas de flujos de datos Este es un proceso de examinar un diagrama de flujo de datos y se determina como se debe dividir en colecciones de procedimientos manuales y colecciones de programas de cmputo. Analice cada procedo para determinar si debe ser un proceso manual o automatizado. Agrupe los procedimientos automatizados en una serie de programas de cmputo. Usualmente se

traza una lnea punteada alrededor de un proceso o grupo de procesos que deben colocarse en un solo programa de cmputo. Existen seis razones para particionar diagramas de flujos de datos: 1. Diferentes grupos de usuarios. Los procesos son realizados por varios grupos de usuarios diferentes, con frecuencia en distintas ubicaciones fsicas de la compaa?. Si es as, se deben particionar en diferentes programas de cmputo. 2. Sintonizacin. En esta parte se debe examinar que los procesos se sincronicen. Si dos procesos se realizan en diferentes momentos, no se puede agrupar en un programa. 3. Tareas similares. Si dos procesos ejecutan tareas similares, es posible agruparlos en un solo programa de cmputo. 4. Eficiencia. En un programa se podra combinar varios procesos para realizar un procesamiento eficiente. 5. Consistencia de los datos. Los procesos se podran combinar en un solo programa para mantener la consistencia de los datos. 6. Seguridad. Los procesos se podran particionar en diferentes programas por razones de seguridad.

3.1.2. DICCIONARIO DE DATOS El diccionario de datos surge de la necesidad de catalogar los procesos, flujos almacenes estructuras y elementos de datos. Los nombres que se usan son muy importantes. Cuando se tiene la oportunidad de asignar nombre a los componentes de los sistemas orientados a datos, es necesario trabajar en la creacin de un nombre significativo pero diferente al de otros componentes de datos existentes. Se ha propuesto el diccionario de datos como gramtica casi formal para describir el contenido de los objetos definidos durante el anlisis estructurado. Esta notacin ha sido definida de la siguiente forma por Yourdon en 1989: El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tenga una misma comprensin de las entradas, salidas, de los componentes de los almacenes y tambin los clculos intermedios. [2]

Muchos sistemas de administracin de base de datos estn equipados con un diccionario de datos automatizado. Estos diccionarios pueden ser complejos o sencillos, algunos diccionarios de datos computarizados catalogan automticamente los elementos de datos cuando se hace la programacin; otros simplemente proporcionan una plantilla para motivar a la persona que llene el diccionario a que lo haga de una manera uniforme para cada entrada. A pesar de la existencia de los diccionarios de datos automatizados, entender qu datos conforman un diccionario de datos, las convenciones usadas en estos ltimos y cmo se desarrolla un diccionario de datos, son problemas que el analista de sistemas debe tener siempre presentes durante el esfuerzo de sistemas. Entender el proceso de compilar un diccionario de datos puede ayudar al analista de sistemas a visualizar el sistema y su funcionamiento. Adems de proporcionar documentacin y eliminar la redundancia, el diccionario datos se podra usar para: 1. Validar la integridad y exactitud del diagrama de flujo de datos. 2. Proporcionar un punto de partida para desarrollar pantallas e informes, 3. Determinar el contenido de los datos almacenados en archivos. 4. Desarrollar la lgica para los procesos del diagrama de flujo de datos,

3.1.2.1 Depsito de datos Aunque el diccionario de datos contiene informacin de los datos y procedimientos, una coleccin ms grande de informacin de proyectos se llama depsito, El concepto depsito es uno de los muchos impactos de las herramientas CASE y podra contener lo siguiente: 1. Informacin sobre los datos mantenidos por el sistema, incluyendo flujos de datos, almacenes de datos, estructuras de registros y elementos. 2. Lgica de procedimientos. 3. Diseo de pantallas e informes. 4. Relaciones entre datos, por ejemplo cmo se vincula una estructura de datos con otra. 5. Requerimientos del proyecto y productos del sistema final. 6. Informacin sobre la administracin del proyecto, tal como itinerarios de entrega," problemas pendientes de solucin y usuarios del proyecto.

Por lo general, los flujos de datos son los primeros elementos que se definen. Las entradas y salidas del sistema se determinan mediante las entrevistas y la observacin de los usuarios, y el anlisis de documentos y de otros sistemas existentes. La informacin capturada se puede resumir usando un formulario que contenga la siguiente informacin: 1. ID, un numero de identificacin opcional. A veces este se codifica usando un esquema para identificar el sistema y la aplicacin del sistema. 2. Un solo nombre descriptivo para este flujo de datos. Este nombre es el texto que debe aparecer en el diagrama y se debe referenciar en todas las descripciones que usen el flujo de datos. 3. Un a descripcin general del flujo de datos. 4. La fuente del flujo de datos. Esta podra ser una entidad externa, un proceso o influjo de datos proveniente de un almacn de datos. 5. El destino del flujo de datos. Esta podra ser una entidad externa, un proceso o influjo de datos proveniente de un almacn de datos. 6. Algo que indique si el flujo de datos es un registro que esta entrando o saliendo de un archivo o un registro que contiene un informe, formulario o pantalla. Si el flujo de datos contiene datos que se usan entre los procesos, se designa como interno. 7. El nombre de la estructura de datos que describe los elementos encontrados en este flujo de datos. Para un flujo de datos simple, podran ser uno o varios elementos. 8. el volumen por unidad de tiempo. Los datos podran ser registros por da o cualquier otra unidad de tiempo. 9. Un rea para comentarios adicionales y anotaciones sobre el flujo de datos.

Descripcin de las estructuras de datos Normalmente las estructuras de datos se describen usando una notacin algebraica. Este mtodo permite al analista producir la vista de los elementos que constituyen la estructura de datos junto con informacin referente a dichos elementos. La notacin algebraica usa los siguientes smbolos: 1. Un signo de igual (=) significa esta compuesto de. 2. Un signo de suma (+) significa y. 3. Las llaves { } indican elementos repetitivos, tambin llamados grupos de repeticin o tablas. En el grupo podra haber un elemento de repeticin o varios de ellos. El grupo

de repeticin podra tener condiciones, tal como un nmero fijo de repeticiones o limites superiores e inferiores para el nmero de repeticiones. 4. Los corchetes [ ] representan una situacin de uno u otro. Se podra representar un elemento u otro, pero no ambos. Los elementos listados entre los corchetes son mutuamente excluyentes. 5. Los parntesis ( ) representan un elemento opcional. Los elementos opcionales se podran dejar en blanco en la entrada de las pantallas y podran contener espacios o ceros para campos numricos en las estructuras de archivos.

Estructuras de datos Lgicas y Fsicas Cuando son definidas las estructuras de datos por primera vez, slo son incluidos los elementos de datos que el usuario podr ver, tales como nombre, direccin y saldo. Esta etapa es el diseo lgico, mostrando cules datos necesita el negocio para su operacin diaria. Usando diseo lgico como base, el analista disea luego las estructuras de datos fsicas. Estas incluyen elementos adicionales para la implementacin del sistema. Ejemplos de elementos de diseo fsico: 1. 2. Campos clave usados para localizar registros en una base de datos Cdigos para identificar el estado de registros maestros. Estos cdigos se pueden mantener en archivos que generen informacin de impuestos. 3. Los cdigos de transaccin son utilizados para identificar tipos de registros cuando un archivo contiene tipos de registros diferentes. 4. Las entradas de grupos repetidos contienen un contador sobre qu tantos conceptos hay en el grupo. 5. 6. Lmites sobre la cantidad de conceptos aceptables en un grupo repetido. Una contrasea usada por un cliente que accede a un sitio web seguro.

Elementos de datos Cada elemento de datos se debe definir una vez en el diccionario de datos y tambin se podra introducir previamente en un formulario de descripcin del elemento. Caractersticas de un formulario de descripcin de elementos:

1.

ID del elemento. Esta entrada opcional permite construcciones entradas de diccionario de datos

2.

El nombre del elemento. El nombre debe ser descriptivo, nico y basado en el propsito al cual esta destinado el elemento en la mayora de los programas o por el usuario principal del elemento.

3. 4. 5.

Alias, son sinnimos u otros nombres para el elemento. Una descripcin breve del elemento Si el elemento es base o derivado. Elemento base es el que se teclea inicialmente en el sistema, nombre del cliente direccin o ciudad; se deben almacenar en archivos. Los elementos derivados son creados por procesos como resultado de clculo.

6.

La longitud del elemento. Algunos elementos tienen longitudes estndar y otras veces pueden variar para otros elementos, aqu se debe decidir en conjunto con el usuario la longitud final.

7.

El tipo de datos: numrico, fecha, alfabtico o carcter que a veces se llama datos alfanumricos o de texto.

8.

Los formatos de entrada y salida se deben incluir, usando smbolos de codificacin especiales para indicar como se deben presentar los datos.

9.

Los criterios de validacin para asegurar que el sistema capture los datos correctos. Los elementos pueden ser discretos, lo cual significa que tiene ciertos valores fijos o continuos, con un rango parejo de valores.

10.

Cualquier valor predeterminado que pudiera tener el elemento. El valor predeterminado se despliega en las pantallas de entrada y se usa para reducir la cantidad de datos que tuviera que teclear el operador.

11.

Un rea adicional para observaciones o comentarios.

Almacenes de datos Todos lo elementos base se deben almacenar en el sistema. Tambin los elementos derivados se podran almacenar en el sistema, tal como, para un empleado, el sueldo bruto acumulado a la fecha. Los almacenes de datos se crean, cuando los elementos base de un flujo de datos se agrupan para formar un registro estructural, se crea un almacn de datos para cada registro estructural nico.

3.1.2.2 Creacin del diccionario de datos Las entradas del diccionario de datos se podran crear despus de completar el diagrama de flujo de datos, o se podran construir conforme se desarrolle el diagrama de flujo de datos. El uso de notacin algebraica y registros estructurales permite desarrollar el diccionario de datos y los diagramas de flujos de datos mediante un enfoque jerrquico de arriba a bajo. Despus de realizar varias entrevistas adicionales para descubrir los detalles del sistema, se puede extender el diagrama de flujo de datos y se crearan los diagramas hijos. Posteriormente se modifica el diccionario de datos para incluir los nuevos registros estructurales y elementos recabados en las entrevistas, observacin y anlisis de documentos posteriores. Cada nivel de un diagrama de flujo de datos debe usar datos adecuados para el nivel. El diagrama 0 debe incluir nicamente formularios, pantallas informes y registros. Conforme se creen los diagramas hijos, el flujo de datos que entre y salga de los procesos ser cada vez mas detallado, incluyendo los registros estructurales y los elementos.

Anlisis de las entradas y salidas Un paso importante en la creacin del diccionario de datos es identificar y categorizar el flujo de datos de entrada y salida del sistema. Campos comnmente incluidos: 1. Nombre descriptivo para la entrada o la salida. Si el flujo de datos esta en un diagrama lgico, el nombre debe identificar el propsito de los datos. 2. El contacto del usuario responsable para la clarificacin de detalles adicionales, retroalimentacin del diseo y aprobacin final 3. Si los datos son de entrada o salida 4. El formato de flujo de datos. En la fase del diseo lgico, el formato podra ser indeterminado. 5. Elementos que indican la secuencia de los datos en un informe o pantalla. 6. Una lista de elementos, incluyendo sus nombres, longitudes y si son base o derivados y sus criterios de edicin.

Desarrollo de almacenes de datos Otra actividad es el desarrollo de los almacenes de datos. Esta informacin se describe en estructuras de datos. Sin embargo la informacin podra estar almacenada en diferentes lugares, y el almacn de datos podra ser diferente en cada lugar. Mientras que los flujos de datos representan datos en movimiento, los almacenes de datos representan datos en reposo. Los almacenes de datos contienen informacin de una naturaleza permanente o semipermanente. Cuando los almacenes de datos se crean para un solo informe o pantalla nos referimos a ellos como vistas del usuario, porque representan la manera en que el usuario quiere ver la informacin.

Uso del diccionario de datos El diccionario de datos ideal es automatizado, interactivo, en lnea y evolutivo. Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la organizacin, se agregan elementos de datos al diccionario de datos. El diccionario de datos no es un fin en si mismo y nunca debe serlo, siempre debe verse como una actividad paralela al anlisis y diseo de sistemas. El diccionario de datos debe vincular a varios programas de sistemas para que cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo mismo en la base de datos. El diccionario de datos se vuelve una curiosidad histrica sino se mantiene actualizado.

3.1.3 DISEO DE MODULOS El concepto de modularidad se ha ido exponiendo desde hace casi cinco dcadas en el software de computadora. La arquitectura de computadora expresa la modularidad; es decir, el software se divide en componentes nombrados y abordados por separado, llamados frecuentemente mdulos, que se integran para satisfacer los requisitos del problema. Se ha afirmado que La modularidad es el nico atributo del software que permite gestionar un programa intelectualmente. El software monoltico (es decir, un programa grande formado por un nico modulo) no puede ser entendido fcilmente por el lector. La cantidad de rutas de control, la amplitud de referencias, la cantidad de variables y la complejidad global

har que el entendimiento este muy cerca de ser imposible. Para ilustrar este punto, tomemos en consideracin el siguiente argumento basado en observaciones humanas sobre la resolucin de problemas. Pensemos que C(x) es una funcin que define la complejidad percibida de un problema x, y que E(x) es una funcin que define el esfuerzo (oportuno) que se requiere para resolver un problema x. para dos problemas p1 y p2, si

C(p1) > C(p2) Implica que E(p1) > E(p2)

(3.1a)

(3.1b)

En general, este resultado es por intuicin obvio. Se tarda ms en resolver un problema difcil. Mediante la experimentacin humana en la resolucin de problemas se ha averiguado otra caracterstica interesante. Esta es,

C(p1 + p2) > C(p1) + C(p2) (3.2)

La ecuacin 3.2 implica que la complejidad percibida de un problema que combina p1 y p2, es mayor que la complejidad percibida cuando se considera cada problema por separado. Teniendo en cuenta la ecuacin (3.2) y la condicin implicada por la ecuacin (3.1) se establece que

E(p1 + p2) > E(p1) + E(p2) (3.3)

Esto lleva a una conclusin: divide y vencers es ms fcil resolver un problema complejo cuando se rompe en piezas manejables. El resultado expresado en la ecuacin 3.3 implica que

es importante en lo que respecta a la modularidad y al software. Es, de hecho, un argumento para la modularidad. Es posible concluir de la ecuacin (3.3) que si subdividimos el software indefinidamente, el esfuerzo que se requiere para desarrollarlo sera mnimo. Desgraciadamente, intervienen otras fuerzas, que hacen que esta conclusin sea (tristemente) falsa. Como muestra la figura 3.4, el esfuerzo (costo) para desarrollar un mdulo software individual disminuye a medida que aumenta el nmero total de mdulos. Dado el mismo conjunto de requisitos: tener ms mdulos conduce a un tamao menor de mdulo. Sin embargo, a medida que aumenta el nmero de mdulos, tambin crece el esfuerzo (costo) asociado con la integracin de mdulos. Estas caractersticas conducen tambin a la curva total del costo o esfuerzo que se muestra en la figura. Existe un nmero M de mdulos que dara como resultado un costo mnimo de desarrollo, aunque no tenemos la sofisticacin necesaria para predecir M con seguridad.

Las curvas de la Figura 3.4 proporcionan en efecto una gua til cuando se tiene en consideracin la modularidad. La modularidad deber aplicarse, pero teniendo cuidado de estar prximo a M. Se deber evitar modularizar de ms o de menos. Cuando se tiene en consideracin la modularidad surge otra pregunta importante. Cmo se define un modulo con un tamao adecuado? La respuesta se, encuentra en los mtodos utilizados para definir los mdulos dentro de un sistema. Meyer define cinco criterios que nos permitirn evaluar un mtodo de diseo en relacin con la habilidad de definir un sistema modular efectivo:

Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un mecanismo sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el problema, consiguiendo de esta manera una solucin modular efectiva.

Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin modular que no inventa nada ya inventado.

Capacidad de comprensin modular. Si un mdulo se puede comprender como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar.

Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de los efectos secundarios de los cambios.

Proteccin modular. Si dentro de un mdulo se produce una condicin absurda y sus efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los errores.

Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso aunque su implementacin deba ser monoltica. Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan sobrecargas de memoria y de velocidad por mnimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podr y deber disearse con modularidad como filosofa predominante. El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los beneficios de un sistema modular.

3.1.3.1 Diseo Modular Efectivo La modularidad se ha convertido en un enfoque aceptado en todas las disciplinas de ingeniera. Un diseo modular reduce la complejidad, facilita los cambios (un aspecto crtico de la capacidad de mantenimiento del software), y da como resultado una implementacin ms fcil al fomentar el desarrollo paralelo de las diferentes partes de un sistema.

El concepto de independencia funcional es la suma de la modularidad y de los conceptos de abstraccin y ocultacin de informacin. En referencias obligadas sobre el diseo del software, Pamas y Wirth sugieren a las tcnicas de refinamiento que mejoran la independencia de mdulos. Trabajos posteriores de Stevens, Wyers y Constantine consolidaron el concepto. La independencia funcional se consigue desarrollando mdulos con una funcin determinante y una aversin a una interaccin excesiva con otros mdulos. Es necesario disear el software de manera que cada mdulo trate una subfuncin de requisitos y tenga una interfaz sencilla cuando se observa desde otras partes de la estructura del programa. Por qu es importante la independencia? El software con una modularidad efectiva, es decir, mdulos independientes, es ms fcil de desarrollar porque la funcin se puede compartimentar y las interfaces se simplifican (tengamos en consideracin las ramificaciones cuando el desarrollo se hace en equipo). Los mdulos independientes son ms fciles de mantener (y probar) porque se limitan los efectos secundarios originados por modificaciones de diseo/cdigo; porque se reduce la propagacin de errores; y porque es posible utilizar mdulos usables. En resumen, la independencia funcional es la clave para un buen diseo y el diseo es la clave para la calidad del software. La independencia se mide mediante dos criterios cualitativos: la cohesin y el acoplamiento. La cohesin es una medida de la fuerza relativa funcional de un mdulo. El acoplamiento es una medida de la independencia relativa entre los mdulos. 3.1.3.2 Cohesin La cohesin es una extensin natural del concepto de ocultacin de informacin (la informacin que esta dentro de un modulo debe ser inaccesible a otros mdulos que no necesiten esa informacin). Un mdulo cohesivo lleva a cabo una sola tarea dentro de un procedimiento de software, lo cual requiere poca interaccin con los procedimientos que se llevan a cabo en otras partes de un programa. Dicho de manera sencilla, un mdulo cohesivo deber (idealmente) hacer una sola cosa. La cohesin se puede representar como un espectro. Siempre debemos buscar la cohesin ms alta, aunque la parte media del espectro suele ser aceptable. La escala de cohesin no es lineal. Es decir, la parte baja de la cohesin es mucho peor que el rango medio, que es casi tan bueno como la parte alta de la escala. En la prctica, un diseador no tiene que

preocuparse de categorizar la cohesin en un mdulo especfico. Ms bien, se deber entender el concepto global, y as se debern evitar los niveles bajos de cohesin al disear los cdigos. .1.3.2.1 Niveles de cohesin Cohesin Casual o Coincidental La cohesin casual ocurre cuando existe poca o ninguna relacin entre los elementos de un mdulo. La cohesin casual establece un punto cero en la escala de cohesin. Es muy difcil encontrar mdulos puramente casuales. Puede aparecer como resultado de la modularizacin de un programa ya escrito, en el cual el programador encuentra un determinada secuencia de instrucciones que se repiten de forma aleatoria, y decide por lo tanto agruparlas en una rutina. Otro factor que influenci muchas veces la confeccin de mdulos casualmente cohesivos, fue la mala prctica de la programacin estructurada, cuando los programadores mal entendan que modularizar consista en cambiar las sentencias GOTO por llamadas a subrutinas Finalmente diremos que si bien en la prctica es difcil encontrar mdulos casualmente cohesivos en su totalidad, es comn que tengan elementos casualmente cohesivos. Tal es el caso de operaciones de inicializacin y terminacin que son puestas juntas en un mdulo superior. Debemos notar que si bien la cohesin casual no es necesariamente perjudicial (de hecho es preferible un programa casualmente cohesivo a uno lineal), dificulta las modificaciones y mantenimiento del cdigo.

Cohesin Lgica Los elementos de un mdulo estn lgicamente asociados si puede pensarse en ellos como elementos que pertenecen a la misma clase lgica de funciones, es decir aquellas que pueden pensarse como lgicamente juntas. Por ejemplo, se puede combinar en un mdulo simple todos los elementos de procesamiento que caen en la clase de "entradas", que abarca todas las operaciones de entrada. Podemos tener un mdulo que lea desde consola una tarjeta con parmetros de control, registros con

transacciones errneas de un archivo en cinta, registros con transacciones vlidas de otro archivo en cinta, y los registros maestros anteriores de un archivo en disco. Este mdulo que podra llamarse "Lecturas", y que agrupa todas las operaciones de entrada, es lgicamente cohesivo. La cohesin lgica es ms fuerte que la casual, debido a que representa un mnimo de asociacin entre el problema y los elementos del mdulo. Sin embargo podemos ver que un mdulo lgicamente cohesivo no realiza una funcin especfica, sino que abarca una serie de funciones.

Cohesin Temporal Cohesin Temporal significa que todos los elementos de procesamiento de una coleccin ocurren en el mismo perodo de tiempo durante la ejecucin del sistema. Debido a que dicho procesamiento debe o puede realizarse en el mismo perodo de tiempo, los elementos asociados temporalmente pueden combinarse en un nico mdulo que los ejecute a la misma vez. Existe una relacin entre cohesin lgica y la temporal, sin embargo, la primera no implica una relacin de tiempo entre los elementos de procesamiento. La cohesin temporal es ms fuerte que la cohesin lgica, ya que implica un nivel de relacin ms: el factor tiempo. Si embargo la cohesin temporal an es pobre en nivel de cohesin y acarrea inconvenientes en el mantenimiento y modificacin del sistema. Un ejemplo comn de cohesin temporal son las rutinas de inicializacin (start-up) comnmente encontradas en la mayora de los programas, donde se leen parmetros de control, se abren archivos, se inicializan variables contadores y acumuladores, etc.

Cohesin de Procedimiento Elementos de procesamiento relacionados procedimentalmente son elementos de una unidad procedimental comn. Estos se combinan en un mdulo de cohesin procedimental que implica una secuencia de ejecucin de los pasos. Una unidad procedimental comn puede ser un proceso de iteracin (loop) y de decisin, o una secuencia lineal de pasos. En este ltimo caso

la cohesin es baja y es similar a la cohesin temporal, con la diferencia que la cohesin temporal no implica una determinada secuencia de ejecucin de los pasos. Al igual que en los casos anteriores, para decir que un mdulo tiene solo cohesin procedimental, los elementos de procesamiento deben ser elementos de alguna iteracin, decisin, o secuencia, pero no deben estar vinculados con ningn principio asociativo de orden superior. La cohesin procedimental asocia elementos de procesamiento sobre la base de sus relaciones algortmicas o procedimentales. Este nivel de cohesin comnmente se tiene como resultado de derivar una estructura modular a partir de modelos de procedimiento como ser diagramas de flujo, o diagramas Nassi-Shneiderman.

Cohesin de Comunicacin Ninguno de los niveles anteriores est fuertemente vinculado a una estructura de problema en particular. Cohesin de Comunicacin es el menor nivel en el cual se encuentra una relacin entre los elementos de procesamiento que es especficamente dependiente del problema.

Decir que un conjunto de elementos de procesamiento estn vinculados por comunicacin significa que todos los elementos operan sobre el mismo conjunto de datos de entrada o de salida.

En el diagrama de la figura 3.5 podemos observar que los elementos de procesamiento a, b, y c, estn asociados por comunicacin sobre la corriente de datos de entrada, en tanto que b, c, y d se vinculan por los datos de salida. Los diagramas de flujo de datos (DFD) son un medio objetivo para determinar si los elementos en un mdulo estn asociados por comunicacin. Las relaciones por comunicacin presentan un grado de cohesin aceptable. La cohesin por comunicacin es comn en aplicaciones comerciales. Algunos ejemplos pueden ser: un mdulo que imprima o grabe un archivo de transacciones; un mdulo que reciba datos de diferentes fuentes, y los transforme y ensamble en una lnea de impresin.

Cohesin Secuencial En este nivel de cohesin, los datos de salida (resultados) de un elemento de procesamiento sirven como datos de entrada al siguiente elemento de procesamiento. En trminos de un diagrama de flujo de datos de un problema, la cohesin secuencial combina una cadena linear de sucesivas transformaciones de datos. Este es claramente un principio asociativo relacionado con el dominio del problema.

Cohesin Funcional En el lmite superior del espectro de relacin funcional encontramos la cohesin funcional. En un mdulo completamente funcional, cada elemento de procesamiento, es parte integral de, y esencial para, la realizacin de una funcin simple. En trminos prcticos podemos decir que cohesin funcional es aquella que no es secuencial, por comunicacin, por procedimiento, temporal, lgica, o casual. Los ejemplos ms claros y comprensibles provienen del campo de las matemticas. Un mdulo para realizar el clculo de raz cuadrada ciertamente ser altamente cohesivo, y probablemente, completamente funcional. No es probable que haya elementos superfluos ms all de los absolutamente esenciales para realizar la funcin matemtica, y no es probable que elementos de procesamiento puedan ser agregados sin alterar el clculo de alguna forma.

En contraste un mdulo que calcule raz cuadrada y coseno, es improbable que sea enteramente funcional (deben realizarse dos funciones ambiguas). En adicin a estos ejemplos matemticos obvios, usualmente podemos reconocer mdulos funcionales que son elementales en naturaleza. Un mdulo llamado LEER-REGISTROMAESTRO, o TRATAR-TRANS-TIPO3, presumiblemente sern funcionalmente cohesivos, en cambio TRATAR-TODAS-TRANS presumiblemente realizar ms de una funcin y ser lgicamente cohesivo. Llegamos a la conclusin que no es necesario determinar el nivel preciso de cohesin. Ms bien, es importante intentar conseguir una cohesin alta y reconocer cuando hay poca cohesin para modificar el diseo del software y conseguir una mayor independencia funcional.

3.1.3.3 Acoplamiento El acoplamiento es una medida de interconexin entre mdulos dentro de una estructura de software. El acoplamiento depende de la complejidad de interconexin entre los mdulos, el punto donde se realiza una entrada o referencia a un mdulo, y los datos que pasan a travs de la interfaz. Los cuatro factores principales que influyen en el acoplamiento entre mdulos son: Tipo de conexin entre mdulos: Los sistemas normalmente conectados, tienen menor acoplamiento que aquellos que tienen conexiones patolgicas. Complejidad de la interfaz: Esto es aproximadamente igual al nmero de producto diferentes pasados (no cantidad de datos). Ms producto, mayor acoplamiento. Tipo de flujo de informacin en la conexin: los sistemas con acoplamiento de datos tienen menor acoplamiento que los sistemas con acoplamiento de control, y estos a su vez menos que los que tienen acoplamiento hbrido. Momento en que se produce el ligado de la Conexin: Conexiones ligadas a referentes fijos en tiempo de ejecucin, resultan con menor acoplamiento que cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su ver menor acoplamiento que cuando el ligado se realiza en tiempo de linkage-edicin, el cual tiene menos acoplamiento que el que se realiza realiza en tiempo de compilacin, todos los que a su vez tiene menos

acoplamiento que cuando el ligado se realiza en tiempo de codificacin.

En el diseo del software, intentamos conseguir el acoplamiento ms bajo posible. Una conectividad sencilla entre los mdulos da como resultado un software ms fcil de entender y menos propenso a tener un efecto ola causado cuando ocurren errores en un lugar y se propagan por el sistema.

La figura 3.6 proporciona ejemplos de diferentes tipos de acoplamiento de mdulos. Los mdulos a y d son subordinados a mdulos diferentes. Ninguno est relacionado y por tanto no ocurre un acoplamiento directo. El mdulo c es subordinado al mdulo a y se accede a l mediante una lista de argumentos por la que pasan los datos. Siempre que tengamos una lista convencional simple de argumentos (es decir, el paso de datos; la existencia de correspondencia uno a uno entre elementos), se presenta un acoplamiento bajo (llamado acoplamiento de datos) en esta parte de la estructura. Una variacin del acoplamiento de datos, llamado acoplamiento de marca (stamp), se da cuando una parte de la estructura de datos (en vez de argumentos simples) se pasa a travs de la interfaz. Esto ocurre entre los mdulos b y a. En niveles moderados el acoplamiento se caracteriza por el paso de control entre mdulos. El acoplamiento de control es muy comn en la mayora de los diseos de software y se muestra en la figura. 3.6 en donde un indicador de control (una variable que controla las decisiones en un mdulo superior o subordinado) se pasa entre los mdulos d y e.

Cuando los mdulos estn atados a un entorno externo al software se dan niveles relativamente altos de acoplamiento. Por ejemplo, la E/S acopla un mdulo a dispositivos, formatos y protocolos de comunicacin. El acoplamiento externo es esencial, pero deber limitarse a unos pocos mdulos en una estructura. Tambin aparece un acoplamiento alto cuando varios mdulos hacen referencia a un rea global de datos. El acoplamiento comn, tal y como se denomina este caso, se muestra en la Figura 3.6. Los mdulos c, g y k acceden a elementos de datos en un rea de datos global (por ejemplo, un archivo de disco o un rea de memoria totalmente accesible). El mdulo c inicializa el elemento. Ms tarde el mdulo g vuelve a calcular el elemento y lo actualiza. Supongamos que se produce un error y que g actualiza el elemento incorrectamente. Mucho ms adelante en el procesamiento, el mdulo k lee el elemento, intenta procesado y falla, haciendo que se interrumpa el sistema. El diagnstico de problemas en estructuras con acoplamiento comn es costoso en tiempo y es difcil. Sin embargo, esto no significa necesariamente que el uso de datos globales sea malo. Significa que el diseador del software deber ser consciente de las consecuencias posibles, del acoplamiento comn y tener especial cuidado de prevenirse de ellos. El grado ms alto de acoplamiento, acoplamiento de contenido, se da cuando un mdulo hace uso de datos o de informacin de control mantenidos dentro de los lmites de otro mdulo. En segundo lugar, el acoplamiento de contenido ocurre cuando se realizan bifurcaciones a mitad de mdulo. Este modo de acoplamiento puede y deber evitarse.

3.1.4 DESCOMPOSICION EN PROCESOS

Las fases que generalmente caracterizan al proceso del software son: definicin desarrollo y soporte, se aplican a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniera del software que debe aplicar el equipo. El gestor del proyecto debe decidir que modelo de proceso es el ms adecuado para: 1. Los clientes que han solicitado el producto y la gente que realizara el trabajo; 2. Las caractersticas del producto en si y 3. El entorno del proyecto en el que trabaja el equipo de software.

Cuando se selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar basado en conjunto de actividades estructurales. Una vez establecido el plan

preliminar, empieza la descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades estructurales. Un equipo debera tener un grado significativo de flexibilidad en la eleccin del paradigma de ingeniera de software que resulte mejor para el proyecto y de las tareas de ingeniera del software que conforman el modelo de proceso una vez elegido. Un proyecto cuando es relativamente pequeo se debe realizar con un enfoque secuencial lineal. Si hay limites de tiempo muy severos y le problema se puede compartir, el modelo apropiado es el DRA. Si se tiene el tiempo limitado lo mas apropiado es tomar una estrategia incremental. Una vez que hemos elegido el modelo de proceso, la Estructura Comn de Procesos (ECP) se adapta a el. En todos los casos, la ECP (comunicacin con el cliente, planificacin, anlisis de riesgo, ingeniera, construccin, entrega y evaluacin del cliente) puede adaptarse al paradigma. Funcionara para modelos lineales, para modelos iterativos e incrementales, para modelos de evolucin e incluso para modelos concurrentes o de ensamblaje de componentes. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organizacin. Las tareas de trabajo reales si varan. La descomposicin del proceso comienza cuando el gestor del proyecto pregunta Cmo vamos a realizar esta actividad ECP? Un proyecto simple requiere las siguientes tareas para la actividad de comunicacin con el cliente: 1. Desarrollar una lista de aspectos que se deben aclarar 2. Reunirse con el cliente para aclara los aspectos de la lista 3. Desarrollar en conjunto una exposicin del mbito del proyecto 4. Revisar el alcance del proyecto con todos los implicados 5. Modificar el alcance del proyecto cuando se requiera.

Este tipo de acontecimientos pueden ocurrir en un periodo de menos de 48 hrs. Representan una descomposicin del problema apropiado para proyectos sencillos. Si se considera un proyecto ms complejo que tenga un mbito ms amplio y un mayor impacto comercial. Un proyecto como se podra requerir las siguientes tareas para la actividad de comunicacin con el cliente: pequeos relativamente

1. Revisar la peticin del cliente 2. Planificar y programar una reunin formal con el cliente 3. Realizar una investigacin para definir soluciones propuestas y enfoques existentes. 4. Prepara un plan de trabajo y una agenda para la reunin formal 5. Realizar la reunin 6. Desarrollar conjuntamente mini-especificaciones que reflejen la

informacin, funcin y caractersticas de comportamiento del software 7. Revisar todas las mini-especificaciones para comprobar su correccin , su consistencia la ausencia de ambigedades 8. Ensamblar las mini-especificaciones de un documento de alcance del proyecto 9. revisar ese documento general con todo lo que pueda afectar 10. modificar el documento de alcance del proyecto cuando se requiera

3.2. EL ENFOQUE ORIENTADO A OBJETOS

El anlisis orientado a objetos (AOO) y el diseo orientado a objetos (DOO) constituyen un enfoque distinto de desarrollo de sistemas. Estas tcnicas se basan en los conceptos de la programacin orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelacin), un lenguaje estandarizado de modelacin en el cual los objetos generados no solo incluyen cdigo referente a los datos sino tambin instrucciones acerca de las operaciones que se realizaran sobre los datos. EL Paradigma Orientado a Objetos es una disciplina de ingeniera de desarrollo y modelado de software que permite construir ms fcilmente sistemas complejos a partir de componentes individuales. Objetos + Mensajes = Programa El proceso Orientado a Objetos se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es en esta parte donde se define el dominio del problema y se identifican las clases bsicas del problema. La planificacin y el anlisis de riesgos establecen una base para el plan de proyecto OO. El trabajo tcnico asociado con la ingeniera del software OO sigue las siguientes tareas: 1. Identificar clases candidatas

2. 3. 4. 5. 6.

Buscar clases en biblioteca Extraer nuevas clases si existen Desarrollar las clases sino existen Aadir las nuevas clases a la biblioteca Construir n-esima iteracin del sistema

La ingeniera de software hace hincapi en la reutilizacin. Por lo tanto las clases se buscan en una biblioteca (de clases existentes) antes de construirse Las Caractersticas del Enfoque Orientado a Objetos son: a) Objeto: Los datos estn cuantificados en entidades discretas y distinguibles llamadas objetos. b) Clase: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupa para formar una clase. c) Atributo: Describen la clase o el objeto de alguna manera d) Mensajes: Medio por el cual interactan los objetos e) Polimorfismo: Significa que una misma operacin puede comportarse de modos distintos en distintas clases. f) Herencia: Compartir atributos y operaciones entre clases tomando como base una relacin jerrquica.

Objeto Un objeto es una unidad de cdigo compuesto de variables y mtodos relacionados. Un objeto encapsula datos, operaciones, otros objetos, constantes y otra informacin relacionada. Pueden ser: Entidades externas, ocurrencias o eventos, papeles o roles, unidades organizacionales, lugares, estructuras. Los Objetos tienen caractersticas y comportamientos. Mantiene sus caractersticas en una o ms "variables", e implementa su comportamiento con "mtodos". Un mtodo es una funcin o subrutina asociada a un objeto. Cuando a las caractersticas del objeto le ponemos valores decimos que el objeto tiene estados. Las variables almacenan los estados de un objeto en un determinado momento.

Para ser considerado como valido un objeto debe de tener las siguientes caractersticas:

Informacin retenida Servicio necesario Atributos mltiples Atributos comunes Operaciones comunes Requisitos esenciales

Clase La clase es un modelo o prototipo que define las variables y mtodos comunes a todos los objetos de cierta clase. Una clase es una descripcin generalizada que describe una coleccin de objetos con caractersticas similares. Todos los objetos que existen dentro de una heredan sus atributos y las operaciones disponibles para la manipulacin de los atributos. Una superclase es una coleccin de clases y una instancia de una clase. Una instancia de una clase es otra forma de llamar a un objeto. En realidad no existe diferencia entre un objeto y una instancia. Slo que el objeto es un trmino ms general, pero los objetos y las instancias son ambas representacin de una clase.

Atributo Los Atributos estn asociados a clases y objetos, ellos describen la clase y el objeto de alguna manera. Un atributo puede tomar un valor definido por un dominio enumerado. En la mayora de los casos, un dominio es simplemente un conjunto de valores especficos. En situaciones ms complejas el dominio puede ser un conjunto de clases. Mensajes Los mensajes son el medio a travs del cual los objetos intercambian informacin. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operacin.

Un objeto es intil si est aislado. El medio empleado para que un objeto interacte con otro son los mensajes. Hablando en trminos un poco ms tcnicos, los mensajes son invocaciones a los mtodos de los objetos.

Encapsulamiento El encapsulamiento significa que toda la informacin de un objeto se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificacin o componente de un programa. El encapsulamiento consiste en unir en la clase las caractersticas y comportamientos, esto es, las variables y mtodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstraccin y el ocultamiento. La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde slo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesar ser conocer qu hace la clase pero no ser necesario saber cmo lo hace. EL Ocultamiento es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer slo los detalles que sean necesarios para el resto del sistema. El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habr cierto comportamiento privado de la Clase que no podr ser accedido por otras Clases. Y controlar porque daremos ciertos mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dnde se validarn que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y mtodos.

Herencia La herencia consiste en que una clase puede heredar sus variables y mtodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y mtodos propios, tiene incorporados los atributos y mtodos

heredados de la superclase. De esta manera se crea una jerarqua de herencia. La herencia reduce el trabajo de la programacin usando fcilmente objetos comunes. Solo es necesario declarar que la clase A hereda de la clase B y despus proporcionar cualquier detalle adicional. Los atributos y comportamientos de la clase B son parte de la clase A y no requiere ninguna programacin adicional.

Polimorfismo El polimorfismo permite que un nmero de operaciones diferentes tengan el mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno ms independiente.

3.2.1. ANLISIS

El AOO ha sido muy exitoso en derribar problemas que se resisten al anlisis estructurado, como las interfaces de usuario. El AOO proporciona una transicin sin igual hacia el DOO y la programacin en lenguajes como Smalltalk, Ada y C++, y es el mtodo de anlisis preferido cuando los mtodos orientados a objetos van a ser utilizados posteriormente en la vida del sistema. Adems, los partidarios del AOO argumentan que los objetos dentro de un sistema son ms fundamentales (importantes, necesarios) para su naturaleza que las funciones que proporciona. Las especificaciones basadas en los objetos sern ms adaptables que las especificaciones basadas en las funciones. Los mtodos que marcan las directrices del AOO son: Coad-Yourdon Tcnica de modelado de objetos de Rumbaugh (Object Modelling Technique OMT) Shlaer-Mellor Booch ROOM Fusin

Coad y Yourdon

Coad y Yourdon describen un mtodo de Anlisis Orientado a Objetos basado en cinco actividades principales: Definicin de las clases y objetos Identificacin de estructuras Identificacin de temas Definicin de atributos Definicin de servicios

Estas actividades son usadas para construir cada capa de un modelo de objetos de cinco niveles. Los objetos existen en el mbito del problema. Las clases son abstracciones de objetos. Los objetos son instancias de clases. La primera tarea del mtodo es identificar las clases y los objetos. La segunda tarea del mtodo es identificar las estructuras. Se reconocen dos tipos de estructuras: estructuras de generalizacin especializacin y estructuras globales *wholepart+. El primer tipo de estructura es como un rbol genealgico: es posible la herencia entre los miembros de una estructura. El segundo tipo de estructura es utilizado para modelar relaciones de entidades (por ejemplo: cada motor contiene una armadura). Los modelos grandes y complejos pueden necesitar una organizacin temtica, con cada (asunto, atributo, en lugar de tema) tema dedicado a un aspecto particular del problema. Por ejemplo, el modelo de objetos de un vehculo de motor puede tener una perspectiva mecnica o una perspectiva elctrica. Los atributos caracterizan a cada clase. Por ejemplo, un atributo de una mquina puede ser el numero de cilindros. Cada objeto tendr un valor para ese atributo. Los servicios definen lo que los objetos hacen. Definir los servicios es equivalente a definir las funciones del sistema. La importancia fundamental del mtodo de Coad y Yourdon es su descripcin breve y concisa, as como el uso de textos generales como fuentes para las definiciones; de modo que las definiciones se enmarcan dentro del sentido comn y reducen el empleo de modismos. La debilidad principal del mtodo es su notacin compleja, la cual es difcil de utilizar sin el apoyo de una herramienta. Algunos usuarios del mtodo Coad-Yourdon han utilizado la dotacin de diagramacin de OMT en su lugar.

Tcnica de Modelado de Objetos La Tcnica de Modelado de Objetos (OMT, Object Modelling Technique) transforma la definicin del problema del usuario (como la que se documenta en un Documento de Requerimientos del Usuario) en tres modelos: Modelo de objetos Modelo dinmico Modelo funcional

Los tres modelos en conjunto crean el modelo lgico requerido por los Estndares de Ingeniera de Software. El modelo de. El procedimiento para construirlo es el siguiente: Identificacin de los objetos Identificacin de las clases de objetos Identificacin de las asociaciones (ejemplo: las relaciones) entre objetos Identificacin de los atributos de los objetos Uso de herencia para organizar y simplificar la estructura de clases Organizacin de las clases y asociaciones estrechamente acopladas dentro de mdulos Acompaar a cada objeto con breves descripciones textuales

Los tipos ms importantes de asociacin son la adicin (es parte de) y la generalizacin (es un tipo de). El modelo dinmico muestra el comportamiento del sistema, especialmente la secuencia de interacciones. El procedimiento para construirlo es el siguiente: Identificar las secuencias de eventos dentro del mbito del problema y documentarlo en el seguimiento (rastreo) de eventos Construir un diagrama de transicin de estados para cada objeto que sea afectado por los eventos, mostrando los mensajes que fluyen, las acciones que son realizadas y los cambios en el estado de los objetos que tienen lugar cuando ocurren los eventos.

El modelo funcional muestra la forma en que se obtienen los valores, sin considerar el momento en que sean computadas. El procedimiento para construirlo no requiere el uso de la descomposicin funcional, sino de: Identificar la entrada y salida de valores que el sistema recibe y produce Construir diagramas de flujo de datos que muestren la forma en que los valores de salida son computados a partir de los valores de entrada Identificar los objetos que son utilizados como almacenes de datos Identificar las operaciones de los objetos que comprenden cada proceso

El modelo funcional es sintetizado a partir de las operaciones de objetos, en vez de descomponerlo desde una funcin de alto nivel. Las operaciones de los objetos pueden ser definidos en cualquier etapa durante el modelado. Los aspectos ms importantes del OMT son sus capacidades simples aunque poderosas de notacin as como su madurez. Ha sido aplicado en varios proyectos por sus autores antes de ser publicado. La principal debilidad es la falta de tcnicas para integrar los modelos de objetos, los modelos dinmicos y los modelos funcionales.

Schlaer y Mellor Schlaer y Mellor comienzan el anlisis identificando el mbito del problema del sistema. Cada mbito es un mundo separado habitado por sus propias entidades conceptuales u objetos. Los mbitos ms grandes son divididos en subsistemas. Despus, cada mbito o subsistema es analizado de forma separada en tres etapas: Modelado de la informacin Modelado de estado Modelado de procesos

Las tres actividades de modelado crean en conjunto el modelo lgico requerido por los Estndares de Ingeniera de Software. El objetivo del modelado de informacin es identificar: Los objetos dentro del sistema Los atributos de cada objeto

Las relaciones entre cada objeto

El modelo de informacin es documentado mediante diagramas y definiciones de objetos, atributos y relaciones. El objetivo del modelo de estado es identificar: Los estados de cada objeto, y las acciones que se realizan sobre ellos Los eventos que causan que los objetos pasen de un estado a otro Las secuencias de estados que forman el ciclo de vida de cada objeto Las secuencias de mensajes que comunican los eventos que fluyen entre los objetos y los subsistemas

Los modelos de estado son documentados mediante diagramas de modelo de estados (mostrando las secuencias de estados), diagramas de modelos de comunicacin de objetos (mostrando los mensajes que fluyen entre los estados), y listas de eventos. El objetivo del modelo de proceso es identificar: Las operaciones de cada objeto requeridas durante cada accin Los atributos de cada objeto que son almacenados en cada accin

Los modelos de proceso son documentados mediante diagramas de accin de flujo de datos, mostrando las operaciones y el flujo de datos que ocurren en cada accin, y los diagramas de modelo de acceso de objeto, mostrando el acceso de datos entre objetos. Los procesos complejos tambin deben ser descritos. La fuerza del mtodo Schlaer-Mellor es su madurez (sus autores declaran haber estado desarrollndolo desde 1979) y la existencia de tcnicas para integrar los modelos de informacin, los modelos de estado y los modelos de proceso. La principal debilidad del mtodo es su complejidad. Booch Booch modela un diseo orientado a objetos desde un punto de vista lgico, el cual define las clases, los objetos y sus relaciones; y desde un punto de vista fsico, que define la arquitectura

de mdulos y procesos. La perspectiva lgica corresponde al modelo lgico que deben construir los ingenieros de software de acuerdo a los requerimientos de los estndares de Ingeniera de Software. El mtodo orientado a objetos de Booch tiene cuatro pasos: 1. Identificacin de clases y objetos a un nivel dado de abstraccin 2. Identificacin de la semntica de estas clases y objetos 3. Identificacin de las relaciones entre esas clases y objetos 4. Implementacin de las clases y objetos

Las primeras tres etapas deben ser completadas dentro de la etapa de Requerimientos del Sistema. La ltima etapa es realizada dentro de las fases de AD y DD. Booch sostiene que el proceso de diseo orientado a objetos no es deductivo [top-down] ni inductivo [bottom Up], sino algo que l denomina round-trip gestalt design *diseo gestalt (conocimiento) de viaje redondo]. El proceso desarrolla un sistema a manera de incrementos e iteraciones. A los usuarios del mtodo de Booch se les advierte que deben integrar las fases SR y AD en una sola fase de modelado. Booch ofrece cuatro tcnicas para la documentacin de la perspectiva lgica: Diagramas de clase: consiste en un conjunto de clases y relaciones entre ellas. Puede contener clases, clases paramtricas, utilidades y metaclases. Los tipos de relaciones son asociaciones, contenencia, herencia, uso, instanciacin y metaclase. Diagramas de objetos: muestra objetos en el sistema y su relacin lgica. Pueden ser diagramas de escenario, donde se muestra cmo colaboran los objetos en cierta operacin; o diagramas de instancia, que muestra la existencia de los objetos y las relaciones estructurales entre ellos Diagramas de estado-transicin: muestran los estados posibles de cada clase, as como los eventos que ocasionan las transiciones de un estado a otro Diagramas de tiempo: aumenta un diagrama de objetos con informacin acerca de eventos externos y tiempo de llegada de los mensajes

Los libros de Booch sobre mtodos orientados a objetos han sido descritos por Stroustrup, el inventor de C++, como los nicos y mejores libros sobre el tema. Este cumplido revela los diversos alcances y la profundidad de un buen anlisis y prctica de diseo en sus escritos. Sin embargo, la notacin de Booch es molesta y hay pocas herramientas disponibles.

ROOM ROOM es una metodologa de Modelado Orientada a Objetos en Tiempo Real desarrollado por la compaa Object Time Developer. Esta metodologa ofrece varios puntos importantes: La complejidad esencial de reactivar sistemas es suficientemente alta para requerir conceptos de modelado especializado. ROOM toma ventajas de muchos desarrollos recientes de la tecnologa de computadoras (mtodos formales, el paradigma de objetos, interfaces grficas al usuario) Tambin, ROOM fue diseado explcitamente para tomar ventaja de la automatizacin basada en computadoras de las dems actividades mecnicas de desarrollo. Esto proporciona un potencial nico para beneficios significativos en productividad y calidad

Estructura del modelado Utiliza sintaxis grfica para una fcil comprensin Abstracciones para tratar con fenmenos arquitectnicos de alto nivel de grandes sistemas de tiempo real. Protocolo basado en mltiples interfaces Objetos concurrentes (actores) Estructuras dinmicas Estructuras reproducidas

Modelado del comportamiento Alto nivel basado en sintaxis grfica Utiliza mquinas de estado jerrquicas; Permite elegir el modelado poderoso de capacidades, al tiempo que permite implementaciones automatizadas avanzadas y eficientes Prioridad basada en la manipulacin de eventos para tratar con requerimientos de tiempo real

Incorpora la industria de lenguajes de programacin estndar (por ejemplo: C++) para detalles especficos.

Experiencia Ms de cien diferentes proyectos industriales han utilizado ROOM Varios dominios de aplicacin:Incluyendo generacin de cdigo automtico completo

Fusin

El Mtodo Fusin est considerado como uno de los mtodos de desarrollo de Segunda Generacin. Proporciona elementos de desarrollo para y con reusabilidad y reingeniera. Los siguientes mtodos o tcnicas han influido en Fusin: OMT (Rumbaugh, 1991): El modelo Objeto es casi similar que en OMT. El modelo operacional es anlogo al modelo funcional en OMT; los diagramas de flujo de datos de OMT no son apropiados de acuerdo con Coleman y han sido formalizados con pre y post condiciones. Mtodos formales: pre y post condiciones son adoptados para describir formalmente qu es lo que hace un sistema. CRC: CRC extendido con informacin de comunicacin ha influenciado en grficas de interaccin de objetos. Diseo OO con Aplicaciones (Booch,1991):La visibilidad de las grficas son influenciadas por informacin de visibilidad en los diagramas Objeto de Booch.

Fusin se basa en un pequeo pero comprensivo conjunto de tcnicas para creacin de diagramas bien definidas para la descripcin de las etapas de anlisis y diseo. Fusin consiste de 3 fases: anlisis, diseo e implementacin. Fusin tambin proporciona reglas para verificar la consistencia e integridad del desarrollo de los modelos.

En la fase de anlisis se define el comportamiento propuesto del sistema. Los modelos en esta fase describen las clases de objetos, las relaciones entre clases, las operaciones que pueden ser ejecutadas en el sistema y permite la realizacin de secuencias de esas operaciones. En la fase de diseo, los modelos producidos muestran la forma en que las operaciones del sistema son implementadas por objetos interactivos, referencias entre clases, relaciones de herencia, atributos de clases y operaciones en clases. En la fase de implementacin, la herencia, la referencia y los atributos de las clases son implementados en clases de un lenguaje de Programacin. Las interacciones entre objetos son programados como mtodos pertenecientes a la clase. Las mquinas estado (State Machines) son implementadas para reconocer secuencias permitidas de operaciones. En sus actividades se encuentran la codificacin, ejecucin y revisin. Fusin mantiene un diccionario de datos, un repositorio donde las diferentes entidades del sistema pueden ser nombradas y descritas.

3.2.2. DISEO

El Diseo Orientado a Objetos (DOO) es un enfoque del diseo de software basado en objetos y clases. Un objeto es una abstraccin de algo en el dominio de un problema o su implementacin, reflejando las capacidades de un sistema para proporcionar informacin acerca de l mismo, interactuar con l o con ambos; es un encapsulamiento de valores de atributo y sus servicios exclusivos. Una clase describe un conjunto de objetos con atributos y servicios comunes. Un objeto es una instancia de una clase, y el acto de crear un objeto se denomina: instantiation. Las clases pueden ser entidades con tipos de datos abstractos, como el Paquete de Telemetra y Espectro, as como entidades ms simples con tipos de datos primitivos como nmeros reales, enteros y cadenas de caracteres. Una clase es definida por sus atributos y servicios. Por ejemplo, la clase Espectro tendra atributos como frecuencia mnima, frecuencia media, frecuencia mxima y servicios tales como calibrar. Las clases pueden ser divididas en subclases. Por ejemplo, pueden existir varios tipos de Paquetes de Telemetra, y pueden ser creadas subclases de Paquete de Telemetra tales como Paquete de Fotmetro y Paquete de Espectmetro. Las subclases comparten caractersticas familiares, y el DOO permite para ello, que las subclases hereden operaciones y

atributos de sus padres. Esto conduce hacia sistemas modulares y estructurados, que requieren menos cdigo para ser implementados. El cdigo comn es automticamente localizado de una manera top-down. Los mtodos de diseo orientado a objetos, a diferencia de otros, ofrecen un mejor soporte para la reutilizacin. El mecanismo tradicional de reus bottom-up donde es perfectamente posible que un mdulo de aplicacin llame a un mdulo de librera. Adems, la caracterstica de herencia permite el reuso top-down de los atributos y las operaciones de la superclase. El DOO combina servicios e informacin, con esto incrementa la modularidad. Las estructuras de control y datos pueden ser definidas de una manera integrada. Otras caractersticas del enfoque orientado a objetos, adems de las clases, los objetos y la herencia son la transmisin de mensajes y el polimorfismo. Los objetos envan mensajes a otros objetos para dirigir sus servicios. Los mensajes tambin son utilizados para transmitir informacin. El polimorfismo es la capacidad, al momento de la ejecucin del programa, para referirse a las instancias de varias clases. El polimorfismo es a menudo implementado para permitir enlaces dinmicos. Las caractersticas de la orientacin a objetos como polimorfismo recaen en la asignacin dinmica de memoria. Esto puede hacer imprevisible el desempeo del software orientado a objetos. Debe tenerse cuidado al momento de programar aplicaciones de tiempo real para asegurar que las funciones que deben completarse dentro de un lmite definido tengan su procesamiento completamente definido al momento de la compilacin y no durante la ejecucin. El DOO es ms efectivo cuando se implementa mediante lenguajes de programacin orientado a objetos que soporten la definicin de objeto, herencia, intercambio de mensajes y polimorfismo. Smalltalk, C++, Eiffel y Object Pascal soportan todas estas caractersticas. Las tcnicas orientadas a objetos han demostrado ser mucho ms satisfactorias para la implementacin de software conducido por eventos, como las Interfaces Grficas de Usuario (GUIs), que los mtodos estructurados. Muchas herramientas CASE para los mtodos estructurados han sido mejoradas para las tcnicas orientadas a objetos. Si los mtodos orientados a objetos van a ser utilizados, esto debe hacerse a todo lo largo del ciclo de vida. Esto significa que el DOO solamente debe ser seleccionado para la fase AD si el Anlisis Orientado a Objetos (OOA) ha sido utilizado en la fase de SR. La transicin del anlisis al diseo, y de este a la programacin es una de las mayores ventajas de los mtodos orientados a objetos, ya que facilita la interaccin. Uno de los primeros trabajos realizados por

Booch, describe una tcnica para el diseo orientado a objetos. En la prctica los resultados no han sido satisfactorios. La perspectiva del anlisis estructurado est basado en las funciones y en los datos, y el enfoque de la orientacin a objetos est basada es clases, objetos, atributos y servicios. Estos enfoques son muy diferentes y es difcil mantenerlos en mente simultneamente. Al igual que el diseo estructurado, el diseo orientado a objetos no es un mtodo nico, sino un nombre para designar una clase de mtodos. Los miembros (Members) de esta clase incluyen: Booch; Diseo Jerrquico Orientado a Objetos (HOOD); Coad-Yourdon; Tcnica del Modelado de Objetos (OMT) Shlaer-Mellor.

En seguida se describe cada uno de ellos. Booch Booch cre el diseo orientado a objetos, y contina jugando un papel principal en el desarrollo del mtodo. Booch modela un diseo orientado a objetos en trminos de un enfoque lgico, el cual define las clases, los objetos y sus relaciones, y un enfoque fsico, el cual define la arquitectura de mdulos y procesos. El enfoque lgico corresponde al modelo lgico que requieren los estndares de la Ingeniera del Software para construir en la fase de SR. El enfoque fsico corresponde al modelo fsico que estos mismos estndares requieren para construir en la fase AD. Booch proporciona dos tcnicas de diagramacin para documentar el enfoque fsico: Diagramas de mdulo, son utilizados para mostrar la asignacin de clases y objetos hacia los mdulos, como los programas, paquetes y tareas en el diseo fsico (el trmino mdulo en el mtodo de Booch es utilizado para describir cualquier componente del diseo); Diagramas de procesos, muestran la asignacin de mdulos hacia los procesadores de hardware.

Los libros de Booch en Diseo Orientado a Objetos contienen muchos anlisis sobre la prctica del buen diseo. Sin embargo, la notacin de Booch puede llegar a ser molesta y existen pocas herramientas disponibles.

HOOD HOOD (Hierarchical Object-Oriented-Design) El diseo jerrquico orientado a objetos (HOOD) es miembro de una familia de mtodos orientados a objetos que tratan de integrar la orientacin a objetos con los mtodos de diseo estructurado. La jerarqua sigue naturalmente a la divisin del objeto raz del nivel ms alto. Al igual que en el diseo estructurado, las parejas de datos fluyen entre componentes del software. La principal diferencia entre HOOD y los mtodos estructurados es que los componentes del software obtienen su identidad de su correspondencia con cosas en el mundo real, en vez de las funciones que el sistema tiene que realizar. HOOD fue originalmente diseado para utilizarse con Ada, aunque Ada no soporta la herencia, y no es un lenguaje de programacin orientado a objetos. Este no es un problema serio para el diseo HOOD, porque el mtodo no utiliza clases para estructurar los sistemas. HOOD no tiene un mtodo de anlisis complementario. El modelo lgico normalmente es construido utilizando el anlisis estructurado. La transformacin del modelo lgico al modelo fsico es difcil, haciendo difcil la construccin de un diseo coherente. HOOD ha sido incluido en aplicaciones Ada. Cuenta ya con un nicho, pero es poco probable que llegue a tener una difusin y un apoyo tan amplio por parte de las herramientas como, por ejemplo, OMT

Coad y Yourdon Coad y Yourdon han publicado un enfoque integral para el anlisis y diseo orientado a objetos. Un diseo orientado a objetos es construido a partir de 4 componentes: Componente del mbito del problema; Componente de interaccin humana; Componente de administracin de tareas; Componente de administrador de datos.

Cada componente est compuesto de clases y objetos. El componente del mbito del problema est basado en el modelo (lgico) construido con el AOO en la fase de anlisis. Define el tema de estudio del sistema y sus responsabilidades. Si el sistema va a ser implementado en un lenguaje orientado a objetos, la correspondencia entre las clases y los objetos del mbito del problema sern uno a uno, y el componente del mbito del problema podr ser programado directamente. Sin embargo, el refinamiento substancial del modelo lgico es normalmente requerido, resultando en la incorporacin de ms atributos y servicios. Las consideraciones de reuso, y la no disponibilidad de un lenguaje de programacin totalmente orientado a objetos, pueden hacer que el diseo del componente del mbito del problema parta de un ideal representado por el modelo de AOO.

Los componentes poco amigables en la interaccin humana envan y reciben mensajes a y desde el usuario. Las clases y objetos en el componente de interaccin humana tiene nombres que son tomados desde el lenguaje de interfaz del usuario, por ejemplo: una ventana y un men. Muchos sistemas tendrn hilos mltiples de ejecucin, y el diseador debe construir un componente de manejo de tareas para organizar el procesamiento. El diseador necesita definir tareas como manejo de eventos (event-driven) o manejo del tiempo (clock-driven), as como sus prioridades de manera crtica. El componente de la administracin de datos proporciona la infraestructura para guardar y recuperar objetos. Puede ser un simple sistema de archivos, un sistema de administracin de bases de datos relacional, o igualmente un sistema de administracin de bases de datos orientado a objetos. Los cuatro componentes juntos hacen el modelo fsico del sistema. En el nivel ms alto, todos los diseos de Coad y Yourdon Orientado-a-Objetos tienen la misma estructura. Las clases y los objetos son organizados en la generalizacin-especializacin y en las estructuras completas (wholepart). Las estructuras de generalizacin especializacin son familiar de rboles, con hijos heredando los atributos de sus padres. Estructuras de partes completas (whole-part) son formadas cuando un objeto es descompuesto. La fuerza de los mtodos Coad y Yourdon son sus instrucciones, descripciones breves y su uso de texto general como fuentes de definiciones, as que las definiciones se ajustan al sentido comn y el jargon es minimizado. El significado de debilidad del mtodo es su notacin

compleja, la cual es difcil de utilizarla sin herramientas de soporte. Algunos usuarios han utilizado en lugar del mtodo Coad-Yourdon la notacin de diagramacin de OMT.

OMT La Tcnica de Modelacin de Objetos (Object Modelling Technique OMT) en el diseo tiene un alto nivel estratgico y decisin para resolver los problemas. Los problemas grandes se deben ver desde el punto de anlisis y diseo, este sistema se divide en subsistemas, a su vez este subsistema puede ser dividido en otros subsistemas de manera que puedan ser manejados y cada componente pueda se comprensible. En esta etapa se deben crear estrategias, formular una arquitectura para el sistema y las polticas que deben guiarla adems un detalle del diseo. Se deben tener en cuenta los siguientes aspectos: Distinguir una arquitectura Elegir una implementacin para un control externo Si se usa base de datos elegir el paradigma de administracin de base de datos Determinar oportunidades para el reuso Elegir estrategia para interaccin de datos Elegir una forma de identificar los objetos Detallar el diseo

Durante el diseo del sistema se debe hacer un cuadro de estrategias y decisiones arquitecturales, tener una idea ms precisa de clases y mtodos individuales. Adicionalmente se puede mejorar el modelo de diseo para mejorar la implementacin. Se debe considerar los siguientes pasos: Uso de transformaciones para simplificar y optimizar el modelo de objetos desde el anlisis. Elaborar un modelo de objeto Elaborar un modelo funcional Evaluar la calidad del diseo del modelo Implementacin

El diseo es trasladado a un lenguaje de programacin actual y cdigo de base de datos. Este paso puede ser aplicado y considerado durante el anlisis y diseo Shlaer y Mellor Shlaer y Mellor describen un Lenguaje de Diseo Orientado a Objetos (OODLE), derivado de la notacin de Booch y Buhr. Existen cuatro tipos de diagramas: Diagrama de Clases que muestran relaciones de utilizacin (cliente/servidor) y de amigos entre clases. Grfica de la estructura de Clase (class) que muestran el aspecto externo de la clase de forma similar a Booch.; Diagrama de Dependencias muestran la estructura de los mtodos de la clase, el flujo de datos y de control; Diagrama de Herencia: representan la herencia.

Existe un diagrama de clase para cada clase. El diagrama de clase define las operaciones y atributos de la clase. La grfica de la estructura de clase define la estructura del mdulo de la clase (class), el control y flujo de datos entre los mdulos de las clases. Existe una grfica de la estructura de la clase para cada clase. Los diagramas de Dependencia muestran las dependencias entre clases, las cuales pueden ser: Cliente - servidor; Amigables.

Una dependencia cliente-servidor existe cuando una clase (el cliente) llama en las operaciones a otras clases (el servidor). Una dependencia de amistad existe cuando una clase accede al dato interno de otra clase. Esto es una violacin de informacin ocultacin. Los diagramas de herencia muestran la herencia de relaciones entre clases.

UNIDAD 4 MODELO DE PROCESOS DE SOFTWARE Para resolver problemas reales de una industria, un ingeniero del software o equipo de ingenieros debe incorporar una estrategia de desarrollo. Esta estrategia a menudo se llama modelo de proceso o paradigma de ingeniera del software. Todo el desarrollo del software se puede caracterizar como un bucle de resolucin de problemas en el que se encuentran cuatro etapas distintas: status quo, definicin de problemas, desarrollo tecnico e integracin de soluciones. Status quo representa el estado actual de sucesos, la definicin de problemas identifica el problema especfico a resolverse; el desarrollo tecnico resuelve el problema a travs de la aplicacin de alguna tecnologa y la integracin de soluciones ofrece los resultados por ejemplo: documentos, programas, datos, nueva funcin comercial, nuevo producto. En las secciones siguientes, se tratan diferentes modelos de procesos para la ingeniera del software. Cada una representa un intento de ordenar una actividad inherente catica. Es importante recordar que cada uno de los modelos se han caracterizado de forma que ayuden (con esperanza) al control y a la coordinacin de un proyecto de software real. 4.1.- MODELO LINEAL SECUENCIAL O EN CASCADA Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal secuencial sugiere un enfoque sistemtico, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. El modelo lineal secuencial comprende las siguientes actividades: Ingeniera y modelado de sistemas/informacin. Esta visin del sistema es esencial cuando el software se debe interconectar con otros elementos como hardware, personas y bases de datos. La ingeniera de informacin abarca los requisitos que se recogen en el nivel de empresa estratgico y en el nivel del rea de negocios.

Ingeniera de sistemas / informacin

Anlisis

Diseo

Cdigo

Prueba

Figura 2.4.- El modelo lineal secuencial Anlisis de los requisitos del software. Se centra especialmente en el software. Para comprender la naturaleza de los programas a construirse, el ingeniero analista del software debe comprender el dominio de informacin del software, as como la funcin requerida, comportamiento, rendimiento e interconexin.

Diseo. Es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso del diseo traduce requisitos en una presentacin del software donde se pueda evaluar su calidad antes de que comience la codificacin. Generacin de cdigo. El diseo se debe traducir en una forma legible por la mquina. Si se lleva a cabo el diseo de una forma detallada, la generacin de cdigo se realiza mecnicamente. Pruebas. Este proceso se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado; es decir, realizar las pruebas para la deteccin de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. Mantenimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo. 4.2.- MODELO EN ESPIRAL Propuesto por Boehm, es un mtodo del proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras interacciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez mas completas del sistema diseado.

Figura 2.8.- Un modelo espiral tpico.

El modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas regiones de tareas. Generalmente existen entre tres y seis regiones de tareas. La Figura 2.8 representa un modelo en espiral que consiste en 6 regiones de tareas: Comunicacin con el cliente.- las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente. Planificacin.- las tareas requeridas para definir recursos, el tiempo y otra informacin relacionadas con el proyecto. Anlisis de riesgos.- las tareas requeridas para evaluar riesgos tcnicos y de gestin. Ingeniera.- las tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y accin.- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentacin y prctica). Evaluacin del cliente.- las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin. Cuando empieza este proceso evolutivo, el equipo de ingeniera del software gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro. El primer circuito puede producir el desarrollo de una especificacin de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso por la regin de planificacin produce ajustes en el plan del proyecto. 4.3.- MODELO INCREMENTAL Combina elementos del modelo lineal secuencial con la filosofa interactiva de construccin de prototipos como muestra la Figura 2.7, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El modelo incremental entrega el software en partes pequeas, pero utilizables, llamadas incrementos. En general, cada incremento se construye sobre aquel que ya haya sido entregado. Cuando se utiliza el modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias quedan sin extraer. El cliente utiliza el producto central. Como resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. El modelo incremental, como la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo

incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin.

Figura 2.7.- El modelo incremental. 4.4.- PROCESO DE DESARROLLO UNIFICADO De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los mejores rasgos y caractersticas de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo gil de software. El proceso unificado reconoce la importancia de la comunicacin con el cliente y los mtodos encaminados a describir el punto de vista del cliente con respecto a un sistema (por ejemplo, el caso de uso). El proceso unificado enfatiza el importante papel de la arquitectura de software y ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajuste a los cambios futuros, y la reutilizacin. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno Al principio de la dcada de 1990, James Rumbaugh, Grady Booch e Ivar Jacobson comenzaron a trabajar en un mtodo unificado que combinara las mejores caractersticas de cada uno de sus mtodos individuales y adoptara caractersticas adicionales que propusieran otros expertos. El resultado fue el lenguaje de modelo unificado (UML) que contiene una notacin robusta para el modelado y el desarrollo de sistemas O.O. El UML proporciona la tecnologa necesaria para apoyar la prctica de ingeniera de software orientada a objetos, pero no provee un marco de trabajo del proceso que gue a los equipos en la aplicacin de la tecnologa. En los aos siguientes, Jacobson, Rumbaugh y Booch desarrollan el proceso unificado, un marco de trabajo para la ingeniera de software orientada a objetos, mediante la utilizacin del UML. En la actualidad, el proceso unificado y el UML se emplean de

forma amplia en proyectos O.O de todos los tipos. El modelo iterativo e incremental que propone el PU puede y debe adaptarse para satisfacer necesidades de proyectos especficas. Como consecuencia de la aplicacin del UML se puede producir un arreglo de productos de trabajo (por ejemplo, modelos y documentos). Fases del proceso unificado. Inicio Planeacin Modelado Elaboracin

Comunicacin Despliegue Incremento del software Produccin Transicin

Construccin construccin

Se han analizado cinco actividades genricas del marco de trabajo y se ha explicado que estas se pueden aplicar para describir cualquier modelo del proceso de software. La fase de inicio del PU abarca la comunicacin con el cliente y las actividades de planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema, y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a travs de un conjunto preliminar de casos de uso. En general, un caso de uso describe una secuencia de acciones que desarrolla un actor (por ejemplo, una persona, una maquina, otro sistema) cuando ste interacta con el software. Los casos de uso ayudan a identificar el mbito del proyecto y proporcionan una base para la planeacin de este. La planeacin identifica recursos, evala los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarn conforme se desarrolle el incremento del software. La fase de elaboracin abarca la comunicacin con el cliente y las actividades de modelado del modelo genrico del proceso. La elaboracin refina expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo de casos de uso, el modelo de anlisis, el modelo de diseo, el modelo de implementacin y el modelo de despliegue. La fase de construccin del PU es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere de los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software. Todas las caractersticas y funciones necesarias y requeridas del

incremento del software (por ejemplo, la entrega) se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de unidad para cada uno de ellos. Adems se realizan las actividades de integracin. Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio de la siguiente fase del PU. La fase de transicin del PU. El software se entrega a los usuarios finales para realizar pruebas beta, y la retroalimentacin del usuario reporte tanto defectos como cambios necesarios. Adems, el equipo de software crea la informacin de soporte necesaria (por ejemplo, manuales de usuario, guas de resolucin de problemas, procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en u n lanzamiento de software utilizable. La fase de produccin del PU coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), y se reciben evalan los informes de defectos y los requerimientos de cambios. Es probable que mientras se realizan las fases de construccin, transicin, y produccin ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una concurrencia por etapas. 4.5.- PROCESO SOFTWARE PERSONAL El proceso de software personal fue creado para proveer a los individuos de un marco de trabajo implementando la aplicacin de mejores prcticas con miras a incrementar la calidad del software que dicho individuo est desarrollando. PSP es una herramienta de auto mejoramiento que le ayuda al individuo a controlar, administrar y mejorar la forma en que trabaja. Esta es una razn de peso para que PSP sea aprendido por los profesionales informticos en etapas tempranas de su formacin. Cuando un Ingeniero de software utiliza PSP puede planear y dar seguimiento a su trabajo, puede utilizar un proceso bien definido y medible, estableciendo metas mensurables y con la posibilidad de rastrear estas metas para determinar cuales se han alcanzado. PSP le muestra a los profesionales del desarrollo de software como manipular la calidad desde el principio del proyecto, como analizar los resultados de las tareas que se van realizando y como utilizar los resultados del proyecto actual para mejorar en el siguiente. Principios de PSP El diseo de PSP se basa en los siguientes principios de planeacin y de calidad. Cada ingeniero es esencialmente diferente; para ser ms precisos, los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales. Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos bien definidos y medidos. Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos.

Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes. Es ms eficiente prevenir defectos que encontrarlos y arreglarlos. La manera correcta de hacer las cosas es siempre la manera ms rpida y ms barata de hacer un trabajo.

UNIDAD 5 TCNICAS, HERRAMIENTAS, Y ESTUDIOS PREVIOS 5.1.- TECNICAS DE RECOPILACIN DE INFORMACIN 5.1.1.- ENTREVISTA Necesita pensar a fondo la entrevista antes de ir a ella. Visualizar porque est yendo, que preguntar y que es lo que constituir una entrevista satisfactoria ante sus ojos. Una entrevista para recoleccin de informacin es una conversacin dirigida con un propsito especfico que usa un formato de preguntas y respuesta. En la entrevista se quiere obtener la opinin del entrevistado y sus sentimientos acerca del estado actual del sistema, los objetivos de la organizacin, los personales y los procedimientos informales. Observe las opiniones de las personas, estas pueden ser ms importantes y ms relevadoras que los hechos. Por ejemplo, imagine que le pregunta al dueo de una tienda que tantas devoluciones de clientes recibe tpicamente cada semana, le dir cerca de 20 a 25 a la semana. Cuando revisa los registros y descubre que el promedio es solo 10.5 por semana, puede concluir que el propietario est exagerando los hechos y el problema. Imagine, en vez de ello, que se le preguntara al propietario cules son sus preocupaciones principales y comenta. en mi opinin, las devoluciones de los clientes estn demasiado altas. Debemos esforzarnos por hacerlo bien desde la primera vez. Los sentimientos expresados ayudan a capturar emocin y las actitudes, si el propietario de la tienda le dice, me siento a gusto de que este trabajando usted en este proyecto, lo puede tomar como un signo positivo de que el proyecto ira bien. Esta informacin est disponible solamente mediante las preguntas acerca de sentimientos. Los objetivos proyectan el futuro de la organizacin. Trate de encontrar tantos objetivos como sea posible a partir de las entrevistas. Tal vez no sea capaz de determinar los objetivos por medio de ningn otro mtodo de recopilacin de datos. En la entrevista, usted esta estableciendo una relacin con alguien que probablemente es un extrao para usted, se necesita dar confianza y comprensin rpidamente, pero, al mismo tiempo, se debe mantener el control de la entrevista Planeacin de la entrevista Cinco pasos en la preparacin de la entrevista

Lectura de material de fondo.- lea y comprenda tanta informacin de fondo acerca del entrevistado y su organizacin como le sea posible. Busque en la biblioteca cualquier informacin corporativa, tal como lo que se encuentra en Standard and Poors. Conforme lea este material, sensibilcese particularmente con el lenguaje que usan los miembros de la organizacin. Lo que esta tratando de hacer es construir un vocabulario comn, que eventualmente le permitir redactar las preguntas de la entrevista en una forma que sea comprensible para el entrevistado. Establecimiento de los objetivos de la entrevista.- use la informacin de fondo que recopil, as como su propia experiencia, para establecer los objetivos de la entrevista. Decidir a quin entrevistar.- cuando este decidiendo a quien entrevistar incluya a gentes claves de todos los niveles que sern afectados por el sistema en alguna forma. Trate de obtener balance para que sean tratadas tantas necesidades de los usuarios como sean posibles. El contacto de la organizacin tambin tendr algunas ideas sobre quin debe ser entrevistado. Prepare al entrevistado.- prepara a la persona a ser entrevistada, llamndole con anticipacin y permitiendo que el entrevistado tenga tiempo para pensar acerca de la entrevista. Las entrevistas deben durar de 45 minutos a 1 hora, a lo mucho. Sin importar que tan deseoso este el entrevistado para extender la entrevista ms all de este lmite, recuerde que cuando ellos gastan tiempo con usted, no estn haciendo su trabajo. Decida sobre tipos de preguntas y estructuras.- las tcnicas adecuadas de cuestionamiento son el corazn de la entrevista. Las preguntas tienen algunas formas bsicas que es necesario saber. Los dos tipos bsicos de preguntas son abiertas y cerradas. Tipos de preguntas Preguntas abiertas.- incluyen aquellas tales como Qu piensa acerca de las microcomputadoras para los gerentes? y por favor, explqueme como toma una decisin de calendarizacin?. Considere la palabra abierta Abierta describe. Los beneficios de usar preguntas abiertas son numerosos e incluyen: 1.- ponen confortable al entrevistado 2.- permite que el entrevistado recoja el vocabulario del entrevistado, el cual refleja su educacin, valores, actitudes y creencias. 3.- proporciona riqueza de detalles 4.- revela caminos para preguntas posteriores que podan haber quedado sin atacar 5.- hace que sea ms interesante para el entrevistado 6.- permite ms espontaneidad 7.- hace que la construccin de frases sea ms fcil para el entrevistador.

8.- se les puede usar en un aprieto si es que el entrevistador es tomado por sorpresa Tambin hay muchas desventajas, que incluyen: 1.- el hacer preguntas que pueden dar como resultado mucho detalle relevante 2.- la posibilidad de perder el control de la entrevista 3.- el permitir respuestas que pueden llevarse demasiado tiempo para la cantidad de informacin til obtenida. 4.- pueden mostrar potencialmente que el entrevistador no esta preparado 5.- pueden dar la impresin de que el entrevistador esta en una expedicin de pesca sin un objetivo real para la entrevista. Preguntas cerradas Las preguntas cerradas, que tienen la forma bsica Qu tantos subordinados tiene?. Las respuestas posibles estn cerradas al entrevistado, debido a que solamente puede responder con un nmero finito, tal como ninguno, uno, o quince. Una pregunta cerrada limita las respuestas posibles del entrevistado. Un tipo especial de pregunta cerrada es la pregunta bipolar. Esto limita todava ms al entrevistado, permitindole solamente una seleccin de algn extremo, tal como si o no, cierto o falso, de acuerdo o desacuerdo. Los beneficios de usar preguntas cerradas de cualquier tipo incluyen: 1.- se ahorra tiempo 2.- se facilita la comparacin de las entrevistas 3.- se llega al punto 4.- se mantiene control sobre la entrevista 5.- se tratan muchos temas rpidamente 6.- se obtienen datos relevantes. Sin embargo, las desventajas del uso de preguntas cerradas son sustanciales, incluyen: 1.- ser aburridas para el entrevistado 2.- no llega a obtener grandes detalles 3.- se pierden ideas principales por la razn anterior 4.- no se llega a establecer una relacin armoniosa entre el entrevistado y el entrevistador.

Averiguaciones.- un tercer tipo de pregunta es la averiguacin. La averiguacin ms fuerte es la ms simple: la pregunta por qu? otras averiguaciones son puede darme un ejemplo? y me podra hablar ms de esto?. El objetivo de las averiguaciones es ir m as all de la respuesta inicial para obtener ms significado. Para aclararlo y para obtener y expandir el punto de vista del entrevistado. Las averiguaciones pueden ser preguntas abiertas o cerradas. Fallas en las preguntas.- redactando sus preguntas de antemano ser capaz de corregir cualquier pregunta tonta que haya escrito. Busque tipos de preguntas problemticas que pueden arruinar los datos. Son llamadas preguntas conducentes y preguntas dobles. Elusin de preguntas conducentes.- las preguntas conducentes tienden a dirigir al entrevistado hacia la respuesta que uno parece querer. La respuesta es entonces sugerida, debido a que se est poniendo un tipo de trampa. Un ejemplo es Ha de estar usted de acuerdo con los dems gerentes de que el control del inventario debe estar computarizado, no es as?. Una redaccin alterna preferida podra ser, Qu piensa usted del control de inventario computarizado? Elusin de preguntas dobles.- las preguntas dobles son aquellas en las que se usa una sola pregunta para lo que de hecho son dos preguntas separadas. Una pregunta tal como Qu decisin toma durante un da tpico y como las toma?. Si el entrevistado responde a este tipo de preguntas los datos pueden presentar dificultades. Una pregunta doble es una mala alternativa, debido a que el entrevistado puede responder solamente una pregunta se puede caer en error sobre cual pregunta est respondiendo y sacar la conclusin equivocada. Acomodo de preguntas en una secuencia lgica Uso de una estructura de pirmide.- mediante el uso de esta forma el entrevistador comienza con preguntas muy detalladas y frecuentemente cerradas. Se debe usar una estructura de pirmide si se considera que el entrevistador necesita ambientarse en el tema. Tambin es til si el entrevistador parece que se resiste a entrar en el tema. La utilizacin de una estructura piramidal para la secuencia de las preguntas tambin es til cuando se quiere una determinacin final acerca del tema. Tal es el caso de la pregunta final, en general, Cmo se siente acerca de los pronsticos?. Las estructuras de pirmide comienzan con una pregunta especfica y terminan con una pregunta general. Uso de una estructura de embudo.- en el segundo tipo de estructura el entrevistador toma un enfoque deductivo, comenzando con preguntas generales y abiertas y estrechando las respuestas posibles usando preguntas cerradas. El uso de estructura de embudo proporciona una forma fcil y no intimidante para comenzar una entrevista. Los que respondan no se sentirn lesionados de que den una respuesta equivocada a una pregunta abierta.

Un beneficio del uso de una estructura de embudo es que el organizar la entrevista en tal forma puede elucidar tanta informacin detallada que son innecesarias las secuencias largas de preguntas cerradas y averiguaciones. Uso de una estructura de rombo.- frecuentemente es mejor una combinacin de las dos estructuras anteriores, dando como resultado la estructura de entrevista con forma de rombo. Esto conlleva en comenzar en una forma muy especfica, luego examinar temas generales y por ultimo llegar a una conclusin muy especfica. La estructura de rombo combina la fuerza de los dos enfoques, pero tiene la desventaja de llevarse ms tiempo. La ventaja principal del uso de una estructura de rombo es conservar el inters y la atencin del entrevistado por medio de una diversidad de preguntas. 5.1.2.- CUESTIONARIO Los cuestionarios son una tcnica de recopilacin de informacin que permite que los analistas de sistemas estudien actitudes, creencias, comportamientos y caractersticas de varias personas principales en la organizacin que pueden ser afectadas por los sistemas actual y propuesto. Planeacin del uso de cuestionarios.- aunque es cierto que se puede recolectar gran cantidad de informacin por medio de cuestionarios sin gastar tiempo en entrevistas personales, el desarrollo de un cuestionario til se lleva un gran tiempo de planeacin por su propio derecho. Primero se debe decir lo que se est tratando de obtener mediante el uso del cuestionario. Estos son algunos lineamientos que le ayudaran a decir si es adecuado el uso de cuestionarios. Considere el uso de cuestionarios si: 1.- las personas a quienes necesita preguntarles estn ampliamente dispersas (diferentes sucursales de la misma corporacin). 2.- en el proyecto del sistema est involucrada gran cantidad de personas y tiene sentido sabes qu proporcin de un grupo dado (por ejemplo, la administracin) aprueba o desaprueba una caracterstica particular del sistema propuesto. 3.- se est haciendo un estudio exploratorio y se quiere medir la opinin general antes de darle al proyecto de sistema una direccin especfica. 4.- se desea asegurarse de que cualquier problema con el sistema actual este identificado y atacado en las entrevistas de averiguacin. Una vez que se ha determinado que se tiene una buena razn para usar un cuestionario y se han destacado los objetivos a ser satisfechos mediante su uso, se puede comenzar a formular preguntas. Definicin de preguntas.- la principal diferencia entre las preguntas usadas en la mayora de las entrevistas y las usadas en los cuestionarios es que las entrevistas permiten la interaccin en relacin con las preguntas y su significado. En una entrevista el analista tiene la

oportunidad de refinar una pregunta, definir un trmino dudoso, cambiar el curso de las preguntas, responder a una apariencia confusa y, por lo general, controlar el contexto. Muy poco de esto es posible en un cuestionario. Lo que esto significa para el analista es que las preguntas deben ser muy claras, el flujo de preguntas coherente, las preguntas de interlocutor anticipadas y la administracin del cuestionario planeada a detalle. Los tipos bsicos de preguntas usados en los cuestionarios son abiertas y cerradas, tal como se dijo para las entrevistas. 5.1.3.- RECOPILACIN DE ANALISIS DE DICUMENTOS Recopilacin de datos: Deber dirigirse al registro de aquellos hechos que permitan conocer y analizar lo que realmente sucede en la unidad o tema que se investiga. Esto consiste en la recoleccin, sntesis, organizacin y comprensin de los datos que se requieren. Se conocen dos tipos de fuentes: 1. primarias: que contienen informacin original no abreviada ni traducida. 2. Secundarias: obras de referencia que auxilian al proceso de investigacin. Se conoce otra divisin que se conforma por las siguientes fuentes: -Documentales -De campo. FICHAS BIBLIOGRFICAS, DE TRABAJO Y HEMEROGRFICAS Las fuentes de recoleccin de datos son todos los registros de aquellos hechos que permitan conocer y analizar lo que realmente sucede en el tema que se investiga. Concluida la parte preparatoria de la investigacin se inicia la fase de recopilacin de datos. Para recabar la informacin existente sobre el tema, el investigador se auxilia de instrumentos como las fichas de trabajo; hay diversos tipos de fichas de trabajo como: Fichas de trabajo para fuentes documentales, fichas de trabajo de una revista, fichas de trabajo de un peridico, para investigacin de campo, para observacin, fichas bibliogrficas y hemerogrficas. ANLISIS E INTERPRETACIN DE INFORMACIN La interpretacin de los resultados de la indagacin lleva inmediatamente a la solucin. El anlisis del instrumento de recoleccin de informacin de campo (encuesta), fue utilizando el anlisis individual de preguntas que se realiza con base en los porcentajes que alcanzan las distintas respuestas de cada pregunta. Para llevar a cabo este tipo de anlisis se dise una forma donde se tabulan las respuestas en base a la cantidad de personas que contestaron cada respuesta y el porcentaje que representa del total de la muestra. REDACCIN Y PRESENTACIN DEL INFORME

El objetivo del informe es presentar a los lectores el proceso que se realiz para presentar una solucin al problema planteado, para lo cual es necesario hacer la presentacin del problema,
los mtodos empleados para su estudio, los resultados obtenidos, las conclusiones a las que se llegaron y las recomendaciones en base a estas. Con respecto a la estructura del informe, sta es sencilla y sigue fielmente los pasos fundamentales del diseo de la investigacin, ya que el informe debe ser la respuesta a lo planteado por el diseo de investigacin.

5.1.4.- OBSERVACIN Y TCNICA STROBE La observacin tanto de tomador de decisiones como del ambiente fsico de este son tcnicas importantes de recopilacin de informacin para el analista de sistemas. Mediante la observacin de las actividades de los tomadores de decisiones, el analista busca obtener una percepcin de lo que realmente se hace y no solo de lo que est documentado o explicado. Mediante la observacin del ambiente de oficina, el analista de sistemas busca el significado simblico del contexto de trabajo de los tomadores de decisiones. El analista examina los elementos fsicos del espacio de trabajo, mediante la observacin de los elementos fsicos sobre los que el tomador de decisiones tiene control (vestimenta, posicin del escritorio, etc.), el analista trabaja para comprender que mensaje est enviando este tomador de decisiones. Observacin del comportamiento del tomador de decisiones.- los analistas de sistemas usan la observacin por muchas razones. Una razn es para obtener informacin acerca de los tomadores de decisiones y su ambiente. La observacin tambin ayuda a confirmar o negar e invertir lo que ha sido encontrado por medio de entrevistas, cuestionarios y otros mtodos. La observacin debe ser estructurada y sistemtica si es que se quiere que los hallazgos sean interpretables. Se debe pensar bien y tener mucho cuidado sobre qu y a quien se va a observar as como cundo, dnde, por qu y cmo. Se dispone de muchos esquemas observacionales, cada uno con su propio objetivo. Observacin de las actividades de toma de decisiones del gerente tpico.- para que el analista aprecie adecuadamente la forma en que los gerentes caracterizan su trabajo se usan las entrevistas y cuestionarios. Sin embargo. La observacin permite que el analista vea de primera mano cmo los gerentes recopilan, procesan, comparten y usan la informacin para hacer que el trabajo se realice. Los siguientes pasos ayudan en la observacin de las actividades tpicas de toma de decisiones de un gerente 1.- decidir lo que va a ser observado (actividades). 2.- decidir a qu nivel de concrecin van a ser observadas las actividades. 3.- crear categoras que capturen adecuadamente las actividades principales. 4.- preparar escalas, listas de verificacin y otros materiales adecuados para la observacin.

5.- decidir cundo observar. Observacin del lenguaje corporal del tomador de decisiones.- la comprensin del lenguaje corporal permite que el analista comprenda mejor los requerimientos de informacin del tomador de decisiones aadiendo dimensin a lo que est siendo dicho. Pares de adjetivos y categoras.- los pares de adjetivos han llegado a ser una forma popular para registrar el comportamiento. Un ejemplo del comportamiento del tomador de decisiones descrito en pares de adjetivos es: decidido/indeciso, confiado/desconfiado, firme/dudoso, y as sucesivamente. El analista determina categoras de actividad antes de que sean tomadas las observaciones. Un ejemplo de una categora concreta es Accesa la base de datos personalmente. Ejemplos de un sistema de categoras que piden ms injerencia del analista para el registro de observaciones son: usa fuentes internas de datos o muestra iniciativa para dar acceso a los datos. El guion del analista.- con esta tcnica, el actor es el tomador de decisiones que es observado actuando o tomando decisiones. Para desarrollar un guion el actor es listado en la columna izquierda y todas sus acciones son listadas en la columna derecha. El guion es un enfoque organizado y sistemtico que demanda que el analista sea capaz de comprender y articular la accin tomada por cada tomador de decisiones observado. Observacin del ambiente fsico.- la observacin del ambiente fsico donde trabaja el tomador de decisiones tambin revela mucho acerca de sus requerimientos de informacin, esto significa examinar sistemticamente las oficinas de los tomadores de decisiones, debido a que las oficinas constituyen su lugar de trabajo principal. Los tomadores de decisiones influencian y a la vez, son influenciados por sus ambientes fsicos. Observacin estructurada del ambiente.- el mtodo para la observacin estructurada del ambiente es llamado STROBE. Es sistemtico debido a que (1) proporciona una metodologa estndar y una clasificacin estndar para el anlisis de los elementos organizacionales que influencian la toma de decisiones, (2) permite que otros analistas de sistemas apliquen el mismo marco de trabajo analtico a la misma organizacin y (3) limita el anlisis a la organizacin a como existe durante la etapa actual de su ciclo de vida. Elementos STROBE.- hay siete elementos concretos que son fcilmente observables por el analista de sistemas. Estos elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila, procesa, guarda y comparte informacin, as como acerca de la credibilidad en el espacio de trabajo. Los siete elementos observables son descritos en los siguientes prrafos. Ubicacin de la oficina.- uno de los primeros elementos que se debe observar es la ubicacin de la oficina. Las oficinas accesibles tienden a incrementar la frecuencia de interaccin y los mensajes informales y, en cambio, las oficinas inaccesibles tienden a disminuir la frecuencia de interaccin e incrementar los mensajes orientados a tarea. Las oficinas distribuidas a lo largo

del edificio, dan como resultado la detencin de reportes o memorndums en alguna de las oficinas y, en cambio, los grupos de oficinas motivan que se comparta informacin. Ubicacin del escritorio del tomador de decisiones.- la ubicacin de un escritorio en la oficina puede proporcionar pistas sobre el ejercicio de poder por el tomador de decisiones. Los ejecutivos que encierran al visitante en un espacio estrecho con su espalda hacia la pared y que a su vez se permiten una gran cantidad de espacio para ellos mismos, se ponen a s mismos en la posicin de poder ms fuerte posible. Un ejecutivo que da posicin a su escritorio viendo hacia la pared con una silla a un lado para el visitante, probablemente est favoreciendo la participacin a nivel de igualdad. Equipo de oficina fijo.- los archiveros, libreros y otros muebles grandes para el almacenamiento de cosas quedan incluidos en la categora de equipo de oficina fijo. Si no hay tal equipo, es probable que el tomador de decisiones guarde pocos conceptos de informacin personalmente. Si hay una abundancia de equipo es presumible que el tomador de decisiones almacene y valore mucha informacin. Propiedades.- hacen referencia a todo el equipo pequeo que se usa para procesar informacin. Esto incluye las calculadoras, pantallas de video, plumas, lpices, y reglas. La presencia de calculadoras y pantallas sugiere que un tomador de decisiones que posee tal equipo es ms probable que lo use personalmente que uno que debe salir del cuarto para usarlo. Revistas y peridicos del negocio.- la observacin del tipo de publicaciones almacenadas en la oficina puede revelar si el tomador de decisiones busca informacin externa (que se encuentra en revistas del negocio, recortes de peridicos sobre otras compaas del negocio, etc.) o se apoya ms en informacin interna (reportes de la compaa, correspondencia intraoficina, manuales de poltica). Iluminacin y color de la oficina.- la iluminacin y color juegan un papel importante en la manera en que un tomador de decisiones recopila in formacin. Una oficina alumbrada con iluminacin incandescente clida indica una tendencia hacia comunicacin ms personal. Un ejecutivo en una oficina iluminada clida recopilar ms informacin informalmente y, en cambio, otro miembro de la organizacin que trabaje en una oficina brillante iluminada y coloreada puede recolectar informacin mediante memorndums ms formales y reportes oficiales. Vestimenta usada por los tomadores der decisiones.- el traje formal de tres piezas para un hombre, o el traje sastre para una mujer, representan la mxima autoridad de acuerdo con algunos investigadores que han estudiado la percepcin de la apariencia de los ejecutivos. Mediante el uso de STROBE el analista de sistemas puede obtener una mejor comprensin sobre la manera en que los gerentes recopilan, procesan, almacenan y usan informacin. 5.2.- HERRAMIENTAS CASE Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Ordenador) son diversas aplicaciones informticas destinadas a aumentar la productividad

en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, calculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. Objetivos 1. Mejorar la productividad en el desarrollo y mantenimiento del software. 2. Aumentar la calidad del software. 3. Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos. 4. Mejorar la planificacin de un proyecto 5. Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. 6. Automatizar, desarrollo del software, documentacin, generacin de cdigo, pruebas de errores y gestin del proyecto. 7. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la documentacin 8. Gestin global en todas las fases de desarrollo de software con una misma herramienta. 9. Facilitar el uso de las distintas metodologas propias de la ingeniera del software. Clasificacin Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros: 1. Las plataformas que soportan. 2. Las fases del ciclo de vida del desarrollo de sistemas que cubren. 3. La arquitectura de las aplicaciones que producen. 4. Su funcionalidad. La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que cubren: Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y diseo de la aplicacin. Lower CASE (L-CASE), herramientas que semiautomatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de Desarrollo_rpido_de_aplicaciones. Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente entre si, ni con la anterior: Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde anlisis hasta implementacin. Meta CASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin. Por funcionalidad podramos diferenciar algunas como: Herramientas de generacin semiautomtica de cdigo. Editores UML.

 Herramientas de Refactorizacin de cdigo. Herramientas de mantenimiento como los sistemas de control de versiones 5.2.1.- ESTRUCTURADAS Aparecieron a fines de los 60s con la Programacin Estructurada, posteriormente a mediados de los 70s extendidas con el Diseo Estructurado y a fines de los 70s con el Anlisis Estructurado. Versiones ms recientes incorporan Diagramas Entidad-Relacin y Diagramas de Transicin de Estados. Ejemplos de metodologas estructuradas impulsadas por organismos gubernamentales lo constituyen: MERISE (Francia), METRICA (Espaa), SSADM (Reino Unido). Otras metodologas estructuradas en el mbito acadmico y comercial son: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco y Information Engineering. Esta ltima propuesta por James Martin pone un nfasis adicional en el modelado de datos y la incorporacin de los desarrollos informticos dentro del contexto organizacional (planificacin, objetivos, etc.).

5.2.2.- ORIENTADAS A OBJETOS Su historia va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y actualmente Java. Slo a fines de los 80s comenzaron a consolidarse algunas metodologas Orientadas a objetos. Algunas de las ms representativas en el mbito comercial son: OMT de Rumbaugh, OOAD de Grady Booch, OOSE de I.Jacobson, la propuesta por Peter Coad & Edward Yourdon, la propuesta por S. Shaler & S.J. Mellor y la propuesta por J.Martin y J.J.Odell. En los ltimos aos se ha realizado un esfuerzo de estandarizacin notacional materializado en UML (Unified Modeling Language), el cual aglutina caracterstica de algunas de las propuestas OO ms conocidas. En 1997 UML fue aprobado como notacin estndar por el OMG.

5.3.- DESARROLLO DE PROTOTIPOS Un prototipo es una tcnica valiosa para la recopilacin rpida de informacin especfica acerca de los requerimientos de informacin de los usuarios. Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinacin de requerimientos, sin embargo la elaboracin de prototipos es una tcnica compleja que requiere el conocimiento del ciclo de vida del desarrollo de sistemas completo antes de que pueda ser lograda satisfactoriamente. Existen cuatro tipos de informacin que busca el analista durante la elaboracin de prototipos. 1.- Reacciones del usuario 2.- Sugerencias del usuario 3.- Innovaciones 4.- Planes de revisin

Reacciones del usuario.- las reacciones son recopiladas por medio de observaciones, entrevistas y formas de retroalimentacin diseadas para recoger la opinin de cada persona acerca del prototipo cuando interacta con el. Por medio de tales reacciones del usuario, el analista descubre muchas perspectivas en el prototipo, incluyendo si parece ser que a los usuarios les agrada el sistema y si habr dificultades para la venta o implementacin del sistema. Sugerencias del usuario.- las sugerencias son recolectadas de aquellos que experimentan el prototipo cuando trabajan con l por un periodo especificado. El tiempo que pasan los usuarios con el prototipo depende, por lo general, de su dedicacin e inters en el proyecto de sistema. Las sugerencias son el producto de la interaccin de los usuarios con el prototipo, as como sus reacciones sobre esta interaccin. Las sugerencias obtenidas de los usuarios deben apuntar al analista hacia formas de refinacin, cambio o limpieza del prototipo para que se ajusten mejor a las necesidades de los usuarios. Innovaciones.- las innovaciones para el prototipo son parte de la informacin buscada por el equipo de analista de sistemas. Las innovaciones son capacidades nuevas del sistema que no haban sido pensadas antes de la interaccin con el prototipo. Van ms all de las caractersticas prototpicas actuales aadiendo algo nuevo a innovador. Planes de revisin.- los planes de revisin ayudan a identificar prioridades para los que se debe construir un prototipo a continuacin. En situaciones donde estn involucradas muchas ramas de la organizacin, los planes de revisin ayudan a determinar para cuales hay que construir un prototipo a continuacin. La informacin recolectada en la fase de hechura del prototipo permite al analista asignar prioridades y redirigir los planes sin realizar gastos con un mnimo de ruptura. Debido a esto, la elaboracin de prototipos y la planeacin van mano a mano. Lineamientos para el desarrollo de un prototipo.- una vez que ha sido tomada la decisin de realizar el prototipo, hay cuatro lineamientos principales a realizar cuando se integra la elaboracin del prototipo en la fase de determinacin de requerimientos del ciclo de vida de desarrollo de sistemas: 1.- Trabajar en mdulos manejables 2.- Construir el prototipo rpidamente 3.- Modificar el prototipo en interacciones sucesivas 4.- Enfatizar la interfaz de usuario. Trabajo en mdulos manejables.- una de las ventajas distintivas de la elaboracin de prototipos en que no es necesario, ni deseable construir un sistema funcional completo para efectos del prototipo.

Un mdulo manejable es aquel que permite la interaccin con sus caractersticas principales, pero todava puede ser construido por separado de otros mdulos del sistema. Las caractersticas del mdulo que se consideran menos importantes son intencionalmente dejadas fuera del prototipo inicial. Construccin rpida del prototipo.- la velocidad es esencial para la elaboracin satisfactoria de un prototipo en un sistema de informacin. Los analistas pueden usar la elaboracin de prototipos para acortar el lapso de entrega del sistema completo, usando tcnicas de recoleccin de informacin tradicionales para resaltar los requerimientos de informacin salientes y luego tomando rpidamente que llevan a un modelo funcional. Modificacin del prototipo.- un tercer lineamiento para el desarrollo del prototipo es que su construccin debe dar soporte a las modificaciones. El hacer el prototipo modificable significa crearlo en mdulos que no son muy interdependientes. Si se observa este lineamiento se encuentra menor resistencia cuando es necesario hacer modificaciones al prototipo. Por lo general el prototipo es modificado varias veces, pasando a travs de varias iteraciones. Cada evaluacin necesita otra modificacin de los usuarios. Tal como sucede con el desarrollo inicial, las modificaciones deben realizarse velozmente, por lo general en un da o dos. El prototipo no es un sistema terminado. El entrar a la fase de elaboracin de prototipos con la idea de que requerir modificaciones es una actitud til que muestra a los usuarios que tan necesaria es su retroalimentacin si es que el sistema va a mejorar. Enfatizar la interfaz del usuario.- la interfaz del usuario con el prototipo en muy importante. Debido a que lo que se est tratando realmente de lograr con el prototipo es hacer que los usuarios muestren cada vez ms sus requerimientos de informacin, deben ser capaces de interactuar fcilmente con el prototipo del sistema. Para muchos usuarios la interfaz es el sistema. No debe ser un obstculo. Por ejemplo, en esta etapa el objetivo del analista es disear una interfaz que permita al usuario interactuar con el sistema con un mnimo de entrenamiento y que permita el mximo de control del usuario sobre las funciones representadas. Desventajas de los prototipos.- la primera es que puede ser bastante difcil el manejar el prototipo como un proyecto dentro de un esfuerzo para un sistema ms grande. La segunda es que los usuarios y analistas pueden adoptar al prototipo como un sistema completo cuando es, de hecho, inadecuado y nunca se pretendi que sirviera como un sistema terminado. Ventajas de los prototipos.- las tres ventajas principales de la elaboracin de prototipos son: la posibilidad de cambiar el sistema en etapas tempranas de su desarrollo, la oportunidad para detener el desarrollo de un sistema que no es funcional y la posibilidad de desarrollar un sistema que ataca ms adecuadamente las necesidades y expectativas de los usuarios. UNIDAD 6 DISEO Y ARQUITECTURA DER PRODUCTOS DE SOFTWARE

6-1.- DESCOMPOSICION MODULAR El diseo modular es una metodologa de desarrollo de programas complejos, que utiliza la filosofa TOP-DOWN, conocida tambin como diseo descendente o refinamiento por pasos sucesivos; o comnmente conocido por los programadores como Divide y Vencers; puesto que enfrenta un problema desde lo abstracto (TOP) hacia lo particular (DOWN). Esta tcnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Mdulos Funcionales. La descomposicin modular contribuye a las caractersticas deseables para la programacin estructurada; y que permite resolver cada mdulo de forma independiente y, si no se sabe resolver alguno de ellos, puede asignrsele un nombre y pasar al desarrollo de otro mdulo y, ms adelante retomar el mdulo incompleto para darle solucin al obtener mayor conocimiento sobre dicho proceso, es decir, la solucin del problema no se detiene por falta de conocimiento de algn proceso en particular. 6.2.- ARQUITECTURA DE DOMINIO ESPECFICO El reto para el diseo es disear el software y hardware para proporcionar caractersticas deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas. Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distincin entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribucin de las aplicaciones generalmente tiene lugar dentro de una nica organizacin. La distribucin soportada es, por lo tanto, intraorganizacional. Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas que son ms adecuadas para la distribucin interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero estn comenzando a usarse para aplicaciones de empresa. Son modelos de arquitectura los cuales son especficos para algn dominio de aplicacin. Dos tipos de modelos de dominio especfico son: Modelos Genricos. Estos son abstracciones de un nmero de sistemas reales y que encapsulan las caractersticas principales de estos sistemas. Modelos de Referencia. Estos son ms abstractos, son modelos idealistas. Proporcionan un significado de informacin con respecto a sistemas de clases y comparacin de diversas arquitecturas.

Modelos genricos Un modelo de Compilador es un ejemplo conocido a travs de otros modelos que existen en dominios de aplicaciones especializadas: analizador lxico Analizador Lxico Tabla de Smbolos Analizador de Sintaxis Analizador Semntico Generador/Optimizador de Cdigo Un modelo de compilador genrico puede ser organizado de acuerdo a diversos modelos de arquitectura. ARQUITECTURAS DE REFERENCIA Los modelos de referencias son derivados del estudio del dominio de una aplicacin, en lugar del estudio de sistemas existentes. Pueden ser utilizados como una base para la implementacin de un sistema o para comparar sistemas diversos. Actan como un estndar, contra el cual los sistemas que pueden ser evaluados. El modelo OSI es un modelo en capas para sistemas de comunicacin, y adems, es un modelo de referencia. La arquitectura de software es la responsable de la derivacin de un modelo de sistema estructural, un modelo de control y un modelo de descomposicin en subsistemas. Los sistemas grandes rara vez conforman un modelo simple de arquitectura. Los modelos de estructuracin de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de mquina abstracta. Los modelos de control incluyen control centralizado y modelos manejadores de eventos. Los modelos de descomposicin modular incluyen los modelos orientados a objetos y los modelos de flujo de datos. 6.2.1.- DISEO DE SOFTWARE DE ARQUITECTURA MULTIPROCESADOR Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razn es porque actualmente la mayora de las CPUs slo pueden ejecutar un proceso cada vez. La nica forma de que se ejecuten de forma simultnea varios procesos es tener varias CPUs (ya sea en una mquina o en varias, en un sistema distribuido. La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta operacin

consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada El multiproceso no es algo difcil de entender: ms procesadores significa ms potencia computacional. Un conjunto de tareas puede ser completado ms rpidamente si hay varias unidades de proceso ejecutndolas en paralelo. Esa es la teora, pero otra historia es la prctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software. Es necesario conocer ampliamente como estn interconectados dichos procesadores, y la forma en que el cdigo que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al mximo sus prestaciones. 6.2.2.- DISEO DE SOFTWARE DE ARQUITECTURA CLIENTE SERVIDOR Esta arquitectura un modelo para el desarrollo de sistemas de informacin en el que las transacciones se dividen en procesos independientes que cooperan entre s para intercambiar informacin, servicios o recursos. Se denomina cliente al proceso que inicia el dilogo o solicita los recursos y servidor al proceso que responde a las solicitudes. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece slo lo particular de cada usuario. Los clientes realizan generalmente funciones como: Manejo de la interfaz de usuario. Captura y validacin de los datos de entrada. Generacin de consultas e informes sobre las bases de datos. Por su parte los servidores realizan, entre otras, las siguientes funciones: Gestin de perifricos compartidos. Control de accesos concurrentes a bases de datos compartidas. Enlaces de comunicaciones con otras redes de rea local o extensa. Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y ste le responde proporcionndolo. Normalmente, pero no necesariamente, el cliente y el servidor estn ubicados en distintos procesadores. Los clientes se suelen situar en ordenadores personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de grupo. Entre las principales caractersticas de la arquitectura cliente/servidor se pueden destacar las siguientes: El servidor presenta a todos sus clientes una interfaz nica y bien definida. El cliente no necesita conocer la lgica del servidor, slo su interfaz externa.

 El cliente no depende de la ubicacin fsica del servidor, ni del tipo de equipo fsico en el que se encuentra, ni de su sistema operativo. Los cambios en el servidor implican pocos o ningn cambio en el cliente. 6.2.3.- DISEO DE SOFTWARE DISTRIBUIDO Sistemas cuyos componentes hardware y software, que estn en ordenadores conectados en red, se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un objetivo. Se establece la comunicacin mediante un protocolo prefijado por un esquema cliente-servidor. Caractersticas: Concurrencia.- Esta caracterstica de los sistemas distribuidos permite que los recursos disponibles en la red puedan ser utilizados simultneamente por los usuarios y/o agentes que interactan en la red. Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realizacin de una tarea, no tienen una temporizacin general, est ms bien distribuida a los componentes. Fallos independientes de los componentes.- Cada componente del sistema puede fallar independientemente, con lo cual los dems pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando. Evolucin: Procesamiento central (Host).- Uno de los primeros modelos de ordenadores interconectados, llamados centralizados, donde todo el procesamiento de la organizacin se llevaba a cabo en una sola computadora, normalmente un Mainframe, y los usuarios empleaban sencillos ordenadores personales. Los problemas de este modelo son: Cuando la carga de procesamiento aumentaba se tena que cambiar el hardware del Mainframe, lo cual es ms costoso que aadir ms computadores personales clientes o servidores que aumenten las capacidades. El otro problema que surgi son las modernas interfaces grficas de usuario, las cuales podan conllevar a un gran aumento de trfico en los medios de comunicacin y por consiguiente podan colapsar. 6.2.4.- DISEO DE SOFTWARE DE TIEMPO REAL El software de tiempo real est muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al mbito del problema en un tiempo dictado por el mbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseo del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las caractersticas del sistema

operativo, por los requisitos de la aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo. La computadora digital se ha convertido en una maquina omnipresente en la vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto de gasolina de nuestras ltimas generaciones de coches y programar a nuestros aparatos. Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de computacin de tiempo real. La computadora est controlando algo que interacta con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interaccin. Los sistemas de tiempo real generan alguna accin en respuesta a sucesos externos. Para realizar esta funcin, ejecutan una adquisicin y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real estn frecuentemente dedicados a una nica aplicacin. Durante muchos aos, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reduccin del coste del hardware ha hecho posible para la mayora de las compaas, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatizacin industrial, investigacin mdica y cientfica, grficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentacin industrial. Consideraciones Sobre los Sistemas Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, para conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento. El problema para los sistemas de tiempo real es realzar la asignacin importante como la funcin, pero las decisiones de asignacin relativas al rendimiento son frecuentemente difciles de hacer con seguridad. Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un hardware especial para hacer el trabajo? Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el ingeniero de sistemas de tiempo real.