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

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

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

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS 750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB]

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Gobierno Municipal del Cantón Bolívar. SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Visión Universidad Técnica del Norte Histórico de Revisiones

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

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos 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

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

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

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables.

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Para obtener el grado de Maestro en Ciencias (Ciencias y Tecnologías de la Información) P R E S E N T A Lic.

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

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

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

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

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Aseguramiento de la calidad del software

Aseguramiento de la calidad del software Aseguramiento de la calidad del software Standard for Software Reviews and Audits [IEEE 1028] IEEE 1028 Para qué sirve Provee definiciones y requerimientos uniformes para los procesos de revisión y auditoría.

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

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

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

Criterios de clasificación

Criterios de clasificación Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre

Más detalles

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

ENTORNO DE UN CURSO. Antes de empezar sería conveniente conocer la estructura de Moodle y entender los siguientes conceptos básicos:

ENTORNO DE UN CURSO. Antes de empezar sería conveniente conocer la estructura de Moodle y entender los siguientes conceptos básicos: ENTORNO DE UN CURSO Antes de empezar sería conveniente conocer la estructura de Moodle y entender los siguientes conceptos básicos: Cursos Categorías Cuentas de usuario y roles Perfil de usuario En Moodle,

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su 88 CAPÍTULO 5 5. IMPLEMENTACIÓN 5.1 Modelo Utilizado en Programación. Hemos utilizado la técnica de programación orientado a objetos por su eficiencia y eficacia en el modelo mvc, ya que permite la reutilización

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

GESTIÓN DEL CAMBIO. Fernanda M. Soto 1, Henry F. Montalván 2 GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE INTRODUCCIÓN

GESTIÓN DEL CAMBIO. Fernanda M. Soto 1, Henry F. Montalván 2 GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE INTRODUCCIÓN GESTIÓN DEL CAMBIO Fernanda M. Soto 1, Henry F. Montalván 2 El arte de coordinar el desarrollo de software para minimizar la confusión se llama gestión de la configuración (GC-GCS). La Gestión de la Configuración

Más detalles

Desarrollo y comercialización de productos de software [El proceso unificado]

Desarrollo y comercialización de productos de software [El proceso unificado] Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 17/08/2005 1.0 Se hace la

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización

Más detalles

Ingeniería de Requisitos

Ingeniería de Requisitos Ingeniería de Requisitos Temario Definiciones Requisitos Funcionales y No Funcionales Tipos de Requisitos Ingeniería de Requisitos Proceso de los Requisitos Obtención de Requisitos - Técnicas Modelado

Más detalles

Especificación de Requisitos según el estándar de IEEE 830

Especificación de Requisitos según el estándar de IEEE 830 Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS)

Más detalles

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION UNIDAD V ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION Contenido: 5.1 Introducción 5.2 Principios del Análisis 5.3 Construcción de Prototipos del Software 5.4 Métodos de Análisis de Requisitos 5.5 La Especificación

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL

CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL Teniendo en cuenta que este trabajo tiene como objetivo el mostrar la metodología de evaluación del modelo de Capacidad de Madurez, es necesario antes de profundizar

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

Visión del Sistema 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

Microsoft. Febrero de 2006

Microsoft. Febrero de 2006 Microsoft Febrero de 2006 Tabla de contenido Información general de Microsoft Office InfoPath 2007...1 Incorpore eficacia a sus formularios comerciales...1 Amplíe el alcance de sus formularios comerciales...2

Más detalles

Requisitos de Software. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Requisitos de Software. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Requisitos de Software Departamento de Lenguajes y Sistemas Informáticos II Introducción Ingeniería de Requisitos Definición: La Ingeniería de requisitos comprende todas las tareas relacionadas con la

Más detalles

Planificación del Help Desk de su escuela

Planificación del Help Desk de su escuela Capítulo 1 Planificación del Help Desk de su escuela Después de terminar este capítulo usted será capaz de: Describir cuál es la función de un Help Desk; Describir qué es el soporte de nivel 1; Explicar

Más detalles

Identificación de requerimientos

Identificación de requerimientos Licenciatura en Informática Administración de requerimientos Identificación de requerimientos Licenciatura en Informática Sirva este material como apoyo a los apuntes de la asignatura Administración de

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba Pruebas Pruebas en el PUD Las pruebas del software Diseño de casos de prueba Tipos de prueba Estrategias de prueba 1 2 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos

Más detalles

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT)

CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT) CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO 6.1. Estructura Detallada del Trabajo (EDT) Un EDT es la agrupación orientada a entregables de los elementos del proyecto que organiza y define el total de los

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

La Implementación de SAP R/3

La Implementación de SAP R/3 SESIÓN 3 La implementación de SAP R/3 Etapas del Proyecto y Tareas a Realizar Entorno de la Implementación SAP Taller de Introducción a ERP SESIÓN 3/1 La Implementación de SAP R/3 El significado usual

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Lección 1 Redactando un resumen ejecutivo

Lección 1 Redactando un resumen ejecutivo Lección 1 Esta lección le enseña a convertir un documento de investigación o un caso de estudio en un Resumen Ejecutivo de dos páginas. Asimismo, le ayuda a redactarlo de manera que impacte eficazmente

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

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

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Por qué MobilityGuard OneGate?

Por qué MobilityGuard OneGate? Para Acceso de Cualquier Escenario Solo Una Solución Por qué MobilityGuard OneGate? Escenarios 1 Acceda desde cualquier lugar 2 Identifique sólidamente los usuarios 3 No más notas de recordatorio con ingreso

Más detalles

cero papel GUíA Nº 1 en la administración pública Buenas Prácticas para reducir el consumo de papel

cero papel GUíA Nº 1 en la administración pública Buenas Prácticas para reducir el consumo de papel GUíA Nº 1 cero papel en la administración pública Buenas Prácticas para reducir el consumo de papel Cómo reducir el consumo de papel mediante la formación de nuevos hábitos en los servidores públicos.

Más detalles

Soporte. Los programas anuales de soporte y mantenimiento Estándar y Extendido están diseñados para proteger

Soporte. Los programas anuales de soporte y mantenimiento Estándar y Extendido están diseñados para proteger Esta guía le proporcionará la información necesaria para conseguir el máximo valor de su inversión en programas técnicos de soporte ECM Solutions para las soluciones de gestión de contenidos y productos

Más detalles

UNIDAD 11 VALIDACION DE REQUISITOS

UNIDAD 11 VALIDACION DE REQUISITOS UNIDAD 11 VALIDACION DE REQUISITOS 11. VALIDACIÓN DE REQUISITOS... 1 11.1. REVISIÓN DE REQUISITOS... 3 11.2. PROTOTIPOS... 6 11.3. GENERACIÓN DE CASOS DE PRUEBA... 9 El proceso de validación de requisitos

Más detalles

La Inteligencia de Negocios es ya una realidad para las empresas medianas

La Inteligencia de Negocios es ya una realidad para las empresas medianas Reuniones/Entrevistas La Inteligencia de Negocios es ya una realidad para las empresas medianas La Inteligencia de Negocios es el siguiente paso que las empresas deben dar para mejorar su toma de decisiones

Más detalles

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3 Contenido INGENIERIA DE SOFTWARE Tema 6: Administración de la calidad del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Introducción 2.

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

INGENIERIA DE SOFTWARE. Dr. Pedro Mejia Alvarez. 2009. Obtención de Requerimientos

INGENIERIA DE SOFTWARE. Dr. Pedro Mejia Alvarez. 2009. Obtención de Requerimientos INGENIERIA DE SOFTWARE. Dr. Pedro Mejia Alvarez. 2009. Obtención de Requerimientos En esta actividad se determina el dominio de la aplicación, se especifican los servicios que debe proveer el sistema,

Más detalles

Grupo de procesos de Planificación

Grupo de procesos de Planificación Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Cuarta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje

Más detalles

Master en Gestion de la Calidad

Master en Gestion de la Calidad Master en Gestion de la Calidad Implantacion Sistema de Gestion de Calidad Implantacion de Sistemas de Gestion de Calidad 1 / 14 OBJETIVOS Al finalizar esta unidad didáctica será capaz: Conocer los pasos

Más detalles

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

GESTIÓN DE CLIENTES Y MERCADO

GESTIÓN DE CLIENTES Y MERCADO Por: José Antonio Villagra GESTIÓN DE CLIENTES Y MERCADO Qué se entiende por gestión de clientes y mercado? La gestión de clientes y mercado comprende un conjunto de conceptos y herramientas de gestión

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

BUENAS PRÁCTICAS PARA REDUCIR EL CONSUMO DE PAPEL

BUENAS PRÁCTICAS PARA REDUCIR EL CONSUMO DE PAPEL 1 BUENAS PRÁCTICAS PARA REDUCIR EL CONSUMO DE PAPEL Como reducir el consumo de papel mediante la formación de nuevos hábitos en los servidores públicos 7 COMO HACER REALIDAD LA OFICINA CERO PAPEL La implementación

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

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE AUDITORÍA INTERNA Versión 05 Diciembre 2008 INDICE Introducción...

Más detalles

Características del cliente en Outlook Web Access

Características del cliente en Outlook Web Access Exchange 2007 Características del cliente en Outlook Web Access En este tema se explican las nuevas y mejoradas características del cliente en Outlook Web Access en Microsoft Exchange Server 2007. Estas

Más detalles

Nota Técnica. Modelo de Diseño Instruccional de Hannafin & Peck: algunas apreciaciones técnico-funcionales en ambientes WEB 1

Nota Técnica. Modelo de Diseño Instruccional de Hannafin & Peck: algunas apreciaciones técnico-funcionales en ambientes WEB 1 Nota Técnica Modelo de Diseño Instruccional de Hannafin & Peck: algunas apreciaciones técnico-funcionales en ambientes WEB 1 YSRAEL ORLANDO MÁRQUEZ RAMÍREZ ysraelmarquez@gmail.com Universidad Nacional

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información 1 1. Definición y objetivos análisis.(del gr. ἀνάλυσις). 1. m. Distinción y separación de las partesdeun todo hasta llegar a conocer sus principios o elementos. 2. m.

Más detalles

Capítulo 1 Documentos HTML5

Capítulo 1 Documentos HTML5 Capítulo 1 Documentos HTML5 1.1 Componentes básicos HTML5 provee básicamente tres características: estructura, estilo y funcionalidad. Nunca fue declarado oficialmente pero, incluso cuando algunas APIs

Más detalles

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte AUDITORIA DE SISTEMAS Jorge Alberto Blanco Duarte QUE ES LA AUDITORIA DE SISTEMAS? La auditoria en informática es la revisión y la evaluación de los controles, sistemas, procedimientos de informática;

Más detalles

MANUAL DE REFERENCIA

MANUAL DE REFERENCIA GOBIERNO DE CHILE MINISTERIO DE HACIENDA Dirección de Presupuestos MANUAL DE REFERENCIA GUÍA PARA IMPLEMENTACIÓN ISO 9001:2000 SISTEMA DE CAPACITACIÓN Versión 05 Diciembre 2008 INDICE Introducción... 3

Más detalles