1 Procesos de la ingeniería de requerimientos.

1.1 Requerimientos de proceso.

Requerimientos del sistema

Los Sistemas de Información por computadora normalmente están integrados por muchos componentes. En la mayor parte de los casos, es difícil para los analistas entender todos estos componentes aún mismo tiempo; por lo tanto los investigadores tienen que comenzar con preguntas de tipo general con relación al propósito del sistema sus entradas y salidas de los procesos incluidos. En los grandes proyectos de sistema varios analistas llevan a cabo una investigación 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 información. Se clasifican en dos tipos: 1. - Flujo de Datos.2. - Estrategias de Análisis de Decisión para el Conocimiento para los Sistema de Información.

Estrategia del Flujo de DatosCuando se siguen un flujo a través de los procesos de negocio, que es el propósito del análisis 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 compañía. Al manejar las transacciones y completar las tareas, los datos de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten.El análisis 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 Análisis de DecisionesLa estrategia del análisis de decisiones es un complemento del análisis del flujo de datos. Esta estrategia realza el estudio de los objetivos de una operación 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 análisis de decisión 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 opción que toman un supervisor de departamento para aceptar o rechazar pedidos.La decisión 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 Análisis del Flujo de Datos1. - Estudiar las operaciones y procesos en marcha.2. - Identificar cómo se procesan los datos al manejar transacciones y terminar las tareas.3. - Seguir el flujo de datos: * Proceso* Almacenamiento* Recuperación* Salida4. - Añadir gradualmente detalles a los niveles inferiores.

Etapas en la Estrategia del Análisis de Decisión1. -Estudiar los objetivos y decisiones necesarias.2. - Desarrollar un modelo del proceso de decisión.

3. - Probar el modelo con datos de prueba.4. - Identificar los requerimientos del proceso para los datos.

4. Requerimientos De Salida

Niveles de diseñoEl diseño de sistema se representa a través de dos fases: el diseño lógico y el diseño físico.Cuando los analistas formulan un diseño lógico; escriben las especificaciones detalladas del nuevo sistema; esto es, describen sus características: las salidas, entradas, archivos y bases de datos y procedimientos; todos de manera que cubran los requerimientos del proyecto.El diseño lógico de un sistema de información es como el plano de un ingeniero para armar un automóvil: muestra las características principales(motor, transmisión 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 están las puertas.Los informes y la producción 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 diseño lógico también 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 métodos para introducir los datos, corridas de informes copiados de archivos y detección de problemas. El diseño físico, actividad que sigue el diseño lógico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseño 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.

Utilización de los Datos de Requerimientos:El alcance del diseño de sistemas se guía por el marco de referencia para el nuevo sistema desarrollado durante el análisis. Los datos de los requerimientos, recopilados durante la investigación, conforman las actividades y componentes del sistema. Los analistas formulan un diseño lógico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiar como resultado de un nuevo diseño. El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de requerimientos.En primer lugar se identifican las características generales, como informes y entradas; en el diseño de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato especifico para establecer cuanto espacio dejar en la información, en la pantalla de despliegue visual o archivo.

Participación de los Usuarios:Los gerentes y usuarios del sistema también poseen un papel importante en le diseño del sistema; no es solamente el proyecto del analista. Durante el diseño, 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 participación del usuario proporciona al analista una retroalimentación importante conforme avanza en el diseño; además asegura a los usuarios tengan un conocimiento no técnico de lo realizara o no el nuevo sistema. Esta visión general del diseño de sistemas subraya los aspectos de diseño que se verán mas adelante en el diseño de la salida de sistema.

Prototipo de Sistemas:Los requerimientos del sistema y las especificaciones de diseño 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 información 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 información 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 información para administrar ciertas actividades.

Métodos para el Desarrollo de Prototipos:Los sistemas de prototipo se pueden desarrollar utilizando lenguajes de programación y métodos convencionales. El procesamiento y los controles de entrada pueden faltar y la documentación 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 perfección. En algunos casos cuando el sistema se utiliza en forma muy frecuente en la formulación de La forma en que sé esta llevando a cabo el diseño de salida del sistema.

Diseño de la Salida de Sistemas:A menudo, para los usuarios la característica más importante de un sistema de información 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 utilización y, por lo tanto, posiblemente ocasionen errores y que el sistema falle.

Diseño Lógico de la Salida:Él termina "salida" se aplica a cualquier información producida por un sistema, ya sea impresa, desplegada o verbal. Cuando los analistas diseñan la salida, seleccionan métodos para representar la información y crean documentos, informes u otros formatos que contienen información producida por el sistema. Los métodos de salida varían a lo largo de los sistemas. Para algunos, como un informe de inventarios de la cantidad de mercancía, 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 múltiples pantallas para desplegar información.

Selección de los Métodos de SalidaLos sistemas de información ya sean que se desarrollen sobre sistemas pequeños de escritorio o sobre grandes sistemas, utilizan 3 métodos principales para la salida los cuales se clasifican en:

Impresión Pantalla Despliegue y audio

Salida ImpresaEste tipo de salida es la que se encarga de producir grandes volúmenes de informes impresos, sin embargo la decisión de utilizar salida impresa no debe ser automática, debe haber alguna razón 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 información a diferentes personas en forma simultanea. Un informe bien diseñado puede reemplazar a otro elaborados pobremente, proporcionando detalles innecesarios la cual no ayuda nada. Las opciones de salida impresa más comunes en las empresas son en papel, informe filmados, formas especiales y formas para enviar por correo.

Objetivos de la Salida

Expresar la Información Relacionada con Actividades Pasadas, Estado Actual o Proyecciones para el Futuro.

Señalar Eventos Importantes, Oportunidades, Problemas ó Advertencia. Iniciar una Acción Confirmar una Acción.

El objetivo principal durante el diseño de salida de la computadora es la información 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 salidaLa 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:

Recuperación de un Dispositivo de Almacenamiento. Transmisión desde un Proceso o Actividad del Sistema. Directamente desde una Fuente de Entrada.

6. Conclusión

La función del Análisis 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 documentación que hacen efectiva la logística metodología o controles de requerimientos del Programa.Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una función externa dentro de los Sistemas. Personal, son los operadores o usuarios directos de las herramientas del Sistema. Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software. Documentación, Manuales, formularios, y otra información descriptiva que detalla o da instrucciones sobre el empleo y operación 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 información con el mundo y sus usuarios, en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son:

Objetivos del Diseño de Entrada.

Captura de Datos para la Entrada.

Objetivo del Diseño de EntradaConsiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los procesos necesarios para poner los datos de transacción 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 diseñador debe controlar la cantidad de datos en la entrada:- Las Operaciones de preparación y entrada dependen de las personas dado que los costos de mano de obra son altos y la preparación de ingreso de los datos también 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:También conocido con el nombre de cuello de botella son siempre uno de los objetivos que el analista evita al diseñar 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 pequeña sea esta menores serán las oportunidades para cometer errores. Es común 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 preparación es algo que no se puede controlar por ello el analista experimentado, evitara diseños para la entrada que traigan una mayor cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso de un día.Mantener la sencillez del Proceso:El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo proporcionarán métodos 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 garantía para el éxito al instalar un sistema complejo y que domine.

Captura de Datos para la Entrada:En una transacción 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 identificación

Datos Variables:Son aquellos que cambian para cada transacción o toman de decisión.

Datos de Identificación:Estos son los que identifican en forma única el artículo que esta siendo procesado.

1.3 Requerimientos para el análisis y negociación.

Gerencia de Proveedores de Bienes y Servicios:

1. Calificación de proveedores de bienes y servicios.2. Análisis de la licitación y recomendaciones.3. Precio Máximo Garantizado /Llave en Mano /administración delegada u otros.4. Asistencia en la selección de contratistas y proveedores.5. Análisis comparativo de contratos y presupuestos.

Negociación de Contrato:

1. Metas de tiempo y costo.2. Desarrollo del contrato/ Revisión de las cláusulas 3. Seguros /Fianza y garantías.4. Análisis de contrato y reportes ejecutivo.5. Administración de contrato durante la construcción.

1.4 Requerimientos para la gestión.

5. Requerimientos de almacenamiento

La memoria de la computadora (RAM) es un lugar provisional de almacenamiento para los archivos que usted usa. La mayoría de la información 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 (también denominados unidades) fueron desarrollados para satisfacer esta necesidad.

Los siguientes constituyen los tipos más comunes de dispositivos de almacenamiento:Unidades de:

Disco duro Disquete Compresión ZIP CD DVD

Disco DuroEl disco duro es el sistema de almacenamiento más 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 cálculo (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 EstadoExisten varias cosas que usted puede realizar para prevenir que la computadora le devuelve mensajes de error molestos. A continuación encontrará una lista de programas diferentes disponibles para asegurarse de que la unidad de disco duro se mantenga saludable y funcionando a plena capacidad. (Están disponibles estos programas de ejemplo a través 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 Desfragmentación de DiscoAl transcurrir el tiempo, es posible que los archivos se vuelvan fragmentados porque se almacenan en posiciones diferentes en el disco. Los archivos estarán completos cuando los abra, pero la computadora lleva más tiempo al leer y escribir en el disco. Están disponibles programas de desfragmentación que corrigen esto. Para obtener acceso al programa de desfragmentación de disco bajo Windows 95, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en Utilidad de Desfragmentación de Disco.

Compresión de DatosUsted puede obtener espacio libre en la unidad de disco duro o en disquetes al comprimir los datos que están almacenados en éstos. En Windows 95, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en DriveSpace.

Detección de DañosSi experimenta problemas con los archivos, tal vez quiera averiguar si existen daños en el disco. ScanDisk de Windows 95 verifica los archivos y las carpetas para encontrar errores de datos y también puede verificar la superficie física del disco. Para ejecutar ScanDisk, haga clic en Inicio. Ilumine Programas, Accesorios, luego en Herramientas de Sistema. Haga clic en ScanDisk. Además, 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 detección y limpieza de virus que están disponibles para usted. Simplemente hay que pedirlos del distribuidor local de software para computadoras.

RespaldoSi la unidad de disco duro se descompone o si los archivos se dañan o se sobrescriben accidentalmente, es una buena idea contar con una copia de respaldo de los datos de la unidad de disco duro. Están 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 CDPuede 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 botón de carga / expulsión y un indicador de actividad luminoso. La unidad de disquetes consiste en un dispositivo de 3,5 pulgadas con una ranura cubierta, un botón de expulsión y un indicador de actividad luminoso.

 

Escritura Lectura Nombre Tipos

Por grabación magnética de pistas concéntricas mediante una cabeza constituida por un electroimán.

Por censado mediante la misma cabeza que escribió actuando en forma inversa

Disco magnético (para lectura y escritura)

Disco rígido, disquete, Zip, Jazz, Bernouilli Floptical.

Por modelado de hoyos formando una pista en espiral, por inyección de plástico en un molde metálico (producción masiva de CDs)

Censado por rayo láser de la longitud de los hoyos grabados y de la distancia que separa dos hoyos sucesivos

CD-ROM (sólo lectura)

DVD-ROM (sólo lectura)

Por efecto térmico de un rayo láser se modifica la transparencia de porciones de una pista en espiral, en una capa de material orgánico

Censado por rayo láser de la longitud de las porciones transparentes y las no transparentes de la espiral grabada

CD-R (Sólo lectura)

 

Por grabación magnética auxiliada por acción térmica de una rayo láser de potencia

Censado de campos magnéticos en las pistas por su efecto en un rayo láser

MO (lectura y escritura)

 

Por efecto térmico de un rayo láser de potencia se modifica el estado cristalino de un material

Censado por rayo láser del estado cristalino del material de las pistas

CD-RW ó E (para lectura y escritura)

DVD-RAM, PD

2 Planificación del sistema.

Etapa uno

Planificación Pre-Construcción

Una clara visión, enfoque y dirección 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 filosofía, 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 parámetros bajo los cuales se medirá el éxito del proyecto. La planificación de pre-construcción permite un análisis lógico y ordenado sus necesidades físicas y cuál es la óptima configuración y metodología del trabajo requerido.

Adicional al análisis físico para nuevas construcciones o remodelaciones, se realiza un profundo análisis de la zonificación, normas municipales, permisos necesarios, estructura impositiva, aspectos laborales, y otros costos blandos que puedan influir en el presupuesto, que son revisados minuciosamente.

Etapa Dos:

Diseño

El 80% de los costos duros se definen en el primer 30% del la fase de diseño. 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. Ayudaríamos a aclararle a los profesionales proyectistas tales como arquitectos, ingenieros, constructores y proveedores todas las especificaciones y requerimientos para lograr óptimos resultados. Sobre diseñar agrega costos y una especificación pobre aumentará costos de operación 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 estarán cumpliendo. Elaboraremos proyecciones y estimaciones de costos de operación y mantenimiento predictivo para las instalaciones en su posterior fase de operación.

Etapa Tres:

Revisión de Presupuestos

La coordinación del proceso de diseño asegura que las especificaciones y planos de construcción están completos, garantizando que los presupuestos incluirán todas las partidas esperadas. Planos inexactos, falta de detalles, e instrucciones deficientes a los contratistas licitantes resultarán en aumentos de obra sustanciales o posiblemente la sustitución de materiales de baja calidad por los contratistas.

El equipo CBB prepara un paquete completo de licitación con instrucciones precisas, la metodología de construcción y los cronogramas de tiempo esperados. Antes de proceder a invitar las empresas a licitar Usted estaría totalmente informado de las diferentes maneras que existen de solicitar propuestas y cómo influyen en los objetivos del proyecto. Precio Máximo Garantizado, Suma Global Modificada, Llave en Mano, Administración Delegada o Fast Track, entre otros, son métodos de solicitud de propuesta que serían analizados para limitar y controlar los posibles ajustes de los costos de construcción

Etapa Seis:

Cierre

Un aspecto vital que es comúnmente olvidado es el cierre del proyecto. Esta actividad asegura que las instalaciones quedan operativas, listas para abrir al público, 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 reúne todas las garantías y manuales de operación e instruye al personal en modos eficiente de operación de sus nuevas instalaciones. Aseguramos que las revisiones y lista de chequeo se efectúa en el momento apropiado para asegurar que usted recibe una instalación funcionando y con la información técnica necesaria para su futura operación y mantenimiento. Llevamos a cabo una auditoria del proyecto como parte de nuestro programa de Calidad Total para conciliar costos y para efectuar las críticas de procedimientos que puedan mejorar futuras instalaciones similares. Sugeriremos un programa de mantenimiento, predictivo y preventivo para asegurar estabilidad en sus costos de operación y mantener las instalaciones 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

Etapa Cuatro:

Negociación

Cuando se reciben las diferentes cotizaciones, el equipo CBB efectúa comparaciones manzanas con manzanas tomando muy en cuenta los aspectos que cada contratista excluye de su cotización. 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 recomendaría a usted el contratista que a su juicio es el más apropiado para llevar a cabo la tarea, para posteriormente iniciar las negociaciones contractuales. CBB revisaría y prepararía contratos que por experiencia han sido exitosos en estos casos, reduciendo la carga de abogados externos quienes solo tendrían que revisar y modificar documentos ya pre-elaborados. Los contratos incluyen protección contra daños, penalidades por incumplimientos, cláusulas de incentivo y procedimientos de pago, cierre de obra y modificaciones.

Etapa Cinco:

Monitoreo de la Construcción

Con el equipo de gerencia CBB estructurado, se efectúan las revisiones finales de seguros, fianzas, seguridad física 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 coordinación periódicas estableceremos estrictas normas de reporte para todos los involucrados. Presentaremos reportes ejecutivos y detallados en diferentes formatos para su revisión y control.

marcha de las oficinas se lleve a cabo sin mayores tropiezos o incomodidad. Esta es una etapa crítica que requiere de intensa supervisión para poder finalizar los proyectos con gran éxito.

http://www.cbb.com.ve/servicios/GERENCIA.html

2.1 Planificación del tiempo.

La planificación en tiempo real es uno de los campos de investigación más activos en la informática. En este apartado, se ofrecerá una introducción a los distintos métodos de planificación en tiempo real y se estudiarán dos algoritmos de planificación clásicos.

En un estudio de los algoritmos de planificación en tiempo real, se observa que los distintos métodos de planificación dependen de sí el sistema lleva a cabo un análisis de planificación: en caso afirmativo, si se realiza estática o dinámica: y si el resultado del análisis genera un plan con respecto al cual se expiden las tareas durante la ejecución. Basándose en estas consideraciones, los autores identifican las siguientes clases de algoritmos:

 

             Métodos con tablas estáticas: realizan un análisis estático de las planificaciones de expedición posibles. El resultado del análisis es una planificación que determina, un tiempo de ejecución, cuando debe comenzar la ejecución de una tarea.

 

             Métodos preferentes con prioridades estáticas: también se realiza un análisis estático, pero no se realiza ninguna planificación. En cambio, se usa dicho análisis para asignar prioridades a tareas, de forma que se pueda emplear un planificador convencional preferente con prioridades.

 

             Métodos de planificación dinámica: se determina la viabilidad en tiempo de ejecución (dinámicamente) en vez de antes de empezar la ejecución (estáticamente). Se acepta una nueva tarea para ejecutar sólo si es factible cumplir sus restricciones de tiempo. Uno de los resultados del análisis de viabilidad es un plan o proyecto empleado para decidir cuando se expide cada tarea.

 

             Métodos dinámicos del mejor resultado: no se realiza ningún análisis de viabilidad. El sistema intenta cumplir todos los plazos y abandona cualquier proceso ya iniciado y cuyo plazo no se haya cumplido.

 

La planificación con tablas estáticas es aplicable a tareas periódicas. La entrada del análisis consta del tiempo periódico de llegada, el tiempo de ejecución, el plazo periódico de finalización y la prioridad relativa de cada tarea. El planificador intenta trazar un plan que le permite cumplir las exigencias de todas las tareas periódicas. Este es un plan que le permite cumplir las exigencias de todas las tareas periódicas. Este es un método predecible, pero también es inflexible, puesto que cualquier cambio en las exigencias de una tarea. Son típicos de esta categoría los algoritmos de planificación de primero el plazo más próximo u otras técnicas periódicas de plazos.

 

 

 

La planificación preferente con preferente con prioridades estáticas hace uso del mecanismo de planificación referente con prioridades, habitual en la mayoría 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 asignación de prioridades se encuentra relacionada con las restricciones de tiempo asociadas a cada tarea. Un ejemplo de ese método es el algoritmo monótono de frecuencia, que asigna prioridades estáticas a las tareas en función de sus periodos.

 

 

 

 

La planificación dinámica basada en un plan, después 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 recién llegada. Si la recién llegada puede planificarse de forma que se cumplan sus plazos y que no se pase ningún plazo de las tareas ya planificadas, se revisa el plan para hacer sitio a la nueva tarea.

 

 

 

La planificación dinámica del mejor resultado, es el método utilizado en la mayoría de los sistemas en tiempo real comercializados en la actualidad. Cuando llega una tarea, el sistema le asigna una prioridad en función de sus características. Normalmente, se emplea alguna forma de planificación por plazo, como puede ser la de primero el plazo más próximo. En general, las tareas son

periódicas, por lo que no es posible un análisis estático de planificación. Con este tipo de planificación, no se sabe si se va a cumplir una restricción de tiempo hasta que vence el plazo o la tarea termina. Esa es la mayor desventaja de esta forma de planificación. Su ventaja está en la facilidad de implementación.

 

 

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

En los mercados donde la demanda es variable, tanto en cantidad como en composición,existen básicamente dos líneas a seguir para hacer frente a dicha variabilidad: crear stocks sies posible, con los costes que ello supone, en épocas de poca demanda para poder hacer frentea los picos que ésta puede presentar en otros períodos, y adaptar la capacidad productiva a lademanda. Una de las formas de lograr esta armonización entre la demanda y la capacidadproductiva es mediante la anualización de la jornada laboral.La anualización de la jornada laboral es una de las formas que existen para flexibilizar lacapacidad productiva; consiste en distribuir las horas anuales contratadas, a lo largo del año yen función de la demanda prevista; de este modo, cada trabajador/a puede realizar jornadas dediferente duración a lo largo del año, respetando, claro está, ciertos límites y reglas.Cada vez son más las empresas que pactan en sus convenios una reducción de jornada acambio de anualizarla, estableciendo, por otro lado, diferentes restricciones. En Francia, la leyAubry II, que establece esencialmente una reducción del tiempo de trabajo a 35 horassemanales en promedio sin reducción de salario, permite, a cambio, una anualización sujeta adiversas reglas que deben tenerse en cuenta al realizar la planificación del tiempo de trabajo(en la fecha del 5 de julio de 2000, se habían suscrito en Francia 35.367 convenios de

reducción de la jornada laboral [27]).Esta anualización debe, además de adaptarse a la demanda, respetar diversas reglas, algunaslegales (por ejemplo, la jornada laboral máxima) y otras establecidas en los convenios (porejemplo, número máximo de semanas consecutivas con una jornada semanal media de, comomáximo, 46 horas, número máximo de horas flexibles, etc.), por lo que surgen nuevosproblemas de planificación, de programación de la jornada de trabajo y de asignación detareas.De esta manera, se abren nuevas posibilidades en la gestión de la jornada laboral, pero éstasgeneran nuevos problemas, más difíciles de resolver en los servicios que en la industriaporque en ellos las fluctuaciones suelen ser más acusadas y porque los productos no puedenalmacenarse para constituir stocks.A pesar de su importancia, y tal y como se expone a continuación, el tema de la anualizaciónha sido poco tratado, especialmente desde un punto de vista cuantitativo, en la literaturacientífica.En Hung [20], pese a lo que pueda sugerir el título de dicho trabajo ("Scheduling a workforceunder annualized hours"), no se aborda la planificación sino la determinación de los días detrabajo de cada miembro de la plantilla en una semana dada; más aún, el autor, en el trabajocitado, dice lo siguiente; "Un problema que las empresas deben afrontar cuando realizan laplanificación bajo jornada anualizada, es la programación de los trabajos a lo largo del año.Por lo que sabemos, no existe literatura acerca de ello. La literatura existente sobreprogramación de personal ([1], [2], [15], [18]) asume demandas cíclicas de mano de obra, yesto no es aplicable a situaciones en las que dicha demanda varía a lo largo del año".En un artículo más reciente de Grabot y Letouzey, [17], se puede leer lo siguiente: "Afrontarel problema que comporta una demanda irregular mediante la anualización de la jornada se haconvertido en una idea cada vez más popular en Europa estos últimos años, y particularmenteen el Reino Unido [19]. En Francia, la ley de las 35 horas ha aumentado el interés sobre estetema. Sin embargo, aunque la anualización ha despertado durante muchos años el interés delsector empresarial, (ver, por ejemplo [5], [14], [23], [24] y [25]), es sorprendente la ausenciade artículos sobre este tema en la literatura sobre programación, con la excepción de losrecientes estudios de Hung sobre el tema ([20], [21]). Aunque estos estudios incluyen lademanda estacional, no tienen en cuenta la polivalencia de los trabajadores ni las restriccionesfijadas por la legislación francesa”.Finalmente, en [6], Corominas y Pastor proponen un método para la planificación del tiempode trabajo, la programación de los horarios y la asignación de tareas, en centros de trabajo conjornada anualizada; en [7], [8] y [9] se detallan las fases del método, formulándose 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 anualización propias decada legislación o convenio generan distintos problemas y/o objetivos, que requieren distintasvías de resolución. Esto hace necesaria una clasificación y definición precisa de los problemasque la anualización plantea. En el siguiente apartado se encuentran algunos de los aspectosque pueden influir sobre las características de dichos problemas o bases para la clasificación.2. ClasificaciónDe lo dicho anteriormente, se deduce que una primera clasificación de los problemas surge dela 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 primercaso, además, deberá diferenciarse el caso en el que el producto o productos son noperecederos de aquél 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 elpersonal interviene en el mismo, deberá tenerse también en cuenta para la definición delproblema. En algunos casos (generalmente en la industria) para que el proceso tenga lugar serequiere la presencia simultánea de todos los miembros del equipo, lo que implica que todosdeben cumplir los mismos horarios; en estos casos, la capacidad productiva a lo largo deltiempo de presencia del equipo se mantiene constante. En otros (en muchos servicios), elproceso productivo requiere sólo la intervención directa de una persona (supuesta una ciertainfraestructura, que puede incluir personal) y, por consiguiente, puede haber un númerovariable, a lo largo del tiempo, de trabajadores presentes, con una capacidad de producciónesencialmente proporcional a dicho número (es lo que ocurre, por ejemplo, en unestablecimiento de venta al detalle); en estos casos el número de horas de presencia en unperíodo (una semana, por ejemplo) puede ser distinto para unos u otros trabajadores e incluso,para un mismo total de horas semanales, también pueden ser distintos los horarios depresencia de los diferentes operarios.Otro aspecto importante a tener presente es el hecho de que se considere o no la contrataciónde personal temporal. Aunque las disposiciones legales lo permitan puede no ser aconsejablepor razones ligadas a la calidad del producto o a la dificultad de manejar determinadosequipos, etc. Como argumenta Oke [26], los trabajadores temporales suelen tener una relacióndébil con la organización, con lo que su posible falta de motivación y de identificación conlos 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 puedehaber varios tipos de tareas o trabajos y puede darse el caso de que exista una correspondenciabiunívoca entre tipos de tareas o trabajo y categorías de personal; también puede suceder quelos tipos de trabajos y las categorías estén jerarquizados, es decir, que un trabajador sea capazde realizar las tareas propias de su categoría y también las correspondientes a las categoríasinferiores o a algunas de ellas; o, finalmente, que se pueda definir una matriz categorías/tiposde tarea que indique qué tipos de tarea puede realizar un trabajador de una categoría dada, sinque esta matriz tenga ninguna estructura especial. Por supuesto, en los casos de polivalenciapuede haber prioridades asociadas, para cada categoría de trabajador, a los tipos de tarea quees capaz de llevar a cabo.También es importante conocer las regulaciones sobre las horas extraordinarias, que sepueden referir al número máximo admisible por trabajador y año (por ejemplo, en España, elEstatuto de los Trabajadores fija un máximo de 80 horas extraordinarias al año), a la propiadefinición de qué horas tienen el carácter de extraordinarias (por ejemplo: las que exceden de9 horas en una jornada diaria o las que exceden de 1650 en un año) y a su retribución (éstapuede diferenciarse en más de un bloque; por ejemplo, hasta un cierto número de horas extraspuede pagarse una cantidad y a partir de ese valor, y hasta llegar al máximo, otra cantidaddiferente). Además, la retribución de las horas extraordinarias puede ser monetaria o puedecompensarse con períodos de descanso (por ejemplo, por cada hora extraordinaria trabajada,una hora y media de descanso).Por otro lado, cada problema quedará también definido por las restricciones que ha de respetaruna solución (o las que es deseable que respete) y que pueden derivarse de una disposiciónlegal, de un acuerdo entre la empresa y los trabajadores o de los requerimientos del sistemaproductivo en relación con las previsiones de la demanda. Algunas de éstas se citan acontinuación:– Satisfacción de unos requerimientos mínimos, 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 mínimo de 100 horas).– Número de horas semanales comprendido entre una cota inferior, definida habitualmenteen el convenio o pacto de empresa y otra superior, que debe, en todo caso, respetar lalegislación, pudiéndose fijar en el convenio una cota superior menor.– Para evitar un excesivo desgaste de los trabajadores en los períodos en los que existe unpico en la demanda, es frecuente que se fije una cota superior de la media de horastrabajadas en un cierto número de semanas consecutivas, o una cota superior del número

de semanas consecutivas con una media de horas trabajadas superior a un cierto valor.Podría también fijarse un número de semanas con un cierto número de horas (o con unnúmero de horas comprendido en un intervalo dado) igual a un valor dado o comprendidoen un intervalo dado, etc.Las distintas modalidades de flexibilidad, reglas y restricciones que aparecen en lalegislación, los convenios y los pactos, dan lugar a distintos tipos de problemas, por lo quedebe tenerse en cuenta este elemento al realizar la clasificación.En [8] se trata el problema de empresas francesas en las que, esencialmente, se permite unadistribución irregular de la jornada respetando el límite anual de horas y otras restriccionesasociadas al número mínimo y máximo de horas semanales de trabajo, al número de semanasde descanso que deben seguir a un bloque de semanas de 46 horas, etc.En España, los artículos 34.1 y 34.2 del Estatuto de los Trabajadores dejan libertad para quecada empresa pacte una distribución irregular de la jornada a lo largo del año, respetando laduración máxima de la jornada ordinaria, que es de 40 horas semanales de trabajo efectivo depromedio en cómputo anual y los períodos mínimos de descanso diario y semanal previstos enla ley [16].Aunque la mayoría de los convenios colectivos se refieren a los artículos 34.1 y 34.2 delEstatuto de los Trabajadores en sus apartados de jornada de trabajo, algunos de elloscontemplan la flexibilidad de la jornada laboral y proponen reglas específicas, con lo quesurgen nuevos tipos de problema. A continuación se citan dos de ellos a modo de ejemplo.El convenio colectivo de la industria química [3] permite 100 horas flexibles de aplicación enlos días laborables y que forman parte del cómputo anual de la jornada. Como compensaciónde las horas que se realicen por encima de las ocho horas ordinarias, se fija una hora dedescanso por cada hora de trabajo flexible que se realice hasta la 9ª hora, incluida, de trabajodiario, 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 alempresario, durante 13 semanas (continuas o discontinuas), determinar una jornada superior oinferior a 40 horas semanales.Finalmente, tenemos el caso de una empresa francesa en la que sus trabajadores debenrealizar, al año, 10 semanas con una jornada de 28 horas y 15 minutos, 8 semanas con unajornada de 45 horas y 28 semanas con una jornada de 35 horas y 45 minutos.Pueden también encontrarse casos en los que el número de horas anual se reparta en dosbloques. Uno a realizar en turnos estables y otro, correspondiente a una bolsa de horasflexible, cuyo objetivo es cubrir las bajas laborales, el absentismo, los posibles problemas ylos picos en la demanda no previstos. Para los picos prolongados, se establece que la empresadeberá subcontratar personal temporal [22].Finalmente, cada problema tendrá su criterio o criterios de evaluación de las soluciones. Porsupuesto uno de estos criterios (que habitualmente será el más importante) es el coste, que

puede tener distintos componentes: posesión de stock, horas extraordinarias, personaltemporal, ventas perdidas por insuficiencia de la capacidad productiva, etc. Pero puede haberotros, tales como la regularidad de los horarios a lo largo del año, la adecuación (de acuerdocon la categoría de los trabajadores) de los tipos de tareas asignadas o las preferencias de lostrabajadores por unos u otros horarios, la distribución equitativa del tiempo de trabajo, demanera que se eliminen los agravios comparativos; en definitiva, criterios vinculados a lasatisfacción de los trabajadores en su actividad laboral y en su vida social y familiar. Loscriterios 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 loscostes de horas extras y subcontratación y, a continuación, obtener, para cada trabajador, unanueva planificación con unas jornadas de trabajo lo más regulares posibles a lo largo del año(minimizando las discrepancias respecto a la media) y de modo que no se superen los costesobtenidos en la primera.3. ConclusionesLa anualización de la jornada laboral permite a las empresas adaptarse a las variaciones en lacantidad y composición de la demanda, a la vez que abre nuevas posibilidades de gestión dela jornada. Esto genera nuevos problemas, distintos según la naturaleza del producto oproductos, el tipo de proceso productivo, la posibilidad de contratar mano de obra temporal, elgrado de polivalencia del personal, la regulación de las horas extraordinarias, las condicionesque debe respetar la jornada laboral, el grado de flexibilidad permitido y los criterios deevaluación de las soluciones.La clasificación de los problemas que pueden darse en la planificación del tiempo de trabajocon jornada anualizada es importante porque permitirá diseñar instrumentos de resoluciónsimilares para problemas de un mismo grupo, con lo que se sistematizará y facilitará laresolución de los distintos problemas.

http://io.us.es/cio2001/Cio-2001/cd/Art%C3%ADculos/UPC/UPC-7.pdf

2.2 Evaluación del costo beneficio.

 Deberán aplicar la metodología para la evaluación costo-beneficio de la regulación todos los entes y órganos de la Administración Pública. Dicha metodología, estarán obligados a completarla cuando se establecen nuevas regulaciones o se reforman las existentes que establezcan trámites, requisitos y procedimientos, sobre inscripciones, registros u autorizaciones. 

La metodología se compone de dos tipos de formularios con sus correspondientes guías de llenado.  El “Formulario de Evaluación Costo-Beneficio” (formulario uno) se debe completar para los casos en que las propuestas de regulación establezcan nuevos trámites, requisitos y procedimientos sobre inscripciones, registros o autorizaciones, o modifiquen o eliminen trámites existentes. En este último caso, cuando se eliminen trámites, se deberá completar este formulario sólo si en adición a tal eliminación se modifican o se crean nuevos trámites, requisitos y procedimientos sobre inscripciones, registros o autorizaciones.

En caso contrario, deberá proceder a llenar el “Formulario Simplificado de Evaluación Costo-Beneficio” (formulario dos) debe completarse para el caso en que la propuesta de regulación sea una  reforma a un trámite existente, en la cual únicamente: se eliminan documentos y requisitos innecesarios, se establezcan plazos definidos, se reduzcan los plazos de resolución, o se disminuyan los procedimientos. 

Para realizar este análisis deberá completarse el “Formulario de Evaluación Costo-Beneficio” (formulario 1) o el “Formulario Simplificado de Evaluación Costo-Beneficio” (formulario 2), según sea el caso, siguiendo las guías de llenado correspondientes. Lo anterior, puede obtenerlo en las siguientes opciones:

Directriz Decreto Formularios Guías 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 más que las diferentes formas de denominar o referirse al documento escrito en el que se recoge toda la información relevante referida a una empresa en proceso de creación. En él se sintetiza y refleja toda la concepción 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 creación de su empresa, puesto que su realización requiere un esfuerzo válido por sí mismo, al servir de guía de actuación en las diferentes etapas a seguir en el proceso de creación hasta la puesta en marcha de la actividad empresarial, permitiendo el conocimiento de las condiciones que intervendrán en el futuro.

Es muy importante que en su elaboración 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.

Decídete a actuar ... TU PUEDES SER UN LIDER

¿cómo actúan los líderes? ¿cómo ganar carisma?

Así pues, el plan de empresa cumple tres funciones básicas:

1. Comprobar la coherencia interna del proyecto. 2. Permite cohesionar al grupo humano durante su elaboración (se

prueba el compromiso de trabajo, de dedicación al proyecto por parte de cada promotor).

3. Al contener todos los datos relevantes, es la tarjeta de presentación idónea para ir a buscar recursos, clientes, colaboradores, etc.

Su estructura y orientación dependerá de cuál sea el objetivo de ese plan. Incluso dentro de un mismo tipo de plan de empresa, dependiendo del proyecto, se dará más importancia a unos puntos que a otros.

También 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 fotografía de cuál es la situación 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 elaboración de informes o "cuadros de mando" en los que se detalla la evolución de la empresa en los últimos meses así como las previsiones de evolución futura a corto, medio y largo plazo y que esos informes, que no son más 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 características 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. También es conveniente mostrar cuál es la situación 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 quién o quiénes son las personas que ponen en marcha el proyecto, incluyendo los datos relativos a su formación y experiencia profesional (en ocasiones es más "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 cuál es el nivel de implicación 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 mínimo de remuneración por su aportación, 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 (quién hablará con los clientes, quién realizará el producto, quién se encargará de la gestión administrativa y contable, quién tratará con

los proveedores... y cómo se hará cada una de esas tareas).

3. Area comercial y situación del mercado: Se trata de hacer un análisis de los posibles futuros clientes, competidores y proveedores. En cuanto a los clientes, habrá que definir e identificar las características de nuestro público objetivo o "target", su localización, necesidades y gustos, poder adquisitivo, edad, sexo, etc. Una vez tengamos toda esa información, podremos planificar la política de comunicación (publicidad) más adecuada para informarles de nuestra oferta, la política de distribución más adecuada para hacerles llegar nuestros productos y perfilar las características del producto de manera que éste sea más apetecible para el cliente según sus gustos y necesidades (precio, tamańo o cantidad por unidad de producto, diseńo del envoltorio o envase, ... ). Por lo que se refiere a competidores, habrá que prestarles una cuidadosa atención intentando extraer de ellos toda la información que nos sea posible: - Quiénes son los líderes del mercado y en qué basan sus éxitos. - Qué empresas del sector tienen dificultades y cuáles son las causas. - Cómo podemos ofrecer nuestros productos de forma que resulten más 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. También es conveniente hacer un análisis de posibles proveedores, contactando con diversas empresas y pidiéndoles presupuestos. En ocasiones, los proveedores pueden ser una importante fuente de información sobre las características del

mercado ya que para ellos somos un futuro cliente.

Antes de arriesgar tu dinero en un negocio, realiza tus propios cálculos de

viabilidad empresarial  - CLICK AQUI -

4.

5. El proceso de producción o la organización del servicio: Se ha de describir el proceso que seguirá la empresa para producir sus productos, haciendo una relación de todas las máquinas y herramientas que se necesitarán y sus características (forma de conseguirlas, precio, duración,...). Igualmente habrá que concretar qué materiales o materias primas componen el producto y en qué cantidades, el número de personas necesario en todo el proceso de fabricación (su cualificación, funciones, horario, etc.) y el plazo de producción (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 prestación del servicio. Por último habrá que calcular cuál es la capacidad máxima de productos que, dados los recursos iniciales, la

empresa es capaz de ofrecer.

6. Plan de Fechas: Este apartado exige un esfuerzo de planificación dividiendo 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 país pero que decida centrarse durante el primer ańo en su propia ciudad (durante la puesta en marcha del negocio), para ir ampliando el ámbito geográfico durante los ańos siguientes. O bien, que decida ofrecer sólo 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

de excesivos recursos financieros.

7. Area económico-financiera: El análisis económico y financiero del proyecto empresarial requiere unos conocimientos específicos mínimos, que de no tenerlos ningún miembro del grupo de promotores, hace aconsejable la intervención de un asesor externo (los ayuntamientos, INEM; gobiernos autonómicos, cámaras de

comercio y otros organismos suelen tener servicios de asesoramiento gratuito para la creación 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 mínimas necesarias para poner en marcha el proyecto y cuáles se realizarán posteriormente (publicidad de lanzamiento; estudios técnicos previos necesarios para la puesta en marcha de la empresa; acondicionamiento del local, instalación de teléfono, fax, etc. ; maquinaria, mobiliario, equipos informáticos; fianzas, seguros; ... ).

9. Plan de financiación: de dónde se van a obtener los recursos necesarios para hacer frente a las inversiones (aportaciones de los socios, créditos bancarios, créditos subvencionados, leasing, subvenciones,... ).

10. Previsión de resultados: se trata de realizar una previsión de los beneficios que esperamos obtener en cada uno de los dos ó tres primeros ańos. Para ello es necesario hacer una previsión de los ingresos por las ventas de productos o por la prestación de servicios (precio por cantidad vendida) así como una previsión de gastos anuales (compra de materias primas, sueldos y salarios, alquileres, suministros de agua, gas, luz y teléfono, transportes, intereses de créditos, publicidad y promociones, primas de seguros, tributos, ... ).

11. Análisis de "punto crítico": en ocasiones resulta bastante difícil o arbitrario establecer una cifra concreta de ingresos esperados. Cuando esto ocurre, es muy útil acompańar el estudio del resultado o beneficio previsto con un análisis del punto crítico (también llamado punto muerto o umbral de rentabilidad) que no es más que el cálculo de la cifra mínima de ventas necesaria para que la empresa no incurra en pérdidas 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. Previsión de tesorería: 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 producción, que nos indicará los meses que se tardará en poder vender el producto final resultante de las materias primas compradas hoy). Es importante prestar atención a este aspecto ya que puede ocurrir que una empresa económicamente rentable (con ingresos superiores a los gastos) se encuentre en una situación financieramente difícil (al no disponer de efectivo para hacer frente a sus pagos por no haber cobrado todavía de los clientes). Balance previsional: en el que se refleje la evolución del patrimonio de la empresa desde el momento inicial

hasta pasados los dos o tres ańos siguientes a su puesta en marcha.

12.

13. Aspectos legales: Es importante dejar constancia en el informe de cuál será la forma jurídica de la empresa (sociedad anónima, cooperativa, etc.) o del tipo de relaciones laborales que se establecerán con los trabajadores (según las diferentes tipologías de contratos existentes). Pero también se deben reseńar 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 nińos 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

administración pública).

14. Conclusiones: En este apartado se puede incluir una valoración 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 Definición del producto o servicio que se pretende ofrecer. Aspectos diferenciales respecto de la competencia

1.3 Situación 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 (formación y experiencia)

2.2 Definición de las áreas funcionales de la empresa (organigrama)

3. Análisis del mercado y plan de marketing

3.1 Estudio del cliente

3.1.1 Perfil de cliente (sus características en cuanto a edad, sexo, nivel económico, costumbres, domicilio, etc.)

3.1.2 Necesidades que se pretenden satisfacer: físicas (alimentación, ropa, transporte,...), psicológicas (entretenimiento u ocio, mejorar la imagen,...) o de cualquier otro tipo (educación, ahorro de tiempo o dinero, etc.)

3.2 Definición del producto o servicio

3.2.1 Esencia o contenido del producto

3.2.2 Presentación e imagen del producto (volumen físico o cantidad por unidad, envoltorio, marca, etc.)

3.3 Estudio de la competencia (número de competidores, puntos fuertes en los que éstos basan su oferta y puntos débiles que podríamos mejorar o de los que nos podríamos aprovechar)

3.4 Distribución (cómo se pretende hacer llegar el producto hasta el consumidor final: venta directa a domicilio, por correo, en supermercados, etc.)

3.5 Publicidad y promoción (tipo de publicidad y medios en los que se realizará y frecuencia de los anuncios publicitarios, de folletos o de catálogos, etc.)

3.6 Precio (gama de precios de venta y descuentos a los distribuidores y al consumidor final, teniendo en cuenta el precio máximo que el cliente estará dispuesto a pagar y el precio mínimo en función de los costes de producción)

4. Plan de producción o de operaciones

4.1 Características del proceso de producción o de operaciones a realizar (especificando los que serán realizados por la propia empresa y los que serán subcontratados)

4.2 Planificación 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 (tamańo mínimo, ubicación idónea, etc.)

4.3.2 Equipos técnicos

4.3.3 Recursos humanos (número de empleados, formación y experiencia requeridas, etc.)

4.3.4 Materias primas. Proveedores (cantidades mínimas necesarias en almacén, análisis de los diferentes proveedores, etc.)

5. Plan de fechas

5.1 Fecha prevista para la puesta en marcha del negocio

5.2 Primer ańo (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 ańo)

5.4 Objetivos de la empresa a largo plazo (a partir del cuarto ańo)

6. Plan económico - 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 financiación (detallar el origen de los recursos financieros necesarios para hacer frente a las inversiones relacionadas en el apartado anterior)

6.3 Previsión de resultados y umbral de rentabilidad (se deberán establecer los beneficios esperados, es decir, los ingresos y gastos previstos tanto a corto como a medio y largo plazo)

6.4 Previsión de tesorería (cálculo y planificación 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 jurídica de la empresa, tipo de relaciones laborales con los trabajadores, normativa que afecta en algún aspecto a la venta del producto o servicio en cuanto a su composición, etiquetado, publicidad, etc.)

8. Conclusiones

9. Anexos (copia de aquella documentación que se considere relevante para quien ha de valorar la futura empresa)

http://empresas.arrakis.es/acem/plan_emp.htm#op2

2.4 Planificación de la documentación.

DESCRIPCIÓN Y OBJETIVOSMientras que el Plan de Sistemas de Información tiene como objetivo proporcionar un marco estratégico que sirvade referencia para los Sistemas de Información de un ámbito concreto de una organización, el objetivo del Estudio

de Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a cortoplazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. La solución obtenida comoresultado del estudio puede ser la definición de uno o varios proyectos que afecten a uno o varios sistemas deinformación ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, siprocede, la situación actual.A partir del estado inicial, la situación actual y los requisitos planteados, se estudian las alternativas de solución.Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en laadquisición 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 organización, la inversión arealizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar las distintasalternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación.Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al sistemaobjeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información a tener en cuentaen todo el proceso.Las actividades que engloba este proceso se recogen en la siguiente figura, en la que se indican las actividades quepueden ejecutarse en paralelo y las que precisan para su realización resultados originados en actividades anteriores.

ACTIVIDAD EVS 1: ESTABLECIMIENTO DELALCANCE DEL SISTEMAEn esta actividad se estudia el alcance de la necesidad planteada por el cliente o usuario, o como consecuencia de larealización de un PSI, realizando una descripción general de la misma. Se determinan los objetivos, se inicia elestudio de los requisitos y se identifican las unidades organizativas afectadas estableciendo su estructura.Se analizan las posibles restricciones, tanto generales como específicas, que puedan condicionar el estudio y laplanificación de las alternativas de solución que se propongan.Si la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y no existeninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizandoposibles alternativas y realizando una valoración y evaluación de las mismas, sino que éste se orientará a laespecificación de requisitos, descripción del nuevo sistema y planificación.Se detalla la composición del equipo de trabajo necesario para este proceso y su planificación. Finalmente, con el finde facilitar la implicación activa de los usuarios en la definición del sistema, se identifican sus perfiles, dejandoclaras sus tareas y responsabilidades.

Tarea EVS 1.1: Estudio de la SolicitudSe realiza una descripción general de la necesidad planteada por el usuario, y se estudian las posibles restriccionesde carácter económico, técnico, 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 lasrestricciones identificadas anteriormente.Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de Información vigente, se debe detomar como referencia el catálogo de requisitos y la arquitectura de información resultante del mismo, comoinformación adicional para la descripción general del sistema y determinación de los requisitos iniciales.ProductosDe entradaCatálogo de Requisitos del PSI (PSI 9.2)Arquitectura de Información (PSI 9.2)Solicitud (externo)De salidaDescripción General del SistemaCatálogo de Objetivos del EVSCatálogo de RequisitosPrácticasCatalogaciónSesiones de trabajoParticipantesComité de DirecciónJefe de ProyectoAnalistas

Tarea EVS 1.2: Identificación del Alcance del SistemaSe analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronización conotros proyectos, que puedan interferir en la planificación y futura puesta a punto del sistema objeto del estudio. Estainformación se recoge en el catálogo de requisitos.Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, se debe tener en cuenta la arquitectura deinformación propuesta para analizar el alcance del sistema e identificar los sistemas de información que quedanfuera del ámbito del estudio. Además, se estudia el plan de proyectos, para determinar las posibles dependencias conotros proyectos.Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, así como suestructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a quiénes afectadirectamente y quiénes pueden influir en el éxito o fracaso del mismo.ProductosDe entradaPlan de Proyectos (PSI 9.2)Arquitectura de Información (PSI 9.2)Descripción General del Sistema (EVS 1.1)Catálogo de Objetivos del EVS (EVS 1.1)Catálogo de Requisitos (EVS 1.1)De salidaDescripción General del Sistema:o Contexto del Sistemao Estructura OrganizativaCatálogo de Requisitos:o Requisitos Relativos a Restricciones o Dependencias con Otros ProyectosCatálogo de UsuariosTécnicas

Diagrama de Flujo de DatosDiagrama de Descomposición FuncionalPrácticasCatalogaciónSesiones de trabajoParticipantesComité de DirecciónJefe de ProyectoAnalistas

Tarea EVS 1.3: Especificación del Alcance del EVSEn función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan lasactividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situación actual y, enel caso de considerarlo necesario, con qué objetivo. Si el sistema pertenece al ámbito de un Plan de Sistemas deInformación, los criterios que pueden orientar sobre la necesidad de llevar a cabo el estudio de la situación actualdependen de la arquitectura de información propuesta, en cuanto a la identificación de los sistemas de informaciónactuales, 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 realización delEstudio 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 aceptación y esperado su confirmación.ProductosDe entradaArquitectura de Información (PSI 9.2)Catálogo de Objetivos del EVS (EVS 1.1)Descripción General del Sistema (EVS 1.2)Catálogo de Usuarios (EVS 1.2)De salidaCatálogo de Objetivos del EVS:

o Objetivos del Estudio de la Situación ActualCatálogo de UsuariosPlan de TrabajoPrácticasCatalogaciónSesiones de trabajoParticipantesComité de DirecciónJefe de ProyectoAnalistas

ACTIVIDAD EVS 2: ESTUDIO DE LA SITUACIÓNACTUALLa situación actual es el estado en el que se encuentran los sistemas de información existentes en el momento en elque se inicia su estudio.Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de la informaciónexistente acerca de los sistemas de información afectados. En función de dicha valoración, se especifica el nivel de

detalle con que se debe llevar a cabo el estudio. Si es necesario, se constituye un equipo de trabajo específico para surealización y se identifican los usuarios participantes en el mismo.Si se decide documentar la situación actual, normalmente es conveniente dividir el sistema actual en subsistemas. Sies posible se describirá cada uno de los subsistemas, valorando qué información puede ser relevante para ladescripción.Como resultado de esta actividad se genera un diagnóstico, estimando la eficiencia de los sistemas de informaciónexistentes e identificando los posibles problemas y las mejoras.

Tarea EVS 2.1: Valoración del Estudio de la Situación ActualEn función de los objetivos establecidos para el estudio de la situación actual, y considerando el contexto delsistema especificado en la descripción general del mismo, se identifican los sistemas de información existentes quees necesario analizar con el fin de determinar el alcance del sistema actual. Asimismo, se decide el nivel de detallecon el que se va a llevar a cabo el estudio de cada uno de los sistemas de información implicados. En el caso dehaber realizado un Plan de Sistemas de Información que afecte a dicho sistema, se toma como punto de partida paraeste análisis la arquitectura de información propuesta.Para poder abordar el estudio, se realiza previamente una valoración de la información existente acerca de lossistemas de información afectados por el EVS. Se debe decidir si se realizan o no los modelos lógicos del sistemaactual o si se describe el modelo físico, en función de los siguientes criterios:Si existen los modelos lógicos, y son fiables, se utilizan en la tarea Descripción de los Sistemas deInformación Existentes (EVS 2.3)Si no existen dichos modelos, o no son fiables, se considera el tiempo de vida estimado para el sistema de

información en función de la antigüedad, la obsolescencia de la tecnología o la falta de adecuación funcionalpara determinar sí se obtienen los modelos lógicos y físicos del sistema actual o por el contrario no se elaboraningún modelo.La información relativa a los sistemas de información que se decida analizar, se obtiene mediante sesiones detrabajo con los Directores de Usuarios y el apoyo de los profesionales de Sistemas y Tecnologías de la Informacióny Comunicaciones (STIC) que se considere necesario.ProductosDe entradaInformación Existente del Sistema Actual (externo)Arquitectura de Información (PSI 9.2)Catálogo de Objetivos del EVS (EVS1.3)Descripción General del Sistema (EVS 1.2)De salidaDescripción de la Situación Actual:o Contexto del Sistema Actualo Descripción de los Sistemas de Información ActualesTécnicasDiagrama de Flujo de DatosPrácticasDiagrama de RepresentaciónSesiones de TrabajoParticipantesJefe de ProyectoAnalistasDirectores de Usuarios

Tarea EVS 2.2: Identificación de los Usuarios Participantes en elEstudio de la Situación ActualEn función del nivel de detalle establecido para el estudio de la situación actual, se identifican los usuariosparticipantes de cada una de las unidades organizativas afectadas por dicho estudio. Se informa a los usuariosidentificados como implicados en el Estudio de la Situación Actual, se solicita su aceptación y se espera suconfirmación.

ProductosDe entradaDescripción General del Sistema (EVS 1.2)Catálogo de Usuarios (EVS 1.3)Descripción de la Situación Actual (EVS 2.1)De salidaCatálogo de UsuariosPrácticasCatalogaciónSesiones de TrabajoParticipantesJefe de ProyectoDirectores de Usuarios

Tarea EVS 2.3: Descripción de los Sistemas de Información ExistentesEn esta tarea se describen los sistemas de información existentes afectados, según el alcance y nivel de detalleestablecido en la tarea Valoración del Estudio de la Situación Actual (EVS 2.1), mediante sesiones de trabajo conlos usuarios designados para este estudio.

Si se ha decidido describir los sistemas a nivel lógico, y si existe un conocimiento suficiente de los sistemas deinformación a especificar, puede hacerse directamente, aplicando las técnicas de modelización y siguiendo unmétodo descendente. Si no se dispone del conocimiento suficiente, se construyen los modelos a partir de ladescripción del modelo físico, es decir, de forma ascendente.Si se tiene que describir el modelo físico, se puede hacer mediante un Diagrama de Representación en el que serecojan todos los componentes físicos y sus referencias cruzadas. Otra opción es describir el modelo físico de formamás detallada, para lo que es necesaria la utilización de herramientas de tipo scanner.Es conveniente indicar la localización geográfica y física actual de los módulos y datos de los sistemas deinformación afectados, evaluando al mismo tiempo la redundancia en las distintas unidades organizativas.ProductosDe entradaDescripción de la Situación Actual (EVS 2.1)Catálogo de Usuarios (EVS 2.2)De salidaDescripción de la Situación Actual:o Descripción Lógica del Sistema Actualo Modelo Físico del Sistema Actual (opcional)o Matriz de Localización Geográfica y Física de Módulos y Datos, incluidas las redundanciasTécnicasDiagrama de Flujo de DatosModelo Entidad/ Relación extendidoDiagrama de ClasesDiagrama de Interacción de ObjetosMatricialPrácticasDiagrama de RepresentaciónSesiones de TrabajoParticipantesAnalistasUsuarios ExpertosEquipo de Soporte Técnico

Tarea EVS 2.4: Realización del Diagnóstico de la Situación ActualCon el fin de elaborar el diagnóstico de la situación actual se analiza la información de los sistemas de informaciónexistentes, obtenida en la tarea anterior y se identifican problemas, deficiencias y mejoras. Estas últimas debentenerse en cuenta en la definición de los requisitos.8 Estudio de Viabilidad del Sistema© Ministerio de Administraciones Públicas Metodología MÉTRICA Versión 3En el caso de haber realizado un Plan de Sistemas de Información, se considera la valoración realizada sobre lossistemas de información actuales que pertenecen al ámbito de este estudio.Si se ha tomado la decisión de no describir la situación actual, se realiza un diagnóstico global justificando estadecisión.ProductosDe entradaDescripción de la Situación Actual (EVS 2.3)Catálogo de Objetivos del EVS (EVS 1.3)Valoración de la Situación actual (PSI 5.3)De salida

Descripción de la Situación Actual:o Diagnóstico de Situación ActualParticipantesAnalistasResponsable de Mantenimiento

ACTIVIDAD EVS 3: DEFINICIÓN DE REQUISITOS DELSISTEMAEsta actividad incluye la determinación de los requisitos generales, mediante una serie de sesiones de trabajo con losusuarios participantes, que hay que planificar y realizar. Una vez finalizadas, se analiza la información obtenidadefiniendo los requisitos y sus prioridades, que se añaden al catálogo de requisitos que servirá para el estudio yvaloración de las distintas alternativas de solución que se propongan.

Tarea EVS 3.1: Identificación de las Directrices Técnicas y de GestiónLa realización de esta tarea permite considerar los términos de referencia para el sistema en estudio desde el puntode vista de directrices tanto técnicas como de gestión. Si el sistema en estudio pertenece al ámbito de un Plan deSistemas de Información vigente, éste proporciona un marco de referencia a considerar en esta tarea.Con este fin, se recoge información sobre los estándares y procedimientos que deben considerarse al proponer unasolución, relativos a:Políticas técnicas:Gestión de Proyectos (seguimiento, revisión y aprobación final).Desarrollo de Sistemas (existencia de normativas, metodologías y técnicas de programación).Arquitectura de Sistemas (centralizada, distribuida).Política de Seguridad (control de accesos, integridad de datos, disponibilidad de aplicaciones).Directrices de Planificación.Directrices de Gestión de Cambios.Directrices de Gestión de Calidad.ProductosDe entradaCatálogo de Normas del PSI (PSI 3.2)Estudio de Viabilidad del Sistema 9© Ministerio de Administraciones Públicas Metodología MÉTRICA Versión 3Recopilación de Directrices Técnicas y de Gestión (externo)De salida

Catálogo de NormasPrácticasCatalogaciónParticipantesJefe de ProyectoAnalistasUsuarios Expertos

Tarea EVS 3.2: Identificación de RequisitosPara la obtención de las necesidades que ha de cubrir el sistema en estudio, se debe decidir qué tipo de sesiones detrabajo se realizarán y con qué frecuencia tendrán lugar, en función de la disponibilidad de los usuariosparticipantes.Si se ha realizado el Estudio de la Situación Actual (EVS 2), puede ser conveniente seleccionar la información delos sistemas de información existentes que resulte de interés para el desarrollo de dichas sesiones de trabajo.Una vez establecidos los puntos anteriores, se planifican las sesiones de trabajo con los usuarios participantesidentificados al estudiar el alcance del Estudio de Viabilidad del Sistema (EVS 1.3), y se realizan de acuerdo al planprevisto. La información obtenida depende del tipo de sesión de trabajo seleccionado.ProductosDe entradaDescripción General del Sistema (EVS 1.2)Catálogo de Requisitos (EVS 1.2)Equipo de Trabajo del EVS (EVS 1.3)Catálogo de Usuarios (EVS 2.2/1.3)Descripción de la Situación Actual (EVS 2.4)De salidaIdentificación de RequisitosPrácticasSesiones de TrabajoParticipantesJefe de ProyectoAnalistasUsuarios Expertos

Tarea EVS 3.3: Catalogación de RequisitosSe analiza la información obtenida en las sesiones de trabajo para la Identificación de Requisitos, definiendo ycatalogando los requisitos (funcionales y no funcionales) que debe satisfacer el sistema, indicando sus prioridades.Se incluirán también requisitos relativos a distribución geográfica y entorno tecnológico.ProductosDe entradaIdentificación de Requisitos (EVS 3.2)Catálogo de Requisitos (EVS 1.2)De salidaCatálogo de RequisitosPrácticasCatalogaciónParticipantesJefe de ProyectoAnalistasUsuarios Expertos

ACTIVIDAD EVS 4: ESTUDIO DE ALTERNATIVAS DESOLUCIÓNEste estudio se centra en proponer diversas alternativas que respondan satisfactoriamente a los requisitos planteados,considerando también los resultados obtenidos en el Estudio de la Situación Actual (EVS 2), en el caso de que sehaya realizado.Teniendo en cuenta el ámbito y funcionalidad que debe cubrir el sistema, puede ser conveniente realizar,previamente a la definición de cada alternativa, una descomposición del sistema en subsistemas.En la descripción de las distintas alternativas de solución 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 amedida, se debe incorporar en la descripción de la misma un modelo abstracto de datos y un modelo de procesos, yen orientación a objetos, un modelo de negocio y un modelo de dominio.

Tarea EVS 4.1: Preselección de Alternativas de Solución

Una vez definidos los requisitos a cubrir por el sistema, se estudian las diferentes opciones que hay para configurarla solución. Entre ellas, hay que considerar la adquisición de productos software estándar del mercado, desarrollos amedida o soluciones mixtas.Dependiendo del alcance del sistema y las posibles opciones, puede ser conveniente realizar inicialmente unadescomposición del sistema en subsistemas. Se establecen las posibles alternativas sobre las que se va a centrar elestudio de la solución, combinando las opciones que se consideren más adecuadas.ProductosDe entradaInformación de Productos Software del Mercado (externo)Descripción General del Sistema (EVS 1.2)Descripción de la Situación Actual (EVS 2.4)Catálogo de Requisitos (EVS 3.3)De salidaDescomposición Inicial del Sistema en Subsistemas (opcional)Alternativas de Solución a EstudiarPrácticasDiagrama de RepresentaciónParticipantesJefe de ProyectoAnalistasTécnicos de Sistemas

Tarea EVS 4.2: Descripción de las Alternativas de SoluciónPara cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos a los que se da respuesta.Se deben considerar también aspectos relativos a la cobertura geográfica (ámbito y limitaciones) de procesos ydatos, teniendo en cuenta a su vez la gestión de comunicaciones y control de red.En la definición de cada alternativa, se propone una estrategia de implantación teniendo en cuenta tanto la coberturaglobal del sistema como la cobertura geográfica.Si la alternativa incluye desarrollo se describe el modelo abstracto de datos y el modelo de procesos, y en el caso deOrientación a Objetos, el modelo de negocio y, opcionalmente, el modelo de dominio. Se propone el entornotecnológico que se considera más apropiado para la parte del sistema basada en desarrollo y se describen losprocesos manuales.Si la alternativa incluye una solución basada en producto se analiza su evolución prevista, adaptabilidad yportabilidad, así como los costes ocasionados por licencias, y los estándares del producto. Igualmente se valora ydetermina su entorno tecnológico.ProductosDe entradaDescripción General del Sistema (EVS 1.2)Descripción de la Situación Actual (EVS 2.4)Catálogo de Requisitos (EVS 3.3)Descomposición Inicial del Sistema en Subsistemas (EVS 4.1) (opcional)Alternativas de Solución a Estudiar (EVS 4.1)De salidaCatálogo de Requisitos (actualizado)Alternativas de Solución a Estudiar:o Catálogo de Requisitos (cobertura)o Modelo de Descomposición en Subsistemas

o Matriz Procesos / Localización Geográficao Matriz Datos / Localización Geográficao Entorno Tecnológico y Comunicacioneso Estrategia de Implantación Global del Sistemao Descripción de Procesos ManualesSi la alternativa incluye desarrollo:o Modelo Abstracto de Datos / Modelo de Procesoso Modelo de Negocio / Modelo de Dominio (en caso de Orientación a Objetos)Si la alternativa incluye un producto software estándar de mercado:o Descripción del Productoo Evolución del Productoo Costes Ocasionados por Productoo Estándares del Productoo Descripción de Adaptación (si es necesaria)TécnicasMatricialDiagrama de Flujo de DatosModelo Entidad/ Relación extendidoDiagrama de ClasesCasos de UsoPrácticasCatalogaciónDiagrama de RepresentaciónParticipantesJefe de ProyectoAnalistasUsuarios ExpertosTécnicos de SistemasResponsable de SeguridadEspecialistas en Comunicaciones

ACTIVIDAD EVS 5: VALORACIÓN DE LASALTERNATIVASUna vez descritas las alternativas se realiza una valoración de las mismas, considerando el impacto en laorganización, tanto desde el punto de vista tecnológico y organizativo como de operación, y los posibles beneficiosque se esperan contrastados con los costes asociados. Se realiza también un análisis de los riesgos, decidiendo cómoenfocar el plan de acción para minimizar los mismos y cuantificando los recursos y plazos precisos para planificarcada alternativa.

Tarea EVS 5.1: Estudio de la InversiónPara cada alternativa de solución propuesta, se valora el impacto en la organización y se establece su viabilidadeconómica. Para ello, se realiza un análisis coste/beneficio que determina los costes del sistema y los pondera conlos beneficios tangibles, cuantificables directamente, y con los beneficios intangibles, buscando el modo decuantificarlos.ProductosDe entradaAlternativas de Solución a Estudiar (EVS 4.2)De salidaValoración de Alternativas:Impacto en la Organización de Alternativaso Coste / beneficio de AlternativasTécnicasAnálisis Coste / BeneficioParticipantesJefe de ProyectoAnalistas

Tarea EVS 5.2: Estudio de los RiesgosPara cada alternativa se seleccionan los factores de situación que habrá que considerar, relativos tanto a laincertidumbre como a la complejidad del sistema. Se identifican y valoran los riesgos asociados y se determinan lasmedidas a tomar para minimizarlos.ProductosDe entradaAlternativas de Solución a Estudiar (EVS 4.2)Valoración de Alternativas (EVS 5.1)De salidaValoración de Alternativas:o Valoración de RiesgosPrácticasImpacto en la OrganizaciónParticipantesJefe de ProyectoAnalistas

Tarea EVS 5.3: Planificación de AlternativasEn función del análisis de riesgos realizado en la tarea anterior, y para cada una de las alternativas existentes:

Se determina el enfoque más adecuado para llevar a buen fin la solución propuesta en cada alternativa.Se realiza una planificación, teniendo en cuenta los puntos de sincronismo con otros proyectos en desarrolloo que esté previsto desarrollar, según se ha recogido en el catálogo de requisitos.De esta manera se garantiza el cumplimiento del plan de trabajo en los restantes procesos del ciclo de vida.ProductosDe entradaCatálogo de Requisitos (EVS 4.2)Alternativas de Solución a Estudiar (EVS 4.2)Valoración de Alternativas (EVS 5.2)De salidaPlan de Trabajo de Cada Alternativa:o Enfoque del Plan de Trabajo de Cada Alternativao Planificación de Cada AlternativaTécnicasPlanificaciónParticipantesJefe de ProyectoAnalistas

ACTIVIDAD EVS 6: SELECCIÓN DE LA SOLUCIÓNAntes de finalizar el Estudio de Viabilidad del Sistema, se convoca al Comité de Dirección para la presentación delas distintas alternativas de solución, resultantes de la actividad anterior. En dicha presentación, se debaten lasventajas de cada una de ellas, incorporando las modificaciones que se consideren oportunas, con el fin deseleccionar la más adecuada. Finalmente, se aprueba la solución o se determina su inviabilidad.

Tarea EVS 6.1: Convocatoria de la PresentaciónSe efectúa la convocatoria de la presentación de las distintas alternativas propuestas, adjuntando los productos de laactividad anterior con el fin de que el Comité de Dirección pueda estudiar previamente su contenido. Se esperaconfirmación por parte del Comité de Dirección de las alternativas a presentar.ProductosDe entradaCatálogo de Usuarios (EVS 2.2/1.3)

Alternativas de Solución a Estudiar (EVS 4.2)Valoración de Alternativas (EVS 5.2)Plan de Trabajo de Cada Alternativa (EVS 5.3)De salidaPlan de Presentación de AlternativasPrácticasPresentaciónParticipantesJefe de Proyecto

Tarea EVS 6.2: Evaluación de las Alternativas y SelecciónUna vez recibida la confirmación de qué alternativas van a ser presentadas para su valoración, se efectúa supresentación al Comité de Dirección, debatiendo sobre las ventajas e inconvenientes de cada una de ellas yrealizando las modificaciones que sugiera dicho Comité, hasta la selección de la solución final.ProductosDe entradaDescripción General del Sistema (Contexto del Sistema) (EVS 1.2)Catálogo de Requisitos (EVS 4.2)Alternativas de Solución a Estudiar (EVS 4.2)Valoración de Alternativas (EVS 5.2)Plan de Trabajo de Cada Alternativa (EVS 5.3)Plan de Presentación de Alternativas (EVS 6.1)De salidaPlan de Presentación de AlternativasCatálogo de Requisitos (Actualizado en Función de la Cobertura de la Solución)Solución Propuesta:o Descripción de la SoluciónModelo de Descomposición en SubsistemasMatriz Procesos / Localización GeográficaMatriz Datos / Localización GeográficaEntorno Tecnológico y ComunicacionesEstrategia de Implantación Global del SistemaDescripción de Procesos ManualesSi la alternativa incluye desarrollo:Modelo Abstracto de Datos / Modelo de ProcesosModelo de Negocio / Modelo de DominioSi la alternativa incluye un producto software estándar de mercado:Descripción del ProductoEvolución del ProductoCostes Ocasionados por ProductoEstándares del ProductoDescripción de Adaptación (si es necesaria)o Contexto del Sistema (con la Definición de las Interfaces en Función de la Solución)o Impacto en la Organización de la Solucióno Coste / Beneficio de la Solucióno Valoración de Riesgos de la Solucióno Enfoque del Plan de Trabajo de la Solucióno Planificación de la SoluciónPrácticasPresentaciónSesiones de TrabajoParticipantesComité de DirecciónJefe de ProyectoAnalistas

Tarea EVS 6.3: Aprobación de la SoluciónEl Comité de Dirección da su aprobación formal o determina la inviabilidad del sistema, por motivos económicos,de funcionalidad como resultado del incumplimiento de los requisitos identificados en plazos razonables o decobertura de los mismos, etc.ProductosDe entradaCatálogo de Requisitos (EVS 6.2)Solución Propuesta (EVS 6.2)De salidaAprobación de la SoluciónParticipantesComité de DirecciónJefe de Proyecto

http://www.csi.map.es/csi/metrica3/evs.pdf

2.5 Gestión de la configuración del software.

La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, consiguiendo la visibilidad del producto y facilitando el resto de procesos de producción. En este artículo se muestra cómo se ha elaborado un Plan de Gestión de Configuración del Software para un proyecto de I+D en colaboración entre Empresa y Universidad. Los iniciales planteamientos de realización 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

producción realizado por la empresa fueron dando paso la definición 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

Gestión de la Configuración del Software

Práctica de GCSWObjetivo de la Práctica

Definir y desarrollar el plan de gestión de la configuración del proyecto XXXX

CONTENIDO

1. Elaborar el plan de gestión de configuración para un proyecto.

2. Desarrollar el plan de gestión de configuración poniendo en práctica los procedimientos y herramientas para la evaluación controlada del proyecto.

3. Crear y mantener la línea base del proyecto e integrar el sistema final y las versiones intermedias.

Descripción de la Práctica

Esta práctica consiste en la aplicación de los conocimientos adquiridos durante las clases de Gestión de Configuración a un proyecto de Ingeniería del Software. Se van a desarrollar todos los pasos del desarrollo de un caso de estudio tratado en la asignatura Análisis y Diseño Orientado a Objetos, desde la Especificación de los Requisitos hasta la implementación y prueba, ejecutando simultáneamente las actividades correspondientes a la Gestión de la Configuración de un proyecto.

Para poder desarrollar la práctica Ud podrá consultar los documentos siguientes:

Plantilla de elaboración del Plan de Gestión de Configuración (planscm-SCMP-SCMCorto)

Preguntas y acciones a ejecutar (FAQ)

En Módulo 5 podrá ver las actividades que plantea CMM, además de lo explicado de las experiencias de PSL.

Para llevar a cabo dichos objetivos, se proporciona la descripción 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 Gestión de Configuración del Software, pero para la práctica se hará así, dado que parece desmesurado desarrollar el sistema completo únicamente para aplicar lo aprendido en este tema.

Para su realización 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 según procede, ha de venir soportado por una “petición de cambio” que la ampare con su correspondiente tramitación. En todos los casos habrá que rellenar

completamente el formulario del documento correspondiente (informe de problema y/o petición de cambio).

Asimismo ha de tenerse en cuenta la necesidad de mantener actualizada la “línea base” (contenidos, versiones, etc) según se van realizando las modificaciones. Para ello utilizará la herramienta Visual Source Safe impartida en clase. Con esta herramienta gestione la configuración y construya un repositorio con control de versiones para documentos, diseño, pruebas y código fuente. Construya un ejecutable a partir de módulos extraidos del repositorio anterior.

Planteamiento del Problema

Dentro del sistema XXXX con el que se ha venido trabajando en ADOO, para la práctica de Gestión de Configuración del Software nos vamos a centrar en una pequeña funcionalidad: XXXX.

Trabajo a Realizar

Como se ha indicado anteriormente, la práctica consiste en el desarrollo de la funcionalidad de XXXX, haciendo especial hincapié en las actividades de Gestión de Configuración del Software que se realizarían a lo largo de todo este proceso.

Lo primero que deberá elaborar el equipo de desarrollo es un Plan de Gestión de Configuración para este pseudo-sistema. En dicho plan se deberá identificar la configuración del sistema (estructura y componentes del producto software, nivel de visibilidad, selección de ECS, definición del esquema de identificación – para ECS, versiones, variantes, configuraciones alternativas, releases –, y selección de relaciones en la configuración a mantener); se deberá identificar la línea base; y se deberán proponer los mecanismos de accesibilidad a los ECS (definición de bibliotecas software).

A continuación, el equipo deberá comenzar con el proceso de desarrollo en sí, aplicando la metodología explicada en ADOO.

Además, 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, deberán gestionarse los procedimientos de Gestión de Configuración, identificando y etiquetando ECS, versiones, variantes y configuraciones alternativas producidas, estableciendo líneas base, manteniendo las relaciones de la configuración y manteniéndolas bibliotecas software.

Debe tenerse en cuenta que esta funcionalidad será parte del sistema total de XXXX, y que no es preciso diseñar una interfaz compleja de usuario, puesto que al final sólo se comunicará con otros módulos del sistema. Por tanto, todas las entradas que procedieran de otros módulos del sistema, se deberán simular como entrada provisional del usuario.

Documentación a Entregar

La memoria de la práctica constará de un único documento, dividido en tres partes diferenciadas, que deberán incluir los siguientes apartados:

PARTE I: Plan de Gestión de Configuración

1. Introducción

I.A. Alcance y Propósito del Documento

I.B. Objetivos del Proyecto para el que se Gestiona la Configuración

I.C. Organización y Responsabilidades

2. Actividades de Gestión de Configuración

II.A. Selección de los ECS

Descripción, etiquetas y relaciones o trazabilidad de los ECS que se van a poner bajo control de configuración. Justificación de la elección.

II.B. Esquema de Identificación de los ECS

Explicación del esquema de identificación que se va a utilizar (para ECS, versiones, variantes, configuraciones alternativas y releases). Especificar dónde y cómo se va a guardar esta identificación. Explicar cada tipo de código utilizado.

II.C. Descripción de las Relaciones a Mantener entre los ECS

Especificar dónde y cómo se va a mantener esta información.

II.D. Definición y Establecimiento de Líneas Base

Descripción de las líneas base a establecer (nombre, momento de establecimiento y composición).

II.E. Definición y Establecimiento de Bibliotecas Software

Descripción de las bibliotecas software a utilizar. Dónde va a estar cada una de ellas. Procedimientos y criterios de transición de una a otra. Quién va a realizar la tarea de bibliotecario.

PARTE II: Desarrollo del proyecto XXXX según ADOO

PARTE III: Informes del Estado de la Configuración

1. Inventario de ECS que se han creado hasta el momento

Incluir, por lo menos, para cada ECS, la línea base, módulo, código del ECS, versión, fecha de creación y descripción.

2. Inventario de versiones que se han creado hasta el momento

Incluir, por lo menos, para cada versión, el módulo, código del ECS, versión, fecha de creación, autor y número de copias.

3. Inventario de copias que se han creado hasta el momento

Incluir, por lo menos, para cada copia, el módulo, código del ECS, versión, número de copia, tipo de ECS y localización.

4. Inventario de líneas base que se han creado hasta el momento

Incluir, por lo menos, para cada línea base, la línea base, código de los ECS aprobados, fecha de cierre y localización.

5. Contenido de la base de datos de relaciones entre ECS

Incluir, por lo menos, las relaciones de composición, dependencia y derivación, y hacer mención que las relaciones de equivalencia se hallan reflejadas en el Inventario de copias y las de sucesión en el Inventario de versiones.

6. Especificación de las configuraciones alternativas que se tengan hasta el momento

Incluir, por lo menos, para cada configuración alternativa, el código de la configuración, y los ECS que la componen, con su correspondiente versión.

7. Descripción del contenido actual de cada una de las bibliotecas software

Incluir, por lo menos, la descripción de las bibliotecas de trabajo, de integración, de soporte al proyecto y maestra.

Conclusiones

Anexos

REGISTRO DE DEFECTOS

Grupo: Hoja: Fecha Número Tipo Introducido Eliminado Tiempo elim. Arreg. def. Detectado por

Descripción:

Fecha Número Tipo Introducido Eliminado Tiempo elim. Arreg. def. Detectado por

Descripción:

Fecha Número Tipo Introducido Eliminado Tiempo elim. Arreg. def. Detectado por

Descripción:

Fecha Número Tipo Introducido Eliminado Tiempo elim. Arreg. def. Detectado por

Descripción:

Fecha Número Tipo Introducido Eliminado Tiempo elim. Arreg. def. Detectado por

Descripción:

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

3 Análisis del proyecto.

ANALISIS DE SISTEMAS DE COMPUTACION

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

TEMA II. Análisis de Sistemas de Computación.

DESARROLLO.

2.1 Conceptos y Análisis:

Es un conjunto o disposición 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 lógico en la unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. También es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Información. Esto se lleva a cabo teniendo en cuenta ciertos principios:

Debe presentarse y entenderse el dominio de la información de un problema.

Defina las funciones que debe realizar el Software. Represente el comportamiento del software a consecuencias de acontecimientos externos. Divida en forma jerárquica los modelos que representan la información, funciones y

comportamiento.

 

El proceso debe partir desde la información esencial hasta el detalle de la Implementación.

La función del Análisis 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 documentación que hacen efectiva la logística metodología o controles de requerimientos del Programa.

Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una función externa dentro de los Sistemas.

Personal, son los operadores o usuarios directos de las herramientas del Sistema. Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema a

las que se accede por medio del Software. Documentación, Manuales, formularios, y otra información descriptiva que detalla o da

instrucciones sobre el empleo y operación 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 Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente:

Identifique las necesidades del Cliente. Evalúe que conceptos tiene el cliente del sistema para establecer su viabilidad. Realice un Análisis Técnico y económico. Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del

Sistema. Establezca las restricciones de presupuestos y planificación temporal. Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.

 

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, así como de la Ingeniería humana (Manejo y Administración de personal), y administración de base de datos.

2.2 Objetivos del Análisis.

2.2.1 Identificación de Necesidades.

Es el primer paso del análisis del sistema, en este proceso en Analista se reúne 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

planificación temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto.

 

Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y lo dividen en cinco partes:

Reconocimiento del problema. Evaluación y Síntesis. Modelado. Especificación. Revisión.

 

Antes de su reunión con el analista, el cliente prepara un documento conceptual del proyecto, aunque es recomendable que este se elabore durante la comunicación Cliente – analista, ya que de hacerlo el cliente solo de todas maneras tendría que ser modificado, durante la identificación 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 materialización sin tener perdidas económicas y frustración profesional. La viabilidad y el análisis de riesgos están 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 interés:

 

 

1. Viabilidad económica.

Una evaluación de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado.

2. Viabilidad Técnica.

Un estudio de funciones, rendimiento y restricciones que puedan afectar la realización de un sistema aceptable.

3. Viabilidad Legal.

Es determinar cualquier posibilidad de infracción, violación o responsabilidad legal en que se podría incurrir al desarrollar el Sistema.

Alternativas. Una evaluación 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 Análisis Económico y Técnico.

El análisis económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema.

 

Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la características del Sistema. El análisis de costos – beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto.

En el Análisis Técnico, el Analista evalúa los principios técnicos del Sistema y al mismo tiempo recoge información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad.

 

Los resultados obtenidos del análisis técnico 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 idéntico, pero en menor escala (mas pequeño).

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 notación gráfica, información y comportamiento del Sistema.

Todos los Sistemas basados en computadoras pueden modelarse como transformación de la información empleando una arquitectura del tipo entrada y salida.

2.2.5 Especificaciones del Sistema.

Es un Documento que sirve como fundamento para la Ingeniería Hardware, software, Base de datos, e ingeniería Humana. Describe la función y rendimiento de un Sistema basado en computadoras y las dificultades que estarán presente durante su desarrollo. Las Especificaciones de los requisitos del software se produce en la terminación de la tarea del análisis.

 

 

 

En Conclusión un proyecto de desarrollo de un Sistema de Información comprende varios componentes o pasos llevados a cabo durante la etapa del análisis, 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, documentación y procedimientos.

 

3.1 Análisis de riesgos.

¿Qué es un análisis de riesgos? Las graves crisis alimentarias que han azotado Europa recientemente han suscitado un intenso debate acerca de la seguridad del suministro de alimentos. También han dado lugar a la creación de la Autoridad Europea de Seguridad Alimentaria (European Food Safety Authority, EFSA). La EFSA se hará cargo de la evaluación científica de riesgos, mientras que las decisiones en materia de gestión de riesgos son competencia de los legisladores y políticos de la Unión Europea. Los riesgos son evaluados y gestionados en el marco del denominado “análisis de riesgos”. Este artículo explica en qué consiste.

¿Tenemos claro lo que queremos decir con el término “riesgo”? Una definición sería “la probabilidad del advenimiento de un acontecimiento adverso, problema o daño y las consecuencias del mismo”. Evaluar riesgos y determinar la mejor manera de gestionarlos en la compleja y amplia escala de la Unión Europea constituye un gran desafío. Es difícil 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 análisis de riesgos es una forma sistemática de evaluar mejor los riesgos, lograr transparencia en su complejidad y resolver las dudas o lagunas. Este sistema facilita la adopción de decisiones en materia de gestión de riesgos y su comunicación. El análisis de riesgos está compuesto de tres etapas: evaluación de riesgos, gestión de riesgos y comunicación de riesgos.

Evaluación de riesgos

En lo que respecta a la alimentación, el riesgo implica un impacto potencial en los consumidores. Los microorganismos infecciosos, las sustancias químicas contaminantes (por ejemplo, los productos de limpieza) o los agentes físicos (como el cristal) entrañan 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

evaluación 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 términos absolutos (por ejemplo, calculando el número de consumidores que enferman cada año por comer determinados productos) o en términos relativos (por ejemplo, comparando la seguridad de un producto con la de otro).

Gestión de riesgos

Los gestores de riesgos dirigen el análisis de riesgos, deciden si la evaluación de un riesgo es necesaria o no para resolver un problema y apoyan a los evaluadores en su trabajo. Una vez realizada la evaluación, los gestores de riesgos se basan en el resultado para decidir qué medidas hay que tomar. Cuando es preciso reducir el riesgo, la gestión de riesgos debe optar por las mejores medidas posibles para lograrlo.

Comunicación de riesgos

En el análisis de riesgos, existen diferentes tipos de comunicación importantes. Los aspectos técnicos se debaten entre gestores, evaluadores y partes interesadas del sector privado. A la hora de decidir cuál es la mejor manera de controlar un riesgo y de ejecutar las decisiones, la comunicación entre los gestores de riesgos y los sectores público y privado es muy importante. Este debate es menos técnico y tiene en cuenta, por ejemplo, puntos de vista éticos, sociales y económicos. A fin de tomar una decisión que se adecue al objetivo y sea aceptable para todas las partes interesadas, la gestión de riesgos debe asegurar una comunicación adecuada. Mucha gente opina que la comunicación de riesgos no es más que una actividad de relaciones públicas, pero la verdad es que la disciplina ha evolucionado de forma independiente, sobre todo gracias a las teorías de la percepción de riesgos. La percepción de riesgos hace referencia a una amplia serie de estudios psicológicos, que se iniciaron hace unos cincuenta años con objeto de analizar por qué unos riesgos se perciben de una forma y otros de otra. Esta investigación mostró que a la gente le afectan más los riesgos involuntarios que los voluntarios, y se preocupa más por los problemas tecnológicos que por las catástrofes naturales. Estos descubrimientos influyeron enormemente en la manera de presentar los riesgos ante la opinión pública. Las estrategias iniciales de comunicación de riesgos funcionaban de “arriba abajo”, por ejemplo, de un legislador al público. Actualmente, se prefiere una forma dialéctica en la comunicación de riesgos que anime al público y las partes interesadas a participar activamente en el proceso comunicativo.

EUFIC sigue de cerca el desarrollo del análisis de riesgos dentro del sector alimentario europeo. La comunicación de riesgos reviste un interés especial para nuestra organización, razón por la cual seguiremos informándoles en los próximos meses sobre este tema y otras actividades relacionadas con el riesgo.

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

Análisis de Riesgo 

México como país miembro de la OMC, ha adquirido, entre otros, el compromiso de cumplir con las obligaciones contenidas en el Acuerdo sobre la Aplicación 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 artículo 5 del citado Acuerdo obliga a los gobiernos miembros a que basen dichas  medidas en la evaluación de los riesgos para la vida y la salud de personas y de los animales o la preservación de las plantas, considerando para ello las técnicas de evaluación de riesgos desarrolladas por organizaciones internacionales reconocidas.  Asimismo, se enfatiza que al efectuar la evaluación de los riesgos, los países deben considerar “la evidencia científica disponible, los más relevantes métodos de producción y procesamiento”; igualmente, deben tener en cuenta “los más significativos métodos de inspección, de muestreo y de análisis”; deberán considerar también “la prevalencia de enfermedades o plagas específicas”, “la existencia de áreas libres de enfermedades o plagas”, “las condiciones ecológicas y ambientales más importantes”, “las cuarentenas y otros tratamientos”.  Como se puede apreciar, el aplicar la evaluación de riesgos se tiene, obligatoriamente que recurrir a otras disciplinas y  a diferentes unidades de cada uno de los servicios.

 

Más aún, el mismo artículo 5 indica que, la evaluación de los riesgos debe ser aplicada para obtener un apropiado nivel de protección sanitaria o fitosanitaria, para ello se deben tener en consideración, como factores económicos relevantes: “el daño potencial en términos de pérdidas de producción o ventas -que se sufriría- en caso de ingreso, establecimiento o difusión de plagas o enfermedades”; “los costos de control o erradicación en un territorio del país importador”; y “el costo-beneficio de los enfoques alternativos para limitar esos riesgos”.

 El Análisis de Riesgos se acepta hoy como la disciplina o metodología más apropiada para la adopción de medidas tendientes a prevenir y controlar plagas y enfermedades cuarentenarias, así como contaminaciones biológicas o químicas de los alimentos, que pueden causar alguna de las llamadas “Enfermedades Transmitidas por Alimentos” (ETA).  Dentro de los servicios veterinarios nacionales, cumplir con la obligación de aplicar la evaluación de riesgos previsto en el AMSF, requiere de la incorporación, dentro de ellos, del recurso humano especializado en materia de epidemiología, bioestadística y de análisis de riesgo propiamente dicho, dentro de parámetros internacionalmente aceptados, que permitan desempeñar 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 revisión y almacenamiento.

 

En el ámbito de salud animal, el análisis de riesgo es una herramienta utilizada para sustentar estudios epidemiológicos que apoyen las evaluaciones sobre el riesgo que representan algunas importaciones de animales, productos y subproductos a México, así como para la reintroducción 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 análisis, una descripción del agente y/o el producto, incluyendo el proceso de producción, el origen del mismo su uso en destino, los principales beneficiarios de la importación, los principales receptores del riesgo, así como otros aspectos relevantes para el estudio.

Es importante señalar que el análisis 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 determinación final.

  Todo lo anterior justifica que la Dirección General de Salud Animal del SENASICA, haya creado, dentro de la estructura de la Dirección de Vigilancia Epidemiológica, una Unidad de Análisis de Riesgo, integrada por personal altamente capacitado, seleccionado entre las diferentes áreas del SENASICA, la cual es la responsable directa de la evaluación de riesgos en materia sanitaria entre cuyos logros destacan:

 ·    Mayor confiabilidad en la calidad sanitaria de los bienes pecuarios exportados

por México·    Proteger la vida y salud de los animales del país y contribuir indirectamente con

aspectos de salud pública.·     Contribuir al soporte y avance de las campañas zoosanitarias y al

reconocimiento y preservación de áreas libres o de baja prevalencia de enfermedades y/o plagas de los animales.

·     Evitar el ingreso y diseminación de enfermedades y plagas exóticas o emergentes.

·     Proteger las inversiones pecuarias y la economía de pequeños y medianos productores.

·     Proteger la biodiversidad y el medio ambiente.·     Favorecer, indirectamente, el incremento del turismo.·     Contribuir a un mejor conocimiento científico de las enfermedades y plagas de

los animales.·     Documentar cada evaluación o análisis de riesgo realizado, para su utilización,

de ser el caso, como soporte de las negociaciones comerciales, desde un punto de vista científico y sanitario, que se realicen con terceros países.

·     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 aplicación de técnicas estadísticas ha tenido gran difusión y al mismo tiempo un enorme éxito, es en la de aquellos aspectos que se relacionan con el control de calidad de producción de bienes y suministro de servicios. En los años 80 la aplicación de la filosofía y técnicas del control de calidad en la producción 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 sólo se subió al carro del control de calidad una vez que la presión ejercida en el mercado por la superioridad de los productos japoneses les obligó a considerar las bondades de la nueva filosofía, en la que la calidad constituye un concepto global que no sólo se aplica al producto sino a todo el proceso de fabricación, incluyendo el control de costes, precios y beneficios, gestión de los suministros y plazos de entrega.

Aunque inicialmente el control de calidad se aplicó solo a la fabricación industrial, enseguida se extendió su radio de acción a la prestación de servicios, donde también podemos incluir el área de salud, aunque dentro del entorno médico hay sectores que por sus características, más asimilables a la industria, tienen una mayor tradición en el empleo del control de calidad; como son los laboratorios de análisis clínicos (hematología, bioquímica o microbiología), o los bancos de sangre. Sin embargo las técnicas han sido utilizadas también en otros entornos, como puede ser por ejemplo en la monitorización de fallos en operaciones quirúrgicas, y su campo de aplicación está limitado tan sólo por nuestra imaginación, 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 clínica del paciente.

Un elemento fundamental en la filosofía del control de calidad moderno es la utilización generalizada de procedimientos científicos, incluidos los métodos estadísticos, en la planificación, recogida de datos y análisis de los mismos, de tal forma que las decisiones no se sustenten en meras conjeturas.

Aunque en un sistema sanitario fundamentalmente público, como es el español, la competencia no constituye el principal acicate para la incorporación de sistemas de control de calidad, no cabe ninguna duda de que sin embargo existen múltiples razones para incorporar estas técnicas en la gestión de los servicios de atención sanitaria, como lo corrobora el hecho del aumento de su difusión y aplicación en este entorno, razones en las que de momento no vamos a entrar, por ser la línea argumental de estos artículos fundamentalmente estadística.

En este documento vamos a echar un vistazo a lo que se conoce como Control estadístico de procesos, metodología que utilizando fundamentalmente gráficos permite monitorizar la estabilidad (calidad) de un proceso de producción o de suministro de un servicio, de forma que se detecte, cuanto antes, cualquier situación inadecuada; lo que permitirá eliminar las causas especiales de variabilidad en la obtención del resultado final.

  Gráficos de control

Los gráficos 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 algún indicador de la variable cuya calidad se mide. Además se incluye otras dos líneas horizontales: los límites superior e inferior de control, escogidos éstos de tal forma que la probabilidad de que una observación esté fuera de esos límites sea muy baja si el proceso está en estado de control, habitualmente inferior a 0.01.

En cualquier proceso, incluida la prestación de servicios sanitarios, se produce variabilidad. Por ejemplo incluso en situaciones muy similares no todas las cirugías 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 organización. Estudiando meticulosamente cualquier proceso es posible eliminar las causas asignables, de tal forma que la variabilidad todavía 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 gráficos de control es por tanto monitorizar dicha situación para controlar su buen funcionamiento, y detectar rápidamente cualquier anomalía respecto al patrón correcto, puesto que ningún proceso se encuentra espontáneamente 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 consecución y mantenimiento exige un esfuerzo sistemático, en primer lugar para eliminar las causas asignables y en segundo para mantenerlo dentro de los estándares de calidad fijados.

Así pues el control estadístico de calidad tiene como objetivo monitorizar de forma continua, mediante técnicas estadísticas, la estabilidad del proceso, y mediante los gráficos de control este análisis se efectúa 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 específica que se podrá investigar y corregir.

El interés de los gráficos de control radica en que son fáciles de usar e interpretar, tanto por el personal encargado de los procesos como por la dirección de éstos, y lo que es más importante: la utilización de criterios estadísticos 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 según la característica medida:

La variable es medible numéricamente, por ejemplo un tiempo. Se estudia un atributo o característica cualitativa que el proceso posee o no

posee, por ejemplo el paciente cumple o no cumple adecuadamente el tratamiento

Se cuenta el número de defectos en el producto o situaciones inadecuadas en la prestación del servicio

Vamos en primer lugar a presentar los gráficos de control para variables cuantitativas. En este caso se puede representar la evolución de un valor medio, como puede ser la media o la mediana, o representar un indicador de dispersión como puede ser el rango o la desviación típica. Cuando no se va a utilizar un programa específico se suele preferir el rango a la desviación típica, por ser mucho más fácil de calcular. Existen otros tipos de gráfico más especializados, que comentaremos más adelante.

  Gráfico de control para variables cuantitativas

Veamos cómo se construye un gráfico de evolución de medias.

En primer lugar, para cada instante de tiempo se tomará una pequeña muestra (por ejemplo diariamente). En control de calidad se usa habitualmente muestras pequeñas de tamaño 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 días se han anotado 5 observaciones.

Tabla 1

Nº Dato 1 Dato 2 Dato 3 Dato 4 Dato 51 10.7 10.7 10.7 10.7 10.92 10.8 10.9 10.8 10.9 10.73 10.8 10.8 10.8 10.7 10.84 10.6 10.7 10.7 10.8 10.75 10.7 10.8 10.7 10.9 10.86 10.6 10.8 10.8 10.9 10.77 10.6 10.8 10.7 10.8 10.88 10.6 10.8 10.7 10.8 10.79 10.7 10.8 10.9 10.9 10.810 10.6 10.7 10.6 10.8 10.711 10.8 10.8 10.9 10.5 10.912 10.9 10.8 10.9 10.7 10.713 10.7 10.7 10.8 10.8 10.714 10.7 10.7 10.9 10.8 10.615 10.8 10.8 10.8 10.8 10.716 10.9 10.8 10.8 10.8 10.917 10.8 10.7 10.9 10.7 10.818 10.8 10.7 10.6 10.7 10.619 10.7 10.7 10.9 10.7 10.720 10.6 10.6 10.7 10.6 10.721 10.5 10.0 10.7 10.8 10.822 10.8 10.7 10.8 10.7 10.723 10.7 10.6 10.7 10.6 10.724 10.7 10.7 10.7 10.6 10.7

Para elaborar el gráfico de evolución 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 máximo - valor mínimo), así como la media de los 24 rangos.

Para el cálculo de los límites de control se utiliza la teoría de probabilidades, suponiendo que los datos siguen una determinada distribución 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 parámetro de variabilidad (sea éste el rango o la desviación típica) nos permite calcular los límites del gráfico de control de calidad, límites que nos garantizan una probabilidad del 99 % de que las observaciones se encuentren dentro de esos márgenes si el proceso está en estado de control. Es un concepto totalmente análogo al de intervalo de confianza para una estimación, al que estamos habituados en la inferencia estadística.

En general no será necesario realizar los cálculos 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 límites de calidad superior e inferior para un gráfico de medias se calculan de acuerdo a las siguientes fórmulas:

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 gráfico las 24 medias de las muestras de tamaño 5 de la tabla 1, una línea horizontal correspondiente a la media global, y dos líneas horizontales correspondientes a los límites de calidad obtenemos un gráfico como el de la figura 1

Fig. 1 Gráfico de control para la evolución de medias

 

Tabla 2. Factores para límites de control en gráficos de medias y rangos

Gráfico de medias Gráfico de Rangos

Tamaño de muestra n Factor A2 Factor D3 Factor D4

2 1.88 0 3.27

3 1.02 0 2.57

4 0.73 0 2.28

5 0.58 0 2.11

6 0.48 0 2.00

7 0.42 0.08 1.92

8 0.37 0.14 1.86

9 0.34 0.18 1.82

10 0.31 0.22 1.78

De igual forma se puede construir un gráfico de control para la evolución del Rango. En este caso los límites de control vienen dados por las fórmulas:

LCSR=D4R

LCIR=D4R

donde D4 se obtiene de la tabla 2, y como antes R es el rango medio.

  Gráfico 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 gráfico de proporciones, en el que la variable a representar en el eje de las Y es la proporción de veces en que el resultado no es adecuado. También aquí se recogerán de 20 a 30 muestras de tamaño suficiente para que se observe en cada una alguno de los resultados defectuosos, lo que hace que el tamaño de muestra necesario sea tanto mayor cuanto menor sea dicha proporción. Si el tamaño n de todas las muestras es el mismo y llamamos P a la media de todas las proporciones, sabemos que se puede estimar la desviación típica mediante la siguiente fórmula

De tal manera que los límites de control vienen dados ahora por las siguientes fórmulas

LCSP=P+3sp

LCIP=P-3sp

En el caso de que los tamaños de cada muestra difieran, también lo hace el valor de la desviación típica, de tal manera que para cada porcentaje representado en la gráfica varían los límites de control, los cuales no serán ya una línea horizontal sino una línea escalonada.

  Interpretación de los gráficos de control

El objetivo de los gráficos de control es determinar de forma visual y por tanto sencilla cuándo un proceso se encuentra fuera de control, con una probabilidad de error pequeña.

La primera indicación de que el proceso puede estar fuera de control viene dada por la presencia de algún punto fuera de los límites de control, como pasa con los datos correspondientes a la muestra 21 en la figura 1.

Para facilitar la detección de patrones anómalos o poco probables en un proceso en estado de control, conviene dividir en tres zonas de igual tamaño el área situada a ambos lados de la línea central, entre ésta y los límites de control, como vemos en la siguiente figura:

Fig.2 Gráfico de control con zonas intermedias

Si en el gráfico se está utilizando la desviación típica para calcular los límites de control, estas zonas corresponden a 1, 2 y 3 desviaciones típicas, que hemos marcado en la figura como A, B y C respectivamente.

Otra posible señal de que el proceso está fuera de control se da cuando aparecen un elevado número de puntos consecutivos al mismo lado de la línea central: si nos encontramos 8 puntos seguidos al mismo lado de la línea central, o 10 puntos de 11, o 12 de 14.

Cualquier tratado sobre implantación de procesos de calidad presenta una serie de reglas caseras para detectar diferentes series de datos improbables. Además 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 más 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 línea central

En cualquier caso siempre hay que estar atento a la presencia de patrones o tendencias en los gráficos de control.

Estas reglas pueden ser incluso más restrictivas (alerta para un nivel de probabilidad más bajo), si así lo requiere el proceso que se controla. Así por ejemplo en el mundo del control de calidad para los laboratorios de análisis clínicos son muy conocidas las denominadas reglas de Westgard, que no son más que una adaptación concreta de los razonamientos expuestos al control de calidad para un analizador del laboratorio, aparato en el que diariamente se efectuarán muestras de control de calidad para verificar que está funcionando adecuadamente. Los resultados obtenidos en estas muestras se representan en un gráfico de control como los ya descritos, aunque en ese entorno se conocen como gráfico de Levey-Jennings, y se aplican una serie de reglas probabilísticas de decisión en las que existen dos niveles: un nivel de alerta y un nivel de rechazo. Así una observación en la zona C o por encima supone una alerta y fuera de la zona de control, por encima de los límites de control obliga a rechazar los análisis efectuados.

  Epílogo

En los años 80 la aplicación de técnicas de control de calidad, surgidas en USA, supuso una gran revolución en la industria japonesa, a la que en breve tuvieron que sumarse las empresas de todo el mundo para competir no sólo con la calidad sino con los precios de los productos japoneses. Tanta importancia le dio el mundo empresarial japonés al control de calidad, que instituyeron un premio anual Deming, con el nombre de uno de los padres de esta filosofía, el estadounidense W. Edwards Deming. Ese interés por la calidad transcendió el entorno de la fabricación de productos, entre los que también se incluye los elaborados por la industria farmacéutica, para asimismo aplicarse al suministro de servicios, y poco a poco se va extendiendo un interés creciente por la calidad en el sector de la salud.

Desdeñar las técnicas de control de calidad como actividades no productivas, o como meras técnicas de inspección, o como algo solo aplicable a la fabricación 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 revolución de Deming y los japoneses, la enfermera británica Florence Nightingale, por cierto uno de los hitos no solo de la enfermería sino también de la bioestadística, ayudó en gran medida a la mejora de calidad de los servicios médicos prestados al ejército británico aportando datos y gráficos cuidadosamente elaborados, mediante los que demostraba que la mayor parte de las muertes de soldados británicos durante la guerra de Crimea eran debidas a las enfermedades contraídas fuera del campo de batalla, o debido a la falta de atención de las heridas recibidas, con lo que logró que su gobierno crease los hospitales de campaña.

Y hay muchos más antecedentes en el mundo de la medicina. Podemos destacar también los planteamientos del cirujano Ernest A. Codman (1869 - 1940), bastante antes de que la revolución del control de calidad llegase a la industria.

Hoy nadie puede dudar que después de los antibióticos y las vacunas, lo que más vidas humanas salva con respecto a siglos anteriores sean probablemente la higiene y la epidemiología, conceptos ligados no solo a la estadística sino también al control de calidad.

Tan solo plantearse el analizar la actividad que se realiza y verificar si es posible mejorarla, constituye ya un primer peldaño para que la calidad sea un hecho.

Enlaces

The Quality Tools CookbookProf. Sid Sytsma, Dr.Katherine Manley - Ferris State UniversityThe 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.orgIHI, 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 

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

SIX SIGMASix 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

Introducción

En los años 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 planificación 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 años 80 al surgir la crisis de la calidad, los altos directivos se vieron en uno de estos casos:

a. Daños considerables en sus empresas y querían recuperarse b. No habían sufrido daños pero no querían que dicha crisis llegara a sus puertas.

c. Los que ya trabajan con la calidad como máxima prioridad y vieron la ocasión oportuna para hacerse sentir

En aquella época sus tácticas fueron: exhibiciones, eslóganes, carteles, estandartes y toda clase de colorido carnaval, que creo conciencia pero no comportamiento para la calidad.

La lección que obtuvieron es que hay que:

1. Establecer los objetivos específicos 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 años 90 la mayoría de las empresas partían del punto en que la calidad cuesta y por esto se disminuirían las ganancias.

Hoy en día mas gente se dé cuenta de que en realidad es al contrario.

La búsqueda 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 planificación de la calidad.

La importancia otorgada durante los últimos años 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 dimensión humana, lo que nosotros llamamos ahora la dirección de calidad total.

"Calidad se ha convertido en una palabra moderna durante los últimos años. A pesar de esto existen aún muchas organizaciones que no están 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 (Biografía)

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 "enseño calidad a los japoneses".

Quizás lo más importante, es que el reconocido como la persona quien agrego la dimensión humana para la amplia calidad y de ahí proviene los orígenes estadísticos de la calidad total.

Su plan fue hacerlo todo: filosofía, 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 apreciación y las relevancias cercanas, Steve Jobs, fundador de Apple Computer y Next, se refiere a Juran por su profunda contribución. Jungi Niguahi, director ejecutivo de la unión de científicos e ingenieros japoneses, establece categóricamente que el Dr. Juran es la mas maravillosa autoridad en control de calidad, en todo el mundo.

Peter Duccker, el escritor de teorías, acertó que "cualquier avance logrado por la industria manufacturera americana en los ultimos 30 o 40 años fueron logrados por la constancia, paciencia y autoindestructible carácter de su trabajo.

Hoy Juran enfoca su atención en una nueva misión: repara la deuda que siente que le debe al país que le brinda la gran oportunidad y el éxito excepcional.

3. Cronologia

1924: Se gradúo como bachiller en ciencias en Ingeniería Eléctrica.

1928: Su primer trabajo (un folleto de entrenamiento llamado" Métodos estadísticos 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: Publicación manual de control de calidad (estándares).

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 técnicas para promulgar sus ideas y explorar el "Impacto de la calidad en la sociedad".

1984: Lo apremia el emperador Japonés Hiri Hito con la orden del tesoro sagrado.

1986: Publica la "Trilogía de la Calidad" ayuda a la creación del Premio de calidad nacional "The Malcoln Baldrige National Quality Award".

1987: Renuncia al liderazgo del Instituto Juran Inc.

1993-1994: Después de una serie de lecturas triunfantes en 1993 y 1994, el tour "The Last World", él suspendió toda publicación reciente, de orden para dedicarse a escribir proyectos y dedicar tiempo a sus obligaciones familiares.

4. La Calidad para Joseph Juran

Calidad según Juran tiene múltiples significados. Dos de esos significados son críticos, no solo para planificar la calidad sino también para planificar la calidad sino también 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, cancelación de contratos de ventas, etc.

Calidad es " adecuación al uso".

La Misión de Juran y la Planificación para la Calidad

Crear la conciencia de la crisis de la calidad, el papel de la planificación de la calidad en esa crisis y la necesidad de revisar el enfoque de la planificación de la calidad.

Establecer un nuevo enfoque de la planificación de la calidad.

Suministrar formación 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 planificación de la calidad, dominio derivado de la replanificacion de los procesos existentes y de la formación correspondiente.

Asistir al personal de la empresa para utilizar el dominio resultante en la planificación de la calidad de forma que se evite la creación de problemas crónicos 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 típica 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":

ProveedorProducto (Bienes y

Servicios)Cliente

Cliente

Desarrollo del producto

Operaciones

Marketing

Información sobre las necesidades

Diseños del producto

Bienes, servicios

Bienes, servicios

Desarrollo del producto

Operaciones

Marketing

Clientes

Observe que algunos de los clientes son "internos", esto es miembros de la misma compañía que los proveedores. Otros clientes son externos.

"La Espiral" es una versión altamente simplificada de lo que ocurre en una gran empresa.

5. La Trilogía de Juran

La planificación de la calidad en uno de los tres procesos básicos de gestión por medio de los cuales gestionamos la calidad. Los tres procesos (la trilogía de Juran) están interrelacionados.

Todo comienza con la planificación 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, películas de polietileno, contrato de ventas, llamadas de asistencia técnica y diseños nuevos para los bienes.

Una vez que se ha completado la planificación, 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 crónica porque el proceso se planifico así.

Bajo patrones convencionales de responsabilidad, las fuerzas operativas son incapaces de eliminar esa perdida crónica 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 (planificación, control, y mejora) han estado presentes durante algún tiempo. Se han utilizado en las finanzas durante siglos, lo suficiente como para haber desarrollado una terminología normalizada.

La tabla que sigue muestra algunos ejemplos:

Procesos de la Trilogía Terminología Financiera

Planificación de la Calidad

Control de Calidad

Presupuestar, planificar el negocio Control de Costos, Control de Gastos, Control de

Inventario

Reducción de Costos, Mejora de Beneficios

 

Mejora la Calidad

El Mapa de Carreteras para la Planificación de la Calidad

La planificación de la calidad consiste en desarrollar los productos y procesos necesarios para satisfacer las necesidades de los clientes. Más concretamente, la planificación de la calidad comprende las siguientes actividades básicas:

 

 

Producto y proceso existente    

     

Necesidades de los clientes

(en unidades de medida)

Identificar clientes    

         

Lista de clientes   Desarrollar producto

         

Descubrir las necesidades de los clientes

  Características del producto

         

Necesidades de los clientes

(en su lenguaje)  Optimizar diseño del producto

         

Traducir   Objetivos del producto

         

Necesidades de los clientes

  Desarrollar proceso

(en nuestro lenguaje)

       

Establecer unidades de medida   Características del proceso

         

Unidades de medida  Optimizar probar la capacidad del

proceso

         

Establecer medida   Proceso listo para ser transferido

         

Necesidades de los clientes

(en unidades de medida)  Transferir a operaciones

       

    Proceso listo para producir

 

6. Identificar a los Clientes

El primer paso en la planificación de la calidad es identificar quiénes son los clientes. Para identificar a los clientes hay que seguir el producto para ver sobre quién 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.

Según el principio de Pareto, los clientes se pueden clasificar en dos categorías básicas:

Unos relativamente pocos ("pocos vitales"), cada uno de los cuales tiene gran importancia para nosotros.

Un número 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 público.

http://www.monografias.com/trabajos5/conca/conca.shtml

4 Análisis de los requerimientos.

Actividades Técnicas

1. Identificar Casos de Uso del sistema

Esta información se representa en un diagrama de casos de uso.

Cómo encontrar un actor?  Identifique los usuarios del sistema 

o Porqué se diseña el sistema?  o Cuáles 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 información 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 comunicación 

Cómo encontrar un caso de uso?          Identifique las operaciones importantes del sistema a construir              Cuáles son las principales tareas de un actor?              Qué información tiene el actor que consultar, actualizar, modificar? Cómo?              Qué cambios del exterior debe informar el actor al sistema?              Qué información debe informársele al actor, con respecto a los cambios del sistema? 

Cómo 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, diferenciándose en la forma en la cual hacen algunas operaciones?  Qué caso de uso redefine la forma en la cual se realiza una transacción 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 información de entrada y salida de cada caso de uso   

Descripción detallada del caso de uso  Descripción textual de su objetivo Variantes posibles para realizar este caso de uso. Diagramas de interacción de

detalle (de secuencia o colaboración)

Errores y excepciones posibles en el caso de uso

Relacionar el caso de uso con la interfaz a usuario que lo representa   

Especificar el diálogo que da solución al caso de uso (ver definición de interfaz)   

 

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

Dibujar las pantallas de interacción 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)          Visualización típica de los elementos del modelo del mundo          Información relevante para el actor          Metáforas de interacción válidas   

Especificar el diálogo que da solución a cada caso de uso que se soluciona con la interacción con esta interfaz. Puede especificarse este diálogo de varias maneras, dependiendo de la complejidad de la interfaz definida (en esta etapa se sugiere escoger el mínimo nivel de detalle posible, para dar más libertad de diseño en las etapas posteriores): 

1. Por medio de una descripción textual de su funcionamiento 2. Por medio de diagramas de interacción 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 términos de la interacción con el usuario

Definir restricciones para la comunicación con actores y sistemas          Describir en el detalle del actor o de la relación con el caso de uso particular 

 

4. Desarrollar el modelo del mundo

Esta información se representa en un diagrama de estructura estática de clases.

Identificar Clases   Elementos físicos y lógicos dentro del sistema a modelar  Top-down: Comenzar por la clase del objeto más general (el mundo).

Encontrar sus componentes hasta llegar a clases de tipos básicos  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 información 

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? Cuáles objetos determinan estos estados? 

o Cómo 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 información o mensajes no relevantes para el problema 

Vista Funcional: Dividir un sistema de la manera clásica 

Identificar atributos y asociaciones. Cuáles son las características 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 (composición)?  Qué información 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 mundo? 

o Qué mensajes se requieren para manipular la información que contienen? 

o Qué mensajes requieren para manipular las relaciones que tiene?  o 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 información 

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 relación 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 asociación Identificar restricciones que relaciones dos o más 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 lógicas 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 reutilización Reutilizar modelos de dominio existentes  Identificar posibles variantes en el futuro tenerlas en cuenta para diseño

(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 válidos en el mundo real

Validar atributos y mensajes  La clase tiene toda la información 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 conservación de las restricciones del modelo?

Desarrollar diagramas de interacción (diagramas de secuencia o de colaboración) para la variante por defecto de cada caso de uso, usando los objetos del modelo del mundo encontrados y sus mensajes. 

Escoger la opción por defecto de cada caso de uso Identificar los objetos involucrados

Desarrollar el diagrama de secuencia o el de colaboración para la interacción

Validar los diagramas de Interacción  Todo mensaje de un objeto a otro implica una asociación 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 interacción 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 interacción descritos como detalle de los casos de uso

del actor

Validar la interfaz diseñada y el diálogo descrito

Iterar si es necesaria más información 

 

Documentos Entregables

Casos de Uso inicialesRequerimientos más importantes del sistema  Usuarios y sistemas externos en comunicación  Especificación de requerimientos

Borradores de Interfaz Presentaciones iniciales para los distintos usuarios de la forma de solucionar sus requerimientos

Modelo del mundo inicial. Versión de requerimientos

Clases, relaciones entre clases y especificación

 http://www.cs.ualberta.ca/~pfiguero/soo/metod/requerimientos.html

Análisis de requerimientos

 

Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y además contienen múltiples relaciones entre si. Lo que nos da a concluir, de acuerdo a lo expuesto en el capítulo 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 análisis de requerimientos consiste brevemente en los siguientes pasos:

Obtener información acerca de lo que los usuarios desean

Clasificar esos deseos para comenzar a estructurar requerimientos

Identificar los niveles de jerarquía 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 capítulos se explica con mas claridad cada uno de estos puntos.

Obteniendo de la información 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 lógico que para recabarlos haya que obtener la información de primera mano.

Esto es, mediante entrevistas con el cliente o recabando documentación 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 documentación original del cliente, así como cada revisión o cambio que se haga a esta documentación

Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuales de ellas serán satisfechas por el software y cuales por algún otro producto del sistema.

http://www.geocities.com/txmetsb/req-mgm-2.htm

El análisis 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 creación 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 términos de componentes físicos: hardware, software, usuarios y la comunicación entre ellos.

La determinación 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, ...), ergonómicos (interfaz gráfica, 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.

IntroducciónEn la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los años, la Ingeniería de Software ha introducido y popularizado una serie de estándares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y artículos relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y estándares de calidad.

Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen tantos proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad? ¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema?

Tal vez suene ilógico pero, a pesar de los avances que ha dado la tecnología, aún existen procesos de producción informales, parciales y en algunos casos no confiables.

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.

La razón principal para escoger este tema se fundamentó en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto común la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas.

Tal "personalización", la mayoría de las veces, termina retrasando el proyecto en meses, o incluso en años. La problemática del año 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 tecnologías 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 definición de los requerimientos.

Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos.

Con este trabajo se pretende alcanzar los siguientes objetivos:

Resaltar la importancia que tiene la Ingeniería 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 técnicas utilizadas en la

IR. Minimizar las dudas que se tiene sobre los casos de uso. Mostrar la utilización de herramientas CASE dentro de la administración de requisitos.

2. La ingeniería de requerimientos y sus principales actividades¿Qué son Requerimientos?Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .

(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición 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 características 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, estándares, etc.

Características de los requerimientosLas características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción 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 redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles 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 difícil de manejar. Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más

estables que otros. Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras

partes del proceso. Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada

proyecto.

Ingeniería de Requerimientos vs. Administración de Requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.

A continuación se darán algunas definiciones para ingeniería de requerimientos."Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979.

"Ingeniería 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 combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987.

"Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también 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 Ingeniería de RequerimientosLos principales beneficios que se obtienen de la Ingeniería 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 estimación 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, desempeño, etc.).

Mejora la comunicación entre equipos: La especificación 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 ingeniería 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 Ingeniería 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 específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, 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 comunicación poco efectiva entre clientes y desarrolladores, que a la vez traería impactos negativos tanto en tiempo como en presupuesto. Los roles más importantes pueden clasificarse como sigue:

Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario.

Usuario Líder: 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 técnico 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 administración de cambios, de la implementación y resolución de anomalías. 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 interactúan 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, diseñadores de base de datos, entre otros.

Puntos a considerar durante la Ingeniería de RequerimientosAunque la lista no está completa, se enumeran los puntos más importantes.Objetivos del negocio y ambiente de trabajoAunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para descomponer el trabajo en tareas específicas. En ciertas situaciones IR se enfoca en la descripción de las tareas y en el análisis de sistemas similares. Esta información proporciona la base para especificar el sistema que será construido; aunque frecuentemente se añadan al sistema tareas que no encajan con el ambiente de trabajo planificado.

El nuevo sistema cambiará el ambiente de trabajo, sin embargo, es muy difícil anticipar los efectos actuales sobre la organización. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en producción; también 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 atención a la IR es la principal.

Frecuentemente la especificación inicial es también la especificación final, lo que obstaculiza la comunicación 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 también pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos.

El tamaño 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 comunicación

La ingeniería de requerimientos depende de una intensa comunicación entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicación.

Para remediar esto, se deben abordar nuevas técnicas operacionales que ayuden a superar estas barreras y así ganar experiencia dentro del marco del sistema propuesto.

Evolución e integración del sistema

Pocos sistemas son construidos desde cero. En la práctica, 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 integración de componentes de varios proveedores.

Para encontrar una solución a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseño; esto minimizará la cantidad de fallas directas en el código.

Documentación de requerimientos

Los documentos de ingeniería de requerimientos son largos. La mayoría están compuestos de cientos o miles de páginas; cada página 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 tamaño, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificación de gran tamaño, pues difícilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta después de haberse construido el sistema.

Actividades de la Ingeniería de Requerimientos

En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas secuencialmente, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado.

Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en número 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:

Análisis del Problema Evaluación y Negociación Especificación Validación Evolución

 

Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniería de Software

MODELO Oliver and Steiner 1996

EIA / IS-632 IEEE Std 1220- 1994

CMM nivel Repetitivo (2)

RUP

           

Actividades

Evaluar la información disponible

Análisis de requerimientos

Análisis de Requerimientos

Identificación de requerimientos

Análisis del Problema

Definir métricas efectivas

Análisis funcional

Estudio de los requerimientos

Identificación de restricciones del sistema a desarrollar

Comprender las necesidades de los involucrados

Crear un modelo del comportamiento del sistema

Síntesis Validación de requerimientos

Análisis de los requerimientos

Definir el sistema

Crear un modelo de los objetos

Análisis y control del sistema

Análisis funcional

Representación de los requerimientos

Analizar el alcance del proyecto

Ejecutar el análisis

  Evaluación y estudio de funciones

Comunicación de los requerimientos

Modificar la definición del sistema

Crear un plan secuencial de construcción y pruebas

  Verificación de funciones

Validación de requerimientos

Administrar los cambios de requerimientos

    Síntesis    

    Estudio y evaluación del diseño

   

    Verificación física

   

    Control    

A continuación se explicará cada una de ellas, presentándolas en el orden en que deben ser aplicadas para un nuevo proyecto.

Análisis del ProblemaEl objetivo de esta actividad es entender las verdaderas necesidades del negocio.

Antes de describir qué pasos deben cumplirse en esta actividad, debemos tener una definición clara del término "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 comunicación

entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades.

A través de la definición de problema, podemos ver entonces que la actividad de "Análisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalúen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solución de alto nivel para resolverlo.

Durante el análisis 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 quién 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 transacción bancaria".

Perspectiva del cliente = Pérdida de tiempoPerspectiva del banco = Posibles pérdidas de clientes

Posibles soluciones pueden ser, determinar por qué demoran los cajeros, colocar una nueva caja (implica contratación de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos, etc).

Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva técnica como la del negocio.

Construir un vocabulario común: Debe confeccionarse un glosario en dónde se definan todos los términos que tengan significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por ejemplo, las palabras pignoración, retención, valor en suspenso, custodia, garantía, entre otras, son utilizadas para referirse a la acción de dejar una prenda (puede ser cualquier forma de ahorros) como garantía de una deuda adquirida.

La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunión están en la misma página, además 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 ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la información necesaria para especificar un sistema adecuado.

Para saber quiénes son las personas, departamentos, organizaciones internas o externas que se verán afectadas por el sistema, debemos realizar algunas preguntas.

¿Quién usará el sistema que se va a construir? ¿Quién desarrollará el sistema? ¿Quién probará el sistema?

¿Quién documentará el sistema? ¿Quién dará soporte al sistema? ¿Quién dará mantenimiento al sistema? ¿Quién mercadeará, venderá, y/o distribuirá el sistema? ¿Quién se beneficiará por el retorno de inversión del sistema?

Como vemos, debe conocerse la opinión de todo aquél que de una u otra forma está involucrado con el sistema, ya sea directa o indirectamente.

Definir los límites 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 restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir.

Evaluación y negociación de los requerimientos

La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades.

En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado.

Los principales pasos de esta actividad son:

Descubrir problemas potenciales: En este paso se asegura que todas las características descritas en el punto 1.1 estén 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 términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño 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 operación crítica del negocio. Si existe algún 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 categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también 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 más que éste sea sólo deseable.

Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?); factibilidades operacionales (¿puede

ser el sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

En la actividad de evaluación y negociación, se incrementa la comunicación 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.

Especificación de Requisitos de Software (SRS)

La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción 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 información que sirva de soporte y guía para fases posteriores.

Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación 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 evolución del sistema.

La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica 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 características de la SRS son verificadas en la actividad de Validación, descrita en el punto 3.4.

La estandarización 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, además de asegurar que se cubren todos los tópicos 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 especificación de requisitos.

Validación de Requisitos

La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además 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 validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad.

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos:

¿Están incluidas todas las funciones requeridas por el cliente? (completa) ¿Existen conflictos en los requerimientos? (consistencia) ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua) ¿Está cada requerimiento claramente representado? (entendible) ¿Pueden los requerimientos ser implementados con la tecnología 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 validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.

Evolución de los requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto,

es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo

que ocurre a lo largo del ciclo de vida del proyecto.

Los requerimientos cambian por diferentes razones. Las más 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 característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra actividades como establecer políticas, guardar históricos 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 código, ya que evita tener requerimientos emparchados en un proyecto

Entre algunos de los beneficios que proporciona el control de versiones están:

Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de "releases". Prevenir la modificación simultánea 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 métodos formales para el desarrollo de software (sw) o, simplemente métodos formales, son métodos que se utilizan para todas las etapas del ciclo de desarrollo de software y que tienen la característica que usan formalismos matemáticos para la representación o derivación 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 (español, inglés, frances, etc.) y, si es necesario, se utilizan también gráficas, tablas y figuras que ayuden a describir con mayor precisión 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 español), son de naturaleza ambigua, es decir, una misma expresión puede tener más de un significado.  El lenguaje informal en que se describe  un DRS es mas cercano al usuario y, se describe más en términos de su entorno de aplicación que en términos computacionales. De esta manera empleará expresiones como la siguiente:

    "El sistema deberá calcular la caida de presión de agua de cada tubería del sistema"     "el sistema de control de  alarmas para cada centro de control de energía deberá desplegar informes resumidos en forma ejecutiva cada día, según el anexo de este documento"

De esta manera, términos computacionales ajenos al lenguaje del usuario, son por lo general evitados en un DRS. De esta forma se evitan términos como "tipo entero", "modulo", etc.

El DRS, por lo general se elabora con la (evidente) participación del usuario. A menudo, el usuario es asistido para la escritura del DRS por uno ó más 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  términos de entrada-salida, mientras que los no-funcionales, en téminos 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 desaparecerán del monitor principal, apareciendo en su lugar el diagrama unifilar de la subestación eléctrica correspondiente"

    "Cuando se selecciona la opción RESUMEN en el munú 1825, se desplegarán los promedios de energía 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 información ejecutiva"

    "El sistema será desarrollado en java e integrado en un estación de trabajo en tiempo real  IDM tipo 6890-56".  

A menudo los DRS se escriben sin la participacion diseñadores de sistemas de cómputo, de modo que no presentan directivas que conlleven a un diseño 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 relación entre el lider y analistas del proyecto de sw y el usuario, mientras la especificación es un documento de trabajo de uso casi exclusivo para el grupo de desarrollo de sw. Esta situación desde luego que debe cambiar ya que la participación del usuario en todas las etapas de desarrollo del sistema.

Los métodos formales se pueden utilizar tanto para la especificación como para la verificación formal de programas y, en principio, para la construcción (de código) formal de programas; esta última da lugar a programación automática y derivación formal de programas; sin embargo, en sistemas reales, es mucho más frecuente encontrar aplicaciones de métodos formales para la etapa de especificación que para la verificación formal y, prácticamente nula para el caso de construcción formal de programas.  En esta sección trataremos sobre los métodos de especificación formal.

http://w3.mor.itesm.mx/~logica/log9808/especif.html

4.2 Casos de uso.

Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además 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 Comunicación .

Elementos

Actor:

Una definición 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 más bien la labor que realiza frente al sistema.

Como ejemplo a la definición 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 operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones:

o Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

o Dependencia o Instanciación

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

o Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Ejemplo:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el número 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 botón de comienzo Existe un operador que desea saber lo siguiente:

a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en

el día. El operador debe además poder cambiar:

a. Información asociada a ítemes. b. Dar una alarma en el caso de que:

i. Item se atora. ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

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

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño 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 Gracia27 de Septiembre de 2003

Quien más o quien menos ha visto algún diagrama UML, lo más probable es que te hayas topado con algún diagrama de clases. También es muy probable que hayas visto algún 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 están en los primeros capítulos siempre son leídos y pocas veces bien entendidos.

Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis 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 cómo este interactúa con el usuario.

Si te has enfrentado alguna vez a UML normalmente habrás visto algún diagrama de clases y esperarás que los Casos de Uso sean también una forma visual de representar la información. Sin embargo estás 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 más claro es que te presente uno. Este podría ser el caso de uso de escribir un mensaje en un foro.

Nombre: Crear mensaje foro

Autor: Joaquin Gracia

Fecha: 24/08/2003

Descripción:      Permite crear un mensaje en el foro de discusión.

Actores:      Usuario de Internet logeado.

Precondiciones:      El usuario debe haberse logeado en el sistema.

Flujo Normal:

1. El actor pulsa sobre el botón para crear un nuevo mensaje. 2. El sistema muestra una caja de texto para introducir el título del

mensaje y una zona de mayor tamaño para introducir el cuerpo del mensaje.

3. El actor introduce el título 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 permitiéndole que los corrija

Poscondiciones:      El mensaje ha sido almacenado en el sistema.

Saltándome los campos evidentes como nombre, autor, fecha y descripción; los actores son aquellos que interactúan 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 ejecución 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 más 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 "muñecos y pelotas".

Muñecos y Pelotas

Cuando empiezas a tener un número considerable de casos de uso como el anterior, no resulta nada fácil situarlos y relacionarlos. Entonces empiezas a tener la necesidad de una visión 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 muñecos son los actores y las pelotas son los documentos de casos de uso. Así que dibujas un muñeco por actor y una pelota por cada caso de uso y los enlazas con líneas cuando haya una relación entre ellos.

Con esto consigues una visión general de cómo los diferentes actores interactúan con los distintos casos de uno.

Enlaces sobre UML

UML Resource Center en IBM UML en OMG Bibliografía UML

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

II.4 Diagrama de Casos de Uso

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están 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 línea. En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

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 organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación 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 descripción 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 específica. 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 específica 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, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (<>): Un caso de uso base incorpora explícitamente a otro

caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura 16 se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

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

Figura 17 - Ejemplo de Relación <> Ambos tipos de relación 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 extensión del caso de uso base en los que se aplica la extensión. • Generalización ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso más específico. Se representa por una línea continua entre los dos casos de uso, con el triángulo que simboliza generalización en UML (usado también para denotar la herencia entre clases) pegado al extremo del caso de uso más general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y características 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 relación se utiliza mucho menos que las dos anteriores.

http://www.clikear.com/manuales/uml/diagramascasouso.asp

4.3 Diseño de interfaz de usuario.

Prólogo General

Los Avances de la Ciencia y la Tecnología han puesto al hombre en un plano intermedio entre lo tangible e intangible computacionalmente hablando, es ahora tan común el convivir con un computador diariamente que cada vez se hace más imperativo la mejor interacción hombre-máquina a través de una adecuada interfaz (Interfaz de Usuario), que le brinde tanto comodidad ,como eficiencia.

El presente trabajo es una introducción al mundo de las Interfaz de Usuarios, en el están los conceptos y nociones básicas que permitirán en adelante adentrarnos más en este

2. Conceptos de interfaz

Lewis y Rieman [1993] definen las interfaces hombre computadora como:

Las interfaces básicas de usuario son aquellas que incluyen cosas como menús, ventanas, teclado, ratón, los "beeps" y algunos otros sonidos que la computadora hace, en general, todos aquellos canales por los cuales se permite la comunicación entre el hombre y la computadora.

La idea fundamental en el concepto de interfaz es el de mediación, entre hombre y máquina. La interfaz es lo que "media", lo que facilita la comunicación, la interacción, entre dos sistemas de diferente naturaleza, típicamente el ser humano y una máquina como el computador. Esto implica, además, que se trata de un sistema de traducción, ya que los dos "hablan" lenguajes diferentes: verbo-icónico en el caso del hombre y binario en el caso del procesador electrónico.

De una manera más técnica 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 máquina mediante instrucciones, denominadas genéricamente entradas. Las entradas se introducen mediante diversos dispositivos, por ejemplo un teclado, y se convierten en señales electrónicas que pueden ser procesadas por la computadora. Estas señales se transmiten a través de circuitos conocidos como bus, y son coordinadas y controladas por la unidad de proceso central y por un soporte lógico conocido como sistema operativo. Una vez que la UPC ha ejecutado las instrucciones indicadas por el usuario, puede comunicar los resultados mediante señales electrónicas, o salidas, que se transmiten por el bus a uno o más dispositivos de salida, por ejemplo una impresora o un monitor.

Resumiendo entonces podemos decir que, una interfaz de software es la parte de una aplicación que el usuario ve y con la cual interactúa. Está relacionada con la subyacente estructura, la arquitectura, y el código que hace el trabajo del software, pero no se confunde con ellos. La interfaz incluye las pantallas, ventanas, controles, menús, metáforas, la ayuda en línea, la documentación y el entrenamiento. Cualquier cosa que el usuario ve y con lo cual interactúa es parte de la interfaz. Una interfaz inteligente es fácil de aprender y usar. Permite a los usuarios hacer su trabajo o desempeñar una tarea en la manera que hace más sentido para ellos, en vez de tener que ajustarse al software. Una interfaz inteligente se diseña específicamente para la gente que la usará.

3. Clasificación

Dentro de las Interfaces de Usuario se distinguir básicamente dos tipos :

Una interfaz de hardware, a nivel de los dispositivos utilizados para ingresar, procesar y entregar los datos: teclado, ratón y pantalla visualizadora; y

Una interfaz de software, destinada a entregar información acerca de los procesos y herramientas de control, a través de lo que el usuario observa habitualmente en la pantalla.

De esta clasificación general se puede ir desprendiendo algunas, así por ejemplo según su evolución tenemos:

La evolución 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 continuación se muestran las distintas interfaces que históricamente han ido apareciendo, ejemplificándolas con las sucesivas versiones de los sistemas operativos más populares.

Interfaces de línea de mandatos (command-line user interfaces, CUIs).

Es el característico del DOS, el sistema operativo de los primeros PC, y es el estilo más antiguo de interacción hombre-máquina. 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, típicamente, y las órdenes están encaminadas a realizar una acción.

El usuario no suele recibir mucha información por parte del sistema (ejemplo: indicador del DOS), y debe conocer cómo funciona el ordenador y dónde están los programas (nada está oculto al usuario). El modelo de la interfaz es el del programador, no el del usuario. Ejemplo del DIR-DEL-DIR, por la falta de información 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 difícil 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

Número de Serie del Volumen es 1D8F-82B0

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 más rápidos, por lo que se puede diseñar un CUI como parte de una interfaz, para que se pueda utilizar una vez que se tenga experiencia.

Interfaces de menús.

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 opción que deseen (véase ejemplo). Los menús 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 algún objeto.

Las interfaces de menús aparecen cuando el ordenador se vuelve una herramienta de usuario y no sólo de programadores. Las actuales interfaces gráficas u orientadas a objetos siguen utilizando este tipo de interfaces (los distintos estilos de interfaces no son mutuamente exclusivos).

Existen distintos tipos de menús. Los primeros fueron los menús de pantalla completa, estructurados jerárquicamente

Menú de pantalla completa (Norton Utilities)

Los menús de barra, situados en la parte superior de la pantalla, son profusamente utilizados en las aplicaciones actuales. Contienen una lista de acciones genéricas que dan paso a menús desplegables donde se concretan.

Menú de barra y menú desplegable

Estos menús pueden llevar a su vez a otros: son los menús en cascada. Pueden cambiar dinámicamente, y deshabilitar opciones que no estén disponibles en un momento dado (marcándolas habitualmente en gris).

Menús en cascada de la barra de inicio de Windows 95

Las paletas o barras de herramientas son menús gráficos con acciones, herramientas y opciones que se pueden colocar en la pantalla. Se utilizan mucho en programas gráficos.

Paletas de herramientas en Microsoft Powerpoint

Los menús contextuales o menús pop-up son los más 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, más algunas de uso frecuente que también son accesibles desde el menú de barra.

Menú contextual de un icono en el escritorio de Windows 95

Las interfaces de menús, bien estructuradas, son buenas para usuarios noveles o esporádicos. Son fáciles de aprender y de recordar. Pueden existir menús simples y avanzados, para adaptarse al tipo de usuario.Precauciones: no ocupar demasiado espacio de la pantalla, recordar la información acumulada de menús precedentes, no colocar demasiados elementos en el menú, agruparlos de manera lógica (no en orden alfabético, por ejemplo; esto ayuda a recordarlos), permitir la personalización por parte del usuario, usar una terminología adecuada y consistente dentro del programa y con otros programas (Exit, Quit, Escape, Close, Return, Back). Las interfaces de menús serán utilizadas normalmente en conjunción con los otros estilos de interfaces.

Interfaces gráficas (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 campaña publicitaria)

Los tres estilos más comunes de interfaces gráficas hombre-computadora son: Lo que tú ves es lo que puedes conseguir (WYSIWYG What you see is what you get), Manipulación directa e Interfaces de usuario basados en iconos.

Un GUI es una representación gráfica en la pantalla del ordenador de los programas, datos y objetos, así como de la interacción con ellos. Un GUI proporciona al usuario las herramientas para realizar sus operaciones, más que una lista de las posibles operaciones que el ordenador es capaz de hacer.

4. Características de un GUI

1. Posee un monitor gráfico de alta resolución.

1. Posee un dispositivo apuntador (típicamente un ratón).

1. Promueve la consistencia de la interfaz entre programas.

1. Los usuarios pueden ver en la pantalla los gráficos y textos tal como se verán impresos.

1. Sigue el paradigma de la interacción objeto-acción.

1. Permite la transferencia de información entre programas.

1. Se puede manipular en la pantalla directamente los objetos y la información.

1. Provee elementos de interfaz estándar como menús y diálogos.

1. Existe una muestra visual de la información y los objetos (iconos y ventanas).

1. Proporciona respuesta visual a las acciones del usuario.

1. Existe información visual de las acciones y modos del usuario/sistema (menús, paletas).

1. Existen controles gráficos (widgets) para la selección e introducción de la información.

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

1. Proporciona flexibilidad en el uso de dispositivos de entrada (teclado/ratón).

Una característica importante es que el GUI permite manipular los objetos e información de la pantalla, no sólo presentarla.

Para usar un GUI, los usuarios deben conocer (o aprender) una serie de conceptos: organización del sistema (ficheros, directorios en Win95), diferentes tipos de iconos y efecto de las acciones sobre ellos, elementos básicos de una ventana, uso de los controles del GUI, uso del ratón.

Los GUI usan el estilo objeto-acción, en contraposición al acción-objeto de los CUI o las interfaces de menú. El usuario selecciona un objeto, y después la acción a realizar sobre dicho objeto. Los objetos son el principal foco de atención del usuario, lo cual resulta más natural y próximo a su modelo mental.

Metáfora de la cámara

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 aplicación, mientras que las OOUIs están orientadas al objeto. La tabla siguiente muestra las principales diferencias entre ambos estilos de interfaz:

Interfaces orientadas a la aplicación Interfaces orientadas a objetos

La aplicación consiste en un icono, una ventana principal y varias secundarias

El producto consiste en una colección de objetos que cooperan y vistas de dichos objetos

Los iconos representan aplicaciones o ventanas abiertas

Los iconos representan objetos que se pueden manipular directamente

Los usuarios deben abrir una aplicación antes de trabajar con objetos

Los usuarios abren objetos como vistas en el escritorio

Proporciona al usuario las funciones necesarias para realizar las tareas

Proporciona al usuario los materiales necesarios para realizar las tareas

Se centra en la tarea principal determinada por la aplicación

Se centra en las entradas y salidas de los objetos y tareas

Las tareas relacionadas son soportadas por otras aplicaciones

Las tareas relacionadas son soportadas por el uso de otros objetos

Estructura rígida: función Estructura flexible: objeto

Los usuarios pueden quedar atrapados en una tarea

Los usuarios no deben quedar atrapados en una tarea

Los usuarios deben seguir la estructura de la aplicación

Los usuarios pueden realizar tareas a su propio gusto

Se requieren muchas aplicaciones: una por tarea

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 cómo utilizar las aplicaciones y ficheros necesarios para cumplir sus objetivos. Por ello se esconde la organización del sistema al usuario (Ejemplo de los accesos directos en Windows95-OS/2).

El estilo de interacción de los OOUIs es el de objeto-acción (también se da en los GUIs, aunque mezclado con el estilo acción-objeto). La ventana es un objeto ventana, no una ventana de aplicación; desaparecen pues los menús de barra y ganan terreno los contextuales.

Los objetos se pueden clasificar en tres categorías: 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 más complicado del diseño 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 metáforas.

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 gráficos 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 aplicación y al objeto, aunque se está produciendo una migración a estos últimos. Las aplicaciones están dejando paso a conjuntos de objetos.

5. Características humanas del diseño de interfaz

Factores Humanos

Al diseñar interfaces de usuario deben tenerse en cuenta las habilidades cognitivas y de percepción de las personas, y adaptar el programa a ellas.

Así, una de las cosas más importantes que una interfaz puede hacer es reducir la dependencia de las personas de su propia memoria, no forzándoles a recordar cosas innecesariamente (por ejemplo, información 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 máquina, 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 más pronto posible.

Velocidad de Respuesta.- El tiempo necesario para realizar una operación en el sistema. Tasa de errores.- Porcentaje de errores que comete el usuario. Retención.- Cuánto recuerda el usuario sobre el uso del sistema en un período. de tiempo. Satisfacción.- Se refiere a que el usuario esté a gusto con el sistema.

Además de éstos existen otros a considerar:

Adecuación

Características Físicas.- Cada persona tiene diferentes características físicas. Hay algunas personas que no les gustan los teclados mientras que a otras sí. Es por eso que hay teclados ergonómicos. 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 iluminación del lugar. ¿ Se refleja el brillo en la pantalla?

Personalidad.- De acuerdo a la edad, nivel socio-económico, 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.

Según la función tenemos:

Motivación

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 más. 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 Investigación.- Realizan tareas muy específicas y tratan de imitar el medio en

el que se desenvuelve el usuario.

6. Pasos para el diseño de interfaz

Pasos Clásicos

En el proceso de diseño de una interfaz de usuario se pueden distinguir cuatro fases o pasos fundamentales:

1. Reunir y analizar la información del usuario 2. Diseñar la interfaz de usuario 3. Construir la interfaz de usuario 4. Validar la interfaz de usuario

Reunir y analizar la información del usuario:

Es decir concretar a través de técnicas de requerimentación, qué tipo de usuarios van a utilizar el programa, qué tareas van a realizar los usuarios y cómo las van a realizar, qué exigen los usuarios del programa, en qué entorno se desenvuelven los usuarios (físico, social, cultural).

Diseñar la interfaz de usuario.

Es importante dedicar tiempo y recursos a esta fase, antes de entrar en la codificación. 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 menús 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 versión del programa que se realice rápidamente 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 diseño que parta del usuario, y no del sistema.

Existen 11 pasos en el proceso de diseño "centrado en las tareas", similar al anterior pero que desglosa algunas actividades implícitas en otras, así:

1.- Entender quien usará el sistema para hacer qué.

2.- Elegir tareas representativas para el diseño.

3.- Plagiar o copiar.

4.- Bosquejar un diseño.

5.- Pensar acerca del diseño.

6.- Crear un prototipo.

7.- Evaluarla con los usuarios.

8.- Repetir.

9.- Construirla.

10.- Rastrearla.

11.- Cambiarla.

Técnicas y pasos avanzadas para el diseño de interfaces de usuario

Presentación de información:

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 sólo por sí mismo, sino también por su combinación con el resto de elementos presentes en la pantalla.

El número de elementos visuales que perciben son: en el caso a) 1 (el fondo); en b) 3 (la línea, lo que está encima y lo que está debajo); en c) son 5 (el espacio fuera del recuadro, el recuadro, la línea y el espacio encima y debajo de ésta); finalmente, en d) el número se eleva a 35, siguiendo el mismo criterio. Conclusión: cada elemento nuevo que se añade influye más de lo que se piensa en el usuario.

Elementos de diseño de pantalla y su percepción visual

Análisis de Color: es probablemente el elemento de la interfaz que con más frecuencia es mal utilizado. El color comunica información, no es sólo decorativo (ejemplo: reforzar mensajes de error). Deben utilizarse combinaciones adecuadas (por ejemplo, las paletas proporcionadas por los sistemas operativos). El color debe atraer la atención, pero no cansar después de un rato de trabajo. Es especialmente importante seguir las líneas de diseño existentes. Principio básico: diseñar primero en blanco y negro, y luego añadir el color.

Análisis Audio. Primero es preciso ver cuándo es más apropiado que la información visual. Segundo, determinar el sonido adecuado. Tercero, permitir la personalización (volumen y desactivación). Como en el caso de los colores existen guías de uso. En lugares de trabajo abiertos, puede ser poco efectivo; además, puede ser embarazoso para algunas personas. El sonido debe usarse para informar, no cuando no añade nada nuevo (por ejemplo, un mensaje de aviso de correo o de bienvenida, respectivamente, al iniciar una sesión de trabajo).

Análisis Animación. Se define como un cambio en el tiempo de la apariencia visual de un elemento gráfico. Ejemplos de su uso: progreso de acciones (copia de ficheros en Windows 95, instalación de programas), estado de procesos (iconos de impresora), acciones posibles (cambios en el cursor al desplazar el ratón). La animación puede ayudar a subrayar iconos importantes, mostrar el estado de un objeto particular o explicar su comportamiento.

Diseño internacional. Debe hacerse un uso adecuado de la terminología. Hay mucho trabajo en este campo. Debe tenerse cuidado con las diferencias culturales (gestos, terminología, dibujos, formatos de teléfonos o calendarios, etc.).

Análisis y Elección 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 indicación visual de que se pueda arrastrar el objeto: ¿qué objetos se pueden arrastrar? ¿a dónde se pueden arrastrar? ¿qué ocurrirá cuando lleguen allí? ¿se podrá deshacer la acción?).

Diferentes controles para los mismos datos

Guías de Expertos

Existen diversas guías de diseño sacadas de expertos y comités, que complementan a las reglas de oro estudiadas anteriormente. Por citar algunas de ellas:

Demasiada simetría puede hacer las pantallas difíciles de leer. Si se ponen objetos sin alinear, hacerlo drásticamente. Asimetría=activo, simetría=sereno. Elementos de tamaño y color similares se perciben como pertenecientes a un grupo. Asumir errores en la entrada del usuario. Diseñar para el usuario, no para demostrar los propios conocimientos tecnológicos. Unos gráficos espectaculares no salvarán a una mala interfaz.

7. Conclusiones Y Recomendaciones

El conocimiento de estos puntos clave, nos permitirán enfocarnos mejor al estudio de la materia.

Las Interfaces de usuario, como vínculo de inmersión del hombre en el entorno de trabajo tecnológico actual, realzan su importancia en el desarrollo de nuevos productos, más eficaces, eficientes e interactivos, que es lo que el mercado demanda.

Puntos, cómo los históricos y evolutivos, deben ser abordados de manera más investigativa, recordemos que "conocer el pasado nos proyecta al futuro".

Otras puntualizaciones de clasificación obligarán 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-Máquina. Instituto Técnico Superior México, 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 Autónoma de Guadalajara, Tutorial "Diseño de una Interfaz Gráfica":

http://www.uag.mx/66/proceso1.htm SIGGRAPH de México: http://groucho.siggraph.org.mx/boletin/Ene99/index.htm LINEBACK, Graphical User Interface Timeline:

http://pla-netx.com/linebackn/guis/guitimeline.html

COMUNICACIÓN HOMBRE MÁQUINA, http://www.lsi.us.es/docencia/asignaturas/dihm/tema1/tema1.html

Trabajo recopilado y realizado por:Carlos Aimacaña Toledomitaly_ceat@latinmail.commitaly2000@magosoftec.intranets.com

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

Proceso de diseño del Interfaz de Usuario

Proceso de diseño 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 técnicas de evaluación o testing de usabilidad que

nos permitan tener datos reales del futuro éxito de la implementación.

En esta sección vamos a plasmar una metodología de trabajo para el ciclo de vida completo, desde la concepción hasta las pruebas finales y puesta en

producción de un sitio Web, que nos garantice máximos niveles de usabilidad del producto final.

Fase de Análisis:

Visión estratégica del site

Usabilidad en el proyecto

Equipo multidisciplinar

Objetivos de Usabilidad

Estudios de campoSelección de

productosPerfiles de usuario Análisis de tareas

Escenarios de usuario

Operativa de usuario

     

Reuniones con responsables para establecer una visión clara del site a diseñar

Inclusión 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

Búsqueda de productos competitivos Crear perfiles de usuario

Desarrollar un análisis de tareas Describir y documentar los escenarios de usuario

Describir y documentar los requerimientos de operativa de usuario

Fase de Diseño:

Diseño concept. / metáforas

Flujo pantallas / modelo naveg.

Revisiones de diseño

Revisiones conceptos diseño

Diseño lápiz y papel

Elaborar "low-fidelity"

Test "low-fidelity"

Elaborar "high-fidelity"

Test "high-fidelity"

Documentar estándares

Crear especific. diseño

   

Brainstormings: diseño de conceptos y metáforas Desarrollo del flujo de pantallas y el modelo de navegación

Realizar revisiones de conceptos de diseño Diseño con papel y lápiz

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"

Documentación de estándares y directrices Elaboración de una especificación de diseño

Fase de Implementación:

Evaluaciones heurísticas

Cooperación responsables entregas

Tests de usabilidad: post-entregas

Realización de evaluaciones heurísticas en curso Trabajar al lado de los responsables finales de la entrega según se va

implementando el diseño 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 información de cómo se está

usando Comprobar objetivos mediante tests de usabilidad

Autor: WebUsablehttp://www.webusable.com/useProcess.htm

 

4.3.1 Reglas en el diseño de interfaz de usuario.

TEORIA DEL INTERFAZ

1.- INTERACCIÓN HOMBRE-MÁQUINA

La interacción hombre-máquina ayuda a entender cómo la gente interactúa con la nuevas tecnologías. Además, esta interacción puede ayudar a mejorar las posibilidades de las nuevas tecnologías en la enseñanza en dos importantes aspectos: primero, puede guiar un análisis cuidadoso y sistemático sobre qué información, herramientas y capacidades necesita la gente para conseguir sus objetivos; y segundo, puede proporcionar herramientas y técnicas con las que evaluar útilmente en el esfuerzo por quitar defectos que estorban en una interacción tranquila entre la gente y las nuevas tecnologías.

Es decir, es necesario que se profundice en los factores que dificultan esta interacción. Este tipo de investigación permitirá la generación de guías para el diseño del interfaz de los usuarios de ordenador.

En los últimos años, se ha ido incrementando el interés en el estudio de los usuarios como parte del sistema hombre-máquina. No obstante, la mayoría de los estudios han sido dirigidos hacia los usuarios con experiencia con el ordenador, o más específicamente a programadores. Sólo algunos de los más recientes estudios se ocupan más específicamente 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 hábiles en la interacción con el ordenador. La interacción es para el usuario experto una destreza cognitiva de rutina.

Además, junto al nivel de experiencia del usuario es necesario atender a los estilos de aprendizaje.

2.- EVOLUCIÓN DE LA INTERACCIÓN

A pesar de que es dificultoso redactar a la vez una amplia cadena de investigaciones, la siguiente tentativa general referente a la interacción hombre-máquina indica que:

1. Ha habido un gran incremento en la cantidad de investigaciones de interacción hombre-máquina desde la pasada década.

2. Va tomando importancia el papel del usuario. 3. Mientras que los usuarios son una parte integrante de la interacción hombre-

máquina, 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 pequeñas investigaciones han remarcado el proceso cognitivo de los usuarios (programadores y no programadores) como su interacción con los sistemas del ordenador.

3.- INTERFAZ

Un ordenador ayudado de un sistema de información consiste en tres principales componentes: hardware, software y usuario. La interacción de estos componentes es una de las más importantes partes del sistema: el interfaz hombre-máquina.

El campo de interacción hombre-máquina se concibe con el diseño del interfaz y es altamente interdisciplinar por naturaleza. Esto supone investigaciones desde la Psicología, la Informática, la Ingeniería, la Educación y las Comunicaciones.

El interfaz hombre-máquina es un canal comunicativo entre el usuario y el ordenador.

Un asunto central de la investigación interacción hombre-máquina es determinar los efectos humanos, tanto psicológicos como cognitivos, y las características afectivas de las interacciones entre los usuarios y los ordenadores en tareas específicas. De esta manera, los investigadores de la interacción hombre-máquina desarrollan modelos de actividades humanas y uso de estos modelos en el diseño de nuevos interfaces.

La producción, distribución y administración de la información 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 tecnologías será continuamente mejorado en función de realizar el ideal de comunicación humana mundial. Los humanos quieren que expresiones como el diálogo, gestos o escribir a máquina sean entendidos inmediatamente por los ordenadores y otros sistemas de información. El "paradigma de la persona entera" y de "la red hombre-máquina" son los puntos culminantes en el mundo futuro de la comunicación.

La comunicación humana incluye no sólo pequeños trozos de información sino también intuición, sentimientos y emociones. El mundo futuro de la comunicación es a veces llamado "pueblo global" para enfatizar el grado de familiaridad creado por el ambiente de alta tecnología.

Tenemos que considerar un nuevo tipo de complejidad, referida a la emoción y intuición del hombre. Hasta el proceso de investigación científica está inspirado en la intuición humana y conducida por las emociones humanas y esto tiene que ser considerado en el mundo futuro de la comunicación.

Basándose en el análisis de las necesidades del usuario, el diseñador de sistemas de información y educación tendrá que seleccionar y integrar datos dentro de la representación informativa del particular dominio trabajo/ocio en el más alto de los niveles conceptuales, mientras que la visualización del formato será desarrollada desde hipótesis sobre la naturaleza de los modelos mentales y estrategias ocasionados, por el trabajo del usuario.

3.1. Principios para el diseño

El modelo de procesamiento de información que prevalece en la Psicología ha permitido los siguientes principios de diseño:

1. El interfaz tendría que compensar las limitaciones humanas, tanto físicas como cognitivas, siempre que sea posible. No obstante, tendría que ser "transparente", no ponerse en el camino de las acciones del usuario o impedir su progreso. Por otra parte, el interfaz no tendría que sobrecargar al usuario con complejidades innecesarias o distraerlo de su labor.

2. Los componentes físicos del interfaz tendrían que ser diseñados ergonómicamente, teniendo presente el confort y la salud del usuario tanto como sus necesidades.

3. El interfaz tendría que ser consistente.

4. El estilo de interacción no mandado como manipulación directa y menús son preferibles al lenguaje de orden. Como mínimo, el usuario experimentado tendría que tener capacidad de moverse rápidamente a través de las capas de los menús.

5. El interfaz tendría de poder tener acciones reversibles. 6. El interfaz tendría que estar sujeto a pruebas al principio del diseño del proceso y

durante su desarrollo.

El principio más básico del interfaz sería estar diseñado alrededor de las necesidades del usuario hasta después de que el sistema haya sido completado, atendiéndose de esta manera las restricciones impuestas por el sistema.

3.2. Tendencias en el diseño

Los sistemas de ordenador son cada vez más 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 utilización de los canales humanos de comunicación.

El interfaz acepta voz y gestos al mismo tiempo que da más 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 físicos del interfaz, hay una investigación activa en componentes conceptuales parecida a los estilos de interacción. La directa manipulación de interfaces continuará emergiendo y una más fuerte adaptación al sistema será desarrollada de acuerdo al tipo de tarea y el nivel de experiencia del usuario. Agentes inteligentes son también desarrollados por debajo. Los agentes pueden asignar tareas específicas para el usuario y después enviarlos a que ejecuten estas tareas.

4. ESTILOS DE APRENDIZAJE

Se necesita investigar sobre los alumnos y sus características para poder determinar qué tipo de enseñanza es la mejor para cada tipo de alumno en cada tipo de ambiente.

En el diseño de material multimedia interactivo, una experiencia de aprendizaje es más rica cuando hay diferentes formas de enseñanza para las diferentes formas de aprendizaje de los alumnos. Todo el proceso de aprendizaje es más eficiente si los alumnos pueden determinar su propio camino, seleccionando la información disponible para ellos, del modo más 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 teóricas. b. Tipo "acomodador", que se fía de juicios intuitivos y aproximaciones erróneas para resolver

problemas y se adapta a situaciones novedosas. c. Tipo "divergente", que contempla un problema desde múltiples perspectivas y tiene unos

amplios intereses culturales. d. Tipo "convergente", que utiliza el sentido común para resolver problemas. Esta perspectiva

de aprendizaje puede ser importada en el diseño de currículum multimedia porque muchas de las diferentes reglas en la producción de multimedia reflejan varios tipos de aprendices. Y si un estilo de aprendizaje encaja con un papel apropiado de producción entonces podría darse un mejor aprendizaje y producción.

5. PAPEL DEL DISEÑO EDUCATIVO EN LOS ORDENADORES

Ya anteriormente, el papel del diseño instruccional en ordenadores fue apoyado por Gagné (1982). Él argumentaba que diseñadores educativos y programadores de ordenadores trabajasen juntos para producir ordenadores basados en materiales que tuviesen ventajas para las características particulares del ordenador. También 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 diseño educativo.

Uno de los más importantes factores que los diseñadores educativos pueden aportar a los ordenadores es el conocimiento de la relación materiales y cognición 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 interacción hombre-ordenador.

¾ Kearsley y Hillelsohn (1982), exigían una metodología sistemática para el proceso comprometiendo a los usuarios en el diseño y la implementación de los ordenadores en sistemas formativos.

¾ Baker (1982), que reclamaba el desarrollo de una variedad de técnicas de interacción que permitiese a los usuarios seleccionar las formas de interacción que más conveniese a sus intereses.

¾ Stewart (1980) fue el más específico, argumentando a favor del control de un número de directrices para la interacción hombre-máquina.

Estas metas para el diseño de sistemas interactivos proporcionan un útil grupo de directrices para los diseñadores de materiales de enseñanza asistida por ordenador. No obstante, el término "usuario" necesita ser especificado con más conocimiento de las diferencias individuales entre usuarios.

6. FACTORES QUE INFLUYEN EN LOS PROCESOS COGNITIVOS

Los diseñadores educativos tendrían que tener presente:

1. Características del usuario: ser conscientes de los probables usuarios de la población, y además, de sus diferencias en los procesos cognitivos.

2. Simplicidad: la noción de simplicidad requiere especificación. Lo que es simple para unos usuarios no tiene porque serlo para otros.

3. Flexibilidad: aparentemente los materiales de la enseñanza asistida por ordenador necesitan ser flexibles en la mayoría 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 diseñadores de materiales multimedia trabajan con conocimiento de los caminos en los cuales los usuarios interactúan 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 podría ser correcto, significativo y informativo, se requieren investigaciones para averiguar que significan estos términos para el usuario.

6. El formato de los materiales: como en otras áreas de diseño 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 educación es una tendencia muy popular en educación. En los últimos años ha aparecido la utilización de los multimedia tanto por parte de los tutores como de los alumnos.

El aprendizaje situado es:

1. Un aprendizaje social más que un aprendizaje individual. 2. Un aprendizaje basado en herramientas más que un aprendizaje independiente de

herramientas. 3. Un aprendizaje ocupado en los objetos más que un aprendizaje dependiente de

símbolos. 4. Un aprendizaje basado en una situación específica más que un aprendizaje teórico.

¿Cuál es el proceso?

El aprendizaje situado tiene lugar en y a través de la interacción con otros en un contexto de resolución de problemas que es auténtico más que descontextualizado. El aprendizaje se produce a través de la reflexión de la experiencia, a partir del diálogo con los otros y explorando el significado de acontecimientos en un espacio y tiempo concreto, como por ejemplo, el contexto.

¿Cuáles son los componentes del proceso?

El aprendizaje situado integra cuatro factores críticos que maximizan el aprendizaje potencial del alumno:

1. Satisfacción 2. Contexto 3. Comunidad 4. Participación

La tecnología permite a estudiantes aplicar teorías a situaciones cotidianas reales a través de micromundos, networds, bases de datos, paquetes de gráficos y editores de texto. Los beneficios son:

1. Los estudiantes aprenden cómo aplicar el conocimiento que han aprendido.

2. Cuando los alumnos aplican teorías a una situación, el cómo usar la teoría en otras situaciones es más evidente.

3. Teorías almacenadas en contextos de situaciones son mucho más útiles que unas simples palabras memorizadas de una teoría. El aprendizaje de teorías puede darse en múltiples contextos no sólo en uno. De esta manera los alumnos pueden aprender a generalizar sobre qué teorías usar y cómo 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 cognición, ni reviste un carácter auxiliar. Tampoco es neutral, sino que forma parte de lo aprendido. Podemos decir que las situaciones coproducen el conocimiento a través de la actividad. En consecuencia, podemos afirmar que el aprendizaje y la cognición están fundamentalmente situados.

La investigación educativa actual puede impactar en el diseño del currículum multimedia por muchos caminos.

Componentes del diseño de un currículum multimedia

Estos cuatro componentes podrían ser útiles en el diseño de un currículum multimedia. Un currículum educativo necesita estar basado o fundado sobre algún paradigma o epistemología, y una perspectiva constructivista podría ser apropiada para la construcción de multimedia. La teoría cognitiva puede contribuir mucho al diseño de un currículum.

Si apropiados procedimientos y principios, utilizados en la industria, pudiesen ser aplicados a un ambiente educativo constructivo, entonces se podría producir un auténtico ambiente multimedia.

El componente final de este currículum multimedia propuesto podría ser extraído desde el uso y práctica de multimedia en educación.

III.- CONCLUSIONES

Podemos encontrar muchos trabajos sobre multimedia y educación en la literatura educativa corriente, pero hay pocos trabajos que actualmente se basen en el currículum multimedia donde la finalidad de estudio es el completo estudio del diseño y producción multimedia.

El principal aspecto en este nuevo tipo de enseñanza es un cambio en los paradigmas que están alrededor del aprendizaje del alumno y la tecnología. En el pasado, el multimedia ha sido utilizado para seminarios y exploración de conocimiento, mientras que ahora se está dando énfasis a la construcción de conocimiento.

La tecnología necesita convertirse en una herramienta para el profesor/tutor. Los estudiantes podrían utilizar los multimedia para sintetizar y exponer su propio conocimiento. Es decir, utilizar esta nueva tecnología para construir un medio de comunicación de estructuras de conocimiento ricas en componentes de información diversa desde una variedad de fuentes.

Múltiples áreas han de ser examinadas para diseñar un currículum multimedia constructivista. Se necesita abarcar desde la investigación cognitiva y cuestiones de diseño educativo, hasta el diseño de la clase y cuestiones de hardware de ordenador.

Un elemento que puede contribuir a la hora de construir nuevos conocimientos a través de las nuevas tecnologías es el interfaz siempre realizado siguiendo las pautas de diseño anteriormente descritas. La comprobación de que esto se puede llevar a la práctica es el interfaz de Campus Extens, basado siempre en las pautas de senzilez, armonía, consistencia e intuición.

Pocas cosas han cambiado desde su creación en las páginas de Campus Extens (colores de fondos, pastillas en el cuaderno descriptivo y en los módulos...), pues desde el principio quisieron ser coherentes y mantener unos principios de diseño en forma de reglas que sirviesen primero a lo largo de todo el documento (asignatura), incluso en las ampliaciones que se pudieran realizar, y después 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 información llegue a todos los alumnos por igual, por ello utiliza lenguajes clásicos ya que no es partidario de innovaciones injustificadas. Prefiere mantener una estructura visual lógica y que no desoriente antes que introducir elementos diferentes que pueden "atrapar" por el efecto novedad pero que también 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.

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

o HALE, D. J. (ed). International Journal of Man-Machine Studies, 1981, 14, 235-236. o 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.

o 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 User-Computer 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 NISBET, J., SHUCKSMITH, J.: Estrategias de aprendizaje. Aula XXI, Santillana. Madrid, 1987.

o STEWART, T. Communicating with dialogues. Ergonomics, 1980, 23(9), 909-919. o SEELY, J., COLLINS, A., DUGUID, P.: La cognición situada y la cultura

del aprendizaje. Kikiriki-39.

El interfaz de usuario.

DATOS DE LOS AUTORES:

Margalida Noguera Oliver

Cristina López-Polín Hernanz

Jesús Salinas Ibáñez

(Universitat de les Illes Balears)

Resumen

Con esta comunicación pretendemos revisar algunas teorías sobre el interfaz de usuario que han aparecido en los últimos años, analizando la interacción hombre-máquina, 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 diseño educativo en los ordenadores. Finalmente, describiremos un caso práctico: 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, interacción hombre-máquina, home, herramientas de comunicación.e contenido.

http://www.filos.unam.mx/POSGRADO/seminarios/pag_robertp/paginas/interfaz.htm

4.3.2 Integración 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 más importantes del sistema.

El 1er. Objetivo de la fase de elaboración es construir una arquitectura sólida 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 páginas para la Descripción 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 visión común (en sist. soft. grandes)

Para dividir el proyecto en clases y facilitar su reutilización (futuros cambios)

1. Compresión del sistema

Todos las personas que trabajen en el desarrollo del sistema deben comprenderla lo cual es un reto difícil porque: operan en entornos complejos y al dividirlos en miniproyectos es difícil coordinarlos.

2. Organización del desarrollo

Mientras más grande sea el proyecto habrá mayor sobrecarga en la comunicación entre los distintos desarrolladores; para ello se divide el sistem en subsistemas donde cada uno tendrá un responsable. También es importante tener interfaces bien definidas.

3. Fomento de la reutilización

Este capitulo es un quilombo. Jacobson andate a la concha de tu madre que te parió cagando.

4. Evolución 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 más importantes (más 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. Estándares y políticas corporativas. Requisitos no funcionales.

La arquitectura del sistema se desarrolla en fase de elaboración juntos con los casos de usos más 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 según la arquitectura del sistema.

La arquitectura guía los casos de uso: Mientras más 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 ampliación se realiza una vez por cada iteración.

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 elaboración. El resultado de esta fase es una línea base de la arquitectura (esqueleto del sistema) que consta de poco software.

1. Línea base de arq: sistema pequeño y flaco

Lo mismo que el 4.4 pero con más boludeces.

La línea base del sistema es una versión interna y se basa en la descripción de la arquitectura.

Cada versión nueva de un modelo se desarrolla a partir de la versión anterior. Nunca son independientes unos de otros.

Los elementos de un mismo modelo se relacionan por medio de dependencias de trazas.

Descripción de arquitectura: Sirve para guiar a los desarrolladores durante ciclo de vida actual y como base para el futuro.

Teniendo una arquitectura estable, la descripción de ésta también será estable.

2. Utilización de patrones en la arquitectura

Definición de Patrón: Solución a un problema de diseño que aparece con frecuencia.

Estos patrones están documentados en libros; en ella hay diferentes plantillas donde asignan un nombre a cada patrón y describe los problemas, qué los causa y las soluciones.

Algunos patrones de diseño: Facade, Decorator, Proxy Observer, Strategy, Visitor.

Los patrones de diseño son ideal para lenguajes con orientación a objetos. Los patrones de arquitectura son ideal para sistemas, subsistemas e interfaces.

Definición 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 aplicación) requieren interfaces menos estables.

1. Descripción 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.

También debe presentar:

Vistas de los distintos modelos. Requisitos que no figuran en los CU (NO funcionales / adicionales) Breve descripción de plataforma, sistema heredados y software comercial q se va a utilizar.

En la DA se describen con más detalle los subsistemas que son significativos para la arquitectura que representan un aprox.10%. Los CU en su mayoría 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 códigos para comunicarse con desarrolladores.

Puede que se necesiten más de un arq. para desarrollar sistemas grandes.

El desarrollo de arquitectura consume mucho tiempo.

1. Ejemplo pág. 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 pequeños pasos

En las primeras iteraciones se realiza:

Determinación del ámbito del proyecto. Eliminación de riesgos críticos. Creación de la línea 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 añaden incrementos hasta llegar a la versión 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, análisis, diseño, implementación, 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 iteración

Si el desarrollador pasa del ciclo de inicio al de elaboración...

Sin resolver los riesgos más críticos. Sin establecer una línea base de la arquitectura. Sin implementar los casos de usos importantes.

Además de ser un choto está construyendo un proyecto no fiable y no vale la pena que siga con él.

La iteración 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. Atenuación de riesgos

Riesgo: es una variable que pone en peligro o impide el éxito del proyecto.

"Aproximación al proceso de desarrollo dirigido por riesgos": El Proceso Unificado reconoce los riesgos más importantes en las primeras 2 fases y reduce los mismos. Los que no, pueden poner en peligro el proyecto entero.

Método cascada: El desarrollo del sistema no se divide en iteraciones. Los problemas graves pueden saltar en la fase de integración & prueba; esto obliga a contratar a desarrolladores con más experiencia, el proyecto queda parado y se retrasan las fechas.

Método iterativo: Los riesgos importantes se tratan en las primeras fases, quedando muy pocas en la de construcción. El proyecto marcha sin inconvenientes hasta el final.

2. Obtención de una arquitectura robusta

Método 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.

Método iterativo: Es al final de la fase de elaboración donde se evalúa la arquitectura; si aún no está madura se trabaja en una nueva iteración; esto es posible ya que es muy poco lo que se in-vierte en esta fase y las fechas aún no están definidas.

3. Gestión de requisitos cambiantes

construcción: es una versión operativa del sistema que demuestra un subconjunto de posibilidades.

Es más fácil para el usuario ver un sistema ejecutable en funcionamiento que leer cientos de páginas de documentos. Esto permite a que los usuarios opinen y sugieran modificar o agregar cosas que se nos pasó de largo. En método cascada los usuarios ven al sistema funcionando recién en la integración y prueba, y si desea cambiar algo deberán aumentar presupuesto y atrasar las fechas.

4. Permitir cambios tácticos

Con método iterativo los directores se encargan de ver al final de cada iteración..

Si hubo un incremento y se han resueltos los problemas; entonces autorizará a los desarrolladores a seguir con la siguiente iteración.

Si el éxito fue parcial, se ampliará la iteración hasta poder cumplir con lo requerido. Si el resultado es negativo puede llegar a cancelarse el proyecto.

1. Conseguir una iteración continua

Método cascada: Muchos errores parecen no estar presentes y el proyecto progresa con norma-lidad hasta llegar a la integración y prueba; ahí salen todos a la luz. Estas ponen en peligro al proy

Método iterativo: Ya desde un principio se hacen frecuentes construcciones, y con éstas aparecen los errores que se tratarán 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 iteración a otra. Puede empezar con unas 5 a 10 pers. pasar a 25 y finalmente a 100. Los nuevos tienen una formación adecuada y trabajan con gente con experiencia, rápidamente se ajustan a la velocidad adecuada.

1. La aproximación 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 iteración temprana.

En fase de inicio y elaboración se tratan la mayoría de los riesgos.

1. Las iteraciones alivian los riesgos técnicos

Hay 4 formas de tratar a un riesgo según su prioridad:

Evitarlo: Quizás se tenga que replanificar el proyecto o hacer un cambio de requisitos. Limitarlo: Achicarlo para que afecta una parte pequeña 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 mínimos.

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

1. Iteración genérica

1. Qué es una iteración

Una iteración es un miniproyecto donde se tiene como resultado una versión interna.

Está compuesto por 5 flujos de trabajos: requisitos, análisis, etc.

Los trabajadores y artefactos pueden trabajar en más de un flujo de trabajo.

Las Fases están divididas en N iteraciones. Descripción de cada fase:

Inicio: Hacer análisis del negocio y reducir los riesgos más importantes. Elaboración: Obtener línea base de la arquitectura, capturar requisitos, reducir demás

riesgos. Construcción: Desarrollar el sistema entero. Ofrecer funcionalidad operativa a clientes. Transición: Tener el producto preparado para la entrega. Se enseña a usuarios a utilizar el

software.

Cada iteración se analiza cuando termina y se ven si cambiaron o aparecieron nuevos requisitos que modificarán a la siguiente iteración.

Prueba de regresión: Sirve para ver si no se han estropeado iteraciones anteriores. Se aplica al antes de terminar con la iteración actual.

1. Planificación de las iteraciones

Requiere de más tiempo que en el modo cascada.

En método cascada la planificación se realiza en un principio, osea, antes de tratar los riesgos importantes y tener una línea base sólida.

Método iterativo: No se planifica proyecto entero en fase de inicio, solo unos pasos. Es al final de la fase de elaboración 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 patrón.

En las primeras iteraciones se conocen mejor los requisitos, riesgos y soluciones. Las iteraciones sgtes. dan como resultado incrementos aditivos que terminan en una versión externa.

La planificación y trabajo de una iteración empieza cuando la anterior se está por entregar.

1. El resultado de una iteración es un incremento

Definiciones de Incremento:

Diferencia entre la versión interna de la iteración anterior y la siguiente.

Diferencia entre 2 líneas bases sucesivas.

Colaboración: Es la representación de los CU más significativos para la arquitectura. Sirve para identificar subsistemas e interfaces. Luego se les da forma (implementa código).

Hay más incrementos a medida que nos acercamos a la fase de transición.

La integración 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 están en punto 4.2

Al final de cada iteración 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 iteración. Los jefes deciden cómo continuar en itera-ciones siguientes.

En fases inicio y elaboración es poco el grupo de gente trabajando (bajo costo).

Aumenta el número de personas en fase de construcción.

CAPITULO 6

Cap. de requisitos: de la visión a los requisitos

1. Por qué la captura de requisitos es complicada

Capturas de requisitos: es el proceso de averiguar en circunstancias difíciles qué se debe construir.

Los desarrolladores no pueden escribir un código sin saber qué es lo que debe hacer. Algo que sucede en algunas ocasiones. Analistas documentaban requisitos según lo que los usuarios pedían, pero llegaba a cientos de páginas y no podían concretarse fácilmente. Los usuarios sabían bien qué debía hacer el software recién 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 cuáles 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 informático, 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. Visión 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 arquetípicos:

Enumerar los requisitos candidatos: De aquí se obtienen características: 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 descripción 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 cómo 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 comunicación entre la gente que trabaja. Los objetos ayudan a identificar clases.

Modelo de negocio: Es más amplio que el modelo de dominio. Describe los procesos que componen el negocio. Objetivo Comprender cuáles 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 cómo 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 líneas de código. Imponen condiciones a requisitos funcionales.

Puede que no pertenezca a ningún 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 mayoría de los CU para detallar los más importantes (10%)

elaboración: Se captura un 80% de requisitos para estimar tiempo de proyecto.

construcción: Se capturan e implementan los demás requisitos.

transición: No hay captura de requisitos.

1. Cómo 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

Interacción: Es una secuencia de acciones que el sistema lleva a cabo (interactuando con actores) para dar un resultado de valor. Descripción de CU puede incluir diagramas de actividad.

Instancia de CU: Es la realización de los CU. Son atómicas: se ejecutan todo o nada. Sin otros de por medio.

Los CU tienen atributos, valores que en su ejecución 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: descripción de una arquitectura

Contiene una vista del modelo de CU que describe los aspectos más 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.

Diseñador de interfaz: Es responsable del prototipo de interfaz de usuario.

Arquitecto: Trabaja con la captura de requisitos para diseñar las vistas de la arq del modelo de CU.

2. Flujos de trabajo

Conjunto de actividades que están 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 través 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 versión 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 fácil 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 más actores que tengan los mismos roles.

El analista le asigna un nombre a cada actor y hace una breve descripción 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 ejecución satisfactoria de un CU da un resultado de valor para que el actor pueda alcanzar su objetivo.

La instancia de un CU involucra a más de un actor.

2. Priorizar casos de uso

Los CU más importantes se desarrollan en primeras iteraciones.

La vista de arquitectura del modelo de CU describe los CU más 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.

Transacción: 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 erróneas del actor.

¿Qué incluye la descripción de un CU?

Estado inicial como precondición. Cómo y cuándo comienza un CU. Orden en que se ejecutan las acciones. Cómo y cuándo termina un CU. Descripción de estado final como postcondición. Descripción de caminos alternativos. Utilización de objetos, valores y recursos. Separar las responsabilidades del sistema / actores.

Requisitos especiales: Son los requisitos no funcionales; especifica sgte. características 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 cómo un usuario puede utilizar el sistema para ejecutar un CU.

Se diseña durante fases de análisis, diseño e implementación.

SECCIÓN: Ing. de software / Análisis de sistema

 

 

 

Ezequiel Hernández

ezequielher@yahoo.com

Argentina

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