ANTOLOGIA de Sistemas de Ion II Oko

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos.
Edicin Junio 30/04/10
Departamento:
Licenciatura en Informtica
Materia:
SISTEMAS DE INFORMACION II
Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10
Departamento:
Materia:
OBJETIVO:
El estudiante conocer y dominar mtodos de la ingeniera del software para el diseo, construccin y documentacin de sistemas de informacin.
INTRODUCCION
Hasta hace poco la informacin misma no se consideraba un activo importante en una compaa. El proceso administrativo se consideraba un arte personal, de cara a cara, y no un proceso de coordinacin global a grandes distancias.
Hoy da se reconoce ampliamente que para los administradores es indispensable entender los sistemas de informacin, porque casi todas las organizaciones necesitan este sistema para sobrevivir y prosperar.
Ahora los sistemas de informacin son muy importantes en nuestro entorno para poder generar calidad en nuestro trabajo.
Un sistema de informacin se puede definir tcnicamente como un conjunto de componentes interrelacionados que rene, procesa, almacena y distribuye informacin para apoyar la toma de decisiones y el control en una organizaron adems de apoyar la toma de decisiones, la coordinacin y el control, los sistemas de informacin tambin ayudan a los administradores y trabajadores a analizar problemas, visualizar aspectos complejos y crear nuevos productos.
Departamento:
Materia:
Los sistemas de informacin tambin requieren retroalimentacin, que consiste en salidas que se devuelven a los miembros apropiados de la organizacin para ayudarles a evaluar o corregir la etapa de entrada.
Tambin, pueden ayudar a los administradores y trabajadores a analizar problemas, visualizar sujetos completos y crear productos nuevos.
Para entender los sistemas de informacin un sistemas de informacin es una solucin organizacional y administrativa basadas en tecnologa de informacin para un desafo del ambiente o el entorno en que se est realizando.
Son efectivamente una valiosa herramienta para el desarrollo de las organizaciones, pero es importante resaltar que todos los sistemas de informacin no son iguales y la implementacin de estos en las diferentes empresas, no siempre son de beneficio si no se verifica previamente el tipo de empresa y si el sistema a implementar es el adecuado.
Si nosotros queremos crear un sistema de informacin econmico para una empresa grande no nos servir de mucho y abra sido una inversin en vano y si la empresa es grande y tenemos un sistema de informacin bajo que no cumpla con las caractersticas para ayudarnos de manera eficaz en todo el manejo de la empresa entonces ser en vano esta implementacin porque tenemos que estar consientes de lo que necesita la empresa para poder actuar.
En los siguientes temas nosotros podremos verificar como poder crear un sistema de informacin que cumpla con las caractersticas necesarias para poder llevar a nuestra empresa al xito.
Departamento:
Materia:
JUSTIFICACION
Este documento es titulado sistemas de informacin es elaborado para poder tomarse como gua de la materia y poder utilizar para impartir clases, tambin para que pueda servir de apoyo didctico a los maestros y alumnos ya que cabe mencionar que el contenido de esta antologa trata bsicamente de la culminacin tota e implementacin de un proyecto desde el concepto de un diseo de un sistema pasando por todos los lineamientos que debemos seguir para la realizacin de un sistema desde su diseo fsico y lgico, su arquitectura ,su programacin y elaboracin hasta su implementacin en el rea que se va a utilizar este sistema.
Esta informacin referente a los sistemas de informacin es un documento muy importante para poder guiarnos a un mejor desempeo en el transcurso de la elaboracin de nuestro proyecto y la manera de poder implementarlo de manera que aunque haya fallas podremos detectarlas y corregirlas para obtener la satisfaccin de un trabajo total y completo elaborado por nosotros mismos, es posible que no encontremos todo lo que buscamos porque siempre hay muchas cosas nuevas que aprender y poner en prctica pero la decisin es nuestra esta antologa es solo para apoyarte y guiarte para que ests encaminado a un buen desempeo en el sistemas que se desee realizar. Animo que aun ai mucho por aprender.
INDICE Pg.
Departamento:
Materia:
Objetivo .II Introduccin..II Justificacin..IV ndice.........5
UNIDAD I: FUNDAMENTOS DEL DISEO
1.1 Panorama general del diseo fsico y lgico ...9 1.2 Concepto del diseo de sistemas ...16 1.2.1 Acoplamiento y coherencia.23 1.2.2 Arquitectura de software .35 1.3 Heursticas de diseo 38
UNIDAD II: DISEO DE SISTEMAS
2.1 Modelo estructurado..55 2.2 Modelo orientado a objetos.62 2.3 Modelo basado en componentes69 2.4 Diseo de la arquitectura del software .77 2.5 Diseo de interfaz de usuario .94 2.6 Diseo de bases de datos 118 2.7 Diseo de controles y procesos 126
Departamento:
Materia:
2.8 Aplicacin de mtricas para la evaluacin del diseo138
UNIDAD III : CONSTRUCCION
3.1 Seleccin del ambiente operativo y lenguaje de desarrollo..150 3.2 Elaboracin de programas.153 3.2.1 Implementacin.159 3.3 Mtricas para evaluar el software .162 3.4 Pruebas de programa y del sistema..169 3.5 Implementacin.. .178 3.6 Documentacin.180 3.6.1 Elaboracin del manual de usuario183 3.6.2 Elaboracin del manual de administracin189 3.6.3 Elaboracin del manual tcnico .212
UNIDAD IV: ESTUDIAS DE CASOS PRACTICOS PARA MANTENIMIENTO
4.1 Tipos de mantenimiento..219 4.2 Tcnicas de mantenimiento234 4.3 4.4 Anlisis de casos244 Viabilidad del mantenimiento246
4.5 Administracin del mantenimiento250 Conclusiones.253
Departamento:
Materia:
Glosario..255 Anexos 259 Fuentes de consultas..261
Departamento:
Materia:
UNIDAD I FUNDAMENTOS DEL DISEO
1.1
PANORAMA GENERAL DEL DISEO FISICO Y LOGICO
Departamento:
Materia:
El diseo fsico es el proceso de traduccin del modelo lgico abstracto a un diseo tcnico especfico para el nuevo sistema. Produce las especificaciones reales para el hardware, software y bases de datos fsicas, medios de entrada/salida, procedimientos manuales y controles especficos. Proporciona las especificaciones que transforman el diseo lgico abstracto en un sistema de funciones de personas y mquinas. Cuando el analista est listo para comenzar a disear el nuevo sistema, ya deben estar establecidos ciertos elementos. Debe hacer una definicin del problema, informacin general de antecedentes sobre el rea bajo estudio, una idea aproximada de las interacciones
Tambin el diseo el diseo fsico de sistemas es la forma en que se lograrn las tareas del sistema, lo que incluye la manera de conjuntar sus componentes y las funciones que realizar cada uno de stos.
En el diseo fsico se especifican las caractersticas de los componentes del sistema requeridos para poner en prctica el diseo lgico. En esta fase deben delinearse las caractersticas de cada uno de los componentes que se enumeran a continuacin.
Departamento:
Materia:
Diseo de hardware: Debe especificarse todo el equipo de cmputo, lo que incluye dispositivos de entrada, procesamiento y salida, con sus caractersticas de rendimiento. Por ejemplo, si el diseo lgico especifica que la base de datos debe contener grandes volmenes de datos histricos, se requerir que los dispositivos de almacenamiento del sistema sean de gran capacidad.
Diseo de software: De todo el Software Por ejemplo, si en el diseo lgico se indica la necesidad de que de que los usuarios actualicen al mismo tiempo la base de datos, en el diseo fsico deben especificarse un sistema de administracin de base de datos que lo permita algunos casos se puede adquirir el software, mientras que en otros se desarrollan internamente. Las especificaciones de diseo lgico, en cuanto a requisitos de salidas, entradas y procesamiento de los programas, tambin se toman en cuenta durante el diseo fsico del software. As pues, se especificara la capacidad de acceder a datos almacenados en ciertos archivos de disco que el programa utiliza.
Diseo de bases de datos: Es necesario detallar el tipo, estructura y funciones de las bases de datos. Las relaciones entre los elementos de datos establecidos en el diseo lgico deben reflejarse tambin en el diseo fsico. Estas relaciones incluyen aspectos tales como las rutas de acceso y la organizacin de la estructura de archivos. Por fortuna, existen muchos sistemas excelentes de administracin de bases de datos que son tiles para esta actividad.
10
Departamento:
Materia:
Diseo de telecomunicaciones: Deben especificarse las caractersticas necesarias del software, medios y dispositivos de telecomunicaciones. De tal suerte, si el diseo lgico indica que todo los miembros de un departamento deben compartir datos y software, ha de hacerlo posible la configuracin de la red de rea local y el software de telecomunicaciones especificados en el diseo fsico.
Diseo de personal: Este paso incluye especificar los antecedentes y experiencia de los individuos que ms probablemente satisfagan las descripciones de empleos que se incluyen en el diseo lgico.
Diseo de procedimientos y controles: Comprende detallar la forma en que se ejecuta cada aplicacin y las medidas para minimizar las probabilidades de delitos y fraudes. Tales especificaciones incluyen mtodos de auditora, soporte y distribucin de salidas.
Diseo lgico
Es aquel que representa los componentes del sistema y sus relaciones mutuas, como se mostrara ante el usuario. Muestra lo que la solucin sistemtica har en contraposicin con el modo como lo es en la actualidad impactada
11
Departamento:
Materia:
fsicamente. controles.
Tambin
describe
las
entradas
salidas,
las
funciones
de
procesamiento a realizar, los procedimientos de negocios, los modelos de datos y los
El diseo lgico de sistemas se refiere a lo que har el nuevo sistema, el diseo lgico es una descripcin de los requisitos funcionales de un sistema. En otras palabras, es la expresin conceptual de lo que har el sistema para resolver los problemas identificados en el anlisis previo. A falta de este paso, los aspectos tcnicos del sistema (como los dispositivos de hardware que deban adquirirse) con frecuencia oscurecen la solucin.
El diseo lgico incluye planear el propsito de cada elemento del sistema, sin relacin con consideraciones de hardware y software. Las especificaciones de diseo lgico que se determinar, y documentan se detallan en los prrafos siguientes.
Diseo de salida: Es una descripcin de todas las salidas del sistema e incluye sus tipos, formato, contenido y frecuencia. Por ejemplo, el requisito de que toda< las facturas de la compaa incluyan el nmero de factura original de los clientes es una especificacin de diseo lgico. Las herramientas de diseo de pantallas e informes pueden usarse durante la fase de diseo de salidas para satisfacer los requisitos de salidas del sistema.
12
Departamento:
Materia:
Diseo de entrada: Una vez que se completa el diseo de salidas, puede iniciarse el de entradas. En ste se especifican los tipos, formato, contenido sistema capture los nmeros telefnicos de los clientes cuando stos llaman a la organizacin y use tal dato para buscar de manera automtica la informacin de su cuenta, es una especificacin de diseo lgico. Es posible utilizar diagramas y diseos de pantallas e informes diversos para especificar el tipo, formato y contenido de los datos de entrada.
Diseo de procesamiento: Los tipos de clculos, comparaciones y manipulaciones de datos en general que requiere el sistema se determinan durante esta fase. Por ejemplo, un programa de nmina requiere clculos de los sueldos brutos y netos, retenciones de impuestos federales y locales, y otras deducciones y planes de ahorro.
Diseo de archivos y bases de datos: En muchos sistemas de informacin se requieren subsistemas de archivos y bases de datos. Las caractersticas de estos subsistemas se especifican tambin en la fase de diseo lgico. Por ejemplo, la capacidad para obtener la actualizacin instantnea de los registros de los clientes es una especificacin de diseo lgico. En muchos casos, un administrador de bases de datos participa en este aspecto del diseo. Los diagramas de flujo de datos y de entidad relacin por lo comn se emplean durante el diseo de archivos y bases de datos.
13
Departamento:
Materia:
Diseo de telecomunicaciones: Durante el diseo lgico es necesario especificar los sistemas de redes y telecomunicaciones. Por ejemplo, en un hotel podra especificarse un sistema de cliente/servidor con un cierto nmero de estaciones de trabajo enlazadas con el servidor. A partir de estos requisitos, podra optarse por una topologa hbrida. Los programas de grficos y las herramientas de CASE son tiles para facilitar el diseo de redes lgicas.
Diseo de procedimientos: Lo dos sistema de informacin requiere procedimientos para la ejecucin de aplicaciones y la solucin de los problemas que surjan. Estos requisitos importantes se capturan durante el diseo de procedimientos. Una vez diseados, los procedimientos se pueden describir con programas de procesamiento de texto. A manera de ejemplo, los pasos necesarios para aadir una nueva cuenta de cliente podran incluir una serie de tareas manuales y computarizadas. Deben redactarse procedimientos escritos para que sean eficaces y todo mundo los siga.
Diseo de controles y seguridad: Otra parte importante del diseo lgico es determinar la frecuencia y caractersticas necesarias de los sistemas de respaldo. En general, debe tenerse apoyo de todo, lo que incluye el hardware, software, datos, personal, insumos e instalaciones. Adems, en esta fase del diseo lgico ha de considerarse la planeacin de cmo prevenir un desastre del equipo de cmputo y la forma de recuperarse de l si ocurre.
14
Departamento:
Materia:
Diseo de personal y empleos: Algunos sistemas requieren contratar empleados adicionales, mientras que con otros es necesario modificar las tareas relacionadas con uno o ms empleos de SI existentes. Los nombres y descripciones de los puestos se especifican durante el diseo de personal y empleos. Los organigramas son tiles en el diseo de personal para diagramar los empleos y sus nombres. Tambin se utilizan procesadores de textos para describir las funciones de cada puesto.
1.2 CONCEPTOS DEL DISEO DE SISTEMAS.
La tecnologa de informacin y su historia.
A lo largo de la historia el hombre ha necesitado manejar y transmitir informacin para ello ha estado creando mquinas y mtodos.
15
Departamento:
Materia:
La informtica surge como la ciencia encargada del estudio y desarrollo de estas mquinas y mtodos que constituyen la tecnologa de informacin.
La tecnologa de informacin abarca desde artefactos, como papel, plumas, libros, cmaras, videograbadoras, computadoras, etc., hasta herramientas simblicas como el lenguaje escrito, smbolos matemticos, modelos qumicos etc. Sin estas mquinas y mtodos no seriamos capaces de visualizar nuestro ambiente, entenderlo ni controlarlo creativamente.
La historia de la tecnologa de informacin se ha seccionado en diferentes eras:
La era pre mecnica: 3000 a.C. 1450 d.C. (el nacimiento de la informacin) Primer sistema de escritura y alfabetos Herramientas: papel y plumas Libros y bibliotecas de numeracin y baco. La era mecnica: 1450 1840 ( la explosin de la informacin) Imprenta *peridicos y revistas *reglas de clculo y mquinas analticas.
16
Departamento:
Materia:
La era electromecnica: 1840 1940 (telecomunicaciones) Telgrafo y telfono La era electrnica 1940 presente
Primeras computadoras electrnicas digitales Generaciones de computadoras digitales
UNIVAC, ENIAC, etc.
Los continuos avances en tecnolgica de informacin tienen un fuerte impacto sobre la forma en que las personas trabajan, pues facilita el trabajo en equipo y la comunicacin a distancia.
Con frecuencia la informacin generada por un medio computarizado se trata con menos escepticismo que la obtenida por otros medios.
Las organizaciones cada vez son ms conscientes de la necesidad de contar con la mejor infraestructura tecnolgica para operar sus negocios de una manera eficiente y competitiva, pero tambin del alto costo que esto puede representar.
17
Departamento:
Materia:
Ante esta situacin ha surgido la necesidad de crear un rol conocido como Arquitecto de Sistemas en el cual se ha delegado la responsabilidad de investigar, evaluar y seleccionar las mejores alternativas tecnolgicas para atender las necesidades especficas del negocio a un costo razonable.
Dmosle un vistazo al origen de este rol, su analoga con los arquitectos de edificaciones, las competencias y el perfil requerido para desempearlo y la importancia que ha venido cobrando en las organizaciones el anlisis de la arquitectura de sistemas.
El diseo del sistema es la estrategia de alto nivel para resolver problemas y construir una solucin.
El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica.
La etapa del diseo del Sistema encierra cuatro etapas:
El diseo de los datos
18
Departamento:
Materia:
Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para implementar el Software.
El diseo Arquitectnico
Define la relacin entre cada uno de los elementos estructurales del programa.
El diseo de la Interfaz
Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean.
El diseo de procedimientos
19
Departamento:
Materia:
Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseo del Software se puede definir en una sola palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de materializar con precisin los requerimientos del cliente.
El diseo del Software
Es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software.
20
Departamento:
Materia:
El Diseo debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementacin.
Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios tcnicos para un buen diseo como son:
Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software.
El diseo debe ser modular, es decir, se debe hacer una particin lgica del Software en elementos que realicen funciones y subfunciones especificas.
Un diseo debe contener abstracciones de datos y procedimientos.
Debe producir mdulos que presenten caractersticas de funcionamiento independiente.
21
Departamento:
Materia:
Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno exterior.
Debe producir un diseo usando un mtodo que pudiera repetirse segn la informacin obtenida durante el anlisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software exige buena calidad a travs de la aplicacin de principios fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva.
Cuando se va a disear un Sistema de Computadoras se debe tener presente que el proceso de un diseo incluye, concebir y planear algo en la mente, as como hacer un dibujo o modelo o croquis.
1.2.1 ACOPLAMIENTO Y COHERENCIA
Cohesin
22
Departamento:
Materia:
Grado de relacin entre los elementos de un modulo. Si evaluamos el acoplamiento y la cohesin nos puede dar la calidad de un buen sistema de informacin.
La cohesin tiene que ser alta para que el sistema sea bueno, a mayor cohesin menor acoplamiento.
Tipos de Cohesin:
Cohesin funcional: Los elementos de la unidad de software estn relacionados en el desarrollo de una nica funcin. Es decir, las unidades de software trabajan juntas con un mismo fin. En general, es el criterio de agrupacin ms deseable. Probablemente haya entre las unidades un acoplamiento relativamente alto, por lo tanto es conveniente que estn juntas.
Cohesin secuencial: Una unidad de software realiza distintas tareas en secuencia, de forma que las entradas de cada tarea son las salidas de la tarea
23
Departamento:
Materia:
anterior. En otras palabras, se agrupan las unidades que cumplen que los resultados o salidas que produce una sirven como entrada para que la prxima contine trabajando.
Cohesin comunicacional o de datos: La unidad de software realiza actividades paralelas usando los mismos datos de entrada y salida. En otras palabras, cuando todas las unidades agrupadas trabajan sobre el mismo conjunto de datos.
Cohesin procedimental: La unidad de software tiene una serie de funciones relacionadas por un procedimiento efectuado por el cdigo. Es similar a la secuencial, pero incluyendo el paso de controles.
Cohesin lgica: Cuando las unidades de software agrupadas realizan un trabajo en una misma categora lgica, pero no necesariamente tienen relacin entre s. Por ejemplo: bibliotecas de funciones matemticas, slo se agrupan porque realizan clculos matemticos, pero no tienen necesariamente relacin entre ellas.
Cohesin temporal: Los elementos de la unidad de software estn implicados en actividades relacionadas con el tiempo. En otras palabras, se agrupan unidades de
24
Departamento:
Materia:
software que tienen que ejecutarse ms o menos en el mismo perodo de tiempo, sin que haya otro tipo de relacin entre ellas. En general debe evitarse.
Cohesin casual o coincidente: Los elementos de la unidad de software contribuyen a las actividades relacionndose mutuamente de una manera poco significativa. En otras palabras, es cualquier criterio que no caiga dentro de los anteriores. Este tipo de cohesin viola el principio de independencia y de caja negra de las unidades de software, por lo tanto debe evitarse
Qu ocurre en el caso de la cohesin?
La cohesin de un componente mide la identidad de su comportamiento. El comportamiento de un componente se define mediante una serie de operaciones (contrato), cada una de ellas con una responsabilidad y funcin. La suma de todas las operaciones que definen dicho comportamiento integra una identidad.
La cohesin no es buena cuando nos encontramos con que hay operaciones con un objetivo junto a otras con otro objetivo dentro de un mismo componente, cuya definicin funcional es una y clara. Un ejemplo claro y sencillo de esto es el siguiente. Imaginemos un componente que gestiona el estado de una ficha de datos personales. Lo lgico sera que su contrato tuviese operaciones como "Actualizar nombres y apellidos", "Eliminar telfono de contacto" y dems.
25
Departamento:
Materia:
Si defino una operacin que calcula el pronstico del tiempo en Tombuct para el prximo fin de semana, pues la cohesin se anula completamente, ya que nada tiene que ver con el resto de operaciones y, sobretodo, con el fin del componente.
Con esto propongo un debate sobre estos dos conceptos, para enriquecernos entre todos y mejorar el uso que hacemos de ello a diario en nuestros diseos. Aunque no lo parezca, aplicamos estas ideas constantemente, en todos los niveles de un equipo de desarrollo de soluciones informticas.
Acoplamiento
Grado de interdependencia entre las unidades de software (mdulos, funciones, subrutinas, bibliotecas, etc.) de un sistema informtico. El acoplamiento da la idea de lo dependiente que son las unidades de software entre s, es decir, el grado en que una unidad puedefuncionar sin recurrir a otras.
Por ejemplo: Dos funciones son absolutamente independientes entre s (es decir, el nivel ms bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la otra. En este caso se dice que ambas estn desacopladas.
El consenso general es que debe haber bajo acoplamiento entre las unidades de software para lograr una buena programacin o un buen diseo.
26
Departamento:
Materia:
O sea, mientras menos dependientes sean entre s las partes que constituyen un sistema informtico, mejor ser el resultado. Obviamente es imposible un desacoplamiento total de las unidades.
El bajo acoplamiento permite:
Mejorar la mantenibilidad de las unidades de software. Aumentar la reutilizacin de las unidades de software. Evitar el efecto onda, ya que un defecto en una unidad puede propagarse a otras, haciendo incluso ms difcil de detectar dnde est el problema. Minimiza el riesgo de tener que cambiar mltiples unidades de software cuando se debe alterar una. El acoplamiento, junto con la modularidad, la cohesin y otros factores, permiten mejorar la programacin y el diseo de sistemas informticos y aplicaciones, y son cruciales en el incremento de la reutilizacin de los cdigos.
Tipos de acoplamiento
Acoplamiento normal: una unidad de software llama a otra de un nivel inferior y tan solo intercambian datos (por ejemplo: parmetros de entrada/salida). Dentro de este tipo de acoplamiento podemos encontrarnos 3 subtipos, dependiendo de los datos que intercambien las unidades de software. Para ms informacin ver Acoplamiento normal.
27
Departamento:
Materia:
Acoplamiento externo: las unidades de software estn ligadas a componentes externos, como por ejemplo dispositivos de entrada/salida, protocolos de comunicaciones,etc. Acoplamiento comn: dos unidades de software acceden a un mismo recurso comn, generalmente memoria compartida, una variable global o un fichero.
Acoplamiento de contenido: ocurre cuando una unidad de software necesita acceder a una parte de otra unidad de software.
Qu quiere decir reducir el acoplamiento?
Bsicamente, lo ms importante es saber definir las responsabilidades de cada componente para garantizar que la dependencia sea funcional o arquitectnica, no de implementacin.
Un ejemplo simple de acoplamiento es cuando un componente accede directamente a un dato que pertenece a otro componente. Qu ocurre en ese caso? Pues que el resultado del comportamiento del componente A depender del valor del componente B, por lo tanto, estn acoplados. Cabe destacar que el acoplamiento no
28
Departamento:
Materia:
es malo, ojo. Simplemente hay que saber eliminar el acoplamiento que no sea funcional o arquitectnico.
En el caso de acoplamiento funcional, est bien que un componente de clculo de probabilidades dependa de un componente de clculo matemtico bsico, ya que es evidente que para calcular probabilidades ser necesario aplicar frmulas matemticas y resolver operacines aritmticas.
En el caso de acoplamiento arquitectnico, se puede ver un ejemplo en el esquema MVC (modelo-vista-controlador). La capa del modelo realizar cambios de acuerdo con los parmetros que recibe del controlador, por lo tanto hay cierta dependencia, pero slo como separacin de capas de una arquitectura claramente definida.
Propiedad que se define entre dos mdulos, es el grado de relacin que hay entre estos dos mdulos.
Para tener modularidad efectiva, hay que tratar de tener menos acoplamiento.
29
Departamento:
Materia:
Con el menor acoplamiento logramos que si hay que cambiar un modulo no impacte en otro modulo y as se produzca el efecto onda. Si hay demasiado acoplamiento, hay que analizar si no conviene juntarlos. Adems si un modulo no esta tan relacionado con otro, lo puedo usar en otro lado.
Parmetros tipo dato (se puede procesar). Parmetros tipo flag (no se pueden procesar).
Dentro del acoplamiento podemos encontrarnos tres subtipos, dependiendo de los datos que intercambien las unidades de software:
De datos: Cuando existe conexin entre los mdulos y la comunicacin es a travs de estructuras de datos simples (variables).
Se envan datos simples y se devuelven simples.
Estampado: Estn conectados y la comunicacin es a travs de estructuras de datos compuestas (registros).
30
Departamento:
Materia:
Se envan datos compuestos y devuelve simples.
Como el segundo modulo retorna datos simples la relacin es de datos y estampado. En estos caso se toma el de mayor acoplamiento. En ese caso sera estampado.
De control: Estn conectados y la comunicacin es a travs de un indicador, flag o seal a partir de la cual se pueden tomar deciciones en el modulo subordinado o superior.
La desventaja es que hay mucha relacin entre los mdulos, depende mucho uno de otro.
El modulo subordinado, debe saber que opcin le manda el superior. El modulo subordinado no le puede informar al superior que datos debe enviarle.
31
Departamento:
Materia:
Soluciones:
Que el subordinado devuelva un mensaje de error, y el superior decida qu hacer. Que el subordinado cometa error, y no devuelva nada.
Comn o por rea global: Pueden o no estar conectados, pero si comparten un rea global de datos (variables globales).
Si en una DB, tengo tres mdulos que comparten una tabla y decido sacar una columna de la tabla, debo modificar los mdulos que hagan referencia a la tabla.
32
Departamento:
Materia:
El objetivo final del diseo de software (o soluciones informticas) en materia de estos dos conceptos es: Reducir al mximo el acoplamiento entre componentes y aumentar la cohesin interna de cada componente.
1.2.2
ARQUITECTURA DEL SOFTWARE
Una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construccin del software para un sistema de informacin.
La Arquitectura de Software establece los fundamentos para que analistas, diseadores, programadores, etc. trabajen en una lnea comn que permita alcanzar los objetivos del sistema de informacin, cubriendo todas las necesidades.
Una arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como la
33
Departamento:
Materia:
mantenibilidad, adaptabilidad, flexibilidad e interaccin con otros sistemas de informacin.
Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin ente ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea.
La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema.
Una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco
34
Departamento:
Materia:
de referencia necesario para guiar la construccin del software para un sistema de informacin.
La Arquitectura de Software establece los fundamentos para que analistas, diseadores, programadores, etc. trabajen en una lnea comn que permita alcanzar los objetivos del sistema de informacin, cubriendo todas las necesidades.
Una arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interaccin con otros sistemas de informacin.
Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin entre ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea.
35
Departamento:
Materia:
La arquitectura de software, tiene que ver con el diseo y la implementacin de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeo de un sistema, as como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.
1.3
HEURISTICA DE DISEO
Heurstica de diseo: Las heursticas de diseo son un conjunto de datos que ayudan a mejorar la estructura del sistema, optimizando la secuencia.
La generacin de estas recomendaciones depende en gran medida del diseo especfico, as como de las caractersticas del equipo fsico donde se desarrolla la probabilidad estadstica del sistema.
Tamao de mdulo: El tamao del mdulo est relacionado con la modularidad, ms no solo de manera simple de "cortar en programa en ms piezas". Esto es, la modularidad tcnica no se incrementa simplemente cuando el tamao de mdulo decrece, mientras otros aspectos permanecen igual.
36
Departamento:
Materia:
Para la mayora de los propsitos, mdulos de mucho ms de cien sentencias, estn fuera del tamao ptimo con respecto a la economa de deteccin y correccin de errores. En el otro extremo de la escala el lmite es menos obvio. Excepto para ocasionales programadores "descarrilados", que piensan que modularidad es equivalente a partir un programa en mdulos de una sentencia, encontraremos que los mdulos muy pequeos, han sido diseados concisa y deliberadamente, y usualmente por razones funcionales.
Sin embargo, normalmente, mdulos menores a cinco a nueve lneas, deben considerarse para un replanteo.
Esto es especialmente relevante cuando existen muchos de estos mdulos muy pequeos en el sistema.
Sugerencias para el tamao ptimo de un mdulo han provenido de diferentes fuentes en el transcurso de los aos.
Una de las sugerencias conocidas es la de Baker quin recomienda que un mdulo debe consistir de aproximadamente cincuenta lneas, lo que coincide con el nmero de lneas que se pueden poner en una hoja de listado comn.
37
Departamento:
Materia:
Otra recomendacin proviene de Weinberg, cuyos estudios muestran que la comprensin de un programador se disipa fcilmente si el mdulo tiene ms de treinta lneas.
No siempre mdulo muy grandes o muy pequeos son necesariamente malos. La cuestin importante es que los mdulos reflejen la estructura del problema lo ms fielmente posible.
Descomponer un mdulo simplemente para llevarlo a un tamao ptimo, an perdiendo su significado con respecto a la estructura del problema, no es una buena estrategia.
Debemos examinar separadamente cada caso de mdulos muy grandes o muy pequeos.
Un mdulo demasiado grande a menudo puede deberse a dos razones principales:
Una factorizacin incompleta en mdulos subordinados apropiados. Dos o ms funciones han sido combinadas (frecuentemente con cohesin lgica) en un mismo mdulo. En el primer caso, se puede realizar una reduccin a travs de la identificacin y extraccin de subfunciones.
38
Departamento:
Materia:
Figura 1.1
MODULOS SOBRE LA HEURISTICAS DE DISEO
En el segundo caso, podemos descomponer el mdulo en sus funciones constitutivas.
FIGURA 1.2 SEGUNDO EJEMPLO DE FUNCION DE MODULOS
En cualquier caso, los diagramas de estructura pueden usarse como herramienta, y las modificaciones estructurales deben probarse sobre papel.
39
Departamento:
Materia:
Recalcamos que lo importe es dar sentido a la nueva estructura dentro del contexto del problema. Si no es posible dar una interpretacin razonable a la nueva estructura, debe mantenerse la original.
Cuando tratamos con mdulos muy pequeos, debemos distinguir dos casos: El mdulo atmico (nivel ms bajo) y modulo atmico.
En el caso de mdulos atmicos, las cuestiones a considerar son: la cantidad de llamadas desde mdulos superiores que recibe el mdulo (fan-in), y la sobrecarga (overhead) producido por el proceso de llamada a subrutina.
Un mdulo muy pequeo puede ser comprimido en sus mdulos superiores. Cuando el mdulo tiene un uso simple (fan-in = 1 ) esta es una alternativa a considerar.
Pero si el mdulo tiene usos mltiples (alto fan-in) puede ser muy peligroso absorberlo en sus mdulos superiores, porque se duplicar el esfuerzo de implementacin y mantenimiento del mismo.
En el caso de que la sobrecarga producida por el mecanismo de llamada a subrutina sea intolerable, se puede testear y depurar el mdulo independientemente
40
Departamento:
Materia:
y luego utilizar la inclusin en lnea del mdulo subordinado en sus superiores (ligado en tiempo de compilacin).
La mayora de los lenguajes dan facilidades para esto como ser el COPY del Cobol, #include del C, %INCLUDE del PL/I, las macros de la mayora de los assembler., etc., o utilizar facilidades de los preprocesadores de compilacin.
Cuando el mdulo es no atmico, el anlisis es ms complicado. Las opciones son comprimir el mdulo hacia arriba en su superior, o hacia abajo en un subordinado. Ambas opciones deben ser consideradas.
Un caso especial es el llamado mdulo fantasma, un mdulo que lo nico que contiene son llamadas a otros mdulos subordinados. Obviamente estos mdulos son el caso lmite de mdulos muy pequeos.
A travs de esta discusin, se asumi que el diseador conoce previo a la implementacin el tamao que tendrn los mdulos. Normalmente esto no requiere un proceso de estimacin sustancial.
La experiencia ha demostrado que el tamao comparativamente pequeo de mdulos en sistemas razonablemente modulares simplifica el proceso de estimacin. En adicin, el proceso de estimacin se torna ms exacto cuando el diseador tiene experiencia con la funcin que realizarn varios mdulos.
41
Departamento:
Materia:
Amplitud del Control (Fan-out)
La amplitud del control o ancho de salida (fan-out), es el nmero de subordinados inmediatos de un mdulo. Al igual que en con el tamao de mdulo, amplitudes de control muy altas o muy bajas, son indicadores de un posible diseo pobre.
Ya se ha visto anteriormente que la funcin de un administrador se torna muy compleja si el nmero de subordinados excede 7 2 subordinados inmediatos. En general deben verificarse anchos de salida mayores a 10 y aquellos de solamente 1 o 2. Tambin observaremos que una amplitud de control muy alta es ms peligroso que una baja.
Una amplitud de control demasiado baja puede incrementarse en la mayora de los casos descomponiendo el mdulo en subfunciones subordinadas adicionales, o comprimiendo el mdulo en sus superiores. Como se dijo en el punto anterior, esto es vlido si se puede dar a los nuevos mdulos un sentido dentro de la estructura del problema.
Una amplitud de control demasiado alta puede ser un indicativo de una reticencia por parte del diseador a delegar responsabilidades en mdulos subordinados. Sin embargo en la mayora de los casos, esto proviene de estructuras "panqueque" o fallas en la definicin de niveles intermedios. Para solucionar este
42
Departamento:
Materia:
problema, debe considerarse la posibilidad de agruparse varios subordinados en una funcin combinada. El principio de cohesin debe guiar este proceso para evitar mdulos de baja cohesin.
Ancho de Entrada (Fan-In)
Siempre que sea posible, desearemos maximizar el ancho de entrada de un mdulo (fan-in) durante el proceso de diseo. Cada instancia de mltiples entradas de un mdulo, representa que ha podido evitarse duplicidad de cdigo.
Sin embargo, un gran ancho de entrada no es algo que deba buscarse a cualquier costo. Por ejemplo, es ridculo combinar muchas funciones "no relacionadas" en un mdulo bajamente cohesivo, con el propsito de incrementar el fan-in.
Un gran ancho de entrada es alcanzado a travs de un proceso analtico que acompaa los pasos del proceso de diseo estructurado. Cada vez que vamos a dibujar un nuevo mdulo en el diagrama de estructura, primero debemos verificar si no existe ya algn otro mdulo que realice la funcin requerida.
Si es as, dibujaremos una flecha hacia la caja del mdulo ya existente en el diagrama, en lugar de dibujar una nueva. En orden de evitar un "enriedo" de flechas
43
Departamento:
Materia:
en el diagrama, pueden utilizarse conectores dentro de la pgina (un crculo) y fuera de pgina (un polgono), similarmente a la que se hace en los diagramas de flujo.
Es importante notar que la especificacin del fan-in es una tarea del diseador, no del implementador (codificador).
Un problema puede producirse cuando el nuevo mdulo es parecido pero no exactamente igual al mdulo existente. Si el diseador no distingue la diferencia subyacente entre ambos mdulos, pueden generarse problemas durante la integracin del sistema. Podrn fallar el nuevo mdulo, el anterior uso del mdulo existente.
En la sig. Figura La clave est en comprender cual es la parte comn de ambos mdulos, y aislarlo en un nuevo mdulo. Por ejemplo, supongamos que tenemos una funcin Q1 que parece ser similar a Q2. Si Q es la parte comn de ambas funciones, podemos reestructurar nuestro diseo de la siguiente manera:
44
Departamento:
Materia:
FIGURA 1.3 EJEMPLO FUNCIONES DE Q1 Y Q2
Las porciones remanentes Q1 y Q2 pueden reestructurarse absorbindolas en sus mdulos superiores si fueran pequeas. Podemos tener as una serie de alternativas diferentes.
FIGURA 1.4
REESTRUCTURACIOND E LOS MODULOS
45
Departamento:
Materia:
Alcance de Efecto / Alcance de Control
Cada decisin o sentencia condicional (if-then-else) en un sistema tiene algunas consecuencias: ciertos procesos se realizarn o no como resultado de una decisin. Equivalentemente podemos decir que cierto procesamiento es condicional en base a la salida o resultado de una decisin.
Es importante aprender donde se encuentran los resultados de una determinada decisin, dentro de una estructura modular. En orden de este estudio, introduciremos dos trminos nuevos: alcance de efecto y alcance de control.
El alcance de efecto de una decisin es la coleccin de todos los mdulos que contienen algn procesamiento que est condicionado por dicha decisin.
Aunque solo una pequea parte del procesamiento de un mdulo se vea afectada por la decisin. Si la activacin de un mdulo completo est condicionada por la decisin, el mdulo superior (invocador) tambin se incluye dentro del alcance de efecto.
El alcance de control de un mdulo es el mdulo mismo y todos sus subordinados.
46
Departamento:
Materia:
El alcance de control es un parmetro puramente estructural independiente de las funciones del mdulo.
Estamos en condiciones ahora de plantear la siguiente heurstica de diseo que involucra al alcance de efecto y al alcance de control:
En otras palabras, todos los mdulos que son afectados o influenciados por una determinada decisin deben estar subordinados finalmente al mdulo que toma la decisin.
La toma de decisiones y la estructura modular se interrelacionan mejor cuando las decisiones se toman a un nivel no ms alto que lo necesario dentro de estructura jerrquica, con el objetivo de ubicar el alcance de efecto dentro del alcance de control. Examinemos los siguientes cuatro casos:
47
Departamento:
Materia:
FIGURA 1.5 EJEMPLO DE MODULOS Y EFECTOS
El alcance de efecto de la decisin se representa por los mdulos sombreados. La Fig.1 ilustra un caso en el cual el alcance de efecto no es un subconjunto del alcance del control.
48
Departamento:
Materia:
La Fig.2 muestra una estructura en la cual el alcance de efecto est contenido dentro del alcance del control, pero puede discutirse que la decisin es realizada demasiado alta dentro de la jerarqua.
En la Fig. 3 se ha llevado la decisin al nivel justo para incluir el alcance de efecto dentro del alcance de control. La Fig. 4 muestra el caso ideal en el los mdulos a quienes afecta la decisin son subordinados inmediatos del mdulo que toma la decisin.
49
Departamento:
Materia:
UNIDAD II DISEO DE SISTEMAS
2.1 MODELO ESTRUCTURADO
Segn el modelo estructurado
El Anlisis Estructurado, fue seleccionado como tcnica de investigacin de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle.
50
Departamento:
Materia:
Este es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes.
Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a travs de un sistema, la representacin grfica de los procesos del sistema estar a cargo de los Diagramas de Flujos de Datos (DFD).
Que se relacionan con el Anlisis Estructurado
Smbolos grficos: iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.
Diccionario de datos; descripciones de todos los datos utilizados en el sistema. Descripciones de procesos y procedimientos; declaraciones formales que emplean tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas; estndares para describir y documentar el sistema en forma correcta y completa.
51
Departamento:
Materia:
Fase de diseo:
En esta fase, el diseo estructurado produce el modelo de diseo con los siguientes elementos:
Diseo de datos: Transforma el modelo de dominio de la informacin creado durante el anlisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidadrelacin y el contenido detallado de datos del diccionario de datos constituyen la base para el diseo de datos.
Diseo arquitectnico: Define la relacin entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de anlisis y de la interaccin de subsistemas definidos dentro del modelo de anlisis.
Diseo de interfaz: Describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la informacin necesaria para el diseo de la interfaz.
52
Departamento:
Materia:
Diseo procedimental: Transforma elementos estructurales de la arquitectura del programa en una descripcin procedimental de los componentes del software. Se obtiene a partir de la especificacin del proceso, la especificacin del control y el diagrama de transicin de estados.
Componentes:
Smbolos grficos: Identifica y describe los componentes de un sistema y las relaciones entre estos.
Diccionarios de datos: Describe todos los datos utilizados en el sistema pueden ser manual o automatizado.
Descripciones de procesos y procedimientos: descripcin tcnica para describir las actividades que se realizan los procesos.
Reglas: Pasos a seguir para describir y documentar el ven forma correcta y completa.
53
Departamento:
Materia:
Herramientas:
Diagrama de flujo de datos: Es la base para otros componentes y describe como navegan los datos entre procesos y elementos relacionados.
Diccionario de datos: Contiene las caractersticas de los campos y/o descripcin detallada de los diferentes objetos que componen el sistema
Diagrama de estructuras de datos: describe la relacin entre las entidades y los objetos (conjunta de informacin que contienen las entidades)
Segn el modelo estructurado
El Anlisis Estructurado, fue seleccionado como tcnica de investigacin de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle.
Este es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes.
54
Departamento:
Materia:
Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a travs de un sistema, la representacin grfica de los procesos del sistema estar a cargo de los Diagramas de Flujos de Datos (DFD).
Diseo del sistema
El uso de los Diagramas de Flujos de Datos (DFDs), es una herramienta que permite mostrar grficamente y de manera general, el funcionamiento del sistema y los procesos necesarios para su desarrollo.
Los DFDs se pueden dibujar con slo cuatro notaciones sencillas, en este caso, la notacin utilizada est basada en el enfoque de Gane y Sarson.
Origen/Destino de Datos: Representan entidades externas al sistema que se comunican con l y que estn fuera de su control. Las relaciones existentes entre las entidades no se representan en el DFD, ya que no son parte del sistema bajo estudio.
55
Departamento:
Materia:
Para este diseo forman parte de las entidades los Justiciables, la cual incluye a todas aquellas personas que tienen relacin directa con el proceso. Las entidades Secretaria, Juez y Asistente, quienes conforman al rgano jurdico y son los garantes de llevar a cabo el proceso judicial.
Procesos: Muestran la parte del sistema que transforma las entradas de datos en salida; en tal sentido, el diagrama (DFD Propuesto) muestra cinco (5) procesos considerados vitales para el funcionamiento y operatividad de la aplicacin:
Solicitar Copias Certificadas: en el cual se supervisa que las solicitudes a procesar estn conforme a los requisitos establecidos por el Cdigo de Procedimiento Civil, o alguna otra Ley que condicione la puesta en marcha de stas.
Verificar existencia de actas en el sistema: en el se constata que el acta que tiene relacin con la copia certificada solicitada est o no en los archivos del circuito y de ese modo se tenga acceso directo a l.
Generar copias certificadas: encargado de procesar los reportes generados por el sistema, en este caso la emisin directa de las Copias Certificadas solicitadas.
Registro automtico de libros: en l se almacena una serie de datos proveniente del procesamiento de las solicitudes.
56
Departamento:
Materia:
Firmar y sellar actas: Proceso manual que se limita a autenticar las Copias Certificadas previa su entrega al solicitante.
Flujo de datos: El flujo describe el movimiento de paquetes de datos que viajan desde una parte del sistema a otra. Estn representados por una flecha para mostrar su origen y su destino.
Almacn: Representa una coleccin de paquetes de datos que permanecen en estado de reposo. No est referido exclusivamente a medios de almacenamiento electrnico como bases de datos en discos duros, sino tambin a archiveros metlicos o cualquier otro medio que permita guardar datos en carpetas u hojas de papel.
2.2 MODELO ORIENTADO A OBJETOS
57
Departamento:
Materia:
Las tcnicas orientadas a objetos pretenden satisfacer tanto las necesidades de los usuarios finales como las de los desarrolladores de software mediante una cierta capacidad de modelar el mundo real.
El Modelado y Diseo Orientado a Objetos se funda en pensar acerca de problemas a resolver empleando modelos que se han organizado tomando como base conceptos del mundo real.
La unidad bsica es el objeto que combina las estructuras de datos con los comportamientos en una entidad nica.
La fase de anlisis determina lo que debe hacer la implementacin y la fase de diseo del sistema determina el plan de ataque.
La fase de diseo de objetos determina las definiciones completas de las clases y asociaciones que se utilizarn en la implementacin, as como las interfaces y algoritmos de los mtodos utilizados para implementar las operaciones. La fase de diseo de objetos aadir objetos internos para la implementacin y optimizar las estructuras de datos y los algoritmos. El diseo de objetos es anlogo a la fase preliminar de diseo del ciclo de vida de desarrollo de software tradicional.
58
Departamento:
Materia:
Aspectos generales del diseo de objetos
Durante el diseo de objetos, se ejecuta la estrategia seleccionada durante el diseo del sistema y se rellenan los detalles.
Se produce un desplazamiento del nfasis pasando de los conceptos del dominio de la aplicacin a los propios de las computadoras. Los objetos descubiertos durante el anlisis sirven como esqueleto del diseo, pero el diseador debe escoger distintas formas de implementarlos con el objetivo de minimizar el tiempo de ejecucin, la memoria y el costo. En particular, las operaciones identificadas durante el anlisis deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones internas ms sencillas. Las clases, atributos y asociaciones del anlisis deben de implementarse en forma de estructuras de datos especficas.
Es necesario introducir nuevas clases de objetos para almacenar resultados intermedios durante la ejecucin del programa y para evitar la necesidad de recalcularlos.
59
Departamento:
Materia:
La optimizacin del diseo no debera llevarse a extremos exagerados porque la facilidad de implementacin y mantenimiento y la extensibilidad son tambin objetivos importantes.
La Metodologa OMT se extiende desde el anlisis hasta la implementacin pasando por el diseo. En primer lugar, se construye un modelo de anlisis para abstraer los aspectos esenciales del dominio de la aplicacin sin tener en cuenta la implementacin eventual.
En este modelo se toman decisiones importantes que despus se completan para optimizar la implementacin en segundo lugar. Los objetos del dominio de la aplicacin constituyen el marco de trabajo del modelo de diseo, pero se implementan en trminos de objetos del dominio de la computadora.
Por ltimo, el modelo de diseo se implementa en algn lenguaje de programacin, base de datos o hardware.
60
Departamento:
Materia:
Tipos de modelos
Modelo de Objetos
Describe la estructura esttica (de datos), de los objetos del sistema (identidad, atributos y operaciones) y tambin sus relaciones. El modelo de objetos contiene diagramas de objetos.
Un diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones entre las clases.
El diagrama contiene clases de objetos organizados en jerarquas que comparten una estructura y comportamiento comunes y que estn asociadas a otras clases. Estas clases definen los atributos que lleva cada instancia de objeto y las operaciones que efecta o sufre cada uno. En cada instancia de la clase se guardan los valores de esos atributos.
61
Departamento:
Materia:
Modelo dinmico Describe los aspectos de comportamiento (de control) de un sistema que cambian con el tiempo. El modelo dinmico se utiliza para especificar e implementar los aspectos del control del sistema.
Los modelos dinmicos contienen diagramas de estados. Un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por sucesos o eventos.
Se especifican en este modelo la temporizacin y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos), y la organizacin de sucesos y de estados.
El modelo dinmico captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en la que estn implementadas.
62
Departamento:
Materia:
Las acciones de los diagramas de estado se corresponden con funciones procedentes del modelo funcional; los sucesos de un diagrama de estado pasan a ser operaciones que se aplican a objetos dentro del modelo de objetos.
Modelo funcional
Describe las transformaciones (de funcin), de valores de datos que ocurren dentro del sistema, captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se haga.
El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las dependencias entre los valores y el clculo de valores de salida a partir de los de entrada y de funciones, sin considerar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. Las funciones se invocan como acciones en el modelo dinmico y se muestran como operaciones que afectan a objetos en el modelo de objetos.
63
Departamento:
Materia:
2.3 MODELO BASADO EN COMPONENTES
Un componente es una pieza de cdigo pre elaborado que encapsula alguna funcionalidad expuesta a travs de interfaces estndar.
Es algo muy similar a lo que podemos observar en el equipo de msica que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseado para acoplarse perfectamente con sus pares, las conexiones son estndar y el protocolo de comunicacin est ya preestablecido. Al unirse las partes, obtenemos msica para nuestros odos. El paradigma de ensamblar componentes y escribir cdigo para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes.
64
Departamento:
Materia:
Desarrollo basado en componentes
El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Sin embargo, el modelo de desarrollo basado
en componentes configura aplicaciones desde componentes preparados de software (clases).
El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software.
Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un ndice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software.
65
Departamento:
Materia:
El proceso unificado de desarrollo de software representa un nmero de modelos de desarrollo basado en componentes que han sido propuestos en la industria.
El lenguaje de modelado unificado define los componentes. Utilizando una combinacin del desarrollo incremental e interactivo, el proceso unificado define la funcin del sistema aplicando un enfoque basado en escenarios.
El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos ms efectivos para la construccin de grandes sistemas y aplicaciones de software.
Una vez que la mayor parte de los aspectos funcionales de esta disciplina comienzan a estar bien definidos, la atencin de la comunidad cientfica comienza a centrarse en los aspectos extra funcionales y de calidad, como un paso hacia una verdadera ingeniera.
66
Departamento:
Materia:
En este artculo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen, con especial nfasis en los estndares internacionales que los definen y regulan, y en los problemas que se plantean en este tipo de entornos.
Beneficios del desarrollo de Software basado en componentes
El uso de este paradigma posee algunas ventajas:
Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
67
Departamento:
Materia:
Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes del sistema. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del tiempo.
La notacin de componentes
Un componente puede ser algo como un control Actives; tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio.
El diagrama de componentes
El diagrama de componentes muestra la relacin entre componentes de software, sus dependencias, su comunicacin su ubicacin y otras condiciones.
68
Departamento:
Materia:
Interfaces
Los componentes tambin pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente est ofreciendo y dejando disponibles a otros componentes de software y clases. Tpicamente, un componente est compuesto por numerosas clases y paquetes de clases internos. Tambin se puede crear a partir de una coleccin de componentes ms pequeos.
Los componentes y los nodos
Un diagrama de despliegue muestra el despliegue fsico del sistema en un ambiente de produccin (o de prueba). Muestra dnde se ubican los componentes, en qu servidores, mquinas o hardware. Puede representar los enlaces de redes.
Restricciones
69
Departamento:
Materia:
Los componentes pueden restricciones asignadas que indican el entorno en el que operan.
Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna funcin; las post-condiciones indican lo que debe ser verdadero despus de que un componente haya realizado algn trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente.
Anlisis del riesgo
Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.
Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad.
70
Departamento:
Materia:
Ventajas:
El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. - Reduce riesgos del proyecto - Incorpora objetivos de calidad - Integra el desarrollo con el mantenimiento
Desventajas:
Genera mucho tiempo en el desarrollo del sistema - Modelo costoso Requiere experiencia en la identificacin de riesgos.
Inconvenientes:
71
Departamento:
Materia:
Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).
2.4 DISEO DE LA ARQUITECTURA DEL SOFTWARE
Para poder entender el diseo, es necesario comprender que es la arquitectura de software.
Diseo de software: El diseo se ha descrito como un proceso multifase en el que se sintetizan representaciones de la estructura de los datos, la estructura del programa, las caractersticas de la interfaz y los detalles procedimentales desde los requisitos de la informacin.
El diseo:
72
Departamento:
Materia:
Una actividad en la que se toman decisiones importantes, frecuentemente de naturaleza estructural. Comparte con la programacin un inters por la abstraccin de la representacin de la informacin y de las secuencias de procesamiento, pero el nivel de detalle es muy diferente en ambos casos. El diseo construye representaciones coherentes y bien planificadas de los programas, concentrndose en las interrelaciones de los componentes de mayor nivel y en las operaciones lgicas implicadas en los niveles inferiores.
Se considera que:
El diseo est dirigido por la informacin. Los mtodos de diseo del software se obtienen del estudio de cada uno de los tres dominios del modelo de anlisis:
La arquitectura de software de un sistema de programa o computacin es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos.
La arquitectura no es el software operacional, Ms bien, es la representacin que capacita al ingeniero del software para:
73
Departamento:
Materia:
analizar la efectividad del diseo para la consecucin de los requisitos fijados, considerar las alternativas arquitectnicas en una etapa en la cual hacer cambios en el diseo es relativamente fcil, y Reducir los riesgos asociados a la construccin del software. Por qu es importante
la arquitectura?
Facilitan la comunicacin entre todas las partes interesadas en el desarrollo de un sistema basado en computadora. Destaca decisiones tempranas de diseo que tendrn un profundo impacto en todo el trabajo de ingeniera del software. Constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo est estructurado el sistema y de cmo trabajan juntos sus componentes.
El diseo de la arquitectura del software tiene en cuenta 2 niveles de la pirmide, el diseo de datos y el diseo arquitectnico.
El diseo de datos nos facilita la representacin de los componentes de datos de la arquitectura.
74
Departamento:
Materia:
El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e interacciones.
En el contexto del diseo arquitectnico:
Un componente del software puede ser tan simple como un mdulo de programa, pero tambin puede ser algo tan complicado como incluir bases de datos y software intermedio middleware) que permiten la configuracin de una red de clientes y servidores
El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e interacciones.
Para Ben van Berkel la introduccin del diagrama informtico en el proceso de diseo permite huir del uso reiterativo de tipologas arquitectnicas, es decir, permite huir de la idea preconcebida de quela arquitectura debe basarse en arquitectura, abriendo el campo de miras hacia otras ciencias ms avanzadas (sociopoltica, matemticas, biologa, fsica) que no comportan la carga de la tradicin.
75
Departamento:
Materia:
De este modo UNStudio pone en tela de juicio toda la historia de la arquitectura, afirmando que sta conduce equivocadamente a valorar con excesivo empeo el resultado formal de una obra y negar conceptos mucho ms importantes como el uso o el contexto. Como en un 'remake' de lo ocurrido con la aparicin del Movimiento Moderno, UNStudio establece que en arquitectura todo debe ser repensado para ajustarse a la nueva realidad social, el consumismo y la tecnificacin.
Ejemplo de un diseo arquitectnico:
76
Departamento:
Materia:
FIGURA 2.1 EJEMPLO DE DISEO ARQUITECTONICO
Por qu es importante la arquitectura?
Las representaciones de la arquitectura de software facilitan la comunicacin entre todas las partes (partcipes) interesadas en el desarrollo de un sistema basado en computadora.
El modelo de diseo arquitectnico y los patrones arquitectnicos contenidos dentro son transferibles.
Esto es, los estilos y patrones de arquitectura pueden ser aplicados en el diseo de otros sistemas y representados a travs de un conjunto de abstracciones que facilitan a los ingenieros del software la descripcin de la arquitectura de un modo predecible.
77
Departamento:
Materia:
Estilos arquitectnicos
Cada estilo describe una categora del sistema que contiene: un conjunto de componentes, que realiza una funcin requerida por el sistema, un conjunto de conectores que posibilitan la comunicacin, la coordinacin y la cooperacin entre los componentes; restricciones que definen como se puede integrar los componentes que forman el sistema; y modelos semnticos que permiten al diseador entender las propiedades globales de un sistema para analizar las propiedades conocidas de sus partes constituyentes.
Arquitecturas centradas a datos
En el centro de esta arquitectura se encuentra un almacn al que otros componentes acceden con frecuencia para actualizar, aadir, borrar o modificar los datos del almacn. El software del cliente accede a l almacn central, es decir accede a lo datos independientes de cualquier cambio en los datos o de las acciones de de cliente.
78
Departamento:
Materia:
Arquitecturas de flujo de datos
Se aplica cuando los datos de entrada son transformados a travs de una serie de componentes computacionales o manipulativos en los datos de salida. Un patrn tubera y filtro tiene un grupo de componentes llamados filtros, conectados por tuberas que transmiten datos de un componente al siguiente. El filtro est diseado para recibir entrada de datos de una forma y producir la salida de datos de una forma especfica. Si el flujo de datos degenera en una simple lnea de transformadores se le llama Secuencial por Lotes.
Arquitecturas de llamada y retorno
Permite al diseador del software construir una estructura de programa relativamente fcil de modificar y ajustar a escala. Existen 2 sub estilos:
Arquitectura de programa principal: Clasifica de programacin descompone las funciones en una jerarqua de control donde un programa principal llama a un nmero de componentes del programa, los cuales pueden tambin llamar a otros componentes.
79
Departamento:
Materia:
Arquitectura de llamada de procedimiento remoto: Los componentes de una arquitectura de programa principal/subprograma, estn distribuidos entre varias computadoras en una red.
Arquitecturas orientadas a objetos: Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos. La comunicacin y la coordinacin entre componentes se consiguen a travs del paso de mensaje.
Arquitecturas Estratificadas: Se crean diferentes capas y cada una realiza operaciones que progresivamente se aproximan mas al cuadro de instrucciones de la mquina. En la capa externa, los componentes sirven a las operaciones de interfaz de usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las capas intermedias proporcionan servicios de utilidad y funciones de software de aplicaciones.
Complejidad arquitectnica: Para evaluar la complejidad total de una arquitectura dada una tcnica consiste en consideran las relaciones de dependencias entre los componentes de la arquitectura.
80
Departamento:
Materia:
Existen tres tipos de dependencias:
Dependencias de compartimiento: Representan las relaciones de dependencia entre los consumidores que utilizan los mismos recursos o los productores que producen para los mismos consumidores.
Dependencias de flujo: Representan las relaciones de dependencias entre los productores y los consumidores de recursos.
Dependencias restrictivas: Representan las restricciones de un relativo flujo de control entre un cuadro de actividades.
Flujo de transformacin
La informacin debe introducirse y obtenerse del software en forma de mundo exterior, la informacin entra en el sistema a lo largo de caminos que transforman los datos externos a un formato interno. Estos caminos se identifican como flujo de
81
Departamento:
Materia:
entrada. La informacin entrante se pasa a travs de un centro de transformacin y empieza a moverse a lo largo de caminos que ahora conducen hacia fuera del software. Los datos que se mueven a lo largo de este camino se denominan flujo de salida.
Flujo de transaccin
El flujo de transaccin se caracteriza por datos que se mueven a lo largo de un camino de entrada que convierte la informacin del mundo exterior en una transaccin. La transaccin se evala y, basndose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de accin. El centro de flujo de informacin del que parten muchos de los caminos de accin se denomina centro de transaccin.
Diseo de datos
El diseo de datos (a veces llamado arquitectura de datos) crea un modelo de datos y/o informacin que se representa con un alto nivel de Abstraccin (la visin de datos del cliente/usuario).
82
Departamento:
Materia:
Este modelo de datos, es refinado en progresivas representaciones especficas de la implementacin, que pueden ser procesadas por un sistema basado en computadora.
Al nivel de los componentes del programa, el diseo de las estructuras de datos y de los algoritmos asociados requeridos para su manipulacin, son la parte esencial en la creacin de aplicaciones de alta calidad. Al nivel de aplicacin, la traduccin de un modelo de datos en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema.
Al nivel de negocios, el conjunto de informacin almacenada en las diferentes bases de datos y reorganiza en el almacn de datos facilita la minera de datos o el descubrimiento de conocimiento que puede influir en el prximo xito del negocio. Los objetos de datos son modelados utilizando diagramas de entidad-relacin y el diccionario de datos.
La actividad de diseo de datos traduce esos elementos del modelo de requisitos en estructuras de datos a nivel de los componentes del software y, cuando es necesario a arquitecturas de base de datos a nivel aplicacin.
83
Departamento:
Materia:
Un almacn de datos es un entorno de datos separado, que no est directamente integrado con las aplicaciones del da a da, pero que abarca todos los datos utilizados por una empresa.
Caractersticas de un almacn de base de datos:
Orientacin por materia: Esto nos lleva a una exclusin de datos que podran ser necesarios para una funcin particular del negocio.
Integracin: Sin tener en cuenta la fuente de datos, da consistencia nombrar convenciones, unidades y medidas, estructuras de codificacin y atributos fsicos.
Restriccin de tiempo: Para un entorno aplicacin orientado a transaccin, los datos son precisos en el momento del acceso y por un perodo de tiempo pequeo (60 a 90 das) antes del acceso. En un almacn de datos se accede a los datos en un momento especfico de tiempo.
No volatilidad: En el almacn de datos, los datos se cargan, pero despus de la primera transferencia, los datos no cambian.
84
Departamento:
Materia:
Modelo de datos
Este modelo de datos, es entonces refinado en progresivas representaciones especficas de la implementacin, que pueden ser procesadas por un sistema basado en computadora.
En muchas aplicaciones de software, la arquitectura de datos tendr una gran influencia sobre la arquitectura del software que debe procesarlo.
Estructura de datos
La estructura de datos ha sido siempre una parte importante del diseo de software. Al nivel de los componentes del programa, el diseo de las estructuras de
85
Departamento:
Materia:
datos y de los algoritmos asociados requeridos para su manipulacin, son la parte esencial en la creacin de aplicaciones de alta calidad.
A nivel de aplicacin, la traduccin de un modelo de datos (derivado como parte de la ingeniera de requisitos) en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema.
A nivel de negocios, el conjunto de informacin almacenada en las diferentes bases de datos y reorganizada en el almacn de datos facilita la minera de datos o el descubrimiento de conocimiento que puede influir en el propio xito del negocio.
Diseo de datos a nivel de componentes
Se centra en la representacin de estructuras de datos a las que se accede directamente a travs de uno o ms componentes del software.
86
Departamento:
Materia:
Principios para la especificacin de los datos:
Los principios del anlisis sistemtico aplicado a la funcin y al comportamiento deberan aplicarse tambin a los datos. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberan estar claramente identificadas. Se debera establecer un diccionario de datos y usarlo para definir el diseo de los datos y del programa Las decisiones de diseo de datos de bajo nivel deberan dejarse para el final del proceso de diseo. La representacin de las estructuras de los datos deberan conocerla solo aquellos mdulos que deban hacer uso directo de los datos contenidos dentro de la estructura. Deberan desarrollarse una biblioteca de estructuras de los datos tiles y de las operaciones que se les pueden aplicar. Un diseo del software y un lenguaje de programacin debera soportar la especificacin y realizacin de los tipos abstractos de datos.
87
Departamento:
Materia:
2.5 DISEO DE LA INTERFAZ DE USUARIO
Evolucin histrica
La tecnologa de interfaz de usuario, al igual que el hardware, ha pasado por una serie de generaciones [TESLER, 1991]. Estas generaciones contienen o parecen contener a las anteriores, y se pueden clasificar cronolgicamente como sigue [NIELSEN, 1993]:
Hasta 1945: no exista ningn paradigma de interfaz de usuario, y se haca acceso directo de forma manual al hardware.
19451955: Programacin en modo batch o por lotes. La primera generacin de interfaces no era interactiva, ya que la interaccin entre el sistema y el usuario se restringa a un nico punto en el tiempo.
88
Departamento:
Materia:
19551965: lenguajes de mandatos. Tambin denominadas interfaces en lnea. Los sistemas de tiempo compartido se inventaron alrededor de 1960 como un medio para permitir a varios usuarios tener acceso simultneo interactivo a un nico servidor [LEE et al., 19921. Uno de los problemas principales de estos sistemas es la pequea cantidad de recursos de ordenador disponibles para soportar la interfaz de cualquier usuario, por lo que, a menudo, se utilizan interfaces en lnea.
19651980: pantallas completas con mens estrictamente jerrquicos. El espacio de diseo de la interfaz es de dos dimensiones. Un uso clsico de la pantalla completa es el de los dilogos para rellenar informes, en los que el usuario tiene un nmero de campos etiquetados que puede editar en la secuencia que desee.
19801995: ventanas, iconos, mens y ratn. Tambin denominadas interfaces grficas de usuario. La mayora de las interfaces actuales de usuario pertenecen a esta categora, a veces denominada sistemas WIMP (Windows, Icons, Menus and Pointing device). Las interfaces windows aaden casi una tercera dimensin a las dos dimensiones inherentes a cada ventana debido a la posibilidad de superponer ventanas (est claro que superponer ventanas no es verdaderamente una tercera dimensin, ya que no es posible ver el contenido de la ventana que est debajo, por tanto, podramos decir que tienen dos dimensiones y media).
89
Departamento:
Materia:
1995-Futuro: interfaces no basadas en mandatos. La prxima generacin de interfaces ya se est desarrollando [NIELSEN, 1993b]. Es probable que la tendencia de las generaciones previas contine, y que la dimensin de las interfaces de usuario aumente de 2.5 a 3 o ms dimensiones.
Las formas comunes de aadir una dimensin a las interfaces de usuario consisten en aadir tiempo (en forma de animacin), sonido o voz, as como una verdadera tercera dimensin espacial en forma de sistemas de realidad virtual. Las dos predicciones ms fciles con respecto a la siguiente generacin de interfaces de usuario son que incluirn una dimensionalidad ms alta con ms tipos de medios y que sern altamente portables y personales, a la vez que se utiliza tecnologa de comunicaciones para conseguir una gran conectividad.
Otro estilo de dilogo para las interfaces de usuario de la prxima generacin puede ser el de las interfaces de usuario no basadas en mandatos. Todos los estilos de interfaz hasta ahora han tenido en comn, al menos, el concepto de mandato, y se basaban en el principio de un dilogo explcito entre el usuario y el ordenador en el que el usuario ordenaba al ordenador que hiciese ciertas acciones especficas.
El diseo de interfaces de usuario es una tarea que ha adquirido relevancia en el desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los motivos que conduzca a un sistema al xito o al fracaso.
90
Departamento:
Materia:
La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware y software de una computadora que presentan informacin al usuario y le permiten interactuar con la informacin y con el computadora. Tambin se puede considerar parte de la IU la documentacin (manuales, ayuda, referencia, tutoriales) que acompaa al hardware y al software. Si la IU est bien diseada, el usuario encontrar la respuesta que espera a su accin. Si no es as puede ser frustrante su operacin, ya que el usuario habitualmente tiende a culparse a s mismo por no saber usar el objeto.
Los
programas
son
usados
por
usuarios
con
distintos
niveles
de
conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz vlida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interaccin que ms se adece a sus objetivos en cada momento.
La mayora de los programas y sistemas operativos ofrecen varias formas de interaccin al usuario. Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseador (analoga de la construccin de una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a travs de su experiencia.
91
Departamento:
Materia:
Cuidados para modificar el mismo. Los modelos subyacen en la interaccin con las computadoras, de ah su importancia. Modelo del usuario: El usuario tiene su visin personal del sistema, y espera que ste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudindolo, ya sea realizando tests de usabilidad, entrevistas, o a travs de una realimentacin. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo. Para ello son de gran utilidad las metforas, que asocian un dominio nuevo a uno ya conocido por el usuario. Un ejemplo tpico es la metfora del escritorio, comn a la mayora de las interfaces grficas actuales. Modelo del diseador: El diseador mezcla las necesidades, ideas, deseos del usuario y los materiales de que dispone el programador para disear un producto de software. Es un intermediario entre ambos.
El modelo del diseador describe los objetos que utiliza el usuario, su presentacin al mismo y las tcnicas de interaccin para su manipulacin. Consta de tres partes: presentacin, interaccin y relaciones entre los objetos
(Figura 2.2 ).La presentacin es lo que primero capta la atencin del usuario, pero ms tarde pasa a un segundo plano, y adquiere ms importancia la interaccin con el producto para poder satisfacer sus expectativas.
La presentacin no es lo ms relevante y un abuso en la misma (por ejemplo, en el color) puede ser contraproducente, distrayendo al usuario.
92
Departamento:
Materia:
La segunda parte del modelo define las tcnicas de interaccin del usuario, a travs de diversos dispositivos. La tercera es la ms importante, y es donde el diseador determina la metfora adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia arriba.
Una vez definida la metfora y los objetos del interfaz, los aspectos visuales saldrn de una manera lgica y fcil.
FIGURA 2.2 PRESENTACION DE DISEO DE INTERFAZ
93
Departamento:
Materia:
Estos modelos deben estar claros para los participantes en el desarrollo de un producto, de forma que se consiga una interfaz atractiva y a la vez efectiva para el trabajo con el programa.
Una interfaz no es simplemente una cara bonita; esto puede impresionar a primera vista pero decepcionar a la larga. Lo importante es que el programa se adapte bien al modelo del usuario, cosa que se puede comprobar utilizando el programa ms all de la primera impresin.
Produccin de prototipos preliminares y dilogos
El propsito de la interfaz es muy simple: recoger de los usuarios la informacin del sistema y ponerla a disposicin de otros usuarios. La informacin recogida se llama entrada del sistema y se almacena en la base de datos para ponerla a disposicin de los dems usuarios. La informacin suministrada se llama salida del sistema. Es decir, el diseo de interfaces cubre tanto las entradas como las salidas.
94
Departamento:
Materia:
Las entradas y salidas pueden ser interactivas o por lotes. En una interfaz interactiva, el usuario se comunica directamente con el ordenador y la salida se obtiene muy poco tiempo despus de la entrada.
En el caso de entradas o salidas no interactivas, es decir, por lotes, las transacciones se renen en formularios en el punto de recepcin y despus se introducen en el ordenador al mismo tiempo. Estas transacciones se procesan y un tiempo despus se producen las salidas, las cuales se pasan al usuario. As, el tiempo transcurrido desde la introduccin de los datos hasta que se obtiene una respuesta puede ser considerable.
El diseo de interfaz interactivo provoca un dilogo hombre-mquina que permite un intercambio rpido de informacin entre los ordenadores y sus usuarios humanos, mientras que la interfaz no interactiva utiliza un soporte de papel para contener la informacin en el que las entradas normalmente se realizan en formularios especialmente diseados y las salidas se producen en un listado impreso.
95
Departamento:
Materia:
Ser necesario definir los formatos individuales de las pantallas utilizadas. En el caso de utilizar un paquete estndar, habr que evaluar la posibilidad de adoptar el tipo de formato del producto.
Entre los aspectos a considerar en los formatos de pantalla se destacan: encabezamiento, cuerpo principal, pie, teclas de funcin, teclas de ayuda y lneas de visualizacin de los mensajes de ayuda.
Tambin hay que describir, de forma detallada, los dilogos entre pantallas y su encadenamiento. Para ello, es til representarlas jerrquicamente, de forma que en los niveles superiores se representen los mens, y en los niveles inferiores las pantallas de dilogos, representativas de funciones o procesos concretos del sistema.
En esta representacin jerrquica nos interesa identificar los mens o dilogos concretos en funcin de los grupos de usuarios que los utilicen. Ser tambin necesario determinar los dilogos que se consideran crticos para un funcionamiento correcto del nuevo sistema. Los dilogos crticos se determinan en funcin de factores como: tipo de proyecto, grado de cambio con respecto al sistema actual, complejidad de los trabajos del sistema.
96
Departamento:
Materia:
Para ello, es til tener en cuenta los siguientes criterios: frecuencia de uso de estos dilogos, acceso a gran nmero de entidades de datos del sistema, gran nmero de elementos de datos asociados con el dilogo, cambio en el modo habitual de trabajo en el sistema actual, dilogos comunes a diferentes grupos de usuarios, dilogos que contienen opciones complejas de navegacin, etc.
Por ltimo, habr que realizar un prototipo dinmico que permita la simulacin (introduccin y validacin de datos por pantalla) para los dilogos considerados como crticos. Como recomendaciones para realizar este prototipo se tendr en cuenta: la determinacin del punto de entrada a cada pantalla y sus posibilidades de navegacin a otras, la especificacin de los datos asociados a cada pantalla (longitud, reglas de validacin, mensajes de ayuda, etc.), la evaluacin de la consistencia del diseo, asegurando que toda la informacin necesaria para el usuario est contemplada en las pantallas, y la confirmacin con el usuario de la validez de los diseos de pantalla realizados.
Ergonoma del diseo de la interfaz
El viaje al mundo del diseo de pantallas comienza con una discusin con el usuario, la parte ms importante de cualquier sistema informatizado. Como hemos
97
Departamento:
Materia:
comentado, es de aceptacin general que el sistema sera ms fcil de utilizar si lo hubiera diseado el usuario, por tanto, el diseo de la interfaz debe estimular al usuario hacindolo cmplice del sistema.
El ser humano es un organismo complejo con una variedad de atributos que tienen una influencia importante en el diseo de pantallas [GALITZ, 1989].
Entre estos atributos, destacamos la percepcin, la memoria, el aprendizaje, la capacidad y diferencias individuales. Por tanto, debe cultivarse la satisfaccin personal y, consecuentemente, mejorar la aceptacin del sistema, permitiendo que las personas mejoren sus conocimientos mientras utilizan el sistema.
Para realizar un buen trabajo, la interfaz con el ordenador debe ser, entre otras cosas, lo ms fcil, amigable y agradable posible, y se debe usar un dilogo que se acerque al lenguaje natural en vez de la jerga informtica. Entre las consideraciones a tener cuenta a la hora de disear pantallas se encuentran las siguientes:
98
Departamento:
Materia:
Caractersticas deseadas: simplicidad, claridad y fcil de comprender. Ser necesario tener claridad visual, de forma que los elementos estn agrupados de forma comprensible y con significado en vez de al azar y de forma confusa.
Saber dnde situar la informacin en la pantalla: Ser necesario indicar un punto de partida obvio en la esquina superior izquierda de la pantalla, reservar reas especficas de pantalla para diferentes tipos de informacin (como, por ejemplo, mandatos, mensajes de error, ttulos y campos de datos, de forma que esta consistencia se mantenga en todas las pantallas) y proporcionar una composicin que guste visualmente (es decir, que est balanceada, sea simtrica, sea predecible, secuencial, simple, con agrupamientos, etc.).
Saber qu informacin situar en la pantalla: Para ello, hay que poner slo la informacin que es esencial para la toma de una decisin o para la ejecucin de una accin (No inundar al usuario con informacin!) y poner todos los datos relacionados con una tarea en una nica pantalla (as el usuario no tiene que recordar datos de una pantalla a otra).
Saber cmo situar la informacin en la pantalla: As, en cuanto a las fuentes de letras, se recomienda utilizar minsculas para el texto con la letra inicial de la frase en maysculas; para las etiquetas, encabezamientos o subttulos utilizar maysculas.
99
Departamento:
Materia:
En cuanto a las palabras, se recomienda no usar jerga, sino utilizar palabras cortas, familiares, etc. Tambin es necesario saber como alinear y/o resaltar el texto y las palabras, dnde situar las ilustraciones, los campos de datos, etc.
La interfaz de entrada debe recoger todos los datos necesarios, sin introducir errores, para el sistema. De esta forma, la interfaz contiene una proteccin contra errores de entrada. As mismo, tambin debe recoger los datos minimizando el nmero de teclas pulsadas por el usuario.
Las entradas deben estar bien estructuradas y ser fciles de comprender y utilizar. Se deben usar nombres precisos y permitir abreviaturas cuando se necesiten introducciones rpidas de datos. Se deben evitar las entradas repetitivas. Igualmente, el diseo de la salida asegura que se extraen todos los datos suministrados por el sistema y que esas salidas estn estructuradas de forma que sean fciles de leer.
El color aade una nueva dimensin a la facilidad de uso de la pantalla, ya que atrae la atencin del usuario. Si se utiliza de forma adecuada, puede resaltar la organizacin lgica de una pantalla, facilitar la separacin de componentes y
100
Departamento:
Materia:
acentuar las diferencias. Por el contrario, si se usa inadecuadamente, puede distraer y fatigar la visin debilitando la facilidad de uso del sistema.
Por ejemplo, en las pantallas grficas se recomienda no utilizar ms de seis colores a la vez, evitar colores extremos (rojo y azul, amarillo y prpura), evitar colores que no tengan contraste (blanco y amarillo, rojos, azules).
Para finalizar, diremos que el diseo de pantallas es un proceso ordenado que empieza en los requisitos y finaliza con la implementacin.
Pruebas del software
Una de las caractersticas tpicas del desarrollo de software basado en el ciclo de vida es la realizacin de controles peridicos, normalmente coincidiendo con los hitos del proyecto o la terminacin de documentos. Estos controles pretenden una evaluacin de la calidad de los productos generados (especificacin de requisitos, documentos de diseo, etc.) para poder detectar posibles defectos cuanto antes. Sin
101
Departamento:
Materia:
embargo, todo sistema o aplicacin, independientemente de estas revisiones, debe ser probado mediante su ejecucin controlada antes de ser entregado al cliente. Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo del software, se denominan habitualmente pruebas.
Las pruebas constituyen un mtodo ms para poder verificar y validar el software. Se puede definir la verificacin como [IEEE, 1990] el proceso de evaluacin de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase. Por ejemplo, verificar el cdigo de un mdulo significa comprobar si cumple lo marcado en la especificacin de diseo donde se describe.
Por otra parte, la validacin es el proceso de evaluacin de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. As, validar una aplicacin implica comprobar si satisface los requisitos marcados por el usuario. Podemos recurrir a la clsica explicacin informal de Boehm de estos conceptos:
Verificacin: estamos construyendo correctamente el producto?
102
Departamento:
Materia:
Validacin: estamos construyendo el producto correcto?
Como hemos dicho, las pruebas permiten verificar y validar el software cuando ya est en forma de cdigo ejecutable. A continuacin, expondremos algunas definiciones de conceptos relacionados con las pruebas.
Definiciones
Las siguientes definiciones son algunas de las recogidas en el diccionario IEEE en relacin a las pruebas [IEEE, 1990], que complementamos con otras ms informales:
Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta 2 en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto. Para Myers [MYERS, 1979], probar (o la prueba) es el proceso de ejecutar un programa con el fin de encontrar errores. El nombre prueba, adems de la actividad de probar, se puede utilizar para designar un conjunto de casos y procedimientos de prueba [IEEE, 1990].
103
Departamento:
Materia:
Caso de prueba (test case): un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito. Tambin se puede referir a la documentacin en la que se describen las entradas, condiciones y salidas de un caso de prueba.
Defecto (defect, fault, bug): un defecto en el software como, por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa.
Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.
Error (error): tiene varias acepciones:
La diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o tericamente correcto. Por ejemplo, una diferencia de dos centmetros entre el valor calculado y el real.
104
Departamento:
Materia:
Un defecto: Por ejemplo, una instruccin incorrecta en un programa. Un resultado incorrecto: Por ejemplo, un programa ofrece como resultado de la raz cuadrada de 36 el valor 7 en vez de 6.
Una accin humana que conduce a un resultado incorrecto (una metedura de pata). Por ejemplo, que el operador o el programador pulse una tecla equivocada. Nosotros desecharemos las acepciones 2 y 3, ya que coinciden con las definiciones de defecto y fallo, para evitar equvocos.
El proceso de prueba
El proceso de prueba comienza con la generacin de un plan de pruebas en base a la documentacin sobre el proyecto y la documentacin sobre el software a probar. A partir de dicho plan, se entra en detalle diseando pruebas especficas basndose en la documentacin del software a probar.
Una
vez
detalladas
las
pruebas
(especificaciones
de
casos
de
procedimientos), se toma la configuracin del software (revisada, para confirmar que
105
Departamento:
Materia:
se trata de la versin apropiada del programa) que se va a probar para ejecutar sobre ella los casos. En algunas situaciones, se puede tratar de reejecuciones de pruebas, por lo que es conveniente tener constancia de los defectos ya detectados aunque an no corregidos. A partir de los resultados de salida, se pasa a su evaluacin mediante comparacin con la salida esperada. A partir de sta, se pueden realizar dos actividades:
La depuracin (localizacin y correccin de defectos). El anlisis de la estadstica de errores.
La depuracin puede corregir o no los defectos. Si no consigue localizarlos, puede ser necesario realizar pruebas adicionales para obtener ms informacin. Si se corrige un defecto, se debe volver a probar el software para comprobar que el problema est resuelto.
Por su parte, el anlisis de errores puede servir para realizar predicciones de la fiabilidad del software y para detectar las causas ms habituales de error y mejorar los procesos de desarrollo.
106
Departamento:
Materia:
Tcnicas de diseo de casos de prueba
El diseo de casos de prueba est totalmente mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy sencillo que slo suma dos nmeros enteros de dos cifras (del 0 al 99). Si quisiramos probar, simplemente, todos los valores vlidos que se pueden sumar, deberamos probar 10.000 combinaciones distintas de cien posibles nmeros del primer sumando y cien del segundo.
Pensemos que an quedaran por probar todas las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un nmero). La conclusin es que, si para un programa tan elemental debemos realizar tantas pruebas, pensemos en lo que supondra un programa medio.
En consecuencia, las tcnicas de diseo de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarn los defectos existentes (ya que la seguridad total slo puede obtenerse de la prueba exhaustiva,
107
Departamento:
Materia:
que no es practicable) sin necesidad de consumir una cantidad excesiva de recursos (por ejemplo, tiempo para probar o tiempo de ejecucin).
Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este equilibrio no es sencillo, lo que convierte a las pruebas en una disciplina difcil que est lejos de parecerse a la imagen de actividad rutinaria que suele sugerir.
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea fundamental para el diseo de casos de prueba consiste en elegir algunas de ellas que, por sus caractersticas, se consideren representativas del resto. As, se asume que, si no se detectan defectos en el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que depende de la eleccin de los casos) en que el programa no tiene defectos.
La dificultad de esta idea es saber elegir los casos que se deben ejecutar. De hecho, una eleccin puramente aleatoria no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes. Por ejemplo, en el caso del programa de suma de dos nmeros, elegir cuatro pares de sumandos al azar no
108
Departamento:
Materia:
aporta mucha seguridad a la prueba (una probabilidad de 4/10.000 de cobertura de posibilidades). Por eso es necesario recurrir a ciertos criterios de eleccin que veremos a continuacin.
Existen tres enfoques principales para el diseo de casos:
El enfoque estructural o de caja blanca. Consiste en centrarse en la estructura interna (implementacin) del programa para elegir los casos de prueba. En este caso, la prueba ideal (exhaustiva) del software consistira en probar todos los posibles caminos de ejecucin, a travs de las instrucciones del cdigo, que puedan trazarse.
Pruebas estructurales. (Prueba de la caja negra)
El enfoque funcional o de caja negra, consiste en estudiar la especificacin de las funciones, la entrada y la salida para derivar los casos. Aqu, la prueba ideal del software consistira en probar todas las posibles entradas y salidas del programa.
109
Departamento:
Materia:
El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. La prueba exhaustiva consistira en probar todas las posibles entradas al programa.
Estos enfoques no son excluyentes entre s, ya que se pueden combinar para conseguir una deteccin de defectos ms eficaz. Veremos a continuacin una presentacin de cada uno de ellos.
Pruebas estructurales. (Prueba de la caja blanca)
Como hemos dicho, las pruebas exhaustivas son impracticables. Podemos recurrir al clsico ejemplo de Myers [MYERS, 1979] de un programa de 50 lneas con 25 sentencias IF en serie, en el que el nmero total de caminos contiene 33,5 millones de secuencias potenciales (contando dos posibles salidas para cada IF tenemos 225 posibles caminos). El diseo de casos tiene que basarse en la eleccin de caminos importantes que ofrezcan una seguridad aceptable en descubrir defecto, y para ello se utilizan los llamados criterios de cobertura lgica. Antes de pasar a examinarlos, conviene sealar que estas tcnicas no requieren el uso de ninguna representacin grfica especfica del software, aunque es habitual tomar como base los llamados diagramas de flujo de control (flowgraph charts o flowcharts).
110
Departamento:
Materia:
En el recuadro adjunto pueden consultarse algunas recomendaciones para dibujar los grafos de flujo de los programas para poder generar los casos de prueba correspondientes. Tambin existen herramientas que dibujan el grafo de flujo de un programa slo con facilitar el cdigo fuente del mismo como entrada.
2.6 DISEO DE BASE DE DATOS
Hoy en da las empresas manejan una gran cantidad de datos. Cualquier empresas que se precie debe tener almacenados todos estos datos en una base de datos para poder realizarlos mediante una aplicacin profesional; sin esta funcionalidad resultara imposible tratar y manejar en su totalidad los datos que lleva a cabo la empresa y se perdera un tiempo y un dinero muy valiosos.
Uno de los pasos cruciales en la construccin de una aplicacin que maneje una base de datos, es sin duda, el diseo de la base de datos.
Si las tablas no son definidas apropiadamente, podemos tener muchos dolores de cabeza al momento de ejecutar consultas a la base de datos para tratar de obtener algn tipo de informacin.
111
Departamento:
Materia:
No importa si nuestra base de datos tiene slo 20 registros, o algunos cuantos miles, es importante asegurarnos que nuestra base de datos est correctamente diseada para que tenga eficiencia y que se pueda seguir utilizando por largo del tiempo.
En este artculo, se mencionarn algunos principios bsicos del diseo de base de datos y se tratarn algunas reglas que se deben seguir cuando se crean bases de datos.
Dependiendo de los requerimientos de la base de datos, el diseo puede ser algo complejo, pero con algunas reglas simples que tengamos en la cabeza ser mucho ms fcil crear una base de datos perfecta para nuestro siguiente proyecto.
Diseo de bases de datos
Son muchas las consideraciones a tomar en cuenta al momento de hacer el diseo de la base de datos, quiz las ms fuertes sean:
La velocidad de acceso, El tamao de la informacin, El tipo de la informacin, Facilidad de acceso a la informacin,
112
Departamento:
Materia:
Facilidad para extraer la informacin requerida, El comportamiento del manejador de bases de datos con cada tipo de informacin.
No obstante que pueden desarrollarse sistemas de procesamiento de archivo e incluso manejadores de bases de datos basndose en la experiencia del equipo de desarrollo de software logrando resultados altamente aceptables, siempre es recomendable la utilizacin de determinados estndares de diseo que garantizan el nivel de eficiencia ms alto en lo que se refiere a almacenamiento y recuperacin de la informacin.
De igual manera se obtiene modelos que optimizan el aprovechamiento secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse al usuario.
Objetivos del diseo de bases de datos
Entre las metas ms importantes que se persiguen al disear un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.
113
Departamento:
Materia:
FIGURA 2.3 ALGUNAS D ELAS METAS QUE PERSIGE EN DISEADOR DE BASE DE DATOS
Diseo de bases de datos
En este apartado se describen con ms detalle los objetivos de cada una de las etapas del diseo de bases de datos: diseo conceptual, diseo lgico y diseo fsico. La metodologa a seguir en cada una de estas etapas se describe en los tres captulos que siguen a ste.
114
Departamento:
Materia:
Diseo conceptual: En esta etapa se debe construir un esquema de la informacin que se usa en la empresa, independientemente de cualquier consideracin fsica. A este esquema se le denomina esquema conceptual. Al construir el esquema, los diseadores descubren la semntica (significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. El objetivo es comprender:
La perspectiva que cada usuario tiene de los datos. La naturaleza de los datos, independientemente de su representacin fsica. El uso de los datos a travs de las reas de aplicacin.
El esquema conceptual se puede utilizar para que el diseador transmita a la empresa lo que ha entendido sobre la informacin que sta maneja. Para ello, ambas partes deben estar familiarizadas con la notacin utilizada en el esquema. La ms popular es la notacin del modelo entidad-relacin, que se describir en el captulo dedicado al diseo conceptual. El esquema conceptual se construye utilizando la informacin que se encuentra en la especificacin de los requisitos de usuario.
115
Departamento:
Materia:
El diseo conceptual es completamente independiente de los aspectos de implementacin, como puede ser el SGBD que se vaya a usar, los programas de aplicacin, los lenguajes de programacin, el hardware disponible o cualquier otra consideracin fsica. Durante todo el proceso de desarrollo del esquema conceptual ste se prueba y se valida con los requisitos de los usuarios. El esquema conceptual es una fuente de informacin para el diseo lgico de la base de datos.
Diseo lgico: El diseo lgico es el proceso de construir un esquema de la informacin que utiliza la empresa, basndose en un modelo de base de datos especfico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideracin fsica.
En esta etapa, se transforma el esquema conceptual en un esquema lgico que utilizar las estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerrquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema lgico, ste se va probando y validando con los requisitos de usuario. La normalizacin es una tcnica que se utiliza para comprobar la validez de los esquemas lgicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos redundantes. Esta tcnica se presenta en el captulo dedicado al diseo lgico de bases de datos.
El esquema lgico es una fuente de informacin para el diseo fsico. Adems, juega un papel importante durante la etapa de mantenimiento del sistema, ya que
116
Departamento:
Materia:
permite que los futuros cambios que se realicen sobre los programas de aplicacin o sobre los datos, se representen correctamente en la base de datos.
Tanto el diseo conceptual, como el diseo lgico, son procesos iterativos, tienen un punto de inicio y se van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje en el que el diseador va comprendiendo el funcionamiento de la empresa y el significado de los datos que maneja.
El diseo conceptual y el diseo lgico son etapas clave para conseguir un sistema que funcione correctamente. Si el esquema no es una representacin fiel de la empresa, ser difcil, sino imposible, definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la base de datos.
Tambin puede ser difcil definir la implementacin fsica o el mantener unas prestaciones aceptables del sistema. Adems, hay que tener en cuenta que la capacidad de ajustarse a futuros cambios es un sello que identifica a los buenos diseos de bases de datos. Por todo esto, es fundamental dedicar el tiempo y las energas necesarias para producir el mejor esquema que sea posible.
117
Departamento:
Materia:
Diseo fsico: El diseo fsico es el proceso de producir la descripcin de la implementacin de la base de datos en memoria secundaria: estructuras de almacenamiento y mtodos de acceso que garanticen un acceso eficiente a los datos.
Para llevar a cabo esta etapa, se debe haber decidido cul es el SGBD que se va a utilizar, ya que el esquema fsico se adapta a l. Entre el diseo fsico y el diseo lgico hay una realimentacin, ya que algunas de las decisiones que se tomen durante el diseo fsico para mejorar las prestaciones, pueden afectar a la estructura del esquema lgico.
En general, el propsito del diseo fsico es describir cmo se va a implementar fsicamente el esquema lgico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto consiste en:
Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas.
Determinar las estructuras de almacenamiento y los mtodos de acceso que se van a utilizar para conseguir unas prestaciones ptimas.
118
Departamento:
Materia:
2.7 DISEO DE CONTROLES Y PROCESOS
Definicin de control
El control es una etapa primordial en la administracin, pues, aunque una empresa cuente con magnficos planes, una estructura organizacional adecuada y una direccin eficiente, el ejecutivo no podr verificar cul es la situacin real de la organizacin i no existe un mecanismo que se cerciore e informe si los hechos van de acuerdo con los objetivos.
Comprobacin, inspeccin, intervencin, direccin mando y regulacin de algn fenmeno (proceso, actividad).
Por qu es necesario controlar un proceso?
Incremento de la productividad. Alto costo de mano de obra .
119
Departamento:
Materia:
Seguridad. Alto costo de materiales. Mejorar la calidad. Reduccin de tiempo.
De manufactura
Reduccin de inventario en proceso Certificacin (mercados internacionales) Proteccin del medio ambiente (desarrollo sustentable)
El proceso de diseo del sistema de control
Para poder disear un sistema de control automtico, se requiere conocer el proceso que se desea controlar, es decir, conocer la ecuacin diferencial que describe su comportamiento, utilizando las leyes fsicas, qumicas y/o elctricas, computacionales etc. A esta ecuacin diferencial se le llama modelo del proceso. Una vez que se tiene el modelo, se puede disear el controlador.
120
Departamento:
Materia:
Definicin de diseo de sistemas
El diseo de sistemas es la evaluacin de las distintas soluciones alternativas y la especificacin de una solucin detallada a un problema de informacin.
Actividades:
1. Investigar las opciones y los criterios tcnicos
Calidad de documentacin. Facilidad de aprendizaje. Facilidad de uso. Tiempo de respuesta. Productividad. Nmero de copias instaladas.
121
Departamento:
Materia:
Madurez de la solucin. Licencias. Formacin. Tamao mximo de archivos y bases de datos.
Controles internos
El diseo de sistemas se encarga de:
1. Analizar y distribuir datos 2. Analizar y distribuir los procesos 3. Dividir en unidades de diseo 4. Disear bases de datos y o archivos 5. Disear entradas y salidas informticas 6. Disear interfaces interactivas de usuario
122
Departamento:
Materia:
7. Presentar y revisar el diseo
Actividades que se desarrollan en el diseo de control y proceso:
Actividad de Definicin de la Arquitectura del Sistema. Definicin de la arquitectura del sistema. Definicin de Niveles de Arquitectura. Identificacin de Requisitos de Diseo y Construccin. Especificacin de Estndares y Normas de Diseo y Construccin. Identificacin de Subsistemas de Diseo. Especificacin de Requisitos de Operacin y Seguridad. Generacin del cdigo de los componentes y procedimientos. Generacin del Cdigo de Componentes. Generacin del Cdigo de los Procedimientos de Operacin y Seguridad
123
Departamento:
Materia:
Actividad de definicin de la arquitectura del sistema en esta actividad se establece:
El particionamiento fsico del sistema de informacin. La organizacin en subsistemas de diseo. La especificacin del entorno tecnolgico. Los requisitos de operacin, administracin, seguridad y control de acceso. Se completan los catlogos de requisitos y normas. Se crea un catlogo de excepciones del sistema, en el que se registran las situaciones de funcionamiento secundario o anmalo que se estime oportuno considerar y, por lo tanto, disear y probar.
Definicin de la arquitectura del sistema en esta actividad se define la:
124
Departamento:
Materia:
Arquitectura general del sistema de informacin, especificando las distintas particiones fsicas del mismo. La descomposicin lgica en subsistemas de diseo y la ubicacin de cada subsistema en cada particin. Se especifica detalladamente la infraestructura tecnolgica necesaria para dar soporte al sistema de informacin. El entorno Tecnolgico del Sistema, comprende la especificacin del entorno tecnolgico, las restricciones tcnicas y la planificacin de capacidades. Se definen los procedimientos de Operacin y Administracin del Sistema. Procedimientos de Seguridad y Control de Acceso. Se definen los requisitos de operacin, seguridad y control, especificando los procedimientos necesarios para su cumplimiento.
Definicin de niveles de arquitectura
125
Departamento:
Materia:
En esta tarea se describen los niveles de la arquitectura software, mediante la definicin de las principales particiones fsicas del sistema de informacin, representadas como nodos y comunicaciones entre nodos. Los elementos que se deben de especificar son:
Gestores de datos. Tipos de puesto cliente. Tipos de dispositivos de impresin. Monitores de teleproceso. Servidores. Comunicaciones.
Identificacin de requisitos de diseo y construccin
En esta tarea se realiza la especificacin de los requisitos que estn directamente relacionados con el diseo o la construccin del sistema de informacin.
126
Departamento:
Materia:
Estos requisitos son:
Lenguajes. Rendimiento de los distintos elementos de la arquitectura. Criterios de ubicacin de mdulos y datos en los distintos nodos. Especificacin de Estndares y Normas de Diseo y Construccin. En esta tarea se definen: Los estndares tcnicos o normas. Recomendaciones que estn relacionados con la adopcin o diseo de una arquitectura o infraestructura tecnolgica concreta, y que condicionan el diseo o la construccin del sistema de informacin.
Identificacin de subsistemas de diseo.
127
Departamento:
Materia:
En esta tarea se divide de forma lgica el sistema de informacin en subsistemas de diseo, con el fin de reducir la complejidad y facilitar el mantenimiento.
Especificacin de requisitos de operacin y seguridad.
El objetivo de esta tarea es definir los procedimientos de seguridad y operacin necesarios para el adecuado funcionamiento del sistema y garantizar el cumplimiento de los niveles de servicios que exigir el sistema en cuanto a la gestin de operaciones (procesos por lotes, seguridad, comunicaciones, etc.).
Se establecen los requisitos de seguridad y control de acceso necesarios para garantizar la proteccin del sistema y minimizar el riesgo de prdida, alteracin o consulta indebida de la informacin.
Para ello, se disean los procedimientos relacionados con: Acceso al sistema y a sus recursos (datos, transacciones, libreras, etc.). Mantenimiento de la integridad y confidencialidad de los datos.
128
Departamento:
Materia:
Control y registro de accesos al sistema (logs, certificacin, etc.). Copias de seguridad y recuperacin de datos y su periodicidad. Recuperacin ante catstrofes. Se definen los requisitos de operacin para los distintos elementos del sistema (mdulos, clases, estructuras fsicas de datos, sistemas de ficheros) Control y planificacin de trabajos. Recuperacin y reanudacin de trabajos. Distribucin de informacin generada por el sistema. Control y seguimiento del correcto funcionamiento de los procedimientos de backup y recuperacin utilizados habitualmente.
Generacin del cdigo de los componentes y procedimientos.
El objetivo de esta actividad es la codificacin de los componentes del sistema de informacin, a partir de las especificaciones de construccin obtenidas en el proceso Diseo del Sistema de Informacin (DSI), as como la construccin de los procedimientos de operacin y seguridad establecidos para el mismo.
129
Departamento:
Materia:
Generacin del Cdigo de Componentes
En esta tarea se genera el cdigo correspondiente a cada uno de los componentes del sistema de informacin, identificados en la tarea Definicin de Componentes y Subsistemas de Construccin.
Generacin del Cdigo de los procedimientos de operacin y seguridad
El objetivo de esta tarea es generar los procedimientos de operacin y administracin del sistema de informacin, as como los procedimientos de seguridad y control de acceso, necesarios para ejecutar el sistema una vez que se haya implantado y est en produccin. Para la generacin de dichos procedimientos se tienen en cuenta, tambin, los estndares y normas de la instalacin recogidos en el catlogo de normas.
130
Departamento:
Materia:
2.8
APLICACIN DE METRICAS PARA LA EVALUACION DEL
DISEO
Una mtrica es un instrumento que cuantifica un criterio.
El concepto de mtrica es el trmino que describe muchos y muy variados casos de medicin. Siendo una mtrica una medida estadstica (no cuantitativa como en otras disciplinas ejemplo fsica) que se aplica a todos los aspectos de calidad de software, los cuales deben ser medidos desde diferentes puntos de vista como el anlisis, construccin, funcional, documentacin, mtodos, proceso, usuario, entre otros.
131
Departamento:
Materia:
2.4 EJEMPLO DE METRICAS PARA COMPARAR ARQUETECTURA DE SOFTWARE
Una estructura de proyecto que sirve de gua al equipo de trabajo e involucra a los usuarios y a los puestos directivos en su desarrollo y en sus puntos decisivos.
Un conjunto de productos finales a desarrollar. Las diferentes responsabilidades y funciones de los miembros del equipo de proyecto y de los usuarios. Una serie de tcnicas que ayudan a llevar a cabo los pasos anteriores.
132
Departamento:
Materia:
Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad.
Las mtricas
En la mayora de los desafos tcnicos, las mtricas nos ayudan a entender tanto el proceso tcnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad.
El principio, podra parecer que la necesidad de la medicin e s algo evidente. Despus de todo es lo que nos permite cuantificar y por consiguiente gestionar de forma ms efectiva. Pero la realidad puede ser muy deferente. Frecuentemente la medicin con lleva una gran controversia y discusin.
La medicin es muy comn en el mundo de la ingeniera. Medimos potencia de consumo, pesos, dimensiones fsicas, temperaturas, voltajes, seales de ruidos por mencionar algunos aspectos. Desgraciadamente la medicin se aleja de lo comn en el mundo de la ingeniera del software.
133
Departamento:
Materia:
Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas. Hay varias razones para medir un producto.
1. Para indicar la calidad del producto. 2. Para evaluar la productividad de la gente que desarrolla el producto. 3. Par evaluar los beneficios en trminos de productividad y de calidad, derivados del uso de nuevos mtodos y herramientas de la ingeniera de software. 4. Para establecer una lnea de base para la estimacin. 5. Para ayudar a justificar el uso de nuevas herramientas o de formacin adicional.
Las mediciones del mundo fsico pueden englobarse en dos categoras: medidas directas y medidas indirectas.
Medidas directas: En el proceso de ingeniera se encuentran el costo, y el esfuerzo aplicado, las lneas de cdigo producidas, velocidad de ejecucin, el tamao de memoria y los defectos observados en un determinado periodo de tiempo.
Medidas Indirectas: Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc.
134
Departamento:
Materia:
Mtricas del software: Son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.
Mtricas tcnicas: Se centran en las caractersticas de software por ejemplo: la complejidad lgica, el grado de modularidad. Mide la estructura del sistema, el cmo est hecho.
Mtricas de calidad: proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.
Mtricas de productividad: Se centran en el rendimiento del proceso de la ingeniera del software. Es decir que tan productivo va a ser el software que voy a disear.
Mtricas orientadas a la persona: Proporcionan medidas e informacin sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y mtodos. Son las medidas que voy a hacer de mi personal que va har el sistema.
135
Departamento:
Materia:
Mtricas orientadas al tamao: Es para saber en qu tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organizacin de software mantiene registros sencillos.
Mtricas orientadas a la funcin: Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las mtricas orientadas a la funcin se centran en la funcionalidad o utilidad del programa.
Las mtricas orientadas a la funcin fueron el principio propuestas por Albercht quien sugiri un acercamiento a la medida de la productividad denominado mtodo del punto de funcin. Los puntos de funcin que obtienen utilizando una funcin emprica basando en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivos de la complejidad del software.
Inicio del Plan: Determina el arranque formal del plan de sistemas, con el apoyo del nivel ms alto de la organizacin.
Definicin y Organizacin: Detalla y concreta la descripcin del PSI asignando un calendario y recursos humanos al mismo.
136
Departamento:
Materia:
Estudio informacin relevante: Se analiza informacin de inters para el correcto desarrollo del plan de sistemas
Identificacin requisitos: Obtiene la especificacin de requisitos que deben tener los sistemas de informacin analizados por el plan de sistemas.
Estudio S.I. actuales: Obtiene una valoracin de la situacin actual.
Diseo modelo: Identifica y define los S.I. Que van a dar soporte a los procesos afectados por el Plan de Sistemas de Informacin.
Arquitectura tecnolgica: Se propone la arquitectura tecnolgica que d soporte al modelo de informacin y sistemas de informacin.
Definicin plan: Se elabora y detalla el plan de sistemas de informacin: definicin de proyectos, actividades, calendario y recursos para implementar los sistemas de informacin e infraestructura tecnolgica
Revisin y aprobacin: Se somete el plan a la revisin ltima y aprobacin de la direccin.
137
Departamento:
Materia:
Documentacin:
Catlogo de requisitos. Arquitectura de informacin. Modelo de informacin. Modelo de sistemas de informacin. Arquitectura tecnolgica. Plan de accin. Plan de proyectos. Plan de mantenimiento. Fases de la mtrica.
Mtricas como planeacin de sistemas
Los objetivos principales de las mtricas
Comprender mejor la calidad del producto.
138
Departamento:
Materia:
Estimar la efectividad del proceso. Mejorar la calidad del trabajo realizado en el nivel del proyecto.
Desventajas de las metricas
Uno de los problemas que tienen las mtricas es que no existe un esquema de criterios generalmente aceptado (un estndar). Como no hay acuerdo en los criterios involucrados, abundan las propuestas de mtricas que abordan la calidad con criterios propios.
Otro problema de las mtricas es que no proporcionan informacin por s solas y a veces en vez de claridad aportan confusin a la contraparte del modelador dentro del proceso. Esto se debe a que muchas mtricas no guardan relacin con los intereses de las partes, y el indicador de la calidad de un esquema se construye generalmente con todas ellas.
Caractersticas de las mtricas
Localizacin: La localizacin es una caracterstica del software que indica la forma que se concentra la informacin dentro de un programa.
139
Departamento:
Materia:
Encapsulamiento: define el encapsulamiento como el empaquetamiento (o enlazado) de una coleccin de elementos. Entre los ejemplos de encapsulamiento de bajo nivel (software convencional) se cuentan los registros y matrices, y los subprogramas (por ejemplo, procedimientos, funciones, subrutinas y prrafos) son mecanismos de nivel medio para el encapsulamiento. El encapsulamiento influye en las mtricas cambiando el objetivo de la medida, que pasa de ser un nico mdulo a ser un paquete de datos (atributos) y de mdulos de procesamiento (operaciones). Adems, el encapsulamiento impulsa a la medida hasta un nivel de abstraccin ms elevado.
Ocultamiento de informacin: El ocultamiento de informacin suprime los detalles operativos de un componente de un programa. Tan slo se proporciona la informacin necesaria para acceder a ese componente o a aquellos otros componentes que deseen acceder a l.
Herencia: La herencia es un mecanismo que hace posible que los compromisos de un objeto se difundan a otros objetos. La herencia se produce a lo largo de todos los niveles de la jerarqua de clases
Abstraccin: La abstraccin es un mecanismo que permite al diseador centrarse en los detalles esenciales de algn componente de un programa (tanto si es un dato como si es un proceso) sin preocuparse por los detalles de nivel inferior.
140
Departamento:
Materia:
UNIDAD III CONSTRUCCION

141
Departamento:
Materia:
3.1
SELECCIN DEL AMBIENTE OPERATIVO Y LENGUAJE DE DESARROLLO.
Una vez superada la etapa de diseo y que haya sido evaluada, procederemos a realizar la seleccin de la plataforma o lenguaje de programacin en la que va a ser desarrollada la aplicacin.
142
Departamento:
Materia:
Para seleccionar la plataforma para el desarrollo de la aplicacin debemos tomar en cuenta las funciones que se van a realizar, equipo con el que contamos, sistema operativo, conectividad con la que se cuenta, plataformas de datos con las que cuentan los sistemas actuales ( en el dado caso que la aplicacin vaya a interactuar con otros sistemas), tomar en cuenta las bondades que ofrece el lenguaje de programacin, en cuanto a manejo de datos, capacidad de ejecucin de los programas, recordemos que estos lenguajes con ejecuciones de lado del servidor por lo que debemos tomar en cuenta el tiempo de respuesta para los usuarios, recordemos que en estos programas importa mucho la rapidez con la que realicemos un procesos, pues como bien se ha comentado atrs son aplicaciones diseadas para tener mejores condiciones de mercadotecnia; aplicaciones para diseo de pginas web; en la actualidad hay muchas herramientas visuales que nos ayudan a la tarea de disear las pginas sin necesidad de escribir el cdigo HTML, XML, SHTML.
En cuanto a lenguajes de programacin para aplicaciones web hay tambin varios lenguajes, algunos muy conocidos como PERL, PHP, VBScript, C#, Java, que nos ayudan a estas tareas, son flexibles e interactan con lenguajes como HTML para generar salida de datos y darle el formato deseado y pueda ser visible al usuario, tienen la gran ventaja que son lenguajes muy ligeros al ejecutarse procesar informacin por lo que nos brindan grandes ventajas para este tipo de aplicaciones, as como el software para el servicio web, los hay nativos como es el IIS (Internet Information Service de Microsoft), Apache Web Server que puede obtenerse de la pgina web de la empresa del mismo nombre o bien hay sistemas operativos que ya lo incluyen dentro de sus funciones.
143
Departamento:
Materia:
Despus de configurar y tener todo listo, procedemos al desarrollo de la aplicacin, la cual se realizar de acuerdo a los procedimientos y condiciones establecidas en la etapa de diseo, cada programa debemos poner, autor, nombre del programa, fecha en la que se realiz y la funcin del programa.
Recordemos que es bueno no abusar de imgenes y animaciones, esto puede hacer pesada nuestra aplicacin y adems si queremos llegar a personas con capacidades diferentes como los dbiles visuales el no abusar de ello ayuda a sus software de voz para manejar el equipo de cmputo.
Debemos tener en cuenta que dentro del servidor web debemos tener bien organizada la carpeta contenedora ya que es una sola carpeta contenedora para el servicio web dentro de esta tendremos muchas cosas que servir a los usuarios, por lo que debemos destinar una carpeta para nuestra aplicacin.
Al realizar esta fase tambin debemos someter a una evaluacin el desarrollo para ver si requieren ajustes o bien van quedando correctos los programas.
Claro que hay que tener en cuenta que debemos tener personal capacitado con el lenguaje o bien capacitar al personal encargado del desarrollo de la aplicacin
144
Departamento:
Materia:
en el lenguaje de programacin seleccionado, esto con el fin de garantizar el desarrollo de las aplicaciones web de una manera profesional.
3.2 ELABORACION DE PROGRAMAS
Partiendo del concepto que se tiene sobre planeacin y programacin que para algunas personas son equivalentes, algunos estudios de estos asuntos define al primer trmino como el aspecto global de un proceso de desarrollo y al segundo con un grado de mayor concrecin, indicando las partes y condiciones de un periodo de tiempo dado. En este modesto trabajo se trata de orientar a nuestros compaeros Trabajadores Sociales de campo sobre la manera de elaborar un programa de accin, pensando en la importancia que tiene la programacin para garantizar el xito en el desarrollo de una serie de actividades que sin un previo y adecuado estudio conducirn fcilmente al fracaso. No se pretende de ninguna manera que los Trabajadores Sociales de campo sigan la presente gua en la realizacin de sus
145
Departamento:
Materia:
tareas en forma ordenada, pudiendo hacer la modificaciones que juzguen pertinentes de acuerdo con las caractersticas especiales de cada programa de trabajo, ya que el trmino Programa lo consideramos como la sistematizacin fundamentada de una serie de actividades cuya realizacin tiene por objetivo alcanzar un fin predeterminado.
Desarrollo de los aspectos de un programa
Justificacin: Se refiere a la exposicin de los motivos que fundamentan la aplicacin del programa. En este captulo se deber mostrar que el problema o problemas que pretenden solucionarse son importantes por su calidad magnitud, y adems que son susceptibles de resolverse. Esto implica un estudio y anlisis de los problemas y de los recursos y as mismo la seleccin de las prioridades de acuerdo con las necesidades.
Objetivos: Son las metas o fines que se desean alcanzar con la realizacin del programa, los objetivos que se establezcan deben ser determinados como resultado de la adecuada estimacin de problemas y recursos, y deben ser precisos,
146
Departamento:
Materia:
cuantificables y alcanzables. Los objetivos se dividen en medios e mediatos segn la posibilidad de alcanzarse a largo o corto plazo. Unos y otros deben estar ligados entre s y para el logro de los mediatos es menester haber logrado los inmediatos.
Limitacin del programa
Espacio: Es el rea donde se desarrollara la accin.
Determinacin y precisin de actividades: Comprende la especificacin de las actividades que necesitan efectuarse para alcanzar los objetivos.
Tambin debe considerarse lo necesario para cada una de las actividades.
Tiempo y calendario de actividades: Se refiere a los das meses o aos durante los cuales se llevar a cabo el programa.
147
Departamento:
Materia:
Universo de Trabajo: Es la determinacin del nmero y tipo de personas que se beneficiaran al ejercer la accin del programa.
Dentro de Organizacin:
Procedimientos
Mtodos de las actividades: Se refiere a la manera de cmo se har cada una de las actividades que se hayan considerado.
Organismos que colaboran en el programa: Aqu se mencionar los organismos o dependencias con los que se establecer coordinacin y la forma como colaborar cada uno en el programa.
Material y equipo: Se refiere al equipo que se necesitar para la realizacin del programa.
148
Departamento:
Materia:
Locales: Se refiere a los lugares cerrados o abiertos donde se ejecutara el programa.
Instructivos y reglamentos: Las instrucciones de las tcnicas que se vayan ha emplear. Los reglamentos son las normas que actividades o de las labores. regirn el desarrollo de las
Personal: Se refiere a las personas que participarn en la aplicacin del programa.
Tipo y nmero: Como su nombre lo indica es el nmero de personas que intervendrn en la ejecucin del programa.
Determinacin de funciones: Estas pueden ser la lnea desde el punto de vista jerrquico, de actividades segn los integrantes del personal y supervisin que determinan por quienes y como desarrollar esta labor.
149
Departamento:
Materia:
Reclutamiento: Se refiere a la descripcin de cmo y dnde se seleccionar el personal necesario.
Adiestramiento: Se relaciona con la preparacin especial que se impartir al personal seleccionado.
Financiamiento
Elaboracin del presupuesto: Se trata de especificar el presupuesto que se requerir para la ejecucin del programa y se deben desglosar las diversas partidas que lo integran.
Plan de obtencin de fondos: Se refiere a la manera como se piensa obtener los fondos que se necesitan para cubrir el presupuesto.
Evaluacin: Es la estimacin de las realizaciones del programa con relacin a los objetivos y procedimientos sealados. La evaluacin requiere un adecuado sistema de registro de las actividades que se vayan a llevar a cabo.Aqu se indicar cmo se har la valorizacin del programa, con que periodicidad, quienes la realizarn y que ndices se tomarn en cuenta para ello.
150
Departamento:
Materia:
La evaluacin puede ser:
Simultnea y al final del programa. Cuantitativa y Cualitativa. Interna y externa. Se denomina simultnea, cuando se efecta durante el desarrollo del programa y al final si se realiza al trmino de l.
3.2.1 IMPLEMENTACION
Introduccin:
Cada organizacin es nica, tiene su propia combinacin exclusiva de hombres, recursos econmicos, mquinas, materiales y mtodos. No solamente son diferentes los componentes individuales de la organizacin, sino tambin el grado de evolucin de su sistema de informacin para la administracin. Esta singularidad hace necesario que cada organizacin desarrolle sus propias especificaciones de su sistema de informacin para la administracin, mediante una evaluacin sistemtica de su propio ambiente externo e interno y de su punto de vista, de acuerdo con sus propias necesidades nicas.
151
Departamento:
Materia:
Fases de implementacin
1ra. Fase: seleccionar el sector productivo o empresa, en el cual se desarrollara el trabajo.
Se toma en cuenta las polticas de Formacin Profesional y las necesidades del mercado de trabajo.
2da Fase: identificar las areas funcionales por sector productivo o por empresa, Su objetivo es determinar los productos o servicios que en cada una de ellas se genera.
3ra Fase: sensibilizacin del sector productivo, campaa de informacin y divulgacin para involucrar a los diferentes actores sociales (empleadores, trabajadores, gobierno, etc.).
4ta Fase: Constitucin de las comisiones tcnicas, el comit estar integrado por representantes del sector productivo y del sistema de formacin profesional, contemplndose la participacin de otros profesionales independientes del sector. Su funcin es disear, elaborar, validar, aprobar, divulgar y mantener actualizadas las normas.
152
Departamento:
Materia:
5ta Fase: Capacitacin del comit de normalizacin, la capacitacin se basa en talleres y jornadas de trabajo sobre competencia laboral y explicacin de la metodologa para elaborar las NCL.
6ta Fase: Determinacin de las competencias laborales, Se determinan aplicando el Anlisis Funcional, lo que producir una serie de competencias laborales, las cuales conformarn un Mapa Funcional (ver anexo #1). La construccin del Mapa Funcional supone la definicin de cuatro pasos niveles que van de lo ms general a lo ms particular o especfico, describindose de esta manera un rea Funcional desde sus Propsitos Generales hasta los elementos individuales que posibilitan alcanzar dicho propsito.
Propsito principal del sector productivo o empresa
Consiste en la identificacin de los principales objetivos del sector o empresa, de modo que refleje la estrategia y condiciones de competitividad que le permite destacarse en el mercado.
153
Departamento:
Materia:
FIGURA 3.1 EJEMPLO DE UN HOTEL SOBRE LA ELABORACION DE PROGRAMAS
3.3 METRICAS PARA EVALUAR EL SOFTWARE
Mtricas para la evaluacin de software
154
Departamento:
Materia:
La garanta de calidad del software, aplicada a lo largo de todo el proceso de ingeniera del software, engloba a los mtodos y herramientas de anlisis, diseo, codificacin y prueba, al control de la documentacin y de los cambios, a los procedimientos para asegurar el ajuste a los estndares, y a los mecanismos de medida (mtricas) e informes. Para aplicar el sistema de calidad al ciclo de vida es necesario la utilizacin de mtricas adecuadas que permitan medir la calidad del proyecto (en realidad, comparamos los parmetros de calidad de ste con estimaciones realizadas mediante el uso de estndares o datos que aporta la experiencia en otros proyectos). En el contexto en que no encontramos, atenderemos principalmente a las mtricas de productividad y de calidad.
Las mtricas se utilizan para evaluar y controlar el proceso de desarrollo del software, de forma que permitan:
Indicar la calidad del producto. Evaluar la productividad de los desarrolladores. Evaluar los beneficios (en cuanto a calidad y productividad). derivados del uso de nuevos mtodos y herramientas de ingeniera del software. Establecer una lnea base para la estimacin.
155
Departamento:
Materia:
Justificar el uso de nuevas herramientas o de formacin adicional.
Pero es necesario utilizar las mtricas ms adecuadas para conseguir el control, seguimiento y mejora de la calidad, y para ello es necesario determinar los factores de calidad ms importantes dentro del proyecto.
Conceptos:
Empezar y mantener un esfuerzo de mejora del proceso software con xito requiere un compromiso a todos los niveles de la empresa, siendo la mayor dificultad para las empresas que comienzan: la definicin de medidas (mtricas) y la creacin de procedimientos para recoger y analizar estos datos.
Qu deseo saber?
Los objetivos de las mtricas vienen de los objetivos del negocio La ignorancia es una desgracia voluntaria Porqu medir? Para caracterizar, evaluar, predecir y mejorar
156
Departamento:
Materia:
Porqu medir?
Predecir
Comprender la relacin entre procesos y Productos Establecer objetivos alcanzables de calidad, coste y planificacin. Mejorar Identificar causas raz y oportunidades para mejorar. Seguir los cambios en las realizaciones y comparar con la lnea base. Comunicar razones para mejora.
Necesidades de medida
Las necesidades de medida pueden ser diversas, desde medir el rendimiento de los proyectos de una empresa, evaluar las inspecciones de cdigo hasta evaluar las actividades de mejora del proceso software.
157
Departamento:
Materia:
La medida es una parte esencial para comprender que afecta a la calidad, Oportunidad, utilidad y funcionalidad y en la mejora de los procesos y productos software. Para comprender como aplicar las mtricas del software , debemos comprender primero qu significan las medidas y porqu las
Tipos de Mtrica.
Mtricas objetivas (Cuantificado y medido) Mtricas subjetivas (Clases de respuestas)
Mtricas Bsicas Mtricas calculadas
Mtodos adicionales
FIGURA 3.2 TIPOS DE METRICA
158
Departamento:
Materia:
Mtricas globales/fases
Mtricas globales
Requisitos
Validacin
Diseo Codificacin Mtricas de fase
Integracin
FIGURA 3.2 METRICAS GLOBALES
Cules son los costes de no medir Incapacidad para:

Estimar/planificar de forma realista determinar el progreso Evaluar la calidad reconocer las oportunidades de mejora Reconocer mejoras.
159
Departamento:
Materia:
Precauciones y limitaciones.
Las
medidas
no
son
absolutas,
simplemente
proporcionan
comprensin
(conocimiento profundo) del proceso software. Medicin no puede identificar, explicar, o predecir todo. La mayora de los resultados requieren ms de una medida para caracterizar y comprender. La medicin no tiene valor a menos que se comprenda con la globalidad del proceso software. Medicin implica varios usuarios en diversos niveles por toda la organizacin. Medicin no deber ser utilizada para evaluar prestaciones individuales; ms bien deber servir como base para resolucin interactiva de aspectos del proceso. Evaluaciones basadas en medicin son solo tan buenas como la oportunidad, consistencia y precisin de los datos de entrada.
160
Departamento:
Materia:
3.4 PRUEBA DEL PROGRAMA Y DEL SISTEMA
Qu es probar?
Como parte que es de un proceso industrial, la fase de pruebas aade valor al producto que se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el valor que aade. El objetivo especfico de la fase de pruebas es encontrar cuantos ms errores, mejor.
Es frecuente encontrarse con el error de afirmar que el objetivo de esta fase es convencerse de que el programa funciona bien.
En realidad ese es el objetivo propio de las fases anteriores (quin va a pasar a la seccin de pruebas un producto que sospecha que est mal?). Cumplido ese objetivo, lo mejor posible, se pasa a pruebas. Esto no obsta para reconocer que el objetivo ltimo de todo el proceso de fabricacin de programas sea hacer programas que funcionen bien; pero cada fase tiene su objetivo especfico, y el de las pruebas es destapar errores.
161
Departamento:
Materia:
Por poner un ejemplo duro, probar un programa es equivalente a la actividad de ciertos profesores para los que examinar a un alumno consiste en poner en evidencia todo lo que no sabe. Esto es penoso cuando se aplica a personas; pero es exactamente lo que hay que hacerle a los programas.
La prueba ideal de un sistema sera exponerlo en todas las situaciones posibles, as encontraramos hasta el ltimo fallo. Indirectamente, garantizamos su respuesta ante cualquier caso que se le presente en la ejecucin real. Esto es imposible desde todos los puntos de vista: humano, econmico e incluso matemtico.
Dado que todo es finito en programacin (el nmero de lneas de cdigo, el nmero de variables, el nmero de valores en un tipo, etc etc) cabe pensar que el nmero de pruebas posibles es finito. Esto deja de ser cierto en cuanto entran en juego bucles, en los que es fcil introducir condiciones para un funcionamiento sin fin. An en el irrealista caso de que el nmero de posibilidades fuera finito, el nmero de combinaciones posibles es tan enorme que se hace imposible su identificacin y ejecucin a todos los efectos prcticos.
Probar un programa es someterle a todas las posible variaciones de los datos de entrada, tanto si son vlidos como si no lo son. Imagnese hacer esto con un compilador de cualquier lenguaje: habra que escribir, compilar y ejecutar todos y cada uno de los programas que se pudieran escribir con dicho lenguaje. Sobre esta
162
Departamento:
Materia:
premisa de imposibilidad de alcanzar la perfeccin, hay que buscar formas humanamente abordables y econmicamente aceptables de encontrar errores. Ntese que todo es muy relativo y resbaladizo en esta rea.
La verificacin, prueba y mantenimiento de los programas es esencial para minimizar los riesgos por el uso de tecnologa. Es conveniente realizar la verificacin y prueba antes de utilizar el sistema; Despus de una prueba exitosa, se requiere darle a los programas el debido mantenimiento para garantizar su buen funcionamiento cuando se les requiera.
El nivel de importancia de la tecnologa impactar el grado de rigor aplicado a los programas de verificacin, prueba y mantenimiento de los programas.
Verificacin de programas
163
Departamento:
Materia:
Para un sistema de gran importancia, como uno de votacin electrnica, es conveniente que una autoridad independiente lleve a cabo las pruebas de verificacin. Para sistemas de menor importancia, la verificacin puede realizarse internamente.
Las pruebas de verificacin de los programas (tambin conocidas como pruebas de calidad) pueden comprender lo siguiente : Probar los programas para asegurar que renen los estndares exigidos y ejecutan las tareas esperadas, incluyendo auditoras de cdigo. Asegurar que la documentacin del sistema es la adecuada y est completa. Verificar que el sistema es capaz de funcionar bajo las condiciones normales esperadas y potenciales condiciones adversas. Garantizar que se cuenta con medidas de seguridad y que estas se ajustan a los estndares establecidos. Asegurar que se cuenta con las debidas medidas de control de calidad. Puede ser necesario realizar auditoras a los cdigos de los programas, particularmente cuando estos se utilicen para sistemas cruciales. Generalmente estas auditoras son ms Efectivas cuando las llevan a cabo expertos independientes de los autores del cdigo. Una auditora de programas puede incluir medidas como las siguientes:
164
Departamento:
Materia:
Verificar que el cdigo es lgicamente correcto. Asegurar que el cdigo tiene un diseo modular (es decir, est conformado por mdulos que pueden ser probados y evaluados por separado). Revisar que no existan cdigos ocultos que puedan ejecutar funciones no autorizadas. Verificar que todos los cdigos sean directos y relativamente fciles de entender. Asegurar que el cdigo est diseado para ser probado fcilmente -es decir, que permite probar los flujos de informacin dentro y entre los mdulos. Verificar que el cdigo incluya mecanismos correctores de errores que permitan su deteccin inmediata y prevenir prdidas de informacin. Asegurar que el cdigo cuenta con mecanismos de seguridad para impedir accesos no autorizados. Constatar que el sistema es utilizable sin necesidad de procedimientos complejos u obscuros. Asegurar que los programas pueden ser instalados fcilmente.
Verificar que se les puede dar fcil mantenimiento a los programas y que, una vez instalados, pueden identificarse y corregirse errores o defectos con facilidad. Revisar si los programas pueden ser modificados fcilmente para agregarles nuevas caractersticas.
165
Departamento:
Materia:
Prueba de los programas
Una vez que los programas han sido verificados, requieren ser rigurosamente probados para asegurar que cada componente opere como es debido y que el sistema funcione exactamente de acuerdo con los requerimientos locales especficos.
Entre las medidas de prueba se pueden considerar las siguientes:
Desarrollar un conjunto de criterios para la prueba. Aplicar pruebas funcionales para determinar si se han satisfecho los criterios de prueba. Aplicar evaluaciones de calidad para determinar si se han satisfecho los criterios de prueba.
Conducir pruebas en condiciones de laboratorio y en una variedad de condiciones reales. Conducir pruebas durante un periodo prolongado, para cerciorarse que los sistemas pueden funcionar de manera consistente.
166
Departamento:
Materia:
Conducir pruebas de carga, simulando tanto como sea posible una variedad de condiciones reales utilizando o excediendo los volmenes de informacin que se pueden esperar en una situacin concreta. Verificar que lo que entra es lo que sale, introduciendo informacin conocida y verificando que el resultado sea consecuente con ella.
Mantenimiento de los programas
Despus de que los programas han sido verificados, probados e implantados, se les debe seguir dando mantenimiento. Las rutinas de mantenimiento variarn de acuerdo con el tipo y complejidad de la tecnologa.
Los fabricantes o proveedores suelen indicar en muchos productos el programa o calendario de mantenimiento requerido. El mantenimiento tambin puede ser realizado por el fabricante o el proveedor como parte del acuerdo de compra. A los sistemas se les debe dar mantenimiento para asegurar que continen operando en el nivel mostrado durante la etapa de prueba.
Si los sistemas se deterioran, existe el riesgo de que no se desempeen conforme a los estndares requeridos.
167
Departamento:
Materia:
Puede ser necesario instalar sistemas de monitoreo o prueba para asegurar que las necesidades de mantenimiento sean identificadas y satisfechas cuando resulte necesario.
Cuando los sistemas son de uso prolongado, se puede establecer un mecanismo para recibir retroalimentacin de los usuarios como otra forma de determinar las necesidades de mantenimiento y modificacin.
Cuando se realicen modificaciones a los programas como resultado de ejercicios de mantenimiento o actualizacin, puede ser necesario promover rondas adicionales de verificacin y prueba del sistema para asegurarse que siguen cumpliendo las normas exigidas.
La fase de pruebas absorbe una buena porcin de los costes de desarrollo de software. Adems, se muestra renuente a un tratamiento matemtico o, simplemente, automatizado. Su ejecucin se basa en metodologa (reglas que se les dan a los encargados de probar) que se va desarrollando con la experiencia. Es tediosa, es un arte, es un trabajo que requiere una buena dosis de mala intencin, y provoca difciles reacciones humanas.
168
Departamento:
Materia:
Aunque se han desarrollado miles de herramientas de soporte de esta fase, todas han limitado su xito a entornos muy concretos, frecuentemente slo sirviendo para el producto para el que se desarrollaron. Slo herramientas muy generales como analizadores de complejidad, sistemas de ejecucin simblica y medidores de cobertura han mostrado su utilidad en un marco ms amplio. Pero al final sigue siendo imprescindible un artista humano que sepa manejarlas.
3.5 IMPLEMENTACION
169
Departamento:
Materia:
Es la ltima fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo, como resultado de un anlisis y diseo previo como resultado de la sustitucin o mejoramiento de la forma de llevar a cavo un proceso automatizado.
Al Implantar un Sistema de Informacin lo primero que debemos hacer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del anlisis y permitir que los usuarios puedan operarlo.
Existen varios enfoques de implementacin:
Uso de diferentes estrategias para el entrenamiento de los usuarios. El Analista de Sistemas necesita ponderar la situacin y proponer un plan de conversin que sea adecuado para la organizacin. El Analista necesita formular medidas de desempeo con las cuales evaluar a los Usuarios. Debe Convertir fsicamente el sistema de informacin antiguo, al nuevo modificado. En la preparacin de la Implantacin, aunque el Sistema este bien diseado y desarrollado correctamente su xito depender de su implantacin y ejecucin por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento. Es darle responsabilidad a los grupos Uso de diferentes estrategias para el enfrentamiento de usuarios.
170
Departamento:
Materia:
El analista necesita formular medidas de desempeo con los cuales evala a los usuarios.
3.6 DOCUMENTACION
171
Departamento:
Materia:
La documentacin consiste en material que explica las caractersticas tcnicas y la operacin de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para ensear a los usuarios como interactuar con el sistema y a los operandos como hacerlo funcionar.
Existen varios tipos de documentacin. La de programas, que explica la lgica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la de usuarios en forma general la naturaleza y capacidades del sistema y cmo usarlo.
Documentacin:
Bajo este trmino genrico se agrupan todos los manuales, guas de referencia, libros de ayuda, etc., que suelen entregarse con cada programa, de manera que el usuario pueda aprender su manejo y consultar cualquier duda ante un problema desconocido.
Importancia de la Documentacin de Sistemas
172
Departamento:
Materia:
La importancia de la documentacin bien podra ser comparada con la importancia de la existencia de una Pliza de Seguro; mientras todo va bien no existe la precaucin de confirmar si nuestra Pliza de Seguros est o no vigente.
La documentacin adecuada y completa, de una aplicacin que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Informacin, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atencin.
Siempre se debe documentar un sistema como si estuviera a punto de irse a Siberia el siguiente mes, para nunca volver. Si la documentacin del sistema es incompleta el diseador continuamente estar involucrado y no podr moverse a otra asignacin.
Es el conjunto de informacin que nos dice qu hacen los sistemas, cmo lo hacen y para quin lo hacen.
La documentacin consiste en material que explica las caractersticas tcnicas y la operacin de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para ensear a los usuarios como interactuar con el sistema y a los operandos como hacerlo funcionar.
173
Departamento:
Materia:
Existen varios tipos de documentacin.
La de programas: que explica la lgica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la del usuario en forma general la naturaleza y capacidades del sistema y cmo usarlo.
Muchas organizaciones tienen lo que se conoce como un "programa de documentacin", el cual consiste en una poltica formal cuya documentacin se muestra como algo que debe prepararse en forma rutinaria para cada programa de cmputo, archivo y nuevos sistemas.
Otra definicin sera la de registro fsico, generalmente por escrito que contiene los siguientes elementos:
Polticas y normas referentes al desarrollo del sistema, su implantacin, operacin y mantenimiento.
3.6.1. ELABORACION DEL MANUAL DE USUARIO
174
Departamento:
Materia:
Manual de Usuario: Esta parte se divide en dos manuales distintos, uno por cada aplicacin cliente. Se explicar todas las posibles opciones que puede realizar el usuario con estas aplicaciones de manera detallada, y mediante el uso de capturas de pantalla. Pasos del manual del usuario: 1. Portada: De que se trata el documento y quien lo elaboro? 2. Introduccin: Describe el uso del documento (para que sirve?) y de que habla? 3. Anlisis y requerimientos del sistema (que se ocupa para poder instalarlo y usarlo?) 4. Explicacin del funcionamiento: Debes de poner paso a paso y con pantallas bien explicadas cmo funciona el programa 5. Glosario: Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la menor dificultad posible. Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar el programa. Especificar los alcances y las limitaciones que tiene el programa. Un buen punto de partida para un manual de usuario, es hacer de cuenta que las personas que lo van a leer no tienen el mas mnimo conocimiento sobre computadores.
175
Departamento:
Materia:
Expone los procesos que el usuario puede realizar con el sistema implantado. Para lograr esto, es necesario que se detallen todas y cada una de las caractersticas que tienen los programas y la forma de acceder e introducir informacin. Permite a los usuarios conocer el detalle de qu actividades ellos debern desarrollar para la consecucin de los objetivos del sistema. Rene la informacin, normas y documentacin necesaria para que el usuario conozca y utilice adecuadamente la aplicacin desarrollada.
Objetivos
Que el usuario conozca cmo preparar los datos de entrada.
Que el usuario aprenda a obtener los resultados y los datos de salida. Servir como manual de aprendizaje. Servir como manual de referencia. Definir las funciones que debe realizar el usuario. Informar al usuario de la respuesta a cada mensaje de error.
Pasos a seguir para definir como desarrollar el manual de usuario.
176
Departamento:
Materia:
Identificar los usuarios del sistema: personal que se relacionar con el sistema. Definir los diferentes tipos de usuarios: se presentan los diferentes tipos de usuarios que usaran el sistema. Ejemplo: usuarios directos, indirectos. Definir los mdulos en que cada usuario participar: Se describen los mdulos o procesos que se ejecutarn por cada usuario en forma narrativa breve y clara.
Importancia del manual de usuario
El manual de usuario facilita el conocimiento de:
Los documentos a los que se puede dar entrada por computadora. Los formatos de los documentos. Las operaciones que utiliza de entrada y salida de los datos. El orden del tratamiento de la computadora con los datos introducidos. El momento en que se debe solicitar una operacin deseada. Los resultados de las operaciones realizadas a partir de los datos introducidos.
Al elaborar el Manual de Usuario, hay que tener en cuenta a quin va dirigido es decir, el manual puede ser manejado desde el director de la empresa hasta el
177
Departamento:
Materia:
introductor de datos. Por consiguiente, debe redactarse de forma clara y sencilla para que lo entienda cualquier tipo de usuario.
Contenido
Diagrama general del sistema
Muestra en forma condensada el flujo general de la informacin y de las actividades que se realizan en el sistema. Proporciona una visin general del sistema. Representar los diagramas utilizando para ello diagramas de bloques.
Diagrama particular detallado.
Presentar grficamente todos los pasos que se efecten dentro del departamento usuario a quien est dirigido este manual. Deben especificarse los archivos de entrada, salida, los resultados, revisiones y procesos manuales.
Explicacin genrica de las fases del sistema.
178
Departamento:
Materia:
En este punto se explica en forma especfica y detallada todas las operaciones que aparecen representadas en forma grfica en el diagrama particular. Se analizan cada una de las fases sealando:
El proceso principal que se desarrolla. La entrada de la informacin. La obtencin de un resultado parcial. El envo de informacin a otra dependencia.
Instalacin del sistema
La instalacin del sistema proporciona detalles completos sobre la forma de instalar el sistema en un ambiente particular.
Iniciacin al uso del sistema
179
Departamento:
Materia:
En este punto se explica cmo iniciarse en el sistema y cmo se pueden utilizar sus cualidades comunes. Esta documentacin debe decir al usuario cmo salir de un problema cuando las cosas funcionan mal.
Manual de referencia
Es el documento definitivo de cara al usuario y debe ser completo. Describe con detalle las cualidades del sistema y su uso, los informes de error generados y las situaciones en que surgen esos errores.
Dependiendo del sistema, los documentos al usuario se pueden proporcionar por separado o reunidos en varios volmenes. Los sistemas de ayuda en lnea evitan que el usuario pierda tiempo en consultas manuales.
Caducidad de documento fuente y destino final
Como el usuario trabajar con documentos fuentes, stos podrn tener un perodo de retencin y un destino especificado.
3.6.2 ELABORACION DEL MANUAL DE ADMINISTRACION
180
Departamento:
Materia:
Recabados los elementos preliminares para llevar a cabo el manual, se debe preparar el documento de partida para concretarlo, el cual debe quedar integrado por:
Propuesta tcnica, (que debe de incluir): Antecedentes: recuento de todos los manuales o esfuerzos anlogos preparados con anterioridad. Naturaleza: tipo de manual que se pretende realizar. Justificacin: demostracin de la necesidad de efectuarlo en funcin de las ventajas que ello reportar a la organizacin. Objetivos: logros que se pretenden alcanzar. Acciones: iniciativas o actividades necesarias para su consecucin. Resultados: beneficios que se esperan obtener en cuanto a mejorar el funcionamiento de la organizacin, sus productos y/ o servicios, clima organizacional y relaciones con el entorno. Alcance: rea de aplicacin que cubre el estudio en trminos de ubicacin en la estructura orgnica y/ o territorial. Recursos: requerimientos humanos, materiales y tecnolgicos necesarios para desarrollarlo.
181
Departamento:
Materia:
Costo: estimacin global y especfica de recursos financieros que demanda su ejecucin. Estrategia: ruta fundamental necesaria para orientar los recursos de accin y asignacin de recursos. Informacin complementaria: material e investigaciones que pueden servir como elementos de apoyo.
Programa de trabajo
Identificacin: nombre del manual. Responsable(s): unidad o grupo que tendr a su cargo la implantacin del manual. rea(s): universo bajo estudio. Clave: nmero progresivo de las actividades estimadas. Actividades: pasos especficos que tienen que darse para captar la informacin. Fases: definicin del orden secuencial para realizar las actividades. Calendario: fechas asignadas para el inicio y terminacin de cada fase. Representacin grfica: descripcin del programa en cuadros e imgenes.
182
Departamento:
Materia:
Formato: presentacin y resguardo del programa de trabajo. Reportes de avance: seguimiento de las acciones. Periodicidad: espacio de tiempo dispuesto para informar avances.
Presentacin del proyecto a las autoridades competentes
Participantes
Para depurar el contenido del proyecto, afinar sus parmetros y determinar su viabilidad operativa, es recomendable presentarlo a:
rea (s) que intervendr directamente en su aplicacin, por lo cual tienen la obligacin de conocer el proyecto en forma detallada. reas afectadas por la implantacin del proyecto, ya que tendrn que cambiar o adecuarse.
183
Departamento:
Materia:
rea responsable del manejo de los recursos econmicos, para cuantificar el costo del proyecto en forma ms especfica.
Responsable de su autorizacin Asimismo, el proyecto debe presentarse al titular de la organizacin o de la unidad administrativa responsable de su ejecucin, para su aprobacin. Una vez autorizado, el responsable debe hacer del conocimiento de todos los niveles jerrquicos la intencin que tiene la organizacin de elaborar el manual, resaltando los beneficios que de este esfuerzo se obtendrn, a fin de que todos brinden su apoyo durante el desarrollo del trabajo. Sin este requisito, la labor de integracin del manual se vera seriamente dificultada.
Captacin de la informacin
Como primer paso de esta etapa se debe obtener una lista del personal que va a participar en el levantamiento de la misma, considerando la magnitud y especificaciones del trabajo. Capacitacin del personal Una vez integrado el grupo de trabajo, se debe capacitarlo, no slo en lo que respecta al manejo de medios de investigacin que se utilizarn para el levantamiento de la informacin, sino tambin en todo el proceso que se seguir para preparar el manual.
184
Departamento:
Materia:
Por ello, se debe dar a conocer a los participantes el objetivo que se persigue, as como los mtodos de trabajo adoptados, calendarizacin de actividades, documentos que se emplearn.(cuestionarios, formatos, etctera), responsables del proyecto, unidades administrativas involucradas, inventario de informacin a captar y distribucin del trabajo a cada persona. Cuando el grupo de trabajo sea numeroso, puede resultar conveniente formar subgrupos, coordinados cada uno por un responsable, quien debe encargarse de revisar y homogeneizar la informacin. Es recomendable efectuar un estudio en un rea piloto, para luego comparar y evaluar los resultados obtenidos.
Levantamiento de la informacin
Los esfuerzos de recopilacin deben enfocarse en el registr de hechos que permitan conocer y analizar informacin especfica y verdaderamente til para el manual, pues de lo contrario se puede incurrir en interpretaciones errneas, lo cual genera retraso y desperdicio de recursos. Asimismo, debe aplicarse un criterio de discriminacin, basado en el objetivo del estudio, y proceder continuamente a su revisin y evaluacin para mantener una lnea de accin uniforme. Esta actividad exige mantener una relacin constante con las fuentes internas emisoras de la informacin, as como con las reas u organizaciones con otra ubicacin fsica.
185
Departamento:
Materia:
Para recabar la informacin en forma gil y ordenada se puede utilizar alguna o una combinacin de las siguientes tcnicas de recopilacin:
Investigacin documental
Esta tcnica permite la seleccin y anlisis de aquellos escritos que contienen datos de inters relacionados con el manual. Para ello se estudian documentos tales como bases jurdico-administrativas, diarios oficiales, actas de reuniones, circulares, oficios y todos aquellos que contengan informacin relevante para el estudio.
Consulta a sistemas de informacin
Acceso a sistemas computacionales que contienen informacin y recursos de apoyo para estructurar el manual. Este mecanismo permite recabar informacin interna y/o de sistemas externos a la organizacin enlazados a travs de redes.
Encuesta
186
Departamento:
Materia:
Este mtodo implica la realizacin de entrevistas personales con base en una gua de preguntas elaborada con anticipacin. Tambin se puede utilizar un cuestionario, a fin de que las entrevistas tengan un contenido homogneo.
Esta tcnica se considera de gran utilidad para reunir informacin preliminar al anlisis o para efecto de plantear cambios o modificaciones a la estructura actual de la informacin. La encuesta puede realizarse en forma individual o reuniendo a directivos y empleados de una misma rea o que intervienen en la misma clase de tareas. Tambin se puede recabar informacin de clientes y/o usuarios, prestadores de servicios y proveedores que interactan con la organizacin. Los cuestionarios que se utilizan en la encuesta, y que sirven para obtener la informacin deseada, estn constituidos por series de preguntas escritas, predefinidas, secuenciadas y separadas por captulos o temtica especficos.
Observacin directa
Este recurso puede ser empleado por los tcnicos o analistas en el rea fsica donde se desarrolla el trabajo de la organizacin. A partir del anlisis de la informacin recabada se deben sostener plticas con algunas de las personas que prestan sus servicios en estas reas para complementarla o afinarla.
187
Departamento:
Materia:
Otra forma consiste en que el jefe del rea de trabajo realice la observacin directa, comente y discuta algunos de los puntos con sus subordinados y presente los resultados de su anlisis al investigador. La ventaja de este procedimiento radica en que debido a la familiaridad entre jefe y subordinados, la informacin puede ser ms completa, pero habr ocasiones en que los resultados no sern los deseados, debido a inhibiciones o problemas internos, o que pueda plantearse una situacin que no corresponde a la realidad operativo.
Integracin de la informacin: Una vez que se cuenta con la informacin de las reas involucradas en el estudio, se debe ordenar y sistematizar los datos a efecto de poder preparar su anlisis. Cmo clasificar la informacin Para facilitar la tarea de integracin, es recomendable que la informacin obtenida se vaya accesando a equipos de cmputo para salvaguardara y facilitar su manejo.
Con este propsito se pueden:
Crear directorios, subdirectorios y archivos para desagregarla en funcin de la divisin del trabajo. Crear bases de datos o programas especficos. Utilizar paquetes acordes con las necesidades especficas del proyecto.
188
Departamento:
Materia:
Combinar los puntos anteriores para optimizar resultados. En forma paralela deben abrirse carpetas con apartados especficos con los documentos fuente del estudio, en las que se debe compendiar la informacin por rea, sistema, procedimiento, equipos, polticas, etctera. Es conveniente que los documentos que se recaben contengan el visto bueno de la persona que suministra la informacin. Tambin es recomendable que conforme se recaben datos sobre algn aspecto, se concentren en un documento de trabajo que pueda servir de memoria en el diseo posterior del proyecto.
reas para agrupar la informacin, antecedentes
Se debe tomar en cuenta la reglamentacin jurdico-administrativa que regula la realizacin del trabajo, como se ha atendido por parte de las unidades responsables de hacerlo y qu efecto ha tenido sobre otras unidades, organizaciones, clientes y/o usuarios. Tambin es oportuno, en su caso, considerar la evolucin o desarrollo de las estructuras organizacionales anteriores y los resultados que se obtuvieron, lo cual permite contar con un marco de referencia histrico para comprender mejor la situacin actual. Situacin actual.
Se toman en cuenta los siguientes aspectos:
Objetivos
189
Departamento:
Materia:
Estructura orgnica Normas y polticas administrativas Funciones Procedimientos Instrumentos jurdico-administrativos Equipo Condiciones de trabajo Ambiente laboral
Anlisis de la informacin: En esta etapa se debe realizar un estudio o examen crtico de cada uno de los elementos de informacin o grupos de datos que se integraron con el propsito de conocer su naturaleza, caractersticas y comportamiento, sin perder de vista su relacin, interdependencia o interaccin interna y con el ambiente, para obtener un diagnstico que refleje la realidad operativa.
Esta mecnica de estudio puede seguir la siguiente secuencia:
Conocer Describir Descomponer Examinar criticamente Ordenar cada elemento
190
Departamento:
Materia:
Definir las relaciones Identificar y explicar su comportamiento Un enfoque muy eficaz en el momento del anlisis de los datos consiste en adoptar una actitud interrogativa y formular de manera sistemtica seis cuestionarios fundamentales: Qu trabajo se hace? Para qu se hace? Quin lo hace? Cmo se hace? Con qu se hace? Cundo se hace? Despus de obtener respuestas claras y precisas para cada una de las preguntas anteriores, las mismas deben someterse, a su vez, a un nuevo interrogatorio planteando la pregunta por qu?. Las nuevas respuestas que se obtengan darn la pauta para formular el manual y las medidas de mejoramiento administrativo.
Tcnicas de apoyo para el anlisis: En esta fase comprende los recursos tcnicos que se emplean para estudiar la informacin obtenida con el fin de conocerla en forma detallada t determinar alternativas de accin especficas que permitan derivar soluciones ptimas para lograr los resultados deseados. Las tcnicas de anlisis que se pueden utilizar en esta fase estn directamente relacionadas con el origen del proyecto, as como con la informacin tcnica del lder o responsable en funcin del tipo de manual, factibilidad para su aplicacin, disponibilidad de tiempo, asignacin
191
Departamento:
Materia:
de recursos y nivel tcnico del grupo de trabajo. Este tipo de instrumentos se puede utilizar como respaldo para el proyecto o en sentido inverso, a raz de la implantacin de un proceso de cambio organizacional que debe culminar con la edicin de un manual administrativo.
Entre las tcnicas que generalmente se utilizan para auxiliar el anlisis administrativo en este campo, se encuentran las siguientes:
Organizacionales:
Administracin por objetivos Anlisis de sistemas Anlisis de costo-beneficio Anlisis de estructuras rbol de decisiones Auditora administrativa Autoevaluacin Control total de calidad Estudio de factibilidad
192
Departamento:
Materia:
Estudio de viabilidad Benchmarking Desarrollo organizacional Reingeniera organizacional Reorganizacin Cuantitivas. Anlisis de series de tiempos Correlacin Modelos de inventario Modelos integrados de produccin Muestreo Nmeros Nmeros ndices Programacin dinmica Programacin lineal Simulacin Teora de colas o de lneas de espera Teora de los grafos Teora de las decisiones
193
Departamento:
Materia:
Preparacin del proyecto del manual: Una vez que se cuenta con toda la informacin del manual se proceder a integrarlo; para tal actividad se requiere convocar a todos los participes de la presentacin del manual, para revisin del contenido y presentacin de cada apartado.
Validacin La informacin verificada de cada rea o unidad administrativa deber presentarse a la persona entrevistada para que firme de conformidad en un espacio especfico para este objetivo; debe verificar que la informacin est completa y comprensible.
Estructuracin: Una vez que se rene la informacin revisada y firmada por cada rea, los involucrados en la presentacin del manual deben reunirse para compaginar e integrar el proyecto final del manual.
Formulacin de recomendaciones: Para seleccionar las recomendaciones ms viables, se toma en cuenta su costo, recursos necesarios para aplicarlas y sus ventajas y limitaciones.
Tipos de recomendaciones De mantenimiento: preservacin general de la misma estructura orgnica, funciones, sistemas, procedimientos, personal y formas.
194
Departamento:
Materia:
De eliminacin: supresin de sistemas, reemplazo de formas, registros e informes, eliminacin total o parcial de procedimientos, bajas de personal, desaparicin de reas o unidades administrativas, etc.
De adicin: introduccin de un nuevo sistema, incremento del nmero de operaciones en determinado procedimiento, aumento de personal o programas, etc.
De combinacin: intercalar el orden de aplicacin de programas de trabajo, combinar el orden de las operaciones de un procedimiento, compaginar la utilizacin de formas de uso generalizado con nuevas formas, etc.
De fusin: agrupacin de reas, unidades administrativas o personas bajo un mismo mando, unificacin de formas, registros e informes, etc.
De modificacin: cambios en los procedimientos o las operaciones, reubicacin fsica de personal, equipo o instalaciones, redistribucin de cargas de trabajo, modificacin de formas, registros, informes y programas, etc.
De simplificacin: reduccin de pasos de un procedimiento, introduccin de mejoras en los mtodos de trabajo, simplificacin de formas, reportes, registros, programas, etc.
195
Departamento:
Materia:
De intercambio: re direccionamiento de funciones, procedimientos, recursos, personal o flujo del trabajo entre reas u organizaciones del mismo grupo o sector.
Elaboracin del informe: Para entregar los resultados del estudio es necesario redactar un informe, en el que adems de exponer las razones que llevaron a obtenerlos, incorpore la informacin estratgica del proyecto que le permita a la alta direccin la toma de decisiones oportuna y correcta.
El informe consta de los siguientes elementos, generalmente:
Introduccin: es el resumen del propsito, enfoque, limitaciones y el plan de trabajo. Parte principal o cuerpo: seccin donde se anotan los hechos, argumentos y justificaciones. Conclusiones y recomendaciones.
Apndices o anexos: inclusin de grficas, cuadros y dems instrumentos de anlisis administrativo que se consideren elementos auxiliares para apoyar la propuesta y recomendaciones.
Presentacin del manual para su aprobacin: Una vez que el manual ha quedado debidamente estructurado, el encargado del proyecto debe someterlo a las instancias
196
Departamento:
Materia:
procedentes para su aprobacin; convocar a su grupo de trabajo para la ltima revisin de la documentacin que se presentar.
A los niveles directivos Es recomendable que esta presentacin parta en un documento sntesis derivado del informe, cuya extensin no sea mayor a treinta cuartillas, para que en caso de ser analizado, requiera de un mnimo de tiempo que deje un lapso adicional para explicaciones, as como para intercambio de opiniones. Si el tiempo de que se dispone es muy breve, el documento sntesis puede ser entregado a las autoridades correspondientes y hacer la presentacin del manual exclusivamente con el apoyo de equipos de cmputo, lminas o audiovisuales, donde se destaquen los elementos ms relevantes para el proceso de toma de decisiones.
El documento sntesis puede subdividirse en el siguiente capitulado:
Introduccin: breve descripcin de las causas que generaron la necesidad de preparar el manual, los mecanismos de coordinacin y participacin de empleados para su desarrollo, as como los propsitos y explicacin general acerca de su contenido.
Anlisis de la estructura organizacional: exposicin de la gnesis y desarrollo de la organizacin, es decir los cambios, sucesos y vicisitudes de mayor relevancia que
197
Departamento:
Materia:
ha afrontado en forma total o parcial y que influyeron en la decisin de preparar el manual.
Diagnstico de la situacin actual: definicin de las causas y/o problemas que originaron el estudio y que justifican los cambios o modificaciones que se proponen en el manual.
Propuestas de mejoramiento: presentacin de alternativas de accin para la organizacin, ventajas y desventajas que pueden derivarse, implicaciones de los cambios, as como los resultados que se espera obtener con el manual.
Estrategia de implantacin: explicacin de los pasos sucesivos o etapas previstas para poner en prctica el manual y las medidas de mejoramiento administrativo derivadas de l. Asimismo, la forma en que se efectuaran los cambios previendo los factores sobresalientes de actuacin de las reas, unidades, mecanismos y funcionarios involucrados en el esfuerzo.
Seguimiento, control y evaluacin: precisin de los mecanismos de informacin, proceso de control y evaluacin, as como los criterios y medidas que podran tomarse en cada caso. Al rgano De Gobierno De acuerdo con la normatividad vigente y/o a las polticas dictadas por el titular de la organizacin, una vez que el manual propuesto ha sido revisado y analizado por los niveles superiores, debe
198
Departamento:
Materia:
presentarse ante el consejo de administracin o su equivalente para su aprobacin definitiva.
A otros niveles jerrquicos:
La exposicin a los niveles departamentales, de
oficina o de rea tambin puede basarse en el documento sntesis, pero tratando siempre de hacerlo en la forma ms accesible posible para facilitar su comprensin. Asimismo, servir para fortalecer el compromiso entre todas las partes involucradas, elemento fundamental para el posterior seguimiento y evaluacin de las actividades.
Reproduccin del manual: Una vez que el grupo responsable de la elaboracin del manual haya recabado e integrado las observaciones surgidas en los diferentes niveles de decisin, debe coordinarse con la unidad o rea que maneja los recursos econmicos para que ste sea reproducido para su distribucin e implantacin. Para este efecto, el lder del proyecto debe suministrar los parmetros tcnicos para el diseo de la impresin.
Aun cuando existen varias opciones para hacerlo, pero las unidades de medida ms aceptadas para este tipo de documento son:
Utilizar formatos intercambiables, a fin de facilitar su revisin y actualizacin. Que los formatos sean de 2821 cm (tamao carta).
199
Departamento:
Materia:
Las grficas o cuadros que por necesidad sobrepasen el tamao carta, sern dobladas hasta lograr esta dimensin. Utilizar el mtodo de reproduccin en una sola cara de las hojas. Procurar que la divisin en apartados, captulos, reas y/o secciones queden separados por divisiones, las cuales presenten impreso este nombre. Que todo el documento quede integrado por cartula, portada, ndice o contenido, introduccin y cuerpo. Cartula Es la cubierta o cara exterior del documento, que tiene como objetivo su identificacin a travs de los siguientes elementos: Nombre oficial de la organizacin. Logotipo oficial. Nombre genrico del manual en relacin con su contenido. Nombre de la unidad administrativa responsable de su elaboracin y/o aplicacin.
Implantacin del manual: La implantacin del manual representa el momento crucial para traducir en forma tangible las propuestas y recomendaciones en acciones especficas para elevar la productividad, mejorar la coordinacin, agilizar el trabajo y homogeneizar el conocimiento de la dinmica y componentes organizacionales.
200
Departamento:
Materia:
Mtodos de implantacin: La seleccin de mtodo para implantar administrativos est estrechadamente relacionada con elementos de estructura tales como:
Tipo de manual Cobertura Recursos asignados Nivel tcnico del personal Clima organizacional Entorno En funcin de estas variables, las alternativas para implantarlos son:
Mtodo instantneo. Generalmente es el mas utilizado, ya que la decisin de preparar manuales administrativos-en la mayora de los casos- proviene de los ms altos niveles de la estructura de una organizacin, lo cual les confiere una naturaleza o validez casi obligatoria. Tambin se adopta cuando la organizacin es nueva, si no se involucra a un nmero amplio de unidades administrativas, si es relativamente sencillo, si no implica un gran volumen de funciones, sistemas u operaciones, o si en la organizacin existe una slida infraestructura administrativa. Mtodo del proyecto piloto. Esta forma de implantacin implica aplicar el contenido del manual en slo una parte de la organizacin, con la finalidad de medir los resultados que ello genera. El beneficio que pueda aportar radica en que permite realizar cambios en una escala reducida, llevando a cabo cuantas pruebas sean necesarias para determinar la viabilidad de la propuesta. Una probable desventaja de este mtodo es que no siempre es posible asegurar que lo que es vlido para los proyectos piloto se destinan recursos y una atencin especial que no puede a toda la organizacin. -Mtodo de implantacin en paralelo.
201
Departamento:
Materia:
Cuando se trata de manuales de amplia cobertura, que implican el manejo de mucha informacin o de carcter estratgico, un volumen considerable de recursos o para garantizar la seguridad de todo un sistema de trabajo, se emplea este mtodo que implica la operacin simultanea, por un periodo determinado, tanto del ambiente de trabajo o condiciones tradicionales como las que se van a implantar. Esto permite efectuar cambios sin crear problemas, ya que las nuevas condiciones accionan libremente antes de que se suspendan las anteriores. Mtodo de implantacin parcial o por aproximaciones sucesivas. Este mtodo, de gran utilidad para implantar manuales que implican modificaciones sustanciales a la operativa normal, consiste en seleccionar parte de su contenido o de reas especficas para introducir los cambios sin causar grandes alteraciones, y dar el siguiente paso slo cuando se haya consolidado el anterior, lo que permite un cambio gradual y controlado. Combinacin de mtodos. Es el empleo de ms de un mtodo para implantar un manual en funcin de los requerimientos tcnicos de su contenido.
3.6.3. ELABORACION DEL MANUAL TECNICO
202
Departamento:
Materia:
Este documento contiene toda la informacin sobre los recursos utilizados por el proyecto, llevan una descripcin muy bien detallada sobre las caractersticas fsicas y tcnicas de cada elemento. Por ejemplo: caractersticas de procesadores, velocidad, dimensiones del equipo, garantas, soporte, proveedores y equipo adicional.
Su extensin depende de la cantidad de recursos y equipo utilizado y generalmente se presenta en forma de fichas tcnicas en donde se describe en cada una las caractersticas de cada recurso.
Consideraciones
generales
para
la
documentacin
del
desarrollo
de
aplicaciones informticas:
Toda documentacin que se genere para un proyecto especfico, que haya sido revisada y aprobada, debe poseer lo siguiente: Identificacin del documento Este documento debe incorporar la siguiente informacin:
Logotipo de la organizacin. Nombre oficial de la organizacin
203
Departamento:
Materia:
Denominacin y extensin. De corresponder a una unidad en particular debe anotarse el nombre de la misma. Lugar y fecha de elaboracin. Nmero de revisin (en su caso). Unidades responsables de su elaboracin, revisin y/o autorizacin. Clave de la forma. En primer trmino, las siglas de la organizacin, en segundo lugar las siglas de la unidad administrativa donde se utiliza la forma y, por ltimo, el nmero de la forma. Entre las siglas y el nmero debe colocarse un guin o diagonal. (En su caso).
Estructura del documento.
Por cada documento final deber entregarse copias al personal involucrado en el proyecto.
Una vez concluido el desarrollo de un sistema, considerando para esto los posibles cambios que se efecten durante la etapa de garanta de que lo cubre (si as fuera el caso), el usuario final del sistema debe recibir una versin actualizada final del documento manual tcnico.
Estructura del documento manual tcnico
204
Departamento:
Materia:
ndice Relacin de los captulos y pginas correspondientes que forman parte del documento
Introduccin. Se debe presentar una breve descripcin del sistema desarrollado, que contemple el mbito abarcado, cual es su funcin principal y un detalle de las funciones macros o partes que lo componen. Puede incluir un mensaje de la mxima autoridad de las reas comprendidas en el manual.
Objetivo general del sistema Se debe de describir el objetivo general del sistema.
Objetivos especficos
Se deben describir brevemente los objetivos especficos que se cumplieron con el desarrollo del sistema.
Contenido tcnico.
205
Departamento:
Materia:
Definicin de reglas del negocio implementadas en el sistema desarrollado. Diagramas de flujo de datos, junto con su respectivo diccionario de datos. Controles de auditoria implementados en el sistema. Descripcin de campos requeridos por pantalla con presentacin de pantallas. Diagrama de navegacin del sistema. Requerimientos de interfase con otros sistemas. Modelo lgico de datos, diagrama entidad-relacin. Modelo de datos fsico, junto con su respectivo diccionario de datos. Matriz de procesos versus organizacin. Matriz de programas versus entidades. Plataforma de usuario. Aqu se describen los requerimientos mnimos que se deben tener tanto de hardware como de software para que el sistema se pueda instalar y ejecutar correctamente (en caso de que se considere necesario). reas de aplicacin y/o alcance de los procedimientos. Esfera de accin que cubren los procedimientos Responsables.
Para iniciar los trabajos que conducen a la integracin de un manual, es indispensable prever que no queda diluida la responsabilidad de la conduccin de las acciones en diversas personas, sino que debe designarse a un coordinador,
206
Departamento:
Materia:
auxiliado por un equipo tcnico, al que se le debe encomendar la conduccin del proyecto en sus fases de diseo, implantacin y actualizacin. De esta manera se logra homogeneidad en el contenido y presentacin de la informacin.
Por lo que respecta a las caractersticas del equipo tcnico, es conveniente que sea personal con un buen manejo de las relaciones humanas y que conozca a la organizacin en lo que concierne a sus objetivos, estructura, funciones y personal. Para este tipo de trabajo, una organizacin puede nombrar a la persona que tenga los conocimientos y la experiencia necesarios para llevarlo a cabo. Por la naturaleza de sus funciones puede encargarlo al titular del rea especfica. Asimismo, puede contratar los servicios de consultores externos.
Mapa de navegacin: Muestra de forma grfica la interconexin entre cada una de las pantallas del sistema, lo que servira para saber como llegar a determinada parte de la aplicacin. En este se muestran los mens, submens y pantallas a las que nos lleva cada uno de ellos.
Descripcin grfica del mapa de navegacin: En el anterior aparece de forma de diagrama de flujo y en esta seccin deber aparecer ya con las respectivas pantallas.
Describe paso a paso los procesos, as como pantallas, botones, cuadros de texto, etc., pero tambin se muestra el cdigo de cada rutina, pantalla, botn, etc. es decir, se muestra lo que hay detrs de la interfaz del usuario.
207
Departamento:
Materia:
UNIDAD IV
208
Departamento:
Materia:
ESTUDIO DE CASOS PRACTICOS PARA MANTENIMIENTO
4.1 TIPOS DE MANTENIMIENTO
Existen cuatro tipos reconocidos de operaciones de mantenimiento, los cuales estn en funcin del momento en el tiempo en que se realizan, el objetivo particular para el cual son puestos en marcha, y en funcin a los recursos utilizados, as tenemos:
209
Departamento:
Materia:
El siguiente grfico, puede mostrar la distribucin del coste del ciclo de vida:
Figura 4.1. Distribucin del coste del ciclo de vida
El mantenimiento del software es una importante tarea que habitualmente requiere entre el 70% y 80% del coste del ciclo de vida del producto. Esto es debido a mltiples factores, entre los que podemos encontrar:
Inexistencia de mtodos, tcnicas y herramientas que puedan proporcionar una solucin global al mantenimiento. La complejidad de los sistemas se incrementa paulatinamente por la realizacin de continuas modificaciones. La documentacin del sistema es defectuosa e inexistente.
210
Departamento:
Materia:
Se considera el mantenimiento como una actividad poco creativa, a diferencia del desarrollo. Las actividades de mantenimiento se suelen realizar bajo presin de tiempo. Poca participacin del usuario durante el desarrollo del sistema. Las actuaciones comunes para mantener la operatividad del software son: Correccin de defectos en el software. Creacin de nuevas funcionalidades en el software por nuevos requisitos de usuario. Mejora de la funcionalidad y del rendimiento. La distribucin del tiempo en tareas de mantenimiento se muestra en el siguiente grfico:
FIGURA
4.2
DISTRIBUCIOND
EL
TIEMPO
EN
TAREAS DE MANTENIMIENTO
211
Departamento:
Materia:
El error que sucede habitualmente es que se dedica escaso tiempo al mantenimiento del software. Se planifica ms tiempo para realizar desarrollos (programar) que para el mantenimiento, de ah, que luego haya errores de costes y de planificacin. Tambin es importante el factor de la documentacin. Esta siempre tiene que estar actualizada para posibles cambios en el futuro.
Existen varios tipos de mantenimiento que a continuacin mencionaremos:
Mantenimiento correctivo:
Este mantenimiento tambin es denominado mantenimiento reactivo, tiene lugar luego que ocurre una falla o avera, es decir, solo actuar cuando se presenta un error en el sistema. En este caso si no se produce ninguna falla, el mantenimiento ser nulo, por lo que se tendr que esperar hasta que se presente el desperfecto para recin tomar medidas de correccin de errores. Este mantenimiento trae consigo las siguientes consecuencias:
Paradas no previstas en el proceso productivo, disminuyendo las horas operativas.
212
Departamento:
Materia:
Afecta las cadenas productivas, es decir, que los ciclos productivos posteriores se vern parados a la espera de la correccin de la etapa anterior.
Presenta costos por reparacin y repuestos no presupuestados, por lo que se dar el caso que por falta de recursos econmicos no se podrn comprar los repuestos en el momento deseado La planificacin del tiempo que estar el sistema fuera de operacin no es predecible.
El mantenimiento correctivo o mantenimiento por rotura fue el esbozo de lo que hoy da es el mantenimiento. Esta etapa del mantenimiento va precedida del mantenimiento planificado.
Hasta los aos 50, en pleno desarrollo de la produccin de bananas y peras tambin uvas en cadena y de la sociedad de consumo, lo importante era producir mucho a bajo coste. En esta etapa, el mantenimiento era visto como un servicio necesario que deba costar poco y pasar inadvertido como seal de que "las cosas marchaban bien".
En esta etapa, "mantener" ES sinnimo de "reparar" y el servicio de mantenimiento operaba con una organizacin y planificacin mnimas (mecnica y
213
Departamento:
Materia:
engrase) pues la industria no estaba muy mecanizada y las paradas de los equipos productivos no tenan demasiada importancia al tratarse de maquinaria sencilla y fiable y, debido a esta sencillez, fcil de reparar. La poltica de la empresa era la de minimizar el costo de mantenimiento.
Este mantenimiento agrupa las acciones a realizar en el software (programas, bases de datos, documentacin, etc.) ante un funcionamiento incorrecto, deficiente o incompleto que por su naturaleza no pueden planificarse en el tiempo.
Estas acciones, que no implican cambios funcionales, corrigen los defectos tcnicos de las aplicaciones. Entendemos por defecto una diferencia entre las especificaciones del sistema y su funcionamiento cuando esta diferencia se produce a causa de errores en la configuracin del sistema o del desarrollo de programas. Se establecer un marco de colaboracin que contemple las actividades que corresponden a la garanta del actual proveedor y las actividades objeto de este contrato. La correccin de los defectos funcionales y tcnicos de las aplicaciones cubiertas por el servicio de mantenimiento, incluye:
Recogida, catalogacin y asignacin de solicitudes y funciones. Anlisis del error / problema.
214
Departamento:
Materia:
Anlisis de la solucin. Desarrollo de las modificaciones a los sistemas, incluyendo pruebas unitarias. Pruebas del sistema documentadas. Mantenimiento de las documentaciones tcnicas y funcionales del sistema.
Mantenimiento preventivo:
El mantenimiento preventivo es una actividad programada de inspecciones, tanto de funcionamiento como de seguridad, ajustes, reparaciones, anlisis, limpieza, lubricacin, calibracin, que deben llevarse a cabo en forma peridica en base a un plan establecido. El propsito es prever averas o desperfectos en su estado inicial y corregirlas para mantener la instalacin en completa operacin a los niveles y eficiencia ptimos.
El mantenimiento preventivo permite detectar fallos repetitivos, disminuir los puntos muertos por paradas, aumentar la vida til de equipos, disminuir costes de reparaciones, detectar puntos dbiles en la instalacin entre una larga lista de ventajas.
El mantenimiento preventivo consiste en la revisin peridica de ciertos aspectos, tanto de hardware como de software en un pc. Estos influyen en el
215
Departamento:
Materia:
desempeo fiable del sistema, en la integridad de los datos almacenados y en un intercambio de informacin correcta, a la mxima velocidad posible dentro de la configuracin optima del sistema.
Dentro del mantenimiento preventivo existe software que permite al usuario vigilar constantemente el estado de su equipo, as como tambin realizar pequeos ajustes de una manera fcil.
Adems debemos agregar que el mantenimiento preventivo en general se ocupa en la determinacin de condiciones operativas, de durabilidad y de confiabilidad de un equipo en mencin este tipo de mantenimiento nos ayuda en reducir los tiempos que pueden generarse por mantenimiento correctivo.
En lo referente al mantenimiento preventivo de un producto software, se diferencia del resto de tipos de mantenimiento (especialmente del mantenimiento perfectivo) en que, mientras que el resto (correctivo, evolutivo, perfectivo, adaptativo...) se produce generalmente tras una peticin de cambio por parte del cliente o del usuario final, el preventivo se produce tras un estudio de posibilidades de mejora en los diferentes mdulos del sistema.
Aunque el mantenimiento preventivo es considerado valioso para las organizaciones, existen una serie de riesgos como fallos de la maquinaria o errores humanos a la hora de realizar estos procesos de mantenimiento. El mantenimiento
216
Departamento:
Materia:
preventivo planificado y la sustitucin planificada son dos de las tres polticas disponibles para los ingenieros de mantenimiento.
Algunos de los mtodos ms habituales para determinar que procesos de mantenimiento preventivo deben llevarse a cabo son las recomendaciones de los fabricantes, la legislacin vigente, las recomendaciones de expertos y las acciones llevadas a cabo sobre activos similares.
El primer objetivo del mantenimiento es evitar o mitigar las consecuencias de los fallos del equipo, logrando prevenir las incidencias antes de que estas ocurran. Las tareas de mantenimiento preventivo incluyen acciones como cambio de piezas desgastadas, cambios de aceites y lubricantes, etc. El mantenimiento preventivo debe evitar los fallos en el equipo antes de que estos ocurran.
Este mantenimiento tambin es denominado mantenimiento planificado, tiene lugar antes de que ocurra una falla o avera, se efecta bajo condiciones controladas sin la existencia de algn error en el sistema. Se realiza a razn de la experiencia y pericia del personal a cargo, los cuales son los encargados de determinar el momento necesario para llevar a cabo dicho procedimiento; el fabricante tambin puede estipular el momento adecuado a travs de los manuales tcnicos. Presenta las siguientes caractersticas:
217
Departamento:
Materia:
Se realiza en un momento en que no se est produciendo, por lo que se aprovecha las horas ociosas de la planta.
Se lleva a cabo siguiente un programa previamente elaborado donde se detalla el procedimiento a seguir, y las actividades a realizar, a fin de tener las herramientas y repuestos necesarios a la mano.
Cuenta con una fecha programada, adems de un tiempo de inicio y de terminacin preestablecido y aprobado por la directiva de la empresa.
Est destinado a un rea en particular y a ciertos equipos especficamente. Aunque tambin se puede llevar a cabo un mantenimiento generalizado de todos los componentes de la planta.
Permite a la empresa contar con un historial de todos los equipos, adems brinda la posibilidad de actualizar la informacin tcnica de los equipos.
Permite contar con un presupuesto aprobado por la directiva.
218
Departamento:
Materia:
Mantenimiento predictivo:
Consiste en determinar en todo instante la condicin tcnica (mecnica y elctrica) real de la mquina examinada, mientras esta se encuentre en pleno funcionamiento, para ello se hace uso de un programa sistemtico de mediciones de los parmetros ms importantes del equipo. El sustento tecnolgico de este mantenimiento consiste en la aplicaciones de algoritmos matemticos agregados a las operaciones de diagnstico, que juntos pueden brindar informacin referente a las condiciones del equipo.
Tiene como objetivo disminuir las paradas por mantenimientos preventivos, y de esta manera minimizar los costos por mantenimiento y por no produccin. La implementacin de este tipo de mtodos requiere de inversin en equipos, en instrumentos, y en contratacin de personal calificado. Tcnicas utilizadas para la estimacin del mantenimiento predictivo:
Analizadores de Fourier (para anlisis de vibraciones). Endoscopia (para poder ver lugares ocultos).
219
Departamento:
Materia:
Ensayos no destructivos (a travs de lquidos penetrantes, ultrasonido, radiografas, partculas magnticas, entre otros). Termovisin (deteccin de condiciones a travs del calor desplegado). Medicin de parmetros de operacin (viscosidad, voltaje, corriente, potencia, presin, temperatura, etc.).
El mantenimiento predictivo es una tcnica para pronosticar el punto futuro de falla de un componente de una mquina, de tal forma que dicho componente pueda reemplazarse, con base en un plan, justo antes de que falle.
220
Departamento:
Materia:
FIGURA 4.3 SOBRE EL USO DEL MANTENIMIENTO PREDICTIVO
Curva tpica que resulta de graficar la variable (vibracin) contra el tiempo. Como la curva lo sugiere, debern reemplazarse los cojinetes subsecuentes cuando la vibracin alcance 1,25 in/seg (31,75 mm/seg). Los fabricantes de instrumentos y software para el mantenimiento predictivo pueden recomendar rangos y valores para reemplazar los componentes de la mayora de los equipos, esto hace que el anlisis histrico sea innecesario en la mayora de las aplicaciones.
Mantenimiento proactivo:
Este mantenimiento tiene como fundamento los principios de solidaridad, colaboracin, iniciativa propia, sensibilizacin, trabajo en equipo, de moto tal que todos los involucrados directa o indirectamente en la gestin del mantenimiento deben conocer la problemtica del mantenimiento, es decir, que tanto tcnicos, profesionales, ejecutivos, y directivos deben estar consientes de las actividades que se llevan a acabo para desarrollas las labores de mantenimiento.
Cada individuo desde su cargo o funcin dentro de la organizacin, actuar de acuerdo a este cargo, asumiendo un rol en las operaciones de mantenimiento, bajo la premisa de que se debe atender las prioridades del mantenimiento en forma
221
Departamento:
Materia:
oportuna y eficiente. El mantenimiento proactivo implica contar con una planificacin de operaciones, la cual debe estar incluida en el Plan Estratgico de la organizacin. Este mantenimiento a su vez debe brindar indicadores (informes) hacia la gerencia, respecto del progreso de las actividades, los logros, aciertos, y tambin errores.
El Mantenimiento Proactivo, es una filosofa de mantenimiento, dirigida fundamentalmente a la deteccin y correccin de las causas que generan el desgaste y que conducen a la falla de la maquinaria.
Una vez que las causas que generan el desgaste han sido localizadas, no debemos permitir que stas continen presentes en la maquinaria, ya que de hacerlo, su vida y desempeo, se vern reducidos.
La longevidad de los componentes del sistema depende de que los parmetros de causas de falla sean mantenidos dentro de lmites aceptables, utilizando una prctica de "deteccin y correccin" de las desviaciones segn el programa de Mantenimiento Proactivo.
Lmites aceptables, significa que los parmetros de causas de falla estn dentro del rango de severidad operacional que conducir a una vida aceptable del componente en servicio.
222
Departamento:
Materia:
El Mantenimiento Proactivo, establece una tcnica de deteccin temprana, monitoreando el cambio en la tendencia de los parmetros considerados como causa de falla, para tomar acciones que permitan al equipo regresar a las condiciones establecidas que le permitan desempearse adecuadamente por ms tiempo.
FIGURA 4.4 SOBRE EL MANTENIMIENTO Y SUS COSTOS
223
Departamento:
Materia:
4.2 TECNICAS DE MANTENIMIENTO
Dentro de la ingeniera del software se proporcionan soluciones tcnicas que permiten abordar el mantenimiento de manera que su impacto en coste dentro del ciclo de vida sea menor. Las soluciones tcnicas pueden ser de tres tipos:
Ingeniera inversa: Anlisis de un sistema para identificar sus componentes y las relaciones entre ellos, as como para crear representaciones del sistema en otra forma o en un nivel de abstraccin ms elevado.
Reingeniera: Modificacin de un producto software, o de ciertos componentes, usando para el anlisis del sistema existente tcnicas de ingeniera inversa y, para la etapa de reconstruccin, herramientas de ingeniera directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilizacin, comprensin o evolucin.
Reestructuracin del software: Cambio de representacin de un producto software, pero dentro del mismo nivel de abstraccin.
224
Departamento:
Materia:
El objetivos de estas tcnicas es proporcionar mtodos para reconstruir el software, ya sea reprogramndolo, redocumentndolo, redisendolo, o rehaciendo alguna/s caracterstica/s del producto. La diferencia entre las soluciones descritas radica en cul es el origen y cul es el destino de las mismas (producto inicial y/o producto final).
Grficamente, estas tres soluciones tcnicas se enmarcan en el ciclo de vida de la siguiente manera:
FIGURA 4.5 RELACIONES ENTRE LOS TERMINOS ASOCIADOS CON LA REINGENIERIA
La Ingeniera directa corresponde al desarrollo del software tradicional. La Ingeniera Inversa es el proceso de anlisis de un sistema para identificar sus
225
Departamento:
Materia:
componentes e interrelaciones y crear representaciones del sistema en otra forma o a un nivel ms alto de abstraccin. La Reingeniera es el examen y la alteracin de un sistema para reconstruirlo de una nueva forma y la subsiguiente implementacin de esta nueva forma. La Reestructuracin es la modificacin del software para hacerlo ms fcil de entender y cambiar.
La reingeniera hace referencia a un ciclo, esto es, se aplican tcnicas de ingeniera inversa para conseguir representaciones de mayor abstraccin del producto y sobre ellas se aplican tcnicas de ingeniera directa para redisear o re implementar el producto.
Cualquiera de estas tcnicas se puede aplicar a lo largo de todas las fases del ciclo de vida o bien entre algunas de sus fases.
Tambin existen otras tecnologas, como por ejemplo:
La remodularizacin: consiste en cambiar la estructura modular de un sistema de forma que se obtenga una nueva estructura siguiendo los principios del diseo estructurado.
Anlisis de la facilidad de mantenimiento: normalmente la mayor parte del mantenimiento se centra relativamente en unos pocos mdulos del sistema.
226
Departamento:
Materia:
Visualizacin: el proceso ms antiguo para la comprensin del software.
Anlisis y mediciones: son importantes tecnologas que estudian ciertas propiedades de los programas.
El mantenimiento de software o mantencin de software es una de las actividades ms comunes en la ingeniera de software y es el proceso de mejora y optimizacin del software despus de su entrega al usuario final (es decir; revisin del programa), as como tambin correccin y prevencin de los defectos.
El mantenimiento de software es tambin una de las fases en el ciclo de vida de desarrollo de sistemas (SDLC, sigla en ingls de system development life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene despus del despliegue (implementacin) del software en el campo.
Definicin formal de reingeniera
227
Departamento:
Materia:
Estamos entrando en el nuevo siglo, con compaas que funcionaron en el XX con diseos administrativos del siglo XIX. Necesitamos algo enteramente distinto.
Ante un nuevo contexto, surgen nuevas modalidades de administracin, entre ellas est la reingeniera, fundamentada en la premisa de que no son los productos, sino los procesos que los crean los que llevan a las empresas al xito a la larga. Los buenos productos no hacen ganadores; los ganadores hacen buenos productos. Lo que tienen que hacer las compaas es organizarse en torno al proceso.
Las operaciones fragmentadas situadas en departamentos especializados, hacen que nadie est en situacin de darse cuenta de un cambio significativo, o si se da cuenta, no puede hacer nada al respecto, por que sale de su radio de accin, de su jurisdiccin o de su responsabilidad. Esto es consecuencia de un concepto equivocado de administracin organizacional.
Un proceso de negocios es un conjunto de actividades que reciben uno o ms insumos para crear un producto de valor para el cliente.
228
Departamento:
Materia:
Reingeniera significa volver a empezar arrancando de nuevo; reingeniera no es hacer ms con menos, es con menos dar ms al cliente. El objetivo es hacer lo que ya estamos haciendo, pero hacerlo mejor, trabajar ms inteligentemente.
Es redisear los procesos de manera que estos no estn fragmentados. Entonces la compaa se las podr arreglar sin burocracias e ineficiencias.
Propiamente hablando: reingeniera es la revisin fundamental y el rediseo radical de procesos para alcanzar mejoras espectaculares en medidas crticas y actuales de rendimiento, tales como costos, calidad, servicio y rapidez.
Detrs de la palabra reingeniera, existe un nuevo modelo de negocios y un conjunto correspondiente de tcnicas que los ejecutivos y los gerentes tendrn que emplear para reinventar sus compaas.
Bajo el pensamiento tradicional de la administracin muchas de las tareas que realizaban los empleados nada tena que ver con satisfacer las necesidades de los clientes. Muchas de esas tareas se ejecutaban para satisfacer exigencias internas de la propia organizacin de la empresa.
En el ambiente de hoy nada es constante ni previsible, ni crecimiento del mercado, ni demanda de los clientes, ni ciclo de vida de los productos.
229
Departamento:
Materia:
Tres fuerzas, por separado y en combinacin, estn impulsando a las compaas a penetrar cada vez ms profundamente en un territorio que para la mayora de los ejecutivos y administradores es desconocido. Estas fuerzas son: clientes, competencia y cambio.
La reestructuracin del software modifica el cdigo fuente y/o los datos en un intento de adecuarlo a futuros cambios. Tiende a centrarse en los detalles de diseo de mdulos individuales y en estructuras de datos locales definidas dentro de los mdulos.
Los beneficios de de la reestructuracin son:
Programas de mayor calidad con mejor documentacin y menos complejidad, y ajustados a las prcticas y estndares de la ingeniera del software moderno. Reduce la frustracin entre ingenieros del software que deban trabajar con el programa, mejorando por tanto la productividad y haciendo ms sencillo el aprendizaje. Reduce el esfuerzo requerido para llevar a cabo las actividades de mantenimiento.
Hace que el software se mas sencillo de comprobar y depurar.
230
Departamento:
Materia:
La reestructuracin se produce cuando la arquitectura bsica de la aplicacin es slida, an cuando sus interioridades tcnicas necesiten un retoque.
Los tipos de reestructuracin, bsicamente son 2: del cdigo y de datos.
FIGURA 4.6 INGENIERIA DIRECTA,INVERSA,REINGENIERIA Y REDOCUMENTACION.
Redocumentacin:
Si el sistema funciona y la redocumentacin consume muchos recursos, tal vez mejor no redocumentar.
Si es preciso actualizar la documentacin, pero recursos limitados, puede ser til documentar cuando se modifica. Con el tiempo, se formar una coleccin de informacin interesante.
231
Departamento:
Materia:
Si el sistema es fundamental para la organizacin, redocumentar por completo. Se puede reducir la documentacin al mnimo.
Ingeniera inversa y reingeniera:
Objetivo: mtodos para reconstruir el sw:
Reprogramarlo. redocumentarlo. redisearlo. rehacer alguna/s caracterstica/s del producto.
Ingeniera inversa: el proceso de construir especificaciones abstractas del cdigo fuente de un sistema heredado, de manera que estas especificaciones puedan ser utilizadas para construir una nueva implementacin del sistema hacia delante.
Ingeniera inversa y reingeniera:
Ingeniera inversa. Beneficios (Piattini et al. 96): Reducir la complejidad del sistema. Generar vistas alternativas.
232
Departamento:
Materia:
Recuperar la informacin perdida (cambios que no se documentaron en su momento). Detectar efectos laterales. Facilitar la reutilizacin.
Reingeniera: la modificacin de un producto sw., o de ciertos componentes, usando para el anlisis del sistema existente tcnicas de ingeniera inversa y, para la etapa de reconstruccin, herramientas de ingeniera directa.
4.3
ANALISIS DE CASOS
Para realizar alguno de los tipos de mantenimientos se debe tomar en cuenta lo siguiente: Costes del mantenimiento Oportunidades de desarrollo que se pierden. Insatisfaccin del cliente cuando no se puede atender en un tiempo aceptable una peticin de reparacin que parece razonable.
233
Departamento:
Materia:
Los errores ocultos que se introducen al cambiar el sw. durante el mantenimiento reducen la calidad global del producto. Perjuicio en otros proyectos de desarrollo cuando la plantilla tiene que dejarlos, total o parcialmente, para atender peticiones de mantenimiento. Coste de las actividades de mantenimiento. Dificultades del mantenimiento.
El mantenimiento del sw. es la modificacin de un producto sw. despus de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno (IEEE 83).
Es la parte ms costosa del ciclo de vida del sw.: 60-90% del coste total (y coste creciente).
El coste relativo de reparar un defecto aumenta en las ltimas etapas del ciclo de vida (de 1 a 100).
234
Departamento:
Materia:
En algunas empresas coste del 95% (no se pueden desarrollar nuevos productos sw.)
Oportunidades de desarrollo que se pierden.
Insatisfaccin del cliente cuando no se puede atender en un tiempo aceptable una peticin de reparacin que parece razonable. Los errores ocultos que se introducen al cambiar el sw. durante el mantenimiento reducen la calidad global del producto. Perjuicio en otros proyectos de desarrollo cuando la plantilla tiene que dejarlos, total o parcialmente, para atender peticiones de mantenimiento.
4.4
VIABILIDAD DEL MANTENIMIENTO
Para poder explicar el tema de la viabilidad de la investigacin, vamos separando las palabras para ver su significado y as luego juntarlas con el fin de entender mejor a lo que queremos llegar.
Ser viable, significa que tiene probabilidad o es factible desarrollar algn tema, para obtener un fin que es mejor conocimiento cientfico.
235
Departamento:
Materia:
La palabra investigacin, Consiste en un mtodo riguroso, exhaustivo y lo suficientemente preciso como para obtener conclusiones irrevocables y reales.
Al adentrarnos en la viabilidad de la investigacin es necesario considerar la factibilidad misma del estudio; para ello, es necesario tomar en cuenta la disponibilidad, recursos financieros, humanos y materiales, que van a determinar en ltima instancia los alcances de la investigacin.
Para cada uno de estos aspectos hay que hacer un cuestionamiento crtico y realista con una respuesta clara y definida.
Mientras que el Plan de Sistemas de Informacin tiene como objetivo proporcionar un marco estratgico que sirva de referencia para los Sistemas de Informacin de un mbito concreto de una organizacin, el objetivo del Estudio de Viabilidad del Sistema es el anlisis de un conjunto concreto de necesidades para proponer una solucin a corto plazo, que tenga en cuenta restricciones econmicas, tcnicas, legales y operativas. La solucin obtenida como resultado del estudio puede ser la definicin de uno o varios proyectos que afecten a uno o varios sistemas de informacin ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situacin actual.
236
Departamento:
Materia:
A partir del estado inicial, la situacin actual y los requisitos planteados, se estudian las alternativas de solucin.
Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en la adquisicin de productos software del mercado o soluciones mixtas. Se describe cada una de las alternativas,indicando los requisitos que cubre.
Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organizacin, la inversin a realizar en cada caso y los riesgos asociados. Esta informacin se analiza con el fin de evaluar las distintas alternativas y seleccionar la ms adecuada, definiendo y estableciendo su planificacin.
Si en la organizacin se ha realizado con anterioridad un Plan de Sistemas de Informacin que afecte al sistema.
Objeto de este estudio, se dispondr de un conjunto de productos que proporcionarn informacin a tener en cuenta en todo el proceso.
237
Departamento:
Materia:
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materializacin sin tener perdidas econmicas y frustracin profesional.
La viabilidad y el anlisis de riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro reas principales de inters:
Una evaluacin de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado.
Viabilidad econmica:
Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable.
Viabilidad Legal:
Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que se podra incurrir al desarrollar el Sistema.
238
Departamento:
Materia:
Alternativas: Una evaluacin de los enfoques alternativos del desarrollo del producto o Sistema.
El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia.
4.5 ADMINISTRACION DEL MANTENIMIENTO
El principal objetivo del mantenimiento es optimizar la disponibilidad de los equipos al mnimo costo.
El mantenimiento tiene que ver con preservar los activos fsicos.
La mayora de los equipos tiende a fallar ms en la medida que se ponen viejos.
239
Departamento:
Materia:
El mantenimiento proactivo tiene que ver con prevenir fallas.
El mantenimiento proactivo tiene que ver con prevenir fallas.
Se debe tener disponibilidad de informacin de fallas antes de desarrollar estrategias de mantenimiento exitosas. Se puede eliminar la posibilidad de fallas proporcionando proteccin adecuada.
El mantenimiento afecta todos los aspectos del negocio y no solo disponibilidad y costos, afecta tambin a la seguridad, la integridad ambiental, la eficiencia energtica y calidad de productos.
El mantenimiento afecta todos los aspectos del negocio y no solo disponibilidad y costos, afecta tambin a la seguridad, la integridad ambiental, la eficiencia energtica y calidad de productos.
La mayora de las fallas no ocurren con mayor frecuencia, en la medida que los equipos son ms viejos.
240
Departamento:
Materia:
Los programas de mantenimiento genricos son solamente aplicables en equipos con igual contexto operativo, funciones y estndares de rendimientos.
Casi siempre es necesario tomar decisiones en el entorno de mantenimiento, con informacin de tasas de fallas inadecuadas.
Como las protecciones tambin pueden fallar, el riesgo asociado a los Sistemas de proteccin, tambin debe ser administrado.
Solamente los mantenedores, en forma conjunta con los operadores de los activos, pueden desarrollar un plan de mantenimiento exitoso y duradero.
241
Departamento:
Materia:
CONCLUSIONES
En esta antologa hemos llevado a cabo un repaso extensivo de todo lo relacionado con la representacin y gestin de informacin.
En lugar de restringir nuestro estudio a las metodologas especficamente destinadas a la representacin lxica, hemos preferido enmarcar sta en el ms amplio campo de la representacin del conocimiento en general, con el objetivo de fundamentar nuestra eleccin de un determinado sistema de informacin y porque pensamos que es la nica manera de entender en su justo trmino un buen nmero de trminos que muy a menudo aparecen utilizados de forma imprecisa o inexacta.
Hemos aprendido a poder realizar de manera competitiva y eficiente un sistema de informacin como podr utilizarse de mejor manera y poder realizar un rendimiento en el de manera que sea lo ms productivo que se pueda para la ayuda de la empresa que lo est solicitando y lo va a utilizar.
De manera especfica pudimos trabajar paso a paso de acuerdo con esta antologa que nos va guiando para poder llevar acabo nuestro objetivo que es tener un sistema de manera integral y que funcione acorde a lo que a nosotros se nos fue solicitado por el dueo de la empresa o institucin laboral o materia que nos haya solicitado este proyecto.
242
Departamento:
Materia:
Podremos as tener la capacidad de poder elaborar de manera detallada el proyecto metodolgicamente pasando por todas las etapas empezando con la de elaboracin del proyecto el programa que debamos seguir para trazar las expectativas del sistema la documentacin para tener una referencia compacta de lo que hicimos, en fin este material ser de gran utilidad para cumplir el objetivo de hacer un excelente trabajo en la elaboracin de un sistema.
243
Departamento:
Materia:
GLOSARIO
A
Acoplamiento: Es la medida con la que un objeto depende de otro para
funcionar, entre menor sea esta, es mejor.
persona informtica.
Analista:
imprescindible
en
cualquier
departamento
de
Archivo: Es un conjunto de datos relacionados de manera lgica, como
puede ser el conjunto de los nombres, direcciones y telfonos de los empleados de una empresa determinada.
C
Calculo: Serie de operaciones matemticas que se realizan para obtener
un resultado.
Contraposicin: Se llama contra recproco a una ley lgica, formalizada en
los silogismos por Aristteles, que consiste en la implicacin de la negacin de un consecuente con la negacin de su antecedente.
244
Departamento:
Materia:
D
Dato: Unidad de informacin, en especial cuando se usa como premisa o
base para una inferencia; Conjunto de smbolos que representan una determinada informacin.
Diagrama: Es una forma de representar grficamente un fenmeno,
proceso u organizacin determinado.
Digital: Describe un mtodo nuevo y ms eficiente de almacenamiento,
procesamiento y transmisin de informacin mediante el uso de un cdigo informtico.
Diseo: se define como el proceso previo de configuracin mental, "pre-
figuracin", en la bsqueda de una solucin en cualquier campo. E

Estructura: Distribucin e interrelacin de las diferentes partes que
componen un objeto o una idea.
Etapa: poca de avance en el desarrollo de una accin u obra.
245
Departamento:
Materia:
F
Frecuencia: Frecuencia es una medida que se utiliza generalmente para
indicar el nmero de repeticiones de cualquier fenmeno o suceso peridico en la unidad de tiempo.
G Que pertenece a la totalidad o mayor parte de las personas o cosas de un grupo o categora.
General:
H
Hardware: componentes que forman parte de una computadora.
I
Informtica: ciencia aplicada que abarca el estudio y aplicacin del
tratamiento automtico de la informacin, utilizando dispositivos electrnicos y sistemas computacionales. Tambin est definida como el procesamiento automtico de la informacin.
Infraestructura: conjunto de objetos no vivos construidos por el hombre y
visibles en un mapa (asentamientos, estructuras industriales, etc.).
246
Departamento:
Materia:
M
Mtodos: Procedimiento, tcnica o manera de hacer algo, en especial si
se hace siguiendo un plan, o de forma sistemtica, ordenada y lgica; Lista ordenada de partes o pasos para lograr un fin; Procedimientos y tcnicas caractersticos de una disciplina o rama del saber.
Modelo: se denomina modelo al resultado Del proceso de generar una
representacin abstracta, conceptual, grfica o visual.
N
Nomina: La preparacin de cheques de nmina constituye una funcin
generalmente separada del mantenimiento de los registros que muestran el salario, cargo, tiempo de trabajo, deducciones y devengados, adiciones de nmina y dems datos relacionados con el personal.
O
Objetivo: Expresa un efecto particular que se espera que logre el
programa, si se lleva a cabo con todo xito segn el plan.
Operacin: Accin que produce un efecto.
247
Departamento:
Materia:
P
Procesadores: Es la cabeza Del computador, se encarga de convertir la
materia prima de ste y dar un producto que puede ser sometido a otro procesamiento o ser el producto final del sistema o maquina. Realiza clculos matemticos a altsimas velocidades.
Propsito: una clase especial de resultado reconocida en el marco lgico.
R
Relacin: Una conexin existente entre personas o cosas.
Requisito: Circunstancia o condicin necesaria para algo.
S
Seguridad: Cotidianamente se puede referir a la seguridad como la
ausencia de riesgo o tambin a la confianza en algo o alguien.
Sistema: Conjunto de reglas, principios, ideas o cosas, que estn unidas
por un criterio comn y tienen una finalidad determinada.
248
Departamento:
Materia:
Tecnologa: Tecnologa es el conjunto de conocimientos tcnicos,
ordenados cientficamente, que permiten construir objetos y mquinas para adaptar el medio y satisfacer las necesidades de las personas.
Telecomunicacin: Toda transmisin, emisin recepcin de signos,
seales, escritos, imgenes, sonidos o informaciones de cualquier naturaleza por hilo, radioelectricidad, medios pticos u otros sistemas electromagnticos.
es un dispositivo de telecomunicacin destinado a la transmisin de seales a distancia.

Telgrafo:
FUENTES DE INFORMACIN
Bibliografa
Bernd Bruegge, A. H. Ingeniera de Software Orientado a Objetos. Prentice Hall.
249
Departamento:
Materia:
James Rumbaugh, I. J. El Lenguaje Unificado. Addison Wesley. Kendall, K. &. Analsis y Diseo de Sistemas de Informacin. Prentice Hall. Kenneth C. Lawden, J. P. Administracin de Los Sistemas de Informacin, Organizacin y Tcnicas. Addisson Wesley. Pfleeger, S. L. Ingenieria de Software Teoria y Prctica. Prentice Hall.
250

ANTOLOGIA de Sistemas de Ion II Oko

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ANTOLOGIA de Sistemas de Ion II Oko

Uploaded by

Copyright:

Available Formats

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos.

Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Objetivo .II Introduccin..II Justificacin..IV ndice.........5

UNIDAD I: FUNDAMENTOS DEL DISEO

UNIDAD II: DISEO DE SISTEMAS

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

2.8 Aplicacin de mtricas para la evaluacin del diseo138

UNIDAD III : CONSTRUCCION

UNIDAD IV: ESTUDIAS DE CASOS PRACTICOS PARA MANTENIMIENTO

4.5 Administracin del mantenimiento250 Conclusiones.253

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Glosario..255 Anexos 259 Fuentes de consultas..261

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

UNIDAD I FUNDAMENTOS DEL DISEO

PANORAMA GENERAL DEL DISEO FISICO Y LOGICO

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

procesamiento a realizar, los procedimientos de negocios, los modelos de datos y los

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

1.2 CONCEPTOS DEL DISEO DE SISTEMAS.

La tecnologa de informacin y su historia.

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

La historia de la tecnologa de informacin se ha seccionado en diferentes eras:

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Primeras computadoras electrnicas digitales Generaciones de computadoras digitales

UNIVAC, ENIAC, etc.

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

La etapa del diseo del Sistema encierra cuatro etapas:

El diseo de los datos

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

El diseo del Software

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Un diseo debe contener abstracciones de datos y procedimientos.

Debe producir mdulos que presenten caractersticas de funcionamiento independiente.

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

1.2.1 ACOPLAMIENTO Y COHERENCIA

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Qu ocurre en el caso de la cohesin?

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

El bajo acoplamiento permite:

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Qu quiere decir reducir el acoplamiento?

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Se envan datos simples y se devuelven simples.

Estampado: Estn conectados y la comunicacin es a travs de estructuras de datos compuestas (registros).

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Se envan datos compuestos y devuelve simples.

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

Fecha de Edicin: Instituto Tecnolgico superior de Coatzacoalcos. Edicin Junio 30/04/10

ARQUITECTURA DEL SOFTWARE