Proyectos Ejemplo
Proyectos Ejemplo
Proyectos Ejemplo
com/2012/10/11/proyecto-orientado-aldesarrollo-de-un-sistema-informatico/
los respectivos documentos oficiales que avalen su veracidad; solo para tener derecho a
realizar los exmenes que sirven como filtros a los posgrados. Posteriormente si los alumnos
llegaran a aprobar todos los exmenes, y fueran candidatos a ser seleccionados, se les pide
nuevamente la misma documentacin con algunos extras, como el original del ttulo
profesional y tambin la de la cdula, con sus respectivas fotocopias. Con lo cual, se consume
mucho tiempo de parte de los alumnos al buscar y organizar todos los documentos para su
entrega, o si en toda esta pila de documentos y copias llegase a tener algn faltante y tuviera
que ser repuesto; pudindoles traer en ocasiones problemas con sus respectivos trabajos y
actividades personales. Cabe sealar que todos los documentos originales no son retenidos
por parte del rea de control escolar de posgrado y solo sirven para que sean cotejados con
sus fotocopias y ver que sean idnticos, ya que las copias son realmente las que se necesitan
para su trmite de ingreso, poniendo en riesgo al documento original de sufrir algn maltrato o
perdida.
Una semana antes del inicio de semestre de algn posgrado, son publicadas en las
ventanillas del departamento de control escolar mediante hojas comunes tamao carta y
pancartas, las materias que los alumnos debern cursar por semestre; los maestros que
impartirn stas materias y sus horarios. El alumno debe tomar nota de todos estos datos y
deber formar su horario de clases, plasmndolos en un formato otorgado por el
departamento de control escolar. Todo este proceso provoca que los alumnos mientras
intentan tomar la informacin, se amontonen en los pasillos del departamento y se estorben
mutuamente, inclusive, tambin estorben al personal que ah labora, impidindoles su libre
paso.
Despus de la inscripcin al semestre, al alumno se le pide que llene otro formato muy
parecido al que entreg al inicio, pero esta vez no puede ser llenado a puo y letra, ya que
ahora si este es el documento original que ser entregado a la respectiva direccin de la
escuela.
Actualmente la nica manera que tiene el departamento de control escolar de comunicar algn
problema en la inscripcin a los alumnos es va correo electrnico. Sin embargo, el envo de
correos es una tarea tediosa ya que si se necesita enviar a todos alguna notificacin, esta
deber ser enviada mediante copias de correos uno por uno.
PLANEACIN
El proyecto se dividir en fases. Cada fase representar un avance o un aspecto a cubrir en la
automatizacin del sistema. Las fases son:
Fase 1 identificacin de los requerimientos y formalizacin de los parmetros de trabajo con el
usuario.
En esta fase se recopilaran todos los requerimientos de los procesos que se llevan a cabo
actualmente en el departamento de posgrado y que debern ser automatizados. Se harn las
entrevistas de reconocimiento con los usuarios implicados y se determinaran sus roles y
cargos. As como tambin, se darn a conocer los planes de trabajo y los horarios de atencin
y de consulta.
Fase 2 Organizacin y estructura de la informacin obtenida por los usuarios:
Una vez que ya se tenga completamente la idea de cmo opera actualmente el departamento
de control escolar de posgrado, y la informacin necesaria para entender sus requerimientos;
se proceder a organizar de manera lgica toda la informacin recabada. Identificando los
puntos clave a ser corregidos, los que debern eliminarse o los nuevos que debern ser
implantados. En base a esto, se harn reportes y reuniones con los usuarios implicados en
cada proceso, para mostrarles las propuestas de cambio y saber sus opiniones o posturas y
seguir adelante si los usuarios estn conformes, o de lo contrario, corregir nuestras
propuestas segn sus peticiones.
Fase 3 Diseo de los elementos de la propuesta final, enfocndolos hacia un sistema de
aplicacin web cliente-servidor:
En la tercera fase, una vez que ya se tenga autorizada completamente la propuesta de cambio
del sistema definida en la fase 2; Se disearan los mdulos del sistema web, las
maquetaciones de la interfaz grfica de los usuarios, los diseos de las bases de datos
relacionales y todos los dems diseos de los planos de infraestructura de equipo de cmputo
necesario como servidores, nodos, equipo de red, impresoras escneres, etc. Todo esto se
recopilar en un documento de forma ordenada y servir como plano lgico del sistema.
Fase 4 Programacin e implantacin del sistema:
En base al plano lgico del sistema, obtenido de la fase anterior; en esta fase es donde se
decidir: cuales debern ser los lenguajes de programacin y sus libreras; los sistemas
manejadores de bases de datos y cuales debern ser los equipos de cmputo necesarios para
instalar el nuevo sistema. Esto se har tambin tomando en cuenta la opinin y el presupuesto
autorizado por el usuario.
Una vez que sea instalada toda la infraestructura fsica y lgica elegida por el usuario, se
proceder a programar y construir el cdigo fuente de los mdulos definidos en el plano
lgico. As como tambin se proceder a construir las bases de datos, creando los esquemas,
las tablas, las relaciones, vistas, ndices, usuarios, roles y permisos; al igual que los procesos
almacenados y disparadores.
Fase 5 Prueba general del nuevo sistema
EJECUCIN
Las reuniones y las entrevistas que se llevan a cabo con los clientes en cada fase del proyecto
y se hacen por las maanas a primera hora.
Para la fases 1 y 2: se hace uso de tcnicas de recopilacin de informacin como encuestas,
cuestionarios, y entrevistas. Esta informacin se representa en graficas, mapas mentales y
conceptuales, cuadros sinpticos y se hace un uso importante de diagramas de casos de uso.
Al trmino de cada fase se hace un reporte general entendible para el usuario.
Para la fase 3: se toma como base de diseo de los mdulos del sistema; al paradigma de
modelado UML (United Model Languaje). Aqu se disean los diagramas de secuencia, los
diagramas de estado y dems diagramas necesarios; y estos son construidos en base a los
diagramas de casos de uso resultantes de las fases anteriores.
Para el diseo de los diagramas de bases de datos de la fase 3, se hace uso del diagrama
entidad relacin en base a los roles de los usuarios y al manejo de los datos.
Para la fase 4, Se hacen cotizaciones de los diferentes elementos que integran al sistema de
manera comparativa en base al plano del sistema lgico y al costo-beneficio. Una vez que el
usuario se decide por una cotizacin, tomando en cuenta su presupuesto y gusto; se procede
a la instalacin correcta de todos los elementos seleccionados.
Por cada modulo que est programado y terminado, se hacen pruebas al lado del usuario.
La prueba general del sistema de la fase 5; se ejecuta en paralelo a la forma del sistema
actual de control escolar, y hasta que el nuevo sistema est estable; se deja de emplear la
forma anterior.
Para la fase final, el sistema es liberado nicamente si los usuarios estn conformes y ste
cumple perfectamente con todo el plano lgico. Para las nuevas modificaciones no previstas
despus de su liberacin se procede a la modificacin de las cuotas de desarrollo.
Toda la actividad del proyecto queda asentada en una carpeta de manera organizada.
CONTROL
Al inicio del proyecto se definen las formas de trabajo para con el usuario as como todos los
reglamentos y parmetros necesarios.
Por lo menos una vez a la semana se har un informe general de todos los avances del
proyecto y tambin se documentaran todos los problemas o situaciones imprevistas, que
impidan el avance.
Todo el ciclo de vida del proyecto ser calendarizado en acuerdo con los usuarios.
Al trmino de cada fase del proyecto, el usuario dar el visto bueno mediante algn
documento de conformidad.
En cada reunin se har uso de minutas.
Cada equipo de cmputo o software nuevo implantado, ser respaldado siempre por una nota
de remisin o factura de compra.
Los usuarios que no quieran cooperar en el desarrollo del sistema, sern reportados a sus
superiores y se proceder a la bsqueda de otros posibles usuarios que permitan la
informacin solicitada.
Es indispensable que se elabore el plano lgico del sistema en la fase 3 y un manual tcnico
en la fase 4.
CIERRE
Al terminar el proyecto, despus de la prueba general del sistema satisfactoria y antes de la
liberacin; se proceder a la capacitacin de los usuarios y a la creacin de los manuales de
usuario que les permitan saber y documente cmo funciona el sistema, de una manera clara y
sin la necesidad de soporte tcnico.
El proyecto se da por terminado cuando el usuario firma que est conforme y el sistema opera
sin ningn problema.
mtodos para conseguir las soluciones ms efectivas por anticipado. Las TIC y los SI son
herramientas que posibilitad una mayor eficiencia en las soluciones encontradas, ms no son
las responsables de la eficacia de la misma.
La eficacia y la efectividad se logran encontrando la idea que responde a la solucin de las
necesidades de los usuarios.
REQUERIMIENTOS DE USUARIOS
Publicado por alexbenca el 10/10/2012 en FUNDAMENTOS TEORICOS
En un proyecto: los usuarios, es decir, las personas que se beneficiaran de l, toman un papel
fundamental en todas las fases de su ciclo de vida. Ya que de ellos es de donde se toman
todos los requerimientos, peticiones y sugerencias reales que influyen en la construccin del
proyecto.
El propsito de la gestin de requerimientos es asegurar que el proyecto cumple con las
expectativas de sus clientes y de sus interesados, tanto externos como internos, siendo el
proceso que garantiza el vnculo entre lo que esperan los clientes y usuarios, y lo que los
equipos de proyecto tienen que desarrollar.
Si bien muchos de sus principios pueden ser adaptados a todo tipo de proyectos, es en los
proyectos de desarrollo de software donde adquieren todo su sentido, garantizando el proceso
y sirviendo de referencia para asegurar y controlar los cambios que en el proyecto puedan
surgir (trazabilidad). A menudo, incluye la elaboracin de planes especficos para diferentes
aspectos como la recoleccin, gestin e integracin de los requerimientos.
Definicin de requerimiento y Stakeholder (Interesados)
Segn la definicin del PMBOK, un requerimiento es la condicin o capacidad que debe
tener un sistema, producto, servicio o componente para satisfacer un contrato, estndar,
especificacin, u otros documentos formalmente establecido.
Son todas aquellas caractersticas observables que cualquier interesado desea que estn
contenidas en el sistema. Como requisitos se incluyen las necesidades, deseos y expectativas
del patrocinador, cliente, usuarios, y otros interesados.
Una capacidad que debe incluirse en un sistema para satisfacer los objetivos del
proyecto.
Definiendo el concepto de stakeholder (interesado) como alguien que est afectado por el
proyecto que se desarrolla, podremos encontrar que hay de dos tipos:
1. Usuarios: Aquellos que utilizaran el sistema.
2. Clientes: aquellos que requieren el sistema y son los responsables de su validacin o
aprobacin.
Es importante distinguir entre estos dos grupos de interesados, dado que muchas veces
podremos encontrarnos que hay un conflicto entre los requerimientos de ambos. En la
mayora de los casos, los requerimientos de los clientes tienen prioridad sobre los
requerimientos de los usuarios.