06/04/2015. Atributos de Calidad Medibles y No Medibles. Clases de Cualidades. Medibles. No Medibles. Escenarios de Atributo de Calidad

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

Download "06/04/2015. Atributos de Calidad Medibles y No Medibles. Clases de Cualidades. Medibles. No Medibles. Escenarios de Atributo de Calidad"

Transcripción

1 Medibles y No Medibles Medibles Pueden ser medidos mientras que el sistema ejecuta Devuelve la respuesta correcta? Es fácil de usar? Cuánto tarda en ejecutar un transacción? Un usuario no autorizado puede vulnerar la seguridad? Con qué frecuencia se cae o deja de funcionar? No Medibles No pueden ser medidos mientas el sistema ejecuta, sino antes o después Cuánto esfuerzo requiere su construcción? Cuánto esfuerzo requiere su testeo? Cuánto esfuerzo requiere su integración? Cuánto costó? Cuán fácil será de modificar? Clases de Cualidades Cualidades del Sistema Cualidades Relativas al Negocio Cualidades de la Arquitectura Aspectos relativos al funcionamiento del sistema. Pueden ser fehacientemente medibles o no. Aspectos del negocio que tienen impacto en decisiones arquitectura Cualidades de la arquitectura que suelen tener impacto en otros atributos de calidad. Disponibilidad Modificabilidad Performance Seguridad Time to market Vida útil del sistema Costo y beneficio Plan de evolución Etc. Testeabilidad Usabilidad Etc. Integridad conceptual Correctitud y completitud Buildability (factibilidad de construcción) Etc. Arquitectura y Diseño de Sistemas 12 Arquitectura y Diseño de Sistemas 13 Cualidades Relativas al Negocio Costo y Planificación Time To Market Costos y Beneficios Vida Útil Proyectada Integración con Sistemas Legados Marketing Mercado Apuntado Plan de Lanzamiento (incremental vs one-time) Organizacional Disponibilidad de equipo adecuada Experiencia en el dominio y tecnologías Cualidades de la Arquitectura Integridad Conceptual El sistema se construye a partir de un numero pequeño de estructuras arquitectónicas que interactúan en un numero pequeño de formas (predeterminadas) Se logra típicamente vía un solo arquitecto, o un grupo de arquitectos pequeño y coordinado Correctitud y Completitud Es esencial que tanto los requerimientos funcionales como las restricciones sean satisfechos por la arquitectura. Se utilizan evaluaciones formales para verificarlos (por ej, ATAM) Buildability Determina si el sistema puede ser construido con los recursos disponibles Equipo Conocimientos Herramientas / Componentes Arquitectura y Diseño de Sistemas 14 Arquitectura y Diseño de Sistemas 15 Cómo Definir Existen 3 problemas para definir atributos de calidad Las definiciones provistas por un atributo no son testeables Ejemplo: El sistema tiene que ser modificable No es claro a qué cualidad pertenece un aspecto particular del sistema Ejemplo: Una falla del sistema es un aspecto de disponibilidad, seguridad o usabilidad? Cada comunidad tiene su propio vocabulario Performance: Habla de eventos arribando en el sistema Seguridad: Habla de ataques arribando al sistema Disponibilidad: Habla de fallas de un sistema Usabilidad: Habla de inputs de usuario Escenarios de Atributo de Calidad Escenarios Generales vs Concretos Definición Mecanismo que permite caracterizar/capturar aspectos de atributos de calidad de una forma que puede ser evaluado y utilizado en diseño Generales Son independientes del sistema y, potencialmente pueden pertenecer a cualquier sistema. Concretos Aquellos que son específicos al sistema en consideración. Un requerimiento de atributo de calidad debería ser testeable y no ambiguo. Para lograrlo, se utilizan escenarios de atributo de calidad como una forma de caracterizarlos. Ejemplo Llega un requerimiento para hacer un cambio en la funcionalidad, y el cambio debe ser hecho en un momento particular dentro del proceso de desarrollo y dentro de un periodo de tiempo específico. Llega un requerimiento para agregar soporte a un nuevo browser para un sistema web y el cambio debe ser hecho en, como máximo, 2 semanas. Arquitectura y Diseño de Sistemas 16 Arquitectura y Diseño de Sistemas 17 1

2 Escenarios s de un Escenario de Atributo de Calidad. La condición a ser considerada cuando arriba al sistema. de. Es la entidad (humano, otro sistema, u otro actor) que generó el estímulo.. Las condiciones sobre las que ocurre el estímulo. El artefacto (componente, equipo, sistema entero) que es estimulado.. Define las acciones que el artefacto debería realizar como respuesta al estímulo. la. La medida de la respuesta por la cual el artefacto es evaluado. Las partes de un Escenario de Atributo de Calidad Tácticas Consideraciones Cada táctica es una opción de diseño. Puede haber otras Una táctica puede ser refinada en otras Cómo se imparte portabilidad a un diseño? Y performance? E interoperabilidad? Una táctica es una decision de diseño que influencia el control de la respuesta de un atributo de calidad Generalmente las tácticas para un atributo de calidad se organizan en una jerarquía. Táctica para Controlar la Arquitectura y Diseño de Sistemas 18 Arquitectura y Diseño de Sistemas 19 Ejemplo: Disponibilidad Áreas de Interés Es la probabilidad que tiene el Sistema de estar operativo cuando se lo necesita. Se preocupa de las fallas del Sistema y sus consecuencias asociadas: Una falla ocurre cuando el Sistema no provee un servicio consistente con sus especificaciones. Dicha falla es observable por los usuarios del Sistema. Disponibilidad Fallas vs Defectos Las fallas son observables por los usuarios del Sistema, mientras que un defecto no. Cuando un defecto es observable por usuarios, pasa a ser una falla. Si el Sistema puede corregir automáticamente los efectos de un defecto, entonces no se convierte en una falla Medición Disponibilidad 1 = tiempo medio de falla tiempo medio de falla + tiempo medio de reparación Cómo se detecta la falla? Cuán frecuentemente ocurre? Qué pasa cuando la falla ocurre? Cuánto tiempo el Sistema puede estar fuera de operación? Cuándo una falla puede ocurrir de manera segura? Cómo se puede evitar una falla? Qué tipo de notificaciones son necesarias cuando ocurre una falla? Cuánto tiempo toma su reparación? 1 Los downtimes (fuera de servicio) planificados no son considerados en el cálculo. Arquitectura y Diseño de Sistemas 20 Arquitectura y Diseño de Sistemas 21 Disponibilidad Disponibilidad Requerimientos de Disponibilidad de Ejemplo la Interna al Sistema; externa al sistema Defecto: omisión, crash, timing incorrecto, respuesta incorrecta Procesadores del sistema, canales de comunicación, almacenamiento persistente, procesos Operación Normal, Inicio del Sistema, Modo de Reparación Operación Degradada (por ej, funcionalidad limitada) El Sistema detectaría un evento y haría una o varias de las siguientes acciones: Registrarlo Notificar a quienes corresponda, incluyendo el usuario y otros sistemas Deshabilitar las fuentes de eventos que causan el defecto o falla de acuerdo a las reglas definidas Quedar no disponible por un intervalo de tiempo, hasta que se repare Continuar la operación en Modo Degradado mientras se repara. Intervalo de tiempo en el que el Sistema debe estar disponible Porcentaje de disponibilidad Tiempo para detectar la falla Tiempo para reparar la falla Tiempo que el Sistema puede funcionar en modo Degradado Arquitectura y Diseño de Sistemas 22 Arquitectura y Diseño de Sistemas 23 2

3 Disponibilidad Disponibilidad El heartbeat monitor determina que el servidor no responde ante operaciones normales. El sistema le informa al operador y continua operando sin tiempo de caídas. Heartbeat Monitor : Servidor no responde Proceso Informar al operador Continuar la Operación Normal operación Sin caídas Arquitectura y Diseño de Sistemas 24 Arquitectura y Diseño de Sistemas 25 Ejemplo: Modificabilidad Áreas de Interés Qué puede cambiar (el artefacto)? Es el costo (y riesgo) que tiene realizar un cambio en el Sistema. Cuándo se hace el cambio? Desarrollador Quién lo hace? Administrador de Sistema Usuario Final Cuál es la probabilidad de cambio Funcionalidad Plataforma (hw, so, middleware) (sistemas con los que debe interoperar) Cualidades del Sistema (performance) Capacidad (# usuarios, # tx) Codificación Compilación Build Configuración Ejecución Modificabilidad Cuál es el costo de hacer un sistema más modificable? El costo de introducir el/los mecanismo/s para hacer el sistema más modificable El costo de hacer la modificación usando el/los mecanismo/s Costo de Introducir el mecanismo Costo de hacer la modificación Sin mecanismo Cero El costo de cambiar el código fuente y testearlo Con mecanismo Costo de crear el mecanismo Costo de usar el mecanismo para hacer el cambio y testear el cambio Para N modificaciones similares, una justificación simplificada para la creación de un mecanismo de cambios podría ser: N x Costo de hacer el cambio sin el mecanismo => * N es la cantidad de modificaciones del mismo tipo que se preven (una predicción) Costo de crear el mecanismo + (N x Costo de hacer el cambio usando el mecanismo) Arquitectura y Diseño de Sistemas 26 Arquitectura y Diseño de Sistemas 27 Modificabilidad [Quién hace el cambio] Usuario final, desarrollador, administrador del sistema [Qué cambio debe hacerse] Deseo de agregar/modificar/eliminar funcionalidad, atributos de calidad, etc. [Qué tiene que cambiar] UI del sistema, plataforma, ambiente, sistemas con los que interactúa [Cuándo se hace el cambio] Ejecución, compilación, build, diseño Localizar los lugares a ser modificados Realizar las modificaciones sin afectar otras características del sistema Testear las modificaciones Instalar modificaciones la Costo del cambio en términos de: Elementos afectados Esfuerzo Dinero Grado en que afecta a otras características del sistema. Modificabilidad Un desarrollador desea cambiar la interfaz de usuario para que el color de fondo de la pantalla sea azul. El cambio se realizará sobre el código en tiempo de diseño, debiendo tomar no más de 3 horas en realizarlo y testearlo y sin tener efectos colaterales sobre el comportamiento del sistema. Desarrollador : Desea modificar la UI Código En tiempo de diseño La modificación es hecha sin efectos colaterales 3 horas Arquitectura y Diseño de Sistemas 28 Arquitectura y Diseño de Sistemas 29 3

4 Modificabilidad Se basan en 4 variables Tamaño del un módulo Siempre y cuando el criterio para dividir el módulo refleje el tipo de cambio que es probable de ocurrir Acoplamiento Reducir el acoplamiento entre dos módulos A y B disminuirá el costo esperado de cualquier modificación que afecte a uno de esos módulos. Cohesión Si un módulo tiene una baja cohesión, puede ser mejorada eliminando responsabilidad no afectadas por los cambios previstos. Así se reduce la posibilidad de efectos colaterales. Momento de implementación (binding time) En una arquitectura que propicia modificaciones tardías en el ciclo de vida, en promedio, un cambio costará menos que en una arquitectura que fuerza que la misma modificación sea hecha más temprano. Modificabilidad Arquitectura y Diseño de Sistemas 30 Arquitectura y Diseño de Sistemas 31 Ejemplo: Performance Consideraciones Origen de eventos Se ocupa básicamente de cuánto tiempo le toma al Sistema responder cuando ocurre un evento. Patrón de arribo del eventos Variable a evaluar De usuarios De otros sistemas Del mismo sistema Periódico Estocástico Esporádico Latencia Momento de procesamiento Throughput Varianza de la latencia Cantidad de eventos no procesados por exceso de carga Datos perdidos por exceso de carga Performance Una de un número independiente de fuentes posibles Eventos periódicos arriban Eventos estocásticos arriban Eventos esporádicos arriban El sistema, uno de sus componentes, un conjunto de componentes Modo normal Modo sobrecargado Modo emergencia Procesar el estímulo Cambiar el nivel de servicio la Latencia Deadline, Throughput Varianza de latencia Tasa de pérdida de requerimientos Tasa de pérdida de datos. Arquitectura y Diseño de Sistemas 32 Arquitectura y Diseño de Sistemas 33 Performance Bajo una operación normal del sistema, las transacciones ejecutadas por los usuarios deberían resolverse, en promedio, en 2 segundos. Usuarios Sistema : Instanciar Transacciones Transacciones procesadas Bajo operación normal Latencia promedio de 2 segundos Performance Background Tiempo de Procesamiento Los eventos son manejados por la ejecución de uno o más componentes, cuyo tiempo utilizado es un recurso. Contención de Recursos Muchos recursos pueden ser usados por un único cliente a la vez. Otros clientes deben esperar para acceder a ese recurso. Tiempo de Bloqueo Un cómputo puede estar bloqueado debido a contención sobre otro recurso, ya que el recurso no está disponible, o a que el cómputo depende del resultado de otro cómputo que aun no está disponible. Disponibilidad de Recursos Un cómputo podría estar detenido debido a la no disponibilidad de un recurso: porque el recursos está offline, o porque está atravesando una falla. Dependencia sobre otros cómputos Un cómputo puede tener que esperar porque debe sincronizarse con el resultado de otro cómputo Arquitectura y Diseño de Sistemas 34 Arquitectura y Diseño de Sistemas 35 4

5 Performance Ejemplo: Seguridad Consideraciones Tipos de ataque Acceder a datos/servicios a los que el usuario no está autorizado Limitar el servicio a usuarios legítimos Es una medida de la capacidad que tiene un Sistema para resistir el uso no autorizado mientras continua proveyendo servicio a usuarios legítimos La seguridad puede ser caracterizada en términos de: Confidencialidad Integridad Disponibilidad Autenticación No repudiación Autorización Arquitectura y Diseño de Sistemas 36 Arquitectura y Diseño de Sistemas 37 Seguridad la Arquitectura y Diseño de Sistemas 38 Individuo o sistema que está correctamente identificado, incorrectamente identificado, de identidad desconocida que es Interno/externo, autorizado/no autorizado con acceso a. Recursos limitados, vastos recursos Trata de Ver datos, modificar/eliminar datos, acceder a servicios del sistema, reducir la disponibilidad de los servicios del sistema Servicios del sistema; datos dentro del sistema Online u offline; conectado o desconectado; detrás de un firewall o abierto Autentica al usuario; oculta la identidad del usuario; bloquea/permite accesos a datos y/o servicios; garantiza o rechaza permisos para acceder a datos y/o servicios; registra los accesos por usuario; almacena datos en un formato no legible; reconoce un inexplicable aumento de demanda del servicio, informando a un usuario u otro sistema y restringiendo la disponibilidad del servicio. Tiempo/esfuerzo/recursos necesarios para sortear medidas de seguridad con probabilidad de éxito; probabilidad de detectar ataques; probabilidad de identificar responsables de un ataque o del acceso/modificación de datos; porcentaje de servicio aun disponible ante un ataque denial-of-services. Seguridad Un empleado descontento desde una ubicación remota intenta acceder a la tabla de tasas de pago durante la operación normal. El sistema mantiene un registro de auditoría y los datos correctos son restaurados dentro de 1 día. Empleado descontento conectado remotamente Arquitectura y Diseño de Sistemas 39 : Intenta modificar tasas de pago Datos dentro del Sistema Bajo operación normal El Sistema mantiene registros de auditoría Los datos correctos son restaurados dentro de 1 día y el autor es identificado Seguridad Ejemplo: Testeabilidad Es el grado en el cual un artefacto de software (sistema, modulo, clase, etc) soporta testing en un contexto de test dado. Si la testeabilidad del arterfacto de sw es alta, entonces encontrar defectos a través del testing es más sencillo. Consideraciones Se orienta, principalmente, a la posibilidad de realizar tests automatizados: unit tests, integration tests, UI tests. Para que un artefacto de software sea testeable, debe ser posible Controlar las entradas del componente, ejercitando su estado interno. Observar las salidas Arquitectura y Diseño de Sistemas 40 Arquitectura y Diseño de Sistemas 41 5

6 Testeabilidad Testers unitarios; testers de integración, tester de sistema, tester de aceptación, usuario finales del sistema (ya sea de manera manual o automática) Un conjunto de tests es ejecutado debido a: Incremento de código terminado o integración de subsistema terminada Sistema entregado La porción del sistema siendo testeada En tiempo de desarrollo En tiempo de compilación En tiempo de deployment En tiempo de ejecución Ejecutar un conjunto de tests y capturar el resultado Capturar las actividades que resultaron en una falla. Controlar y monitorear el estado del sistema la Porcentaje de cobertura del código ejecutable Probabilidad de falla, si la falla existe Tiempo para realizar los test Longitud de la cadena de dependencias más larga en un test Cantidad de tiempo para preparar un ambiente de test Testeabilidad Un tester unitario (desarrollador) terminó una unidad de código durante el desarrollo y realiza una secuencia de tests cuyos resultados son capturados logrando una cobertura del 85% en menos de 3 horas. Tester Unitario : Unidad de código terminada Unidad de códigp Desarrollo Resultados capturados La cobertura de código del 85% es realizada en 3 horas. Arquitectura y Diseño de Sistemas 42 Arquitectura y Diseño de Sistemas 43 Testeabilidad Testeabilidad Caso de Estudio: El Ejército de Simios de Netflix Netfix está montado sobre la nube de Amazon (AWS), más precisamente sobre instancias de EC2 (servidores virtuales). Utiliza un ejército de simios como para parte de su proceso de testing. Chaos Monkey: Aleatoriamente mata procesos en el sistema ejecutando para monitorear el efecto de un proceso fallido. Latency Monkey: Introduce retardos artificiales en la capa de comunicación cliente-servidor para simular degradación. Conformity Monkey: Busca instancias que no adhieren a las buenas prácticas y las baja (por ej., instancias que no pertenecen a un auto-scaling group). Doctor Monkey: Monitorea la salud de las instancias de EC2. Janitor Monkey: Asegura que en ambiente de Netflix en la nube no desperdicia recursos. Donde encuentra un recurso no usado, lo libera. Security Monkey: Busca violaciones o vulnerabilidades de seguridad. Si las encuentra, las elimina. También chequea que los certificados SSL no se venzan Monkey: Detecta problemas de configuración de localización e i18n. Netflix pondera la testeabilidad de su sistema para asegurar la calidad de su servicio. Arquitectura y Diseño de Sistemas 44 Arquitectura y Diseño de Sistemas 45 Ejemplo: Usabilidad Areas de Interés Aprendizaje de características del sistema Uso eficiente del sistema Minimizar el impacto de errores Adaptación del sistema a las necesidades del usuario Incrementar la confianza y satisfacción Relación con la Arquitectura Muchas características de usabilidad requieren de soluciones arquitectónicas tempranas Arquitectura y Diseño de Sistemas 46 La facilidad con que las personas pueden utilizar un Sistema con el fin de alcanzar un objetivo concreto. Usabilidad Arquitectura y Diseño de Sistemas 47 Usuario final Quiere Aprender las características del sistema; usar el sistema eficientemente; minimizar el impacto de errores de usuario; adaptar el sistema a sus necesidades; configurar el sistema Sistema En tiempo de ejecución; en tiempo de configuración Para soportar el aprendizaje de las características del sistema Sistema de ayuda sensible al contexto; UI familiar para el usuario Para soportar el uso del sistema eficientemente Agregación de datos/comandos; reuso de datos y comandos ya ingresados; soporte para una navegación eficiente; distintas vistas con operaciones consistentes; Para minimizar el impacto de errores de usuario Deshacer, rehacer y recuperarse de una falla del sistema; reconocer y corregir un error de usuario; recuperar password olvidada Para adaptar el sistema Personalización; Internacionalización Para sentirse cómodo Mostrar el estado del sistema; trabajar al ritmo del usuario la Tiempo de la tarea; cantidad de errores; cantidad de problemas resueltos; satisfacción del usuario; tasa de operaciones exitosas vs operaciones no exitosas; interacción necesaria para completar una tarea. 6

7 Usabilidad Usabilidad Un usuario descarga una nueva aplicación y está usándola productivamente luego de 2 minutos de experimentación. Usuarios : Descargar una nueva aplicación Sistema En ejecución El usuario usa la aplicación productivamente Dentro de 2 minutos de exploración Arquitectura y Diseño de Sistemas 48 Arquitectura y Diseño de Sistemas 49 Ejemplo: Confiabilidad La capacidad de un sistema de mantenerse operativo en el tiempo. La probabilidad que tiene el sistema de realizar su función sin fallas durante un período de tiempo Medidas: Tiempo Medio Entre Fallas (MTTF) Porcentaje de operaciones que se ejecutan correctamente en un periodo Ejemplo: Sistema de Aterrizaje Automático Disponibilidad Alta: Debe estar disponible cuando el avión debe aterrizar Confiabilidad Baja: No tiene que permanecer operativo por largos periodos de tiempo. Confiabilidad Observaciones: Está muy ligado a otros atributos de calidad: Disponiblidad: Es la probabilidad que tiene el Sistema de estar operativo en un determinado punto en el tiempo. Tolereancia a Fallas: La capacidad para mantener un determinado nivel de rendimiento en casos de fallas de software o de violación a su interfaz. Recuperabilidad: La capacidad de restablecer un nivel de rendimiento determinado y recuperar los datos directamente afectados en caso de falla. Madurez: La capacidad de evitar fallas como resultado de defectos en el software. Arquitectura y Diseño de Sistemas 50 Arquitectura y Diseño de Sistemas 51 Confiabilidad la Interna al Sistema; externa al sistema Defecto: datos erróneos, falla de hardware, bug en el código, problemas de ambiente Procesadores del sistema, canales de comunicación, almacenamiento persistente, procesos, datos Modo Normal, Modo Sobrecargado El Sistema detectaría un evento y haría una o varias de las siguientes acciones: Registrarlo Notificar a quienes corresponda, incluyendo el usuario y otros sistemas Tomar las acciones necesarias para dejar los datos consistentes Reintentar la operación (probablemente con algún delay) Tiempo medio entre fallas Porcentaje de operaciones que se ejecutan correctamente en un periodo Tiempo que el Sistema puede funcionar en modo Sobrecargado Disponibilidad En AWS (la nube de Amazon) las conexiones a los servicios de AWS pueden fallar eventual y esporádicamente. Ante una falla de la infraestructura de AWS, el sistema debe reintentar la transacción en 5, 10, 20, segundos hasta que logre ejecutarse existosamente. Infraestructura de AWS : Error de acceso a un servicio de AWS Proceso Operación Normal Reintentar la transacción hasta tener éxito. Frecuencia de reintento: 5, 10, 20, 40 segundos, Sin transacciones fallidas Arquitectura y Diseño de Sistemas 52 Arquitectura y Diseño de Sistemas 53 7

8 Usabilidad Reliability Tactics Detect Faults Recover from Faults Prevent Faults Fault Ping/Echo Monitor Heartbeat Timestamp Sanity Checking Condition Monitoring Voting Exception Detection Self-Test Preparation and Repair Active Redundancy Retry Ignore Faulty Behaior Degradation Reconfiguration Async. Processing Reintroduction Shadow Passive State Resync Redundancy Escalating Restart Exception Handling Non-Stop Rollback Forwarding Transaction Predective Model Exception Prevention Increase Competence Set Replace Fault Masked or Repair Made Arquitectura y Diseño de Sistemas 54 8

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

Temario III Testing in the Large

Temario III Testing in the Large Temario III Testing in the Large 1ra Parte Verificación y Validación de Software UNS 1 Contenidos Testing de Integración Testing de Sistema Testing de Regresión Verificación y Validación de Software UNS

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

Testing. Tipos, Planificación y Ejecución de Pruebas

Testing. Tipos, Planificación y Ejecución de Pruebas Testing Tipos, Planificación y Ejecución de Pruebas Contenido Definiciones del Testing de Software Objetivos, conceptos Tipos de Test Testing a-la RUP Rol del Testing en el proceso Artefactos Trabajadores

Más detalles

Ingeniería de Software Calidad de Procesos y Productos de Software

Ingeniería de Software Calidad de Procesos y Productos de Software Ingeniería de Software Calidad de Procesos y Productos de Software M. Visconti & H. Astudillo Departamento de Informática Universidad Técnica Federico Santa María Calidad

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Primer Cuatrimestre de 2009 Clase 3b: Especificación de Atributos de Calidad y QAW Buenos Aires, 23 de Marzo de 2009 Una historia real Reunión por una gran licitación entre el

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

Trabajo de Investigación

Trabajo de Investigación Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un

Más detalles

Atributos de Calidad / Tácticas

Atributos de Calidad / Tácticas Atributos de Calidad / Tácticas Ing. Nicolás Passerini Ing. Gustavo Andrés Brey Gastón Coco 2009 Agenda # Tema 1 Introducción Duración 10 min 4 Atributos de Calidad / Tácticas 4.1 Performance 15 min 4.2

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

Atributos de Calidad y Tácticas. Performance / Disponibilidad / Seguridad / Usabilidad / Modificabilidad

Atributos de Calidad y Tácticas. Performance / Disponibilidad / Seguridad / Usabilidad / Modificabilidad Atributos de Calidad y Tácticas Performance / Disponibilidad / Seguridad / Usabilidad / Modificabilidad Atributos, concerns y Una breve introducción tácticas Concerns y Escenarios Tácticas Se asocian con

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

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

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

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

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

Ingeniería del Software II

Ingeniería del Software II Ingeniería del Software II Segundo cuatrimestre de 2008 Práctica de Arquitectura de Software - Parte I Atributos de calidad y escenarios Departamento de Computación Facultad de Ciencias Exactas Universidad

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

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010 SSTQB Nivel Fundamentos Examen ejemplo Página 1 de 12 Fecha publicación: 28 - octubre - 2015 Índice Preguntas... 3 Respuestas... 12 Página 2 de 12 Fecha publicación: 28 - octubre - 2015 Preguntas 1 2 Una

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

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

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Alcance y descripción del servicio ANTIVIRUS IPLAN

Alcance y descripción del servicio ANTIVIRUS IPLAN Alcance y descripción del servicio ANTIVIRUS IPLAN 1. Introducción. El servicio de Antivirus IPLAN ofrece una amplia cobertura contra distintos tipos de detecciones, permitiendo de forma cotidiana, efectiva

Más detalles

Programa de Capacitación y Certificación.

Programa de Capacitación y Certificación. Programa de Capacitación y Certificación. NIVEL 2. DIRECTORIO ACTIVO INFORMES@COMPUSUR.COM.MX WWW.COMPUSUR.COM.MX 1 Contenido CARRERA DE CERTIFICACION. ADMINISTRADOR DE SERVIDORES (PERFIL)... 3 CARRERA

Más detalles

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 22/08/2005 1.0 Versión preliminar Horacio Nova 25/08/2005 1.0 Versión

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

http://www.statum.biz http://www.statum.info http://www.statum.org

http://www.statum.biz http://www.statum.info http://www.statum.org ApiaMonitor Monitor de Infraestructura BPMS Por: Ing. Manuel Cabanelas Product Manager de Apia Manuel.Cabanelas@statum.biz http://www.statum.biz http://www.statum.info http://www.statum.org Abstract A

Más detalles

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2 TABLA DE CONTENIDO Pág. 1. REQUERIMIENTOS NO FUNCIONALES... 2 1.1 ATRIBUTOS DE CALIDAD DEL SISTEMA... 2 1.2 OTROS REQUERIMIENTOS NO FUNCIONALES... 4 1.3 REQUERIMIENTOS NO FUNCIONALES PARA HERRAMIENTAS

Más detalles

Implantación de Sistemas

Implantación de Sistemas Implantación de Sistemas Maria Ines Parnisari 17 de Diciembre de 2014 Índice Parte 1: Implantación... 2 Factores clave para una implantación exitosa... 2 Etapas de un proyecto de Sistemas... 2 Fases de

Más detalles

Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas 1er.Cuatrimestre de 2006.

Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas 1er.Cuatrimestre de 2006. Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 2 Calidades del producto y del proceso Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar]

Más detalles

BSDENTERPRISE SA DE CV

BSDENTERPRISE SA DE CV Servicios Software Testing Quality Assurance BSDENTERPRISE SA DE CV Tabla de Contenido Objetivo del Documento...2 Objetivo QA...2 Ventajas y beneficios...2 Principales Tipos de Prueba...3 Esquema de pruebas...3

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

Control de Calidad de Software. Ing. Jorge Montaño Párraga

Control de Calidad de Software. Ing. Jorge Montaño Párraga Control de Calidad de Software Ing. Jorge Montaño Párraga Agenda Contenido Porque es necesario controlar la calidad? Que es testear? 7 Principios de Control de Calidad Proceso Fundamental de SQA Porque

Más detalles

Continuous Integration Contenido

Continuous Integration Contenido Continuous Integration Contenido Continuous Integration... 1 Principios del Manifiesto Ágil... 3 Concepto... 3 Qué es integrar?... 3 Qué implica construir?... 3 Entonces, Qué es la Integración Continua?...

Más detalles

4. La instantánea se pone en línea y está listo para su uso.

4. La instantánea se pone en línea y está listo para su uso. 1 er RESUMEN TRADUCIDO. Las instantáneas de SQL Server 2005. Una vista de DBA en SQL 2005 instantáneas de base de datos Las instantáneas de bases de datos son un instrumento nuevo Enterprise Edition sólo,

Más detalles

Medición de calidad de software. Calidad en el Desarrollo de Software. Modelo de McCall. Modelos iniciales de calidad

Medición de calidad de software. Calidad en el Desarrollo de Software. Modelo de McCall. Modelos iniciales de calidad Medición de calidad de software Modelos de calidad de software Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Segundo Cuatrimestre 2007 la calidad, al igual que la belleza,

Más detalles

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad.

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad. Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS290T. Ingeniería de Software I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Dr. Marcello Visconti Z. Programa Proceso de Software y Paradigmas de Desarrollo Gestión de Proyectos Fases del

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

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

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR Ignacio.bayugar@mercadolibre.com, i id nachobayugar@gmail.com NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE El desarrollo ágil El nuevo rol de

Más detalles

Seguridad de la información en SMart esolutions

Seguridad de la información en SMart esolutions Seguridad de la información en SMart esolutions Índice Qué es SMart esolutions? Qué es la seguridad de la información? Definiciones Opciones de seguridad de SMart esolutions Preguntas frecuentes 04/05/2005

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

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

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

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A. Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software SLC -ERS Relator: Sr. Eduardo Leyton G Ingeniería de Software (IS) Es una disciplina

Más detalles

CAPITULO 1 INTRODUCCIÓN

CAPITULO 1 INTRODUCCIÓN CAPITULO 1 INTRODUCCIÓN La seguridad en las redes de comunicaciones se ha convertido en un aspecto de importancia para los proveedores del Internet y para los clientes debido a la prioridad que ha tomado

Más detalles

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A. Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software Estrategias de Pruebas Relator: Sr. Eduardo Leyton G Pruebas del Software (Basado en

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

monitoreo efectivo del desempeño en entornos SAP

monitoreo efectivo del desempeño en entornos SAP INFORME OFICIAL Septiembre de 2012 monitoreo efectivo del desempeño en entornos SAP Los desafíos clave y cómo CA Nimsoft Monitor ayuda a abordarlos agility made possible tabla de contenido resumen 3 Introducción

Más detalles

Modelado y Diseño de Arquitectura de Software

Modelado y Diseño de Arquitectura de Software Modelado y Diseño de Arquitectura de Software CONCEPTOS DE MODELADO Fernando Barraza A. MS.c. fernando.barraza@gmail.com 2 Desarrollo de sistemas de software Requisitos funcionales del software Si todo

Más detalles

EXIN Cloud Computing Foundation

EXIN Cloud Computing Foundation Examen tipo EXIN Cloud Computing Foundation Edición Abril 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

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

PROCEDIMIENTO DE ADMINISTRACIÓN DE LA SEGURIDAD EN LA RED

PROCEDIMIENTO DE ADMINISTRACIÓN DE LA SEGURIDAD EN LA RED 1. OBJETIVO Establecer el procedimiento para la administración de la seguridad en la que asegure su protección efectiva contra ataques y permita cumplir los requisitos de confidencialidad, integridad y

Más detalles

Components & Connectors Viewtype. Estilos

Components & Connectors Viewtype. Estilos Components & Connectors Viewtype Estilos 1 Estilos Especializan el C&C viewtype introduciendo tipos de componente y conector a los cuales pertenecerán las instancias del modelo Especifican patrones de

Más detalles

Software y Aplicaciones

Software y Aplicaciones Software y Aplicaciones 1. Consejo de Seguridad Informática ST04-006 Saber qué son los Parches Cuando los proveedores advierten vulnerabilidades en sus productos, a menudo largan parches para solucionar

Más detalles

Auditoría documental y seguridad de la información: Como generar un Sistema de Seguridad de la Información?

Auditoría documental y seguridad de la información: Como generar un Sistema de Seguridad de la Información? 1 Título diapositiva Auditoría documental y seguridad de la información: Como generar un Sistema de Seguridad de la Información? Alicia Barnard Amozorrutia Quito, Ecuador, abril 25, 2014 2 Contenido Auditoría

Más detalles

PLATAFORMA DE GESTIÓN DE PROYECTOS-REDMINE: FUNCIONALIDADES

PLATAFORMA DE GESTIÓN DE PROYECTOS-REDMINE: FUNCIONALIDADES PLATAFORMA DE GESTIÓN DE PROYECTOS-REDMINE: FUNCIONALIDADES Para: Plataforma SW Público. Emergya Ingeniería Nuevo Tajámar, 555 Piso 6 Las Condes Santiago Chile. Tfno. : +562 4273917 www.emergya.com. negocio-chile@emergya.com

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

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

Q-expeditive Publicación vía Internet

Q-expeditive Publicación vía Internet How to Q-expeditive Publicación vía Internet Versión: 2.0 Fecha de publicación 11-04-2011 Aplica a: Q-expeditive 3 Índice Introducción... 3 Publicación de servicios... 3 Ciudadanos... 3 Terminales de auto

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

Monitoreo de Nubes Privadas

Monitoreo de Nubes Privadas Monitoreo de Nubes Privadas Whitepaper Autores: Dirk Paessler, CEO de Paessler AG Gerald Schoch, Editor Técnico de Paessler AG Publicado: Mayo 2011 Ultima Actualización: Febrero 2015 PÁGINA 1 DE 7 Contenido

Más detalles

Historia de revisiones

Historia de revisiones Especificación de Requerimientos de Software Versión 3.0 Historia de revisiones Fecha Versión Descripción Autor 22/08/2015 1.0 Especificación Inicial. Analistas 23/08/2015 1.1 Revisión de SQA. Correcciones

Más detalles

COMPUTACIÓN DE ALTA PERFORMANCE

COMPUTACIÓN DE ALTA PERFORMANCE COMPUTACIÓN DE ALTA PERFORMANCE 2011 1 TOLERANCIA A FALLOS COMPUTACIÓN DE ALTA PERFORMANCE Curso 2011 Sergio Nesmachnow (sergion@fing.edu.uy) Santiago Iturriaga (siturria@fing.edu.uy) Gerardo Ares (gares@fing.edu.uy)

Más detalles

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

Notas de la versión McAfee Web Gateway 7.3.1

Notas de la versión McAfee Web Gateway 7.3.1 Notas de la versión McAfee Web Gateway 7.3.1 Acerca de este documento Funciones nuevas y mejoradas Problemas resueltos Problemas conocidos Instalación Descripción Ampliación desde la versión 7.3 o 7.3.0.x

Más detalles

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

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

Administración y Gestión de Proyectos de Software

Administración y Gestión de Proyectos de Software Administración y Gestión de Proyectos de Software 2do. Cuatrimestre 2005 Depto. Cs. e Ingeniería de la Computación Universidad Nacional del Sur Riesgo: Componentes Riesgo de Rendimiento: el grado de incertidumbre

Más detalles

Documento de Arquitectura de Software IEEE-1471-2000

Documento de Arquitectura de Software IEEE-1471-2000 Documento de Arquitectura de Software Control del documento IEEE-1471-2000 Proyecto Sistema Restaurant Título Arquitectura del Sistema [v1.0 al 02 de Julio de 2009] Generado por Magister en Informática

Más detalles

Práctica de Evaluación de Cortafuegos personales

Práctica de Evaluación de Cortafuegos personales Práctica de Evaluación de Cortafuegos personales Objetivo El objetivo de esta práctica es que el alumno aprenda a configurar y evaluar cuál es la mejor opción de producto en relación a los cortafuegos

Más detalles

Icards Solutions S.A. de C.V.

Icards Solutions S.A. de C.V. Este documento explica la instalación, configuración y operación del sistema de emisión de tarjetas México Emprende. Fecha Autor Revisor Versión 10-06- 2011 Ana Karen Aguilar Rubén Pacheco López 1.0 24-06.2011

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

Más detalles

K2BIM Plan de SQA Versión 1.1

K2BIM Plan de SQA Versión 1.1 K2BIM Plan de SQA Versión 1.1 Historia de revisiones Fecha VersiónDescripción Autor 18/08/2009 1.0 Creación del documento. Diego Píriz 23/08/2009 1.1 Pequeñas correciones. Alan Descoins 1 Contenido 1.

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

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

MS_20331 Core Solutions of Microsoft SharePoint Server 2013

MS_20331 Core Solutions of Microsoft SharePoint Server 2013 Core Solutions of Microsoft SharePoint Server 2013 www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso le proporcionará

Más detalles

www.e-cronia.com Gracias www.eduardoleyton.com

www.e-cronia.com Gracias www.eduardoleyton.com Gracias C.C.S. Calidad de Componentes Software ISO 9126 Agenda Conceptos sobre Componentes Software y Componentes COTS (Commercial Off-The-Shelf Comercio fuera de formalidad o a pedido) Desarrollo Software

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

1. O3 Server Administrator... 2 1.1 Usando O3 Server Administrator... 2 1.2 Administrando el O3 Server... 4 1.3 Administrando los Cubos... 14 1.

1. O3 Server Administrator... 2 1.1 Usando O3 Server Administrator... 2 1.2 Administrando el O3 Server... 4 1.3 Administrando los Cubos... 14 1. O3 Server Administrator...................................................................................... 2 1 Usando O3 Server Administrator...........................................................................

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

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

Más detalles

Evolucionar hacia la Facturación Electrónica es fácil.

Evolucionar hacia la Facturación Electrónica es fácil. Evolucionar hacia la Facturación Electrónica es fácil. Qué es la FACTURACIÓN ELECTRÓNICA? El régimen de facturación electrónica es una modalidad de facturación que traslada los beneficios de la universalización

Más detalles

Seguridad, Web y Java

Seguridad, Web y Java 2 Seguridad, Web y Java Seguridad, Web y Java Daniel López Janáriz d.lopez@uib.es Seguridad, Web y Java 3 1. Introducción: Puntos a tener en cuenta cuando hablamos de seguridad La seguridad al 100% no

Más detalles

FICHAS DE DESCRIPCIÓN DE FUNCIONES Y COMPETENCIAS LABORALES

FICHAS DE DESCRIPCIÓN DE FUNCIONES Y COMPETENCIAS LABORALES Página 1 de 11 I. IDENTIFICACIÓN DENOMINACIÓN DEL CARGO: PROGRAMADOR DE COMPUTADOR SIGLA:PC CLASE: V GRADO: 12-14-16 NIVEL: ADMINISTRATIVO NÚMERO DE CARGOS: ÁREA: 5 JEFE INMEDIATO: 1. OFICINA DE INFORMÀTICA

Más detalles

Implementando iphone e ipad Administración de dispositivos móviles

Implementando iphone e ipad Administración de dispositivos móviles Implementando iphone e ipad Administración de dispositivos móviles ios es compatible con la administración de dispositivos móviles, brindando a las empresas la capacidad de administrar implementaciones

Más detalles

E 2.4.1 Documento de entrega de Aplicación

E 2.4.1 Documento de entrega de Aplicación E 2.4.1 Documento de entrega de Aplicación Versión: 0.1 Fecha: 11/08/11 Autor: Email: Antoni Bertran Bellido abertran@opentrends.net Historial de cambios Versión Fecha Autor Cambios 0.1 11/08/11 Antoni

Más detalles

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do.

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do. Gobernabilidad de TI COBIT Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur 2do. Cuatrimestre 2010 T. 2 Contenido Introducción a la Gobernabilidad de TI

Más detalles

XV Conferencia Colombiana de Usuarios Esri Bogotá, Agosto 26 30 de 2013

XV Conferencia Colombiana de Usuarios Esri Bogotá, Agosto 26 30 de 2013 Taller Técnico Líder en soluciones geográficas empresariales XV Conferencia Colombiana de Usuarios Esri Bogotá, Agosto 26 30 de 2013 Web GIS, Portal y patrones de despliegue Reinaldo Cartagena Web GIS?

Más detalles

Oficina de Seguridad del Internauta (OSI). Ministerio de Industria, Turismo y Comercio DATOS GENERALES. Antecedentes del servicio

Oficina de Seguridad del Internauta (OSI). Ministerio de Industria, Turismo y Comercio DATOS GENERALES. Antecedentes del servicio Oficina de Seguridad del Internauta (OSI). Ministerio de Industria, Turismo y Comercio DATOS GENERALES Antecedentes del servicio Los usuarios frecuentes, es decir, los que se conectan a la red a diario

Más detalles

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas Unidad I Fundamentos de Sistemas Distribuidos M.C. Juan Carlos Olivares Rojas Temario 1.1. Características de un sistema distribuido 1.2. Objetivos de los sistemas distribuidos 1.3. Ventajas y desventajas

Más detalles

Fundamentos de Sistemas Operativos

Fundamentos de Sistemas Operativos Fundamentos de Sistemas Operativos Sistemas Informáticos Fede Pérez Índice TEMA Fundamentos de Sistemas Operativos 1. - Introducción 2. - El Sistema Operativo como parte de un Sistema de Computación 2.1

Más detalles

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico

Más detalles

Administración de bases de datos Microsoft SQL Server 2014 CURSO PRESENCIAL DE 25 HORAS

Administración de bases de datos Microsoft SQL Server 2014 CURSO PRESENCIAL DE 25 HORAS Administración de bases de datos Microsoft SQL Server 2014 CURSO PRESENCIAL DE 25 HORAS CURSO DESCRIPCIÓN DEL CURSO... 2 TEMARIO... 6 Administración de bases de datos Microsoft SQL Server Duración: 25

Más detalles

capacitación y guía para el desarrollo de software Pruebas de Software Pruebas de Software 1

capacitación y guía para el desarrollo de software Pruebas de Software Pruebas de Software 1 Pruebas de Software Pruebas de Software 1 PRUEBAS DE SOFTWARE... 3 INTRODUCCIÓN... 3 Definiciones [1]... 3 Filosofía y Economía... 4 Justificación... 4 PRINCIPIOS [1]... 7 NIVELES DE PRUEBAS... 8 TIPOS

Más detalles