proyecto sosciotecnologico iv esquema del informe completo

5/10/2018 Proyecto Sosciotecnologico IV Esquema Del Informe Completo - slidepdf.com

http://slidepdf.com/reader/full/proyecto-sosciotecnologico-iv-esquema-del-informe-completo 1/17

INFORME TÈCNICO PARA PRESENTAR PROYECTO

SOCIOTECNOLÒGICO IV

ADAPTADO A GESTIÓN DE PROYECTOS, ENFOQUE DEL MARCO

LÓGICO Y PROCESO DE DESARROLLO ME RINDE

PARTE I

PLANIFICACIÓN DEL PROYECTO SOCIOTECNOLÓGICO

1. PLANIFICACIÓN DEL PROYECTO1.1. Conformación de equipos preliminares de trabajo

• Planeadores

• Elaboradores de instrumentos

• Validadores de Instrumentos

• Aplicadores de instrumentos

1.2. Planeación de las fases a abordar para la ejecución del

Proyecto

Realizar un diagrama Pert-CPM o Diagrama de Gantt, donde

se observe:

1. Diagnóstico situacional o Abordaje a la comunidad para

relevar la situación actual, en la que se buscaba

encontrar síntomas que reflejarán la posibilidad de

encontrar debilidades o problemas. Esta fase va desde la

planeación del diagnóstico y culmina con la Propuesta desolución del problema.

2. Planeación de la propuesta

Esta fase comprende la fase de planificación del proyecto

de desarrollo de software, por lo tanto debemos utilizar el

artefacto de planificación que nos ofrece Me Rinde, sólo

se hará en la parte 3 del informe técnico aquí solo se

menciona.3. Diseño de la propuesta

4. Construcción o elaboración de la propuesta

5. Pruebas y optimización

6. Entrega del proyecto de software

MATERIAL ELABORADO POR CLAUDIA INOSTROZA VR-01 MAYO 2011



PARTE II

LA COMUNIDAD/ORGANIZACIÓN

1. DIAGNÓSTICO SITUACIONAL

1.1 Descripción de la Comunidad y su Contexto:

Identificación de la Organización

Nombre

Misión

Visión

Objetivos generalesObjetivos Específicos

Objetivos estratégicos

Localización Geográfica (Estado, Municipio, Parroquia, Caserío

y Dirección).

Historia de Vida de la Organización (Reseña histórica).

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 mejorentendimiento de la organización o parte de ella, donde se va aimplantar la aplicación de software. Los objetivos específicosde la disciplina modelado de negocio son:• Asegurar que clientes, usuarios finales y desarrolladorestengan un entendimiento común de la organización objetivo.• Derivar los requerimientos del sistema necesarios para

apoyar a la organización objetivo en su mejora.• Entender el problema actual en la organización objetivo eidentificar potenciales mejoras.• Entender la estructura y la dinámica de la organización parala cual el sistema va a ser desarrollado (organización objetivo).

1.2.1 DAN

Detallar las vistas que se usarán para representar la arquitectura e indicar losinvolucrados aplicables a cada vista, describir los tipos de elementos que contienecada vista.

Vista de la Organización:

Organigrama estructural

Organigrama Funcional de la organización

Organigrama de cargos

Nombre de la o las Unidades Funcionales en estudio:

Vista de Procesos del Negocio: (esta se hará por cadaunidad funcional)

Esta vista incluye los procesos claves del negocio. La Vistade Procesos representa los casos de uso del negocio mediante




un diagrama que refleja la relación existente entre los actoresdel negocio y los casos de uso del negocio.Mostrar los casos de uso del negocio significantes. Incluir un diagrama que muestreestos casos de uso del negocio en relación a los actores del negocio y proporcionar ladescripción o flujo de eventos de cada uno de los casos de uso del negocio.Arquitectónicamente los casos de uso del negocio significantes son esos queproporcionan un alcance funcional extenso y/o ejercen una parte crítica del negocio.

FORMATO PARA FLUJOS DE EVENTOS DE LOS CASOS DE USOS

1.2.2 Evaluación de la Organización Objetivo, EOO (esta se hará

por cada unidad funcional)


Caso de Uso – Asignación de Arma e Implementos

Nombre/ID: R01

Descripción: El caso de uso se inicia cuando el funcionario solicita la asignación del arma oimplementos. 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 implementoal 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 tenganinguna condición que niegue su solicitud

Flujo Normal:

Actor Respuesta de negocio

1.- El funcionario solicita el arma oimplementos entregando al parquero sucredencia.

5. El funcionario verifica los datos en elformato de asignación procesado por el

parquero.

6. El funcionario devuelve el formato al

parquero

8.- El funcionario recibe el arma oimplemento.

10.-El funcionario recibe el credencial

2.El parquero procede a verificar el credencial del funcionario enel listado de funcionarios adscritos y su ubicación

3.Si el Funcionario existe el parquero llena el formato deasignación con los datos personales del funcionario y los datos delarma o implemento a entregar

Si el Funcionario no existe pasar a la línea 9

4.- El parquero entrega el formato al funcionario para su respectivo

chequeo y para la firma.

7.- Si el formato esta bien procesado , el parquero le entrega elarma o implemento

Si el formato esta mal procesado, el parquero lo recibe paracorregirlo, pasar a la línea 3

9.-El parquero entrega el credencial al funcionario

Flujo Alterno:

Actor Respuesta de negocio

En la línea 2

En la línea 7

Si el funcionario está adscrito a la comisaria- Si el funcionario está adscrito, el parquero le procesa laentrega- Si el funcionario no está adscrito, el parquero no procesala entrega

Si el formato de asignación está bien procesado:• Si es esta bien los datos, el funcionario procede afirmar el formato de asignación• Si no están bien los datos, el funcionario se niega afirmar el formato de asignación y lo devuelve al parquero

Pos

condicio

nes:

El Parquero queda disponible para procesar otra solicitud, inventario de armas actualizado

Requeri

mientos

Especial

es:

N/A



Este artefacto describe la situación actual en que se encuentrala organización objetivo, es decir, la organización en la que elsistema será implantado. La descripción está en términos deprocesos actuales, herramientas, competencias entrepersonas, actitudes de las personas, clientes, competidores,tendencias técnicas, problemas y áreas de mejora.El EOO también es usado para crear motivación y comprensiónentre las personas en la organización objetivo que sondirectamente o indirectamente afectadas, así como también

explicar al involucrado por qué existe la necesidad de cambiarlos procesos del negocio, y además proporcionar la entrada alMarco de Desarrollo y al Plan de Iteración.

Descripción de los procesos que se realizan en la o las

unidades funcionales

Unidad Funcional: XXXXXXXXXXNombre del proceso: DEBE SER UN VERBO

ENTRADAS DESCRIPCION GENERAL DEL

PROCESO

SALIDAS

TRABAJADOR QUE

LO EJECUTA

1.2.3 Modelo de Análisis del Negocio (esta se hará por cadaunidad funcional)

Este modelo es interno al negocio, describe la realización delos casos de uso del negocio, para lo cual detalla cómo cadacaso de uso de negocio es llevado a cabo por un grupo detrabajadores u sistemas que emplean entidades del negocio yunidades de trabajo recíprocamente. A diferencia del Modelode Casos de Uso del Negocio el cual describe qué pasa entre elnegocio y los actores de negocio, el Modelo de Análisis definelos trabajadores internos de negocio y la información que ellosemplean (entidades de negocio). Describe su organizaciónestructural en unidades independientes (sistema de negocio) yprecisa cómo ellos interactúan para ejecutar el

comportamiento señalado en los casos de uso de negocio.El Modelo de Análisis del Negocio puede contener: losdiagramas, trabajadores, sistemas, entidades, reglas, lasrelaciones, colaboraciones, entre otros elementos del negocio.Para representar los diagramas del Modelo de Análisis delNegocio se pueden emplear diferentes diagramas de UML talescomo:• Diagramas de Colaboración.• Diagramas de Secuencia.• Diagramas de Actividad yo recomiendo este• Diagramas de Estado.

ANEXOS

1 Realizaciones de los Casos de Uso del NegocioEste artefacto expresa la colaboración de los sistemas delnegocio, los trabajadores del negocio, las entidades delnegocio, y los eventos del negocio para realizar un caso de usodel negocio particular. Mientras que un caso de uso del negociodescribe los pasos que se deben realizar para aportar valor aun actor del negocio, una realización de casos de uso delnegocio describe la manera en que estos pasos se realizandentro de la organización. Además, las Realizaciones de losCasos de uso del Negocio son utilizadas por los involucrados




para verificar que el equipo del proyecto y demás involucradosentienden la estructura y el funcionamiento del negocio.

Entidad del NegocioEste artefacto representa una pieza de informaciónsignificativa que es manipulada por los actores y trabajadoresdel negocio. Se refiere al estado de la información que pasaráentre cada capa como un conjunto de datos que la identificanuna entidad. Las entidades del negocio de una aplicaciónrepresenta entidades reales y además suelen ser sustantivos,

como por ejemplo: Cliente, Nómina, Factura,Depósito, etc. Asimismo, las entidades de negocio son la basepara compartir documentos entre los trabajadores del negocioy estas pueden ser utilizadas en diversas Realizaciones de losCasos de Uso del Negocio.2 Reglas del NegocioUna Regla del Negocio es la declaración de políticas yrestricciones de negocio de una organización. Este artefactoconsiste en definir una exigencia específica o invariable quedebe satisfacerse por el negocio. Las Reglas del Negociopueden aplicarse siempre o sólo bajo una condición específica.Es necesario que la aplicación muestre las restricciones queexisten en el negocio, de tal forma que no sea posible realizaracciones inválidas.3 Trabajador del NegocioUn Trabajador del Negocio representa a un ser humano,software o hardware que desempeña un rol dentro de lasRealizaciones del Caso de Uso del Negocio. Este trabajadorinteractúa con entidades y otros trabajadores para que elnegocio funcione. Los trabajadores de negocio son roles y noposiciones organizacionales, ya que una persona puededesempeñar varios roles pero sólo tiene una posición en laOrganización. Esta Conceptualización permite identificarmejoras en los procesos del negocio y considerar el efecto dela automatización del proceso del negocio o del outsourcing deproceso del negocio.

1.3 Descripción del diagnóstico situacional de la o las unidades

funcionales en estudio (Formulación del problema).

1.3.1Árbol del Problema

2.- OBJETIVOS DEL PROYECTO (General y Específicos).

2.1 Árbol de Objetivos

Redactar objetivo general y específicos del Proyecto

(importante señalar que el objetivo del proyecto es diferente

al objetivo del Software a desarrollar)

2.2 Propuesta de solución (aquí se plantea el desarrollo de

alguna solución informática que permitirá logar los

objetivos del proyecto)

Visión del Sistema

Este artefacto describe los objetivos principales del proyecto,funcionalidades y restricciones en forma concisa; es unresumen del proyecto apto para la toma de decisiones,ofrece una descripción del sistema a ser desarrollado desdela perspectiva de los requerimientos más importantes. Estedocumento captura las expectativas de los que soportan eldesarrollo del proyecto.Se recomienda que este artefacto se conserve lo más claro yresumido posible para que pueda llegar lo más prontoposible a los involucrados en el proyecto y para que sea más




fácil de entender por estos. Este documento debe incluirsolamente las principales descripciones de losrequerimientos y debe evitar muchos detalles específicos.Adicionalmente debe especificar las capacidadesoperacionales (volúmenes de trabajo, tiempos derespuestas, precisión), perfiles de usuario, y los límites delsistema.

Modelo de Casos de Uso (este se deriva del diagrama deactividades del CUN, actividades a computarizar)

Este artefacto se basa en la descripción de elementos ousuarios externos al sistema (actores) y de la funcionalidaddel sistema (casos de uso). Un Modelo de Casos de Usodescribe los requerimientos funcionales de un actor (usuario,sistema, dispositivo, etc.) en términos de las interaccionesque éste ejecuta con el sistema. El modelado de casos deuso es una técnica efectiva y a la vez simple para modelarlos requerimientos del sistema desde la perspectiva del

usuario. Presenta el sistema desde la perspectiva de su usoy esquematiza como proporcionará valor a sus usuarios. Elmodelo de casos de uso sirve como acuerdo entre clientes ydesarrolladores para limitar las funciones con que dispondráel sistema luego de ser implementado, además proporcionala entrada fundamental para el análisis, el diseño, laimplementación y las pruebas. Cabe recordar que MeRindeestá dirigido por casos de uso, de aquí la importancia de estemodelo. Este modelo está formado por los diagramas decasos de uso y las narrativas de los casos de uso. Pararepresentar 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 PARACADA CUS

2.3 Especificación de Requerimientos del Software (ERS)

El objetivo de este artefacto es documentar todos losrequerimientos del sistema, este describe las funciones delsistema, los requerimientos no funcionales, características deldiseño, y otros elementos necesarios para proporcionar unadescripción completa y comprensiva de los requerimientos

para el software a desarrollar. Los requerimientos pueden serlevantados con diferentes herramientas, también se puedenencontrar dispersos en varios artefactos y herramientas. Es porello, que esta metodología propone capturar todos losrequerimientos para el ERS en un solo artefacto, el cual estáconformado por dos (2) artefactos que describen losrequerimientos que son: Modelo de Casos de Uso yEspecificaciones Suplementarias. El artefacto ERS controla laevolución del sistema durante toda el ciclo de desarrollo delproyecto, cuando las nuevas características son añadidas omodificadas al artefacto de visión, son aclarados dentro del

artefacto ERS. Las decisiones hechas escribiendo el ERS estánbasadas en información de los documentos de la propuesta delproyecto y en requerimientos del usuario. El conjunto derequerimientos especificados en el ERS deben ser satisfechosen el diseño del sistema. Cualquier requerimiento funcional ono funcional que no sea identificado en el ERS, no debeaparecer en el producto final.

2.3.1 Requerimientos Funcionales

ID del

Requerimiento:RF-01




Nombre del

Requerimiento: Asignación de Implementos

Características: Datos que describen o identifican los diferentesimplementos asignados al Departamento.

Descripción del

requerimiento:

Se debe almacenar: Nombre, descripción, tipo,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. Losrequerimientos no funcionales tienen que ver con las características que de una uotra forma puedan limitar el sistema como son: el rendimiento (en tiempo yespacio), confiabilidad, interfaces, fiabilidad (robustez del sistema, disponibilidad deequipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Usabilidad

En este apartado se debe incluir la lista de todos los requerimientos que afecten lausabilidad. Esto debe incluir: el tiempo que se tomará un usuario en aprender autilizar el sistema y se podría explicar por qué debe ser rápido el aprendizaje, lostiempos medibles de tarea para las tareas típicas y los requerimientos paraconcordar con estándares.

Confiabilidad

Aquí se deben detallar los requerimientos de confiabilidad del sistema. Describa lascaracterísticas de confiabilidad explicando la posibilidad del sistema de realizar lasfunciones para las que fue diseñado sin presentar fallos. Entre estos

requerimientos puede mencionar características como la disponibilidad, elporcentaje de fallas máximo, etc.

Seguridad

Aquí se deben detallar los requerimientos de seguridad del sistema. Esto incluye siel acceso al sistema será controlado con nombres de usuario y contraseñas, quesolo los usuarios con privilegios de administrador podrán acceder a las funcionesadministrativas y los usuarios normales no podrán.

Eficiencia

En este apartado se debe ver reflejado las características de eficiencia del sistema.

Se debe especificar: el tiempo de respuesta para una transacción (promedio),capacidad (número de clientes y transacciones), rendimiento del procesamiento(Ej. transacciones por segundo) y cuando el sistema se ha degradado cuál es elmodo aceptable de operación.

Mantenimiento y Actualización

En este apartado se debe ver reflejado los requerimientos de mantenimiento yactualización. La capacidad de mantenimiento es la habilidad que se tiene pararealizar cambios al producto en el tiempo y la capacidad de actualización es lahabilidad que se tiene para entregar las versiones del producto a bajo costo a losclientes con un mínimo de tiempo de descarga. Una característica clave paraapoyar este objetivo es la descarga automática de parches o actualizaciones y

actualizaciones del equipo del usuario final. También debemos utilizar formatospara archivos de datos que incluyan suficientes metadatos para permitirnostrasformar con seguridad la información existente del usuario durante unaactualización.

Soportabilidad y Operabilidad

Especificar los requerimientos de soportabilidad y operabilidad del sistema. Lasoportabilidad la habilidad de proveer soporte técnico eficiente y a buen precio y laoperabilidad es la habilidad que se tiene de hospedar y operar el software como unASP (Proveedor de Servicios de Aplicaciones).

Restricción de Diseño

En este apartado se debe indicar cualquier limitación de diseño en el sistema quees construido. Por ejemplo: lenguajes de software, requerimientos del proceso desoftware, uso de herramientas de desarrollo, componentes comprados, etc.




Requerimientos de Documentación en Línea y de Sistemas de Ayuda

En caso de que exista se debe describir los requerimientos, para la documentaciónen línea 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. Contienetanto requerimientos funcionales como no funcionales delsistema. Los requerimientos que deben considerarse paraeste artefacto son los siguientes: usabilidad, confiabilidad,desempeño, mantenibilidad, seguridad, restricciones dediseño, requerimientos de documentación en línea y desistemas 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 términos ahacer utilizados durante la realización del proyecto, quedeben ser comprendidos por los participantes de tal maneraque haya una buena comunicación y evitar interpretacionesdispares o ambiguas de los términos del dominio delproblema. Documentar las definiciones de términos yacrónimos ayuda a otros artefactosa ser más concisos y precisos. En algunos proyectos dondela planeación del negocio y del dominio no se realiza, elGlosario es el artefacto principal para capturar la información

sobre el dominio de negocio del proyecto.

3.- JUSTIFICACIÓN E IMPACTO SOCIAL DE LA PROPUESTA

Teórico, técnico, legal.

Población Beneficiada.

Impacto Social (Plan Simón Bolívar)

4.- ESTUDIO DE FACTIBILIDAD DE LA PROPUESTA (Legal, social,organizacional operativa, técnica y económica).

5. ANTECEDENTES TECNOLÓGICOS

6. BASES TEÓRICAS




PARTE III

ANÁLISIS, DISEÑO, DESARROLLO E IMPLEMENTACIÓN DELDISEÑO TECNOLÓGICO

1. Metodología a utilizar Me Rinde, definir aspectos relevantes que caracterizan a

la metodología

2. Planificación del Proyecto de software2.1 Objetivo

Se refiere a los objetivos del software2.2 Alcance

2.3 Características y BeneficiosEjemplo:• Una aplicación para Web reutilizable con funcionalidad paracrear, editar, borrar, buscar, categorizar, navegar, calificar ycomentar clientes. Esto automatiza todos las operaciones de los

clientes y asegura que los usuarios podrán encontrar siempreinformación que de forma automática se encuentre actualizada.• La aplicación del sitio deberá tener una apariencia altamenteconfigurable que le permita ajustarse a la apariencia y carácter del




cliente. Esto permite reutilizar la aplicación del sitio para quetenga una apariencia de alta calidad que pueda ser muy buena.• La aplicación del sitio deberá ser segura y solo permitir usuarioscon los permisos adecuados para editar, borrar o añadir otrosusuarios al sistema. Esto para prevenir trampas o la publicación deinformación falsa.

2.4 Suposiciones y LimitacionesDescribir todas las suposiciones que se realizan sobre el proyecto

y se declaran las restricciones impuestas tales como restriccionesde personal, temporales, de hardware, de software, etc.

2.5 Organización de los Equipos de TrabajoEn este apartado se realiza la descripción de la organización de losequipos del proyecto. Se debe reflejar en qué consistirá cadaequipo.Ver los roles que define Me rinde

a. Analista de Calidad.b. Analista de Producto.

c. Arquitecto de Software.d. Desarrollador.e. Involucrado.f. Líder del Proyecto.g. Mentor.h. Probador.

2.6 Herramientas de Desarrollo y ColaboraciónAquí se especifican las herramientas que se planean usar demanera intensiva durante el desarrollo del proyecto. Esasherramientas pueden ser : listas de correo del proyecto, sitio Webdel proyecto, sistema de control de cambios, sistemaautomatizado de compilación, sistema de control de versiones,sistema automatizado para unidad de pruebas, etc.

2.7 Calendario del proyectoSe debe incluir un calendario de las principales actividades delproyecto.

2.8 Matriz de componentes a desarrollar (ver matriz derelación de disciplinas y componentes pág. 66)

Ejemplo…COMPONENTES FASES

DISCIPLINA ARTEFACTO I E C T

MODELADODEL

NEGOCIO

Documento de Arquitecturadel NegocioEvaluación de la OrganizaciónObjetivoVisión del NegocioModelo de Análisis del NegocioEntidad del Negocio

Trabajador del NegocioReglas del NegocioModelo de Caso de Uso del NegocioModelo de Diseño del Negocio




Realizaciones de los Casos de Uso delNegocioModelo de Implantación del NegocioPrueba de Concepto Arquitectónico delNegocio

2.9 Manejo de RiesgosEnumerar y agrupar los mayores riesgos para este proyecto, y quese planea hacer para resolver o prevenir cada riesgo. En el caso deque no se vaya a hacer nada para mitigar el riesgo debemencionarlo.

2.9.1 Plan de Riesgos

Se debe tener en cuenta la siguiente matriz de probabilidades e impacto de losriesgos

Objetivo del

proyectoMuy Bajo (5%) Bajo (10%) Moderado (20%) Alto (40%) Muy Alto (80%)

Costos Incremento

insignificante en

costos, aun pueden

ser cubiertos.

Incremento en costo

< 10%. Nuevo

Análisis de

Asignación de

Recursos del

Proyecto.

Incremento en costos

entre 10-20%.

Replanteo de los

procesos del proyecto.

Incremento en costos

entre 20-40%.

Suspensión temporal

del desarrollo del

proyecto.

Incrementos en costos

>40%. Incrementos no

pueden ser cubiertos en

su totalidad. Proyecto

finaliza.

Tiempo Insignificante, no

afecta la

asignación de

tiempos.

Retraso <10%.

Posibilidad de

aumento del tiempo

asignado.

Retraso global entre

10-20%. Aumento de

los tiempos de las

tareas en 10-20%.

Retraso global entre 20-

40%. Aumento de

tiempo de tareas en 20-

40%

Retraso global >40%.

Suspensión de las

actividades del proyecto.

Alcance Reducción

escasamente

apreciable. Noafecta al alcance

planteado.

Alcance afectado de

manera mínima.

Áreas mayores de

alcance afectadas.

Reducción de alcance

inaceptado por la

Institución.

No se puede llegar a

cumplir con el alcance

del proyecto. Fin del proyecto.

Calidad Degradación

escasamente

aceptable. No

afecta el

desempeño del

proyecto.

Se afectan

aplicaciones

exigentes por escasez

de recursos.

Posible reducción de

calidad por replanteo

de tareas y tiempos.

Menor calidad por

desarrollo acelerado

(reducción de módulos)

Cierre de proyecto

debido al

incumplimiento de

estándares y normativas

de calidad.

Prioridades Establecidas para los Riesgos:

Prioridad de Riesgo Descripción

1 Alta2 Moderada3 Bajo4 Muy Bajo

2.9.2 Gestión de Riesgos del Proyecto

Id

Riesgo que

puede sucede

y como puede

suceder

Lasconsecuencias de

suceder un evento

Aptitud de los controles

existentes Puntajee

Probabilidad

Nivelde

riesgo

Prioridad

de riesgoconsecuencias Probabilidad

2.9.3 Plan de Tratamiento de los Riesgos

RiesgoRiesgos en orden

de prioridades

Posible tratamiento de los

riesgos

Opción de

tratamiento

elegida

Contro

les

existent

es

Aceptación o

rechazo según

análisis

Costo/beneficio

Fecha de

implementación

Monitoreo

de riesgos y

opciones de

tratamiento




1

Fecha limite de la

presentación de

entregables

próxima.

• Trabajar tiempo

extra.

• Recuperar el

tiempo perdido por las

noches.

• Solicitar apoyo

a la Institución o al

Instituto académico

mediante una prórrogaen fecha límite de

entrega.

• Solicitar apoyo a

la Institución o

al Instituto

académico

mediante una

prórroga en

fecha límite de

entrega.

Se

efectúa

el

control

periódic

o del

cronogr

ama de

activida

des

Aceptación

según

Costo/Beneficio

2 días antes de la

fecha de

presentación del

entregable.

Manejo de

reportes

periódicos

de cada una

de las

actividades

para

determinar

el porcentaje

de retraso.

2.9.4 Planes de Contingencia de Riesgos

Riesgo:1 Referencia: Plan de Tratamiento de Riesgos

Riesgo: Fecha límite de la presentación de entregables próxima.Resumen: Solicitar apoyo a la Institución o Instituto Académico mediante una prórroga en fecha límite

de entrega.

Se efectúa el control periódico del cronograma de actividades para determinar niveles de retraso y

anticiparse a la disminución de los mismos.Plan de Acción

Acciones Propuestas

Se Manejaran reportes periódicos 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 implantación de los planes de acción establecidos para este riesgo, se realizaran 2 días antes de la

fecha de presentación del entregable.

3. Monitoreo

El monitoreo es realizado de acuerdo a Reportes de Avances.

3 Análisis y Diseño

3.1 Documento de Arquitectura del Software DAS

Es una especificación de las ideas principales del diseño. El DASproporciona una descripción entendible de la arquitectura delsistema software y sirve como medio de comunicación entre elarquitecto de software y otros miembros de equipo del proyectocon respecto a las decisiones arquitectónicamente significativasque se han tomado en el proyecto. Contiene varias vistas quemuestran aspectos distintos del sistema como son:

• Vista de Casos de Uso: Esta vista muestra la funcionalidaddel sistema como es percibida desde el exterior. Así comotambién describe un conjunto de escenarios y casos de usoque tienen una cobertura arquitectónicamente significativa oque ilustran un punto específico de la arquitectura.

• Vista Lógica: Describe el diseño más importante de lasclases y su organización en paquetes y subsistemas, y laorganización de éstos en capas. También contiene algunasrealizaciones de casos de uso. Esta muestra cómo lafuncionalidad es diseñada en el interior del sistema, en

términos de la estructura estática y comportamientodinámico del sistema




• Vista de Implementación: Esta vista muestra laorganización del código y el código actual de ejecución.Contiene una visión general del Modelo de Implementación ysu organización en términos de módulos en paquetes ycapas. También se describe la asignación de paquetes yclases de la Vista Lógica a los paquetes y módulos de laVista de Implementación.

• Vista de Implantación: Describe varios nodos físicos para

las configuraciones más típicas de las plataformas y laasignación de las tareas de la Vista del Proceso a los nodosfísicos. Es un subconjunto del Modelo de Implantación. Estavista se realiza sólo si el sistema es distribuido a través demás de un nodo, por lo tanto es opcional.

• Vista de Datos: Esta vista especifica arquitectónicamentelos elementos constantes en el Modelo de Datos. Describeuna apreciación global del modelo de los datos y suorganización por lo que se refiere a las tablas, vistas yalmacenamiento de los procedimientos que proporcionan la

persistencia al sistema. También describe la cartografía declases constantes de la Vista Lógica a la estructura de losdatos de la base de datos.

3.2 Modelo de Diseño

Para representar los diagramas del Modelo de Diseño sepueden emplear diferentes diagramas de UML tales como:• Diagramas de Clase.• Diagramas de Colaboración.• Diagramas de Estado.

• Diagramas de Secuencia.

3.3 Mapa de de navegación o Carta EstructuradaEste artefacto expresa la estructura de los elementos de lainterfaz de usuario del sistema, junto a los caminos denavegación principales. Este permite al usuario una adecuadanavegación en el sistema y sobre todo saber en qué punto delsistema se encuentra y hacia donde puede ir. Sin un Mapa deNavegación no se podría aprovechar al máximo un sistema.Cabe destacar que existirá solamente uno de estos artefactosen el sistema.

3.4 Modelo de DatosMODELO E_RMODELO de la base de datosDiccionario de Datos

3.5 Realizaciones de los Casos de UsoSon los diagramas de secuencia que expresan el comportamientodel caso del uso en términos de objetos de colaboración

3.6 Modelo de ImplantaciónDiagramas de componentes y diagramas de despliegue

4 Implementación4.1 Componente Operacional del Sistema

Este artefacto es una versión operacional del sistema o partede este que cubre un subconjunto especificado de losrequerimientos que el sistema final cumplirá. Este comprendeuno o más elementos de la aplicación (funciones ejecutables)que son creados de otros elementos mediante un proceso decompilación y unión del código fuente. Agrupa un conjunto deSubsistemas de Implementación. Cabe destacar que cada unade las funciones y capacidades que representan una parte delsistema pueden ser probadas durante su ejecución.




4.2 Modelo de Implementación:En esta actividad se propone una estructura para laimplementación, con el fin de conseguir facilitar laimplementación, integración y desarrollo de los procesos.

Elemento de ImplementaciónEl elemento de implementación es un artefacto que representa elmás bajo nivel de composición de un componente de software, esdecir, un conjunto de elementos de implementación son los queconforman a un componente del sistema. Este artefacto puede serun código fuente, un código binario, un archivo, un ejecutable,entre otros.Subsistema de ImplementaciónEsta actividad integra los cambios de los desarrolladores paracrear una nueva versión consistente de la implementación de un

subsistema.Plan de IntegraciónEsta actividad se planifica la integración del sistema para laiteración en curso.

PARTE IV

PRUEBAS E IMPLANTACIÓN DEL DISEÑO TECNOLÓGICO

1. Plan de Pruebas (ver documento de Plan de Pruebas)

Este artefacto define un conjunto de datos de entradas,condiciones de ejecución y resultados esperados de las pruebas,identificados para hacer una evaluación de los aspectosespecíficos de un elemento objeto de prueba. Cada Caso de dePrueba está asociado a un escenario de un Caso de Uso enparticular.




Los casos de prueba deben ser escritos con el detalle suficientepara que el probador pueda empezar rápidamente a ejecutarpruebas y a encontrar defectos. Además, estos reflejantrazabilidad con los casos de uso, las especificacionessuplementarias de requerimientos y diseño del sistema,garantizando que los procedimientos de pruebas sean compatiblescon las necesidades de los usuarios/clientes.

En la metodología los Casos de Uso dirigen todo el proceso de

desarrollo, es por ello que los Casos de Uso se transforman en unactivo que puede directamente conducir el proceso de pruebas. UnCaso de Prueba no es igual a un Caso de Uso. El Caso de Pruebaextiende o amplía la información contenida en un Caso de Uso.

Entre las actividades a realizar se encuentran, trabaje con las queestán dentro de los parámetros de su proyecto:

1. Acordar la Misión de las Pruebas2. Acordar las Pruebas a Realizar3. Analizar Pruebas Fallidas

4. Definir Criterios de Aceptación de los Casos de Prueba5. Definir el Enfoque de Pruebas6. Definir los Detalles de las Pruebas7. Determinar los Resultados de las Pruebas Ejecutar el

Conjunto de Pruebas Establecer la Configuración delAmbiente de Pruebas

8. Evaluar y Defender la Calidad9. Evaluar y Mejorar el Esfuerzo de las Pruebas10. Identificar la Misión de las Pruebas 111. Identificar las Ideas de Pruebas12. Identificar los Motivadores de las Pruebas13. Identificar los Objetos de Pruebas14. Implementar las Pruebas15. Preparar los Lineamientos del Proyecto

2. Implantación

El SistemaEste artefacto es el producto final, es decir, el sistema yafuncionando que puede ser instalado y ser utilizado por el cliente.Un Sistema se diferencia de una unidad de implantación, ya que el

sistema puede contener varias unidades de implantación. Cabedestacar que dichas unidades de implantación que reúne elsistema pueden ser exportadas a una unidad de almacenamiento.

Lista de MaterialesEste artefacto lista los componentes de una versión dada de unproducto y define donde los componentes físicos pueden serencontrados. Además, describe los cambios realizados en laversión y se refiere a la forma en que el producto puede serinstalad

Artefactos de InstalaciónEste artefacto tiene como objetivo permitir que la instalación delsistema sea llevado a cabo por alguien. Se basa en los programase instrucciones documentadas requeridas para que ese alguieninstale el producto. Puede incluir: instrucciones, scripts, iconos,archivos de licencia, etc.

Los Artefactos de Instalación son necesarios cuando se quiereconfigurar el sistema mediante los programas de instalación ypueden 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 instalación se reflejan en el Manual deInstalación y si se espera que el usuario instale el producto(sistema) puede reflejarse en el


http://merinde.net/index.php?option=com_content&task=view&id=363&Itemid=246








































Manual de Usuario.

Este artefacto provee una ayuda a las personas que manipularándirectamente el producto, acerca del uso que le debe dar alsistema. Dicho artefacto debe ser discutido y aprobado por elcliente.

Elaborar el manual de usuario durante las primeras iteraciones delproyecto permitirá al equipo de probadores conocer el sistema

antes de que comiencen las pruebas, adicionalmente provee losmecanismos básicos para elaborar los planes de pruebas y loscasos de pruebas, y permite la elaboración de sistemasautomatizados para las pruebas.

Según el tipo de sistema se define el comienzo del desarrollo delManual de Usuario. Sistemas con interfaces complejas o conmucha interacción requerirán versiones tempranas del manual deusuario así como de prototipos de interfaces. Sistemas con pocainteracción probablemente no requieran que la documentación delusuario se elabore muy temprano.

Manual de Instalación (ver documento de manual deInstalación)El manual de instalación es un artefacto que refleja loslineamientos que hay que seguir para instalar el sistema. Contieneinformación sobre la infraestructura de instalación e instruccionespara la instalación y actualización del software.

Material de AdiestramientoEl propósito del Material de Adiestramiento, dependiendo de losrequerimientos del proyecto, es enseñar a los usuarios cómoutilizar, operar o mantener el producto. Este material se piensapara el uso en cursos de aprendizaje.

Mecanismo de Retroalimentación

Este artefacto provee un mecanismo para captar los comentariosde los clientes al probar el producto beta, tiene como fin de quelos usuarios hagan pruebas al sistema sobre el conjunto decaracterísticas disponibles y en lo posible, retroalimentar a susdesarrolladores con el descubrimiento de fallos y haciendosugerencias en cuanto a la funcionalidad, etc.

Plan de Adiestramiento

Muestra el plan detallado de adiestramiento. El propósito de esteplan es que las personas que vayan a utilizar el sistema, secapaciten para su utilización evitando que el mismo sea malutilizado. Dicho artefacto debe ser discutido y aprobado por elcliente.

Este artefacto está compuesto por secciones para indicar el

programa de entrenamiento o cursos que serán impartidos a losusuarios finales para enseñarles el uso, operación ymantenimiento del sistema.

Plan de Implantación

El objetivo principal de este artefacto es asegurar que el sistemallegue satisfactoriamente al conjunto de usuarios para el cual fuedestinado. Este artefacto debe definir un conjunto de tareas que

defina una transición sencilla para el cliente, para ello se debeminimizar el impacto que la implantación del sistema pueda llegara causar en el personal del cliente, los sistemas de producciónexistentes y en todas las rutinas del negocio.




Este artefacto describe el conjunto de tareas necesarias parapoder poner en funcionamiento el sistema en las instalaciones delos usuarios. Las actividades descritas en este documento abarcantemas referentes a la instalación del nuevo sistema, instruccionesespecíficas sobre la sustitución de antiguos sistemas,compatibilidad del sistema, y estrategias de migración yadaptación al nuevo sistema. Adicionalmente este artefactodescribe en detalle las actividades correspondientes a la entregadel producto, el cronograma de actividades, personal responsable,

los recursos y fuentes necesarias para el funcionamiento del nuevosistema, plan de adiestramiento, notas de seguridad, deprocedimientos operacionales específicos, entre otros.

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


http://merinde.net/index.php?option=com_frontpage&Itemid=1

http://merinde.net/index.php?option=com_frontpage&Itemid=1

proyecto sosciotecnologico iv esquema del informe completo

Documents