Professional Documents
Culture Documents
LLEGADA
PLANIFICACION Y CONTROL DE
ACTIVIDADES
ACTIVIDADES NO PLANI-
FICADAS QUE NO
LLEVAN A NINGUN
LUGAR
El desarrollo de Sistemas de Información Comité Directivo,
Usuarios Finales
Empleados
es una actividad estrechamente relacio- Jefes
nada con las personas de la Empresa.
Es necesario planificar adecuadamente los plazos de entrega y tomar un control sobre los
costos incurridos. Si se preveé que los costos que se incurrirán en el sistema no justifican los
beneficios esperados, es mejor replantear los costos o en su defecto desestimar el proyecto.
La Perspectiva del ¡De que sirve que lo entregue hoy si lo necesitábamos el mes
Cliente.
pasado!
Un sistema que no se entregue a tiempo puede amenazar la exis-
tencia jurídica de una empresa, es por ello que los equipos de
proyectos de desarrollo de sistemas se consideran como engra-
najes en las actividades de cualquier empresa, no entregar un
producto a tiempo retrasa actividades en la empresa, puede ge-
nerar perdidas y hasta sacarla del medio competitivo empresarial.
De acuerdo funciona, pero su instalación ha sido tan difícil que mi personal técnico nunca
confiará en el nuevo programa
Cuando se instalan sistemas mal concebidos la imagen y confianza que se depositaba en el
sistema y en el equipo de desarrollo desaparece.
Por ejemplo un equipo de desarrolladores instaló un servidor de datos en red para que los
usuarios de toda la empresa deje de usar sus discos locales y compartan información en
esta unidad, la intensión era buena, compartir información y evitar costos en el uso de Cds,
Usb. El sistema llego a instalarse pero al cabo de 6 semanas colapsa y se pierde
irreversiblemente la información almacenada, a pesar de ser superado y corregido el
problema, el servidor de datos dejo de ser usado por la mayoría, pues los usuarios
regresaron a la actividad de sus copias personales.
La Perspectiva del Cliente.
No lo quise desde un principio
Las relaciones en la empresa entre sus componentes: Comité
Directivo, Jefaturas, Usuarios finales, pueden ser complejas y
hasta contraproducentes, a tal punto de rechazar la
implementación parcial o total de un sistema.
Es necesario en estos casos concertar reuniones con los
involucrados a fin de planificar predisposiciones, acuerdos y
respecto a las actividades del proyecto.
Puede que los usuarios reclamen al presentárseles el producto final y es porque no se les
ha dado a conocer que no pueden cambiar de opinión después de un tiempo porque va
en contra de los objetivos de la empresa planteados en su debida oportunidad, y que
ejecutar sus nuevas necesidades es asumir nuevamente otro ciclo de desarrollo, es por
ello que se debe establecer lo mas claramente posible los requerimientos antes de iniciar
el proceso de diseño y desarrollo.
La Perspectiva del Diseñador
No tuvimos el tiempo necesario para hacerlo mejor
El presupuesto asignado a un proyecto de trabajo siempre
determina el tiempo general del proyecto y los plazos de
entrega en cada etapa del proyecto, los cuales deben ser
respetados.
Si bien es cierto que es angustiosa la presión por culminar bien cada etapa del proyecto,
es peor si sesgamos tiempo del análisis para empezar a diseñar construir cualquier cosa
con tal de satisfacer al usuario/cliente, esto por lo general tira por los suelos las
actividades programadas y el producto final, porque se esta entregando un sistema que
adolece de requisitos que no se tuvieron en cuenta, procesos que no están
debidamente consistenciados, en general un mal producto que no satisface las las
necesidades para las que fue planificado.
La Perspectiva del Diseñador
No me culpes nunca antes he realizado un análisis orientado
a objetos
El equipo de proyecto debe contener personal homogéneo
en habilidades a fin de conversar un mismo idioma y
desarrollar los trabajos sin retrasos o incompatibilidades.
Nuestros analistas de sistemas deben dominar una metodología en común, por ejemplo
Orientado a Objetos, mal haríamos en considerar análisis parciales unos orientados a
objetos y otros en un análisis estructurado porque tendría dificultades insalvables en la
integración de las bases diseñadas.
Nuestros programadores deben trabajar en un lenguaje de programación común o por
lo menos compatibles, de preferencia todos en java o C++
Nuestro equipo de especialistas en redes igualmente deben conocer a detalle la
metodología a usar a fin de coordinar la implementación física de las líneas en las que
circulara nuestro sistema, soporte técnico y mantenimiento de los equipos.
La Perspectiva del Diseñador
¿Cómo puedo resolverlo? No se como se supone que debe
funcionar
Esto sucede cuando a nuestros programadores se les solicita
mejorar o modificar un sistema anterior en el cual no ha tenido
participación. Lo principal aquí es solicitar los manuales de diseño,
programación y los documentos relacionados a dicho sistema.
No debemos caer en este error documentando adecuadamente todos nuestros procesos
en cada una de las etapas de desarrollo del proyecto
!Dijimos que eso era imposible, pero nadie nos escucho!
Es necesaria la confianza entre el equipo de desarrollo y el Jefe del Proyecto a fin de poder
sincerar sus habilidades, muchas veces son muy exigentes las metas propuestas por el
cliente y al ser tratadas con el equipo de desarrollo, el jefe de proyecto se compromete a
realizar las metas exigentes en el tiempo solicitado, pero no sabe si su equipo tendrá los
conocimientos y habilidades necesarias para cubrir las expectativas solicitadas.
Pueda que no esten debidamente capacitados para las exigencias del software solicitado, o
sientan que el tiempo es demasiado poco para alcanzar a entregar un producto de calidad.
La Perspectiva del Diseñador
El sistema esta bien, el problema son los Usuarios
Sres. antes de formar juicios de esta índole, es necesario hacer
una investigación del porque el sistema no esta siendo usado
por los usuarios en forma adecuada, las situaciones mas
probables son:
El problema equivocado
Pueda que el Cliente no tenga bien definido las metas que desea alcanzar e incluso que
no tenga planificado estrategia alguna como empresa, entonces allí estamos ante un
problema, es necesario concertar con nuestro cliente y definir claramente cuales son sus
metas empresariales a fin de acoplar a ellas las metas del proyecto.
En caso de que equipo de desarrollo no tenga una buena comunicación con el cliente
podría caer el problema de desarrollar un excelente sistema que no satisface las metas u
objetivos de la empresa, el error genera perdida de tiempo y recursos ante lo cual
debería corregirse desde un principio.
Se ignora el contexto
Sres. Los prejuicios de formar en nuestra mente la idea de «yo se como hacerlo» sin
hacer las consultas tanto a USUARIOS como ha CLIENTES hay que desterrarlas, este tipo
de pensamiento genera que tengamos sistemas con procedimientos engorrosos y que
hicieron oídos sordos a las sugerencias de los involucrados. Es necesario oír a ambas
partes en la etapa de requerimiento y análisis, puesto que podemos encontrar puntos de
vistas antagónicos en el desarrollo de las actividades de la empresa de ambas partes, y
las cuales debemos exponer, aclarar y determinar con los involucrados a fin de tener
claro que es lo que se va a desarrollar.
Sucesos externos
Todo proyecto siempre se vera amenazado por sucesos externos sobre los cuales no
podemos tener control, es necesario que se haga un análisis del entorno y de los sucesos
que podrían afectar el funcionamiento del sistema a fin de minimizar riesgos.
Problemas de Productividad
Gestión Inadecuada del proyecto
El Director/Jefe del proyecto es el responsable del éxito del sistema, el fracaso siempre
se debe a una mala planificación y uso de los recursos asignados.
Implementación no factible
A veces proyectos muy ambiciosos resultan inoperables, por ejemplo el querer unir
diversos sistemas o bases de datos requiere de hacer “parches” implementaciones que
solucionan temporalmente los problemas, hasta que los requerimientos hacia el sistema
crece y con ello los “parches” que cada vez se hacen imposibles de solucionar, a la larga
la unión de estos sistemas resulta incompatibles y se tiende a iniciar con uno nuevo que
involucre a todos los sistemas relacionados.
Costos asociados a los fallos
Aspecto del Ejemplo Efectos Inmediatos Otras consecuencias
Diseño
Interfaz de Organización ilógica Tiempo perdido Pérdida de confianza en el
Usuario de la pantalla sistema
Pantallas de difícil Aumento de la Aumento las bajas temporales
lectura frustración
Mensajes de ayuda Aumento de la tasa de Aumento de la rotación del
de poca utilidad errores personal
Ejecución del La respuesta del Igual o peor que antes Aumento de los costes de
Programa sistema es lenta funcionamiento
Almacenamie Pérdida de datos Trabajo extra para Disminución de los ingresos
nto de Datos volver a introducir los
datos
Salidas no fiables Trabajo extra al Pérdida de la confianza de los
verificar los datos clientes, Pérdida de ventas
• Todo producto de software realiza tareas entre la idea inicial y el
producto final.
• Un Modelo de Desarrollo establece el orden en el que se harán
las tareas en el proyecto, provee recursos de entrada y salida
para cada una de las tareas.
• Es necesario destacar el ciclo de vida del proyecto y el modelo
de desarrollo.
• El ciclo de vida del proyecto ayuda a controlar las actividades
del proyecto desde el inicio al fin del mismo.
• El modelo de desarrollo es una guía para construir el producto.
• Ambos se complementan para generar el producto desde el
punto de vista técnico y administrativo.
El Modelo de Cascada.
El Modelo en V.
En Flor.
Prototipos
El Modelo de Espiral.
El Modelo de Procesos.
Desarrollo Incremental.
SECUENCIA
PURA Cumple con el ciclo de
desarrollo de software.
Este modelo tiene una
secuencia ordenada.
El trabajo de una etapa previa
es la entrada del siguiente
proceso.
SECUENCIA
Provee de un gran control
RETROALIMENTADA sobre las fechas de entrega y
entregables.
Establece criterios de entrada
y salida en cada fase
claramente definidos.
Excelente cuando se tiene un Tiene poca flexibilidad
producto estable y se conoce la Los proyectos en la practica
tecnología raramente siguen un flujo
Es un método muy estructurado secuencial.
que funciona bien con gente de Siempre es difícil para el cliente
mucha experiencia. mostrar todos los requerimientos
Provee estabilidad en los explícitamente y con mucha
requerimientos anticipación
La Planeación se puede hacer en El Cliente debe tener paciencia
forma anticipada No es factible de cambios una vez
Para proyectos grandes terminada una etapa
Poco apropiado para aplicaciones
para la toma de decisiones
Los Usuarios tienen una
participación limitada
Se hace una reexaminación del
modelo de ciclo de vida a fin de
asegurar la calidad del producto
Cuando cada proceso termina su
producto, las especificaciones de
prueba deben estar listo para
probar el producto
Se valida cada uno de los procesos
una vez terminada cada etapa.
Se basa en la estructura de una flor en la cual
cada pétalo será una etapa a realizar.
Sin embargo todas las etapas se deben de
REQUE- desarrollar al mismo tiempo para asi lograr
ANA-
RIMIEN
LISIS
que el procedimiento llegue a obtener un
-TOS producto final.
Este modelo puede contemplar las sgtes
PRUE-
DISEÑO etapas:
BAS
– REQUERIMIENTOS
IMPLE- CODI- – ANÁLISIS
MENTA FICA-
-CION CION – DISEÑO
– CÓDIFICACION
– IMPLEMENTACIÓN
– PRUEBAS
Un prototipo es una versión preliminar de un sistema de información con fines de
demostración o evaluación. (Una versión rápida)
Es usado para definir los requerimientos del sistema de manera
directa con el usuario a fin de retroalimentar al proyecto con
requerimientos omitidos o procedimientos innecesarios.
Puede ser usado para determinar requerimientos justo
antes de la fase de requerimientos.
En consecuencia...
Un proyecto:
• Tiene un principio y un fin.
• Debe de tener un objetivo (debe de ser medible).
• Requiere de un líder y de un equipo.
¿ Cual seguir?
Para seleccionar el modelo a adoptar habrá que hacerse una serie de
cuestionamientos:
– ¿Qué tantos son los riesgos del proyecto?
– ¿Qué tan claros están los requerimientos?
– ¿Se conoce bien la tecnología ha utilizar?
– ¿Visibilidad que requiere el proyecto?
– ¿Qué tanta planeación hacia adelante es requerida?
Criterios de Éxito
• Contar con un modelo debidamente documentado. (entradas, salidas,
entregables, aprobaciones)
• Los documentos deben de estar actualizados.
• La gente que participa en el proyecto debe estar capacitada en su uso.
• Se debe de reforzar el uso del modelo mediante supervisiones y
revisiones programadas.
• La alta gerencia debe soportar la utilización de un modelo.
• Cualquier desviación al modelo debe ser documentada y aprobada.
• Se debe de medir la eficiencia del modelo.
• Retroalimentar y ajustar.
Se muestra un cuadro comparativo considerando algunos criterios básicos, la
medida utilizada indica el nivel de efectividad del modelo de acuerdo al criterio
Desarrollo Iterativo: Ventajas
• Tolerable a cambios en los requerimientos
• Los elementos son integrados progresivamente
• Los riesgos son mitigados en etapas tempranas
• Permite a la organización aprender e improvisar
• Facilita el reúso, porque es fácil identificar partes
comunes diseñadas o implementadas
• Resulta un producto más robusto ya que los errores
se van corrigiendo en cada iteración
• El proceso puede ser improvisado y refinado en el
desarrollo
• Si no existe una disciplina de control, el proceso de desarrollo rápi-
damente degenera en caos
• La coordinación de las actividades y artefactos de los desarrollado-
res y equipos, involucra establecer flujos repetibles para la adminis-
tración de cambios de software. Esta coordinación permite una me-
jor identificación de los recursos básicos en las prioridades y riesgos
del proyecto.
• El control de cambios es más
que revisar entradas y salidas
en los archivos. Esto incluye
administrar los flujos, el desa-
rrollo paralelo, la integración
y la construcción del software.
Un Modelo es una simplificación de la realidad que describe
completamente un sistema desde una perspectiva particular
El modelado es
importante porque
ayuda al equipo a
visualizar, especificar,
construir y documentar la estructura y
el comportamiento de la arquitectura
del sistema
Un modelo correctamente diseñado usando tecnología
de objetos es:
• Fácil de entender: Claramente corresponde a la
realidad.
• Fácil de modificar: Cambios en un aspecto en
particular concierne
únicamente al objeto
que representa ese
aspecto
• Se implementa a
través de UML
UML “Lenguaje de Modelamiento Unificado” es un
compendio de los principales métodos de análisis y diseño
orientado a objetos
CARACTERISTICAS: