domingo, 30 de junio de 2013

Informes

Se presentarán informes semanalmente para el control y seguimiento por parte del responsable del grupo del proyecto. De la misma manera se presentarán los informes respetando las fechas fijadas en el cronograma de actividades.
La presentación del informe se la realizará bajo un formato descrito en Anexo A.



sábado, 29 de junio de 2013

Mecanismo De Supervisión

El seguimiento de la planificación se realizará mediante los siguientes mecanismos de supervisión:

• Realizando reuniones periódicas para controlar el estado del proyecto en la que todos los miembros del equipo informan del progreso y de los problemas ya sea individual o grupalmente.
• Determinando si se han conseguido la tareas del proyecto en las fechas programadas. Comparando la fecha real de inicio con las previstas para cada tarea del proyecto.
• Realizando reuniones formales con el responsable del grupo del proyecto para obtener sus valoraciones subjetivas del progreso hasta fecha y los problemas que se avecinan.
• Evaluando los resultados de todas la revisiones y correcciones realizadas a lo largo del proceso de ingeniería de software.

viernes, 28 de junio de 2013

Refinamiento de Tareas Principales

Las tareas principales descritas en la sección anterior, se emplean para definir una planificación temporal macroscópica. El refinamiento consiste en tomar cada tarea y descomponerlas en subtareas. Para este fin utilizamos un enfoque de lenguaje de diseño de proceso.


1. Etapa de planificación del proyecto
Definición de tarea: Tarea 1.1 Elaboración del plan de proyecto de software
1.1. Elaboración del plan de proyecto de software
1.1.1. Elaboración
2. Etapa de desarrollo y prueba del software 1er. Incremento
Definición de tarea: Tarea 2.1 Especificación de Requisitos
2.1. Especificación de Requisitos.
2.1.1. Identificación de actores y tareas
2.1.2. Especificación de Casos de Uso
Definición de tarea: Tarea 2.2 Diseño conceptual
2.2. Diseño conceptual .
2.2.1. Identificación de Clases, entidades y relaciones
2.2.2. Modelo conceptual E-R
3. Etapa de desarrollo y prueba del software 2do. Incremento
Definición de tarea: Tarea 3.1 Especificación de Requisitos
3.1. Especificación de Requisitos.
3.1.1. Identificación de actores y tareas
3.1.2. Especificación de Casos de Uso
Definición de tarea: Tarea 3.2 Diseño conceptual
3.2. Diseño conceptual.
3.2.1. Identificación de Clases, objetos, relaciones y subsistemas
3.2.2. Esquema de Clases e Instancias
Definición de tarea: Tarea 3.3 Diseño Navegacional
3.3. Diseño Navegacional.
3.3.1. Esquema Navegacional
3.3.2. Esquema de Contextos
3.3.3. Tarjetas de especificaciones
Definición de tarea: Tarea 3.4 Diseño de Interfaz Abstracta
3.4. Diseño de Interfaz Abstracta.
3.4.1. Elaboración de diseño de interfaz abstracta
4. Presentación Final del proyecto

jueves, 27 de junio de 2013

Selección de Tareas Principales

Como ya se definió anteriormente, se deben definir conjuntos de tareas que se desarrollaran a lo largo de la duración del proyecto.
Estos conjuntos son colecciones de hitos y entregas para completar el proyecto, de los cuales, los más significativos se detallan a continuación.

1. Etapa de planificación del proyecto
1.1. Elaboración del plan de proyecto de software
2. Etapa de desarrollo y prueba del software 1er. Incremento
2.1. Especificación de Requisitos.
2.2. Diseño conceptual.
3. Etapa de desarrollo y prueba del software 2do. Incremento
3.1. Especificación de Requisitos.
3.2. Diseño conceptual.
3.3. Diseño Navegacional.
3.4. Diseño de Interfaz Abstracta.
4. Presentación Final del proyecto

miércoles, 26 de junio de 2013

PROGRAMA DEL PROYECTO

La programación del Proyecto engloba las actividades de selección y refinamiento de tareas, cuyo resultado se expresará en una red de tareas, y posteriormente en un Diagrama de Gantt, donde se asignaránqQ responsabilidades, evitando de esta manera la aparición de los posibles riesgos contemplados en el apartado 3.

martes, 25 de junio de 2013

DIVISION DEL TRABAJO

En función al punto 7 se establecen las responsabilidades para cada uno de lo miembros del equipo, las mismas que se detallan en la tabla 6.1.


Nombre Responsabilidad
Juan Barrancos
Christian Bascopé
Julio Mérida Elaboración del Plan de Proyecto de Software
Especificación de Requisitos (Identificación de Actores y tareas)
Implementación Primer Incremento
Implementación del Segundo Incremento
Documentación
Presentación final
Juan Barrancos
Christian Bascopé
Julio Mérida Especificación de Requisitos (Especificación de Casos de Uso)
Diseño Conceptual de la Base de Datos
Juan Barrancos
Christián Bascopé
Julio Mérida Especificación de Requisitos segundo incremento
Diseño Conceptual segundo incremento
Diseño navegacional
Tabla 6.1.- Responsabilidades para cada miembro del equipo

Dado que las responsabilidades están según el cronograma grupo del proyecto y las posibilidades de riesgos y ante la posibilidad de algún retraso del proyecto se preveé que estas responsabilidades están sujetas a modificaciones para de esta manera evitar el retraso del proyecto

lunes, 24 de junio de 2013

REQUERIMIENTOS DE RECURSOS DE HARDWARE Y SOFTWARE

En el proyecto se utilizaran diversos recursos de software como de hardware que permitirá de manera la realización del plan de proyecto.

8.1 Recursos de Hardware

Durante todo el proceso de desarrollo de software, se requerirán de los siguientes recursos de Hardware:

• 02 Computadoras de escritorio:
o 01 P-IV 2.8 GHz, 256 MB RAM, 120 GB HD
o 01 P-IV 2.53 GHz, 512 MB RAM, 80 GB HD

• 02 Impresoras Cannon Bubble Jet
8.2 Recursos de Software

Durante todo el proceso de desarrollo de software, se utilizarán las siguientes herramientas:

• Rational Rose 98 – herramienta que se utilizará específicamente en la fase de Diseño Conceptual, para la representación de los diagramas de Caso de Uso, y diagramas de clases.

• Microsoft Project 2003 – este programa será utilizado principalmente para la elaboración de diagramas de Gantt en la etapa de planificación del proyecto.

• Microsoft Word 2003 – este programa es elegido por su amplia cobertura en la edición de texto, que permite una fácil elaboración de la documentación pertinente al Sistema.

• Sybase Power Designer 9.5 - el cual nos permite automatizar el proceso de diseño de base de datos, y el paso de un modelo conceptual a un modelo físico.

• Macromedia Dreamweaver MX 2004 – es un programa que facilita la elaboración del código HTML, y PHP. Agiliza el proceso de unión del sistema a la base de datos.

• AppServ 2.4 – conjunto de programas que incluyen las versiones:

o PHP 4.3.6
o MySQL 4.0.18
o Apache 1.3.29

• PHP 4.3.6 – Lenguaje de programación de páginas Web dinámicas, significa que se puede tener acceso a base de datos con todas las características que esta funcionalidad incluye, como ser: Consultas, actualizaciones, inserciones y eliminación de registros.

• Mysql 4.0.18 – Gestor de Base de Datos que soporta el lenguaje de consulta estructurado (Structured – Query- Language) SQL.

• Apache 1.3.29 – Servidor encargado de la integración del código HTML, y PHP.

domingo, 23 de junio de 2013

Planeación de Riesgos

En este punto se realizara la planeación de acciones a tomar ante los riesgos de la sección (4.1). Ver Tabla 4.3


Riesgo
Estrategia
Renuncia de uno de los miembros del grupo de desarrollo del proyecto.

Plan de contingencia:
Redistribuir totalmente las tareas asignadas al socio desertor, entre el resto del personal.
Falta de experiencia del personal en el uso de las herramientas.

Estrategia de disminución:
Asignar un periodo de tiempo previo paralelo a la fase de análisis del proyecto.
Cambio de Lenguaje de Programación.

Estrategia de anulación:
Analizar en el comienzo de la fase de análisis la factibilidad tecnológica del lenguaje de programación a usar y el grado de familiaridad y/o la facilidad de adecuación a un nuevo lenguaje, del personal.
Enfermedad de de los integrantes del grupo.

Plan de contingencia:
Redistribuir temporalmente las tareas asignadas al socio convaleciente, entre el resto del personal.
El Cliente (Unidad Operativa de Tránsito), cambia de requerimientos.                    

Plan de contingencia:
Emplear una metodología de desarrollo, y un  modelo de ciclo de vida de software que soporte cambios y/o añadiduras  repentinas de requerimientos.

Insatisfacción del cliente con el sistema presentado.

Estrategia de anulación:
Emplear herramientas para el control de proceso de desarrollo de software con el fin de supervisar continuamente los avances para cada tarea o actividad y permanecer en contacto frecuente con el cliente, para trabajar como un equipo y de esta manera se puedan refinar los requerimientos.

Tabla 4.3.- Planeación de Riesgos

sábado, 22 de junio de 2013

Análisis de Riesgos

En este punto se analizará cada riesgo de la sección (4.1). Ver Tabla 4.2



Riesgos
Categoría
Impacto
Probabilidad
Renuncia de uno de los miembros del grupo de desarrollo del proyecto.

 Proyecto
2
Bajo
Falta de experiencia del personal en el uso de las herramientas.

Desarrollo
2
Moderado
Cambio de Lenguaje de Programación.

Desarrollo
1
Bajo
Enfermedad de de los integrantes del grupo.

Desarrollo
3
Bajo
El Cliente (Unidad Operativa de Tránsito), cambia de requerimientos.                    

 Negocio
2
Bajo
Insatisfacción del cliente con el sistema presentado.

Negocio
1
Muy Bajo
El cliente esta insatisfecho con el diseño de la interfaz de usuario.
Negocio
3
Muy Bajo
Tabla 4.2.- Análisis de Riesgos


viernes, 21 de junio de 2013

Identificación de Riesgos

Los posibles riesgos que el proyecto pueda enfrentar son:


Riesgos del Proyecto:
• Renuncia de uno de los miembros del grupo de desarrollo del proyecto.


Riesgos de Desarrollo:
• Falta de experiencia del personal en el uso de las herramientas.
• Cambio de Lenguaje de Programación.
• Enfermedad de un(os) de los integrantes del grupo.

Riesgos del Negocio:
• El Cliente (Unidad Operativa de Tránsito), cambia de requerimientos.
• Insatisfacción del cliente con el sistema presentado.
• El cliente esta insatisfecho con el diseño de la interfaz de usuario.

jueves, 20 de junio de 2013

Factibilidad Técnica

El sistema es factible técnicamente parcialmente puesto que para el desarrollo del mismo no se requiere de tecnología que este fuera del alcance de la empresa es decir no se requiere de hardware nuevo o de alguna tecnología que este fuera del alcance de la misma. No es factible Técnicamente en el sentido de que a la hora de la implantación, se requeriría tecnología adecuada para su correcto uso, gastos en los que tendría que incurrir la Unidad que utilizaría este sistema.


Además se analizo que este problema puede ser resuelto dentro del tiempo planteado por el grupo.

miércoles, 19 de junio de 2013

Factibilidad económica


El sistema es factible económicamente dado que, el estudio realizado dentro la modalidad de titulación de Trabajo Dirigido, tiene como fin la titulación de los estudiantes desarrolladores, y acorde a esta modalidad, no se incurrirá en ningún gasto económico.

martes, 18 de junio de 2013

Factibilidad Operativa

Puesto que el sistema es de Automatización del Proceso de registro de Licencias de conducir, no se observa mayor problema para que el sistema no pueda adaptarse a la organización Policial. Se eligió como metodología de diseño a OOHDM y modelo de ciclo de vida incremental.

lunes, 17 de junio de 2013

Factibilidad Legal

El sistema será desarrollado para la Unidad Operativa de Tránsito, División Licencias, así que todos los derechos legales serán de esa institución.

El producto final no infringe ninguna ley debido a que el mismo esta siendo desarrollado para fines de titulación, educativos, Institucionales, por tanto se considera que el proyecto factible legalmente.

domingo, 16 de junio de 2013

FACTIBILIDADES

El estudio de la factibilidad permite ver si el sistema propuesto es conveniente.
Es un estudio muy rápido y orientado a conocer si el sistema puede desarrollarse con la tecnología actual y con el tiempo y coste previsto.
Por tanto se realizará un estudio para ver si el sistema es factible técnicamente, operativamente, legalmente y económicamente.

sábado, 15 de junio de 2013

Rol: Programador

El programador se encargará de la codificación del programa. Las principales funciones que tendrá son las siguientes:

5.4.3.1. Funciones

 Codificar el análisis realizado del proyecto.
 Manejar diferentes lenguajes de programación.

5.4.3.2 Especificación Del Cargo

a) Experiencia

Fuerte conocimiento en la codificación de proyectos de software.

b) Condiciones Personales

 Persona responsable.
 Con bastantes conocimientos de programación.
 Dominio de bases de datos.
 Interrelaciones
 Habilidad para investigar

viernes, 14 de junio de 2013

Especificación del Rol

a) Experiencia
Facilidad de análisis de proyectos de Software.

b) Condiciones Personales

 Persona responsable.
 Capacidad de análisis a nivel externo e interno.
 Habilidad para resolver problemas no necesariamente técnicos.
 Habilidad en los procesos de Ingeniería de Software.
 Habilidad para investigar.
 Habilidad para extraer información del usuario.
 Saber trabajar bajo presión.
 Liderazgo.

jueves, 13 de junio de 2013

Funciones

Las principales funciones que tendrá son las siguientes:

 Determinar los requerimientos que se tienen para el desarrollo del proyecto.
 Determinar la disponibilidad de Hardware.
 Determinar la disponibilidad de Software.
 Determinar la posible necesidad de usar redes, bases de datos u otros.
 Determinar los diagramas de especificación del proyecto (Diagramas UML, E-R, etc.)

miércoles, 12 de junio de 2013

Rol: Analista de Sistemas


El analista de sistemas tiene como responsabilidad el análisis de los requerimientos que solicita el usuario, usa técnicas y herramientas principales para análisis y diseño de aplicaciones,

martes, 11 de junio de 2013

Consultor – Desarrollador

El Consultor – Desarrollador tiene las funciones de investigar, evaluar, desarrollar, planificar y analizar prever todos los aspectos relacionados al proceso de desarrollo de software.
Este cargo implica los siguientes roles:

 Analista de Sistemas
 Programador

lunes, 10 de junio de 2013

Asesor del Proyecto

El Asesor del Proyecto es la persona que se ocupa de la supervisión, conjuntamente realiza actividades de dirección, administración y desarrollo de los trabajos encomendados del grupo.
Dicho esto Asesor del Proyecto deberá ser elegido en base de la experiencia, los estudios, la capacidad, el entusiasmo y el la cantidad de tiempo disponible que este cargo requiere.
Este cargo contempla los siguientes roles:

 Administrador del proyecto.
 Analista de Sistemas

Lógica rebatible

La programación en lógica es uno de los principales exponentes de la programación declarativa. Aunque se la ha utilizado como herramienta de representación de conocimiento, presenta limitaciones para adaptarse al razonamiento rebatible. En los últimos años se han desarrollado extensiones de la programación en lógica que incorporan algunos aspectos del razonamiento rebatible. Por ejemplo, Gelfond y Lifschitz, en el artículo escrito el año 1990 titulado “Programación lógica con negación clásica”, introducen los programas lógicos extendidos que permiten la representación de cláusulas de programas con antecedentes negados. Los programas lógicos extendidos presentan ventajas importantes a la hora de representar conocimiento. Pero lamentablemente cuando dos literales complementarios pueden derivarse de un programa lógico extendido, el conjunto de respuestas del programa es igual a todo el lenguaje. Los agentes inteligentes tienden a razonar en una forma rebatible: Conclusiones previas son refutadas ante la presencia de mayor información. En la tesis de Vreeswijk, escrita el año 1993 con el título “Estudios en argumentación rebatible”, la argumentación rebatible es una formalización que intenta capturar este tipo de razonamiento. Como habitualmente el conocimiento maneja información tentativa, la información por defecto, y la representación de información tentativa en la mayoría de los casos lleva a bases de conocimiento inconsistentes, en la mayoría de los casos el programa deriva todo el lenguaje.

Kowalsky y Sadri, en el artículo escrito el año 1990 titulado “Programación lógica con excepciones”, utilizan los programas lógicos extendidos para representar información negativa, y los extienden para la representación de excepciones a reglas generales. Por ejemplo, los pingüinos son una excepción a la regla “las aves vuelan”. La idea que proponen es representar las reglas generales y las excepciones con cláusulas, luego a la hora de calcular la respuesta, las excepciones tienen prioridad sobre las reglas. Lamentablemente la forma en que diferencian una regla de una excepción tiene algunas limitaciones, debido a que las primeras tienen un consecuente positivo y las últimas un consecuente negado. Esto representa una restricción muy grande, que trae aparejada confusiones, ya que la cláusula “los mamíferos no vuelan” representaría una excepción a la regla “los murciélagos vuelan”. El artículo de Katsumi Inoue, escrito el año 1991 con el título “Programación lógica extendida con suposiciones por defecto”, extiende el artículo de Gelfond y Litfschitz, citado anteriormente, para trabajar con información potencialmente inconsistente. También ataca el problema de los conjuntos de respuestas inconsistentes, pero lo hace separando la información absoluta, de la información tentativa o hipotética. De esta forma un “sistema de conocimiento” es un par conformado por un conjunto de hechos, que son verdaderos en el dominio en cuestión, y un conjunto de hipótesis. La tarea del sistema es hallar un subconjunto del conjunto de hipótesis tal que el conjunto de respuestas del conjunto unión de hechos y el subconjunto de las hipótesis sea consistente.

En palabras de García, reflejadas en la tesis escrita el año 1997 con el título de “La programación en lógica rebatible su definición teórica y computacional”, investigadores en inteligencia artificial continúan produciendo nuevos formalismos, con el fin de obtener mejores métodos de razonamiento y de representación de conocimiento. Tanto la implementación de métodos de razonamiento, como la representación de conocimiento, siguen siendo problemas abiertos, y constituyen áreas centrales dentro de la investigación en inteligencia artificial, ya que cualquier avance en estas áreas, redundara en un beneficio casi inmediato para muchas otras áreas de la ciencia de la computación. Aunque la lógica clásica ha sido utilizada desde sus inicios como una formalización del razonamiento humano, razonar implica mecanismos mucho más complejos que los que provee la lógica clásica. Por ejemplo, una de las características del razonamiento de las personas es que la aparición de nueva evidencia puede invalidar conclusiones obtenidas con anterioridad. Sin embargo, las lógicas de primer orden, cumplen con la propiedad de monotonicidad, es decir, en la lógica clásica, agregar nuevos axiomas o hipótesis a la teoría no invalida viejos teoremas, y por lo tanto no es posible desechar conclusiones obtenidas con anterioridad.

domingo, 9 de junio de 2013

Tipo de organización del grupo

Nosotros como empresa desarrolladora de software, seguimos el tipo de organización de tipo lineal. Este tipo de organización maneja una estructura horizontal, donde el grupo de trabajo de la empresa rinde cuentas a un solo supervisor, que en este caso llegaría a ser el Asesor de la Materia de Metodología de Investigación y Planificación de Proyecto Final.

Este tipo de organización ha sido elegido ya que brinda las siguientes ventajas:
 Es sencillo y claro.
 No hay conflicto de autoridades ni fugas de responsabilidad.
 Se facilita la rapidez de acción.
 Se crea una firme disciplina.
 Es más fácil y útil en la pequeña empresa.

sábado, 8 de junio de 2013

ORGANIZACIÓN DEL PROYECTO

La finalidad de una estructura organizacional es establecer un sistema de papeles que han de desarrollar los miembros de una entidad para trabajar juntos de forma óptima y que se alcancen las metas fijadas en la planificación.

viernes, 7 de junio de 2013

METODOLOGÍA

La metodología a usar durante el proceso de desarrollo de Software será OOHDM (Object-Oriented Hypermedia Design Method).
Descripción

OOHDM usa abstracción y mecanismos de composición para un entorno orientado a objeto. En OOHDM una aplicación de hipermedios es construida en un proceso de 4 pasos antes de su implementación, soportando un ciclo de vida incremental y algunas ventajas del ciclo de vida de prototipos. En cada paso se enfoca un aspecto en particular, y se construye un modelo orientado a objetos. Conceptos de Clasificación, Agregación, y Generalización/Especialización, son usados a lo largo del proceso para reforzar el poder de abstracción y asimismo, aprovechar las oportunidades de la reutilización de componentes, que es uno de los principales objetivos a la hora de desarrollar software.
A continuación, se resumen lo aspectos referentes a cada uno de los pasos, productos, mecanismos, y cuestiones de diseño en OOHDM. (Tabla 1.1).

Tabla .1 – Resumen Metodología OOHDM
Actividades
Producto
Formalismos
Mecanismos
Cuestiones de diseño
Especificación de requerimientos
Casos de uso, anotaciones
Escenarios; Diagramas de Interacción del Usuario; Patrones de diseño.
Análisis de Escenarios y Casos de Uso, Entrevistas, Modelo Conceptual de Mapeo de Interfaz de Usuario.
Capturar lo Requerimientos del cliente para la Aplicación.
Diseño Conceptual
Clases, sub -sistemas, relacionamientos, perspectivas de atributos.
Modelamiento Orientado a Objetos; Patrones de Diseño.
Clasificación, Agregación, Generalización y Especificación.
Modelar la semántica del Dominio de la Aplicación.
Diseño Navegacional
Nodos, enlaces, estructuras de acceso, contexto navegacional, trasformaciones navegacionales.
Vistas Orientadas a Objetos; Diagramas de Estado Orientado a Objeto; Clases de Contexto; Patrones de Diseño;
Clasificación, Agregación, Generalización y Especificación
Cuentas de Usuario y tareas, con énfasis en los aspectos cognoscitivos. Construir la estructura navegacional de la Aplicación.
Diseño de Interfaz Abstracta

Objetos de interfaz abstracta, respuestas a eventos externos, transformaciones de interfaz.
Visa de datos Abstractos; Diagramas de Configuración; Diagramas ADV; Patrones de Diseño.
Mapeo entre Navegación y Objetos perceptibles.
Modelar   objetos perceptibles, teniendo en cuenta los criterios  elegidos. Describir la interfaz para los objetos navegacionales. Describir la disposición  de los   Objetos de Interfaz.
Implementación
Aplicación corriendo.
Todos los soportados por el entorno.
Todos los soportados por el entorno.
Completitud;
Performance.



jueves, 6 de junio de 2013

OBJETIVOS ESPECÍFICOS

Para alcanzar el objetivo general enunciado en el numeral anterior, se deberán lograr los siguientes propósitos específicos:

• Identificar las causas de cada parte del problema.


• Ubicar, seleccionar y presentar resumidamente planteamientos directamente relacionados con la puesta en marcha de un Sistema de automatización del proceso de registro de Licencias de Conducir, Orientado a la WEB, utilizando la tecnología y normas orientadas a la WEB para el funcionamiento del proyecto.

• Ubicar, seleccionar y presentar resumidamente planteamientos directamente relacionados con la reformulación de la tecnología empleada en la emisión de las licencias de conducir, proponiendo la implantación de tarjetas magnéticas, utilizando la tecnología y herramientas apropiadas para este fin.


• Presentar resumidamente las normas que se tienen que cumplir en la elaboración de un proyecto para la implantación de un Sistema de automatización del proceso de registro de Licencias de Conducir, Orientado a la WEB.

• Presentar un Sistema de automatización del proceso de registro de Licencias de Conducir, Orientado a la WEB, utilizable dentro de la institución.



• Cumplir con las especificaciones planteadas por la institución.

miércoles, 5 de junio de 2013

OBJETIVO GENERAL

La presente investigación pretende analizar el proceso de registro de Licencias de Conducir referente a la filiación de Conductores nuevos y antiguos y la reformulación de la tecnología utilizada en la emisión de las licencias proponiendo tarjetas magnéticas, dentro la Unidad Operativa de Tránsito – División Licencias; del Departamento de Cochabamba; con respecto a un marco referencial que integre las normas que rigen el funcionamiento de dicha institución; mediante un análisis sistémico de requerimientos con el propósito de identificar las causas de cada parte del problema de tal manera que tengamos base para proponer los lineamientos para el funcionamiento de un Sistema de Automatización del proceso de registro de Licencia de Conducir, Orientado a la WEB, que permita un manejo y flujo de la información, eficiente y efectivo.

martes, 4 de junio de 2013

JUSTIFICACIÓN

El presente proyecto persigue la meta de desarrollar una herramienta que permita automatizar el proceso de registro de licencias de conducir y de la Información que relaciona a los conductores que se benefician de estos servicios en el dominio de su entorno.

lunes, 3 de junio de 2013

DESCRIPCIÓN DEL PROBLEMA

El crecimiento vertiginoso de la manipulación de información referente al proceso manual de registro de licencias de conducir y todos sus sub-actividades, ha traído consecuencias administrativas, sociales y laborales tales como:
Retardo en la culminación del proceso de registro de licencias,

Inseguridad en el manejo de dicha información en el sentido de que cualquier ente externo podría alterar la consistencia de la información,

Durante el proceso han ido apareciendo operaciones burocráticas innecesarias,

Falta de credibilidad de las personas que requieren de los servicios que presta la institución,

Inestabilidad de los trabajadores respecto de su cargo, debido a un manejo ineficiente de la información.

domingo, 2 de junio de 2013

GESTIÓN DE RIESGOS

El riesgo es la incertidumbre acerca de un evento futuro. Para un sistema de información se evalúan los distintos riesgos que se pueden presentar durante el desarrollo del proyecto, así como planes o acciones para poder minimizarlos o en algunos casos si es posible evitarlos. Esto es algo importante a tener en cuenta porque cualquier riesgo que pueda darse, influye en el desarrollo normal del proyecto y por ello hay que reducir el porcentaje de aparición de estos.

Los riesgos impredecibles pueden ocurrir, pero son extremadamente difíciles de identificar por adelantado. El grupo de trabajo del proyecto se basa en su experiencia profesional para la identificación de los riesgos que se tomarán en cuenta en este apartado.

A continuación se analizarán todos los posibles riesgos que podrían presentarse durante el desarrollo del proyecto, para después gestionarlos y darles posibles soluciones.

Metodología de Investigación y Planificación de Proyecto Final

1. INTRODUCCIÓN

Desde el punto de vista profesional, él casi profesional adopta una formación educativa y de conocimientos en una institución universitaria.

El tendrá que desarrollar un plan de investigación pretendiendo, obtener resultados del mismo; siendo requisito para obtener su título profesional.

La elaboración del plan de investigación sólo pretende investigar o estudiar un problema (problema que cumpla con los criterios de formulación) para la ciencia o para la sociedad y proponer su solución.

La gestión de un proyecto de software comienza con un conjunto de actividades que globalmente se denominan planificación de proyecto. Antes de que el proyecto comience, el gestor y equipo de software deben realizar una estimación del trabajo realizar, de los recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización.

A continuación presentamos un ejemplo donde se verá con más detalle la selección de un problema según sus criterios y prioridades.