INFORME TCNICO PARA PRESENTAR PROYECTO SOCIOTECNOLGICO IV ADAPTADO A GESTIN DE PROYECTOS, ENFOQUE DEL MARCO LGICO Y PROCESO DE DESARROLLO

ME RINDE PARTE I PLANIFICACIN DEL PROYECTO SOCIOTECNOLGICO 1. PLANIFICACIN DEL PROYECTO 1.1. Conformacin de equipos preliminares de trabajo Planeadores Elaboradores de instrumentos Validadores de Instrumentos Aplicadores de instrumentos 1.2. Planeacin de las fases a abordar para la ejecucin del Proyecto Realizar un diagrama Pert-CPM o Diagrama de Gantt, donde se observe: 1. Diagnstico situacional o Abordaje a la comunidad para relevar la situacin actual, en la que se buscaba encontrar sntomas que reflejarn la posibilidad de encontrar debilidades o problemas. Esta fase va desde la planeacin del diagnstico y culmina con la Propuesta de solucin del problema. 2. Planeacin de la propuesta Esta fase comprende la fase de planificacin del proyecto de desarrollo de software, por lo tanto debemos utilizar el artefacto de planificacin que nos ofrece Me Rinde, slo se har en la parte 3 del informe tcnico aqu solo se menciona. 3. Diseo de la propuesta 4. Construccin o elaboracin de la propuesta 5. Pruebas y optimizacin 6. Entrega del proyecto de software

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

PARTE II LA COMUNIDAD/ORGANIZACIN 1. DIAGNSTICO SITUACIONAL 1.1 Descripcin de la Comunidad y su Contexto: Identificacin de la Organizacin Nombre Misin Visin Objetivos generales Objetivos Especficos Objetivos estratgicos Localizacin Geogrfica (Estado, Municipio, Parroquia, Casero y Direccin). Historia de Vida de la Organizacin (Resea histrica). Organizaciones Vinculadas (Mencionar las organizaciones sociales y no sociales que caracterizan la comunidad 1.2 Modelado del Negocio Con esta disciplina se pretende llegar a un mejor entendimiento de la organizacin o parte de ella, donde se va a implantar la aplicacin de software. Los objetivos especficos de la disciplina modelado de negocio son: Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Derivar los requerimientos del sistema necesarios para apoyar a la organizacin objetivo en su mejora. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Entender la estructura y la dinmica de la organizacin para la cual el sistema va a ser desarrollado (organizacin objetivo). 1.2.1 DAN
Detallar las vistas que se usarn para representar la arquitectura e indicar los involucrados aplicables a cada vista, describir los tipos de elementos que contiene cada vista.

Vista de la Organizacin: Organigrama estructural Organigrama Funcional de la organizacin Organigrama de cargos

Nombre de la o las Unidades Funcionales en estudio:

Vista de Procesos del Negocio: (esta se har por cada unidad funcional) Esta vista incluye los procesos claves del negocio. La Vista de Procesos representa los casos de uso del negocio mediante
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

un diagrama que refleja la relacin existente entre los actores del negocio y los casos de uso del negocio.
Mostrar los casos de uso del negocio significantes. Incluir un diagrama que muestre estos casos de uso del negocio en relacin a los actores del negocio y proporcionar la descripcin o flujo de eventos de cada uno de los casos de uso del negocio. Arquitectnicamente los casos de uso del negocio significantes son esos que proporcionan un alcance funcional extenso y/o ejercen una parte crtica del negocio.

Caso de Uso Asignacin de Arma e Implementos Nombre/ID: Descripcin: R01 El caso de uso se inicia cuando el funcionario solicita la asignacin del arma o implementos. El proceso da curso a la solicitud, analizando la posibilidad de entrega. El caso de uso finaliza cuando el parquero procede a la entrega del arma e implemento al funcionario. Solicitud de arma e implementos, Arma o implemento disponible Que haya arma e implementos disponible, que el solicitante est registrado y no tenga ninguna condicin que niegue su solicitud Actor 1.- El funcionario solicita el arma o implementos entregando al parquero su credencia. Respuesta de negocio 2.El parquero procede a verificar el credencial del funcionario en el listado de funcionarios adscritos y su ubicacin

Requerimiento: Precondiciones: Flujo Normal:

3.Si el Funcionario existe el parquero llena el formato de 5. El funcionario verifica los datos en el asignacin con los datos personales del funcionario y los datos del formato de asignacin procesado por el arma o implemento a entregar parquero. Si el Funcionario no existe pasar a la lnea 9 6. El funcionario devuelve el formato al 4.- El parquero entrega el formato al funcionario para su respectivo parquero chequeo y para la firma. 8.- El funcionario recibe el arma o implemento. 10.-El funcionario recibe el credencial 7.- Si el formato esta bien procesado , el parquero le entrega el arma o implemento Si el formato esta mal procesado, el parquero lo recibe para corregirlo, pasar a la lnea 3 9.-El parquero entrega el credencial al funcionario Flujo Alterno: Actor En la lnea 2 Respuesta de negocio Si el funcionario est adscrito a la comisaria Si el funcionario est adscrito, el parquero le procesa la entrega Si el funcionario no est adscrito, el parquero no procesa la entrega Si el formato de asignacin est bien procesado: Si es esta bien los datos, el funcionario procede a firmar el formato de asignacin Si no estn bien los datos, el funcionario se niega a firmar el formato de asignacin y lo devuelve al parquero Pos El Parquero queda disponible para procesar otra solicitud, inventario de armas actualizado condicio nes: Requeri N/A mientos Especial es:

En la lnea 7

FORMATO PARA FLUJOS DE EVENTOS DE LOS CASOS DE USOS

1.2.2 Evaluacin de la Organizacin Objetivo, EOO (esta se har por cada unidad funcional)

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Este artefacto describe la situacin actual en que se encuentra la organizacin objetivo, es decir, la organizacin en la que el sistema ser implantado. La descripcin est en trminos de procesos actuales, herramientas, competencias entre personas, actitudes de las personas, clientes, competidores, tendencias tcnicas, problemas y reas de mejora. El EOO tambin es usado para crear motivacin y comprensin entre las personas en la organizacin objetivo que son directamente o indirectamente afectadas, as como tambin explicar al involucrado por qu existe la necesidad de cambiar los procesos del negocio, y adems proporcionar la entrada al Marco de Desarrollo y al Plan de Iteracin.

Descripcin de los procesos que se realizan en la o las unidades funcionales Unidad Funcional: XXXXXXXXXX Nombre del proceso: DEBE SER UN VERBO
TRABAJADOR QUE ENTRADAS DESCRIPCION GENERAL DEL PROCESO SALIDAS LO EJECUTA

1.2.3 Modelo de Anlisis del Negocio (esta se har por cada unidad funcional) Este modelo es interno al negocio, describe la realizacin de los casos de uso del negocio, para lo cual detalla cmo cada caso de uso de negocio es llevado a cabo por un grupo de trabajadores u sistemas que emplean entidades del negocio y unidades de trabajo recprocamente. A diferencia del Modelo de Casos de Uso del Negocio el cual describe qu pasa entre el negocio y los actores de negocio, el Modelo de Anlisis define los trabajadores internos de negocio y la informacin que ellos emplean (entidades de negocio). Describe su organizacin estructural en unidades independientes (sistema de negocio) y precisa cmo ellos interactan para ejecutar el comportamiento sealado en los casos de uso de negocio. El Modelo de Anlisis del Negocio puede contener: los diagramas, trabajadores, sistemas, entidades, reglas, las relaciones, colaboraciones, entre otros elementos del negocio. Para representar los diagramas del Modelo de Anlisis del Negocio se pueden emplear diferentes diagramas de UML tales como: Diagramas de Colaboracin. Diagramas de Secuencia. Diagramas de Actividad yo recomiendo este Diagramas de Estado.

ANEXOS 1 Realizaciones de los Casos de Uso del Negocio Este artefacto expresa la colaboracin de los sistemas del negocio, los trabajadores del negocio, las entidades del negocio, y los eventos del negocio para realizar un caso de uso del negocio particular. Mientras que un caso de uso del negocio describe los pasos que se deben realizar para aportar valor a un actor del negocio, una realizacin de casos de uso del negocio describe la manera en que estos pasos se realizan dentro de la organizacin. Adems, las Realizaciones de los Casos de uso del Negocio son utilizadas por los involucrados
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

para verificar que el equipo del proyecto y dems involucrados entienden la estructura y el funcionamiento del negocio. Entidad del Negocio Este artefacto representa una pieza de informacin significativa que es manipulada por los actores y trabajadores del negocio. Se refiere al estado de la informacin que pasar entre cada capa como un conjunto de datos que la identifican una entidad. Las entidades del negocio de una aplicacin representa entidades reales y adems suelen ser sustantivos, como por ejemplo: Cliente, Nmina, Factura, Depsito, etc. Asimismo, las entidades de negocio son la base para compartir documentos entre los trabajadores del negocio y estas pueden ser utilizadas en diversas Realizaciones de los Casos de Uso del Negocio. 2 Reglas del Negocio Una Regla del Negocio es la declaracin de polticas y restricciones de negocio de una organizacin. Este artefacto consiste en definir una exigencia especfica o invariable que debe satisfacerse por el negocio. Las Reglas del Negocio pueden aplicarse siempre o slo bajo una condicin especfica. Es necesario que la aplicacin muestre las restricciones que existen en el negocio, de tal forma que no sea posible realizar acciones invlidas. 3 Trabajador del Negocio Un Trabajador del Negocio representa a un ser humano, software o hardware que desempea un rol dentro de las Realizaciones del Caso de Uso del Negocio. Este trabajador interacta con entidades y otros trabajadores para que el negocio funcione. Los trabajadores de negocio son roles y no posiciones organizacionales, ya que una persona puede desempear varios roles pero slo tiene una posicin en la Organizacin. Esta Conceptualizacin permite identificar mejoras en los procesos del negocio y considerar el efecto de la automatizacin del proceso del negocio o del outsourcing de proceso del negocio. 1.3 Descripcin del diagnstico situacional de la o las unidades funcionales en estudio (Formulacin del problema). 1.3.1rbol del Problema 2.- OBJETIVOS DEL PROYECTO (General y Especficos). 2.1 rbol de Objetivos objetivo general y especficos del Proyecto Redactar

(importante sealar que el objetivo del proyecto es diferente al objetivo del Software a desarrollar) 2.2 Propuesta de solucin (aqu se plantea el desarrollo de alguna solucin informtica que permitir logar los objetivos del proyecto) Visin del Sistema Este artefacto describe los objetivos principales del proyecto, funcionalidades y restricciones en forma concisa; es un resumen del proyecto apto para la toma de decisiones, ofrece una descripcin del sistema a ser desarrollado desde la perspectiva de los requerimientos ms importantes. Este documento captura las expectativas de los que soportan el desarrollo del proyecto. Se recomienda que este artefacto se conserve lo ms claro y resumido posible para que pueda llegar lo ms pronto posible a los involucrados en el proyecto y para que sea ms
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

fcil de entender por estos. Este documento debe incluir solamente las principales descripciones de los requerimientos y debe evitar muchos detalles especficos. Adicionalmente debe especificar las capacidades operacionales (volmenes de trabajo, tiempos de respuestas, precisin), perfiles de usuario, y los lmites del sistema. Modelo de Casos de Uso (este se deriva del diagrama de actividades del CUN, actividades a computarizar) Este artefacto se basa en la descripcin de elementos o usuarios externos al sistema (actores) y de la funcionalidad del sistema (casos de uso). Un Modelo de Casos de Uso describe los requerimientos funcionales de un actor (usuario, sistema, dispositivo, etc.) en trminos de las interacciones que ste ejecuta con el sistema. El modelado de casos de uso es una tcnica efectiva y a la vez simple para modelar los requerimientos del sistema desde la perspectiva del usuario. Presenta el sistema desde la perspectiva de su uso y esquematiza como proporcionar valor a sus usuarios. El modelo de casos de uso sirve como acuerdo entre clientes y desarrolladores para limitar las funciones con que dispondr el sistema luego de ser implementado, adems proporciona la entrada fundamental para el anlisis, el diseo, la implementacin y las pruebas. Cabe recordar que MeRinde est dirigido por casos de uso, de aqu la importancia de este modelo. Este modelo est formado por los diagramas de casos de uso y las narrativas de los casos de uso. Para representar los diagramas del Modelo de Casos de Uso se puede emplear el diagrama de UML de Caso de Uso. DEBEN REALIZAR EL CUS Y FLUJO DE EVENTOS PARA CADA CUS 2.3 Especificacin de Requerimientos del Software (ERS) El objetivo de este artefacto es documentar todos los requerimientos del sistema, este describe las funciones del sistema, los requerimientos no funcionales, caractersticas del diseo, y otros elementos necesarios para proporcionar una descripcin completa y comprensiva de los requerimientos para el software a desarrollar. Los requerimientos pueden ser levantados con diferentes herramientas, tambin se pueden encontrar dispersos en varios artefactos y herramientas. Es por ello, que esta metodologa propone capturar todos los requerimientos para el ERS en un solo artefacto, el cual est conformado por dos (2) artefactos que describen los requerimientos que son: Modelo de Casos de Uso y Especificaciones Suplementarias. El artefacto ERS controla la evolucin del sistema durante toda el ciclo de desarrollo del proyecto, cuando las nuevas caractersticas son aadidas o modificadas al artefacto de visin, son aclarados dentro del artefacto ERS. Las decisiones hechas escribiendo el ERS estn basadas en informacin de los documentos de la propuesta del proyecto y en requerimientos del usuario. El conjunto de requerimientos especificados en el ERS deben ser satisfechos en el diseo del sistema. Cualquier requerimiento funcional o no funcional que no sea identificado en el ERS, no debe aparecer en el producto final. 2.3.1 Requerimientos Funcionales

ID del RF-01 Requerimiento:

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Nombre del Requerimiento: Asignacin de Implementos Caractersticas: Datos que describen o identifican los diferentes implementos asignados al Departamento. Descripcin del Se debe almacenar: Nombre, descripcin, tipo, requerimiento: cantidad, serial, Prioridad del requerimiento: Alta O Media Alta O Media Baja O Baja O Media

2.3.2 Requerimientos No Funcionales

Describa los requerimientos no funcionales para este documento. Los requerimientos no funcionales tienen que ver con las caractersticas que de una u otra forma puedan limitar el sistema como son: el rendimiento (en tiempo y espacio), confiabilidad, interfaces, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc. Usabilidad En este apartado se debe incluir la lista de todos los requerimientos que afecten la usabilidad. Esto debe incluir: el tiempo que se tomar un usuario en aprender a utilizar el sistema y se podra explicar por qu debe ser rpido el aprendizaje, los tiempos medibles de tarea para las tareas tpicas y los requerimientos para concordar con estndares. Confiabilidad Aqu se deben detallar los requerimientos de confiabilidad del sistema. Describa las caractersticas de confiabilidad explicando la posibilidad del sistema de realizar las funciones para las que fue diseado sin presentar fallos. Entre estos requerimientos puede mencionar caractersticas como la disponibilidad, el porcentaje de fallas mximo, etc. Seguridad Aqu se deben detallar los requerimientos de seguridad del sistema. Esto incluye si el acceso al sistema ser controlado con nombres de usuario y contraseas, que solo los usuarios con privilegios de administrador podrn acceder a las funciones administrativas y los usuarios normales no podrn. Eficiencia En este apartado se debe ver reflejado las caractersticas de eficiencia del sistema. Se debe especificar: el tiempo de respuesta para una transaccin (promedio), capacidad (nmero de clientes y transacciones), rendimiento del procesamiento (Ej. transacciones por segundo) y cuando el sistema se ha degradado cul es el modo aceptable de operacin. Mantenimiento y Actualizacin En este apartado se debe ver reflejado los requerimientos de mantenimiento y actualizacin. La capacidad de mantenimiento es la habilidad que se tiene para realizar cambios al producto en el tiempo y la capacidad de actualizacin es la habilidad que se tiene para entregar las versiones del producto a bajo costo a los clientes con un mnimo de tiempo de descarga. Una caracterstica clave para apoyar este objetivo es la descarga automtica de parches o actualizaciones y actualizaciones del equipo del usuario final. Tambin debemos utilizar formatos para archivos de datos que incluyan suficientes metadatos para permitirnos trasformar con seguridad la informacin existente del usuario durante una actualizacin. Soportabilidad y Operabilidad Especificar los requerimientos de soportabilidad y operabilidad del sistema. La soportabilidad la habilidad de proveer soporte tcnico eficiente y a buen precio y la operabilidad es la habilidad que se tiene de hospedar y operar el software como un ASP (Proveedor de Servicios de Aplicaciones). Restriccin de Diseo En este apartado se debe indicar cualquier limitacin de diseo en el sistema que es construido. Por ejemplo: lenguajes de software, requerimientos del proceso de software, uso de herramientas de desarrollo, componentes comprados, etc.
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Requerimientos de Documentacin en Lnea y de Sistemas de Ayuda En caso de que exista se debe describir los requerimientos, para la documentacin en lnea del usuario, sistemas de ayuda, ayuda sobre avisos, etc.

Especificaciones Suplementarias (OPCIONAL)

Este artefacto captura los requerimientos del sistema que no fueron recogidos en el Modelo de Casos de Uso. Contiene tanto requerimientos funcionales como no funcionales del sistema. Los requerimientos que deben considerarse para este artefacto son los siguientes: usabilidad, confiabilidad, desempeo, mantenibilidad, seguridad, restricciones de diseo, requerimientos de documentacin en lnea y de sistemas de ayuda, componentes comprados, interfaces, requerimientos de licenciamiento, y aspectos legales, derecho de autor y otros avisos Glosario del Sistema

Es una lista que contiene las definiciones de los trminos a hacer utilizados durante la realizacin del proyecto, que deben ser comprendidos por los participantes de tal manera que haya una buena comunicacin y evitar interpretaciones dispares o ambiguas de los trminos del dominio del problema. Documentar las definiciones de trminos y acrnimos ayuda a otros artefactos a ser ms concisos y precisos. En algunos proyectos donde la planeacin del negocio y del dominio no se realiza, el Glosario es el artefacto principal para capturar la informacin sobre el dominio de negocio del proyecto. 3.- JUSTIFICACIN E IMPACTO SOCIAL DE LA PROPUESTA Terico, tcnico, legal. Poblacin Beneficiada. Impacto Social (Plan Simn Bolvar) 4.- ESTUDIO DE FACTIBILIDAD DE LA PROPUESTA (Legal, social, organizacional operativa, tcnica y econmica). 5. ANTECEDENTES TECNOLGICOS 6. BASES TERICAS

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

PARTE III ANLISIS, DISEO, DESARROLLO E IMPLEMENTACIN DEL DISEO TECNOLGICO 1. Metodologa a utilizar Me Rinde, definir aspectos relevantes que caracterizan a la metodologa 2. Planificacin del Proyecto de software 2.1 Objetivo Se refiere a los objetivos del software 2.2 Alcance

2.3 Caractersticas y Beneficios Ejemplo: Una aplicacin para Web reutilizable con funcionalidad para crear, editar, borrar, buscar, categorizar, navegar, calificar y comentar clientes. Esto automatiza todos las operaciones de los clientes y asegura que los usuarios podrn encontrar siempre informacin que de forma automtica se encuentre actualizada. La aplicacin del sitio deber tener una apariencia altamente configurable que le permita ajustarse a la apariencia y carcter del
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

cliente. Esto permite reutilizar la aplicacin del sitio para que tenga una apariencia de alta calidad que pueda ser muy buena. La aplicacin del sitio deber ser segura y solo permitir usuarios con los permisos adecuados para editar, borrar o aadir otros usuarios al sistema. Esto para prevenir trampas o la publicacin de informacin falsa. 2.4 Suposiciones y Limitaciones Describir todas las suposiciones que se realizan sobre el proyecto y se declaran las restricciones impuestas tales como restricciones de personal, temporales, de hardware, de software, etc. 2.5 Organizacin de los Equipos de Trabajo En este apartado se realiza la descripcin de la organizacin de los equipos del proyecto. Se debe reflejar en qu consistir cada equipo. Ver los roles que define Me rinde a. Analista de Calidad. b. Analista de Producto. c. Arquitecto de Software. d. Desarrollador. e. Involucrado. f. Lder del Proyecto. g. Mentor. h. Probador. 2.6 Herramientas de Desarrollo y Colaboracin Aqu se especifican las herramientas que se planean usar de manera intensiva durante el desarrollo del proyecto. Esas herramientas pueden ser : listas de correo del proyecto, sitio Web del proyecto, sistema de control de cambios, sistema automatizado de compilacin, sistema de control de versiones, sistema automatizado para unidad de pruebas, etc.

2.7 Calendario del proyecto Se debe incluir un calendario de las principales actividades del proyecto.

2.8 Matriz de componentes a desarrollar (ver matriz de relacin de disciplinas y componentes pg. 66) Ejemplo COMPONENTES DISCIPLINA ARTEFACTO Documento de Arquitectura del Negocio Evaluacin de la Organizacin Objetivo Visin del Negocio MODELADO Modelo de Anlisis del Negocio DEL Entidad del Negocio NEGOCIO Trabajador del Negocio Reglas del Negocio
Modelo de Caso de Uso del Negocio Modelo de Diseo del Negocio
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

FASES E C

Realizaciones de los Casos de Uso del Negocio Modelo de Implantacin del Negocio Prueba de Concepto Arquitectnico del Negocio

2.9 Manejo de Riesgos Enumerar y agrupar los mayores riesgos para este proyecto, y que se planea hacer para resolver o prevenir cada riesgo. En el caso de que no se vaya a hacer nada para mitigar el riesgo debe mencionarlo. 2.9.1 Plan de Riesgos Se debe tener en cuenta la siguiente matriz de probabilidades e impacto de los riesgos
Objetivo proyecto Costos del Muy Bajo (5%) Incremento insignificante ser cubiertos. Bajo (10%) Moderado (20%) Alto (40%) Muy Alto (80%)

Incremento en costo Incremento en costos Incremento en costos Incrementos en costos en < 10%. Nuevo entre de Replanteo del 10-20%. entre de los Suspensin del proyecto. 20-40%. >40%. Incrementos no temporal pueden ser cubiertos en del su totalidad. Proyecto finaliza. desarrollo

costos, aun pueden Anlisis Asignacin Recursos Tiempo Insignificante, afecta asignacin tiempos. Alcance Reduccin escasamente apreciable. planteado. Calidad Degradacin escasamente aceptable. afecta desempeo proyecto. Se aplicaciones el de recursos. del No afecta al alcance Proyecto. no Retraso la Posibilidad asignado.

de procesos del proyecto.

<10%. Retraso global entre Retraso global entre 20- Retraso global >40%. de 10-20%. Aumento de 40%. tiempos de tareas en 10-20%. mayores 40% de Reduccin de alcance No se puede llegar a inaceptado Institucin. por la cumplir con el alcance del proyecto. Fin del proyecto. afectan Posible reduccin de Menor calidad por replanteo desarrollo calidad por Cierre de proyecto al de Aumento de Suspensin de las las tiempo de tareas en 20- actividades del proyecto.

de aumento del tiempo los

Alcance afectado de reas manera mnima.

alcance afectadas.

acelerado debido incumplimiento de calidad.

No exigentes por escasez de tareas y tiempos.

(reduccin de mdulos)

estndares y normativas

Prioridades Establecidas para los Riesgos: Prioridad de Riesgo 1 2 3 4 2.9.2 Gestin de Riesgos del Proyecto
Riesgo que Id puede sucede y como puede suceder Las consecuencias de Aptitud de los controles existentes Puntaje e Nivel de riesgo Prioridad de riesgo

Descripcin Alta Moderada Bajo Muy Bajo

suceder un evento consecuencias Probabilidad Probabilidad

2.9.3
Riesgo

Plan de Tratamiento de los Riesgos

Opcin tratamiento elegida de Contro les es Aceptacin o Monitoreo de de riesgos y tratamiento implementacin opciones de rechazo segn Fecha Costo/beneficio

Riesgos en orden Posible tratamiento de los de prioridades riesgos

existent anlisis

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

 extra. Fecha limite de la 1 presentacin entregables prxima. de

Trabajar tiempo Recuperar noches. Solicitar apoyo a la Institucin o al Instituto acadmico mediante una prrroga en fecha lmite de entrega. el

Se Solicitar apoyo a efecta la Institucin o el al Instituto control peridic una o del en cronogr activida des acadmico mediante prrroga entrega. Aceptacin segn Costo/Beneficio fecha entregable.

Manejo reportes peridicos

de

tiempo perdido por las

2 das antes de la de cada una de de para determinar el porcentaje de retraso. las presentacin del actividades

fecha lmite de ama de

2.9.4 Planes de Contingencia de Riesgos

Riesgo:1 Referencia: Plan de Tratamiento de Riesgos Riesgo: Fecha lmite de la presentacin de entregables prxima. Resumen: Solicitar apoyo a la Institucin o Instituto Acadmico mediante una prrroga en fecha lmite de entrega. Se efecta el control peridico del cronograma de actividades para determinar niveles de retraso y anticiparse a la disminucin de los mismos. Plan de Accin Acciones Propuestas Se Manejaran reportes peridicos de cada una de las actividades para determinar el porcentaje de retraso, en los cuales cada rea involucrada deber informar sobre su avance, sobre retrasos si existen, el motivo de los mismos, y las medidas a tomar para corregir los mismos, con la finalidad de evitar que el Plan de trabajo del proyecto quede obsoleto. 1. Requerimientos de Recursos La solicitud de recursos depende de los reportes de avances, si fuera el caso se solicitara solo los recursos necesarios para minimizar el retraso. 2. Fecha La implantacin de los planes de accin establecidos para este riesgo, se realizaran 2 das antes de la fecha de presentacin del entregable. 3. Monitoreo El monitoreo es realizado de acuerdo a Reportes de Avances.

Anlisis y Diseo 3.1 Documento de Arquitectura del Software DAS Es una especificacin de las ideas principales del diseo. El DAS proporciona una descripcin entendible de la arquitectura del sistema software y sirve como medio de comunicacin entre el arquitecto de software y otros miembros de equipo del proyecto con respecto a las decisiones arquitectnicamente significativas que se han tomado en el proyecto. Contiene varias vistas que muestran aspectos distintos del sistema como son:

Vista de Casos de Uso: Esta vista muestra la funcionalidad del sistema como es percibida desde el exterior. As como tambin describe un conjunto de escenarios y casos de uso que tienen una cobertura arquitectnicamente significativa o que ilustran un punto especfico de la arquitectura. Vista Lgica: Describe el diseo ms importante de las clases y su organizacin en paquetes y subsistemas, y la organizacin de stos en capas. Tambin contiene algunas realizaciones de casos de uso. Esta muestra cmo la funcionalidad es diseada en el interior del sistema, en trminos de la estructura esttica y comportamiento dinmico del sistema
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Vista de Implementacin: Esta vista muestra la organizacin del cdigo y el cdigo actual de ejecucin. Contiene una visin general del Modelo de Implementacin y su organizacin en trminos de mdulos en paquetes y capas. Tambin se describe la asignacin de paquetes y clases de la Vista Lgica a los paquetes y mdulos de la Vista de Implementacin. Vista de Implantacin: Describe varios nodos fsicos para las configuraciones ms tpicas de las plataformas y la asignacin de las tareas de la Vista del Proceso a los nodos fsicos. Es un subconjunto del Modelo de Implantacin. Esta vista se realiza slo si el sistema es distribuido a travs de ms de un nodo, por lo tanto es opcional. Vista de Datos: Esta vista especifica arquitectnicamente los elementos constantes en el Modelo de Datos. Describe una apreciacin global del modelo de los datos y su organizacin por lo que se refiere a las tablas, vistas y almacenamiento de los procedimientos que proporcionan la persistencia al sistema. Tambin describe la cartografa de clases constantes de la Vista Lgica a la estructura de los datos de la base de datos.

3.2 Modelo de Diseo Para representar los diagramas del Modelo de Diseo se pueden emplear diferentes diagramas de UML tales como: Diagramas de Clase. Diagramas de Colaboracin. Diagramas de Estado. Diagramas de Secuencia. 3.3 Mapa de de navegacin o Carta Estructurada Este artefacto expresa la estructura de los elementos de la interfaz de usuario del sistema, junto a los caminos de navegacin principales. Este permite al usuario una adecuada navegacin en el sistema y sobre todo saber en qu punto del sistema se encuentra y hacia donde puede ir. Sin un Mapa de Navegacin no se podra aprovechar al mximo un sistema. Cabe destacar que existir solamente uno de estos artefactos en el sistema. 3.4 Modelo de Datos MODELO E_R MODELO de la base de datos Diccionario de Datos 3.5 Realizaciones de los Casos de Uso Son los diagramas de secuencia que expresan el comportamiento del caso del uso en trminos de objetos de colaboracin 3.6 Modelo de Implantacin Diagramas de componentes y diagramas de despliegue 4 Implementacin 4.1 Componente Operacional del Sistema Este artefacto es una versin operacional del sistema o parte de este que cubre un subconjunto especificado de los requerimientos que el sistema final cumplir. Este comprende uno o ms elementos de la aplicacin (funciones ejecutables) que son creados de otros elementos mediante un proceso de compilacin y unin del cdigo fuente. Agrupa un conjunto de Subsistemas de Implementacin. Cabe destacar que cada una de las funciones y capacidades que representan una parte del sistema pueden ser probadas durante su ejecucin.
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

4.2 Modelo de Implementacin: En esta actividad se propone una estructura para implementacin, con el fin de conseguir facilitar implementacin, integracin y desarrollo de los procesos.

la la

Elemento de Implementacin El elemento de implementacin es un artefacto que representa el ms bajo nivel de composicin de un componente de software, es decir, un conjunto de elementos de implementacin son los que conforman a un componente del sistema. Este artefacto puede ser un cdigo fuente, un cdigo binario, un archivo, un ejecutable, entre otros. Subsistema de Implementacin Esta actividad integra los cambios de los desarrolladores para crear una nueva versin consistente de la implementacin de un subsistema. Plan de Integracin Esta actividad se planifica la integracin del sistema para la iteracin en curso.

PARTE IV PRUEBAS E IMPLANTACIN DEL DISEO TECNOLGICO 1. Plan de Pruebas (ver documento de Plan de Pruebas) Este artefacto define un conjunto de datos de entradas, condiciones de ejecucin y resultados esperados de las pruebas, identificados para hacer una evaluacin de los aspectos especficos de un elemento objeto de prueba. Cada Caso de de Prueba est asociado a un escenario de un Caso de Uso en particular.
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Los casos de prueba deben ser escritos con el detalle suficiente para que el probador pueda empezar rpidamente a ejecutar pruebas y a encontrar defectos. Adems, estos reflejan trazabilidad con los casos de uso, las especificaciones suplementarias de requerimientos y diseo del sistema, garantizando que los procedimientos de pruebas sean compatibles con las necesidades de los usuarios/clientes. En la metodologa los Casos de Uso dirigen todo el proceso de desarrollo, es por ello que los Casos de Uso se transforman en un activo que puede directamente conducir el proceso de pruebas. Un Caso de Prueba no es igual a un Caso de Uso. El Caso de Prueba extiende o ampla la informacin contenida en un Caso de Uso. Entre las actividades a realizar se encuentran, trabaje con las que estn dentro de los parmetros de su proyecto: Acordar la Misin de las Pruebas Acordar las Pruebas a Realizar Analizar Pruebas Fallidas Definir Criterios de Aceptacin de los Casos de Prueba Definir el Enfoque de Pruebas Definir los Detalles de las Pruebas Determinar los Resultados de las Pruebas Ejecutar el Conjunto de Pruebas Establecer la Configuracin del Ambiente de Pruebas 8. Evaluar y Defender la Calidad 9. Evaluar y Mejorar el Esfuerzo de las Pruebas 10. Identificar la Misin de las Pruebas 1 11. Identificar las Ideas de Pruebas 12. Identificar los Motivadores de las Pruebas 13. Identificar los Objetos de Pruebas 14. Implementar las Pruebas 15. Preparar los Lineamientos del Proyecto 1. 2. 3. 4. 5. 6. 7. 2. Implantacin El Sistema Este artefacto es el producto final, es decir, el sistema ya funcionando que puede ser instalado y ser utilizado por el cliente. Un Sistema se diferencia de una unidad de implantacin, ya que el sistema puede contener varias unidades de implantacin. Cabe destacar que dichas unidades de implantacin que rene el sistema pueden ser exportadas a una unidad de almacenamiento. Lista de Materiales Este artefacto lista los componentes de una versin dada de un producto y define donde los componentes fsicos pueden ser encontrados. Adems, describe los cambios realizados en la versin y se refiere a la forma en que el producto puede ser instalad Artefactos de Instalacin Este artefacto tiene como objetivo permitir que la instalacin del sistema sea llevado a cabo por alguien. Se basa en los programas e instrucciones documentadas requeridas para que ese alguien instale el producto. Puede incluir: instrucciones, scripts, iconos, archivos de licencia, etc. Los Artefactos de Instalacin son necesarios cuando se quiere configurar el sistema mediante los programas de instalacin y pueden ser descartados si el sistema es instalado una vez, ya sea porque el sistema es de uso interno en un servidor corporativo. Las instrucciones de instalacin se reflejan en el Manual de Instalacin y si se espera que el usuario instale el producto (sistema) puede reflejarse en el
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Manual de Usuario. Este artefacto provee una ayuda a las personas que manipularn directamente el producto, acerca del uso que le debe dar al sistema. Dicho artefacto debe ser discutido y aprobado por el cliente. Elaborar el manual de usuario durante las primeras iteraciones del proyecto permitir al equipo de probadores conocer el sistema antes de que comiencen las pruebas, adicionalmente provee los mecanismos bsicos para elaborar los planes de pruebas y los casos de pruebas, y permite la elaboracin de sistemas automatizados para las pruebas. Segn el tipo de sistema se define el comienzo del desarrollo del Manual de Usuario. Sistemas con interfaces complejas o con mucha interaccin requerirn versiones tempranas del manual de usuario as como de prototipos de interfaces. Sistemas con poca interaccin probablemente no requieran que la documentacin del usuario se elabore muy temprano. Manual de Instalacin (ver documento de manual de Instalacin) El manual de instalacin es un artefacto que refleja los lineamientos que hay que seguir para instalar el sistema. Contiene informacin sobre la infraestructura de instalacin e instrucciones para la instalacin y actualizacin del software. Material de Adiestramiento El propsito del Material de Adiestramiento, dependiendo de los requerimientos del proyecto, es ensear a los usuarios cmo utilizar, operar o mantener el producto. Este material se piensa para el uso en cursos de aprendizaje. Mecanismo de Retroalimentacin Este artefacto provee un mecanismo para captar los comentarios de los clientes al probar el producto beta, tiene como fin de que los usuarios hagan pruebas al sistema sobre el conjunto de caractersticas disponibles y en lo posible, retroalimentar a sus desarrolladores con el descubrimiento de fallos y haciendo sugerencias en cuanto a la funcionalidad, etc. Plan de Adiestramiento Muestra el plan detallado de adiestramiento. El propsito de este plan es que las personas que vayan a utilizar el sistema, se capaciten para su utilizacin evitando que el mismo sea mal utilizado. Dicho artefacto debe ser discutido y aprobado por el cliente. Este artefacto est compuesto por secciones para indicar el programa de entrenamiento o cursos que sern impartidos a los usuarios finales para ensearles el uso, operacin y mantenimiento del sistema.

Plan de Implantacin El objetivo principal de este artefacto es asegurar que el sistema llegue satisfactoriamente al conjunto de usuarios para el cual fue destinado. Este artefacto debe definir un conjunto de tareas que defina una transicin sencilla para el cliente, para ello se debe minimizar el impacto que la implantacin del sistema pueda llegar a causar en el personal del cliente, los sistemas de produccin existentes y en todas las rutinas del negocio.
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Este artefacto describe el conjunto de tareas necesarias para poder poner en funcionamiento el sistema en las instalaciones de los usuarios. Las actividades descritas en este documento abarcan temas referentes a la instalacin del nuevo sistema, instrucciones especficas sobre la sustitucin de antiguos sistemas, compatibilidad del sistema, y estrategias de migracin y adaptacin al nuevo sistema. Adicionalmente este artefacto describe en detalle las actividades correspondientes a la entrega del producto, el cronograma de actividades, personal responsable, los recursos y fuentes necesarias para el funcionamiento del nuevo sistema, plan de adiestramiento, notas de seguridad, de procedimientos operacionales especficos, entre otros.

FUENTE ORIGINAL DE LOS ARTEFACTOS http://merinde.net/index.php?option=com_frontpage&Itemid=1

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011