6.1. Ficha de caracterización del subproceso Gestión de Requerimientos y Requisitos

Tamaño: px
Comenzar la demostración a partir de la página:

Download "6.1. Ficha de caracterización del subproceso Gestión de Requerimientos y Requisitos"

Transcripción

1 Índice de contenido 6.1. Ficha de caracterización del subproceso Gestión de Requerimientos y Requisitos Descripción de la Actividades del procedimiento Gestión de Requerimientos y Requisitos Guias Los Requerimientos y Requisitos Detallando un Requerimiento(s) o Requisito(s) Definición de los Requisitos Técnicas de Captura de Requerimientos y/o Requisitos Errores comunes en la definición de los Requerimientos y Requisitos Revisiones Efectivas de los Requerimientos y Requisitos Construcción del documento Visión...29 Impacto de no contar con el artefacto...29 Opciones de Representación...30 Pasos...30 Lista de Verificación Construcción de los Casos de Uso...33 Propósito...33 Opciones de Representación...34 Propiedades de los Casos de Uso...35 Lista de verificación Construcción de los Modelos de Casos de Uso...39 Opciones de Representación...40 Lista de Verificación Construcción del Documento Especificaciones de requisitos...42 Impacto de no contar con este artefacto...42 Opciones de Representación...43 Lista de Verificación Construcción del Glosario...45 Propósito...45 Consideraciones claves...45 Impacto de no tenerlo...45 Opciones de Representación...45

2 6.1. Ficha de caracterización del subproceso Gestión de Requerimientos y Requisitos

3

4 6.2. Descripción de la Actividades del procedimiento Gestión de Requerimientos y Requisitos Nombre de la Actividad 1. Definitr o Ajustar Necesidad(s) 2. Elaboración o actualización de la lista maestra de requerimiento(s) Descripción Una necesidad es una demanda que expresa una persona(s), dependencia(s) o instancia con respecto a una situación problemática y que puede ser solucionada a través de una aplicación informática. El interesado debe emitir o expresar cual es su necesidad y el analista debe interpretarla y asi iniciar el proceso de desarrollo. Un requerimiento es la descripción precisa y clara de una necesidad funcional en términos de lo que debe hacer el sistema. Una necesidad puede descomponerse en varios requerimientos dependiendo de la manera como se haya definido. Responsables Analista Interesados Analista Artefactos Relacionados (Procductos) Solicitud de Necesidad Lista Maestra de requerimientos Guías Los requerimientos y los requisiitos Detallando un requerimiento(s) o requisito(s) Tecnicas de Captura de requerimientos y requisiitos Errores comunes en la definición de los requerimiento(s) y requisitos(s) Revisiones efectivas de los requerimientos

5 3. Elaboración y actualización del documento Visión 4. Elaboración y actualización Documento Glosario 5. Elaboración y actualización del documento Especificación de Requisitos 6. Aprobación de la Visión Con base en las necesidades de los interesados, los requerimientos y los requisitos de alto nivel definidos por el analista se plantea la situación problematica y la posible solución informatica para los interesados. A medida que se definen y ajustan las necesidades y requerimientos de los interesados, se construye y unifican cierta terminología entre los interesados y el equipo de trabajo con el fin de que exista una buena comunicación entre los mismos. Un requerimiento responde a una necesidad funcional del sistema, mientras que un requisito representa una necesidad técnica en terminos de usabilidad, confiabilidad, disponibilidad y seguridad del sistema. Luego de una revisión de la visión por parte de los interesados, estos evaluan si aprueba o no la definición o solución al problema planteado, en caso de que no se apruebe se debe ajustar el documento y consecuentemente las necesidades planteadas. Analista Visión Construcción del documento visión Analista Interesados Glosario Analista Documento Especificación de requisitos Construcción del Glosario La construcción del documento Especificaciones de Requisitos Interesados Acta Construcción del documento visión

6 7. Aprobación de los Requerimientos 8. Elaborar modelos, casos y especificaciones de uso 9. Diseño, desarrollo y despliegue de los requerimientos y requisitos. Al igual que con el documento visión, los interesados deben dar su aval cuando se define un requerimiento y en caso de que no se aprueben deberán ser ajustados para su futura aprobación. Con base en los requerimientos aprobados, se procede a detallarlo mediante diagramas, casos y especificaciones de casos de uso. Este procedimiento (Gestión de requerimientos y requisitos) es el insumo para llevar a cabo el diseño, desarrollo y despliegue del software Interesados Acta Los requerimientos y los requisiitos Detallando un requerimiento(s) o requisito(s) Tecnicas de Captura de requerimientos y requisiitos Errores comunes en la definición de los requerimiento(s) y requisitos(s) Revisiones efectivas de los requerimientos Analista Equipo de Desarrollo Modelo de Casos de Uso. Caso de Uso de alto Especificación de caso de uso Construcción de los casos de uso Construccion de los modelos de casos de uso Revisar los capitulos siguientes

7 10. Control de Cambios diseño, desarrollo y depliegue del software. A medida que surgen los cambios propios del proceso de desarrollo (Anáisis, diseño, desarrollo, despliegue), es necesario ajustar la documentación propia de la gestión de requerimientos y requisitos, como la visión, el glosario, los casos de uso de alto nivel, las especificación de requisitos y lista maestra de requerimientos. Analista Visión Lista Maestra de Requerimientos Especificación de requisitos Modelo, caso de uso de alto nivel y especificaciones de casos de uso Revisar capitulo Gestión de Cambios

8 6.3. Guias Los Requerimientos y Requisitos Los Requerimientos definen: Lo que los grupos de interés (usuarios) necesitan Lo que el sistema debe incluir para satisfacer las necesidades de los grupos de interés. Los Requerimientos son las listas "por hacer" del equipo del proyecto. Los Requerimientos definen lo que es necesario y enfoca al equipo del proyecto. Son el mecanismo primario para comunicar los objetivos del proyecto a cualquiera que intervenga en el proyecto. Son la base para capturar y validar las necesidades, administrar las expectativas, priorizar y asignar el trabajo, verificar y validar el sistema y administrar el ámbito del proyecto. Los requerimientos pueden tomar diferentes formas incluyendo los casos de uso y los escenarios, texto no estructurado, texto estructurado o una combinación de todos ellos y pueden estar estructurados en diferentes niveles de granularidad. En el más alto nivel de granularidad las características definen los servicios que el sistema debe proveer para solucionar los problemas de los clientes. Dichas características son capturadas en texto estructurado o no estructurado dentro del Visión. El siguiente nivel de granularidad son los casos de uso que definen la funcionalidad que el sistema debe tener para poder proveer las características requeridas, estos describen la secuencia de acciones desarrolladas por el sistema para poder brindar un resultado observable que sea de valor para el actor o actores. El sistema debe ser desarrollado de acuerdo al comportamiento que se especifica en los casos de uso. Sin embargo, existen requerimientos del sistema que representan un comportamiento específico a estos se les denomina Requisitos tales como: Requisitos legales o normativos, así como estándares. Atributos de calidad incluyendo características de uso e interacción con los usuarios, confiabilidad, desempeño y requerimiento de soporte. Requisitos de interfaz que le dan capacidad al sistema para interaccionar con sistemas externos. Restricciones de diseño tales como sistemas operativos, imagen institucional o de compatibilidad con otro software.

9 Los requisitos se capturan de forma estructurada en el documento Especificaciones de Requisitos de soporte Los requisitos de soporte están clasificados de acuerdo al modelo FURPS+ (Funcional (Requerimientos), características de uso e interacción con el usuario, confiabilidad, desempeño, capacidad de soporte + restricciones). Las restricciones incluyen aquellas relacionadas al diseño, implementación, interfaces y reglas del negocio. Los requisitos de características de uso e interacción con los usuarios Incluye aquelos basados en factores humanos e interfaces de usuario tales como la capacidad de acceso, estética de las interfaces y consistencia. Los requisitos de confiabilidad Incluye aspectos tales como la disponibilidad, exactitud, proyección, frecuencia de fallo o recuperación del sistema en caso de fallo. Los requisitos de desempeño incluye requisitos de carga de información del sistema, tiempos de respuesta del sistema y uso de recursos. Por otro lado encontramos los requisitos asociados a las restricciones de diseño, implementación, interfaces, físicas y reglas de negocio: Restricciones de diseño: limitar el diseño y declarar los requisitos sobre el enfoque que debe tenerse en cuenta en el desarrollo del sistema. Restricciones de implementación: poner límites al proceso de generación de código o de construcción. (estándares requeridos, lenguajes, herramientas o plataforma) Restricciones de interfaz: son requerimientos para interaccionar con sistemas externos, describiendo los protocolos o la naturaleza de la información que debe ser transferida a través de la interfaz. Restricciones físicas: afectan el hardware o el empaquetado del sistema (forma, tamaño y peso) Reglas del negocio: son la políticas, normas, estatutos, acuerdos, resoluciones o cualquier tipo de decisión que gobierna la forma en que la institución opera. Ellas restringirán los pasos descritos en el flujo del caso de uso. Los requerimientos, requisitos y los casos de uso definen las necesidades de lo que se quiere del sistema. Estos deben soportar las características dadas en la declaración de Visión. Cada requerimiento y requisito debe soportar al menos una de las características y cada característica debe estar soportada por al menos un caso de uso. En general, los requerimientos describen el comportamiento y son capturados en los casos de uso y los requisitos o requerimientos no funcionales son capturados en el artefacto Especificación de Requisitos de Soporte. Sin embargo, algunos requisitos están relacionados con algunos casos de uso por lo que estos son capturados directamente dentro de ellos para simplificar la comunicación y el

10 mantenimiento. Por otro lado existen requerimientos globales, o de nivel de sistema, que son capturados junto con los requerimientos de soporte. A los requerimientos y requisitos se le puede asignar unos atributos para ayudar en la gestión del proyecto. Los atributos son propiedades que determinan información adicional e importante. Esta información pude ser utilizada para responder preguntas acerca del estado de desarrollo de un proyecto específico. A continuación se muestra un conjunto típico de atributos. El valor de cada uno de ellos podrá ser un número, un valor boleano, una fecha o simplemente una cadena de texto: Prioridad: Declara la importancia relativa del requerimiento o requisito desde el punto de vista de los interesados. Puede ser usada una escala de valoración (alta, media, baja). De acuerdo a la complejidad del sistema dicha escala deberá poseer más valores que hagan más discernible el modelo de requisitos. Asignado a: En la institución quien es el encargado de asegurarse que el requerimiento o requisito se esta cumpliendo. Corresponde a un nombre de persona y a un rol específico dentro de la institución. Iteración La iteración en la cual se pretende implementar el requerimiento o requisito Estimación del tamaño Brindar una estimación de alto nivel que de cuenta del esfuerzo requerido parta implementar y verificar el requerimiento o requisito y su solución. Usualmente se mide a partir de valores sin unidades. Esfuerzo faltante: Un estimativo del esfuerzo que falta para implementar y verificar el requerimiento o requisito y su implementación. Usualmente en horas Estado: Marca el progreso en la implementación de un requerimiento o requisito. Puede utilizarse una lista numerada (completo, parcialmente completado, no iniciado) o puede ser inferido desde el atributo del esfuerzo faltante. Cuando se asignan valores a todos los atributos de un requerimiento o requisito resulta relativamente sencillo responder preguntas acerca del estado del proyecto: Cuantos requerimientos o requisiitos fueron implementados en la iteración? Que porcentaje de requerimientos o requisitos de alta prioridad han sido implementados? Cuantos requerimientos o requisitos asignados a la presente iteración continúan sin ser implementados? Cuales requerimientos o requisitos están asignados a una persona en especial? otros atributos útiles podrían ser:

11 Fuente: Persona, documento u otro origen del requerimiento. Este es importante para poder determinar a quien referirse cuando se tengan inquietudes o para agrupar requerimientos de acuerdo a una fuente en particular. Comentarios: Comentarios hechos a un requerimiento o requisito por parte de los revisores o escritores. Dificultad: Un indicador del nivel de esfuerzo requerido para implementar el requerimiento (Alto, medio, bajo). Riesgo: Medida confidencial acerca de la probabilidad real de cumplir o no un requerimiento o requisito. ID de prueba: Identificación de una prueba específica u otro método de verificación que pueda ser aplicado al requerimiento o requisito Detallando un Requerimiento(s) o Requisito(s). Un requerimiento(s) y/o requisito(s) deben ser escritos en una sola frase conformada por un sujeto y un predicado. El sujeto es un actor, un interesado, el sistema en desarrollo o una entidad de diseño que esté relacionada con el requerimiento. El predicado especifica la acción, o el resultado esperado, que es realizada por, para o con el sujeto, usualmente incluye condiciones y criterios de desempeño. Así es posible analizar un requerimiento o requisito desde un pinto de vista gramatical. Por ejemplo: El modulo de matrículas debe ser capaz de completar 100 peticiones de los estudiantes en menos de 10 minutos. Este requerimiento o requisito tiene un sujeto (el módulo de matrículas, que es parte del sistema en desarrollo), un estado de finalización específico y medible (100 peticiones de estudiantes completadas) y un criterio de desempeño (en menos de 10 minutos). En los requerimientos o requisitos de los interesados el uso del debería ser capaz de expresar claramente que el interesado puede realizar algo pero no está obligado a hacerlo. Para el caso de los requisitos del sistema la forma verbal deberá expresar que el sistema se obliga a ejecutar esa acción cuando se cumplan determinadas condiciones. Agrupar los requerimientos en listas numeradas pueden hacer que la lectura sea más clara pero debe tenerse en cuenta que cada ítem de la lista debe ser en sí un requerimiento completo. Deben evitarse palabras que conduzcan a ambigüedad tales como todos, todo, algunos.

12 Las siguientes guías ayudaran a escribir mejores requerimientos o requisitos. Para mantener la consistencia del ejemplo todos los requerimientos se encuentran en el contexto de un proceso de admisiones: Definir un requerimiento o requisito a la vez. Por ejemplo usar, El Jefe de Admisiones debe ser capaz de actualizar el listado de inscritos de acuerdo a la información del estrato socio económico. El Jefe de Admisiones debe ser capaz de actualizar la información del estrato socio económico. Evitar las conjunciones (y, o) que generan múltiples requerimientos y fomentan la ambigüedad. Por ejemplo es mejor usar: El Aspirante debe ser capaz de observar si fue admitido desde la ventanilla de admisiones. El Aspirante deber ser capaz de observar información relacionada con el proceso de admisión en la ventanilla de admisiones. En lugar de: El Aspirante debe ser capaz de ver desde la ventanilla de admisiones si fue admitido y toda la información relacionada con el proceso de admisiones. La última forma es potencialmente peligrosa en el sentido de que no se especifica claramente si el Aspirante debe ver la información al mismo tiempo a hacen parte de dos procesos separados. Evitar frases sueltas o palabras que impliquen opciones o excepciones (a menos que, exceptuando, si es necesario, pero). Estas son peligrosas ya que dificultan la tarea de determinar si el requerimiento aplica o no. Será mejor escribir requerimiento separados para cada condición o estado del sistema. Por ejemplo, es mejor usar: El sistema debe ser capaz de generar el recibo de pago 10 días antes del inicio de clases. El sistema debe ser capaz de generar un recibo de pago en cualquier fecha cuando lo solicite al Consejo de Facultad. En lugar de: El sistema debe ser capaz de generar los recibos de pago 10 días antes de iniciar las clases a menos que haya una solicitud del Consejo de Facultad. Usar frases simples y directas

13 El Jefe de Planeación debe ser capaz de ver el indicador de ocupación del salón. En lo posible use palabras simples y conocidas de tal forma que se entiendan por un grupo no especializado. Identificar el tipo de usuario que necesita cada requerimiento El docente debe ser capaz de.. Enfocarse en declarar cual es el resultado que el sistema dará a un tipo especial de usuarios:...ver el plan de trabajo en una hoja de cálculo... Definir criterios identificables Definición de los Requisitos Esta guía explica como desarrollar y usar las especificación de requisitos del sistema. Existe un conjunto finito de requisitos que se deben tener en cuenta cuando se considera todo el ámbito del sistema, la características de calidad o las restricciones. Muchos de ellos no son familiares para los interesados y por tanto ellos encontraran dificultades a la hora de responder preguntas relacionadas con la disponibilidad desempeño, escalabilidad o localización. Se puede utilizar esta guía al momento de hablar con los interesados. a. Características de Uso e interacción con el usuario Los requisitos que determinan las características de uso e interacción son críticas para el éxito de cualquier sistema. No ayuda mucho si se tienen requisitos como: El sistema debe ser fácil de usar. Ya que este no puede ser verificado. Mientras se capturan los requerimientos funcionales es una buena idea identificar primero los problemas y las inquietudes para poder refinarlas luego convirtiéndolas en requisitos verificables. De acuerdo con la definición tradicional las características de uso e interacción tienen cinco factores: Facilidad de Aprendizaje: Un usuario con un nivel específico de experiencia debe ser capaz de aprender como se utiliza el sistema en una cantidad determinada de tiempo. Eficiencia en las tareas: Un usuario debe ser capaz de completar una tarea específica en un tiempo determinado (o en un número determinado de pulsaciones del ratón). Facilidad de recordar: Un usuario debe ser capaz de recordar como se utiliza el sistema aun cuando haya dejado de utilizarlo por un determinado periodo de tiempo. Facilidad de ser comprendido: Un usuario debe ser capaz de entender los mensajes y las alertas que el sistema genera.

14 Satisfacción subjetiva: Un porcentaje considerable de la comunidad de usuarios debe expresar satisfacción al utilizar el sistema. Se pueden utilizar los siguientes métodos para identificar y especificar los requisitos de uso e interacción con el usuario: 1. Identificar los problemas claves relacionados con las características de uso y de interacción con el usuario. Es ideal revisar las tareas críticas, perfiles de usuario, metas del sistema y problemas anteriores que se hayan presentado. 2. Seleccionar el estilo apropiado para expresar los requisitos: b. Confiabilidad Estilo basado en el desempeño: Especificar que tan rápido los usuarios pueden aprender varias tareas y que tan rápido ellos deben ejecutar tales tareas después de ser entrenados. Estilo centrado en los defectos: Más que medir el tiempo empleado en ejecutar una tarea se deben identificar los defectos encontrados con la características de uso e interacción con el usuario, especificando con que frecuencia ocurren. Estilo centrado en guías de diseño: Especificar la apariencia general y los tiempos de respuesta de la interfaz de usuario haciendo referencia a un estándar bien definido. La confiabilidad incluye la habilidad que el sistema tiene para continuar funcionando ante situaciones de tensión o condiciones adversas. En el caso de las aplicaciones la confiabilidad se relaciona con la cantidad de tiempo que el sistema permanece funcionando. Especificar la confiabilidad a niveles aceptables así como los mecanismos para que esta pueda ser medida y evaluada. Describir los criterios de confiabilidad en términos cuantificables, usualmente como el tiempo permitido entre fallos o la tasa de fallo total permitida. Otras consideraciones de confiabilidad incluye: Exactitud: Especificar los requisitos para la precisión (resolución) y la exactitud (de acuerdo a un estándar conocido) que se necesita en cualquiera de los cálculos desarrollados o en la salida del sistema. Disponibilidad: Especificar los requisitos para el porcentaje de tiempo que el sistema esta disponible para uso, las horas de uso y las horas de mantenimiento. La disponibilidad es típicamente especificada en términos del tiempo medio entre fallos. (TMEF). Recuperación: Especificar los requisitos para que el sistema se recupere de un fallo. Esto es expresado típicamente en términos del tiempo medio de recuperación (TMDR). Frecuencia y severidad de los fallos: Especificar la tasa máxima de defectos (expresadas en defectos/ksloc o defectos/puntos de función) y la severidad de los fallos. La severidad puede ser catalogada como menor, significativa y crítica. Los requerimientos deben definir

15 cada uno de estos términos sin ambigüedad, Por ejemplo, un defecto crítico puede ser definido como aquel que resulta en una pérdida de datos o como uno que genere una pérdida de la funcionalidad en una parte del sistema. c. Desempeño Tiempo de respuesta: Especificar la cantidad de tiempo disponible para que el sistema complete tareas específicas o transacciones (promedio, máximo). Utilizar unidades de medida. Ejemplo: Cualquier interfaz entre el usuario y el sistema debe tener un tiempo máximo de respuesta de 2 segundos. Rendimiento: Especificar la capacidad del sistema para soportar un determinado flujo de información (Por Ejemplo, transacciones por segundo). Capacidad: Especificar la cantidad de datos que el sistema almacena y el volumen de datos que el sistema maneja. Asegurar que la descripción de requerimientos esta cuantificada de tal forma que pueda ser probada. Usar unidades de medida tales como: número de usuarios o transacciones que el sistema puede administrar, el uso de recursos (memoria, discos, conexiones de red, buffers, etc) Ejemplos: El sistema debe atender hasta estudiantes dentro del periodo de tiempo comprendido entre las 9:00 AM a las 11 AM. La carga máxima en otros periodos será de Inicio del sistema: Tiempo máximo para que el sistema entre en producción después de ser encendido. Apagado del Sistema: Tiempo máximo que el sistema tarda en apagarse. d. Capacidad del sistema para ser mantenido Capacidad de adaptación: Existen requerimientos especiales que contemplen la adaptación del software (incluyendo actualizaciones)?. Listar los requerimientos que faciliten que el sistema se adapte a nuevos ambientes. Compatibilidad: Existen requerimientos que contemplen la compatibilidad del sistema con otras versiones o con sistemas subsidiarios que proveen la misma capacidad? Configuración: El producto debe ser configurado después de haberse instalado? En que forma debe ser configurado el sistema? Instalación: Declarar cualquier requerimiento especial que se relaciones con la instalación del sistema.

16 Nivel de soporte: Que nivel de soporte se requiere para el producto? Usualmente se utilizan una mesa de ayuda (Help desk). Si existe personas que provean soporte al producto es ese soporte parte de lo que se debe proveer a los clientes? existen requerimientos para dicho soporte?. Si se debe incluir soporte dentro del mismo sistema en esta sección deberían colocarse tales requerimientos. Considere el nivel de soporte que el sistema, de forma anticipada, provee y la forma en que será prestado. Mantenimiento: Existen requerimientos especiales que contemplen el mantenimiento del sistema? Cuales son los requerimientos para el ciclo de liberaciones del sistema? En que forma se realizaran tales liberaciones?. Cuantificar el tiempo necesario para realizar cambios específicos en el producto. Existen otros requerimientos especiales para el mantenimiento tales como requerimientos para que los usuarios finales o interesados puedan realizar las tareas de mantenimiento. Esto tiene efecto en la forma en que el sistema debe ser desarrollado. Además, deben existir requerimientos adicionales para la documentación y el entrenamiento o capacitación. Describir el tipo de mantenimiento y la cantidad de esfuerzo requerido. Ejemplos: Las mejoras de mantenimiento deben ser ofrecidas una vez cada año. Capacidad de crecimiento: Que volumen de datos y usuarios debe soportar el sistema? Estos requerimientos especifican el incremento esperado en tamaño que el sistema deberá soportar a medida que el negocio crece ( o lo que se espera que crezca), los sistemas software deben aumentar su capacidad para copar dichos volúmenes. Esto usualmente se expresa como un perfil de tiempo. Capacidad de ser probado: Existen requerimientos especiales que contemplen las pruebas del sistema?. Usualmente los planes de auditoria pueden ser una fuente efectiva para rescatar estos requerimientos a un alto nivel. e. Restricciones (+) Restricciones de diseño: Existen decisiones de diseño que deban ser aceptadas por el producto? Estas incluyen políticas de imagen institucional, colores institucionales, etc. Componentes de terceros: Especificar cualquier componente de software tanto de software libre como COTS o elementos legales que deban ser usados por el sistema. Lenguajes de implementación: Especificar los requerimientos para los lenguajes de programación que deben ser utilizados. Plataforma de soporte: Especificar los requerimientos para la plataforma de soporte para el sistema.

17 Límite de recursos: Especificar los requerimientos que limitan el uso de recursos del sistema, tales como el espacio en disco duro y la memoria. Restricciones físicas: Especificar los requisitos de forma, tamaño y peso del hardware resultante que debe contener el sistema. f. Requisitos de Interfaz(+) Describe tanto la interfaz de usuario como las interfaces con sistemas externos. Describe los requisitos relacionadas con la interfaz de usuario que debe ser implementada por el software. La intención de esta sección es describir los requerimientos pero no describir la interfaz como tal porque el diseño podría solaparse con el proceso de captura de requerimientos. Esto es particularmente cierto cuando se esta utilizando la técnica de prototipos como parte del proceso de captura de requerimientos. A medida que se desarrollan prototipos es importante capturar los requerimientos que se relacionan con la forma en que luce y se ve la interfaz de usuario. En otras palabras, debe asegurarse en todo momento que se entienden las intenciones de la institución en cuando a la interfaz de usuario. Se recomienda registrar dichos requerimientos y no solo utilizar un prototipo para su aprobación. Estilo y sensación: Una descripción de la apariencia estética y el diseño de la interfaz. La institución puede tener ciertas restricciones en cuanto al estilo, los colores, el grado de interacción y otras cosas. La idea es capturar las expectativas, restricciones y las demandas de los clientes antes de diseñar la interfaz. Ejemplos: El producto debe tener el mismo diseño que la página principal de la institución. El producto debe utilizar los colores de la institución. Requerimientos de disposición en pantalla y navegación: Especifica los requerimientos de las áreas de la pantalla y como ellas deben ser agrupadas. Consistencia: La consistencia en la interfaz de usuario permite que se pueda predecir que sucederá al interaccionar con el sistema. En esta sección se debe declarar los requerimientos en cuanto al uso de mecanismos que se emplearán el la interfaz de usuario. Esto aplica tanto para el sistema como para otros sistemas relacionados y puede ser aplicado a diferentes niveles: controles de navegación, tamaños y forma de las áreas de la pantalla, lugares para colocar o ingresar datos, terminología, etc. Personalización de usuario y requerimientos de personalización: requerimientos sobre el contenido que debería se presentado automáticamente al usuario o ser disponible sobre la base de los atributos del usuario. Algunas veces se permite al usuario personalizar el contenido mostrado.

18 g.interfaz a sistemas o dispositivos externos Interfaz de software: Existen sistemas externos con los cuales tenga que interaccionar el software? Existen restricciones debido a la naturaleza de la interfaz, tales como el formato de datos que se transfiere? Dichas interfaces usan un protocolo específico? Describir la interfaz o interfaces, que el sistema tenga con otros sistemas. Dichas interfaces pueden incluir componentes comprados, componentes reusados desde otra aplicación, componentes que deben ser desarrollados por subsistemas que se encuentran fuera del ámbito del proyecto pero con los cuales se tiene que interaccionar. Para cada sistema se deben considerar tanto las interfaces requeridas como las provistas. Interfaz de hardware: Defina cualquier interfaz de hardware que deba ser soportada por el software incluyendo la estructura lógica, la dirección física, el comportamiento esperado, etc. Interfaz de comunicación: Describa cualquier interfaz de comunicación que se tenga con otros sistemas o dispositivos tales como redes de área local (LAN), dispositivos seriales remotos, etc. h. Reglas de Negocio (+) Más allá de los requerimientos técnicos también se debe considerar el dominio de negocios particular en el cual encaja el sistema. Las reglas del negocio o políticas que el sistema debe cumplir. Las reglas del negocio son referenciadas desde los casos de uso del sistema y pueden ser definidas en forma de tablas de decisión, reglas computacionales, árboles de decisión y algoritmos entre otros. Al describir las reglas dentro de los flujos de los casos de uso usualmente los vuelve confusos. Por esta razón es que dichas reglas son capturadas en artefactos separados o como anexos relacionados con las especificaciones de los casos de uso. En muchos casos una regla del negocio aplica a más de un caso de uso. Se recomienda recopilar las reglas en un repositorio único tal como el documento de requerimientos de soporte Técnicas de Captura de Requerimientos y/o Requisitos Esta guía describe varias técnicas que pueden ser útiles en la captura de los requerimientos y requisitos. Unos buenos requerimientos y requisitos inician cuando se detectan correctamente las fuentes. Encontrar fuentes de alta calidad es una tarea importante que, afortunadamente, requiere pocos recursos.

19 La fuente primaria de requerimientos son los interesados, luego es necesario identificar otros candidatos: Clientes Usuarios Administradores Equipo de Mantenimiento Asociados Preguntar a cada interesado para que ellos mismos propongan a otros interesados. De esta manera se podrán identificar rápidamente a todos los interesados de tal forma que no se pierdan perspectivas o requerimientos importantes. Esto puede servir para identificar y resolver los conflictos de requerimientos de forma temprana. Existen otras posibles fuentes de ideas para los requerimientos : Expertos en el dominio de interés. Como jefes de dependencias, empleados antiguos, pensionados. Analistas en el tema de la educación y la administración educativa. Información acerca de Instituciones de Educación Superior o en general del área de interés. Este último ítem también incluye la información asociada a los sistemas de información que utilizan otras instituciones para solucionar los mismos problemas. Después de que se identifiquen las fuentes de requerimientos se pueden aplicar diferentes técnicas que sirven para capturarlos. Sin embargo, hay que tener en cuenta que la captura de requerimientos es un proceso iterativo y que no existe una técnica única que sea universalmente aplicable. Algunos de los métodos de captura de requerimientos son: Sesiones de tormentas de ideas. Entrevistas Trabajar en el ambiente objetivo Estudio de sistemas análogos Análisis de sugerencias y reportes de problemas y fallos. Charlas con los equipos de soporte Estudiar las mejoras realizadas por los usuarios Búsqueda de usuarios no considerados

20 Conducir sesiones de trabajo en grupo y talleres. Mostrar los prototipos a los interesados a. Conducir Sesiones de Tormenta de Ideas Una tormenta de ideas es un sesión de trabajo en la que un pequeño grupo de personas proponen ideas acerca de lo que consideren importante en el área o tópico de interés. Inicialmente Las ideas se recogen pero no se discuten. Después de esto un facilitador guía al grupo para que los resultados de la sesión sean organizados y priorizados. Las siguientes reglas básicas pueden asegurar unos mejores resultados: Comenzar declarando claramente el objetivo de la sesión de tormenta de ideas. Generar el mayor número de ideas posible. Permitir que la imaginación vuele. Evitar y disuadir cualquier forma de crítica o de debate mientras se están capturando las ideas. Después de que se hayan capturado las ideas reformularlas y combinarlas. b. Entrevistas a Usuarios El contacto cara a cara con los usuarios a través de las entrevistas se puede considerar como la fuente primaria de requerimientos y una de las vías más adecuadas para validarlos. Sin embargo se debe recordar que esta nos es la única técnica y que las entrevistas también pueden tomar muchas formas. Se recomienda desarrollar un repertorio de entrevistas para ser utilizado en situaciones específicas. A menos que el grupo de desarrollo sea el único interesado en el producto es necesario hacer un esfuerzo para entender de forma clara y correcta el problema que se desea resolver. Empezar con entrevistas no estructuradas para ganar un entendimiento del marco de trabajo. Preguntar a los interesados acerca de sus trabajos y de los problemas que enfrentan y pueden ser solucionados con el sistema. Luego de ello se pueden estructurar entrevistas con base a un conjunto de preguntas prediseñadas que tengan como objetivo complementar el conocimiento adquirido. c.trabajar en el ambiente objetivo A veces es necesario tener la experiencia de los usuarios de forma directa. Esto ayuda a entender el problema de primera mano y comprender el por qué las soluciones previas han fallado. Ha de tenerse en cuenta que el integrante del grupo de desarrollo debe tratar por todos los medios de ponerse en el lugar del usuario y así entender que es lo que podría hacer el sistema para disminuirle las cargas de trabajo. En todo caso, es necesario evitar soluciones que incluyan herramientas para programadores

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

DE VIDA PARA EL DESARROLLO DE SISTEMAS

DE VIDA PARA EL DESARROLLO DE SISTEMAS MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS 1. METODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS. El desarrollo de Sistemas, un proceso

Más detalles

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000 1 INTRODUCCIÓN Dos de los objetivos más importantes en la revisión de la serie de normas ISO 9000 han sido: desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas

Más detalles

Análisis y gestión de riesgo

Análisis y gestión de riesgo Marco Dueñes Intriago María Cabrales Jaquez Resumen capitulo 6 Ingeniería del software Análisis y gestión de riesgo Estrategias de riesgo proactivas vs reactivas Una estrategia considerablemente más inteligente

Más detalles

Hoja Informativa ISO 9001 Comprendiendo los cambios

Hoja Informativa ISO 9001 Comprendiendo los cambios Revisiones ISO Hoja Informativa ISO 9001 Comprendiendo los cambios Cambios que se aproximan ISO 9001 de un vistazo Cómo funciona ISO 9001? ISO 9001 puede ser aplicado a todo tipo de organizaciones de cualquier

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

Más detalles

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos. Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a 5. METODOLOGIAS COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio

Más detalles

Sistema para Gestión Hotelera Visión

Sistema para Gestión Hotelera Visión Sistema para Gestión Hotelera Visión Tabla de Contenidos 1. Introducción 4 1.1 Propósito 4 1.2 Alcance 4 1.3 Definiciones, Acrónimos, y Abreviaciones 4 1.4 Referencias 4 2. Posicionamiento 4 2.1 Oportunidad

Más detalles

AI 2 ADQUISICIÓN Y MANTENIMIENTO DE SOFTWARE DE APLICACIÓN AFINES OBJETIVOS OBJETIVOS DE CONTROL

AI 2 ADQUISICIÓN Y MANTENIMIENTO DE SOFTWARE DE APLICACIÓN AFINES OBJETIVOS OBJETIVOS DE CONTROL AI 2 ADQUISICIÓN Y MANTENIMIENTO DE SOFTWARE DE APLICACIÓN OBJETIVOS 1 Métodos de Diseño 2 Cambios Significativos a Sistemas Actuales 3 Aprobación del Diseño 4 Definición y Documentación de Requerimientos

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

2.1 Identifique y determine las prioridades de los temas de salud pública de la comunidad

2.1 Identifique y determine las prioridades de los temas de salud pública de la comunidad PASO 2: DETERMINE SU ENFOQUE Ahora que usted sabe quienes participarán en este proceso, su primer paso juntos, es determinar qué quieren alcanzar, en forma colectiva, con la evaluación. Articular esto

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

-OPS/CEPIS/01.61(AIRE) Original: español Página 11 5. Estructura del programa de evaluación con personal externo

-OPS/CEPIS/01.61(AIRE) Original: español Página 11 5. Estructura del programa de evaluación con personal externo Página 11 5. Estructura del programa de evaluación con personal externo 5.1 Introducción Esta sección presenta la estructura del programa de evaluación con personal externo. Describe las funciones y responsabilidades

Más detalles

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008)

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008) Unidades temáticas de Ingeniería del Software Fases del proceso de desarrollo 4ª edición (2008) Facultad de Informática organización del desarrollo El ciclo de vida del software abarca el proceso de desarrollo,

Más detalles

Procedimiento de Sistemas de Información

Procedimiento de Sistemas de Información Procedimiento de Sistemas de Información DIRECCIÓN DE COORDINACIÓN TÉCNICA Y PLANEACIÓN VIEMBRE DE 2009 PR-DCTYP-08 Índice. 1. INTRODUCCIÓN.... 3 2. OBJETIVO.... 4 3. ALCANCE.... 4 4. MARCO LEGAL.... 4

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION

Más detalles

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) Introducción 1. Como se indica en la Norma Internacional de Auditoría 401, "Auditoría en un contexto informatizado", los objetivos globales

Más detalles

CONCEPTOS GENERALES SOBRE SEGURIDAD INFORMATICA

CONCEPTOS GENERALES SOBRE SEGURIDAD INFORMATICA CONCEPTOS GENERALES SOBRE SEGURIDAD INFORMATICA Hoy en día las redes de comunicaciones son cada vez mas importantes para las organizaciones ya que depende de estás, para que exista un manejo adecuado de

Más detalles

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN (BPMN) es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes

Más detalles

Unidad VI: Supervisión y Revisión del proyecto

Unidad VI: Supervisión y Revisión del proyecto Unidad VI: Supervisión y Revisión del proyecto 61. Administración de recursos La administración de recursos es el intento por determinar cuánto, dinero, esfuerzo, recursos y tiempo que tomará construir

Más detalles

ESPECIFICACIONES TÉCNICAS DEL PROCESO DE ATENCIÓN AL CIUDADANO

ESPECIFICACIONES TÉCNICAS DEL PROCESO DE ATENCIÓN AL CIUDADANO ESPECIFICACIONES TÉCNICAS DEL PROCESO DE ATENCIÓN AL CIUDADANO OBJETO. El presente Documento de Especificaciones Técnicas tiene por objeto establecer los requisitos que debe cumplir el proceso de Atención

Más detalles

I INTRODUCCIÓN. 1.1 Objetivos

I INTRODUCCIÓN. 1.1 Objetivos I INTRODUCCIÓN 1.1 Objetivos En el mundo de la informática, la auditoría no siempre es aplicada en todos las empresas, en algunos de los casos son aplicadas por ser impuestas por alguna entidad reguladora,

Más detalles

Gestión de Configuración del Software

Gestión de Configuración del Software Gestión de Configuración del Software Facultad de Informática, ciencias de la Comunicación y Técnicas Especiales Herramientas y Procesos de Software Gestión de Configuración de SW Cuando se construye software

Más detalles

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi Gestión de Permisos Bizagi Suite Gestión de Permisos 1 Tabla de Contenido Gestión de Permisos... 3 Definiciones... 3 Rol... 3 Perfil... 3 Permiso... 3 Módulo... 3 Privilegio... 3 Elementos del Proceso...

Más detalles

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas. El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los

Más detalles

Soporte Técnico de Software HP

Soporte Técnico de Software HP Soporte Técnico de Software HP Servicios Tecnológicos HP Servicios contractuales Datos técnicos El Soporte Técnico de Software HP ofrece servicios integrales de soporte remoto de para los productos de

Más detalles

Ejemplo Manual de la Calidad

Ejemplo Manual de la Calidad Ejemplo Manual de la Calidad www.casproyectos.com ELABORADO POR: REPRESENTANTE DE LA DIRECCION APROBADO POR: GERENTE GENERAL 1. INTRODUCCIÓN Nuestra organización, nació en el año XXXXXXXXX, dedicada a

Más detalles

Técnico y sus funciones. 5. Función de los líderes. 6 Función del analista de datos. 6. Metas del Help Desk. 7 Definir el alcance del Help Desk.

Técnico y sus funciones. 5. Función de los líderes. 6 Función del analista de datos. 6. Metas del Help Desk. 7 Definir el alcance del Help Desk. 3 Qué es un Help Desk? 3 Cómo trabaja un Help Desk? 3 Cómo se mide el éxito de un Help Desk? 5 Funciones de los miembros del equipo del Help Desk. 5 Técnico y sus funciones. 5 Función de los líderes. 6

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Gestión de la Configuración

Gestión de la Configuración Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de

Más detalles

Marco Normativo de IT

Marco Normativo de IT Marco Normativo de IT PC0901 - Proceso de control de cambios en software de aplicación provisto por Organismos Gobierno de la Ciudad Autónoma de Buenos Aires PC0901 - Proceso de control de cambios en software

Más detalles

CONSTRUCCIÓN DEL PROCESO TRANSACCIONAL Bizagi Process Modeler

CONSTRUCCIÓN DEL PROCESO TRANSACCIONAL Bizagi Process Modeler Bizagi Process Modeler Copyright 2011 - bizagi Contenido 1. INTRODUCCIÓN A LAS TRANSACCIONES... 3 2. DIAGRAMA DEL PROCESO... 4 SUB PROCESO RESERVA... 5 SUB PROCESO REPORTE DE GASTOS... 8 3. MODELO DE DATOS...

Más detalles

El modelo de ciclo de vida cascada, captura algunos principios básicos:

El modelo de ciclo de vida cascada, captura algunos principios básicos: Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",

Más detalles

UNIVERSIDAD AUTÓNOMA DEL CARIBE PROCEDIMIENTO DE ATENCIÓN DE INCIDENTES Y REQUERIMIENTOS PARA EQUIPOS DE CÓMUPUTO Y/O PERIFÉRICOS GESTIÓN INFORMÁTICA

UNIVERSIDAD AUTÓNOMA DEL CARIBE PROCEDIMIENTO DE ATENCIÓN DE INCIDENTES Y REQUERIMIENTOS PARA EQUIPOS DE CÓMUPUTO Y/O PERIFÉRICOS GESTIÓN INFORMÁTICA Página: 1/5 UNIVERSIDAD AUTÓNOMA DEL CARIBE INCIDENTES Y REQUERIMIENTOS PARA EQUIPOS DE CÓMUPUTO Y/O GESTIÓN INFORMÁTICA Página: 2/5 1. OBJETO Satisfacer los requerimientos que hagan los usuarios para

Más detalles

DISEÑO DE FUNCIONES (TRATAMIENTOS)

DISEÑO DE FUNCIONES (TRATAMIENTOS) DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se

Más detalles

GUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES

GUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES GUÍA TÉCNICA PARA LA DEFINICIÓN DE COMPROMISOS DE CALIDAD Y SUS INDICADORES Tema: Cartas de Servicios Primera versión: 2008 Datos de contacto: Evaluación y Calidad. Gobierno de Navarra. evaluacionycalidad@navarra.es

Más detalles

DESCRIPCIÓN DEL PROCESO DE RIESGO OPERACIONAL

DESCRIPCIÓN DEL PROCESO DE RIESGO OPERACIONAL DESCRIPCIÓN DEL PROCESO DE RIESGO Julio 10, de 2012 INDICE Proceso Riesgo Operacional... 1 Objetivo General... 1 Objetivos Específicos... 1 I. Identificación del Riesgo.... 1 II. Medición y Mitigación

Más detalles

DECLARACIÓN DE PRIVACIDAD DE FONOWEB

DECLARACIÓN DE PRIVACIDAD DE FONOWEB DECLARACIÓN DE PRIVACIDAD DE FONOWEB Fonoweb se compromete a respetar su privacidad y la confidencialidad de su información personal, los datos de las comunicaciones y el contenido de las comunicaciones

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD

COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD COMISION DE REGLAMENTOS TECNICOS - CRT COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD SUB COMITÉ SECTOR EDUCACION NORMAS APROBADAS NTP 833.920-2003 Guía de aplicación de la Norma

Más detalles

FACULTAD DE CONTADURIA Y CIENCIAS ADMINISTRATIVAS FINANZAS I NORMAS DE INFORMACION FINANCIERA

FACULTAD DE CONTADURIA Y CIENCIAS ADMINISTRATIVAS FINANZAS I NORMAS DE INFORMACION FINANCIERA Normas de Información Financiera Durante más de 30 años, la Comisión de Principios de Contabilidad (CPC) del Instituto Mexicano de Contadores Públicos A. C. (IMCP) fue la encargada de emitir la normatividad

Más detalles

<Generador de exámenes> Visión preliminar

<Generador de exámenes> Visión preliminar 1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,

Más detalles

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... Tabla de Contenido PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... 2 1. LA PRESENCIA DE INFORMACIÓN Y AYUDA ÚTIL PARA COMPLETAR LOS TRÁMITES EN LÍNEA.... 2 2. LA DISPONIBILIDAD DE DIVERSOS

Más detalles

Implementando un ERP La Gestión del Cambio

Implementando un ERP La Gestión del Cambio Artículos> Implementando un ERP - La Gestión del Cambio Artículo Implementando un ERP La Gestión del Cambio 1 Contenido Sumario Ejecutivo 3 Los sistemas ERP flexibilizan la gestión de la empresa y su cadena

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

RESULTADOS CONSULTA CIUDADANA VIRTUAL. Consulta Laboral en Línea

RESULTADOS CONSULTA CIUDADANA VIRTUAL. Consulta Laboral en Línea RESULTADOS CONSULTA CIUDADANA VIRTUAL Consulta Laboral en Línea Septiembre, 2015 1 Agradecimientos Ponemos a disposición de ustedes los resultados de la Consulta Ciudadana Virtual, efectuada en julio de

Más detalles

I. Información General del Procedimiento

I. Información General del Procedimiento PR-DGSE-5 Octubre 211 I. Información General del Objetivo: Describir los pasos a seguir para la realización de las al Sistema de Gestión de Calidad de la, del MINERD. Alcance: Este procedimiento aplica

Más detalles

Introducción a la Firma Electrónica en MIDAS

Introducción a la Firma Electrónica en MIDAS Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento

Más detalles

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS Objetivo Este subproceso establece las actividades que se realizan para la planeación y control de respaldos y desastres relacionados con los recursos informáticos existentes en el Senado de La República

Más detalles

UNIVERSIDAD TECNICA DE MANABI Facultad de Ciencias Informáticas Ingeniería en sistemas. SEGURIDAD INFORMATICA Tema:

UNIVERSIDAD TECNICA DE MANABI Facultad de Ciencias Informáticas Ingeniería en sistemas. SEGURIDAD INFORMATICA Tema: UNIVERSIDAD TECNICA DE MANABI Facultad de Ciencias Informáticas Ingeniería en sistemas SEGURIDAD INFORMATICA Tema: CATEGORÍAS DE BENEFICIOS DE ESTANDARES Y PROCEDIMIENTOS Integrantes Doris María Mera Mero

Más detalles

USABILIDAD Y ACCESIBILIDAD EN WEB Guillermo M. Martínez de la Teja

USABILIDAD Y ACCESIBILIDAD EN WEB Guillermo M. Martínez de la Teja USABILIDAD Y ACCESIBILIDAD EN WEB Guillermo M. Martínez de la Teja "La usabilidad trata sobre el comportamiento humano; reconoce que el humano es emotivo, no está interesado en poner demasiado esfuerzo

Más detalles

Manual del Usuario. Sistema de Help Desk

Manual del Usuario. Sistema de Help Desk Manual del Usuario Sistema de Help Desk Objetivo del Manual El siguiente manual tiene como objetivo proveer la información necesaria para la correcta utilización del sistema Help Desk. Describe los procedimientos

Más detalles

RECOMENDACIONES DE INVESTIGACIÓN FUTURA.

RECOMENDACIONES DE INVESTIGACIÓN FUTURA. Capítulo 6 CONCLUSIONES Y RECOMENDACIONES DE INVESTIGACIÓN FUTURA. 212 METODOLOGÍA PARA LA DETECCIÓN DE REQUERIMIENTOS SUBJETIVOS EN EL DISEÑO DE PRODUCTO. CAPÍTULO 6. CONCLUSIONES, APORTACIONES Y RECOMENDACIONES.

Más detalles

Términos definiciones

Términos definiciones Términos y definiciones 3Claves para la ISO 9001-2015 Términos y definiciones: ISO9001 utiliza una serie de definiciones ligadas a la gestión de la calidad, que también deben ser comprendidas por la organización

Más detalles

0. Introducción. 0.1. Antecedentes

0. Introducción. 0.1. Antecedentes ISO 14001:2015 0. Introducción 0.1. Antecedentes Conseguir el equilibrio entre el medio ambiente, la sociedad y la economía está considerado como algo esencial para satisfacer las necesidades del presente

Más detalles

Traducción del. Our ref:

Traducción del. Our ref: Traducción del Documento: Our ref: Secretaría del ISO/TC 176/SC 2 Fecha: 15 de octubre de 2008 A los Miembros del ISO/TC 176/SC 2 - Gestión de la Calidad y Aseguramiento de la Calidad/ Sistemas de la Calidad

Más detalles

Guía de los cursos. Equipo docente:

Guía de los cursos. Equipo docente: Guía de los cursos Equipo docente: Dra. Bertha Patricia Legorreta Cortés Dr. Eduardo Habacúc López Acevedo Introducción Las organizaciones internacionales, las administraciones públicas y privadas así

Más detalles

Capítulo IV. Manejo de Problemas

Capítulo IV. Manejo de Problemas Manejo de Problemas Manejo de problemas Tabla de contenido 1.- En qué consiste el manejo de problemas?...57 1.1.- Ventajas...58 1.2.- Barreras...59 2.- Actividades...59 2.1.- Control de problemas...60

Más detalles

Caso práctico de Cuadro de Mando con Tablas Dinámicas

Caso práctico de Cuadro de Mando con Tablas Dinámicas 1 Caso práctico de Cuadro de Mando con Tablas Dinámicas Luis Muñiz Socio Director de SisConGes & Estrategia Introducción Hay una frase célebre que nos permite decir que: Lo que no se mide no se puede controlar

Más detalles

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN CONCEPTOS DE PRUEBAS DE APLICACIÓN El departamento de Testing se encarga de diseñar, planear y aplicar el rol de pruebas a los sistemas que el PROVEEDOR

Más detalles

Capítulo 2. Metodologías de selección de personal

Capítulo 2. Metodologías de selección de personal Capítulo 2. Metodologías de selección de personal 2.1 Introducción La selección de personal es una actividad en la cual toda empresa invierte parte de sus recursos, debido a que es una tarea de vital importancia.

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR

Más detalles

Usos de los Mapas Conceptuales en Educación

Usos de los Mapas Conceptuales en Educación Usos de los Mapas Conceptuales en Educación Carmen M. Collado & Alberto J. Cañas Introducción Los mapas conceptuales son una poderosa herramienta de enseñanza-aprendizaje. Su utilización en (y fuera de)

Más detalles

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:

Más detalles

CURSO COORDINADOR INNOVADOR

CURSO COORDINADOR INNOVADOR CURSO COORDINADOR INNOVADOR PRESENTACIÓN La tarea que el Ministerio de Educación se propone a través de Enlaces, en relación al aseguramiento del adecuado uso de los recursos, con el fin de lograr un impacto

Más detalles

Operación 8 Claves para la ISO 9001-2015

Operación 8 Claves para la ISO 9001-2015 Operación 8Claves para la ISO 9001-2015 BLOQUE 8: Operación A grandes rasgos, se puede decir que este bloque se corresponde con el capítulo 7 de la antigua norma ISO 9001:2008 de Realización del Producto,

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

comunidades de práctica

comunidades de práctica 1. Introducción CoSpace es una plataforma web diseñada para proporcionar un espacio virtual de interacción y colaboración entre formadores en comunidades virtuales. Se originó como resultado de las necesidades

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

MODULO: MERCADEO. Acuerdo de Nivel de Servicio (ANS) Service Level Agreement (SLA) MODELO DE MUESTRA SIN VALOR COMERCIAL

MODULO: MERCADEO. Acuerdo de Nivel de Servicio (ANS) Service Level Agreement (SLA) MODELO DE MUESTRA SIN VALOR COMERCIAL MODULO: MERCADEO Acuerdo de Nivel de Servicio (ANS) Service Level Agreement (SLA) 1 Servicio de Soporte. El presente apartado constituye las condiciones de soporte y mantenimiento por parte de enncloud

Más detalles

INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DE TRABAJO DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA

INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DE TRABAJO DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA con destino a GORE DE ATACAMA ELIMCO SISTEMAS Alfredo Barros Errázuriz 1954

Más detalles

PROCEDIMIENTO DE AUDITORIAS INTERNAS. CALIDAD INSTITUCIONAL Versión: 02

PROCEDIMIENTO DE AUDITORIAS INTERNAS. CALIDAD INSTITUCIONAL Versión: 02 1. OBJETIVO Realizar la planificación, estructuración y ejecución de las auditorías internas, con el objeto de garantizar el cumplimiento de los requisitos de la Norma ISO 9001:2008 y los fijados por la

Más detalles

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION. Los sistemas que el analista diseña día a día, la tecnología, las personas, que utilizan el

Más detalles

REGISTRO DE PEDIDOS DE CLIENTES MÓDULO DE TOMA DE PEDIDOS E INTEGRACIÓN CON ERP

REGISTRO DE PEDIDOS DE CLIENTES MÓDULO DE TOMA DE PEDIDOS E INTEGRACIÓN CON ERP REGISTRO DE PEDIDOS DE CLIENTES MÓDULO DE TOMA DE PEDIDOS E INTEGRACIÓN CON ERP Visual Sale posee módulos especializados para el método de ventas transaccional, donde el pedido de parte de un nuevo cliente

Más detalles

Visión del Sistema Proyecto: <Nombre del Proyecto>

Visión del Sistema Proyecto: <Nombre del Proyecto> Visión del Sistema Proyecto: Nota: El texto incluido en rectángulos azules y el exhibido en cursiva azul (Estilo=InfoBlue) se incluye con el fin de proporcionar una guía para

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

Más detalles

GUÍA 14 Diseño de Planes y Programas. Descripción

GUÍA 14 Diseño de Planes y Programas. Descripción GUÍA 14 Diseño de Planes y Programas Descripción El Diseño de Planes y Programas tiene como objetivo elaborar la proyección de la institución a corto, mediano y largo plazo, e impulsar y guiar las actividades

Más detalles

ACUERDO DE SERVICIO. Sistemas-Gestión de los Servicios Informáticos

ACUERDO DE SERVICIO. Sistemas-Gestión de los Servicios Informáticos Páginas 1 de 7 1. OBJETIVO Brindar el marco normativo que fije las condiciones en que deben prestarse los Servicios de Tecnologías de Información a los procesos de la organización, estableciendo criterios

Más detalles

Capítulo SIMULACIÓN Y SIMULACRO

Capítulo SIMULACIÓN Y SIMULACRO Capítulo SIMULACIÓN Y SIMULACRO Capítulo 4 SIMULACIÓN Y SIMULACRO En este capítulo, se enuncian conceptos y consideraciones para la organización de ejercicios prácticos que permitan poner a prueba parcial

Más detalles

ITIL FOUNDATION V3 2011

ITIL FOUNDATION V3 2011 ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la

Más detalles

Soporte y mantenimiento. Generalidades

Soporte y mantenimiento. Generalidades Soporte y mantenimiento Generalidades Tabla de Contenido 1. Introducción 2. Objetivos generales 3. Caso de soporte 4. Condiciones 5. Restricciones 6. Sistema de soporte Soporte y mantenimiento 1. Introducción

Más detalles

LA IMPLANTACIÓN DEL PROCEDIMIENTO DE GESTIÓN DE QUEJAS Y SUGERENCIAS

LA IMPLANTACIÓN DEL PROCEDIMIENTO DE GESTIÓN DE QUEJAS Y SUGERENCIAS Página 1 de 1 Manual Guía para la Implantación del Procedimiento de Gestión de Quejas y Sugerencias Página 2 de 2 ÍNDICE Introducción pag. 3 PARTE I - Objetivos del Procedimiento pag. 4 PARTE II - Fases

Más detalles

Capítulo III. Manejo de Incidentes

Capítulo III. Manejo de Incidentes Manejo de Incidentes Manejo de Incidentes Tabla de contenido 1.- En qué consiste el manejo de incidentes?...45 1.1.- Ventajas...47 1.2.- Barreras...47 2.- Requerimientos...48 3.- Clasificación de los incidentes...48

Más detalles

LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS

LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS Los clientes compran un servicio basandose en el valor que reciben en comparacion con el coste en el que incurren. Por, lo tanto, el objetivo a largo plazo

Más detalles

Metodología básica de gestión de proyectos. Octubre de 2003

Metodología básica de gestión de proyectos. Octubre de 2003 Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecución

Más detalles

SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO

SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO 1 Objetivo del Manual Elaborado por: Revisado por: Aprobado por: Fecha: 13/08/2015 Difusión: Información del Manual

Más detalles

2 EL DOCUMENTO DE ESPECIFICACIONES

2 EL DOCUMENTO DE ESPECIFICACIONES Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir

Más detalles