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

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

Caso de Uso Asignacin de Arma e Implementos

Nombre/ID: R01
Descripcin: 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.
Requerimiento: Solicitud de arma e implementos, Arma o implemento disponible
Precondiciones: Que haya arma e implementos disponible, que el solicitante est registrado y no
tenga ninguna condicin que niegue su solicitud
Flujo Normal:
Actor Respuesta de negocio
1.- El funcionario solicita el arma o 2.El parquero procede a verificar el credencial del funcionario en
implementos entregando al parquero su el listado de funcionarios adscritos y su ubicacin
credencia.
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

parquero respectivo chequeo y para la firma.

8.- El funcionario recibe el arma o 7.- Si el formato esta bien procesado , el parquero le entrega el
implemento. arma o implemento
Si el formato esta mal procesado, el parquero lo recibe para
10.-El funcionario recibe el credencial corregirlo, pasar a la lnea 3

9.-El parquero entrega el credencial al funcionario

Flujo Alterno:

Actor Respuesta de negocio

En la lnea 2 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
En la lnea 7
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
condici
ones:
Requer N/A
imiento
s
Especia
les:

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)

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.
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011
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 LO
ENTRADAS DESCRIPCION GENERAL DEL PROCESO SALIDAS 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 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
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011
 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
Redactar objetivo general y especficos del Proyecto (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 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
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011
 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:

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
O Media Baja O Baja

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
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011
 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.

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)
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011
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 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.

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

 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 FASES
DISCIPLINA ARTEFACTO I E C T
Documento de Arquitectura del Negocio
Evaluacin de la Organizacin Objetivo
Visin del Negocio
Modelo de Anlisis del Negocio
Entidad del Negocio
MODELADO Trabajador del Negocio
DEL NEGOCIO Reglas del Negocio
Modelo de Caso de Uso del Negocio
Modelo de Diseo del Negocio
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 del
proyecto Muy Bajo (5%) Bajo (10%) Moderado (20%) Alto (40%) Muy Alto (80%)

Costos Incremento Incremento en costo Incremento en costos Incremento en costos Incrementos en costos
insignificante en < 10%. Nuevo entre 10-20%. entre 20-40%. >40%. Incrementos no
costos, aun pueden Anlisis de Replanteo de los Suspensin temporal pueden ser cubiertos en
ser cubiertos. Asignacin de procesos del proyecto. del desarrollo del su totalidad. Proyecto
Recursos del proyecto. finaliza.
Proyecto.
Tiempo Insignificante, no Retraso <10%. Retraso global entre Retraso global entre 20- Retraso global >40%.
afecta la Posibilidad de 10-20%. Aumento de 40%. Aumento de Suspensin de las
asignacin de aumento del tiempo los tiempos de las tiempo de tareas en 20- actividades del proyecto.
tiempos. asignado. tareas en 10-20%. 40%

Alcance Reduccin Alcance afectado de reas mayores de Reduccin de alcance No se puede llegar a
escasamente manera mnima. alcance afectadas. inaceptado por la cumplir con el alcance
apreciable. No Institucin. del proyecto. Fin del
afecta al alcance proyecto.
planteado.
Calidad Degradacin Se afectan Posible reduccin de Menor calidad por Cierre de proyecto
escasamente aplicaciones calidad por replanteo desarrollo acelerado debido al
aceptable. No exigentes por escasez de tareas y tiempos. (reduccin de mdulos) incumplimiento de
afecta el de recursos. estndares y normativas
desempeo del de calidad.
proyecto.

Prioridades Establecidas para los Riesgos:

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011
 Prioridad de Riesgo Descripcin
1 Alta
2 Moderada
3 Bajo
4 Muy Bajo

2.9.2 Gestin de Riesgos del Proyecto

Riesgo que Aptitud de los controles
Las Puntaje Nivel
puede sucede existentes Prioridad
Id consecuencias de e de
y como puede de riesgo
suceder un evento consecuencias Probabilidad Probabilidad riesgo
suceder

2.9.3 Plan de Tratamiento de los Riesgos

Contro Aceptacin o Monitoreo
Opcin de
Riesgos en orden Posible tratamiento de los les rechazo segn Fecha de de riesgos y
Riesgo tratamiento
de prioridades riesgos existent anlisis implementacin opciones de
elegida
es Costo/beneficio tratamiento

Trabajar tiempo
Se Manejo de
extra.
Solicitar apoyo a efecta reportes
Recuperar el
la Institucin o el peridicos
tiempo perdido por las
Fecha limite de la al Instituto control 2 das antes de la de cada una
noches. Aceptacin
presentacin de acadmico peridic fecha de de las
1 Solicitar apoyo segn
entregables mediante una o del presentacin del actividades
a la Institucin o al Costo/Beneficio
prxima. prrroga en cronogr entregable. para
Instituto acadmico
fecha lmite de ama de determinar
mediante una prrroga
entrega. activida el porcentaje
en fecha lmite de
des de retraso.
entrega.

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.

3 Anlisis y Diseo

3.1 Documento de Arquitectura del Software DAS

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

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

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

 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.

4.2 Modelo de Implementacin:

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

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)

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011

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.

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:

1. Acordar la Misin de las Pruebas

2. Acordar las Pruebas a Realizar
3. Analizar Pruebas Fallidas
4. Definir Criterios de Aceptacin de los Casos de Prueba
5. Definir el Enfoque de Pruebas
6. Definir los Detalles de las Pruebas
7. 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

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.

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
MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011
 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