1 Procesos de la ingeniera de requerimientos. 1.1 Requerimientos de proceso.

Requerimientos del sistema Los Sistemas de Informacin por computadora normalmente estn integrados por muchos componentes. En la mayor parte de los casos, es difcil para los analistas entender todos estos componentes an mismo tiempo; por lo tanto los investigadores tienen que comenzar con preguntas de tipo general con relacin al propsito del sistema sus entradas y salidas de los procesos incluidos. En los grandes proyectos de sistema varios analistas llevan a cabo una investigacin en forma seccionada que la distribuyen entre ellos mismos, de manera que cada uno pueda trabajar en forma independiente. Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de informacin. Se clasifican en dos tipos: 1. - Flujo de Datos. 2. - Estrategias de Anlisis de Decisin para el Conocimiento para los Sistema de Informacin. Estrategia del Flujo de Datos Cuando se siguen un flujo a travs de los procesos de negocio, que es el propsito del anlisis del flujo de datos, le indica a los analistas una gran cantidad de datos sobre como se esta llevando a cabo los objetivos de la compaa. Al manejar las transacciones y completar las tareas, los datos de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten. El anlisis de flujo de datos que muestra el estudio y el uso de cada actividad, documenta los hallazgos en los diagramas de flujo de datos. Estrategia del Anlisis de Decisiones La estrategia del anlisis de decisiones es un complemento del anlisis del flujo de datos. Esta estrategia realza el estudio de los objetivos de una operacin y de las decisiones que deben realizarse para cumplir con los objetivos. Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial, las estrategia de anlisis de decisin con frecuencia utiliza por parte de alta gerencia para desarrollar la toma de decisiones. La alternativa que selecciona los gerentes responsables en la toma de decisiones, en cuanto a una estrategia de precios entre un conjunto de alternativas, se maneja de forma diferente a la la opcin que toman un supervisor de departamento para aceptar o rechazar pedidos. La decisin de rechazar pedidos generalmente ocurre con mas frecuencia, de manera que las condiciones y acciones normalmente se conocen como un aspecto importante. Etapas en la Estrategia del Anlisis del Flujo de Datos 1. - Estudiar las operaciones y procesos en marcha. 2. - Identificar cmo se procesan los datos al manejar transacciones y terminar las tareas. 3. - Seguir el flujo de datos: * Proceso * Almacenamiento * Recuperacin * Salida 4. - Aadir gradualmente detalles a los niveles inferiores. Etapas en la Estrategia del Anlisis de Decisin 1. -Estudiar los objetivos y decisiones necesarias. 2. - Desarrollar un modelo del proceso de decisin.

3. - Probar el modelo con datos de prueba. 4. - Identificar los requerimientos del proceso para los datos. 4. Requerimientos De Salida Niveles de diseo El diseo de sistema se representa a travs de dos fases: el diseo lgico y el diseo fsico. Cuando los analistas formulan un diseo lgico; escriben las especificaciones detalladas del nuevo sistema; esto es, describen sus caractersticas: las salidas, entradas, archivos y bases de datos y procedimientos; todos de manera que cubran los requerimientos del proyecto. El diseo lgico de un sistema de informacin es como el plano de un ingeniero para armar un automvil: muestra las caractersticas principales(motor, transmisin y rea para los pasajeros)y como se relacionan unas con otras(donde se conectan entre s los componentes del sistema, o por ejemplo, cuan separadas estn las puertas. Los informes y la produccin del analista son los componentes de todo el mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje. El diseo lgico tambin especifica las formas de entrada y las descripciones de las pantallas de todas las transacciones y archivos a fin de mantener los datos de inventario, los detalles de las transacciones y los datos del proveedor. Las especificaciones de los procedimientos describen mtodos para introducir los datos, corridas de informes copiados de archivos y deteccin de problemas. El diseo fsico, actividad que sigue el diseo lgico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseo indican a los programadores que debe hacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas por parte de los usuarios, procesan los datos, producen los informes y almacenan estos datos en los archivos. Utilizacin de los Datos de Requerimientos: El alcance del diseo de sistemas se gua por el marco de referencia para el nuevo sistema desarrollado durante el anlisis. Los datos de los requerimientos, recopilados durante la investigacin, conforman las actividades y componentes del sistema. Los analistas formulan un diseo lgico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiar como resultado de un nuevo diseo. El diseo lgico va de arriba hacia abajo, como lo hizo la determinacin de requerimientos. En primer lugar se identifican las caractersticas generales, como informes y entradas; en el diseo de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato especifico para establecer cuanto espacio dejar en la informacin, en la pantalla de despliegue visual o archivo. Participacin de los Usuarios: Los gerentes y usuarios del sistema tambin poseen un papel importante en le diseo del sistema; no es solamente el proyecto del analista. Durante el diseo, a algunos se les pide que revisen los borradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura de los procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada. La participacin del usuario proporciona al analista una retroalimentacin importante conforme avanza en el diseo; adems asegura a los usuarios tengan un conocimiento no tcnico de lo realizara o no el nuevo sistema. Esta visin general del diseo de sistemas subraya los aspectos de diseo que se vern mas adelante en el diseo de la salida de sistema. Prototipo de Sistemas: Los requerimientos del sistema y las especificaciones de diseo se establecen con claridad y son muy bien entendidas, y los analistas tienen la experiencia para convertir los requerimientos en un sistema eficiente y que trabaje bien. Los prototipos de sistemas pueden desarrollarse para proporcionar la informacin necesaria y producir un sistema adecuado.

Razones para Desarrollar Prototipos de Sistemas: A pesar de los mejores esfuerzos de los analistas de sistemas, las necesidades de informacin no siempre se establecen correctamente. Esto puede ocurrir por dos razones: Los usuarios pueden saber solo lo que necesitan mejorar el sistema en ciertas reas del negocio, o que deben modificar los procedimientos existentes; por otro lado, conocer que mejor informacin para administrar ciertas actividades. Mtodos para el Desarrollo de Prototipos: Los sistemas de prototipo se pueden desarrollar utilizando lenguajes de programacin y mtodos convencionales. El procesamiento y los controles de entrada pueden faltar y la documentacin del sistema normalmente falta en su totalidad. La clave esta en las pruebas de las ideas y en proporcionar suposiciones sobre los requerimientos, no tanto en la eficiencia del sistema o en exactitud o perfeccin. En algunos casos cuando el sistema se utiliza en forma muy frecuente en la formulacin de La forma en que s esta llevando a cabo el diseo de salida del sistema. Diseo de la Salida de Sistemas: A menudo, para los usuarios la caracterstica ms importante de un sistema de informacin es la salida que produce. Si la salida no es de calidad, se pueden convencer de que todo el sistema es tan innecesario que eviten su utilizacin y, por lo tanto, posiblemente ocasionen errores y que el sistema falle. Diseo Lgico de la Salida: l termina "salida" se aplica a cualquier informacin producida por un sistema, ya sea impresa, desplegada o verbal. Cuando los analistas disean la salida, seleccionan mtodos para representar la informacin y crean documentos, informes u otros formatos que contienen informacin producida por el sistema. Los mtodos de salida varan a lo largo de los sistemas. Para algunos, como un informe de inventarios de la cantidad de mercanca, el sistema del computador, bajo el control del programa, nada mas consulta los datos que se tienen a mano en el almacenamiento, y los ensambla en una forma que sea presentable. Otra salida puede requerir procesamiento sustancial, antes de que este disponible para utilizarlo. Los analistas deben decidir cuando imprimir, desplegar o presentar su salida en forma audible. La salida impresa puede utilizar papel en blanco o formas preimpresas, la salida visual puede utilizar una o mltiples pantallas para desplegar informacin. Seleccin de los Mtodos de Salida Los sistemas de informacin ya sean que se desarrollen sobre sistemas pequeos de escritorio o sobre grandes sistemas, utilizan 3 mtodos principales para la salida los cuales se clasifican en: Impresin Pantalla Despliegue y audio

Salida Impresa Este tipo de salida es la que se encarga de producir grandes volmenes de informes impresos, sin embargo la decisin de utilizar salida impresa no debe ser automtica, debe haber alguna razn como la necesidad de enviar a un cliente o proveedor un documento por correo, tener un registro impreso de los datos o circular una cantidad de informacin a diferentes personas en forma simultanea. Un informe bien diseado puede reemplazar a otro elaborados pobremente, proporcionando detalles innecesarios la cual no ayuda nada. Las opciones de salida impresa ms comunes en las empresas son en papel, informe filmados, formas especiales y formas para enviar por correo.

Objetivos de la Salida Expresar la Informacin Relacionada con Actividades Pasadas, Estado Actual o Proyecciones para el Futuro. Sealar Eventos Importantes, Oportunidades, Problemas Advertencia. Iniciar una Accin Confirmar una Accin.

El objetivo principal durante el diseo de salida de la computadora es la informacin que ser presentada a las personas, puede afirmarse que la salida de la computadora es para las personas, es por esto que no se aborda la forma en que los datos se mueven entre los procesos o entre los almacenamientos de datos. Tipos de salida La Salida del Sistema Puede Ser: un reporte un documento un mensaje

de acuerdo con las circunstancias y los contenidos, la salida puede ser impresa o presentada en una pantalla, el contenido de la pantalla tiene su origen en las siguientes fuentes: Recuperacin de un Dispositivo de Almacenamiento. Transmisin desde un Proceso o Actividad del Sistema. Directamente desde una Fuente de Entrada.

6. Conclusin La funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales: Software, que son Programas de computadora, con estructuras de datos y su documentacin que hacen efectiva la logstica metodologa o controles de requerimientos del Programa. Hardware, dispositivos electrnicos y electromecnicos, que proporcionan capacidad de clculos y funciones rpidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin externa dentro de los Sistemas. Personal, son los operadores o usuarios directos de las herramientas del Sistema. Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software. Documentacin, Manuales, formularios, y otra informacin descriptiva que detalla o da instrucciones sobre el empleo y operacin del Programa. Procedimientos, o pasos que definen el uso especifico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento.

1.2 Requerimientos de los usuarios (actores involucrados).

3. Requerimientos De Entrada

Es el enlace que une al sistema de informacin con el mundo y sus usuarios, en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son: Objetivos del Diseo de Entrada. Captura de Datos para la Entrada.

Objetivo del Diseo de Entrada Consiste en el desarrollo de especificaciones y procedimientos para la preparacin de datos, la realizacin de los procesos necesarios para poner los datos de transaccin en una forma utilizable para su procesamiento as como la entrada de los datos se logra al instruir a la computadora para que lea ya sea documentos escritos, impresos por personas que los escriben directamente al sistema. Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos, controlar los errores y mantener la sencillez de los pasos necesarios, estos son: Control de la Calidad de Entrada Evitar los Retrasos Evitar los errores en los datos Evitar los pasos adicionales Mantener la Sencillez del Proceso

Control de la Calidad de Entrada: Existen varias razones por las cuales un buen diseador debe controlar la cantidad de datos en la entrada: - Las Operaciones de preparacin y entrada dependen de las personas dado que los costos de mano de obra son altos y la preparacin de ingreso de los datos tambin lo son. - La fase de entrada puede ser un proceso lento que toma mucho mas tiempo que el que necesitan las computadoras para realizar sus tareas. Evitar los Retrasos: Tambin conocido con el nombre de cuello de botella son siempre uno de los objetivos que el analista evita al disear la entrada, una forma de evitarle es utilizar los documentos de retorno. Evitar los errores en los datos: La tasa de errores depende de la cantidad de datos, ya que entre mas pequea sea esta menores sern las oportunidades para cometer errores. Es comn encontrar en las operaciones de ventas por lo menos un 3% de errores en las operaciones de entrada de datos. Evitar los Pasos Adicionales: Algunas veces el volumen de transacciones y la cantidad de datos en preparacin es algo que no se puede controlar por ello el analista experimentado, evitara diseos para la entrada que traigan una mayor cantidad de pasos a seguir. Ya sea aadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso de un da. Mantener la sencillez del Proceso: El sistema mejor diseado se ajusta a las personas que lo utilizarn y al mismo tiempo proporcionarn mtodos para el control de los errores, la simplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajo que los usuarios acepten sistemas complejos o confusos y que no exista ninguna garanta para el xito al instalar un sistema complejo y que domine. Captura de Datos para la Entrada: En una transaccin existen datos importantes y otros que no, el analista debe saber cuales utilizar y cuales en realidad deben formar la entrada. Existen dos tipos de datos: datos variables datos de identificacin

Datos Variables: Son aquellos que cambian para cada transaccin o toman de decisin. Datos de Identificacin: Estos son los que identifican en forma nica el artculo que esta siendo procesado.

1.3 Requerimientos para el anlisis y negociacin.

Gerencia de Proveedores de Bienes y Servicios: 1. Calificacin de proveedores de bienes y servicios. 2. Anlisis de la licitacin y recomendaciones. 3. Precio Mximo Garantizado /Llave en Mano /administracin delegada u otros. 4. Asistencia en la seleccin de contratistas y proveedores. 5. Anlisis comparativo de contratos y presupuestos. Negociacin de Contrato: 1. Metas de tiempo y costo. 2. Desarrollo del contrato/ Revisin de las clusulas 3. Seguros /Fianza y garantas. 4. Anlisis de contrato y reportes ejecutivo. 5. Administracin de contrato durante la construccin.
1.4 Requerimientos para la gestin.
5. Requerimientos de almacenamiento La memoria de la computadora (RAM) es un lugar provisional de almacenamiento para los archivos que usted usa. La mayora de la informacin guardada en la RAM se borra cuando se apaga la computadora. Por lo tanto, su computadora necesita formas permanentes de almacenamiento para guardar y recuperar programas de software y archivos de datos que desee usar a diario. Los dispositivos de almacenamiento (tambin denominados unidades) fueron desarrollados para satisfacer esta necesidad. Los siguientes constituyen los tipos ms comunes de dispositivos de almacenamiento: Unidades de: Disco duro Disquete Compresin ZIP CD DVD

Disco Duro El disco duro es el sistema de almacenamiento ms importante de su computador y en el se guardan los archivos de los programas - como los sistemas operativo D.O.S. o Windows 95, las hojas de clculo (Excel, Qpro, Lotus) los procesadores de texto (Word, WordPerefct, Word Star, Word Pro), los juegos (Doom, Wolf, Mortal Kombat) - y los archivos de cartas y otros documentos que usted produce. Un Disco Duro en Buen Estado Existen varias cosas que usted puede realizar para prevenir que la computadora le devuelve mensajes de error molestos. A continuacin encontrar una lista de programas diferentes disponibles para asegurarse de que la unidad de disco duro se mantenga saludable y funcionando a plena capacidad. (Estn disponibles estos programas de ejemplo a travs de Windows 95. Usted puede comprar otros programas para realizar las mismas tareas; simplemente hay que hablar con un distribuidor local de software para la computadora.) Utilidad de Desfragmentacin de Disco Al transcurrir el tiempo, es posible que los archivos se vuelvan fragmentados porque se almacenan en posiciones diferentes en el disco. Los archivos estarn completos cuando los abra, pero la computadora lleva ms tiempo al leer y escribir en el disco. Estn disponibles programas de desfragmentacin que corrigen esto. Para obtener acceso al programa de desfragmentacin de disco bajo Windows 95, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en Utilidad de Desfragmentacin de Disco. Compresin de Datos Usted puede obtener espacio libre en la unidad de disco duro o en disquetes al comprimir los datos que estn almacenados en stos. En Windows 95, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en DriveSpace. Deteccin de Daos Si experimenta problemas con los archivos, tal vez quiera averiguar si existen daos en el disco. ScanDisk de Windows 95 verifica los archivos y las carpetas para encontrar errores de datos y tambin puede verificar la superficie fsica del disco. Para ejecutar ScanDisk, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en ScanDisk. Adems, es posible que la unidad de disco duro puede estar 'infectada' con un virus, si ha transferido los archivos o datos de otra computadora. Existen varios programas de deteccin y limpieza de virus que estn disponibles para usted. Simplemente hay que pedirlos del distribuidor local de software para computadoras. Respaldo Si la unidad de disco duro se descompone o si los archivos se daan o se sobrescriben accidentalmente, es una buena idea contar con una copia de respaldo de los datos de la unidad de disco duro. Estn disponibles varios programas de respaldo de uso con cintas, disquetes y aun con los medios desmontables. A menudo, la computadora tendr una utilidad de respaldo ya instalada. Unidad de Disquete y CD Puede obtener acceso a la unidad de CD y la unidad de disquetes desde el panel frontal de la computadora. La unidad de CD consiste en un dispositivo de 5,25 pulgadas con una ranura cubierta o con una bandeja deslizable, un botn de carga / expulsin y un indicador de actividad luminoso. La unidad de disquetes consiste en un dispositivo de 3,5 pulgadas con una ranura cubierta, un botn de expulsin y un indicador de actividad luminoso.

Escritura

Lectura

Nombre Disco magntico (para lectura y escritura)

Tipos Disco rgido, disquete, Zip, Jazz, Bernouilli Floptical. DVD-ROM (slo lectura)

Por grabacin magntica de pistas concntricas Por censado mediante la mediante una cabeza constituida por un misma cabeza que escribi electroimn. actuando en forma inversa Por modelado de hoyos formando una pista en espiral, por inyeccin de plstico en un molde metlico (produccin masiva de CDs) Por efecto trmico de un rayo lser se modifica la transparencia de porciones de una pista en espiral, en una capa de material orgnico

Censado por rayo lser de la CD-ROM longitud de los hoyos (slo lectura) grabados y de la distancia que separa dos hoyos sucesivos Censado por rayo lser de la longitud de las porciones transparentes y las no transparentes de la espiral grabada Censado de campos magnticos en las pistas por su efecto en un rayo lser Censado por rayo lser del estado cristalino del material de las pistas CD-R (Slo lectura)

Por grabacin magntica auxiliada por accin trmica de una rayo lser de potencia Por efecto trmico de un rayo lser de potencia se modifica el estado cristalino de un material

MO (lectura y escritura) CD-RW E (para lectura y escritura) DVD-RAM, PD

2 Planificacin del sistema. Etapa uno

Planificacin Pre-Construccin Una clara visin, enfoque y direccin es esencial en un proyecto exitoso. El primer paso es formar parte de su Equipo y entrevistarnos con su alta gerencia para hacer propios su filosofa, objetivos y metas corporativas; as como establecer que sus presupuestos y cronograma de trabajo se ajusten al plan de negocio. Estas reuniones son clave, ya que definen los parmetros bajo los cuales se medir el xito del proyecto. La planificacin de pre-construccin permite un anlisis lgico y ordenado sus necesidades fsicas y cul es la ptima configuracin y metodologa del trabajo requerido. Adicional al anlisis fsico para nuevas construcciones o remodelaciones, se realiza un profundo anlisis de la zonificacin, normas municipales, permisos necesarios, estructura impositiva, aspectos laborales, y otros costos blandos que puedan influir en el presupuesto, que son revisados minuciosamente. Etapa Dos:

Diseo El 80% de los costos duros se definen en el primer 30% del la fase de diseo. Debido a que el potencial para lograr ahorros disminuye sustancialmente posterior a esta etapa, es importante contar con la experticia de su equipo CBB en las primeras etapas del proyecto. Ayudaramos a aclararle a los profesionales proyectistas tales como arquitectos, ingenieros, constructores y proveedores todas las especificaciones y requerimientos para lograr ptimos resultados. Sobre disear agrega costos y una especificacin pobre aumentar costos de operacin y obligar a efectuar gastos imprevistos en mejoras. Investigaremos, analizaremos, recomendaremos y haremos seguimiento a los profesionales y contratistas aprobados para asegurar el fiel cumplimiento a sus compromisos contractuales. Mantenemos actualizado una base de costos para asegurarnos que los presupuestos de proyecto se estarn cumpliendo. Elaboraremos proyecciones y estimaciones de costos de operacin y mantenimiento predictivo para las instalaciones en su posterior fase de operacin. Etapa Tres: Revisin de Presupuestos La coordinacin del proceso de diseo asegura que las especificaciones y planos de construccin estn completos, garantizando que los presupuestos incluirn todas las partidas esperadas. Planos inexactos, falta de detalles, e instrucciones deficientes a los contratistas licitantes resultarn en aumentos de obra sustanciales o posiblemente la sustitucin de materiales de baja calidad por los contratistas. El equipo CBB prepara un paquete completo de licitacin con instrucciones precisas, la metodologa de construccin y los cronogramas de tiempo esperados. Antes de proceder a invitar las empresas a licitar Usted estara totalmente informado de las diferentes maneras que existen de solicitar propuestas y cmo influyen en los objetivos del proyecto. Precio Mximo Garantizado, Suma Global Modificada, Llave en Mano, Administracin Delegada o Fast Track, entre otros, son mtodos de solicitud de propuesta que seran analizados para limitar y controlar los posibles ajustes de los costos de construccin

Etapa Cuatro: Negociacin Etapa Seis: Cierre Un aspecto vital que es comnmente olvidado es el cierre del proyecto. Esta actividad asegura que las instalaciones quedan operativas, listas para abrir al pblico, de acuerdo a las metas corporativas previstas. El equipo CBB prueba todos los equipos y todos los sistemas haciendo entrega de las instalaciones al equipo que va a operar las instalaciones. CBB rene todas las garantas y manuales de operacin e instruye al personal en modos eficiente de operacin de sus nuevas instalaciones. Aseguramos que las revisiones y lista de chequeo se efecta en el momento apropiado para asegurar que usted recibe una instalacin funcionando y con la informacin tcnica necesaria para su futura operacin y mantenimiento. Llevamos a cabo una auditoria del proyecto como parte de nuestro programa de Calidad Total para conciliar costos y para efectuar las crticas de procedimientos que puedan mejorar futuras instalaciones similares. Sugeriremos un programa de mantenimiento, predictivo y preventivo para asegurar estabilidad en sus costos de operacin y mantener las instalaciones Cuando se reciben las diferentes cotizaciones, el equipo CBB efecta comparaciones manzanas con manzanas tomando muy en cuenta los aspectos que cada contratista excluye de su cotizacin. Se preparan entrevistas con cada contratista para analizar partida por partida el contenido de su propuesta y solicitar las revisiones si as fuera necesario. El Equipo recomendara a usted el contratista que a su juicio es el ms apropiado para llevar a cabo la tarea, para posteriormente iniciar las negociaciones contractuales. CBB revisara y preparara contratos que por experiencia han sido exitosos en estos casos, reduciendo la carga de abogados externos quienes solo tendran que revisar y modificar documentos ya preelaborados. Los contratos incluyen proteccin contra daos, penalidades por incumplimientos, clusulas de incentivo y procedimientos de pago, cierre de obra y modificaciones. Etapa Cinco: Monitoreo de la Construccin Con el equipo de gerencia CBB estructurado, se efectan las revisiones finales de seguros, fianzas, seguridad fsica y permisos en la obra. Durante el proceso se desarrollar una actividad continua e intensa de control de calidad, control de costos y control de avance cierto. Por medio de una constante presencia en la obra y reuniones de coordinacin

en un ptimo estado de funcionamiento de tal manera que el mantenimiento no interfiera con la actividad medular de su empresa. Asistiremos en el proceso de mudanza en todas sus etapas; asegurando que la puesta en marcha de las oficinas se lleve a cabo sin mayores tropiezos o incomodidad. Esta es una etapa crtica que requiere de intensa supervisin para poder finalizar los proyectos con gran xito.
http://www.cbb.com.ve/servicios/GERENCIA.html 2.1 Planificacin del tiempo.

La planificacin en tiempo real es uno de los campos de investigacin ms activos en la informtica. En este apartado, se ofrecer una introduccin a los distintos mtodos de planificacin en tiempo real y se estudiarn dos algoritmos de planificacin clsicos. En un estudio de los algoritmos de planificacin en tiempo real, se observa que los distintos mtodos de planificacin dependen de s el sistema lleva a cabo un anlisis de planificacin: en caso afirmativo, si se realiza esttica o dinmica: y si el resultado del anlisis genera un plan con respecto al cual se expiden las tareas durante la ejecucin. Basndose en estas consideraciones, los autores identifican las siguientes clases de algoritmos:

Mtodos con tablas estticas: realizan un anlisis esttico de las planificaciones de expedicin posibles. El resultado del anlisis es una planificacin que determina, un tiempo de ejecucin, cuando debe comenzar la ejecucin de una tarea.

Mtodos preferentes con prioridades estticas: tambin se realiza un anlisis esttico, pero no se realiza ninguna planificacin. En cambio, se usa dicho anlisis para asignar prioridades a tareas, de forma que se pueda emplear un planificador convencional preferente con prioridades.

Mtodos de planificacin dinmica: se determina la viabilidad en tiempo de ejecucin (dinmicamente) en vez de antes de empezar la ejecucin (estticamente). Se acepta una nueva tarea para ejecutar slo si es factible cumplir sus restricciones de tiempo. Uno de los resultados del anlisis de

viabilidad es un plan o proyecto empleado para decidir cuando se expide cada tarea.

Mtodos dinmicos del mejor resultado: no se realiza ningn anlisis de viabilidad. El sistema intenta cumplir todos los plazos y abandona cualquier proceso ya iniciado y cuyo plazo no se haya cumplido.

La planificacin con tablas estticas es aplicable a tareas peridicas. La entrada del anlisis consta del tiempo peridico de llegada, el tiempo de ejecucin, el plazo peridico de finalizacin y la prioridad relativa de cada tarea. El planificador intenta trazar un plan que le permite cumplir las exigencias de todas las tareas peridicas. Este es un plan que le permite cumplir las exigencias de todas las tareas peridicas. Este es un mtodo predecible, pero tambin es inflexible, puesto que cualquier cambio en las exigencias de una tarea. Son tpicos de esta categora los algoritmos de planificacin de primero el plazo ms prximo u otras tcnicas peridicas de plazos.

La planificacin preferente con preferente con prioridades estticas hace uso del mecanismo de planificacin referente con prioridades, habitual en la mayora de los sistemas muliprogamados que no son en tiempo real. En un sistema que no es real, puede emplearse una gran variedad de factores para determinar la prioridad. Pro ejemplo, en un sistema en tiempo compartido, la prioridad de un proceso cambia dependiendo de s tiene carga de procesador o de E/S. En un sistema en tiempo real, la asignacin de prioridades se encuentra relacionada con las restricciones de tiempo asociadas a cada tarea. Un ejemplo de

ese mtodo es el algoritmo montono de frecuencia, que asigna prioridades estticas a las tareas en funcin de sus periodos.

La planificacin dinmica basada en un plan, despus de que una tarea llega al sistema, pero antes de comenzar a ejecutarla, se intenta crear un plan que contenga las tareas previamente planificadas, as como la recin llegada. Si la recin llegada puede planificarse de forma que se cumplan sus plazos y que no se pase ningn plazo de las tareas ya planificadas, se revisa el plan para hacer sitio a la nueva tarea.

La planificacin dinmica del mejor resultado, es el mtodo utilizado en la mayora de los sistemas en tiempo real comercializados en la actualidad. Cuando llega una tarea, el sistema le asigna una prioridad en funcin de sus caractersticas. Normalmente, se emplea alguna forma de planificacin por plazo, como puede ser la de primero el plazo ms prximo. En general, las tareas son peridicas, por lo que no es posible un anlisis esttico de planificacin. Con este tipo de planificacin, no se sabe si se va a cumplir una restriccin de tiempo hasta que vence el plazo o la tarea termina. Esa es la mayor desventaja de esta forma de planificacin. Su ventaja est en la facilidad de implementacin.

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/PLAPR O02_archivos/planificacion_en_teimpo_real.htm

En los mercados donde la demanda es variable, tanto en cantidad como en composicin, existen bsicamente dos lneas a seguir para hacer frente a dicha variabilidad: crear stocks si es posible, con los costes que ello supone, en pocas de poca demanda para poder hacer frente a los picos que sta puede presentar en otros perodos, y adaptar la capacidad productiva a la demanda. Una de las formas de lograr esta armonizacin entre la demanda y la capacidad productiva es mediante la anualizacin de la jornada laboral. La anualizacin de la jornada laboral es una de las formas que existen para flexibilizar la capacidad productiva; consiste en distribuir las horas anuales contratadas, a lo largo del ao y en funcin de la demanda prevista; de este modo, cada trabajador/a puede realizar jornadas de diferente duracin a lo largo del ao, respetando, claro est, ciertos lmites y reglas. Cada vez son ms las empresas que pactan en sus convenios una reduccin de jornada a cambio de anualizarla, estableciendo, por otro lado, diferentes restricciones. En Francia, la ley

Aubry II, que establece esencialmente una reduccin del tiempo de trabajo a 35 horas semanales en promedio sin reduccin de salario, permite, a cambio, una anualizacin sujeta a diversas reglas que deben tenerse en cuenta al realizar la planificacin del tiempo de trabajo (en la fecha del 5 de julio de 2000, se haban suscrito en Francia 35.367 convenios de reduccin de la jornada laboral [27]). Esta anualizacin debe, adems de adaptarse a la demanda, respetar diversas reglas, algunas legales (por ejemplo, la jornada laboral mxima) y otras establecidas en los convenios (por ejemplo, nmero mximo de semanas consecutivas con una jornada semanal media de, como mximo, 46 horas, nmero mximo de horas flexibles, etc.), por lo que surgen nuevos problemas de planificacin, de programacin de la jornada de trabajo y de asignacin de tareas. De esta manera, se abren nuevas posibilidades en la gestin de la jornada laboral, pero stas generan nuevos problemas, ms difciles de resolver en los servicios que en la industria porque en ellos las fluctuaciones suelen ser ms acusadas y porque los productos no pueden almacenarse para constituir stocks. A pesar de su importancia, y tal y como se expone a continuacin, el tema de la anualizacin ha sido poco tratado, especialmente desde un punto de vista cuantitativo, en la literatura cientfica. En Hung [20], pese a lo que pueda sugerir el ttulo de dicho trabajo ("Scheduling a workforce under annualized hours"), no se aborda la planificacin sino la determinacin de los das de trabajo de cada miembro de la plantilla en una semana dada; ms an, el autor, en el trabajo citado, dice lo siguiente; "Un problema que las empresas deben afrontar cuando realizan la planificacin bajo jornada anualizada, es la programacin de los trabajos a lo largo del ao. Por lo que sabemos, no existe literatura acerca de ello. La literatura existente sobre programacin de personal ([1], [2], [15], [18]) asume demandas cclicas de mano de obra, y esto no es aplicable a situaciones en las que dicha demanda vara a lo largo del ao". En un artculo ms reciente de Grabot y Letouzey, [17], se puede leer lo siguiente: "Afrontar el problema que comporta una demanda irregular mediante la anualizacin de la jornada se ha convertido en una idea cada vez ms popular en Europa estos ltimos aos, y particularmente en el Reino Unido [19]. En Francia, la ley de las 35 horas ha aumentado el inters sobre este tema. Sin embargo, aunque la anualizacin ha despertado durante muchos aos el inters del sector empresarial, (ver, por ejemplo [5], [14], [23], [24] y [25]), es sorprendente la ausencia de artculos sobre este tema en la literatura sobre programacin, con la excepcin de los recientes estudios de Hung sobre el tema ([20], [21]). Aunque estos estudios incluyen la demanda estacional, no tienen en cuenta la polivalencia de los trabajadores ni las restricciones fijadas por la legislacin francesa.

Finalmente, en [6], Corominas y Pastor proponen un mtodo para la planificacin del tiempo de trabajo, la programacin de los horarios y la asignacin de tareas, en centros de trabajo con jornada anualizada; en [7], [8] y [9] se detallan las fases del mtodo, formulndose diversos modelos y algoritmos para tratarlos. Otras aportaciones de Corominas y Pastor, principalmente con comunicaciones a congresos, pueden verse en [10], [11], [12] y [13]. Por otro lado, las reglas, restricciones y modalidades de flexibilidad o anualizacin propias de cada legislacin o convenio generan distintos problemas y/o objetivos, que requieren distintas vas de resolucin. Esto hace necesaria una clasificacin y definicin precisa de los problemas que la anualizacin plantea. En el siguiente apartado se encuentran algunos de los aspectos que pueden influir sobre las caractersticas de dichos problemas o bases para la clasificacin. 2. Clasificacin De lo dicho anteriormente, se deduce que una primera clasificacin de los problemas surge de la naturaleza del producto o productos. Concretamente, el producto puede ser almacenable, como ocurre usualmente en la industria, o no, como ocurre en el sector servicios. En el primer caso, adems, deber diferenciarse el caso en el que el producto o productos son no perecederos de aqul en el que stos pueden almacenarse nicamente durante cierto tiempo (por ejemplo, yogures). La naturaleza del proceso productivo, especialmente en lo que respecta a la forma en que el personal interviene en el mismo, deber tenerse tambin en cuenta para la definicin del problema. En algunos casos (generalmente en la industria) para que el proceso tenga lugar se requiere la presencia simultnea de todos los miembros del equipo, lo que implica que todos deben cumplir los mismos horarios; en estos casos, la capacidad productiva a lo largo del tiempo de presencia del equipo se mantiene constante. En otros (en muchos servicios), el proceso productivo requiere slo la intervencin directa de una persona (supuesta una cierta infraestructura, que puede incluir personal) y, por consiguiente, puede haber un nmero variable, a lo largo del tiempo, de trabajadores presentes, con una capacidad de produccin esencialmente proporcional a dicho nmero (es lo que ocurre, por ejemplo, en un establecimiento de venta al detalle); en estos casos el nmero de horas de presencia en un perodo (una semana, por ejemplo) puede ser distinto para unos u otros trabajadores e incluso, para un mismo total de horas semanales, tambin pueden ser distintos los horarios de presencia de los diferentes operarios. Otro aspecto importante a tener presente es el hecho de que se considere o no la contratacin de personal temporal. Aunque las disposiciones legales lo permitan puede no ser aconsejable por razones ligadas a la calidad del producto o a la dificultad de manejar determinados

equipos, etc. Como argumenta Oke [26], los trabajadores temporales suelen tener una relacin dbil con la organizacin, con lo que su posible falta de motivacin y de identificacin con los valores de la empresa puede desembocar en unos niveles bajos de productividad y calidad. La polivalencia del personal es otro factor a tener en cuenta. En un centro de servicios puede haber varios tipos de tareas o trabajos y puede darse el caso de que exista una correspondencia biunvoca entre tipos de tareas o trabajo y categoras de personal; tambin puede suceder que los tipos de trabajos y las categoras estn jerarquizados, es decir, que un trabajador sea capaz de realizar las tareas propias de su categora y tambin las correspondientes a las categoras inferiores o a algunas de ellas; o, finalmente, que se pueda definir una matriz categoras/tipos de tarea que indique qu tipos de tarea puede realizar un trabajador de una categora dada, sin que esta matriz tenga ninguna estructura especial. Por supuesto, en los casos de polivalencia puede haber prioridades asociadas, para cada categora de trabajador, a los tipos de tarea que es capaz de llevar a cabo. Tambin es importante conocer las regulaciones sobre las horas extraordinarias, que se pueden referir al nmero mximo admisible por trabajador y ao (por ejemplo, en Espaa, el Estatuto de los Trabajadores fija un mximo de 80 horas extraordinarias al ao), a la propia definicin de qu horas tienen el carcter de extraordinarias (por ejemplo: las que exceden de 9 horas en una jornada diaria o las que exceden de 1650 en un ao) y a su retribucin (sta puede diferenciarse en ms de un bloque; por ejemplo, hasta un cierto nmero de horas extras puede pagarse una cantidad y a partir de ese valor, y hasta llegar al mximo, otra cantidad diferente). Adems, la retribucin de las horas extraordinarias puede ser monetaria o puede compensarse con perodos de descanso (por ejemplo, por cada hora extraordinaria trabajada, una hora y media de descanso). Por otro lado, cada problema quedar tambin definido por las restricciones que ha de respetar una solucin (o las que es deseable que respete) y que pueden derivarse de una disposicin legal, de un acuerdo entre la empresa y los trabajadores o de los requerimientos del sistema productivo en relacin con las previsiones de la demanda. Algunas de stas se citan a continuacin: Satisfaccin de unos requerimientos mnimos, medidos en horas de presencia semanales (por ejemplo, para una semana con una demanda de 200 horas de cierto tipo de trabajo, puede haberse de satisfacer un mnimo de 100 horas). Nmero de horas semanales comprendido entre una cota inferior, definida habitualmente

en el convenio o pacto de empresa y otra superior, que debe, en todo caso, respetar la legislacin, pudindose fijar en el convenio una cota superior menor. Para evitar un excesivo desgaste de los trabajadores en los perodos en los que existe un pico en la demanda, es frecuente que se fije una cota superior de la media de horas trabajadas en un cierto nmero de semanas consecutivas, o una cota superior del nmero de semanas consecutivas con una media de horas trabajadas superior a un cierto valor. Podra tambin fijarse un nmero de semanas con un cierto nmero de horas (o con un nmero de horas comprendido en un intervalo dado) igual a un valor dado o comprendido en un intervalo dado, etc. Las distintas modalidades de flexibilidad, reglas y restricciones que aparecen en la legislacin, los convenios y los pactos, dan lugar a distintos tipos de problemas, por lo que debe tenerse en cuenta este elemento al realizar la clasificacin. En [8] se trata el problema de empresas francesas en las que, esencialmente, se permite una distribucin irregular de la jornada respetando el lmite anual de horas y otras restricciones asociadas al nmero mnimo y mximo de horas semanales de trabajo, al nmero de semanas de descanso que deben seguir a un bloque de semanas de 46 horas, etc. En Espaa, los artculos 34.1 y 34.2 del Estatuto de los Trabajadores dejan libertad para que cada empresa pacte una distribucin irregular de la jornada a lo largo del ao, respetando la duracin mxima de la jornada ordinaria, que es de 40 horas semanales de trabajo efectivo de promedio en cmputo anual y los perodos mnimos de descanso diario y semanal previstos en la ley [16]. Aunque la mayora de los convenios colectivos se refieren a los artculos 34.1 y 34.2 del Estatuto de los Trabajadores en sus apartados de jornada de trabajo, algunos de ellos contemplan la flexibilidad de la jornada laboral y proponen reglas especficas, con lo que surgen nuevos tipos de problema. A continuacin se citan dos de ellos a modo de ejemplo. El convenio colectivo de la industria qumica [3] permite 100 horas flexibles de aplicacin en los das laborables y que forman parte del cmputo anual de la jornada. Como compensacin de las horas que se realicen por encima de las ocho horas ordinarias, se fija una hora de descanso por cada hora de trabajo flexible que se realice hasta la 9 hora, incluida, de trabajo diario, y una hora y media de descanso a partir de la 10 hora, incluida. Otro ejemplo lo encontramos en el convenio de la industria textil [4]. ste permite al empresario, durante 13 semanas (continuas o discontinuas), determinar una jornada superior o inferior a 40 horas semanales. Finalmente, tenemos el caso de una empresa francesa en la que sus trabajadores deben realizar, al ao, 10 semanas con una jornada de 28 horas y 15 minutos, 8 semanas con una jornada de 45 horas y 28 semanas con una jornada de 35 horas y 45 minutos. Pueden tambin encontrarse casos en los que el nmero de horas anual se reparta en dos bloques. Uno a realizar en turnos estables y otro, correspondiente a una bolsa de horas flexible, cuyo objetivo es cubrir las bajas laborales, el absentismo, los posibles problemas y

los picos en la demanda no previstos. Para los picos prolongados, se establece que la empresa deber subcontratar personal temporal [22]. Finalmente, cada problema tendr su criterio o criterios de evaluacin de las soluciones. Por supuesto uno de estos criterios (que habitualmente ser el ms importante) es el coste, que puede tener distintos componentes: posesin de stock, horas extraordinarias, personal temporal, ventas perdidas por insuficiencia de la capacidad productiva, etc. Pero puede haber otros, tales como la regularidad de los horarios a lo largo del ao, la adecuacin (de acuerdo con la categora de los trabajadores) de los tipos de tareas asignadas o las preferencias de los trabajadores por unos u otros horarios, la distribucin equitativa del tiempo de trabajo, de manera que se eliminen los agravios comparativos; en definitiva, criterios vinculados a la satisfaccin de los trabajadores en su actividad laboral y en su vida social y familiar. Los criterios pueden estar jerarquizados o pueden existir relaciones de intercambio entre ellos. Por ejemplo, en [7] se expone un caso que consiste en resolver el problema minimizando los costes de horas extras y subcontratacin y, a continuacin, obtener, para cada trabajador, una nueva planificacin con unas jornadas de trabajo lo ms regulares posibles a lo largo del ao (minimizando las discrepancias respecto a la media) y de modo que no se superen los costes obtenidos en la primera. 3. Conclusiones La anualizacin de la jornada laboral permite a las empresas adaptarse a las variaciones en la cantidad y composicin de la demanda, a la vez que abre nuevas posibilidades de gestin de la jornada. Esto genera nuevos problemas, distintos segn la naturaleza del producto o productos, el tipo de proceso productivo, la posibilidad de contratar mano de obra temporal, el grado de polivalencia del personal, la regulacin de las horas extraordinarias, las condiciones que debe respetar la jornada laboral, el grado de flexibilidad permitido y los criterios de evaluacin de las soluciones. La clasificacin de los problemas que pueden darse en la planificacin del tiempo de trabajo con jornada anualizada es importante porque permitir disear instrumentos de resolucin similares para problemas de un mismo grupo, con lo que se sistematizar y facilitar la resolucin de los distintos problemas.
http://io.us.es/cio2001/Cio-2001/cd/Art%C3%ADculos/UPC/UPC-7.pdf 2.2 Evaluacin del costo beneficio.

Debern aplicar la metodologa para la evaluacin costo-beneficio de la regulacin todos los entes y rganos de la Administracin Pblica. Dicha metodologa, estarn obligados a completarla cuando se establecen nuevas regulaciones o se reforman las existentes que establezcan trmites, requisitos y procedimientos, sobre inscripciones, registros u autorizaciones.
La metodologa se compone de dos tipos de formularios con sus correspondientes guas de llenado. El Formulario de Evaluacin Costo-Beneficio (formulario uno) se debe completar para los casos en que las propuestas de regulacin establezcan nuevos trmites, requisitos y procedimientos sobre inscripciones, registros o autorizaciones, o modifiquen o eliminen trmites existentes. En este ltimo caso, cuando se eliminen trmites, se deber completar este formulario slo si en adicin a tal eliminacin se modifican o se crean nuevos trmites, requisitos y procedimientos sobre inscripciones, registros o autorizaciones. En caso contrario, deber proceder a llenar el Formulario Simplificado de Evaluacin Costo-Beneficio (formulario dos) debe completarse para el caso en que la propuesta de regulacin sea una reforma a un trmite existente, en la cual nicamente: se eliminan documentos y requisitos innecesarios, se establezcan plazos definidos, se reduzcan los plazos de resolucin, o se disminuyan los procedimientos. Para realizar este anlisis deber completarse el Formulario de Evaluacin Costo-Beneficio (formulario 1) o el Formulario Simplificado de Evaluacin Costo-Beneficio (formulario 2), segn sea el caso, siguiendo las guas de llenado correspondientes. Lo anterior, puede obtenerlo en las siguientes opciones: Directriz

Decreto Formularios Guas de llenado

2.3 Estudio de viabilidad.

A. Concepto y Funciones Plan de empresa, memoria del proyecto empresarial, estudio de viabilidad o "business plan", no son ms que las diferentes formas de denominar o referirse al documento escrito en el que se recoge toda la informacin relevante referida a una empresa en proceso de creacin. En l se sintetiza y refleja toda la concepcin del negocio, todas las informaciones y reflexiones realizadas por los emprendedores durante el proceso de estudio del proyecto empresarial.

Puede ser considerado como un instrumento al servicio del emprendedor o grupo de emprendedores, un apoyo para la creacin de su empresa, puesto que su realizacin requiere un esfuerzo vlido por s mismo, al servir de gua de actuacin en las diferentes etapas a seguir en el proceso de creacin hasta la puesta en marcha de la actividad empresarial, permitiendo el conocimiento de las condiciones que intervendrn en el futuro.

Es muy importante que en su elaboracin participen todos los socios o promotores, de forma que todos ellos se impliquen plenamente en los objetivos que se establezcan y en la manera de conseguirlos.

Decdete a actuar ... TU PUEDES SER UN LIDER

cmo actan los lderes? cmo ganar carisma?

As pues, el plan de empresa cumple tres funciones bsicas:

1. Comprobar la coherencia interna del proyecto. 2. Permite cohesionar al grupo humano durante su elaboracin (se prueba el compromiso de trabajo, de dedicacin al proyecto por parte de cada promotor). 3. Al contener todos los datos relevantes, es la tarjeta de presentacin idnea para ir a buscar recursos, clientes, colaboradores, etc.
Su estructura y orientacin depender de cul sea el objetivo de ese plan. Incluso dentro de un mismo tipo de plan de empresa, dependiendo del proyecto, se dar ms importancia a unos puntos que a otros. Tambin es conveniente precisar que el plan de empresa no debe considerarse como un esfuerzo puntual sino como una herramienta al servicio del emprendedor que se debe ir actualizando de manera constante y que, cuando sea preciso, nos permitir obtener una fotografa de cul es la situacin en un momento determinado. Hay que tener presente que incluso las grandes empresas (que quieren seguir creciendo y seguir siendo rentables) invierten cada mes muchos recursos en la elaboracin de informes o "cuadros de mando" en los que se detalla la evolucin de la empresa en los ltimos meses as como las previsiones de evolucin futura a corto, medio y largo plazo y que esos informes, que no son ms que un plan de empresa para cuando sta ya est creada, son considerados como una herramienta de ayuda imprescindible para la toma de decisiones por parte de los altos directivos.

http://www.tramites.go.cr/Costo_Beneficio.htm

1. Breve resumen e historia del proyecto: Se trata de explicar de forma breve (los detalles deben reservarse para los siguientes apartados) la actividad que se pretende poner en marcha as como las caractersticas del producto o servicio que ofreceremos, las necesidades que satisfar, las ventajas competitivas en las que nos apoyaremos y los posibles riesgos o problemas a los que habr que hacer frente. Tambin es conveniente mostrar cul es la situacin actual del proyecto y las actividades ya realizadas u objetivos ya alcanzados.

2. Recursos humanos. El empresario promotor o grupo de promotores: Dejar constancia de quin o quines son las personas

que ponen en marcha el proyecto,

incluyendo los datos relativos a su formacin y experiencia profesional (en ocasiones es ms "fiable" un proyecto en apariencia mediocre pero con un grupo de profesionales experimentados que lo respalda que un buen proyecto puesto en marcha por inexpertos). Se ha de definir cul es el nivel de implicacin de cada promotor con la futura empresa (qu aportar cada uno tanto en trabajo como en bienes) y qu pretenden obtener de la empresa (nivel mnimo de remuneracin por su aportacin, ya sea de recursos financieros, de trabajo personal o de ambas cosas a la vez). Se ha de definir el organigrama de la empresa, la estructura de toma de decisiones y responsabilidades, descripciones de puestos de trabajo y de los circuitos administrativos (quin hablar con los clientes, quin realizar el producto, quin se encargar de la gestin administrativa y contable, quin tratar con los proveedores... y cmo se har cada una de esas tareas).

3. Area comercial y situacin del mercado: Se trata de hacer un anlisis de los posibles futuros clientes, competidores y proveedores. En cuanto a los clientes, habr que definir e identificar las caractersticas de nuestro pblico objetivo o "target", su localizacin, necesidades y gustos, poder adquisitivo, edad, sexo, etc. Una vez tengamos toda esa informacin, podremos planificar la poltica de comunicacin (publicidad) ms adecuada para informarles de nuestra oferta, la poltica de distribucin ms adecuada para hacerles llegar nuestros productos y perfilar las caractersticas del producto de manera que ste sea ms apetecible para el cliente segn sus gustos y necesidades (precio, tamao o cantidad por unidad de producto, diseo del envoltorio o envase, ... ). Por lo que se refiere a competidores, habr que prestarles una cuidadosa atencin intentando extraer de ellos toda la informacin que nos sea posible: - Quines son los lderes del mercado y en qu basan sus xitos. - Qu empresas del sector tienen dificultades y cules son las causas. - Cmo podemos ofrecer nuestros productos de forma que resulten ms atractivos que los de la competencia para un determinado segmento del mercado (ventaja competitiva). - Qu productos cumplen funciones similares a las de nuestro producto o cubren la misma necesidad (productos substitutivos). - Qu empresas ofrecen productos complementarios al nuestro y con los que, en consecuencia, podemos intentar establecer colaboraciones beneficiosas para ambos. Tambin es conveniente hacer un anlisis de posibles proveedores, contactando con diversas empresas y pidindoles presupuestos. En ocasiones, los proveedores pueden ser una importante fuente de informacin sobre las caractersticas del mercado ya que para ellos somos un futuro cliente.

Antes de arriesgar tu dinero en un negocio, realiza tus propios clculos de viabilidad empresarial - CLICK AQUI 4. 5. El proceso de produccin o la organizacin del servicio: Se ha de describir el proceso que seguir la empresa para producir sus productos, haciendo una relacin de todas las mquinas y herramientas que se necesitarn y sus caractersticas (forma de conseguirlas, precio, duracin,...). Igualmente habr que concretar qu materiales o materias primas componen el producto y en qu cantidades, el nmero de personas necesario en todo el proceso de fabricacin (su cualificacin, funciones, horario, etc.) y el plazo de produccin (tiempo que transcurre desde que se compran las materias primas hasta que el producto final est listo para ser servido al cliente). En el caso de que, en lugar de un producto, se pretenda ofrecer un servicio, se tendr que describir todo el conjunto de operaciones y circuitos organizados necesarios para una buena prestacin del servicio. Por ltimo habr que calcular cul es la capacidad mxima de productos que, dados los recursos iniciales, la empresa es capaz de ofrecer.

6.

Plan de Fechas: Este apartado exige un esfuerzo de los objetivos en subobjetivos a conseguir a corto, medio y largo plazo, as como los recursos necesarios. Es muy posible que una empresa decida servir sus productos a todo el pas pero que decida centrarse durante el primer ao en su propia ciudad (durante la puesta en marcha del negocio), para ir ampliando el mbito geogrfico durante los aos siguientes. O bien, que decida ofrecer slo uno o dos productos inicialmente para, con posterioridad, ir ampliando la gama. Un correcto plan de fechas puede hacer un xito de una empresa incluso si no se disponen
planificacin dividiendo

de excesivos recursos financieros.

7. Area econmico-financiera: El anlisis econmico y financiero del proyecto empresarial requiere unos conocimientos especficos mnimos, que de no tenerlos ningn miembro del grupo de promotores, hace aconsejable la intervencin de un asesor externo (los ayuntamientos, INEM; gobiernos autonmicos, cmaras de comercio y otros organismos suelen tener servicios de asesoramiento gratuito para la creacin de empresas). Habr que definir y concretar:

Averigua si tu proyecto de empresa es viable

Click Aqu

8. Plan de inversiones: qu inversiones son las mnimas necesarias para poner en marcha el proyecto y cules se realizarn posteriormente (publicidad de lanzamiento; estudios tcnicos previos necesarios para la puesta en marcha de la empresa; acondicionamiento del local, instalacin de telfono, fax, etc. ; maquinaria, mobiliario, equipos informticos; fianzas, seguros; ... ). 9. Plan de financiacin: de dnde se van a obtener los recursos necesarios para hacer frente a las inversiones (aportaciones de los socios, crditos bancarios, crditos subvencionados, leasing, subvenciones,... ). 10. Previsin de resultados: se trata de realizar una previsin de los beneficios que esperamos obtener en cada uno de los dos tres primeros aos. Para ello es necesario hacer una previsin de los ingresos por las ventas de productos o por la prestacin de servicios (precio por cantidad vendida) as como una previsin de gastos anuales (compra de materias primas, sueldos y salarios, alquileres, suministros de agua, gas, luz y telfono, transportes, intereses de crditos, publicidad y promociones, primas de seguros, tributos, ... ). 11. Anlisis de "punto crtico": en ocasiones resulta bastante difcil o arbitrario establecer una cifra concreta de ingresos esperados. Cuando esto ocurre, es muy til acompaar el estudio del resultado o beneficio previsto con un anlisis del punto crtico (tambin llamado punto muerto o umbral de rentabilidad) que no es ms que el clculo de la cifra mnima de ventas necesaria para que la empresa no incurra en prdidas o, dicho de otra forma, la cifra de ventas (en unidades de producto o en valor monetario) a partir de la cual la empresa empieza a tener beneficios. Previsin de tesorera: se trata de especificar las entradas y salidas de dinero a las que la empresa deber hacer frente mes a mes durante los primeros meses de puesta en marcha del negocio (teniendo en cuenta los posibles pagos y cobros aplazados, a los proveedores y clientes respectivamente, as como el plazo de produccin, que nos indicar los meses que se tardar en poder vender el producto final resultante de las materias primas compradas hoy). Es importante prestar atencin a este aspecto ya que puede ocurrir que una empresa econmicamente rentable (con ingresos superiores a los gastos) se encuentre en una situacin financieramente difcil (al no disponer de efectivo para hacer frente a sus pagos por no haber cobrado todava de los clientes). Balance previsional: en el que se refleje la evolucin del patrimonio de la empresa desde el momento inicial hasta pasados los dos o tres aos siguientes a su puesta en marcha.

12. 13. Aspectos legales: Es importante dejar constancia en el informe de cul ser la forma jurdica de la empresa (sociedad annima, cooperativa, etc.) o del tipo de relaciones laborales que se establecern con los trabajadores (segn las diferentes tipologas de contratos existentes). Pero tambin se deben resear todas aquellas restricciones legales a las que se deber someter la empresa (por ejemplo, la normativa legal que afecta a la forma y materiales en los juguetes para nios o al tipo de publicidad en productos como los medicamentos o el tabaco), as como de aquellas posibles ventajas legales que puedan existir (por ejemplo, posibles incentivos fiscales o subvenciones de las que se pueda beneficiar la empresa por

cumplir con determinados requisitos establecidos por la administracin pblica).

14. Conclusiones: En este apartado se puede incluir una valoracin global de la empresa, de su atractivo y puntos fuertes, as como de sus riesgos y problemas.

Volver al Men

C. Ejemplo de Estructura de un Plan de Empresa 1. Breve resumen de la idea de empresa e historia del proyecto 1.1 Origen de la idea del negocio y aspectos que hacen pensar que puede ser interesante y rentable 1.2 Definicin del producto o servicio que se pretende ofrecer. Aspectos diferenciales respecto de la competencia 1.3 Situacin actual del proyecto (inversiones realizadas, compromisos y derechos ya adquiridos, aspectos pendientes)

2. Empresario fundador o grupo promotor y equipo directivo 2.1 Detalle de los componentes del proyecto (formacin y experiencia) 2.2 Definicin de las reas funcionales de la empresa (organigrama) 3. Anlisis del mercado y plan de marketing 3.1 Estudio del cliente 3.1.1 Perfil de cliente (sus caractersticas en cuanto a edad, sexo, nivel econmico, costumbres, domicilio, etc.) 3.1.2 Necesidades que se pretenden satisfacer: fsicas (alimentacin, ropa, transporte,...), psicolgicas (entretenimiento u ocio, mejorar la imagen,...) o de cualquier otro tipo (educacin, ahorro de tiempo o dinero, etc.) 3.2 Definicin del producto o servicio

3.2.1 Esencia o contenido del producto 3.2.2 Presentacin e imagen del producto (volumen fsico o cantidad por unidad, envoltorio, marca, etc.) 3.3 Estudio de la competencia (nmero de competidores, puntos fuertes en los que stos basan su oferta y puntos dbiles que podramos mejorar o de los que nos podramos aprovechar) 3.4 Distribucin (cmo se pretende hacer llegar el producto hasta el consumidor final: venta directa a domicilio, por correo, en supermercados, etc.) 3.5 Publicidad y promocin (tipo de publicidad y medios en los que se realizar y frecuencia de los anuncios publicitarios, de folletos o de catlogos, etc.) 3.6 Precio (gama de precios de venta y descuentos a los distribuidores y al consumidor final, teniendo en cuenta el precio mximo que el cliente estar dispuesto a pagar y el precio mnimo en funcin de los costes de produccin)

4. Plan de produccin o de operaciones 4.1 Caractersticas del proceso de produccin o de operaciones a realizar (especificando los que sern realizados por la propia empresa y los que sern subcontratados) 4.2 Planificacin de la "secuencia de tareas" (desde que los proveedores nos sirven las materias primas o inputs hasta que el producto final est listo pare ser enviado al cliente) 4.3 Recursos requeridos 4.3.1 Locales e instalaciones (tamao mnimo, ubicacin idnea, etc.) 4.3.2 Equipos tcnicos 4.3.3 Recursos humanos (nmero de empleados, formacin y experiencia requeridas, etc.) 4.3.4 Materias primas. Proveedores (cantidades mnimas necesarias en almacn, anlisis de los diferentes proveedores, etc.) 5. Plan de fechas 5.1 Fecha prevista para la puesta en marcha del negocio 5.2 Primer ao (detalle de los objetivos a conseguir y pasos a realizar durante cada uno de los doce primeros meses de vida de la empresa) 5.3 Objetivos de la empresa a medio plazo (segundo y tercer ao) 5.4 Objetivos de la empresa a largo plazo (a partir del cuarto ao)

6. Plan econmico - financiero

6.1 Plan de inversiones (concretar el importe de las inversiones a realizar teniendo en cuenta los recursos requeridos y el plan de fechas establecido) 6.2 Plan de financiacin (detallar el origen de los recursos financieros necesarios para hacer frente a las inversiones relacionadas en el apartado anterior) 6.3 Previsin de resultados y umbral de rentabilidad (se debern establecer los beneficios esperados, es decir, los ingresos y gastos previstos tanto a corto como a medio y largo plazo) 6.4 Previsin de tesorera (clculo y planificacin del saldo de la cuenta bancaria - o de dinero disponible teniendo en cuenta los diferentes plazos de pago a los proveedores y de cobro a los clientes). 6.5 Balance previsional (en el que se reflejar la relaciones entre recursos propios y deuda, entre deuda a largo y a corto plazo, entre recursos disponibles e inmovilizados, etc.) 7. Aspectos Legales (forma jurdica de la empresa, tipo de relaciones laborales con los trabajadores, normativa que afecta en algn aspecto a la venta del producto o servicio en cuanto a su composicin, etiquetado, publicidad, etc.) 8. Conclusiones 9. Anexos (copia de aquella documentacin que se considere relevante para quien ha de valorar la futura empresa)

http://empresas.arrakis.es/acem/plan_emp.htm#op2 2.4 Planificacin de la documentacin.

DESCRIPCIN Y OBJETIVOS
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. 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. Las actividades que engloba este proceso se recogen en la siguiente figura, en la que se indican las actividades que pueden ejecutarse en paralelo y las que precisan para su realizacin resultados originados en actividades anteriores.

ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA

En esta actividad se estudia el alcance de la necesidad planteada por el cliente o usuario, o como consecuencia de la realizacin de un PSI, realizando una descripcin general de la misma. Se determinan los objetivos, se inicia el estudio de los requisitos y se identifican las unidades organizativas afectadas estableciendo su estructura. Se analizan las posibles restricciones, tanto generales como especficas, que puedan condicionar el estudio y la planificacin de las alternativas de solucin que se propongan. Si la justificacin econmica es obvia, el riesgo tcnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoracin y evaluacin de las mismas, sino que ste se orientar a la especificacin de requisitos, descripcin del nuevo sistema y planificacin. Se detalla la composicin del equipo de trabajo necesario para este proceso y su planificacin. Finalmente, con el fin de facilitar la implicacin activa de los usuarios en la definicin del sistema, se identifican sus perfiles, dejando claras sus tareas y responsabilidades.

Tarea EVS 1.1: Estudio de la Solicitud

Se realiza una descripcin general de la necesidad planteada por el usuario, y se estudian las posibles restricciones de carcter econmico, tcnico, operativo y legal que puedan afectar al sistema. Antes de iniciar el estudio de los

requisitos del sistema se establecen los objetivos generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente. Si el sistema objeto de estudio se encuentra en el mbito de un Plan de Sistemas de Informacin vigente, se debe de tomar como referencia el catlogo de requisitos y la arquitectura de informacin resultante del mismo, como informacin adicional para la descripcin general del sistema y determinacin de los requisitos iniciales.

Productos
De entrada Catlogo de Requisitos del PSI (PSI 9.2) Arquitectura de Informacin (PSI 9.2) Solicitud (externo) De salida Descripcin General del Sistema Catlogo de Objetivos del EVS Catlogo de Requisitos

Prcticas

Catalogacin Sesiones de trabajo

Participantes

Comit de Direccin Jefe de Proyecto Analistas

Tarea EVS 1.2: Identificacin del Alcance del Sistema

Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronizacin con otros proyectos, que puedan interferir en la planificacin y futura puesta a punto del sistema objeto del estudio. Esta informacin se recoge en el catlogo de requisitos. Si el sistema pertenece al mbito de un Plan de Sistemas de Informacin, se debe tener en cuenta la arquitectura de informacin propuesta para analizar el alcance del sistema e identificar los sistemas de informacin que quedan fuera del mbito del estudio. Adems, se estudia el plan de proyectos, para determinar las posibles dependencias con otros proyectos. Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, as como su estructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a quines afecta directamente y quines pueden influir en el xito o fracaso del mismo.

Productos
De entrada Plan de Proyectos (PSI 9.2) Arquitectura de Informacin (PSI 9.2) Descripcin General del Sistema (EVS 1.1) Catlogo de Objetivos del EVS (EVS 1.1) Catlogo de Requisitos (EVS 1.1) De salida Descripcin General del Sistema: o Contexto del Sistema o Estructura Organizativa Catlogo de Requisitos: o Requisitos Relativos a Restricciones o Dependencias con Otros Proyectos Catlogo de Usuarios

Tcnicas
Diagrama de Flujo de Datos Diagrama de Descomposicin Funcional

Prcticas

Catalogacin Sesiones de trabajo

Participantes

Comit de Direccin Jefe de Proyecto Analistas

Tarea EVS 1.3: Especificacin del Alcance del EVS

En funcin del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan las actividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situacin actual y, en el caso de considerarlo necesario, con qu objetivo. Si el sistema pertenece al mbito de un Plan de Sistemas de Informacin, los criterios que pueden orientar sobre la necesidad de llevar a cabo el estudio de la situacin actual dependen de la arquitectura de informacin propuesta, en cuanto a la identificacin de los sistemas de informacin actuales, implicados en el mbito de este estudio, que se haya decidido conservar. Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la realizacin del Estudio de Viabilidad del Sistema, determinando previamente sus perfiles y responsabilidades. Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el Estudio de Viabilidad, solicitando su aceptacin y esperado su confirmacin.

Productos
De entrada Arquitectura de Informacin (PSI 9.2) Catlogo de Objetivos del EVS (EVS 1.1) Descripcin General del Sistema (EVS 1.2) Catlogo de Usuarios (EVS 1.2) De salida Catlogo de Objetivos del EVS: Objetivos del Estudio de la Situacin Actual Catlogo de Usuarios Plan de Trabajo
o

Prcticas

Catalogacin Sesiones de trabajo

Participantes

Comit de Direccin Jefe de Proyecto Analistas

ACTIVIDAD EVS 2: ESTUDIO DE LA SITUACIN ACTUAL

La situacin actual es el estado en el que se encuentran los sistemas de informacin existentes en el momento en el que se inicia su estudio. Teniendo en cuenta el objetivo del estudio de la situacin actual, se realiza una valoracin de la informacin

existente acerca de los sistemas de informacin afectados. En funcin de dicha valoracin, se especifica el nivel de detalle con que se debe llevar a cabo el estudio. Si es necesario, se constituye un equipo de trabajo especfico para su realizacin y se identifican los usuarios participantes en el mismo. Si se decide documentar la situacin actual, normalmente es conveniente dividir el sistema actual en subsistemas. Si es posible se describir cada uno de los subsistemas, valorando qu informacin puede ser relevante para la descripcin. Como resultado de esta actividad se genera un diagnstico, estimando la eficiencia de los sistemas de informacin existentes e identificando los posibles problemas y las mejoras.

Tarea EVS 2.1: Valoracin del Estudio de la Situacin Actual

En funcin de los objetivos establecidos para el estudio de la situacin actual, y considerando el contexto del sistema especificado en la descripcin general del mismo, se identifican los sistemas de informacin existentes que es necesario analizar con el fin de determinar el alcance del sistema actual. Asimismo, se decide el nivel de detalle con el que se va a llevar a cabo el estudio de cada uno de los sistemas de informacin implicados. En el caso de haber realizado un Plan de Sistemas de Informacin que afecte a dicho sistema, se toma como punto de partida para este anlisis la arquitectura de informacin propuesta. Para poder abordar el estudio, se realiza previamente una valoracin de la informacin existente acerca de los sistemas de informacin afectados por el EVS. Se debe decidir si se realizan o no los modelos lgicos del sistema actual o si se describe el modelo fsico, en funcin de los siguientes criterios:

 Si existen los modelos lgicos, y son fiables, se utilizan en la tarea Descripcin de los Sistemas de Informacin Existentes (EVS 2.3) Si no existen dichos modelos, o no son fiables, se considera el tiempo de vida estimado para el sistema de informacin en funcin de la antigedad, la obsolescencia de la tecnologa o la falta de adecuacin funcional para determinar s se obtienen los modelos lgicos y fsicos del sistema actual o por el contrario no se elabora ningn modelo. La informacin relativa a los sistemas de informacin que se decida analizar, se obtiene mediante sesiones de trabajo con los Directores de Usuarios y el apoyo de los profesionales de Sistemas y Tecnologas de la Informacin y Comunicaciones (STIC) que se considere necesario.

Productos
De entrada Informacin Existente del Sistema Actual (externo) Arquitectura de Informacin (PSI 9.2) Catlogo de Objetivos del EVS (EVS1.3) Descripcin General del Sistema (EVS 1.2) De salida Descripcin de la Situacin Actual: o Contexto del Sistema Actual o Descripcin de los Sistemas de Informacin Actuales

Tcnicas
Diagrama de Flujo de Datos

Prcticas

Diagrama de Representacin Sesiones de Trabajo

Participantes

Jefe de Proyecto Analistas Directores de Usuarios

Tarea EVS 2.2: Identificacin de los Usuarios Participantes en el Estudio de la Situacin Actual
En funcin del nivel de detalle establecido para el estudio de la situacin actual, se identifican los usuarios participantes de cada una de las unidades organizativas afectadas por dicho estudio. Se informa a los usuarios identificados como implicados en el Estudio de la Situacin Actual, se solicita su aceptacin y se espera su confirmacin.

Productos
De entrada Descripcin General del Sistema (EVS 1.2) Catlogo de Usuarios (EVS 1.3) Descripcin de la Situacin Actual (EVS 2.1) De salida Catlogo de Usuarios

Prcticas

Catalogacin Sesiones de Trabajo

Participantes

Jefe de Proyecto Directores de Usuarios

Tarea EVS 2.3: Descripcin de los Sistemas de Informacin Existentes

En esta tarea se describen los sistemas de informacin existentes afectados, segn el alcance y nivel de detalle establecido en la tarea Valoracin del Estudio de la Situacin Actual (EVS 2.1), mediante sesiones de trabajo con los usuarios designados para este estudio. Si se ha decidido describir los sistemas a nivel lgico, y si existe un conocimiento suficiente de los sistemas de informacin a especificar, puede hacerse directamente, aplicando las tcnicas de modelizacin y siguiendo un mtodo descendente. Si no se dispone del conocimiento suficiente, se construyen los modelos a partir de la descripcin del modelo fsico, es decir, de forma ascendente. Si se tiene que describir el modelo fsico, se puede hacer mediante un Diagrama de Representacin en el que se recojan todos los componentes fsicos y sus referencias cruzadas. Otra opcin es describir el modelo fsico de forma ms detallada, para lo que es necesaria la utilizacin de herramientas de tipo scanner. Es conveniente indicar la localizacin geogrfica y fsica actual de los mdulos y datos de los sistemas de informacin afectados, evaluando al mismo tiempo la redundancia en las distintas unidades organizativas.

Productos
De entrada Descripcin de la Situacin Actual (EVS 2.1) Catlogo de Usuarios (EVS 2.2) De salida Descripcin de la Situacin Actual: o Descripcin Lgica del Sistema Actual o Modelo Fsico del Sistema Actual (opcional) o Matriz de Localizacin Geogrfica y Fsica de Mdulos y Datos, incluidas las redundancias

Tcnicas
Diagrama de Flujo de Datos Modelo Entidad/ Relacin extendido Diagrama de Clases Diagrama de Interaccin de Objetos Matricial

Prcticas
Diagrama de Representacin Sesiones de Trabajo

Participantes

Analistas Usuarios Expertos Equipo de Soporte Tcnico

Tarea EVS 2.4: Realizacin del Diagnstico de la Situacin Actual

Con el fin de elaborar el diagnstico de la situacin actual se analiza la informacin de los sistemas de informacin existentes, obtenida en la tarea anterior y se identifican problemas, deficiencias y mejoras. Estas ltimas deben tenerse en cuenta en la definicin de los requisitos. 8 Estudio de Viabilidad del Sistema Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3 En el caso de haber realizado un Plan de Sistemas de Informacin, se considera la valoracin realizada sobre los sistemas de informacin actuales que pertenecen al mbito de este estudio.

Si se ha tomado la decisin de no describir la situacin actual, se realiza un diagnstico global justificando esta decisin.

Productos
De entrada Descripcin de la Situacin Actual (EVS 2.3) Catlogo de Objetivos del EVS (EVS 1.3) Valoracin de la Situacin actual (PSI 5.3) De salida Descripcin de la Situacin Actual: o Diagnstico de Situacin Actual

Participantes
Analistas Responsable de Mantenimiento

ACTIVIDAD EVS 3: DEFINICIN DE REQUISITOS DEL SISTEMA

Esta actividad incluye la determinacin de los requisitos generales, mediante una serie de sesiones de trabajo con los usuarios participantes, que hay que planificar y realizar. Una vez finalizadas, se analiza la informacin obtenida definiendo los requisitos y sus prioridades, que se aaden al catlogo de requisitos que servir para el estudio y valoracin de las distintas alternativas de solucin que se propongan.

Tarea EVS 3.1: Identificacin de las Directrices Tcnicas y de Gestin

La realizacin de esta tarea permite considerar los trminos de referencia para el sistema en estudio desde el punto de vista de directrices tanto tcnicas como de gestin. Si el sistema en estudio pertenece al mbito de un Plan de Sistemas de Informacin vigente, ste proporciona un marco de referencia a considerar en esta tarea. Con este fin, se recoge informacin sobre los estndares y procedimientos que deben considerarse al proponer una solucin, relativos a: Polticas tcnicas: Gestin de Proyectos (seguimiento, revisin y aprobacin final). Desarrollo de Sistemas (existencia de normativas, metodologas y tcnicas de programacin). Arquitectura de Sistemas (centralizada, distribuida). Poltica de Seguridad (control de accesos, integridad de datos, disponibilidad de aplicaciones). Directrices de Planificacin.

 Directrices de Gestin de Cambios. Directrices de Gestin de Calidad.

Productos

De entrada Catlogo de Normas del PSI (PSI 3.2) Estudio de Viabilidad del Sistema 9 Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3 Recopilacin de Directrices Tcnicas y de Gestin (externo) De salida Catlogo de Normas

Prcticas

Catalogacin

Participantes
Jefe de Proyecto Analistas Usuarios Expertos

Tarea EVS 3.2: Identificacin de Requisitos

Para la obtencin de las necesidades que ha de cubrir el sistema en estudio, se debe decidir qu tipo de sesiones de trabajo se realizarn y con qu frecuencia tendrn lugar, en funcin de la disponibilidad de los usuarios participantes. Si se ha realizado el Estudio de la Situacin Actual (EVS 2), puede ser conveniente seleccionar la informacin de los sistemas de informacin existentes que resulte de inters para el desarrollo de dichas sesiones de trabajo. Una vez establecidos los puntos anteriores, se planifican las sesiones de trabajo con los usuarios participantes identificados al estudiar el alcance del Estudio de Viabilidad del Sistema (EVS 1.3), y se realizan de acuerdo al plan previsto. La informacin obtenida depende del tipo de sesin de trabajo seleccionado.

Productos
De entrada Descripcin General del Sistema (EVS 1.2) Catlogo de Requisitos (EVS 1.2) Equipo de Trabajo del EVS (EVS 1.3) Catlogo de Usuarios (EVS 2.2/1.3) Descripcin de la Situacin Actual (EVS 2.4) De salida Identificacin de Requisitos

Prcticas

Sesiones de Trabajo

Participantes

Jefe de Proyecto Analistas Usuarios Expertos

Tarea EVS 3.3: Catalogacin de Requisitos

Se analiza la informacin obtenida en las sesiones de trabajo para la Identificacin de Requisitos, definiendo y catalogando los requisitos (funcionales y no funcionales) que debe satisfacer el sistema, indicando sus prioridades. Se incluirn tambin requisitos relativos a distribucin geogrfica y entorno tecnolgico.

Productos
De entrada Identificacin de Requisitos (EVS 3.2) Catlogo de Requisitos (EVS 1.2)

De salida Catlogo de Requisitos

Prcticas

Catalogacin

Participantes
Jefe de Proyecto Analistas Usuarios Expertos

ACTIVIDAD EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIN

Este estudio se centra en proponer diversas alternativas que respondan satisfactoriamente a los requisitos planteados, considerando tambin los resultados obtenidos en el Estudio de la Situacin Actual (EVS 2), en el caso de que se haya realizado. Teniendo en cuenta el mbito y funcionalidad que debe cubrir el sistema, puede ser conveniente realizar, previamente a la definicin de cada alternativa, una descomposicin del sistema en subsistemas. En la descripcin de las distintas alternativas de solucin propuestas, se debe especificar si alguna de ellas est basada, total o parcialmente, en un producto existente en el mercado. Si la alternativa incluye un desarrollo a medida, se debe incorporar en la descripcin de la misma un modelo abstracto de datos y un modelo de procesos, y en orientacin a objetos, un modelo de negocio y un modelo de dominio.

Tarea EVS 4.1: Preseleccin de Alternativas de Solucin

Una vez definidos los requisitos a cubrir por el sistema, se estudian las diferentes opciones que hay para configurar la solucin. Entre ellas, hay que considerar la adquisicin de productos software estndar del mercado, desarrollos a medida o soluciones mixtas. Dependiendo del alcance del sistema y las posibles opciones, puede ser conveniente realizar inicialmente una descomposicin del sistema en subsistemas. Se establecen las posibles alternativas sobre las que se va a centrar el estudio de la solucin, combinando las opciones que se consideren ms adecuadas.

Productos
De entrada Informacin de Productos Software del Mercado (externo) Descripcin General del Sistema (EVS 1.2) Descripcin de la Situacin Actual (EVS 2.4) Catlogo de Requisitos (EVS 3.3) De salida Descomposicin Inicial del Sistema en Subsistemas (opcional) Alternativas de Solucin a Estudiar

Prcticas
Diagrama de Representacin

Participantes

Jefe de Proyecto Analistas Tcnicos de Sistemas

Tarea EVS 4.2: Descripcin de las Alternativas de Solucin

Para cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos a los que se da respuesta. Se deben considerar tambin aspectos relativos a la cobertura geogrfica (mbito y limitaciones) de procesos y datos, teniendo en cuenta a su vez la gestin de comunicaciones y control de red. En la definicin de cada alternativa, se propone una estrategia de implantacin teniendo en cuenta tanto la cobertura global del sistema como la cobertura geogrfica. Si la alternativa incluye desarrollo se describe el modelo abstracto de datos y el modelo de procesos, y en el caso de Orientacin a Objetos, el modelo de negocio y, opcionalmente, el modelo de dominio. Se propone el entorno tecnolgico que se considera ms apropiado para la parte del sistema basada en desarrollo y se describen los procesos manuales. Si la alternativa incluye una solucin basada en producto se analiza su evolucin prevista, adaptabilidad y portabilidad, as como los costes ocasionados por licencias, y los estndares del producto. Igualmente se valora y determina su entorno tecnolgico.

Productos
De entrada Descripcin General del Sistema (EVS 1.2) Descripcin de la Situacin Actual (EVS 2.4) Catlogo de Requisitos (EVS 3.3) Descomposicin Inicial del Sistema en Subsistemas (EVS 4.1) (opcional) Alternativas de Solucin a Estudiar (EVS 4.1) De salida Catlogo de Requisitos (actualizado) Alternativas de Solucin a Estudiar: o Catlogo de Requisitos (cobertura) o Modelo de Descomposicin en Subsistemas o Matriz Procesos / Localizacin Geogrfica o Matriz Datos / Localizacin Geogrfica o Entorno Tecnolgico y Comunicaciones o Estrategia de Implantacin Global del Sistema o Descripcin de Procesos Manuales Si la alternativa incluye desarrollo: o Modelo Abstracto de Datos / Modelo de Procesos o Modelo de Negocio / Modelo de Dominio (en caso de Orientacin a Objetos) Si la alternativa incluye un producto software estndar de mercado: o Descripcin del Producto o Evolucin del Producto o Costes Ocasionados por Producto o Estndares del Producto o Descripcin de Adaptacin (si es necesaria)

Tcnicas
Matricial Diagrama de Flujo de Datos

 Modelo Entidad/ Relacin extendido Diagrama de Clases Casos de Uso

Prcticas

Catalogacin Diagrama de Representacin

Participantes

Jefe de Proyecto Analistas Usuarios Expertos Tcnicos de Sistemas Responsable de Seguridad Especialistas en Comunicaciones

ACTIVIDAD EVS 5: VALORACIN DE LAS ALTERNATIVAS

Una vez descritas las alternativas se realiza una valoracin de las mismas, considerando el impacto en la organizacin, tanto desde el punto de vista tecnolgico y organizativo como de operacin, y los posibles beneficios que se esperan contrastados con los costes asociados. Se realiza tambin un anlisis de los riesgos, decidiendo cmo enfocar el plan de accin para minimizar los mismos y cuantificando los recursos y plazos precisos para planificar cada alternativa.

Tarea EVS 5.1: Estudio de la Inversin

Para cada alternativa de solucin propuesta, se valora el impacto en la organizacin y se establece su viabilidad econmica. Para ello, se realiza un anlisis coste/beneficio que determina los costes del sistema y los pondera con los beneficios tangibles, cuantificables directamente, y con los beneficios intangibles, buscando el modo de cuantificarlos.

Productos
De entrada Alternativas de Solucin a Estudiar (EVS 4.2) De salida Valoracin de Alternativas:

Impacto en la Organizacin de Alternativas o Coste / beneficio de Alternativas

Tcnicas
Anlisis Coste / Beneficio

Participantes

Jefe de Proyecto Analistas

Tarea EVS 5.2: Estudio de los Riesgos

Para cada alternativa se seleccionan los factores de situacin que habr que considerar, relativos tanto a la incertidumbre como a la complejidad del sistema. Se identifican y valoran los riesgos asociados y se determinan las medidas a tomar para minimizarlos.

Productos
De entrada Alternativas de Solucin a Estudiar (EVS 4.2) Valoracin de Alternativas (EVS 5.1) De salida Valoracin de Alternativas: o Valoracin de Riesgos

Prcticas
Impacto en la Organizacin

Participantes

Jefe de Proyecto Analistas

Tarea EVS 5.3: Planificacin de Alternativas

En funcin del anlisis de riesgos realizado en la tarea anterior, y para cada una de las alternativas existentes: Se determina el enfoque ms adecuado para llevar a buen fin la solucin propuesta en cada alternativa. Se realiza una planificacin, teniendo en cuenta los puntos de sincronismo con otros proyectos en desarrollo o que est previsto desarrollar, segn se ha recogido en el catlogo de requisitos. De esta manera se garantiza el cumplimiento del plan de trabajo en los restantes procesos del ciclo de vida.

Productos
De entrada Catlogo de Requisitos (EVS 4.2) Alternativas de Solucin a Estudiar (EVS 4.2) Valoracin de Alternativas (EVS 5.2) De salida Plan de Trabajo de Cada Alternativa: o Enfoque del Plan de Trabajo de Cada Alternativa o Planificacin de Cada Alternativa

Tcnicas
Planificacin

Participantes
Jefe de Proyecto Analistas

ACTIVIDAD EVS 6: SELECCIN DE LA SOLUCIN

Antes de finalizar el Estudio de Viabilidad del Sistema, se convoca al Comit de Direccin para la presentacin de las distintas alternativas de solucin, resultantes de la actividad anterior. En dicha presentacin, se debaten las ventajas de cada una de ellas, incorporando las modificaciones que se consideren oportunas, con el fin de seleccionar la ms adecuada. Finalmente, se aprueba la solucin o se determina su inviabilidad.

Tarea EVS 6.1: Convocatoria de la Presentacin

Se efecta la convocatoria de la presentacin de las distintas alternativas propuestas, adjuntando los productos de la actividad anterior con el fin de que el Comit de Direccin pueda estudiar previamente su contenido. Se espera confirmacin por parte del Comit de Direccin de las alternativas a presentar.

Productos
De entrada Catlogo de Usuarios (EVS 2.2/1.3) Alternativas de Solucin a Estudiar (EVS 4.2) Valoracin de Alternativas (EVS 5.2) Plan de Trabajo de Cada Alternativa (EVS 5.3) De salida Plan de Presentacin de Alternativas

Prcticas

Presentacin

Participantes
Jefe de Proyecto

Tarea EVS 6.2: Evaluacin de las Alternativas y Seleccin

Una vez recibida la confirmacin de qu alternativas van a ser presentadas para su valoracin, se efecta su presentacin al Comit de Direccin, debatiendo sobre las ventajas e inconvenientes de cada una de ellas y realizando las modificaciones que sugiera dicho Comit, hasta la seleccin de la solucin final.

Productos
De entrada Descripcin General del Sistema (Contexto del Sistema) (EVS 1.2) Catlogo de Requisitos (EVS 4.2) Alternativas de Solucin a Estudiar (EVS 4.2) Valoracin de Alternativas (EVS 5.2) Plan de Trabajo de Cada Alternativa (EVS 5.3) Plan de Presentacin de Alternativas (EVS 6.1) De salida Plan de Presentacin de Alternativas Catlogo de Requisitos (Actualizado en Funcin de la Cobertura de la Solucin)

 Solucin Propuesta: o Descripcin de la Solucin Modelo de Descomposicin en Subsistemas Matriz Procesos / Localizacin Geogrfica Matriz Datos / Localizacin Geogrfica Entorno Tecnolgico y Comunicaciones Estrategia de Implantacin Global del Sistema Descripcin de Procesos Manuales Si la alternativa incluye desarrollo: Modelo Abstracto de Datos / Modelo de Procesos Modelo de Negocio / Modelo de Dominio Si la alternativa incluye un producto software estndar de mercado: Descripcin del Producto Evolucin del Producto Costes Ocasionados por Producto Estndares del Producto Descripcin de Adaptacin (si es necesaria) o Contexto del Sistema (con la Definicin de las Interfaces en Funcin de la Solucin) o Impacto en la Organizacin de la Solucin o Coste / Beneficio de la Solucin o Valoracin de Riesgos de la Solucin o Enfoque del Plan de Trabajo de la Solucin o Planificacin de la Solucin

Prcticas
Presentacin Sesiones de Trabajo

Participantes

Comit de Direccin Jefe de Proyecto Analistas

Tarea EVS 6.3: Aprobacin de la Solucin

El Comit de Direccin da su aprobacin formal o determina la inviabilidad del sistema, por motivos econmicos, de funcionalidad como resultado del incumplimiento de los requisitos identificados en plazos razonables o de cobertura de los mismos, etc.

Productos
De entrada Catlogo de Requisitos (EVS 6.2) Solucin Propuesta (EVS 6.2) De salida Aprobacin de la Solucin

Participantes

Comit de Direccin Jefe de Proyecto

http://www.csi.map.es/csi/metrica3/evs.pdf 2.5 Gestin de la configuracin del software.

La gestin de la configuracin del software es uno de los procesos clave para toda organizacin dedicada a la Ingeniera del Software, ya que posibilita una mejor organizacin del desarrollo y mantenimiento, consiguiendo la visibilidad del producto y facilitando el resto de procesos de produccin. En este artculo se muestra cmo se ha elaborado un Plan de Gestin de Configuracin del Software para un proyecto de I+D en colaboracin entre Empresa y Universidad. Los iniciales planteamientos de realizacin de un control informal de cambios para evitar interferencias entre los nuevos componentes a desarrollar por parte del equipo de la Universidad y el mantenimiento del sistema de

produccin realizado por la empresa fueron dando paso la definicin de un plan de GCS completo, tanto para el desarrollo del proyecto como para los desarrollos futuros realizados internamente en la empresa. http://www.di.uniovi.es/~tuya/pub/jcs-2000.html Gestin de la Configuracin del Software

Prctica de GCSW
Objetivo de la Prctica
Definir y desarrollar el plan de gestin de la configuracin del proyecto XXXX

CONTENIDO
1. Elaborar el plan de gestin de configuracin para un proyecto. 2. Desarrollar el plan de gestin de configuracin poniendo en prctica los procedimientos y herramientas para la evaluacin controlada del proyecto. 3. Crear y mantener la lnea base del proyecto e integrar el sistema final y las versiones intermedias.

Descripcin de la Prctica
Esta prctica consiste en la aplicacin de los conocimientos adquiridos durante las clases de Gestin de Configuracin a un proyecto de Ingeniera del Software. Se van a desarrollar todos los pasos del desarrollo de un caso de estudio tratado en la asignatura Anlisis y Diseo Orientado a Objetos, desde la Especificacin de los Requisitos hasta la implementacin y prueba, ejecutando simultneamente las actividades correspondientes a la Gestin de la Configuracin de un proyecto. Para poder desarrollar la prctica Ud podr consultar los documentos siguientes: Plantilla de elaboracin del Plan de Gestin de Configuracin (planscm-SCMP-SCMCorto) Preguntas y acciones a ejecutar (FAQ) En Mdulo 5 podr ver las actividades que plantea CMM, adems de lo explicado de las experiencias de PSL. Para llevar a cabo dichos objetivos, se proporciona la descripcin de una de las funcionalidades de un caso de estudio tratado. Es evidente que para una funcionalidad de un sistema no es necesario desarrollar todo un Plan de Gestin de Configuracin del Software, pero para la prctica se har as, dado que parece desmesurado desarrollar el sistema completo nicamente para aplicar lo aprendido en este tema. Para su realizacin habr que tener en cuenta la historia de lo sucedido en el desarrollo del ADOO para este proyecto y las nuevas modificaciones planteadas al mismo. Debe haber recogido todas las modificaciones, actualizaciones, cambios, etc, realizadas durante ADOO y las nuevas peticiones. Cada una de las modificaciones realizadas han de venir avaladas por un informe de problema' que segn procede, ha de venir soportado por una peticin de cambio que la ampare con su correspondiente tramitacin. En todos los casos habr que rellenar

completamente el formulario del documento correspondiente (informe de problema y/o peticin de cambio). Asimismo ha de tenerse en cuenta la necesidad de mantener actualizada la lnea base (contenidos, versiones, etc) segn se van realizando las modificaciones. Para ello utilizar la herramienta Visual Source Safe impartida en clase. Con esta herramienta gestione la configuracin y construya un repositorio con control de versiones para documentos, diseo, pruebas y cdigo fuente. Construya un ejecutable a partir de mdulos extraidos del repositorio anterior.

Planteamiento del Problema

Dentro del sistema XXXX con el que se ha venido trabajando en ADOO, para la prctica de Gestin de Configuracin del Software nos vamos a centrar en una pequea funcionalidad: XXXX.

Trabajo a Realizar
Como se ha indicado anteriormente, la prctica consiste en el desarrollo de la funcionalidad de XXXX, haciendo especial hincapi en las actividades de Gestin de Configuracin del Software que se realizaran a lo largo de todo este proceso. Lo primero que deber elaborar el equipo de desarrollo es un Plan de Gestin de Configuracin para este pseudo-sistema. En dicho plan se deber identificar la configuracin del sistema (estructura y componentes del producto software, nivel de visibilidad, seleccin de ECS, definicin del esquema de identificacin para ECS, versiones, variantes, configuraciones alternativas, releases , y seleccin de relaciones en la configuracin a mantener); se deber identificar la lnea base; y se debern proponer los mecanismos de accesibilidad a los ECS (definicin de bibliotecas software). A continuacin, el equipo deber comenzar con el proceso de desarrollo en s, aplicando la metodologa explicada en ADOO. Adems, tal y como se puede observar en el esquema propuesto, algunas de las actividades no ser necesario realizarlas para este problema, dada la sencillez del mismo. Por supuesto, a medida que se vaya realizando el desarrollo del sistema, debern gestionarse los procedimientos de Gestin de Configuracin, identificando y etiquetando ECS, versiones, variantes y configuraciones alternativas producidas, estableciendo lneas base, manteniendo las relaciones de la configuracin y mantenindolas bibliotecas software. Debe tenerse en cuenta que esta funcionalidad ser parte del sistema total de XXXX, y que no es preciso disear una interfaz compleja de usuario, puesto que al final slo se comunicar con otros mdulos del sistema. Por tanto, todas las entradas que procedieran de otros mdulos del sistema, se debern simular como entrada provisional del usuario.

Documentacin a Entregar
La memoria de la prctica constar de un nico documento, dividido en tres partes diferenciadas, que debern incluir los siguientes apartados: PARTE I: Plan de Gestin de Configuracin 1. Introduccin I.A. Alcance y Propsito del Documento I.B. Objetivos del Proyecto para el que se Gestiona la Configuracin I.C. Organizacin y Responsabilidades 2. Actividades de Gestin de Configuracin II.A. Seleccin de los ECS
Descripcin, etiquetas y relaciones o trazabilidad de los ECS que se van a poner bajo control de configuracin. Justificacin de la eleccin.

II.B. Esquema de Identificacin de los ECS Explicacin del esquema de identificacin que se va a utilizar (para ECS, versiones, variantes, configuraciones alternativas y releases). Especificar dnde y cmo se va a guardar esta identificacin. Explicar cada tipo de cdigo utilizado. II.C. Descripcin de las Relaciones a Mantener entre los ECS
Especificar dnde y cmo se va a mantener esta informacin.

II.D. Definicin y Establecimiento de Lneas Base

Descripcin de las lneas base a establecer (nombre, momento de establecimiento y composicin).

II.E. Definicin y Establecimiento de Bibliotecas Software Descripcin de las bibliotecas software a utilizar. Dnde va a estar cada una de ellas. Procedimientos y criterios de transicin de una a otra. Quin va a realizar la tarea de bibliotecario. PARTE II: Desarrollo del proyecto XXXX segn ADOO PARTE III: Informes del Estado de la Configuracin 1. Inventario de ECS que se han creado hasta el momento Incluir, por lo menos, para cada ECS, la lnea base, mdulo, cdigo del ECS, versin, fecha de creacin y descripcin. 2. Inventario de versiones que se han creado hasta el momento Incluir, por lo menos, para cada versin, el mdulo, cdigo del ECS, versin, fecha de creacin, autor y nmero de copias. 3. Inventario de copias que se han creado hasta el momento

Incluir, por lo menos, para cada copia, el mdulo, cdigo del ECS, versin, nmero de copia, tipo de ECS y localizacin. 4. Inventario de lneas base que se han creado hasta el momento Incluir, por lo menos, para cada lnea base, la lnea base, cdigo de los ECS aprobados, fecha de cierre y localizacin. 5. Contenido de la base de datos de relaciones entre ECS Incluir, por lo menos, las relaciones de composicin, dependencia y derivacin, y hacer mencin que las relaciones de equivalencia se hallan reflejadas en el Inventario de copias y las de sucesin en el Inventario de versiones. 6. Especificacin de las configuraciones alternativas que se tengan hasta el momento Incluir, por lo menos, para cada configuracin alternativa, el cdigo de la configuracin, y los ECS que la componen, con su correspondiente versin. 7. Descripcin del contenido actual de cada una de las bibliotecas software Incluir, por lo menos, la descripcin de las bibliotecas de trabajo, de integracin, de soporte al proyecto y maestra.

Conclusiones Anexos

REGISTRO DE DEFECTOS Grupo:

Fecha Nmero Tipo Introducido Eliminado

Hoja:
Tiempo elim. Arreg. def. Detectado por

Descripcin:

Fecha

Nmero

Tipo

Introducido

Eliminado

Tiempo elim.

Arreg. def.

Detectado por

Descripcin:

Fecha

Nmero

Tipo

Introducido

Eliminado

Tiempo elim.

Arreg. def.

Detectado por

Descripcin:

Fecha

Nmero

Tipo

Introducido

Eliminado

Tiempo elim.

Arreg. def.

Detectado por

Descripcin:

Fecha

Nmero

Tipo

Introducido

Eliminado

Tiempo elim.

Arreg. def.

Detectado por

Descripcin:

http://dis.eafit.edu.co/pos/espsw/01/apgcsw.doc

3 Anlisis del proyecto.

ANALISIS DE SISTEMAS DE COMPUTACION

TEMA II. Anlisis de Sistemas de Computacin. DESARROLLO. 2.1 Conceptos y Anlisis: Es un conjunto o disposicin de procedimientos o programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lgico en la unin de las partes. Un mtodo, plan o procedimiento de clasificacin para hacer algo. Tambin es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Informacin. Esto se lleva a cabo teniendo en cuenta ciertos principios: Debe presentarse y entenderse el dominio de la informacin de un problema.

Defina las funciones que debe realizar el Software. Represente el comportamiento del software a consecuencias de acontecimientos externos. Divida en forma jerrquica los modelos que representan la informacin, funciones y comportamiento.

El proceso debe partir desde la informacin esencial hasta el detalle de la Implementacin. La funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales:

Software, que son Programas de computadora, con estructuras de datos y su documentacin que hacen efectiva la logstica metodologa o controles de requerimientos del Programa. Hardware, dispositivos electrnicos y electromecnicos, que proporcionan capacidad de clculos y funciones rpidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin externa dentro de los Sistemas. Personal, son los operadores o usuarios directos de las herramientas del Sistema. Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software. Documentacin, Manuales, formularios, y otra informacin descriptiva que detalla o da instrucciones sobre el empleo y operacin del Programa. Procedimientos, o pasos que definen el uso especifico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento.

Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente: Identifique las necesidades del Cliente. Evale que conceptos tiene el cliente del sistema para establecer su viabilidad. Realice un Anlisis Tcnico y econmico. Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema. Establezca las restricciones de presupuestos y planificacin temporal. Cree una definicin del sistema que forme el fundamento de todo el trabajo de Ingeniera.

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, as como de la Ingeniera humana (Manejo y Administracin de personal), y administracin de base de datos. 2.2 Objetivos del Anlisis. 2.2.1 Identificacin de Necesidades. Es el primer paso del anlisis del sistema, en este proceso en Analista se rene con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas

globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificacin temporal y presupuestal, lneas de mercadeo y otros puntos que puedan ayudar a la identificacin y desarrollo del proyecto.

Algunos autores suelen llamar a esta parte Anlisis de Requisitos y lo dividen en cinco partes: Reconocimiento del problema. Evaluacin y Sntesis. Modelado. Especificacin. Revisin.

Antes de su reunin con el analista, el cliente prepara un documento conceptual del proyecto, aunque es recomendable que este se elabore durante la comunicacin Cliente analista, ya que de hacerlo el cliente solo de todas maneras tendra que ser modificado, durante la identificacin de las necesidades.

2.2.2 Estudio de Viabilidad. 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:

1. Viabilidad econmica. Una evaluacin de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado. 2. Viabilidad Tcnica. Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. 3. Viabilidad Legal. Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que se podra incurrir al desarrollar el Sistema. 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.

2.2.3 Anlisis Econmico y Tcnico. El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema.

Muchas veces en el desarrollo de Sistemas de Computacin estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la caractersticas del Sistema. El anlisis de costos beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto. En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de mantenimiento y productividad.

Los resultados obtenidos del anlisis tcnico son la base para determinar sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfectamente unas con otras.

2.2.4 Modelado de la arquitectura del Sistema. Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios, Herramientas, Aviones, Maquinas, se crea un modelo idntico, pero en menor escala (mas pequeo). Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe tomar una forma diferente, deben representar todas las funciones y subfunciones de un Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden incluir notacin grfica, informacin y comportamiento del Sistema. Todos los Sistemas basados en computadoras pueden modelarse como transformacin de la informacin empleando una arquitectura del tipo entrada y salida. 2.2.5 Especificaciones del Sistema. Es un Documento que sirve como fundamento para la Ingeniera Hardware, software, Base de datos, e ingeniera Humana. Describe la funcin y rendimiento de un Sistema basado en computadoras y las dificultades que estarn presente durante su desarrollo. Las Especificaciones de los requisitos del software se produce en la terminacin de la tarea del anlisis.

En Conclusin un proyecto de desarrollo de un Sistema de Informacin comprende varios componentes o pasos llevados a cabo durante la etapa del anlisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno mas de los componentes: Software, hardware, personas, base de datos, documentacin y procedimientos.

3.1 Anlisis de riesgos.

Qu es un anlisis de riesgos?
Las graves crisis alimentarias que han azotado Europa recientemente han suscitado un intenso debate acerca de la seguridad del suministro de alimentos. Tambin han dado lugar a la creacin de la Autoridad Europea de Seguridad Alimentaria (European Food Safety Authority, EFSA). La EFSA se har cargo de la evaluacin cientfica de riesgos, mientras que las decisiones en materia de gestin de riesgos son competencia de los legisladores y polticos de la Unin Europea. Los riesgos son evaluados y gestionados en el marco del denominado anlisis de riesgos. Este artculo explica en qu consiste. Tenemos claro lo que queremos decir con el trmino riesgo? Una definicin sera la probabilidad del advenimiento de un acontecimiento adverso, problema o dao y las consecuencias del mismo. Evaluar riesgos y determinar la mejor manera de gestionarlos en la compleja y amplia escala de la Unin Europea constituye un gran desafo. Es difcil apreciar todos los aspectos de un riesgo y prever todas las consecuencias de una medida de control, ya que siempre habr cierto grado de incertidumbre. El anlisis de riesgos es una forma sistemtica de evaluar mejor los riesgos, lograr transparencia en su complejidad y resolver las dudas o lagunas. Este sistema facilita la adopcin de decisiones en materia de gestin de riesgos y su comunicacin. El anlisis de riesgos est compuesto de tres etapas: evaluacin de riesgos, gestin de riesgos y comunicacin de riesgos. Evaluacin de riesgos En lo que respecta a la alimentacin, el riesgo implica un impacto potencial en los consumidores. Los microorganismos infecciosos, las sustancias qumicas contaminantes (por ejemplo, los productos de limpieza) o los agentes fsicos (como el cristal) entraan posibles peligros relacionados con los alimentos. A pesar de que se realizan todos los esfuerzos posibles para minimizar los peligros, la seguridad alimentaria no es absoluta y stos peligros siempre pueden darse. La

evaluacin de riesgos aplica un enfoque estructurado para estimar el riesgo y comprender mejor los factores que intervienen de forma positiva o negativa. Un riesgo puede evaluarse en trminos absolutos (por ejemplo, calculando el nmero de consumidores que enferman cada ao por comer determinados productos) o en trminos relativos (por ejemplo, comparando la seguridad de un producto con la de otro). Gestin de riesgos Los gestores de riesgos dirigen el anlisis de riesgos, deciden si la evaluacin de un riesgo es necesaria o no para resolver un problema y apoyan a los evaluadores en su trabajo. Una vez realizada la evaluacin, los gestores de riesgos se basan en el resultado para decidir qu medidas hay que tomar. Cuando es preciso reducir el riesgo, la gestin de riesgos debe optar por las mejores medidas posibles para lograrlo. Comunicacin de riesgos En el anlisis de riesgos, existen diferentes tipos de comunicacin importantes. Los aspectos tcnicos se debaten entre gestores, evaluadores y partes interesadas del sector privado. A la hora de decidir cul es la mejor manera de controlar un riesgo y de ejecutar las decisiones, la comunicacin entre los gestores de riesgos y los sectores pblico y privado es muy importante. Este debate es menos tcnico y tiene en cuenta, por ejemplo, puntos de vista ticos, sociales y econmicos. A fin de tomar una decisin que se adecue al objetivo y sea aceptable para todas las partes interesadas, la gestin de riesgos debe asegurar una comunicacin adecuada. Mucha gente opina que la comunicacin de riesgos no es ms que una actividad de relaciones pblicas, pero la verdad es que la disciplina ha evolucionado de forma independiente, sobre todo gracias a las teoras de la percepcin de riesgos. La percepcin de riesgos hace referencia a una amplia serie de estudios psicolgicos, que se iniciaron hace unos cincuenta aos con objeto de analizar por qu unos riesgos se perciben de una forma y otros de otra. Esta investigacin mostr que a la gente le afectan ms los riesgos involuntarios que los voluntarios, y se preocupa ms por los problemas tecnolgicos que por las catstrofes naturales. Estos descubrimientos influyeron enormemente en la manera de presentar los riesgos ante la opinin pblica. Las estrategias iniciales de comunicacin de riesgos funcionaban de arriba abajo, por ejemplo, de un legislador al pblico. Actualmente, se prefiere una forma dialctica en la comunicacin de riesgos que anime al pblico y las partes interesadas a participar activamente en el proceso comunicativo. EUFIC sigue de cerca el desarrollo del anlisis de riesgos dentro del sector alimentario europeo. La comunicacin de riesgos reviste un inters especial para nuestra organizacin, razn por la cual seguiremos informndoles en los prximos meses sobre este tema y otras actividades relacionadas con el riesgo.

http://www.eufic.org/sp/food/pag/food38/food382.htm

Anlisis de Riesgo
Mxico como pas miembro de la OMC, ha adquirido, entre otros, el compromiso de cumplir con las obligaciones contenidas en el Acuerdo sobre la Aplicacin de las Medidas Sanitarias y Fitosanitarias (AMSF), que tiene por finalidad proteger la salud y vida de las personas y de los animales, as como preservar los vegetales. El artculo 5 del citado Acuerdo obliga a los gobiernos miembros a que basen dichas medidas en la evaluacin de los riesgos para la vida y la salud de personas y de los animales o la preservacin de las plantas, considerando para ello las tcnicas de evaluacin de riesgos desarrolladas por organizaciones internacionales reconocidas. Asimismo, se enfatiza que al efectuar la evaluacin de los riesgos, los pases deben considerar la evidencia cientfica disponible, los ms relevantes mtodos de produccin y procesamiento; igualmente, deben tener en cuenta los ms significativos mtodos de inspeccin, de muestreo y de anlisis; debern considerar tambin la prevalencia de enfermedades o plagas especficas, la existencia de reas libres de enfermedades o plagas, las condiciones ecolgicas y ambientales ms importantes, las cuarentenas y otros tratamientos. Como se puede apreciar, el aplicar la evaluacin de riesgos se tiene, obligatoriamente que recurrir a otras disciplinas y a diferentes unidades de cada uno de los servicios. Ms an, el mismo artculo 5 indica que, la evaluacin de los riesgos debe ser aplicada para obtener un apropiado nivel de proteccin sanitaria o fitosanitaria, para ello se deben tener en consideracin, como factores econmicos relevantes: el dao potencial en trminos de prdidas de produccin o ventas -que se sufrira- en caso de ingreso, establecimiento o difusin de plagas o enfermedades; los costos de control o erradicacin en un territorio del pas importador; y el costo-beneficio de los enfoques alternativos para limitar esos riesgos. El Anlisis de Riesgos se acepta hoy como la disciplina o metodologa ms apropiada para la adopcin de medidas tendientes a prevenir y controlar plagas y enfermedades cuarentenarias, as como contaminaciones biolgicas o qumicas de los alimentos, que pueden causar alguna de las llamadas Enfermedades Transmitidas por Alimentos (ETA). Dentro de los servicios veterinarios nacionales, cumplir con la obligacin de aplicar la evaluacin de riesgos previsto en el AMSF, requiere de la incorporacin, dentro de ellos, del recurso humano especializado en materia de epidemiologa, bioestadstica y de anlisis de riesgo propiamente dicho, dentro de parmetros internacionalmente aceptados, que permitan desempear esta labor; que tal recurso humano funcione en equipo, que cuente con materiales y equipamiento apropiados, as como que existan los mecanismos para aprobar los documentos generados durante el proceso, su revisin y almacenamiento.

En el mbito de salud animal, el anlisis de riesgo es una herramienta utilizada para sustentar estudios epidemiolgicos que apoyen las evaluaciones sobre el riesgo que representan algunas importaciones de animales, productos y subproductos a Mxico, as como para la reintroduccin de enfermedades a zonas libres.
El riesgo implica la probabilidad de ocurrencia de un evento adverso (peligro) y la magnitud de sus consecuencias. Es por ello, que la parte preliminar del estudio debe incluir un perfil de las circunstancias por las que se va a realizar el anlisis, una descripcin del agente y/o el producto, incluyendo el proceso de produccin, el origen del mismo su uso en destino, los principales beneficiarios de la importacin, los principales receptores del riesgo, as como otros aspectos relevantes para el estudio. Es importante sealar que el anlisis de riesgo es una parte de la toma de decisiones y quien tiene la responsabilidad de decidir debe tomar en cuenta otras consideraciones antes de llegar a una determinacin final.

Todo lo anterior justifica que la Direccin General de Salud Animal del SENASICA, haya creado, dentro de la estructura de la Direccin de Vigilancia Epidemiolgica, una Unidad de Anlisis de Riesgo, integrada por personal altamente capacitado, seleccionado entre las diferentes reas del SENASICA, la cual es la responsable directa de la evaluacin de riesgos en materia sanitaria entre cuyos logros destacan: Mayor confiabilidad en la calidad sanitaria de los bienes pecuarios exportados por Mxico Proteger la vida y salud de los animales del pas y contribuir indirectamente con aspectos de salud pblica. Contribuir al soporte y avance de las campaas zoosanitarias y al reconocimiento y preservacin de reas libres o de baja prevalencia de enfermedades y/o plagas de los animales. Evitar el ingreso y diseminacin de enfermedades y plagas exticas o emergentes. Proteger las inversiones pecuarias y la economa de pequeos y medianos productores. Proteger la biodiversidad y el medio ambiente. Favorecer, indirectamente, el incremento del turismo. Contribuir a un mejor conocimiento cientfico de las enfermedades y plagas de los animales. Documentar cada evaluacin o anlisis de riesgo realizado, para su utilizacin, de ser el caso, como soporte de las negociaciones comerciales, desde un punto de vista cientfico y sanitario, que se realicen con terceros pases. Favorecer directamente las exportaciones de bienes pecuarios.

http://web2.senasica.sagarpa.gob.mx/xportal/dgsa/czoo/Doc497/Ariesgo.doc

3.2 Control de calidad.

Una de las reas de la actividad humana en la que la aplicacin de tcnicas estadsticas ha tenido gran difusin y al mismo tiempo un enorme xito, es en la de aquellos aspectos que se relacionan con el control de calidad de produccin de bienes y suministro de servicios. En los aos 80 la aplicacin de la filosofa y tcnicas del control de calidad en la produccin supuso un enfoque revolucionario y tremendamente competitivo, que fue aprovechado sobre todo por la industria japonesa para colocarse a la cabeza del mercado mundial, lo que resulta curioso, siendo americanos los "padres" del control de calidad, puesto que la industria americana slo se subi al carro del control de calidad una vez que la presin ejercida en el mercado por la superioridad de los productos japoneses les oblig a considerar las bondades de la nueva filosofa, en la que la calidad constituye un concepto global que no slo se aplica al producto sino a todo el proceso de fabricacin, incluyendo el control de costes, precios y beneficios, gestin de los suministros y plazos de entrega. Aunque inicialmente el control de calidad se aplic solo a la fabricacin industrial, enseguida se extendi su radio de accin a la prestacin de servicios, donde tambin podemos incluir el rea de salud, aunque dentro del entorno mdico hay sectores que por sus caractersticas, ms asimilables a la industria, tienen una mayor tradicin en el empleo del control de calidad; como son los laboratorios de anlisis clnicos (hematologa, bioqumica o microbiologa), o los bancos de sangre. Sin embargo las tcnicas han sido utilizadas tambin en otros entornos, como puede ser por ejemplo en la monitorizacin de fallos en operaciones quirrgicas, y su campo de aplicacin est limitado tan slo por nuestra imaginacin, ya que cualquier actividad humana es susceptible de ser cuantificada y por tanto monitorizada para mejorar su calidad, desde el tiempo de espera de un paciente que acude a consulta, hasta el porcentaje de pacientes que cumplen adecuadamente el tratamiento prescrito, o el mismo registro de datos en la historia clnica del paciente. Un elemento fundamental en la filosofa del control de calidad moderno es la utilizacin generalizada de procedimientos cientficos, incluidos los mtodos estadsticos, en la planificacin, recogida de datos y anlisis de los mismos, de tal forma que las decisiones no se sustenten en meras conjeturas. Aunque en un sistema sanitario fundamentalmente pblico, como es el espaol, la competencia no constituye el principal acicate para la incorporacin de sistemas de control de calidad, no cabe ninguna duda de que sin embargo existen mltiples razones para incorporar estas tcnicas en la gestin de los servicios de atencin sanitaria, como lo corrobora el hecho del aumento de su difusin y aplicacin en este entorno, razones en las que de momento no vamos a entrar, por ser la lnea argumental de estos artculos fundamentalmente estadstica. En este documento vamos a echar un vistazo a lo que se conoce como Control estadstico de procesos, metodologa que utilizando fundamentalmente grficos permite monitorizar la estabilidad (calidad) de un proceso de produccin o de suministro de un servicio, de forma que se detecte, cuanto antes, cualquier situacin inadecuada; lo que permitir eliminar las causas especiales de variabilidad en la obtencin del resultado final. Grficos de control Los grficos de control fueron propuesto originalmente por W. Shewart en 1920, y en ellos se representa a lo largo del tiempo el estado del proceso que estamos monitorizando. En el eje horizontal X se indica el tiempo, mientras que el eje vertical Y se representa algn indicador de la variable cuya calidad se mide. Adems se incluye otras dos lneas horizontales: los lmites superior e inferior de control, escogidos stos de tal forma que la probabilidad de que una observacin est fuera de esos lmites sea muy baja si el proceso est en estado de control, habitualmente inferior a 0.01.

En cualquier proceso, incluida la prestacin de servicios sanitarios, se produce variabilidad. Por ejemplo incluso en situaciones muy similares no todas las cirugas resultan exitosas, no todas las consultas duran el mismo tiempo, etc. En cada caso el origen de esa variabilidad puede ser muy diverso, por un lado tenemos causas impredecibles, de origen desconocido, y por tanto en principio inevitables, y por otro lado, causas previsibles debidas a factores humanos, a los instrumentos o a la organizacin. Estudiando meticulosamente cualquier proceso es posible eliminar las causas asignables, de tal forma que la variabilidad todava presente en los resultados sea debida nicamente a causas no asignables; momento ste en el que diremos que el proceso se encuentra en estado de control. La finalidad de los grficos de control es por tanto monitorizar dicha situacin para controlar su buen funcionamiento, y detectar rpidamente cualquier anomala respecto al patrn correcto, puesto que ningn proceso se encuentra espontneamente en ese estado de control, y conseguir llegar a l supone un xito, as como mantenerlo; se es el objetivo del control de calidad de procesos, y su consecucin y mantenimiento exige un esfuerzo sistemtico, en primer lugar para eliminar las causas asignables y en segundo para mantenerlo dentro de los estndares de calidad fijados. As pues el control estadstico de calidad tiene como objetivo monitorizar de forma continua, mediante tcnicas estadsticas, la estabilidad del proceso, y mediante los grficos de control este anlisis se efecta de forma visual, representando la variabilidad de las mediciones para detectar la presencia de un exceso de variabilidad no esperable por puro azar, y probablemente atribuible a alguna causa especfica que se podr investigar y corregir. El inters de los grficos de control radica en que son fciles de usar e interpretar, tanto por el personal encargado de los procesos como por la direccin de stos, y lo que es ms importante: la utilizacin de criterios estadsticos permite que las decisiones se basen en hechos y no en intuiciones o en apreciaciones subjetivas que tantas veces resultan desgraciadamente falsas. A la hora de analizar los datos en un proceso de control calidad tenemos que diferenciar tres casos segn la caracterstica medida: La variable es medible numricamente, por ejemplo un tiempo. Se estudia un atributo o caracterstica cualitativa que el proceso posee o no posee, por ejemplo el paciente cumple o no cumple adecuadamente el tratamiento Se cuenta el nmero de defectos en el producto o situaciones inadecuadas en la prestacin del servicio

Vamos en primer lugar a presentar los grficos de control para variables cuantitativas. En este caso se puede representar la evolucin de un valor medio, como puede ser la media o la mediana, o representar un indicador de dispersin como puede ser el rango o la desviacin tpica. Cuando no se va a utilizar un programa especfico se suele preferir el rango a la desviacin tpica, por ser mucho ms fcil de calcular. Existen otros tipos de grfico ms especializados, que comentaremos ms adelante. Grfico de control para variables cuantitativas Veamos cmo se construye un grfico de evolucin de medias. En primer lugar, para cada instante de tiempo se tomar una pequea muestra (por ejemplo diariamente). En control de calidad se usa habitualmente muestras pequeas de tamao de entre 5 a 10 elementos, tomadas a lo largo de un tiempo representativo, normalmente de 20 a 30 ocasiones. Veamos un sencillo ejemplo, en el que durante 24 das se han anotado 5 observaciones.

Tabla 1 N 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Dato 1 Dato 2 Dato 3 Dato 4 Dato 5 10.7 10.7 10.7 10.7 10.9 10.8 10.9 10.8 10.9 10.7 10.8 10.8 10.8 10.7 10.8 10.6 10.7 10.7 10.8 10.7 10.7 10.8 10.7 10.9 10.8 10.6 10.8 10.8 10.9 10.7 10.6 10.8 10.7 10.8 10.8 10.6 10.8 10.7 10.8 10.7 10.7 10.8 10.9 10.9 10.8 10.6 10.7 10.6 10.8 10.7 10.8 10.8 10.9 10.5 10.9 10.9 10.8 10.9 10.7 10.7 10.7 10.7 10.8 10.8 10.7 10.7 10.7 10.9 10.8 10.6 10.8 10.8 10.8 10.8 10.7 10.9 10.8 10.8 10.8 10.9 10.8 10.7 10.9 10.7 10.8 10.8 10.7 10.6 10.7 10.6 10.7 10.7 10.9 10.7 10.7 10.6 10.6 10.7 10.6 10.7 10.5 10.0 10.7 10.8 10.8 10.8 10.7 10.8 10.7 10.7 10.7 10.6 10.7 10.6 10.7 10.7 10.7 10.7 10.6 10.7

Para elaborar el grfico de evolucin de medias, en primer lugar se calcula la media de cada muestra de 5 observaciones y luego la media global de esas 24 medias. Seguidamente se calcula los rangos para cada muestra (valor mximo - valor mnimo), as como la media de los 24 rangos. Para el clculo de los lmites de control se utiliza la teora de probabilidades, suponiendo que los datos siguen una determinada distribucin de probabilidad, ya sea sta normal, binomial, Poisson o cualquiera otra, dependiendo del tipo de datos analizado. De esta forma se determinar un factor que al multiplicarlo por un parmetro de variabilidad (sea ste el rango o la desviacin tpica) nos permite calcular los lmites del grfico de control de calidad, lmites que nos garantizan una probabilidad del 99 % de que las observaciones se encuentren dentro de esos mrgenes si el proceso est en estado de control. Es un concepto totalmente anlogo al de intervalo de confianza para una estimacin, al que estamos habituados en la inferencia estadstica. En general no ser necesario realizar los clculos concretos, ya que si no se dispone de un programa al efecto siempre se puede acudir a cualquier libro de control de calidad, donde encontraremos tabulados los valores a aplicar, de forma similar a como se presentan en la tabla 2. Los lmites de calidad superior e inferior para un grfico de medias se calculan de acuerdo a las siguientes frmulas: LCSm=M+A2R

LCIm=M-A2R donde M es la media global (media de todas las medias) y R es la media de todos los rangos. Representado en un grfico las 24 medias de las muestras de tamao 5 de la tabla 1, una lnea horizontal correspondiente a la media global, y dos lneas horizontales correspondientes a los lmites de calidad obtenemos un grfico como el de la figura 1

Fig. 1 Grfico de control para la evolucin de medias

Tabla 2. Factores para lmites de control en grficos de medias y rangos Grfico de medias Tamao de muestra n Factor A2 2 3 4 5 6 7 8 9 10 1.88 1.02 0.73 0.58 0.48 0.42 0.37 0.34 0.31 Grfico de Rangos Factor D3 0 0 0 0 0 0.08 0.14 0.18 0.22 Factor D4 3.27 2.57 2.28 2.11 2.00 1.92 1.86 1.82 1.78

De igual forma se puede construir un grfico de control para la evolucin del Rango. En este caso los lmites de control vienen dados por las frmulas:

LCSR=D4R LCIR=D4R donde D4 se obtiene de la tabla 2, y como antes R es el rango medio. Grfico de control para atributos Cuando la variable que se analiza solo puede tomar dos valores, no o s, correcto o incorrecto, adecuado o inadecuado, se habla de control por atributos. Ahora las muestras han de ser necesariamente mayores que cuando se analizan variables medibles, y habitualmente se utilizar un grfico de proporciones, en el que la variable a representar en el eje de las Y es la proporcin de veces en que el resultado no es adecuado. Tambin aqu se recogern de 20 a 30 muestras de tamao suficiente para que se observe en cada una alguno de los resultados defectuosos, lo que hace que el tamao de muestra necesario sea tanto mayor cuanto menor sea dicha proporcin. Si el tamao n de todas las muestras es el mismo y llamamos P a la media de todas las proporciones, sabemos que se puede estimar la desviacin tpica mediante la siguiente frmula

De tal manera que los lmites de control vienen dados ahora por las siguientes frmulas LCSP=P+3sp LCIP=P-3sp En el caso de que los tamaos de cada muestra difieran, tambin lo hace el valor de la desviacin tpica, de tal manera que para cada porcentaje representado en la grfica varan los lmites de control, los cuales no sern ya una lnea horizontal sino una lnea escalonada. Interpretacin de los grficos de control El objetivo de los grficos de control es determinar de forma visual y por tanto sencilla cundo un proceso se encuentra fuera de control, con una probabilidad de error pequea. La primera indicacin de que el proceso puede estar fuera de control viene dada por la presencia de algn punto fuera de los lmites de control, como pasa con los datos correspondientes a la muestra 21 en la figura 1. Para facilitar la deteccin de patrones anmalos o poco probables en un proceso en estado de control, conviene dividir en tres zonas de igual tamao el rea situada a ambos lados de la lnea central, entre sta y los lmites de control, como vemos en la siguiente figura:

Fig.2 Grfico de control con zonas intermedias Si en el grfico se est utilizando la desviacin tpica para calcular los lmites de control, estas zonas corresponden a 1, 2 y 3 desviaciones tpicas, que hemos marcado en la figura como A, B y C respectivamente. Otra posible seal de que el proceso est fuera de control se da cuando aparecen un elevado nmero de puntos consecutivos al mismo lado de la lnea central: si nos encontramos 8 puntos seguidos al mismo lado de la lnea central, o 10 puntos de 11, o 12 de 14. Cualquier tratado sobre implantacin de procesos de calidad presenta una serie de reglas caseras para detectar diferentes series de datos improbables. Adems de las dos anteriores destacamos las siguientes: 2 de 3 puntos seguidos en la zona C 4 de 5 puntos seguidos en la zona B o ms all (como vemos que pasa en la figura 2 en los puntos marcados en rojo) 6 puntos seguidos ascendentes o descendentes 8 puntos seguidos fuera de la zona A, a ambos lados de la lnea central

En cualquier caso siempre hay que estar atento a la presencia de patrones o tendencias en los grficos de control. Estas reglas pueden ser incluso ms restrictivas (alerta para un nivel de probabilidad ms bajo), si as lo requiere el proceso que se controla. As por ejemplo en el mundo del control de calidad para los laboratorios de anlisis clnicos son muy conocidas las denominadas reglas de Westgard, que no son ms que una adaptacin concreta de los razonamientos expuestos al control de calidad para un analizador del laboratorio, aparato en el que diariamente se efectuarn muestras de control de calidad para verificar que est funcionando adecuadamente. Los resultados obtenidos en estas muestras se representan en un grfico de control como los ya descritos, aunque en ese entorno se conocen como grfico de Levey-Jennings, y se aplican una serie de reglas probabilsticas de decisin en las que existen dos niveles: un nivel de alerta y un nivel de rechazo. As una observacin en la zona C o por encima supone una alerta y fuera de la zona de control, por encima de los lmites de control obliga a rechazar los anlisis efectuados. Eplogo En los aos 80 la aplicacin de tcnicas de control de calidad, surgidas en USA, supuso una gran revolucin en la industria japonesa, a la que en breve tuvieron que sumarse las empresas de todo el mundo para competir

no slo con la calidad sino con los precios de los productos japoneses. Tanta importancia le dio el mundo empresarial japons al control de calidad, que instituyeron un premio anual Deming, con el nombre de uno de los padres de esta filosofa, el estadounidense W. Edwards Deming. Ese inters por la calidad transcendi el entorno de la fabricacin de productos, entre los que tambin se incluye los elaborados por la industria farmacutica, para asimismo aplicarse al suministro de servicios, y poco a poco se va extendiendo un inters creciente por la calidad en el sector de la salud. Desdear las tcnicas de control de calidad como actividades no productivas, o como meras tcnicas de inspeccin, o como algo solo aplicable a la fabricacin industrial con escasa utilidad en el entorno sanitario constituye un craso error. Toda actividad humana es susceptible de mejora y por lo tanto de aumentar su calidad. Resulta curioso que mucho antes de la revolucin de Deming y los japoneses, la enfermera britnica Florence Nightingale, por cierto uno de los hitos no solo de la enfermera sino tambin de la bioestadstica, ayud en gran medida a la mejora de calidad de los servicios mdicos prestados al ejrcito britnico aportando datos y grficos cuidadosamente elaborados, mediante los que demostraba que la mayor parte de las muertes de soldados britnicos durante la guerra de Crimea eran debidas a las enfermedades contradas fuera del campo de batalla, o debido a la falta de atencin de las heridas recibidas, con lo que logr que su gobierno crease los hospitales de campaa. Y hay muchos ms antecedentes en el mundo de la medicina. Podemos destacar tambin los planteamientos del cirujano Ernest A. Codman (1869 - 1940), bastante antes de que la revolucin del control de calidad llegase a la industria. Hoy nadie puede dudar que despus de los antibiticos y las vacunas, lo que ms vidas humanas salva con respecto a siglos anteriores sean probablemente la higiene y la epidemiologa, conceptos ligados no solo a la estadstica sino tambin al control de calidad. Tan solo plantearse el analizar la actividad que se realiza y verificar si es posible mejorarla, constituye ya un primer peldao para que la calidad sea un hecho. Enlaces

The Quality Tools Cookbook

Prof. Sid Sytsma, Dr.Katherine Manley - Ferris State University The aim of the Quality Tools Cookbook is to provide a free, comprehensive, reference to the quality tools for students, faculty, or anyone on the Internet who may find it useful. The quality tools can be used to improve any kind of process, including manufacturing processes, business processes, and educational processes. Learning to use the quality tools is not difficult. The Cookbookis a step-by-step guide to using each tool, examples, and when appropriate, Excel templates. The material for each tool can be accessed from one of the menus in the page. The tools are classified into three major categories, the traditional tools, the management/planning tools, and the 1995 tools. Since this is a continuing work, additions, improvements and changes may occur at any time.

Common Control Chart Cookbook Sampling and Control Charts Control chart selection flowchart

Institute for Healthcare Improvement (IHI)

The Institute for Healthcare Improvement (IHI) is a not-for-profit organization driving the improvement of health by advancing the quality and value of health care.

http://www.qualityhealthcare.org

IHI, in collaboration with the British Medical Journal Publishing Group, developed QualityHealthCare.org for a global audience that seeks to improve, or in the case of some, leapfrog traditional health care delivery with the most innovative practices and ideas available. Health care providers just need the means to do so QualityHealthCare.org offers that means.

Quality in health care links Online Quality Resource Guide NCQA

NCQA is an independent, 501(c)(3) non-profit organization whose mission is to improve health care quality everywhere

SIX SIGMA
Six Sigma is a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a company's operational performance by identifying and eliminating "defects" in manufacturing and service-related processes.

Control Charts Qualityadvisor.com

Online reference for statistical process control, measurement systems analysis, and Six Sigma. It includes articles and FAQs on capability analysis, control charts, chart interpretation, and gage R&R. Visit our forum to browse quality questions and submit your own.

http://www.seh-lelha.org/calidad.htm
Introduccin En los aos 80 la crisis de la calidad en las empresas en las reas de productos y procesos produjo que estas reevaluaran de nuevo sus gestiones de calidad. Esta dio a conocer que los problemas se encontraban en la planificacin de la calidad en s; las perdidas en ventas, costos de la mala calidad y las amenazas a la sociedad se resume a la crisis de la calidad. En los aos 80 al surgir la crisis de la calidad, los altos directivos se vieron en uno de estos casos: a. Daos considerables en sus empresas y queran recuperarse b. No haban sufrido daos pero no queran que dicha crisis llegara a sus puertas. c. Los que ya trabajan con la calidad como mxima prioridad y vieron la ocasin oportuna para hacerse sentir

En aquella poca sus tcticas fueron: exhibiciones, eslganes, carteles, estandartes y toda clase de colorido carnaval, que creo conciencia pero no comportamiento para la calidad. La leccin que obtuvieron es que hay que:

1. Establecer los objetivos especficos que se han de alcanzar y los planes para alcanzar
dichos objetivos.

2. Asignar una responsabilidad clara para cumplir los objetivos

3. Recompensar por los resultados obtenidos. Hasta el comienzo de los aos 90 la mayora de las empresas partan del punto en que la calidad cuesta y por esto se disminuiran las ganancias. Hoy en da mas gente se d cuenta de que en realidad es al contrario. La bsqueda para ofrecerle mejor calidad al cliente provoca positivamente la baja de precios y mayores ganancias. Muchas de las deficiencias de los productos y procesos tienen su origen en la mala planificacin de la calidad. La importancia otorgada durante los ltimos aos al control de calidad es una respuesta a la competencia Japonesa basada en la calidad. Juran se reconoce como la persona que agrego la calidad a la dimensin humana, lo que nosotros llamamos ahora la direccin de calidad total. "Calidad se ha convertido en una palabra moderna durante los ltimos aos. A pesar de esto existen an muchas organizaciones que no estn conscientes de la importancia de la calidad, lo que implica calidad o como se llega a la calidad correcta de un servicio. 2. Dr. Joseph M. Juran (Biografa) Naci el 24 de diciembre de 1904 en la ciudad de Braila, entonces y ahora parte de Rumania. Observador astuto, oyente, atento, brillante, sintetizador, pronosticador, persistente, Juran ha sido llamado el padre de la calidad "gur" de la calidad y el hombre quien "enseo calidad a los japoneses". Quizs lo ms importante, es que el reconocido como la persona quien agrego la dimensin humana para la amplia calidad y de ah proviene los orgenes estadsticos de la calidad total. Su plan fue hacerlo todo: filosofa, escritura, lectura consultar. Gerentes que han aprendido de Juran hay miles y miles de ellos mundialmente hablando de sus ideas con el respeto que trasciende apreciacin y las relevancias cercanas, Steve Jobs, fundador de Apple Computer y Next, se refiere a Juran por su profunda contribucin. Jungi Niguahi, director ejecutivo de la unin de cientficos e ingenieros japoneses, establece categricamente que el Dr. Juran es la mas maravillosa autoridad en control de calidad, en todo el mundo.

Peter Duccker, el escritor de teoras, acert que "cualquier avance logrado por la industria manufacturera americana en los ultimos 30 o 40 aos fueron logrados por la constancia, paciencia y autoindestructible carcter de su trabajo. Hoy Juran enfoca su atencin en una nueva misin: repara la deuda que siente que le debe al pas que le brinda la gran oportunidad y el xito excepcional. 3. Cronologia 1924: Se grado como bachiller en ciencias en Ingeniera Elctrica. 1928: Su primer trabajo (un folleto de entrenamiento llamado" Mtodos estadsticos aplicados a los problemas de manufactura". 1937: Conceptualiza el principio de Pareto. 1941: Temporal asistente administrador con la Lend-Lease Administration (ah experimento con lo hoy llamado reingenieria). 1951: Publicacin manual de control de calidad (estndares). 1954: Le entrega una serie de lecturas a gerentes japoneses el cual los ayuda a estableser sobre la trayectoria de calidad. 1979: Fundo el instituto Juran para crear nuevas herramientas y tcnicas para promulgar sus ideas y explorar el "Impacto de la calidad en la sociedad". 1984: Lo apremia el emperador Japons Hiri Hito con la orden del tesoro sagrado. 1986: Publica la "Triloga de la Calidad" ayuda a la creacin del Premio de calidad nacional "The Malcoln Baldrige National Quality Award". 1987: Renuncia al liderazgo del Instituto Juran Inc. 1993-1994: Despus de una serie de lecturas triunfantes en 1993 y 1994, el tour "The Last World", l suspendi toda publicacin reciente, de orden para dedicarse a escribir proyectos y dedicar tiempo a sus obligaciones familiares. 4. La Calidad para Joseph Juran Calidad segn Juran tiene mltiples significados. Dos de esos significados son crticos, no solo para planificar la calidad sino tambin para planificar la calidad sino tambin para planificar la estrategia empresarial. Calidad: Se refiere a la ausencia de deficiencias que adopta la forma de: Retraso en la entregas, fallos durante los servicios, facturas incorrectas, cancelacin de contratos de ventas, etc. Calidad es " adecuacin al uso". La Misin de Juran y la Planificacin para la Calidad

Crear la conciencia de la crisis de la calidad, el papel de la planificacin de la calidad en esa crisis y la necesidad de revisar el enfoque de la planificacin de la calidad. Establecer un nuevo enfoque de la planificacin de la calidad. Suministrar formacin sobre como planificar la calidad, utilizando el nuevo enfoque. Asistir al personal de la empresa para replanificar aquellos procesos insistentes que poseen deficiencias de calidad inaceptables (caminar por toda la empresa). Asistir al personal de la empresa para dominar el proceso de planificacin de la calidad, dominio derivado de la replanificacion de los procesos existentes y de la formacin correspondiente. Asistir al personal de la empresa para utilizar el dominio resultante en la planificacin de la calidad de forma que se evite la creacin de problemas crnicos nuevos. La Espiral del Progreso de la Calidad

Una forma conveniente de mostrar algunos de los muchos usos y usuarios es por medio de la "espiral de progreso de la calidad". Nos referimos a ella simplemente como "la espiral. "La espiral muestra una secuencia tpica de actividades para poner un producto en le mercado. En las grandes empresas departamentalizamos esas actividades. Como resultado cada departamento realiza un proceso operativo, produce un producto y suministra dicho producto a otros departamentos receptores pueden ser considerados "clientes" que reciben los productos procedentes de los departamentos proveedores. La tabla de mas abajo muestra algunas de las relaciones evidentes en "la espiral":

Proveedor Cliente Desarrollo del producto

Producto (Bienes y Servicios) Informacin sobre las necesidades Diseos del producto

Cliente Desarrollo del producto Operaciones Marketing

Operaciones Bienes, servicios Marketing Bienes, servicios

Clientes

Observe que algunos de los clientes son "internos", esto es miembros de la misma compaa que los proveedores. Otros clientes son externos. "La Espiral" es una versin altamente simplificada de lo que ocurre en una gran empresa. 5. La Triloga de Juran La planificacin de la calidad en uno de los tres procesos bsicos de gestin por medio de los cuales gestionamos la calidad. Los tres procesos (la triloga de Juran) estn interrelacionados. Todo comienza con la planificacin de la calidad. El objeto de planificar la calidad es suministrar a las fuerzas operativas los medios para producir productos que puedan satisfacer las necesidades de los clientes, productos tales como facturas, pelculas de polietileno, contrato de ventas, llamadas de asistencia tcnica y diseos nuevos para los bienes. Una vez que se ha completado la planificacin, el plan se pasa a las fuerzas operativas. Su trabajo es producir el producto. Al ir progresan las operaciones, vemos que el proceso es deficiente: se pierde el 20% del esfuerzo operativo, porque el trabajo se debe rehacer debido a las deficiencias de la calidad. Esta perdida se hace crnica porque el proceso se planifico as. Bajo patrones convencionales de responsabilidad, las fuerzas operativas son incapaces de eliminar esa perdida crnica planificada. En vez de ello, lo que hacen es realizar el control de calidad para evitar que las cosas empeoren. Si echamos una mirada alrededor, pronto vemos que esos tres procesos (planificacin, control, y mejora) han estado presentes durante algn tiempo. Se han utilizado en las finanzas durante siglos, lo suficiente como para haber desarrollado una terminologa normalizada. La tabla que sigue muestra algunos ejemplos: Procesos de la Triloga Planificacin de la Calidad Control de Calidad Terminologa Financiera Presupuestar, planificar el negocio Control de Costos, Control de Gastos, Control de Inventario Reduccin de Costos, Mejora de Beneficios Mejora la Calidad

El Mapa de Carreteras para la Planificacin de la Calidad La planificacin de la calidad consiste en desarrollar los productos y procesos necesarios para satisfacer las necesidades de los clientes. Ms concretamente, la planificacin de la calidad comprende las siguientes actividades bsicas:

Producto y proceso existente Necesidades de los clientes (en unidades de medida) Identificar clientes Lista de clientes Descubrir las necesidades de los clientes Necesidades de los clientes Optimizar diseo del producto (en su lenguaje) Traducir Necesidades de los clientes Desarrollar proceso (en nuestro lenguaje) Establecer unidades de medida Unidades de medida Establecer medida Necesidades de los clientes Transferir a operaciones (en unidades de medida) Optimizar probar la capacidad del proceso Proceso listo para ser transferido Caractersticas del proceso Objetivos del producto Desarrollar producto Caractersticas del producto

Proceso listo para producir

6. Identificar a los Clientes El primer paso en la planificacin de la calidad es identificar quines son los clientes. Para identificar a los clientes hay que seguir el producto para ver sobre quin repercute. Cualquier persona sobre la que repercuta es un cliente. Para seguir el producto, hay que preparar un diagrama de flujo de proceso que produce el producto. Segn el principio de Pareto, los clientes se pueden clasificar en dos categoras bsicas: Unos relativamente pocos ("pocos vitales"), cada uno de los cuales tiene gran importancia para nosotros. Un nmero relativamente elevado de clientes, cada uno de los cuales tiene una importancia moderada para nosotros ("muchos tiles").

Los "pocos vitales" incluyen los grandes fabricantes de equipos primarios, los grandes comerciantes, los altos directivos. Los "muchos tiles" incluyen los clientes, los comerciantes, la mano de obra, los procesadores y el pblico.

http://www.monografias.com/trabajos5/conca/conca.shtml 4 Anlisis de los requerimientos.

Actividades Tcnicas 1. Identificar Casos de Uso del sistema

Esta informacin se representa en un diagrama de casos de uso. Cmo encontrar un actor?

Identifique los usuarios del sistema o Porqu se disea el sistema? o Cules son los actores que el sistema va a beneficiar? o Qu actores van a interactuar directamente con el sistema? (actores primarios) o Qu actores van a supervisar, mantener, recibir informacin del sistema? (actores secundarios) Identifique los roles que juegan esos usuarios desde el punto de vista del

sistema Identifique otros sistemas con los cuales exista comunicacin Cmo encontrar un caso de uso? Identifique las operaciones importantes del sistema a construir Cules son las principales tareas de un actor? Qu informacin tiene el actor que consultar, actualizar, modificar? Cmo? Qu cambios del exterior debe informar el actor al sistema? Qu informacin debe informrsele al actor, con respecto a los cambios del sistema? Cmo encontrar relaciones entre actores y casos de uso? Identifique los casos de uso en los cuales se v implicado un actor Busque relaciones extends entre casos de uso Qu casos de uso son similares, diferencindose en la forma en la cual hacen algunas operaciones? Qu caso de uso redefine la forma en la cual se realiza una transaccin dentro de otro caso de uso? Busque relaciones uses entre casos de uso Que casos de uso son usados como transacciones de otros?

2. Dar detalle a los casos de uso descritos

Describir la informacin de entrada y salida de cada caso de uso Descripcin detallada del caso de uso

Descripcin textual de su objetivo Variantes posibles para realizar este caso de uso. Diagramas de interaccin de detalle (de secuencia o colaboracin)

Errores y excepciones posibles en el caso de uso Relacionar el caso de uso con la interfaz a usuario que lo representa

Especificar el dilogo que da solucin al caso de uso (ver definicin de interfaz)

3. Definir una interfaz inicial del sistema (si es aplicable)

Dibujar las pantallas de interaccin para los distintos actores-usuarios

Copiar el modelo mental del usuario Revisar los elementos del modelo del mundo interesantes para el actor-usuario (Ver Modelo del Mundo) Visualizacin tpica de los elementos del modelo del mundo Informacin relevante para el actor Metforas de interaccin vlidas Especificar el dilogo que da solucin a cada caso de uso que se soluciona con la interaccin con esta interfaz. Puede especificarse este dilogo de varias maneras, dependiendo de la complejidad de la interfaz definida (en esta etapa se sugiere escoger el mnimo nivel de detalle posible, para dar ms libertad de diseo en las etapas posteriores): 1. Por medio de una descripcin textual de su funcionamiento 2. Por medio de diagramas de interaccin que muestren la secuencia de operaciones entre los objetos de interfaz y los actores involucrados 3. Por medio de diagramas de estados, donde se muestre claramente los estados de la interfaz Por medio de un prototipo funcional, en trminos de la interaccin con el usuario Definir restricciones para la comunicacin con actores y sistemas Describir en el detalle del actor o de la relacin con el caso de uso particular

4. Desarrollar el modelo del mundo

Esta informacin se representa en un diagrama de estructura esttica de clases.

Identificar Clases

Elementos fsicos y lgicos dentro del sistema a modelar Top-down: Comenzar por la clase del objeto ms general (el mundo). Encontrar sus componentes hasta llegar a clases de tipos bsicos Identificar los sustantivos del enunciado del problema y determinar si son clases del modelo del mundo Identificar clases desde el punto de vista de la informacin o Identifique los elementos del espacio del problema o Identifique otros sistemas relacionados como objetos externos o Identifique dispositivos relacionados o Identifique los eventos que el sistema debe recordar y manipular o Identifique los roles de los elementos del mundo o Identifique sitios o Identifique unidades organizacionales importantes en el problema

Identificar clases desde el punto de vista funcional (casos de uso) o Identifique los objetos que participan en un caso de uso particular o Continue con los mensajes de cada objeto, dejando para el final los atributos. Identificar clases desde el punto de vista de sus estados o En qu estados est en sistema? Cules objetos determinan estos estados? o Cmo es el ciclo de vida de estos objetos?

Posibles errores:

Una clase HACE en vez de una clase ES Solo se requiere un objeto de la clase Dificultad para encontrar atributos Objetos con iniciativa propia Es un objeto y un usuario a la vez Solo se encuentra un servicio Varias clases tienen los mismos atributos o servicios Solo tienen informacin o mensajes no relevantes para el problema Vista Funcional: Dividir un sistema de la manera clsica

Identificar atributos y asociaciones.

Cules son las caractersticas determinantes del objeto en el dominio del problema? Con qu objetos esta relacionado? Con qu objetos debe estar relacionado para realizar sus mensajes? Identificar el nombre, los roles y cardinalidad de las asociaciones Qu asociaciones hay de tipo partes y un todo (composicin)? Qu informacin se requiere en una clase para realizar su comportamiento?

Posibles errores

Identificar atributos o relaciones no relevantes a los casos de uso identificados Las relaciones no reflejan directamente la realidad

Identificar mensajes

Punto de vista funcional o Qu mensajes debe tener un objeto para colaborar en un caso de uso? Punto de vista de comportamiento o Qu comportamiento se espera de un objeto dado en el modelo del

o o o

mundo? Qu mensajes se requieren para manipular la informacin que contienen? Qu mensajes requieren para manipular las relaciones que tiene? Qu mensajes hacen que el objeto cambie de un estado a otro?

Posibles errores

Identificar servicios no relevantes a los casos de uso identificados Identificar servicios que no puede realizar la clase por falta de informacin

Identificar relaciones de herencia

Qu clases son abstracciones naturales de clases ya existentes? Qu clases comparten atributos o servicios? Qu clases extienden atributos o servicios de otras?

Posibles Errores

No tener una relacin Es Un entre las clases

Identificar restricciones del modelo

Identificar valores posibles y no posibles de los atributos. Describirlos como restricciones de las clases Identificar valores permitidos para las asociaciones. Describirlos como restricciones de la asociacin Identificar restricciones que relaciones dos o ms atributos o relaciones. Describirlas dentro de la clase correspondiente

Posibles errores

Hay estados en el modelo imposibles en el mundo real Hay estados en el mundo real no considerados en el modelo

Identificar paquetes

Qu subdivisiones lgicas pueden tener las clases identificadas? Que subconjunto de clases y casos de uso pueden ser reutilizados en otros dominios?

Combinar clases fuertemente relacionadas en un paquete Combinar clases que tienen que ver con los mismos casos de uso en un paquete

Consideraciones de reutilizacin

Reutilizar modelos de dominio existentes Identificar posibles variantes en el futuro tenerlas en cuenta para diseo (patrones)

5. Validar los modelos

Validar las restricciones descritas para las clases

Para cada clase evaluar la completitud de las restricciones

Desarrollar objetos ejemplo que cumplan con las restricciones y que no sean vlidos en el mundo real Validar atributos y mensajes

La clase tiene toda la informacin necesaria para desarrollar la tarea? La clase tiene las relaciones necesarias para propagar el mensaje y cumplir con la tarea? Los mensajes si son utilizados dentro del contexto del problema?

Los mensajes obligan la conservacin de las restricciones del modelo? Desarrollar diagramas de interaccin (diagramas de secuencia o de colaboracin) para la variante por defecto de cada caso de uso, usando los objetos del modelo del mundo encontrados y sus mensajes.

Escoger la opcin por defecto de cada caso de uso Identificar los objetos involucrados

Desarrollar el diagrama de secuencia o el de colaboracin para la interaccin Validar los diagramas de Interaccin

Todo mensaje de un objeto a otro implica una asociacin y un rol en el diagrama de clases

Todo mensaje est definido en su correspondiente clase

Opcional: Completar el diagrama de clases con asociaciones de dependencia a las clases de los argumentos de los mensajes Validar con un experto del dominio

Validar estructura del mundo Validar funcionalidad esperada del sistema

Validar los diagramas de interaccin descritos como detalle de los casos de uso Validar con un usuario representativo de cada actor

Validar la funcionalidad esperada para el actor en particular: completitud, relevancia Validar los diagramas de interaccin descritos como detalle de los casos de uso del actor

Validar la interfaz diseada y el dilogo descrito Iterar si es necesaria ms informacin

Documentos Entregables
Casos de Uso iniciales Borradores de Interfaz Requerimientos ms importantes del sistema Usuarios y sistemas externos en comunicacin Especificacin de requerimientos Presentaciones iniciales para los distintos usuarios de la forma de solucionar sus requerimientos

Modelo del mundo inicial. Versin Clases, relaciones entre clases y especificacin de requerimientos
http://www.cs.ualberta.ca/~pfiguero/soo/metod/requerimientos.html

Anlisis de requerimientos

Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y adems contienen mltiples relaciones entre si. Lo que nos da a concluir, de acuerdo a lo expuesto en el captulo de complejidad en el software, que el conjunto de requerimientos de un sistema computacional es complejo. Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos. El anlisis de requerimientos consiste brevemente en los siguientes pasos: Obtener informacin acerca de lo que los usuarios desean Clasificar esos deseos para comenzar a estructurar requerimientos Identificar los niveles de jerarqua del sistema y empezar a alojar los ya clasificados requerimientos en cada nivel. Especificar formalmente los requerimientos de acuerdo al nivel de audiencia que se desea.

En los siguientes captulos se explica con mas claridad cada uno de estos puntos.

Obteniendo de la informacin
Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente.

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lgico que para recabarlos haya que obtener la informacin de primera mano. Esto es, mediante entrevistas con el cliente o recabando documentacin que describa la manera que el cliente desea que funcione el sistema de software. Las necesidades y/o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentacin original del cliente, as como cada revisin o cambio que se haga a esta documentacin Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuales de ellas sern satisfechas por el software y cuales por algn otro producto del sistema.
http://www.geocities.com/txmetsb/req-mgm-2.htm
El anlisis de requerimientos es la primera etapa de un proyecto software, en ella se tratan de definir las condiciones o capacidades necesarias para uno o varios usuarios con el fin de solucionar un problema o conseguir un objetivo. Para la creacin global del sistema se necesita comprender todos los objetivos y necesidades del usuario. En primer lugar, hemos de especificar el comportamiento externo del sistema desde el punto de vista del usuario. Una vez acabado, podemos pensar en la arquitectura general del sistema, en trminos de componentes fsicos: hardware, software, usuarios y la comunicacin entre ellos. La determinacin de los requerimientos se haya en base a la experiencia, de hablar con los usuarios finales sobre sus necesidades y analizando un sistema software existente. Podemos modelizar los requerimientos de usuario mediante lenguajes como UML, que disponen de modelos llamados casos de uso pensados para describir las funcionalidades necesarias para los usuarios. Hay diferentes tipos de requerimientos: de entorno (sistema operativo, sistema gestor de base de datos, sistema de archivos, ...), ergonmicos (interfaz grfica, etc..), funcionales(QUE debe hacer el sistema), de rendimiento, de tiempo, formato de entrega, etc...

http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/ingenieria/analisis.asp

4.1 Requerimientos funcionales y no funcionales.

Introduccin En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los aos, la Ingeniera de Software ha introducido y popularizado una serie de estndares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en s. Se han publicado muchos libros y artculos relacionados con este tema, con el modelado de procesos del negocio y la reingeniera. Un nmero creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en da la economa global depende ms de sistemas automatizados que en pocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva dcada de procesos y estndares de calidad. Sin embargo, cmo explicamos la alta incidencia de fallos en los proyectos de software? Por qu existen tantos proyectos de software vctimas de retrasos, presupuestos sobregirados y con

problemas de calidad? Cmo podemos tener una produccin o una economa de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema? Tal vez suene ilgico pero, a pesar de los avances que ha dado la tecnologa, an existen procesos de produccin informales, parciales y en algunos casos no confiables. La Ingeniera de Requerimientos cumple un papel primordial en el proceso de produccin de software, ya que enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas. La razn principal para escoger este tema se fundament en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro pas somos partcipes de este problema a diario, en donde se ha vuelto comn la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas. Tal "personalizacin", la mayora de las veces, termina retrasando el proyecto en meses, o incluso en aos. La problemtica del ao 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados. El reemplazo de plataformas y tecnologas obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definicin de los requerimientos. Estudios realizados muestran que ms del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participacin del usuario, requerimientos incompletos y el cambio a los requerimientos, tambin ocupan sitiales altos en los motivos de fracasos. Con este trabajo se pretende alcanzar los siguientes objetivos: Resaltar la importancia que tiene la Ingeniera de Requerimientos dentro del ciclo de desarrollo. Dar a conocer las diferentes alternativas que existen para identificar requerimientos. Ayudar a comprender la diferencia que existe entre las diferentes tcnicas utilizadas en la IR. Minimizar las dudas que se tiene sobre los casos de uso. Mostrar la utilizacin de herramientas CASE dentro de la administracin de requisitos.

2. La ingeniera de requerimientos y sus principales actividades Qu son Requerimientos? Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE . (1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (3) Una representacin documentada de una condicin o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc. Caractersticas de los requerimientos Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Dificultades para definir los requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Ingeniera de Requerimientos vs. Administracin de Requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. A continuacin se darn algunas definiciones para ingeniera de requerimientos. "Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa, consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema" Boehm 1979. "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no

ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software Importancia de la Ingeniera de Requerimientos Los principales beneficios que se obtienen de la Ingeniera de Requerimientos son: Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso. Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniera de Requerimientos Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles especficos dentro de la planificacin del proyecto; el conocimiento de cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo como en presupuesto. Los roles ms importantes pueden clasificarse como sigue: Usuario final: Son las personas que usarn el sistema desarrollado. Ellos estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales de usuario. Usuario Lder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado el software desarrollado. Ellos proporcionan al equipo tcnico los detalles y requerimientos de las interfaces del sistema.

Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, stas personas son las responsables de la administracin de cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Analistas y programadores: Son los responsables del desarrollo del producto en s; ellos interactan directamente con el cliente. Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseadores de base de datos, entre otros. Puntos a considerar durante la Ingeniera de Requerimientos Aunque la lista no est completa, se enumeran los puntos ms importantes. Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio estn definidos frecuentemente en trminos generales, son usados para descomponer el trabajo en tareas especficas. En ciertas situaciones IR se enfoca en la descripcin de las tareas y en el anlisis de sistemas similares. Esta informacin proporciona la base para especificar el sistema que ser construido; aunque frecuentemente se aadan al sistema tareas que no encajan con el ambiente de trabajo planificado. El nuevo sistema cambiar el ambiente de trabajo, sin embargo, es muy difcil anticipar los efectos actuales sobre la organizacin. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en produccin; tambin ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atencin a la IR es la principal. Frecuentemente la especificacin inicial es tambin la especificacin final, lo que obstaculiza la comunicacin y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados. Punto de vista de los clientes Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario. Diferentes puntos de vistas tambin pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos. El tamao y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos. Barreras de comunicacin La ingeniera de requerimientos depende de una intensa comunicacin entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicacin.

Para remediar esto, se deben abordar nuevas tcnicas operacionales que ayuden a superar estas barreras y as ganar experiencia dentro del marco del sistema propuesto. Evolucin e integracin del sistema Pocos sistemas son construidos desde cero. En la prctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integracin de componentes de varios proveedores. Para encontrar una solucin a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseo; esto minimizar la cantidad de fallas directas en el cdigo. Documentacin de requerimientos Los documentos de ingeniera de requerimientos son largos. La mayora estn compuestos de cientos o miles de pginas; cada pgina contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamao, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificacin de gran tamao, pues difcilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta despus de haberse construido el sistema. Actividades de la Ingeniera de Requerimientos En el proceso de IR son esenciales diversas actividades. En este documento sern presentadas secuencialmente, sin embargo, en un proceso de ingeniera de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado. Dependiendo del tamao del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en nmero como en nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso. A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son: Anlisis del Problema Evaluacin y Negociacin Especificacin Validacin Evolucin

Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniera de Software MODELO Oliver and EIA / IS-632 IEEE Std 1220- CMM nivel RUP

Steiner 1996

1994

Repetitivo (2)

Evaluar la informacin disponible Definir mtricas efectivas

Anlisis de Anlisis de Identificacin de Anlisis del requerimientos Requerimientos requerimientos Problema Anlisis funcional Estudio de los requerimientos Identificacin de Comprender las restricciones del necesidades de sistema a los involucrados desarrollar Anlisis de los requerimientos Definir el sistema

Crear un Sntesis modelo del comportamiento del sistema Crear un modelo de los objetos Actividades Ejecutar el anlisis Crear un plan secuencial de construccin y pruebas Anlisis y control del sistema

Validacin de requerimientos

Anlisis funcional Evaluacin y estudio de funciones Verificacin de funciones

Representacin Analizar el de los alcance del requerimientos proyecto Comunicacin de los requerimientos Validacin de requerimientos Modificar la definicin del sistema Administrar los cambios de requerimientos

Sntesis Estudio y evaluacin del diseo Verificacin fsica Control A continuacin se explicar cada una de ellas, presentndolas en el orden en que deben ser aplicadas para un nuevo proyecto. Anlisis del Problema El objetivo de esta actividad es entender las verdaderas necesidades del negocio. Antes de describir qu pasos deben cumplirse en esta actividad, debemos tener una definicin clara del trmino "Problema". "Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean" . Aqu vemos nuevamente la importancia que tiene una buena comunicacin entre desarrolladores y clientes; de esta comunicacin con el cliente depende que entendamos sus necesidades. A travs de la definicin de problema, podemos ver entonces que la actividad de "Anlisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel para resolverlo.

Durante el anlisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes Comprender el problema que se est resolviendo: Es importante determinar quin tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que debe formar para realizar una transaccin bancaria". Perspectiva del cliente = Prdida de tiempo Perspectiva del banco = Posibles prdidas de clientes Posibles soluciones pueden ser, determinar por qu demoran los cajeros, colocar una nueva caja (implica contratacin de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (telfono, internet, mediante cajeros automticos, autobancos, etc). Como puede verse, mltiples soluciones aplican para el mismo problema, sin embargo, slo una de ellas ser la ms factible. Las soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva tcnica como la del negocio. Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto. Por ejemplo, las palabras pignoracin, retencin, valor en suspenso, custodia, garanta, entre otras, son utilizadas para referirse a la accin de dejar una prenda (puede ser cualquier forma de ahorros) como garanta de una deuda adquirida. La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems de ser reutilizable en otros proyectos. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas. Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema? Quin mercadear, vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin del sistema?

Como vemos, debe conocerse la opinin de todo aqul que de una u otra forma est involucrado con el sistema, ya sea directa o indirectamente.

Definir los lmites y restricciones del sistema: Este punto es importante pues debemos saber lo que se est construyendo, y lo que no se est construyendo, para as entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restriccin ambiental, presupuestaria, de tiempo, tcnica y de factibilidad que limite el sistema que se va a construir. Evaluacin y negociacin de los requerimientos La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluacin de los mismos antes de definir si son adecuados para el cliente. El trmino "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades tcnicas y econmicas, a la vez que se buscan resultados completos, correctos y sin ambigedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstraccin y descomposicin de cada problema presentado. Los principales pasos de esta actividad son: Descubrir problemas potenciales: En este paso se asegura que todas las caractersticas descritas en el punto 1.1 estn presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc. Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un requerimiento en trminos de implementacin. A esta caracterstica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de diseo y prueba de cada requisito. La prioridad de cada requerimiento depender de las necesidades que tenga el negocio. En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operacin crtica del negocio. Si existe algn proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario. Una vez hecha esta categorizacin de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por ms que ste sea slo deseable. Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (pueden implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales (puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas (ha sido aprobado por los clientes el presupuesto?). En la actividad de evaluacin y negociacin, se incrementa la comunicacin entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos: Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema.

Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones.

Especificacin de Requisitos de Software (SRS) La especificacin de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripcin completa de las necesidades y funcionalidades del sistema que ser desarrollado; describe el alcance del sistema y la forma en como har sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra informacin que sirva de soporte y gua para fases posteriores. Es importante destacar que la especificacin de requisitos es el resultado final de las actividades de anlisis y evaluacin de requerimientos; este documento resultante ser utilizado como fuente bsica de comunicacin entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementacin del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se est proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborar las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolucin del sistema. La SRS posee las mismas caractersticas de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada caracterstica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y as sucesivamente. Las caractersticas de la SRS son verificadas en la actividad de Validacin, descrita en el punto 3.4. La estandarizacin de la SRS es fundamental pues ayudar, entre otras cosas, a facilitar la lectura y escritura de la misma. Ser un documento familiar para todos los involucrados, adems de asegurar que se cubren todos los tpicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. En el anexo #1 se muestra una plantilla completa para la especificacin de requisitos. Validacin de Requisitos La validacin es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; adems revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes. En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validacin garantiza que todos los requerimientos presentes en el documento de especificacin sigan los estndares de calidad.

No debe confundirse la actividad de evaluacin de requerimientos con la validacin de requerimientos. La evaluacin verifica las propiedades de cada requerimiento, mientras que la validacin revisa el cumplimiento de las caractersticas de la especificacin de requisitos. Durante la actividad de validacin pueden hacerse preguntas en base a cada una de las caractersticas que se desean revisar. A continuacin se presentan varios ejemplos: Estn incluidas todas las funciones requeridas por el cliente? (completa) Existen conflictos en los requerimientos? (consistencia) Tiene alguno de los requerimientos ms de una interpretacin? (no ambigua) Est cada requerimiento claramente representado? (entendible) Pueden los requerimientos ser implementados con la tecnologa y el presupuesto disponible? (factible) Est la SRS escrita en un lenguaje apropiado? (clara) Existe facilidad para hacer cambios en los requerimientos? (modificable) Est claramente definido el origen de cada requisito? (rastreable) Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)

La validacin de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado. Evolucin de los requerimientos Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cmo los objetivos de la organizacin pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolucin es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las ms frecuentes son: Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Porque cambi el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambi el ambiente de negocios. Porque cambi el mercado en el cual se desenvuelve el negocio.

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una caracterstica en particular, modificacin que a la vez puede tener impacto en otros requerimientos. Por esto, la administracin de cambios involucra actividades como establecer polticas, guardar histricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del cdigo, ya que evita tener requerimientos emparchados en un proyecto Entre algunos de los beneficios que proporciona el control de versiones estn: Prevenir cambios no autorizados.

Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de "releases". Prevenir la modificacin simultnea a los requisitos.

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

http://www.monografias.com/trabajos6/resof/resof.shtml

INTRODUCCION Los mtodos formales para el desarrollo de software (sw) o, simplemente mtodos formales, son mtodos que se utilizan para todas las etapas del ciclo de desarrollo de software y que tienen la caracterstica que usan formalismos matemticos para la representacin o derivacin de los elementos involucrados en cada etapa. El punto de arranque en la mayoria de los proyectos de sw es un Documento de Requerimientos del Sistema (DRS), en el cual se plazman lo que el usuario desea que haga el sw que desea adquirir. Este documento se escribe por lo general en lenguaje natural (espaol, ingls, frances, etc.) y, si es necesario, se utilizan tambin grficas, tablas y figuras que ayuden a describir con mayor precisin lo que el usuario desea. De esta manera, el lenguaje empleado para escribir un DRS es un lenguaje informal, pero amigable. Los lenguajes informales (como el espaol), son de naturaleza ambigua, es decir, una misma expresin puede tener ms de un significado. El lenguaje informal en que se describe un DRS es mas cercano al usuario y, se describe ms en trminos de su entorno de aplicacin que en trminos computacionales. De esta manera emplear expresiones como la siguiente: "El sistema deber calcular la caida de presin de agua de cada tubera del sistema" "el sistema de control de alarmas para cada centro de control de energa deber desplegar informes resumidos en forma ejecutiva cada da, segn el anexo de este documento" De esta manera, trminos computacionales ajenos al lenguaje del usuario, son por lo general evitados en un DRS. De esta forma se evitan trminos como "tipo entero", "modulo", etc. El DRS, por lo general se elabora con la (evidente) participacin del usuario. A menudo, el usuario es asistido para la escritura del DRS por uno ms miembros del grupo de desarrollo del sistema. En el DRS, se describen los requerimientos funcionales y no funcionales del sistema de sw que se desea. Los requerimientos funcionales describen al sistema en trminos de entrada-salida, mientras que los no-funcionales, en tminos de cualidades deseables del sistema. Por ejemplo, los siguientes son requerimientos funcionales:

"Cuando el operador central teclee el comando DOWN, todos los mensajes de alarma almacenados en la pantalla desaparecern del monitor principal, apareciendo en su lugar el diagrama unifilar de la subestacin elctrica correspondiente" "Cuando se selecciona la opcin RESUMEN en el mun 1825, se desplegarn los promedios de energa generada por cada planta generadora perteneciente al centro del control correspondiente". Son ejemplos de requerimientos no funcionales, los siguientes: "El sistema de manejo de eventos no deber tardar mas de 10 segundos en proporcionar resumenes de informacin ejecutiva" "El sistema ser desarrollado en java e integrado en un estacin de trabajo en tiempo real IDM tipo 6890-56". A menudo los DRS se escriben sin la participacion diseadores de sistemas de cmputo, de modo que no presentan directivas que conlleven a un diseo eficiente. Por otro lado contienen imprecisiones, de manera que se requiere una tarea de analisis que especifique, claramente y sin ambiguedades, el sistema a realizar. El DRS est dirigido para una relacin entre el lider y analistas del proyecto de sw y el usuario, mientras la especificacin es un documento de trabajo de uso casi exclusivo para el grupo de desarrollo de sw. Esta situacin desde luego que debe cambiar ya que la participacin del usuario en todas las etapas de desarrollo del sistema. Los mtodos formales se pueden utilizar tanto para la especificacin como para la verificacin formal de programas y, en principio, para la construccin (de cdigo) formal de programas; esta ltima da lugar a programacin automtica y derivacin formal de programas; sin embargo, en sistemas reales, es mucho ms frecuente encontrar aplicaciones de mtodos formales para la etapa de especificacin que para la verificacin formal y, prcticamente nula para el caso de construccin formal de programas. En esta seccin trataremos sobre los mtodos de especificacin formal.
http://w3.mor.itesm.mx/~logica/log9808/especif.html

4.2 Casos de uso.

Casos de Uso (Use Case)

Introduccin El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor:

Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino ms bien la labor que realiza frente al sistema. Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso.

Relaciones:
o

Asociacin
Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple.

Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada.

Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde esta la duda clsica de usar o heredar. Ejemplo: Como ejemplo esta el caso de una Mquina Recicladora: Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el nmero de temes ingresados. Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total El usuario/cliente presiona el botn de comienzo Existe un operador que desea saber lo siguiente: a. Cuantos temes han sido retornados en el da. b. Al final de cada da el operador solicita un resumen de todo lo depositado en el da. El operador debe adems poder cambiar: a. Informacin asociada a temes. b. Dar una alarma en el caso de que: i. Item se atora. ii. No hay ms papel.

Como una primera aproximacin identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la informacin de un Item o bien puede Imprimir un informe:

Adems podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn item por un cliente o bien puede ser realizada a peticin de un operador.

Entonces, el diseo completo del diagrama Use Case es:

http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html

Casos de Uso Desarrollo de Software Orientado a Objetos

Por Joaquin Gracia 27 de Septiembre de 2003
Quien ms o quien menos ha visto algn diagrama UML, lo ms probable es que te hayas topado con algn diagrama de clases. Tambin es muy probable que hayas visto algn caso de uso, pero sabes lo que son? En los libros que tratan de UML, normalmente, los primeros diagramas que presentan, de entre todos los tipos de diagramas UML, son los Casos de Uso. Y como estn en los primeros captulos siempre son ledos y pocas veces bien entendidos.

Los Casos de Uso no son parte del diseo (cmo), sino parte del anlisis (qu). De forma que al ser parte del anlisis nos ayudan a describir qu es lo que es sistema debe hacer. Los Casos de Uso son qu hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cmo este interacta con el usuario.

Si te has enfrentado alguna vez a UML normalmente habrs visto algn diagrama de clases y esperars que los Casos de Uso sean tambin una forma visual de representar la informacin. Sin embargo ests muy equivocado, si bien los casos de usos se pueden agrupar en diagramas, los diagramas no son lo importante. Voy a repetirlo para que quede claro, "Los diagramas no son lo importante".
Se que alguno estar impaciente con los diagramas, as que luego los tratar. Pero primero vayamos con lo realmente interesante. Si lo primordial de los casos de uso no son los diagramas, entonces que es lo importante? Lo realmente til de los casos de uso es el documento que describe el caso de uso, en este documento se explica la forma de interactuar entre el sistema y el usuario.

Pero lo ms claro es que te presente uno. Este podra ser el caso de uso de escribir un mensaje en un foro. Nombre: Autor: Fecha: Crear mensaje foro Joaquin Gracia 24/08/2003

Descripcin: Permite crear un mensaje en el foro de discusin. Actores: Usuario de Internet logeado. Precondiciones: El usuario debe haberse logeado en el sistema. Flujo Normal: 1. El actor pulsa sobre el botn para crear un nuevo mensaje. 2. El sistema muestra una caja de texto para introducir el ttulo del mensaje y una zona de mayor tamao para introducir el cuerpo del mensaje. 3. El actor introduce el ttulo del mensaje y el cuerpo del mismo.

4. El sistema comprueba la validez de los datos y los almacena. Flujo Alternativo: 4. El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitindole que los corrija Poscondiciones: El mensaje ha sido almacenado en el sistema.

Saltndome los campos evidentes como nombre, autor, fecha y descripcin; los actores son aquellos que interactan con el sistema. Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo. Luego tenemos el flujo de eventos, que corresponde a la ejecucin normal y exitosa del caso de uso. Los flujos alternativos son los que nos permiten indicar qu es lo que hace el sistema en los casos menos frecuentes e inesperados. Por ltimo, las poscondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha ejecutado correctamente. De forma que un caso de uso es un documento como el anteriormente presentado. Los casos de uso se pueden detallar ms o menos dependiendo de la necesidad del problema. El que te he presentado no es completo, si te interesa puedes echar un vistazo a una plantilla completa de un caso de uso, se les suele llamar casos de uso "full-dressed". Pero no voy a terminar sin explicar, como he prometido antes, los diagramas de casos de uso, que a mi me gusta llamar diagramas de "muecos y pelotas".

Muecos y Pelotas
Cuando empiezas a tener un nmero considerable de casos de uso como el anterior, no resulta nada fcil situarlos y relacionarlos. Entonces empiezas a tener la necesidad de una visin general del asunto, y ahora si, es cuando los diagramas de casos de uso son de utilidad. En los diagramas de casos de uso los muecos son los actores y las pelotas son los documentos de casos de uso. As que dibujas un mueco por actor y una pelota por cada caso de uso y los enlazas con lneas cuando haya una relacin entre ellos.
Con esto consigues una visin general de cmo los diferentes actores interactan con los distintos casos de uno.

Enlaces sobre UML

UML Resource Center en IBM UML en OMG Bibliografa UML

http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php

II.4 Diagrama de Casos de Uso

Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea. En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automtico.

II.4.1 Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. II.4.1.1 Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores. II.4.1.2 Casos de Uso Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema. II.4.1.3 Relaciones entre Casos de Uso Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin con un alcance menor como caso de uso. La razn para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicacin en el equipo de desarrollo, el manejo de la documentacin de casos de uso. Para el caso de que queramos utilizar estos casos de uso ms pequeos, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: Incluye (<>): Un caso de uso base incorpora explcitamente a otro

caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial comn a varios casos de uso. En la Figura 16 se muestra cmo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorizacin.

Figura 16 - Ejemplo de Relacin <> Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de extensin) en los cuales, dependiendo de ciertos criterios, se va a realizar una interaccin adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relacin incluye que se da siempre que se realiza la interaccin descrita) En la Figura 17 se muestra como el caso de uso Comprar Producto permite explicitamente extensiones en el siguiente punto de extensin: info regalo. La interaccin correspondiente a establecer los detalles sobre un producto que se enva como regalo estn descritos en el caso de uso Detalles Regalo.

Figura 17 - Ejemplo de Relacin <> Ambos tipos de relacin se representan como una dependencia etiquetada con el estereotipo correspondiente (<> o <>), de tal forma que la flecha indique el sentido en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede detallar el/los puntos de extensin del caso de uso base en los que se aplica la extensin. Generalizacin ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso ms especfico. Se representa por una lnea continua entre los dos casos de uso, con el tringulo que simboliza generalizacin en UML (usado tambin para denotar la herencia entre clases) pegado al extremo del caso de uso ms general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y caractersticas del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no est definido completamente. Este tipo de relacin se utiliza mucho menos que las dos anteriores.
http://www.clikear.com/manuales/uml/diagramascasouso.asp

4.3 Diseo de interfaz de usuario.

Prlogo General Los Avances de la Ciencia y la Tecnologa han puesto al hombre en un plano intermedio entre lo tangible e intangible computacionalmente hablando, es ahora tan comn el convivir con un computador diariamente que cada vez se hace ms imperativo la mejor interaccin hombremquina a travs de una adecuada interfaz (Interfaz de Usuario), que le brinde tanto comodidad ,como eficiencia. El presente trabajo es una introduccin al mundo de las Interfaz de Usuarios, en el estn los conceptos y nociones bsicas que permitirn en adelante adentrarnos ms en este 2. Conceptos de interfaz Lewis y Rieman [1993] definen las interfaces hombre computadora como: Las interfaces bsicas de usuario son aquellas que incluyen cosas como mens, ventanas, teclado, ratn, los "beeps" y algunos otros sonidos que la computadora hace, en general, todos aquellos canales por los cuales se permite la comunicacin entre el hombre y la computadora. La idea fundamental en el concepto de interfaz es el de mediacin, entre hombre y mquina. La interfaz es lo que "media", lo que facilita la comunicacin, la interaccin, entre dos sistemas de diferente naturaleza, tpicamente el ser humano y una mquina como el computador. Esto implica, adems, que se trata de un sistema de traduccin, ya que los dos "hablan" lenguajes diferentes: verbo-icnico en el caso del hombre y binario en el caso del procesador electrnico. De una manera ms tcnica se define a Interfaz de usuario, como conjunto de componentes empleados por los usuarios para comunicarse con las computadoras. El usuario dirige el funcionamiento de la mquina mediante instrucciones, denominadas genricamente entradas. Las entradas se introducen mediante diversos dispositivos, por ejemplo un teclado, y se convierten en seales electrnicas que pueden ser procesadas por la computadora. Estas seales se transmiten a travs de circuitos conocidos como bus, y son coordinadas y controladas por la unidad de proceso central y por un soporte lgico conocido como sistema operativo. Una vez que la UPC ha ejecutado las instrucciones indicadas por el usuario, puede comunicar los resultados mediante seales electrnicas, o salidas, que se transmiten por el bus a uno o ms dispositivos de salida, por ejemplo una impresora o un monitor. Resumiendo entonces podemos decir que, una interfaz de software es la parte de una aplicacin que el usuario ve y con la cual interacta. Est relacionada con la subyacente estructura, la arquitectura, y el cdigo que hace el trabajo del software, pero no se confunde con ellos. La interfaz incluye las pantallas, ventanas, controles, mens, metforas, la ayuda en lnea, la documentacin y el entrenamiento. Cualquier cosa que el usuario ve y con lo cual interacta es parte de la interfaz. Una interfaz inteligente es fcil de aprender y usar. Permite a los usuarios hacer su trabajo o desempear una tarea en la manera que hace ms sentido para ellos, en vez de tener que ajustarse al software. Una interfaz inteligente se disea especficamente para la gente que la usar. 3. Clasificacin Dentro de las Interfaces de Usuario se distinguir bsicamente dos tipos : Una interfaz de hardware, a nivel de los dispositivos utilizados para ingresar, procesar y entregar los datos: teclado, ratn y pantalla visualizadora; y Una interfaz de software, destinada a entregar informacin acerca de los procesos y herramientas de control, a travs de lo que el usuario observa habitualmente en la pantalla.

De esta clasificacin general se puede ir desprendiendo algunas, as por ejemplo segn su evolucin tenemos: La evolucin de las interfaces de usuario corre en paralelo con la de los sistemas operativos; de hecho, la interfaz constituye actualmente uno de los principales elementos de un sistema operativo. A continuacin se muestran las distintas interfaces que histricamente han ido apareciendo, ejemplificndolas con las sucesivas versiones de los sistemas operativos ms populares. Interfaces de lnea de mandatos (command-line user interfaces, CUIs). Es el caracterstico del DOS, el sistema operativo de los primeros PC, y es el estilo ms antiguo de interaccin hombre-mquina. El usuario escribe rdenes utilizando un lenguaje formal con un vocabulario y una sintaxis propia (los mandatos en el caso del DOS). Se usa un teclado, tpicamente, y las rdenes estn encaminadas a realizar una accin. El usuario no suele recibir mucha informacin por parte del sistema (ejemplo: indicador del DOS), y debe conocer cmo funciona el ordenador y dnde estn los programas (nada est oculto al usuario). El modelo de la interfaz es el del programador, no el del usuario. Ejemplo del DIR-DELDIR, por la falta de informacin de respuesta del DOS. Otras veces, en cambio, es excesiva: etiqueta del volumen en el DIR. Inconveniente: carga de memoria del usuario (debe memorizar los mandatos; incluso la ayuda es difcil de leer); nombres no siempre adecuados a las funciones, significado de los mandatos mal comprendido a veces (varios mandatos con el mismo o parecido significado, como DEL y ERASE); inflexible en los nombres (DEL y no DELETE). Ventajas: potente, flexible y controlado por el usuario, aunque esto es una ventaja para usuarios experimentados. La sintaxis es estricta, y los errores pueden ser graves As: C:\TMP\>dir El volumen en unidad C es PCDOS_6 Nmero de Serie del Volumen es 1D8F82B0 Directorio de C:\TMP . <DIR> 02-02-98 21:08 .. <DIR> 02-02-98 21:08 ABCD <DIR> 02-02-98 21:23 CARTA DOC 1.107 22-10-96 9:51 4 archivo(s) 1.107 bytes 24.862.720 bytes libres

C:\TMP\> Problema del mandato COPY En suma, un CUI es adecuado para usuarios expertos, no para noveles. Para aquellos resultan ms rpidos, por lo que se puede disear un CUI como parte de una interfaz, para que se pueda utilizar una vez que se tenga experiencia. Interfaces de mens. Un men es una lista de opciones que se muestran en la pantalla o en una ventana de la pantalla para que los usuarios elijan la opcin que deseen (vase ejemplo). Los mens permiten dos cosas: navegar dentro de un sistema, presentando rutas que llevan de un sitio a otro, y seleccionar elementos de una lista, que representan propiedades o acciones que los usuarios desean realizar sobre algn objeto. Las interfaces de mens aparecen cuando el ordenador se vuelve una herramienta de usuario y no slo de programadores. Las actuales interfaces grficas u orientadas a objetos siguen utilizando este tipo de interfaces (los distintos estilos de interfaces no son mutuamente exclusivos). Existen distintos tipos de mens. Los primeros fueron los mens de pantalla completa, estructurados jerrquicamente Men de pantalla completa (Norton Utilities) Los mens de barra, situados en la parte superior de la pantalla, son profusamente utilizados en las aplicaciones actuales. Contienen una lista de acciones genricas que dan paso a mens desplegables donde se concretan. Men de barra y men desplegable Estos mens pueden llevar a su vez a otros: son los mens en cascada. Pueden cambiar dinmicamente, y deshabilitar opciones que no estn disponibles en un momento dado (marcndolas habitualmente en gris).

Mens en cascada de la barra de inicio de Windows 95

Las paletas o barras de herramientas son mens grficos con acciones, herramientas y opciones que se pueden colocar en la pantalla. Se utilizan mucho en programas grficos. Paletas de herramientas en Microsoft Powerpoint Los mens contextuales o mens pop-up son los ms recientes. Se llaman as porque el contenido del men depende del contexto de trabajo del usuario. Contienen nicamente las opciones que son aplicables al objeto seleccionado, ms algunas de uso frecuente que tambin son accesibles desde el men de barra. Men contextual de un icono en el escritorio de Windows 95 Las interfaces de mens, bien estructuradas, son buenas para usuarios noveles o espordicos. Son fciles de aprender y de recordar. Pueden existir mens simples y avanzados, para adaptarse al tipo de usuario. Precauciones: no ocupar demasiado espacio de la pantalla, recordar la informacin acumulada de mens precedentes, no colocar demasiados elementos en el men, agruparlos de manera lgica (no en orden alfabtico, por ejemplo; esto ayuda a recordarlos), permitir la personalizacin por parte del usuario, usar una terminologa adecuada y consistente dentro del programa y con otros programas (Exit, Quit, Escape, Close, Return, Back). Las interfaces de mens sern utilizadas normalmente en conjuncin con los otros estilos de interfaces. Interfaces grficas (graphical user interfaces, GUIs). Desarrolladas originalmente por XEROX (sistema Xerox Star, 1981, sin xito comercial), aunque popularizadas por Apple (Steven Jobs se inspir en los trabajos de Xerox y cre el Apple Lisa, 1983, sin xito, y Apple Macintosh, 1984, con xito debido en gran medida a su campaa publicitaria) Los tres estilos ms comunes de interfaces grficas hombre-computadora son: Lo que t ves es lo que puedes conseguir (WYSIWYG What you see is what you get), Manipulacin directa e Interfaces de usuario basados en iconos.

Un GUI es una representacin grfica en la pantalla del ordenador de los programas, datos y objetos, as como de la interaccin con ellos. Un GUI proporciona al usuario las herramientas para realizar sus operaciones, ms que una lista de las posibles operaciones que el ordenador es capaz de hacer. 4. Caractersticas de un GUI

1. Posee un monitor grfico de alta resolucin.

1. Posee un dispositivo apuntador (tpicamente un ratn). 1. Promueve la consistencia de la interfaz entre programas. 1. Los usuarios pueden ver en la pantalla los grficos y textos tal como se vern impresos.

1. Sigue el paradigma de la interaccin objeto-accin.

1. Permite la transferencia de informacin entre programas. 1. Se puede manipular en la pantalla directamente los objetos y la informacin. 1. Provee elementos de interfaz estndar como mens y dilogos.

1. Existe una muestra visual de la informacin y los objetos (iconos y ventanas).

1. Proporciona respuesta visual a las acciones del usuario. 1. Existe informacin visual de las acciones y modos del usuario/sistema (mens, paletas).

1. Existen controles grficos (widgets) para la seleccin e introduccin de la

informacin. 1. Permite a los usuarios personalizar la interfaz y las interacciones.

1. Proporciona flexibilidad en el uso de dispositivos de entrada (teclado/ratn).

Una caracterstica importante es que el GUI permite manipular los objetos e informacin de la pantalla, no slo presentarla. Para usar un GUI, los usuarios deben conocer (o aprender) una serie de conceptos: organizacin del sistema (ficheros, directorios en Win95), diferentes tipos de iconos y efecto de las acciones sobre ellos, elementos bsicos de una ventana, uso de los controles del GUI, uso del ratn. Los GUI usan el estilo objeto-accin, en contraposicin al accin-objeto de los CUI o las interfaces de men. El usuario selecciona un objeto, y despus la accin a realizar sobre dicho objeto. Los objetos son el principal foco de atencin del usuario, lo cual resulta ms natural y prximo a su modelo mental. Metfora de la cmara Interfaces orientadas a objetos (object oriented user interfaces, OOUIs). Su aspecto es similar al de las GUIs. La diferencia estriba en el modelo subyacente: las GUIs son interfaces orientadas a la aplicacin, mientras que las OOUIs estn orientadas al objeto. La tabla siguiente muestra las principales diferencias entre ambos estilos de interfaz: Interfaces orientadas a la aplicacin La aplicacin consiste en un icono, una ventana principal y varias secundarias Los iconos representan aplicaciones o ventanas abiertas Los usuarios deben abrir una aplicacin antes de trabajar con objetos Interfaces orientadas a objetos El producto consiste en una coleccin de objetos que cooperan y vistas de dichos objetos Los iconos representan objetos que se pueden manipular directamente Los usuarios abren objetos como vistas en el escritorio

Proporciona al usuario las funciones necesarias para realizar las tareas Se centra en la tarea principal determinada por la aplicacin Las tareas relacionadas son soportadas por otras aplicaciones Estructura rgida: funcin

Proporciona al usuario los materiales necesarios para realizar las tareas Se centra en las entradas y salidas de los objetos y tareas Las tareas relacionadas son soportadas por el uso de otros objetos Estructura flexible: objeto

Los usuarios pueden quedar atrapados Los usuarios no deben quedar atrapados en una en una tarea tarea Los usuarios deben seguir la estructura de la aplicacin Se requieren muchas aplicaciones: una por tarea Los usuarios pueden realizar tareas a su propio gusto Se requieren pocos objetos, que se reutilizan en muchas tareas

El objetivo de la OOUI es que el usuario se concentre en sus tareas en lugar de en el ordenador y cmo utilizar las aplicaciones y ficheros necesarios para cumplir sus objetivos. Por ello se esconde la organizacin del sistema al usuario (Ejemplo de los accesos directos en Windows95-OS/2). El estilo de interaccin de los OOUIs es el de objeto-accin (tambin se da en los GUIs, aunque mezclado con el estilo accin-objeto). La ventana es un objeto ventana, no una ventana de aplicacin; desaparecen pues los mens de barra y ganan terreno los contextuales. Los objetos se pueden clasificar en tres categoras: datos, contenedores y dispositivos. Sobre ellos se definen distintas vistas (por ejemplo, la ayuda constituye una vista del objeto). Definir los objetos y las vistas es lo ms complicado del diseo de la interfaz. El objeto debe ser familiar al usuario (encajar con su modelo mental, apoyado en su vida diaria), y estar relacionado con el mundo real: uso de las metforas. Distintas vistas del objeto reloj Un ejemplo de lo que se pretende con una interfaz OOUI es el considerar un documento como un objeto sobre el cual realizar tareas tales como incorporar grficos y textos, sin necesidad de usar programas distintos para cada una de ellas. Estos programas suelen tener funciones que se solapan, con el consiguiente gasto extra en espacio y dinero. Actualmente existe una mezcla de productos orientados a la aplicacin y al objeto, aunque se est produciendo una migracin a estos ltimos. Las aplicaciones estn dejando paso a conjuntos de objetos. 5. Caractersticas humanas del diseo de interfaz Factores Humanos Al disear interfaces de usuario deben tenerse en cuenta las habilidades cognitivas y de percepcin de las personas, y adaptar el programa a ellas. As, una de las cosas ms importantes que una interfaz puede hacer es reducir la dependencia de las personas de su propia memoria, no forzndoles a recordar cosas innecesariamente (por

ejemplo, informacin que apareci en una pantalla anterior) o a repetir operaciones ya realizadas (por ejemplo, introducir un mismo dato repetidas veces). La persona tiene unas habilidades distintas de la mquina, y sta debe utilizar las suyas para soslayar las de aquella (como por ejemplo la escasa capacidad de la memoria de corto alcance). Velocidad de Aprendizaje.- Se pretende que la persona aprenda a usar el sistema lo ms pronto posible. Velocidad de Respuesta.- El tiempo necesario para realizar una operacin en el sistema. Tasa de errores.- Porcentaje de errores que comete el usuario. Retencin.- Cunto recuerda el usuario sobre el uso del sistema en un perodo. de tiempo. Satisfaccin.- Se refiere a que el usuario est a gusto con el sistema.

Adems de stos existen otros a considerar: Adecuacin Caractersticas Fsicas.- Cada persona tiene diferentes caractersticas fsicas. Hay algunas personas que no les gustan los teclados mientras que a otras s. Es por eso que hay teclados ergonmicos. Lo mismo sucede con el mouse. Ambiente.- El lugar donde va a ser usado el sistema. Cada interfaz tiene que adecuarse al lugar. Visibilidad.- Tomar en cuenta la cantidad de iluminacin del lugar. Se refleja el brillo en la pantalla? Personalidad.- De acuerdo a la edad, nivel socio-econmico, etc. Cultura.- Los japoneses no tienen las mismas pantallas, ventanas, etc. Este factor es importante si el mercado para el sistema es a nivel internacional.

Segn la funcin tenemos: Motivacin Sistemas Vitales.- Son de vida o muerte; muchas personas dependen de ellos. Ejemplo: un sistema para reactores nucleares. Este sistema trabaja en tiempo real, y es de suma importancia la seguridad y efectividad del mismo. Sistemas Comerciales e Industriales.- Sirven para aumentar la productividad y vender ms. Sistemas de Oficina, Hogar y Juegos.- Factor importante: el mercado a quien est dirigido; tienen que ser muy amigables y satisfacer al cliente. Sistemas de Investigacin.- Realizan tareas muy especficas y tratan de imitar el medio en el que se desenvuelve el usuario.

6. Pasos para el diseo de interfaz Pasos Clsicos En el proceso de diseo de una interfaz de usuario se pueden distinguir cuatro fases o pasos fundamentales: 1. 2. 3. 4. Reunir y analizar la informacin del usuario Disear la interfaz de usuario Construir la interfaz de usuario Validar la interfaz de usuario

Reunir y analizar la informacin del usuario: Es decir concretar a travs de tcnicas de requerimentacin, qu tipo de usuarios van a utilizar el programa, qu tareas van a realizar los usuarios y cmo las van a realizar, qu exigen los usuarios del programa, en qu entorno se desenvuelven los usuarios (fsico, social, cultural). Disear la interfaz de usuario. Es importante dedicar tiempo y recursos a esta fase, antes de entrar en la codificacin. En esta fase se definen los objetivos de usabilidad del programa, las tareas del usuario, los objetos y acciones de la interfaz, los iconos, vistas y representaciones visuales de los objetos, los mens de los objetos y ventanas. Todos los elementos visuales se pueden hacer primero a mano y luego refinar con las herramientas adecuadas. Construir la interfaz de usuario. Es interesante realizar un prototipo previo, una primera versin del programa que se realice rpidamente y permita visualizar el producto para poderlo probar antes de codificarlo definitivamente Validar la interfaz de usuario. Se deben realizar pruebas de usabilidad del producto, a ser posible con los propios usuarios finales del mismo. Es importante, en suma, realizar un diseo que parta del usuario, y no del sistema. Existen 11 pasos en el proceso de diseo "centrado en las tareas", similar al anterior pero que desglosa algunas actividades implcitas en otras, as: 1.- Entender quien usar el sistema para hacer qu. 2.- Elegir tareas representativas para el diseo. 3.- Plagiar o copiar. 4.- Bosquejar un diseo. 5.- Pensar acerca del diseo. 6.- Crear un prototipo. 7.- Evaluarla con los usuarios. 8.- Repetir. 9.- Construirla. 10.- Rastrearla. 11.- Cambiarla.

Tcnicas y pasos avanzadas para el diseo de interfaces de usuario Presentacin de informacin: No se deben colocar demasiados objetos en la pantalla, y los que existen deben estar bien distribuidos. Cada elemento visual influye en el usuario no slo por s mismo, sino tambin por su combinacin con el resto de elementos presentes en la pantalla. El nmero de elementos visuales que perciben son: en el caso a) 1 (el fondo); en b) 3 (la lnea, lo que est encima y lo que est debajo); en c) son 5 (el espacio fuera del recuadro, el recuadro, la lnea y el espacio encima y debajo de sta); finalmente, en d) el nmero se eleva a 35, siguiendo el mismo criterio. Conclusin: cada elemento nuevo que se aade influye ms de lo que se piensa en el usuario. Elementos de diseo de pantalla y su percepcin visual Anlisis de Color: es probablemente el elemento de la interfaz que con ms frecuencia es mal utilizado. El color comunica informacin, no es slo decorativo (ejemplo: reforzar mensajes de error). Deben utilizarse combinaciones adecuadas (por ejemplo, las paletas proporcionadas por los sistemas operativos). El color debe atraer la atencin, pero no cansar despus de un rato de trabajo. Es especialmente importante seguir las lneas de diseo existentes. Principio bsico: disear primero en blanco y negro, y luego aadir el color. Anlisis Audio. Primero es preciso ver cundo es ms apropiado que la informacin visual. Segundo, determinar el sonido adecuado. Tercero, permitir la personalizacin (volumen y desactivacin). Como en el caso de los colores existen guas de uso. En lugares de trabajo abiertos, puede ser poco efectivo; adems, puede ser embarazoso para algunas personas. El sonido debe usarse para informar, no cuando no aade nada nuevo (por ejemplo, un mensaje de aviso de correo o de bienvenida, respectivamente, al iniciar una sesin de trabajo). Anlisis Animacin. Se define como un cambio en el tiempo de la apariencia visual de un elemento grfico. Ejemplos de su uso: progreso de acciones (copia de ficheros en Windows 95, instalacin de programas), estado de procesos (iconos de impresora), acciones posibles (cambios en el cursor al desplazar el ratn). La animacin puede ayudar a subrayar iconos importantes, mostrar el estado de un objeto particular o explicar su comportamiento. Diseo internacional. Debe hacerse un uso adecuado de la terminologa. Hay mucho trabajo en este campo. Debe tenerse cuidado con las diferencias culturales (gestos, terminologa, dibujos, formatos de telfonos o calendarios, etc.). Anlisis y Eleccin de controles. Muchas veces existe la duda de qu controles utilizar. En realidad no existe una nica forma correcta. Un aspecto a considerar es la escalabilidad (men de 10/1000 elementos; ejemplo: programas del men inicio de Windows 95). Ejemplo de alternativas: usar un men de barra o de paleta, permitir arrastrar objetos o no (problema: no existe indicacin visual de que se pueda arrastrar el objeto: qu objetos se pueden arrastrar? a dnde se pueden arrastrar? qu ocurrir cuando lleguen all? se podr deshacer la accin?). Diferentes controles para los mismos datos Guas de Expertos

Existen diversas guas de diseo sacadas de expertos y comits, que complementan a las reglas de oro estudiadas anteriormente. Por citar algunas de ellas: Demasiada simetra puede hacer las pantallas difciles de leer. Si se ponen objetos sin alinear, hacerlo drsticamente. Asimetra=activo, simetra=sereno. Elementos de tamao y color similares se perciben como pertenecientes a un grupo. Asumir errores en la entrada del usuario. Disear para el usuario, no para demostrar los propios conocimientos tecnolgicos. Unos grficos espectaculares no salvarn a una mala interfaz.

7. Conclusiones Y Recomendaciones El conocimiento de estos puntos clave, nos permitirn enfocarnos mejor al estudio de la materia. Las Interfaces de usuario, como vnculo de inmersin del hombre en el entorno de trabajo tecnolgico actual, realzan su importancia en el desarrollo de nuevos productos, ms eficaces, eficientes e interactivos, que es lo que el mercado demanda. Puntos, cmo los histricos y evolutivos, deben ser abordados de manera ms investigativa, recordemos que "conocer el pasado nos proyecta al futuro". Otras puntualizaciones de clasificacin obligarn a que investiguemos y propongamos, nuevas distribuciones clasificatorias, tiles a futuro en una carrera de desarrollo de software.

Fuente: Enciclopedia Encarta 99, Interfaz de Usuario Enciclopedia del Estudiante, LARPRESS 99,Interfaz Hombre-Mquina. Instituto Tcnico Superior Mxico, curso de interfaz de Usuario: http://webdia.cem.itesm.mx/ac/rtrejo/Interfaz/index.html http://www.bayesinf.com/spanish/product/forphone/help/4inteelem/contens.htm Universidad Autnoma de Guadalajara, Tutorial "Diseo de una Interfaz Grfica": http://www.uag.mx/66/proceso1.htm SIGGRAPH de Mxico: http://groucho.siggraph.org.mx/boletin/Ene99/index.htm LINEBACK, Graphical User Interface Timeline: http://pla-netx.com/linebackn/guis/guitimeline.html COMUNICACIN HOMBRE MQUINA, http://www.lsi.us.es/docencia/asignaturas/dihm/tema1/tema1.html

Trabajo recopilado y realizado por: Carlos Aimacaa Toledo mitaly_ceat@latinmail.com mitaly2000@magosoftec.intranets.com

http://www.monografias.com/trabajos6/inus/inus.shtml

Proceso de diseo del Interfaz de Usuario

Proceso de diseo del Interfaz de Usuario

En el site (al igual que en otros especializados) se encuentra diverso material sobre qu funciona y qu no en sitios Web, qu factores mejoran la experiencia del usuario en un site o las tcnicas de evaluacin o testing de usabilidad que nos permitan tener datos reales del futuro xito de la implementacin. En esta seccin vamos a plasmar una metodologa de trabajo para el ciclo de vida completo, desde la concepcin hasta las pruebas finales y puesta en produccin de un sitio Web, que nos garantice mximos niveles de usabilidad del producto final. Fase de Anlisis:

Visin estratgica del site Estudios de campo Escenarios de usuario

Usabilidad en el proyecto Seleccin de productos Operativa de usuario

Equipo multidisciplinar Perfiles de usuario

Objetivos de Usabilidad Anlisis de tareas

Reuniones con responsables para establecer una visin clara del site a disear Inclusin de tareas relativas a usabilidad en el plan del proyecto Reunir un equipo multidisciplinar para asegurar un conocimiento global Establecer objetivos de usabilidad Organizar estudios de campo Bsqueda de productos competitivos Crear perfiles de usuario Desarrollar un anlisis de tareas Describir y documentar los escenarios de usuario Describir y documentar los requerimientos de operativa de usuario Fase de Diseo:

Diseo concept. / metforas Diseo lpiz y papel Test "highfidelity"

Flujo pantallas / modelo naveg. Elaborar "lowfidelity" Documentar estndares

Revisiones de diseo Test "lowfidelity" Crear especific. diseo

Revisiones conceptos diseo Elaborar "highfidelity"

Brainstormings: diseo de conceptos y metforas Desarrollo del flujo de pantallas y el modelo de navegacin Realizar revisiones de conceptos de diseo Diseo con papel y lpiz Elaborar prototipos "low-fidelity" Organizar tests de usabilidad sobre los prototipos "low-fidelity"

Elaborar prototipos detallados "high-fidelity" Organizar tests de usabilidad sobre los prototipos "high-fidelity" Documentacin de estndares y directrices Elaboracin de una especificacin de diseo

Fase de Implementacin:

Evaluaciones heursticas

Cooperacin responsables entregas

Tests de usabilidad: postentregas

Realizacin de evaluaciones heursticas en curso Trabajar al lado de los responsables finales de la entrega segn se va implementando el diseo Organizar tests de usabilidad inmediatamente a las entregas Fase de Desarrollo:

Encuestas a usuarios: feedback

Pruebas de uso real

Tests de usabilidad: cumplimiento objetivos

Realizar encuestas para obtener feedback de los usuarios Organizar estudios de campo para obtener informacin de cmo se est usando Comprobar objetivos mediante tests de usabilidad

Autor: WebUsable
http://www.webusable.com/useProcess.htm

4.3.1 Reglas en el diseo de interfaz de usuario.

TEORIA DEL INTERFAZ 1.- INTERACCIN HOMBRE-MQUINA La interaccin hombre-mquina ayuda a entender cmo la gente interacta con la nuevas tecnologas. Adems, esta interaccin puede ayudar a mejorar las posibilidades de las nuevas tecnologas en la enseanza en dos importantes aspectos: primero, puede guiar un anlisis cuidadoso y sistemtico sobre qu informacin, herramientas y capacidades necesita la gente para conseguir sus objetivos; y segundo, puede proporcionar herramientas y tcnicas con las que evaluar tilmente en el esfuerzo por quitar defectos que estorban en una interaccin tranquila entre la gente y las nuevas tecnologas. Es decir, es necesario que se profundice en los factores que dificultan esta interaccin. Este tipo de investigacin permitir la generacin de guas para el diseo del interfaz de los usuarios de ordenador. En los ltimos aos, se ha ido incrementando el inters en el estudio de los usuarios como parte del sistema hombre-mquina. No obstante, la mayora de los estudios han sido dirigidos hacia los usuarios con experiencia con el ordenador, o ms especficamente a programadores. Slo algunos de los ms recientes estudios se ocupan ms especficamente de los usuarios casuales o principiantes. Los usuarios principiantes y experimentados generalmente manifiestan maneras de comportamiento bastante diferentes. Los principiantes normalmente se dedican a actividades de resolver problemas, mientras que los experimentados son hbiles en la interaccin con el ordenador. La interaccin es para el usuario experto una destreza cognitiva de rutina. Adems, junto al nivel de experiencia del usuario es necesario atender a los estilos de aprendizaje. 2.- EVOLUCIN DE LA INTERACCIN A pesar de que es dificultoso redactar a la vez una amplia cadena de investigaciones, la siguiente tentativa general referente a la interaccin hombre-mquina indica que:

1. Ha habido un gran incremento en la cantidad de investigaciones de interaccin hombre-mquina desde la pasada dcada. 2. Va tomando importancia el papel del usuario. 3. Mientras que los usuarios son una parte integrante de la interaccin hombre-mquina, las investigaciones hasta ahora se han concentrado primariamente sobre programadores a costa de los usuarios principiantes.

4. Las dificultades individuales entre los usuarios no han sido remarcadas.

5. Muchas pequeas investigaciones han remarcado el proceso cognitivo de los usuarios (programadores y no programadores) como su interaccin con los sistemas del ordenador. 3.- INTERFAZ Un ordenador ayudado de un sistema de informacin consiste en tres principales componentes: hardware, software y usuario. La interaccin de estos componentes es una de las ms importantes partes del sistema: el interfaz hombre-mquina.

El campo de interaccin hombre-mquina se concibe con el diseo del interfaz y es altamente interdisciplinar por naturaleza. Esto supone investigaciones desde la Psicologa, la Informtica, la Ingeniera, la Educacin y las Comunicaciones. El interfaz hombre-mquina es un canal comunicativo entre el usuario y el ordenador. Un asunto central de la investigacin interaccin hombre-mquina es determinar los efectos humanos, tanto psicolgicos como cognitivos, y las caractersticas afectivas de las interacciones entre los usuarios y los ordenadores en tareas especficas. De esta manera, los investigadores de la interaccin hombre-mquina desarrollan modelos de actividades humanas y uso de estos modelos en el diseo de nuevos interfaces. La produccin, distribucin y administracin de la informacin se han convertido en las actividades principales de los conocimientos modernos en los que se basa la sociedad. De esta manera, el interfaz entre humanos y las nuevas tecnologas ser continuamente mejorado en funcin de realizar el ideal de comunicacin humana mundial. Los humanos quieren que expresiones como el dilogo, gestos o escribir a mquina sean entendidos inmediatamente por los ordenadores y otros sistemas de informacin. El "paradigma de la persona entera" y de "la red hombre-mquina" son los puntos culminantes en el mundo futuro de la comunicacin. La comunicacin humana incluye no slo pequeos trozos de informacin sino tambin intuicin, sentimientos y emociones. El mundo futuro de la comunicacin es a veces llamado "pueblo global" para enfatizar el grado de familiaridad creado por el ambiente de alta tecnologa. Tenemos que considerar un nuevo tipo de complejidad, referida a la emocin y intuicin del hombre. Hasta el proceso de investigacin cientfica est inspirado en la

intuicin humana y conducida por las emociones humanas y esto tiene que ser considerado en el mundo futuro de la comunicacin. Basndose en el anlisis de las necesidades del usuario, el diseador de sistemas de informacin y educacin tendr que seleccionar y integrar datos dentro de la representacin informativa del particular dominio trabajo/ocio en el ms alto de los niveles conceptuales, mientras que la visualizacin del formato ser desarrollada desde hiptesis sobre la naturaleza de los modelos mentales y estrategias ocasionados, por el trabajo del usuario. 3.1. Principios para el diseo El modelo de procesamiento de informacin que prevalece en la Psicologa ha permitido los siguientes principios de diseo:

1. El interfaz tendra que compensar las limitaciones humanas, tanto fsicas como cognitivas, siempre que sea posible. No obstante, tendra que ser "transparente", no ponerse en el camino de las acciones del usuario o impedir su progreso. Por otra parte, el interfaz no tendra que sobrecargar al usuario con complejidades innecesarias o distraerlo de su labor. 2. Los componentes fsicos del interfaz tendran que ser diseados ergonmicamente, teniendo presente el confort y la salud del usuario tanto como sus necesidades. 3. El interfaz tendra que ser consistente. 4. El estilo de interaccin no mandado como manipulacin directa y mens son preferibles al lenguaje de orden. Como mnimo, el usuario experimentado tendra que tener capacidad de moverse rpidamente a travs de las capas de los mens. 5. El interfaz tendra de poder tener acciones reversibles. 6. El interfaz tendra que estar sujeto a pruebas al principio del diseo del proceso y durante su desarrollo.
El principio ms bsico del interfaz sera estar diseado alrededor de las necesidades del usuario hasta despus de que el sistema haya sido completado, atendindose de esta manera las restricciones impuestas por el sistema. 3.2. Tendencias en el diseo Los sistemas de ordenador son cada vez ms interactivos y esta tendencia continuar a medida que los nuevos interfaces se desarrollen. La interactividad ser apoyada por los nuevos recursos de imput y output que llevan muchas ventajas a la utilizacin de los canales humanos de comunicacin. El interfaz acepta voz y gestos al mismo tiempo que da ms control a los usuarios que se han de mover a la vez que controlan sistemas y hacen posible una variedad de aplicaciones virtuales reales.

En referencia a las ventajas de los componentes fsicos del interfaz, hay una investigacin activa en componentes conceptuales parecida a los estilos de interaccin. La directa manipulacin de interfaces continuar emergiendo y una ms fuerte adaptacin al sistema ser desarrollada de acuerdo al tipo de tarea y el nivel de experiencia del usuario. Agentes inteligentes son tambin desarrollados por debajo. Los agentes pueden asignar tareas especficas para el usuario y despus enviarlos a que ejecuten estas tareas. 4. ESTILOS DE APRENDIZAJE Se necesita investigar sobre los alumnos y sus caractersticas para poder determinar qu tipo de enseanza es la mejor para cada tipo de alumno en cada tipo de ambiente. En el diseo de material multimedia interactivo, una experiencia de aprendizaje es ms rica cuando hay diferentes formas de enseanza para las diferentes formas de aprendizaje de los alumnos. Todo el proceso de aprendizaje es ms eficiente si los alumnos pueden determinar su propio camino, seleccionando la informacin disponible para ellos, del modo ms conveniente para su propio estilo de aprendizaje. Cuatro tipos de estilos de aprendizaje han sido identificados:

a. Tipo "asimilador", que utiliza razonamientos inductivos y formaciones tericas. b. Tipo "acomodador", que se fa de juicios intuitivos y aproximaciones errneas para resolver problemas y se adapta a situaciones novedosas. c. Tipo "divergente", que contempla un problema desde mltiples perspectivas y tiene unos amplios intereses culturales. d. Tipo "convergente", que utiliza el sentido comn para resolver problemas. Esta perspectiva de aprendizaje puede ser importada en el diseo de currculum multimedia porque muchas de las diferentes reglas en la produccin de multimedia reflejan varios tipos de aprendices. Y si un estilo de aprendizaje encaja con un papel apropiado de produccin entonces podra darse un mejor aprendizaje y produccin.
5. PAPEL DEL DISEO EDUCATIVO EN LOS ORDENADORES Ya anteriormente, el papel del diseo instruccional en ordenadores fue apoyado por Gagn (1982). l argumentaba que diseadores educativos y programadores de ordenadores trabajasen juntos para producir ordenadores basados en materiales que tuviesen ventajas para las caractersticas particulares del ordenador. Tambin observ que este proceso ha sido impedido por el factor comercial: parece que los programadores pueden crear software que venden sin considerar los principios del diseo educativo. Uno de los ms importantes factores que los diseadores educativos pueden aportar a los ordenadores es el conocimiento de la relacin materiales y cognicin del usuario. Entre estos podemos destacar a:

 Hale (1981), que observ que un tema persistente de estudios era la necesidad para continuar dando apoyo a los estudios de los factores humanos tratando con la interaccin hombre-ordenador. Kearsley y Hillelsohn (1982), exigan una metodologa sistemtica para el proceso comprometiendo a los usuarios en el diseo y la implementacin de los ordenadores en sistemas formativos. Baker (1982), que reclamaba el desarrollo de una variedad de tcnicas de interaccin que permitiese a los usuarios seleccionar las formas de interaccin que ms conveniese a sus intereses. Stewart (1980) fue el ms especfico, argumentando a favor del control de un nmero de directrices para la interaccin hombre-mquina. Estas metas para el diseo de sistemas interactivos proporcionan un til grupo de directrices para los diseadores de materiales de enseanza asistida por ordenador. No obstante, el trmino "usuario" necesita ser especificado con ms conocimiento de las diferencias individuales entre usuarios. 6. FACTORES QUE INFLUYEN EN LOS PROCESOS COGNITIVOS Los diseadores educativos tendran que tener presente:

1. Caractersticas del usuario: ser conscientes de los probables usuarios de la poblacin, y adems, de sus diferencias en los procesos cognitivos. 2. Simplicidad: la nocin de simplicidad requiere especificacin. Lo que es simple para unos usuarios no tiene porque serlo para otros. 3. Flexibilidad: aparentemente los materiales de la enseanza asistida por ordenador necesitan ser flexibles en la mayora de caminos, para as mantener una amplia variedad de imput de usuario para capturar los pensamientos del usuario. 4. El control y feedback del usuario: si los diseadores de materiales multimedia trabajan con conocimiento de los caminos en los cuales los usuarios interactan con los ordenadores, significa que aumentar el control del usuario sobre el aprendizaje a seguir. Un posible camino de promover el control del usuario es el uso de un feedback efectivo y apropiado. 5. Mensajes de error: a pesar de que es aparente que el mensaje de error podra ser correcto, significativo y informativo, se requieren investigaciones para averiguar que significan estos trminos para el usuario. 6. El formato de los materiales: como en otras reas de diseo educativo, son requeridas investigaciones sobre la eficacia

de los variados formatos de materiales multimedia de diferentes tipos de usuarios de ordenador.

7. APRENDIZAJE SITUADO El aprendizaje situado es un aprendizaje de conocimiento y habilidades en el contexto que se aplica a situaciones cotidianas reales. El uso de multimedia en educacin es una tendencia muy popular en educacin. En los ltimos aos ha aparecido la utilizacin de los multimedia tanto por parte de los tutores como de los alumnos. El aprendizaje situado es:

1. Un aprendizaje social ms que un aprendizaje individual. 2. Un aprendizaje basado en herramientas ms que un aprendizaje independiente de herramientas. 3. Un aprendizaje ocupado en los objetos ms que un aprendizaje dependiente de smbolos. 4. Un aprendizaje basado en una situacin especfica ms que un aprendizaje terico.
Cul es el proceso? El aprendizaje situado tiene lugar en y a travs de la interaccin con otros en un contexto de resolucin de problemas que es autntico ms que descontextualizado. El aprendizaje se produce a travs de la reflexin de la experiencia, a partir del dilogo con los otros y explorando el significado de acontecimientos en un espacio y tiempo concreto, como por ejemplo, el contexto. Cules son los componentes del proceso? El aprendizaje situado integra cuatro factores crticos que maximizan el aprendizaje potencial del alumno:

1. 2. 3. 4.

Satisfaccin Contexto Comunidad Participacin

La tecnologa permite a estudiantes aplicar teoras a situaciones cotidianas reales a travs de micromundos, networds, bases de datos, paquetes de grficos y editores de texto. Los beneficios son: 1. Los estudiantes aprenden cmo aplicar el conocimiento que han aprendido. 2. Cuando los alumnos aplican teoras a una situacin, el cmo usar la teora en otras situaciones es ms evidente.

3. Teoras almacenadas en contextos de situaciones son mucho ms tiles que unas simples palabras memorizadas de una teora. El aprendizaje de teoras puede darse en mltiples contextos no slo en uno. De esta manera los alumnos pueden aprender a generalizar sobre qu teoras usar y cmo usarlas en determinadas situaciones. En la actualidad se afirma que la actividad en la que se desarrolla y despliega el conocimiento no puede separarse del aprendizaje ni de la cognicin, ni reviste un carcter auxiliar. Tampoco es neutral, sino que forma parte de lo aprendido. Podemos decir que las situaciones coproducen el conocimiento a travs de la actividad. En consecuencia, podemos afirmar que el aprendizaje y la cognicin estn fundamentalmente situados. La investigacin educativa actual puede impactar en el diseo del currculum multimedia por muchos caminos.

Componentes del diseo de un currculum multimedia Estos cuatro componentes podran ser tiles en el diseo de un currculum multimedia. Un currculum educativo necesita estar basado o fundado sobre algn paradigma o epistemologa, y una perspectiva constructivista podra ser apropiada para la construccin de multimedia. La teora cognitiva puede contribuir mucho al diseo de un currculum.

Si apropiados procedimientos y principios, utilizados en la industria, pudiesen ser aplicados a un ambiente educativo constructivo, entonces se podra producir un autntico ambiente multimedia. El componente final de este currculum multimedia propuesto podra ser extrado desde el uso y prctica de multimedia en educacin. III.- CONCLUSIONES Podemos encontrar muchos trabajos sobre multimedia y educacin en la literatura educativa corriente, pero hay pocos trabajos que actualmente se basen en el currculum multimedia donde la finalidad de estudio es el completo estudio del diseo y produccin multimedia. El principal aspecto en este nuevo tipo de enseanza es un cambio en los paradigmas que estn alrededor del aprendizaje del alumno y la tecnologa. En el pasado, el multimedia ha sido utilizado para seminarios y exploracin de conocimiento, mientras que ahora se est dando nfasis a la construccin de conocimiento. La tecnologa necesita convertirse en una herramienta para el profesor/tutor. Los estudiantes podran utilizar los multimedia para sintetizar y exponer su propio conocimiento. Es decir, utilizar esta nueva tecnologa para construir un medio de comunicacin de estructuras de conocimiento ricas en componentes de informacin diversa desde una variedad de fuentes. Mltiples reas han de ser examinadas para disear un currculum multimedia constructivista. Se necesita abarcar desde la investigacin cognitiva y cuestiones de diseo educativo, hasta el diseo de la clase y cuestiones de hardware de ordenador. Un elemento que puede contribuir a la hora de construir nuevos conocimientos a travs de las nuevas tecnologas es el interfaz siempre realizado siguiendo las pautas de diseo anteriormente descritas. La comprobacin de que esto se puede llevar a la prctica es el interfaz de Campus Extens, basado siempre en las pautas de senzilez, armona, consistencia e intuicin. Pocas cosas han cambiado desde su creacin en las pginas de Campus Extens (colores de fondos, pastillas en el cuaderno descriptivo y en los mdulos...), pues desde el principio quisieron ser coherentes y mantener unos principios de diseo en forma de reglas que sirviesen primero a lo largo de todo el documento (asignatura), incluso en las ampliaciones que se pudieran realizar, y despus a modo de plantilla para todas las asignaturas que pertenecen al proyecto. Al ser un proyecto educativo de gran envergadura y como ya se ha comentado anteriormente se ve limitado y condicionado por el hecho de que la informacin llegue a todos los alumnos por igual, por ello utiliza lenguajes clsicos ya que no es partidario de innovaciones injustificadas. Prefiere mantener una estructura visual lgica y que no desoriente antes que introducir elementos diferentes que pueden "atrapar" por el efecto novedad pero que tambin pueden desconcertar. Referencias o

FUNDESCO: Environment Mangement.

<URL: http://www.fundesco.es/aesopian/advanced/02000000.html> - <URL: http://www.ed.psu.edu/insys/527/situaded/527mideas.html> o

BARKER, P.G. "Some experiments in man-machine optimal relevant to computer assisted instruction". British Journal of Educational Technology, 1982, 1 (13), 65-75. BRICKELL, G.: Navigation and learning style.

<URL: http://cleo.murdoch.edu.au/gen/aset/ajet/ajet9/su93p103.html> o

COLLINS, A. (1991). Cognitive apprenticeship and instructional technology.

<URL: http://ouray.cudenver.edu/slsanfor/cog_it.txt> o

o o

GAGN, R. M. Developments in learning psychology (Interview). Implications for instruction design, and effects of computer technology on instructional design and development Educational Technology, June 1982, 11-15. HALE, D. J. (ed). International Journal of Man-Machine Studies, 1981, 14, 235-236. HEDBERG, J., HARPER, B., BROWN, C.: Reducing Cognitive Load in Multimedia Navigation.

<URL: http://cleo.murdoch.edu.au/gen/aset/ajet/ajet9/su93p157.html> o

HEDBERG, J., PERRY, N.: Human-Computer Interaction and CAI: a review and research prospectus.

<URL: http://cleo.murdoch.edu.au/gen/aset/ajet/ajet1/win85p12.html> o

KEARLEY, G.P. & HILLELSOHN, M. J. "Humans factors considerations for computer-based trainig". Journal of Computer-Based Instruction, 1982, 8(4), 74-85. LINDGAARD, G.: Human Factors in Telecommunications Research.

<URL: http://cleo.murdoch.edu.au/gen/aset/ajet/ajet1/sum85p3.html> o

MARCHIONINI, G.: Psychological Dimensions of UserComputer Interfaces.

<URL: http://www.de.gov/databases/ERIC_Digests/ed337203.html>. o

MEEK, J.: Intelligent agents, Internet information and interface.

<URL: http://cleo.murdoch.edu.au/gen/aset/ajet/ajet11/su95p75.html> o o o

NISBET, J., SHUCKSMITH, J.: Estrategias de aprendizaje. Aula XXI, Santillana. Madrid, 1987. STEWART, T. Communicating with dialogues. Ergonomics, 1980, 23(9), 909-919. SEELY, J., COLLINS, A., DUGUID, P.: La cognicin situada y la cultura del aprendizaje. Kikiriki-39.
El interfaz de usuario.

DATOS DE LOS AUTORES: Margalida Noguera Oliver Cristina Lpez-Poln Hernanz Jess Salinas Ibez (Universitat de les Illes Balears) Resumen Con esta comunicacin pretendemos revisar algunas teoras sobre el interfaz de usuario que han aparecido en los ltimos aos, analizando la interaccin hombre-mquina, los estilos de aprendizaje, los factores que influyen en los procesos cognitivos, el aprendizaje situado, y recalcando los principios y tendencias del interfaz de usuario y el papel del diseo educativo en los ordenadores. Finalmente, describiremos un caso prctico: el modelo educativo Campus Extens. Abstract With this communication we seek to revise some theories on user's interface that have appeared in the last years, analyzing the interaction human-computer, the learning styles, the factors that influence in the cognitive processes, the located learning, and emphasizing the principles and tendencies of user's interface and the paper of the educational design in the computers. Finally, we will check if the theory, previously studied, is adjusted a practical case: the pattern educational Campus Extens. Palabras clave Aprendizaje situado, interfaz de usuario, interaccin hombre-mquina, home, herramientas de comunicacin.e contenido. http://www.filos.unam.mx/POSGRADO/seminarios/pag_robertp/paginas/interfaz.htm

4.3.2 Integracin de la interfaz al caso de uso.

Un proceso centrado en la arquitectura Arquitectura: Da una perspectiva del sistema completo; todos los empleados deben estar de acuerdo con ella. Describe los elementos ms importantes del sistema. El 1er. Objetivo de la fase de elaboracin es construir una arquitectura slida que sirva de base para construir el sistema. 1. Arquitectura en pocas palabras

El conjunto de todas las vistas representa a la arquitectura. Cada vista es una perspectiva diferente del sistema. Cantidad de pginas para la Descripcin de arquitectura: Se recomienda que sea de entre 50 y 100 1. Por qu es necesaria la arquitectura Para que los desarrolladores progresen hasta obtener una visin comn (en sist. soft. grandes) Para dividir el proyecto en clases y facilitar su reutilizacin (futuros cambios) 1. Compresin del sistema Todos las personas que trabajen en el desarrollo del sistema deben comprenderla lo cual es un reto difcil porque: operan en entornos complejos y al dividirlos en miniproyectos es difcil coordinarlos. 2. Organizacin del desarrollo Mientras ms grande sea el proyecto habr mayor sobrecarga en la comunicacin entre los distintos desarrolladores; para ello se divide el sistem en subsistemas donde cada uno tendr un responsable. Tambin es importante tener interfaces bien definidas. 3. Fomento de la reutilizacin Este capitulo es un quilombo. Jacobson andate a la concha de tu madre que te pari cagando. 4. Evolucin del sistema Un sistema grande evoluciona con el tiempo incluso durante su desarrollo, o sea, sufrir futuras modificaciones (nuevos casos de usos). Si el sistema es flexible (tolerable a cambios) dichas modificaciones no deben causar resultados inesperados. Las arquitecturas de sistemas pobres deben ser parcheadas hasta el final y su coste es grande e innecesario.

2. Casos de uso y arquitectura La arquitectura se ve condicionada por: Los casos de usos ms importantes (ms significativos). El producto software que se desea desarrollar. Por ej.: sist.op.; base de datos; etc. Los productos de capa media que se van a utilizar. Sistemas heredados a utilizar. Estndares y polticas corporativas. Requisitos no funcionales.

La arquitectura del sistema se desarrolla en fase de elaboracin juntos con los casos de usos ms importantes. Una vez que se tiene una arquitectura estable se realiza el resto de los casos de uso (los menos relevantes) que por lo general se basan en los requisitos de los clientes y usuarios. El valor de costo de nuevos casos de usos se reflejan segn la arquitectura del sistema. La arquitectura gua los casos de uso: Mientras ms se conozca la arq. mejor se har la captura de requisitos para desarrollar los casos de usos. Los casos de uso conducen a la arquitectura: ??? Cada vez que se quiera implementar un conjunto de CU al sistema, lo ideal es ampliar la arquitectura para darles soporte. Dicha ampliacin se realiza una vez por cada iteracin. Entonces, Los CU ayudan a tener una arquitectura cada vez mejor. 1. Pasos hacia una arquitectura La arquitectura se desarrolla mediante un conjunto de iteraciones, principalmente en fase de elaboracin. El resultado de esta fase es una lnea base de la arquitectura (esqueleto del sistema) que consta de poco software. 1. Lnea base de arq: sistema pequeo y flaco Lo mismo que el 4.4 pero con ms boludeces. La lnea base del sistema es una versin interna y se basa en la descripcin de la arquitectura. Cada versin nueva de un modelo se desarrolla a partir de la versin anterior. Nunca son independientes unos de otros. Los elementos de un mismo modelo se relacionan por medio de dependencias de trazas. Descripcin de arquitectura: Sirve para guiar a los desarrolladores durante ciclo de vida actual y como base para el futuro. Teniendo una arquitectura estable, la descripcin de sta tambin ser estable. 2. Utilizacin de patrones en la arquitectura

Definicin de Patrn: Solucin a un problema de diseo que aparece con frecuencia. Estos patrones estn documentados en libros; en ella hay diferentes plantillas donde asignan un nombre a cada patrn y describe los problemas, qu los causa y las soluciones. Algunos patrones de diseo: Facade, Decorator, Proxy Observer, Strategy, Visitor. Los patrones de diseo son ideal para lenguajes con orientacin a objetos. Los patrones de arquitectura son ideal para sistemas, subsistemas e interfaces.

Definicin de Capa: Conjunto de subsistemas que comparten la misma generalidad y de volatilidad de interfaces: Las capas inferiores (media y de sistema) requieren de interfaces estables; las capas superiores (de aplicacin) requieren interfaces menos estables. 1. Descripcin de la arquitectura

Debe contener todo lo que los trabajadores necesitan para hacer sus trabajos. Debe actualizarse en forma constante para reflejar cambios y adiciones. Tambin debe presentar: Vistas de los distintos modelos. Requisitos que no figuran en los CU (NO funcionales / adicionales) Breve descripcin de plataforma, sistema heredados y software comercial q se va a utilizar.

En la DA se describen con ms detalle los subsistemas que son significativos para la arquitectura que representan un aprox.10%. Los CU en su mayora no modifican al sistema. 1. El arquitecto crea la arquitectura: que novedad Es importante que el arquitecto tenga conocimientos sobre... ..la empresa con la que est trabajando: adquirir experiencia con usuarios. ..desarrollo de software: saber escribir cdigos para comunicarse con desarrolladores.

Puede que se necesiten ms de un arq. para desarrollar sistemas grandes. El desarrollo de arquitectura consume mucho tiempo. 1. Ejemplo pg. 72 2. Resumen CAPITULO 5 Un proceso iterativo e incremental Cada fase de desarrollo se compone por una serie de iteraciones e incrementos.

1. Iterativo e incremental en pocas palabras 3 Claves del Proceso Unificado para el desarrollo de software: El sistema est dirigido por casos de usos. Se centre en una arquitectura. Tenga un desarrollo iterativo e incremental. 1. Desarrollo en pequeos pasos En las primeras iteraciones se realiza: Determinacin del mbito del proyecto. Eliminacin de riesgos crticos. Creacin de la lnea base de arquitectura.

Se deben dominar los requisitos, el problema y los riesgos que pueden surgir. En las iteraciones posteriores Se reducen los riesgos menos graves Se implementan componentes

Se aaden incrementos hasta llegar a la versin extrema (para el cliente). El ciclo de vida de un proyecto se divide en miniproyectos = iteraciones, cada una compuesta por sus respectivos flujos de trabajo (requisito, anlisis, diseo, implementacin, prueba). Se les llama miniproyectos porque no es algo que el usuario haya pedido. El jefe de proyecto es quien se encarga de ordenar las iteraciones. 1. No es una iteracin Si el desarrollador pasa del ciclo de inicio al de elaboracin...

Sin resolver los riesgos ms crticos. Sin establecer una lnea base de la arquitectura. Sin implementar los casos de usos importantes.

Adems de ser un choto est construyendo un proyecto no fiable y no vale la pena que siga con l. La iteracin NO es aleatoria. Sirve como herramienta; para que los directores controlen el proyecto y reduce los riesgos q puedan amenazar al principio del ciclo de vida. 1. Por qu un desarrollo iterativo e incremental? 1. Atenuacin de riesgos Riesgo: es una variable que pone en peligro o impide el xito del proyecto.

"Aproximacin al proceso de desarrollo dirigido por riesgos": El Proceso Unificado reconoce los riesgos ms importantes en las primeras 2 fases y reduce los mismos. Los que no, pueden poner en peligro el proyecto entero. Mtodo cascada: El desarrollo del sistema no se divide en iteraciones. Los problemas graves pueden saltar en la fase de integracin & prueba; esto obliga a contratar a desarrolladores con ms experiencia, el proyecto queda parado y se retrasan las fechas. Mtodo iterativo: Los riesgos importantes se tratan en las primeras fases, quedando muy pocas en la de construccin. El proyecto marcha sin inconvenientes hasta el final. 2. Obtencin de una arquitectura robusta Mtodo cascada: Es en las ltimas fases donde se sabe con certeza si la arquitectura que se dise es la adecuada. Si no lo es, se habr perdido mucha guita y no podremos cumplir con la fecha de entrega. Mtodo iterativo: Es al final de la fase de elaboracin donde se evala la arquitectura; si an no est madura se trabaja en una nueva iteracin; esto es posible ya que es muy poco lo que se in-vierte en esta fase y las fechas an no estn definidas. 3. Gestin de requisitos cambiantes construccin: es una versin operativa del sistema que demuestra un subconjunto de posibilidades. Es ms fcil para el usuario ver un sistema ejecutable en funcionamiento que leer cientos de pginas de documentos. Esto permite a que los usuarios opinen y sugieran modificar o agregar cosas que se nos pas de largo. En mtodo cascada los usuarios ven al sistema funcionando recin en la integracin y prueba, y si desea cambiar algo debern aumentar presupuesto y atrasar las fechas. 4. Permitir cambios tcticos Con mtodo iterativo los directores se encargan de ver al final de cada iteracin.. Si hubo un incremento y se han resueltos los problemas; entonces autorizar a los desarrolladores a seguir con la siguiente iteracin. Si el xito fue parcial, se ampliar la iteracin hasta poder cumplir con lo requerido. Si el resultado es negativo puede llegar a cancelarse el proyecto.

1. Conseguir una iteracin continua Mtodo cascada: Muchos errores parecen no estar presentes y el proyecto progresa con norma-lidad hasta llegar a la integracin y prueba; ah salen todos a la luz. Estas ponen en peligro al proy

Mtodo iterativo: Ya desde un principio se hacen frecuentes construcciones, y con stas aparecen los errores que se tratarn a lo largo de todo el proyecto. No habr sorpresas para el final.

2. Conseguir un aprendizaje temprano

Se ingresa gente nueva a medida que se pasa de una iteracin a otra. Puede empezar con unas 5 a 10 pers. pasar a 25 y finalmente a 100. Los nuevos tienen una formacin adecuada y trabajan con gente con experiencia, rpidamente se ajustan a la velocidad adecuada. 1. La aproximacin iterativa est dirigida por riesgos Se analizan los riesgos, luego se priorizan y se organizan las iteraciones para Tratar los requisitos pedido por los usuarios Obtener una arquitectura robusta. Tratar otros aspectos como rendimiento, disponibilidad, portabilidad: stos se ven cuando se implementa y se prueba el software.

Objetivo: acabar con los riesgos en una iteracin temprana. En fase de inicio y elaboracin se tratan la mayora de los riesgos. 1. Las iteraciones alivian los riesgos tcnicos Hay 4 formas de tratar a un riesgo segn su prioridad: Evitarlo: Quizs se tenga que replanificar el proyecto o hacer un cambio de requisitos. Limitarlo: Achicarlo para que afecta una parte pequea del proyecto. Atenuarlo: Probar repetidas veces hasta ver si aparecen o no. Controlarlo: Ver si el proyecto puede convivir con sta. Caso contrario no se podr continuar: algo que no es tan malo ya que se detect en un principio y los gastos fueron mnimos.

Se manejan por iteraciones para no tener que tratar con todos los errores a la vez. 1. Iteracin genrica

1. Qu es una iteracin Una iteracin es un miniproyecto donde se tiene como resultado una versin interna. Est compuesto por 5 flujos de trabajos: requisitos, anlisis, etc. Los trabajadores y artefactos pueden trabajar en ms de un flujo de trabajo. Las Fases estn divididas en N iteraciones. Descripcin de cada fase: Inicio: Hacer anlisis del negocio y reducir los riesgos ms importantes.

Elaboracin: Obtener lnea base de la arquitectura, capturar requisitos, reducir dems riesgos. Construccin: Desarrollar el sistema entero. Ofrecer funcionalidad operativa a clientes. Transicin: Tener el producto preparado para la entrega. Se ensea a usuarios a utilizar el software.

Cada iteracin se analiza cuando termina y se ven si cambiaron o aparecieron nuevos requisitos que modificarn a la siguiente iteracin. Prueba de regresin: Sirve para ver si no se han estropeado iteraciones anteriores. Se aplica al antes de terminar con la iteracin actual. 1. Planificacin de las iteraciones Requiere de ms tiempo que en el modo cascada. En mtodo cascada la planificacin se realiza en un principio, osea, antes de tratar los riesgos importantes y tener una lnea base slida. Mtodo iterativo: No se planifica proyecto entero en fase de inicio, solo unos pasos. Es al final de la fase de elaboracin donde se tiene una base para planificar la mayor parte. 2. Secuencia de iteraciones Los casos de usos establecen una meta. La arquitectura establece un patrn. En las primeras iteraciones se conocen mejor los requisitos, riesgos y soluciones. Las iteraciones sgtes. dan como resultado incrementos aditivos que terminan en una versin externa. La planificacin y trabajo de una iteracin empieza cuando la anterior se est por entregar. 1. El resultado de una iteracin es un incremento

Definiciones de Incremento: Diferencia entre la versin interna de la iteracin anterior y la siguiente. Diferencia entre 2 lneas bases sucesivas. Colaboracin: Es la representacin de los CU ms significativos para la arquitectura. Sirve para identificar subsistemas e interfaces. Luego se les da forma (implementa cdigo). Hay ms incrementos a medida que nos acercamos a la fase de transicin. La integracin del ltimo incremento se convierte en el sistema final. 1. Iteraciones sobre el ciclo de vida Cada una de las 4 fases termina con un hito principal.

Objetivos de cada fase: Ya estn en punto 4.2 Al final de cada iteracin se producen artefactos como resultado. Hitos principales: Se dan al final de cada fase. Jefes y desarrolladores toman decisiones impor-tantes: continuar o no con el proyecto, calendario y presupuesto. Hitos secundarios: Se dan al final de una iteracin. Los jefes deciden cmo continuar en itera-ciones siguientes.

En fases inicio y elaboracin es poco el grupo de gente trabajando (bajo costo). Aumenta el nmero de personas en fase de construccin. CAPITULO 6 Cap. de requisitos: de la visin a los requisitos

1. Por qu la captura de requisitos es complicada Capturas de requisitos: es el proceso de averiguar en circunstancias difciles qu se debe construir. Los desarrolladores no pueden escribir un cdigo sin saber qu es lo que debe hacer. Algo que sucede en algunas ocasiones. Analistas documentaban requisitos segn lo que los usuarios pedan, pero llegaba a cientos de pginas y no podan concretarse fcilmente. Los usuarios saban bien qu deba hacer el software recin cuando el producto estaba casi terminado y para hacer los cambios pedidos no quedaba otra que postergar las fechas y aumentar presupuesto. El usuario no saben cules son los requisitos. 2. Objeto de flujo del trabajo de los requisitos Objetivo: Guiar el desarrollo hacia el sistema correcto. Suponiendo que el usuario no es un especialista informtico, debemos ser capaces de hacer entender al cliente el resultado de los requisitos; utilizando el lenguaje del cliente e introduciendo (con mucho cuidado) formalidad y estructuras. 3. Visin general de la captura de requisitos Se puede comenzar con la captura de requisitos de muchas maneras: haciendo un modelo de negocio, o de dominio por ejemplo. Flujos de trabajo arquetpicos: Enumerar los requisitos candidatos: De aqu se obtienen caractersticas: lista de sugerencias que el usuarios va dando. Aumenta cuando se agregan elementos; se restan al convertirse en otros artefactos como casos de uso. Compuesto por un nombre corto, breve descripcin y un conj. de valores: Estado (propuesto, aprobado, validado) Coste estimado, Prioridad, Nivel de Riesgo.

Estos valores sirven para calcular tiempo que llevar el proyecto y cmo dividirlo en iteraciones. Comprender contexto del sistema: Hay 2 aproximaciones para expresar el contexto de sist. Modelo de dominio: Describe los objetos del dominio*, se les asignan un nombre que se pasan a un glosario para mejorar la comunicacin entre la gente que trabaja. Los objetos ayudan a identificar clases. Modelo de negocio: Es ms amplio que el modelo de dominio. Describe los procesos que componen el negocio. Objetivo Comprender cules son los procesos que soportar el sistema.. Capturar requisitos funcionales: Se basa en los caso de usos = Describen de qu forma el usuario va a utilizar el sistema. Cada usuario requiere de varios CU. Los analistas proponen cmo ser la interfaz del sistema esbozando varias versiones para que el usuario decida. Capturar requisitos NO funcionales: Especifica las propiedades del sistema que tienen que ver con rendimiento, velocidad, uso de memoria, plataforma. Fiabilidad: tiempo de respuesta media, defectos por miles de lneas de cdigo. Imponen condiciones a requisitos funcionales. Puede que no pertenezca a ningn caso de uso => se agregan como requisitos adicionales. * objetos de dominio: Cosas o eventos que existen o suceden en el entorno donde trabaja el sistema. 4. Papel de los requisitos en el ciclo de vida de software inicio: Se identifican la mayora de los CU para detallar los ms importantes (10%) elaboracin: Se captura un 80% de requisitos para estimar tiempo de proyecto. construccin: Se capturan e implementan los dems requisitos. transicin: No hay captura de requisitos. 1. Cmo desarrollar un modelo de negocio (2 pasos) El modelador.. hace un modelo de CU del negocio que identifique a los actores y los CU que utilicen los actores. Desarrolla un modelo de objetos del negocio compuesto por trabajadores, entidades del negocio y unidades de trabajo.

Una entidad del negocio representa algo que los trabajadores toman, manipulan, modifican, utilizan (una factura por ejemplo). Una unidad de trabajo es un conjunto de entidades de trabajo.

CAPITULO 7 Captura de requisitos como caso de uso

1. Artefactos
Los artefactos fundamentales en captura de requisitos son: Modelos de CU: Incluye actores y casos de usos Otros: Prototipos de interfaz de usuario. 1. Artefacto: modelo de CU El modelo de CU sirve para llegar a un acuerdo entre el cliente y desarrollador sobre los requisitos que deber tener en cuenta el sistema. Describe lo que hace el sistema para cada tipo de usuario. 2. Artefacto: actor Actor: Representa el entero externo al sistema. Rol: Define lo que hace un trabajador en proceso de negocio. Instancia: es un actor que interactua con el sistema. 3. Caso de uso Interaccin: Es una secuencia de acciones que el sistema lleva a cabo (interactuando con actores) para dar un resultado de valor. Descripcin de CU puede incluir diagramas de actividad. Instancia de CU: Es la realizacin de los CU. Son atmicas: se ejecutan todo o nada. Sin otros de por medio. Los CU tienen atributos, valores que en su ejecucin se pueden usar y modificar. Flujos de sucesos: Especifica qu hace el sistema cuando ejecuta un determinado CU. Flujos especiales: Describe a un grupo de requisitos no funcionales. 4. Artefacto: descripcin de una arquitectura Contiene una vista del modelo de CU que describe los aspectos ms importantes de la arquitectura. 5. Artefacto: Glosario 6. Artefacto: prototipo de interfaz de usuario

Mejora la interfaz de usuario y ayuda a comprender los CU. 2. Trabajador

Representa los comportamientos, descripciones y responsabilidades del mismo. No es lo mismo que un individuo ya que ste puede representar a varios trabajadores si es que realiza distintas actividades. 1. Analista de sistemas Hace la captura de requisitos func. y no func. para moldearlos a los CU. Hay 1 por cada sistema. Especificador de CU: Asiste al analista de sistema. Diseador de interfaz: Es responsable del prototipo de interfaz de usuario. Arquitecto: Trabaja con la captura de requisitos para disear las vistas de la arq del modelo de CU. 2. Flujos de trabajo Conjunto de actividades que estn ordenados. Los trabajadores crean, ejecutan y modifican artefactos. Cada salida de una actividad sirve como entrada para la siguiente. Los artefactos se completan y mejoran a travs de las iteraciones. Los analistas para hacer captura de requisitos requiere de la ayuda de usuarios, desarrolladores y otros analistas. 4 pasos para tener una nueva versin del modelo de CU con actores: Encontrar los actores / CU / describir cada CU / Describir modelo de CU. No requieren de un rden. 1. Encontrar actores: Es fcil hacerlo teniendo el modelo de negocio. 1 actor por c/ trabajador. 1 actor por c/ cliente. Hay que elegir un actor candidato que represente a todos sus pares. No pueden haber 2 o ms actores que tengan los mismos roles. El analista le asigna un nombre a cada actor y hace una breve descripcin q aclare necesidades y respon. Encontrar casos de uso:

En general empieza con un verbo e indica el objetivo del CU para cada actor. Resultado de valor: La ejecucin satisfactoria de un CU da un resultado de valor para que el actor pueda alcanzar su objetivo. La instancia de un CU involucra a ms de un actor. 2. Priorizar casos de uso Los CU ms importantes se desarrollan en primeras iteraciones. La vista de arquitectura del modelo de CU describe los CU ms significativos para la arquitectura. 3. Detallar un caso de uso Objetivo: Describir su flujo de sucesos de cada CU. Puede hacerse en texto o diagramas. Transaccin: Secuencia de acciones q se llevan a cabo en una instancia de CU. Desviaciones: Puede darse por que.. El actor puede tomar caminos diferentes. El sistema detecta entradas errneas del actor.

Qu incluye la descripcin de un CU? Estado inicial como precondicin. Cmo y cundo comienza un CU. Orden en que se ejecutan las acciones. Cmo y cundo termina un CU. Descripcin de estado final como postcondicin. Descripcin de caminos alternativos. Utilizacin de objetos, valores y recursos. Separar las responsabilidades del sistema / actores.

Requisitos especiales: Son los requisitos no funcionales; especifica sgte. caractersticas del sistema: velocidad, estado de memoria, tiempo de respuesta, rendimiento, disponibilidad. Diagramas de estado: Sirve para comprender un CU complejo y largo con caminos alternativos. 1. Prototipar interfaz de usuario: Sirve para ver cmo un usuario puede utilizar el sistema para ejecutar un CU. Se disea durante fases de anlisis, diseo e implementacin.

SECCIN: Ing. de software / Anlisis de sistema

Ezequiel Hernndez ezequielher@yahoo.com Argentina

http://www.monografias.com/trabajos22/desarrollo-software/desarrollo-software.shtml