.

Retoma la propuesta de idea de un proyecto de sistema de información, así como la función

que realizará en el marco de una organización, que brevemente plantease en la actividad
1 y amplíala.

Como mencioné en actividades anteriores, actualmente en la empresa en la que laboro se

requiere de un sistema de solicitudes de servicio interno que permita al área de ventas
enviar los requerimientos de sus proyectos para sus clientes y que de esta forma el área de
operaciones reciba esta solicitud para procesar los requerimientos del área de ventas.

Es necesario definir cuáles son los requerimientos del sistema que se pretende diseñar para
poder saber qué es lo que vamos a crear como proyecto. A continuación se detallan los
requerimientos:
 Generales.- El área de ventas proporciona soluciones de software a la industria
farmacéutica, es decir; CRM, validación de ficheros médicos, localización GPS, CLM,
Business Intelligence, Representante Médico Virtual entre otras. Estas soluciones se las
solicita al área de operaciones para procesar los detalles que personalizan cada solución
para cada cliente, en este caso los clientes no son personas físicas, sino; personas morales
que requieren de un proveedor de soluciones funcionales para la operación diaria de sus
representantes médicos.

Requerimientos ventas:

1. Debe generar un número de servicio.

2. Nombre del ejecutivo de ventas.
3. Nombre del cliente del ejecutivo de ventas.
4. Tipo de proyecto de ventas.
5. Fecha de solicitud.
6. Fecha de revisión.
7. Descripción del proyecto.
8. Firmas digitales de autorización.

Requerimientos operaciones:

1. Fecha de inicio para procesar el proyecto de ventas.

2. Acuerdos del proyecto.
3. Fecha de revisión con el área comercial.
4. Fecha de entrega de la maquila del proyecto al área comercial.
5. Firmas digitales de acuerdo de entrega del proyecto terminado.

En sí, no teníamos mucho la cultura de planificar un proyecto interno hasta que nos
enfrentamos a una fuerte demanda de productos y solicitudes de servicios, esto nos ha
llevado a replantear nuestro antiguo modo de elaborar un proyecto de consumo interno y
establecer una planificación junto con una metodología que ayuden a la función de
administrar un proyecto como actualmente lo tenemos.

Planificación del Proyecto.-

1. Diseño de la interfaz.
2. Lenguaje de programación.
3. Tipo de base de datos.
4. Funcionalidad en sistemas operativos diferentes.
5. Preguntas al usuario.
6. Fecha de inicio del proyecto.
7. Fecha final del proyecto.
El tipo de estructura será orientada a objetos para un mejor manejo de los módulos de la
interfaz.

Éstas serían las preguntas con las que podemos iniciar a recabar información entre las dos
áreas que requieren de este sistema:

¿Qué tipo de solicitud se requiere?

¿Es de consumo interno o externo?

¿En qué tipo de plataforma se va a programar, web o escritorio?

¿Se requieren niveles de perfiles?

¿Quiénes están autorizados a entrar al sistema?

¿Qué tipo de seguridad se va a requerir?

¿La interfaz debe ser responsiva?

¿Debe cumplir con alguna condición de seguridad o todas las condiciones?

¿La información que se manejará es sensible o es pública?

¿Cuántos usuarios van a utilizar la plataforma?

¿En caso de ser web, el lenguaje debe ser Microsoft o PHP?

¿El tipo de base de datos será en Tomcat o en MySql? Esto depende de la pregunta
anterior.

¿Qué usuarios realizarán las pruebas?

En sí, no es exactamente un ejemplo, en realidad es un proyecto que tengo que desarrollar

en mi trabajo pero lo interesante es que las características que debe cumplir son las
siguientes:

Debe ser un sistema bidireccional.

Debe ser capaz de almacenar tantos proyectos como sean necesarios (Entendamos
proyectos como las soluciones que se proporcionan al cliente por parte del área comercial).

El área comercial no debe tener acceso a los componentes de la interfaz del área de
operaciones, deben poder leer las respuestas pero no modificarlas.

El área de operaciones no debe tener acceso a los componentes del área comercial, debe
poder visualizar las solicitudes más no modificar.

Las direcciones Comercial, Tecnología y General deben tener sus firmas digitales de
autorización protegidas, es decir todos podrán verlas más no se podrán modificar excepto
por sus propietarios.

Propón brevemente un proyecto de administración de sistemas de información, por ejemplo,

uno que se pueda aplicar en tu trabajo, esta propuesta debe ser breve y de tu creación,
máximo media cuartilla, ya más adelante en la actividad 2, realizaras la propuesta de forma
más amplia.

En realidad, el ejemplo propuesto anteriormente en realidad no es nada más un ejemplo,

es un sistema que debe llevarse a cabo iniciando el 25 de enero y terminando el 1 de marzo,
he aprovechado este sistema que desarrollaré para trabajarlo en paralelo como actividad
de la materia y como sistema que se implementará en la empresa.
Redacta detalladamente la propuesta de la idea del proyecto y menciona a qué tipo de
proyecto de sistema de información corresponde.
La clasificación de este proyecto es de tipo informático y es un proyecto de tecnología
nueva.
En lo personal pienso que debemos tener una organización de proyecto lo más cercano a
la perfección, esto nos permitirá manejar tiempos, objetivos, metas y de esta forma
podremos realizar las pruebas que se requieran de manera precisa, leyendo las
aportaciones de mis colegas; pude observar que coincidimos mucho con la parte
fundamental de un proyecto “Tiempo, Objetivo y Meta” creo que todos tenemos en mente
que estas tres palabras son el principio que construye el proyecto y que nos permiten
administrarlo para lograr un resultado conveniente a nuestro trabajo y a nuestros usuarios.
En mi caso, es verdaderamente particular, ya que no consideramos el aumento de la
productividad del área de programación y desarrollo, esto es debido a que las herramientas
que yo desarrollo normalmente son de consumo interno y esto significa que la herramienta
hará más eficiente a otra área y no al proyecto en sí. Los proyectos internos podrían
consumir tiempos de 1, 2 o 3 meses en desarrollarse y sí consideramos el tiempo de
elaboración, objetivos y metas pero no consideramos exigencias del cliente externo,
solamente la funcionalidad del cliente interno que en este caso son mis compañeros de
trabajo de otras áreas.
A pesar de que se supone que debemos tener una cultura de administración de un proyecto
y nos estamos formando como desarrolladores de software, que además se supone que
debemos tener metodologías de trabajo para realizar una gestión de proyecto realmente
satisfactoria; en realidad, hay veces en que las empresas nos piden romper parte de estos
protocolos y gestionar a través de alguna subcultura; es decir, “olvídate del tiempo
propuesto para los módulos, llévalos a cabo hoy porque se necesitan ya” y esto hace que
tengamos que mover el plan de trabajo y por lo mismo replantear los métodos ocupados
para el proyecto.
.
Lo principal es tener sintonía con las áreas que van a utilizar el sistema, para esto debemos
considerar los siguientes elementos:
Recursos
Primero: Para mí, antes que nada, debo saber con qué recursos cuento para realizar un
proyecto. Es decir; si cuento con un equipo de trabajo o si solamente voy a ser yo quien
lleve a cabo el proyecto, si es de prioridad o si es proyecto común, si tengo la red disponible
o si solamente será una plataforma de escritorio. Estos son elementos importantes para
saber con qué cuento y con qué no cuento.
Objetivo
Segundo: Para mí es importante saber primero el objetivo del proyecto, cual es la necesidad
que deberá cubrir, esto es porque muchas veces escuchamos las necesidades y el usuario
normalmente se sube a las nubes pidiendo funciones que realmente son disfuncionales y
que no tienen nada que ver con la verdadera necesidad del resultado del proyecto.
Especificidad
Tercero: Yo considero la especificidad del sistema después de considerar los recursos y el
objetivo, esto es debido a que en puerta tengo otros proyectos que debo realizar en tiempo
y forma, pero, a esto le corresponde que debo saber si es un proyecto único o si tendrá
replicas.
Destinatario
Cuarto: Antes de considerar el tiempo y las actividades, siempre considero a quién va
dirigido el proyecto, esto tiene la finalidad de saber ahora sí el tiempo que se puede calcular
y las actividades que serán distribuidas
Actividades
Quinto: Ahora sí puedo considerar la distribución de actividades y planearlas para poder
calcular correctamente un tiempo de elaboración y entrega del proyecto ya finalizado.
Tiempo
Sexto: habiendo organizado los puntos anteriores, ya puedo estimar un tiempo de
elaboración y entrega para pruebas finales e implementación.
De esta forma, el sistema propuesto de solicitudes de servicio interno; quedaría de la
siguiente manera:
Recursos: Red interna, programa de escritorio en Visual Basic, base de datos en Access,
acceso remoto por carpetas compartidas.
Objetivo: es un programa que permite a los ejecutivos de ventas realizar solicitudes de
servicio interno, es decir que les sea parametrizada cada una de las soluciones que han
vendido a sus clientes, el área de operaciones podrá recibir la solicitud en tiempo real y de
esta manera podrán gestionar la solicitud del área de ventas.
Especificidad: se trata de un proyecto único de baja prioridad.
Destinatario: área de ventas, área de operaciones y las respectivas direcciones; Comercial,
Tecnología y General.
Actividades: Desarrollo de la interfaz gráfica, conexión a la base de datos, creación de
carpetas compartidas, elaboración de las funciones, recabar requerimientos funcionales y
no funcionales. Entrevistas con las áreas, cuestionario de preguntas a las áreas. Requisitos
de sistemas operativos de las áreas, compatibilidad del lenguaje con los sistemas
operativos. Designar a los usuarios que llevarán a cabo el piloto del proyecto.
Tiempo: se estima un tiempo de un mes y una semana, es decir; del 25 de enero 2018 al 1
de marzo 2018.
Es evidente que debemos tener ya para este punto el ciclo de vista del proyecto, por lo que
consideraremos los siguientes pasos.
Aprobación: Pondremos a consideración de viabilidad el proyecto ante la Dirección
Comercial, Dirección de Tecnología y la Dirección General. Una vez que realicen todas las
preguntas y consideraciones pertinentes, deberán aprobar el proyecto para su puesta en
marcha (De ser rechazado, se regresa para su análisis y reconsideraciones para volverse
a presentar).
Definición: Como en el punto anterior, el proyecto debe sufrir cambios y probablemente
rechazos por parte del staff de Direcciones, así mismo por parte de los usuarios finales
quienes son los principales interesados en trabajar con el sistema. Aquí podremos
replantear todas las veces que sean necesarias las soluciones que se necesiten para
modificar el sistema hasta llegar a una idea de versión prototipo que se pretende llevar a
cabo.
Planificación: Aquí deberemos obtener todas las especificaciones del sistema, además
deberemos contar con la lista de tareas que vamos a realizar junto con el tiempo que nos
llevará cada tarea, no consideramos el tiempo de entrega final, solamente el tiempo de cada
tarea. Yo normalmente no ocupo mucho los diagramas de PERT, prefiero los diagramas de
Gantt que de alguna forma permite una mejor planificación de los tiempos, además de que
me proporciona la vista del cumplimiento de objetivos de forma más gráfica.
Ejecución: para esta etapa, ya debemos tener todos los requerimientos y funcionalidades
planteadas por las áreas además de formatos y demás escritos y aprobaciones para llevar
a cabo el proyecto. Tomando en cuenta que la idea ya es bastante clara y ya no estamos
en etapas de reconsideraciones porque ya llegamos al punto de elaboración con todos los
puntos cubiertos, en caso de no ser así estaríamos de regreso en la planificación para
replantear y reestructurar las ideas del proyecto.
Cierre: En el caso del sistema propuesto, debemos considerar primero las pruebas que han
realizado los usuarios piloto, esto quiere decir que; una vez que se cuente con la aprobación
de funcionalidad del usuario entonces podemos considerar que nuestro proyecto ya está
por concluir, es importante mencionar que en este caso no se requiere de presupuestos
debido a que el sistema es de consumo interno y que no cuenta con contratos de prestación
de servicio. Sí debemos considerar la documentación correspondiente que sería acerca del
glosario, índice, informes de pruebas y de avances hasta su culminación.
Las características con las que debe cumplir el proyecto en cuestión son los siguientes:
Trascendencia: Logra mejorar la forma en que se solicitan los servicios internos del área de
ventas y logra beneficiar al área de operaciones. Marca la diferencia entre solicitar a través
de un correo electrónico que se puede perder y una base de datos que contendrá las
solicitudes de manera centralizada.
Manejo de Recursos: En este caso, solamente es un programador, la red interna y los
ordenadores de los colaboradores de las áreas.
Discontinuidad del proyecto: Es proyecto único, tiene un inicio y su final de elaboración e
implementación.
Dinamismo: El proyecto aún ya aprobado, puede sufrir una serie de cambios durante la
marcha, es decir; si se requiere de introducir un campo nuevo o si se requiere de una
función que condicione algún campo que sea obligatorio llenar cuando otros campos están
llenos o si el campo se debe dejar vacío cuando otros campos estén vacíos.
Irreversibilidad: El proyecto se debe elaborar conforme a lo planeado con el estándar que
se planteó, habrán cosas que pueden ser susceptibles a cambios, pero el proyecto y su
esencia no deben ser susceptibles a ningún cambio.
Influencias Externas: En este caso no existen, es un sistema de consumo interno.
Explica las funciones que realizará el proyecto propuesto, como muestra la primera etapa
del ciclo de vida de un proyecto, que es la generación de una idea, identificando
características y funciones del proyecto propuesto, bosquejando una propuesta del
proyecto de sistema de información.
Este sistema debe proporcionar la facilidad de proveer una solicitud vía sistema desde el
área de ventas y que va dirigida al área de operaciones, cuando el área de ventas realiza
una solicitud; debe poder crear un número de servicio de forma automática, esto es para
que el número de servicio sea único e inamovible para que no se duplique ni se confunda.
El área de ventas debe tener la claridad de un sistema amigable que les permita llenar en
unos cuantos pasos una solicitud para solicitar un servicio, en otras palabras debe tener lo
siguiente:
1. Debe generar un número de servicio.
2. Nombre del ejecutivo de ventas.
3. Nombre del cliente del ejecutivo de ventas.
4. Tipo de proyecto de ventas.
5. Fecha de solicitud.
6. Fecha de revisión.
7. Descripción del proyecto.
8. Firmas digitales de autorización.

Esto ya lo he detallado antes, pero es importante desmenuzar cada uno de los puntos
1. Debe generar un número de servicio: Debe ser único por cada solicitud de servicio,
este servirá como clave de cada proyecto que genere el área de ventas (entiéndase
por proyecto cada venta de soluciones de software).
2. Nombre del ejecutivo de ventas: Es importante diferenciar de quien es el propietario
del proyecto de ventas, es por ello que debe incluir el nombre del empleado o
ejecutivo de ventas.
3. Nombre del cliente del ejecutivo de ventas: Así como se debe diferenciar el nombre
del ejecutivo de ventas, es muy importante saber a qué cliente del ejecutivo se le
proporcionará el servicio que ofrece la empresa.
4. Tipo de proyecto de ventas: Así mismo, se debe incluir un campo que proporcione
una forma de saber qué tipo de solución se le proporcionará al cliente del ejecutivo
de ventas; es decir, si se trata de un CRM, CLM, ERP, Validación de ficheros
médicos, Software Ad-Hoc, etc.
5. Fecha de solicitud: El campo de fecha de solicitud, se maneja con un campo especial
que contiene un calendario en el cual se puede seleccionar la fecha de la solicitud
que no necesariamente tiene que ser la de hoy.
6. Fecha de revisión: Esta fecha es igual que la anterior, esta sirve para solicitar una
reunión entre el ejecutivo de ventas y el área de operaciones, esto tiene la finalidad
de omitir los correos electrónicos y fijar la fecha y hora a partir de este campo.
 7. Descripción del proyecto: Este es un campo de texto que permite brindar bastante
libertad al ejecutivo para que realice la solicitud con los detalles de su proyecto, en
otras palabras; esto le permite al ejecutivo explicar su proyecto y de qué se trata.
8. Firmas digitales de autorización: Un proyecto no puede ser iniciado sin las firmas
correspondientes de autorización, en este caso las firmas serán de manera digital.

Requerimientos operaciones:

1. Fecha de inicio para procesar el proyecto de ventas: En la contraparte que

correspondería al área de operaciones, debe contar con una fecha para iniciar el
proyecto que solicitó el área de ventas. Esto es para proporcionar una fecha grabada
que podrá ver el área de ventas en su interfaz.
2. Acuerdos del proyecto: Este es un campo en el cual el área de operaciones guarda
la minuta de la junta de acuerdos, es algo así como expresar lo que el área de
operaciones acordó con el área de ventas.
3. Fecha de revisión con el área comercial: En este campo, el área de operaciones
proporciona una fecha de revisión con el ´rea de ventas; esto tiene la finalidad de
revisar el proyecto ya terminado.
4. Fecha de entrega de la maquila del proyecto al área comercial: Este campo tiene la
finalidad de marcar una fecha en el calendario como compromiso de entrega final
del proyecto.
5. Firmas digitales de acuerdo de entrega del proyecto terminado: Estos campos están
destinados a que los tres directivos de la empresa junto con el área de operaciones
y el ejecutivo comercial firmen de manera digital la aceptación de lo que el área de
operaciones entrega al área de ventas, de esta manera el área de ventas recibe de
conforme acuerdo el proyecto.

Aunque en la planeación del proyecto no siempre se incluyen los requerimientos

funcionales y no funcionales de un desarrollo de software, sería importante mencionar los
lenguajes, en este caso sería HTML, PHP, JavaScript. El proyecto sería basado en web y
permitirá realizar solicitudes aunque el ejecutivo no se encuentre en la oficina.
No obstante, en la planificación debemos obtener toda la información que nos permitirá
definir claramente las especificaciones que realizará el sistema, así pues; en este caso
tenemos que después de hablar con las respectivas áreas, debemos considerar las
siguientes especificaciones:
1. El sistema debe estar conectado a una base de datos en donde se guardará el
histórico de solicitudes.
2. La base de datos debe ser con tablas relacionales ya que tendrá que almacenar por
separado el motivo del proyecto de los demás campos, esto es más por comodidad
de no saturar la base de datos.
3. El sistema deberá contar con funciones dinámicas diseñadas en PHP, estas
permitirán realizar en envío de la información a la base de datos, pero también,
permitirá hacer el llamado a la base de datos para imprimir en pantalla la información
guardada.
4. Los campos de la interfaz serán los siguientes:

a) Txt_servicio: campo de texto

 b) Txt_ejecutivo
c) Txt_ejecutivo_cliente
d) Txt_proyecto
e) Txt_fecha_solicitud_ventas
f) Txt_fecha_revision_ventas
g) Txt_descripcion
h) Txt_firma_ejecutivo
i) Txt_firma_comercial
j) Txt_firma_operaciones
k) Txt_firma_tecnologia
l) Txt_firma_dgeneral
m) Txt_fecha_inicio
n) Txt_acuerdos
o) Tet_fecha_revision_terminado
p) Txt_fecha_entrega
q) Txt_firma_ejecutivo_fin
r) Txt_firma_comercial_fin
s) Txt_firma_operaciones_fin
t) Txt_firma_tecnologia_fin
u) Txt_firma_dgeneral_fin
v) Txt_fecha_inicio_fin
w) Txt_acuerdos_fin
x) Btn_nuevo
y) Btn_grabar
z) Btn_eliminar
aa) Btn_eliminar
bb) Txt_fecha_actual

Conclusiones
La administración de este proyecto será importante para dar la forma correcta al mismo, de
hecho es fundamental considerar todos los aspectos mencionados para llevar a cabo un
proyecto de alta calidad, es posible que la fecha de inicio sea cambiada por cuestiones de
cambios en algunos elementos del proyecto pero lo principal es que se respete la idea
principal y en sí no perder de vista que se trata de un proyecto de solicitudes de servicio
interno. El usuario muchas veces trata de hacer cambios de último momento en sus
requerimientos, pero siempre debemos pensar hasta dónde llega la intervención del usuario
en el proyecto como usuario y en donde debemos impedir que el usuario controle el
proyecto dentro de la programación.
Es muy importante llevar a cabo una buena administración del proyecto, en mi caso; soy el
desarrollador de este proyecto y para mí, es muy importante aprender el correcto
planteamiento de un proyecto ya que en la medida en la que vayan creciendo mis
conocimientos; también mis proyectos serán más robustos.
El proyecto que planteo, en sí, es una requisición de mi empresa y en particular es una
solicitud del Director comercial, aproveché este proyecto para aprender y aplicar al mismo
tiempo, aquí en la materia; estoy aprendiendo mejores prácticas para administrar un
proyecto y en la empresa estoy llevando a la práctica lo aprendido en la materia.

Referencias:
UNADM. (2018). Fundamentos de Proyectos. 22-01-2018, de UNADM Sitio web:
https://unadmexico.blackboard.com/bbcswebdav/institution/DCEIT/2016_S2_B1/DS/06/DA
PI/U1/Unidad_1_Fundamentos_de_proyectos.pdf