You are on page 1of 55

ACTIVIDADES NO PLANIFICADAS

QUE CASUALMENTE LLEGAN


A DESTINO A MUY ALTO
PARTIDA
COSTO

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.

Por cada grupo de personas obtenemos:


Jefe de Proyecto
 Actitud Positiva/Negativa en la cola-
boración con el equipo de Desarrollo
 Perspectivas diferentes de la aprecia-
ción del problema
 Sugerencias, soluciones según la con-
veniencia de cada grupo.
 Falta de capacitación profesional en
el Grupo de Desarrollo.
 Etc. Equipo de
Desarrolladores
 La Perspectiva del Usuario Final.
 ¿Qué sistema? Yo no he visto un nuevo sistema
 Es muy bonito pero, ¿hace algo que sea de utilidad?
 !Puede funcionar, pero su empleo resulta espantoso!

 La Perspectiva del Cliente


 ¡Si hubiera sabido el precio real nunca hubiese llegado a un acuerdo!
 ¡De que sirve que lo entregue hoy si lo necesitábamos el mes pasado!
 De acuerdo funciona, pero su instalación ha sido tan difícil que mi personal técnico
nunca confiará en el nuevo programa
 No lo quise desde un principio
 Todo ha cambiado ahora. Necesitamos un sistema completamente distinto

 La Perspectiva del Diseñador


 Hemos construido lo que dijeron que querían...
 No tuvimos el tiempo necesario para hacerlo mejor
 No me culpes nunca antes he realizado un análisis orientado a objetos
 ¿Cómo puedo resolverlo? No se como se supone que debe funcionar
 !Dijimos que eso era imposible, pero nadie nos escucho!
 El sistema esta bien, el problema son los Usuarios
 La Perspectiva del Usuario Final.
¿Qué sistema? Yo no he visto un nuevo sistema
Cuando un proyecto no se culmina en los tiempos
establecidos o se anula, los afectados son los usuarios
finales que ven truncos los beneficios que esperaban.

Es muy bonito pero, ¿hace algo que sea de utilidad?


Un sistema que no tiene en cuenta las sugerencias de mejora de sus usuarios finales
tiende a entorpecer su trabajo, y por lo general el sistema no es aceptado.
Los peores casos ocurren cuando del sistema creado depende la vida de usuarios.

!Puede funcionar, pero su empleo resulta espantoso!


Uso desagradable de sistemas que no cumplen criterios mínimos de calidad:
 Pobre diseño de interfaz
 Es difícil de usar por los procesos engorrosos que hay que hacer
 Secuencias inapropiadas/ilogicas de entrada de datos
 Un sistema de ayuda inexistente/ineficaz, mensajes de error incomprensibles
 Tiempos de respuesta pobres y poca confiabilidad en su funcionamiento.
 La Perspectiva del Cliente.
Generalmente el Cliente (Comité Directivo, dueños, Jefes) tiene una
participación tangencial respecto a los procedimientos y detalles de
los procesos, les interesa los resultados finales y solo aquellos que
directamente les ayuda a tomar decisiones. Son pocos los Clientes
que se involucran directamente en los procesos y son a su vez
Usuarios, a menos de que la empresa sea de menor envergadura y
amerita de que el cliente sea el usuario final del sistema.

¡Si hubiera sabido el precio real nunca hubiese llegado a un acuerdo!


Cuando un proyecto no se culmina en los tiempos establecidos encarece su costo de
desarrollo, por lo que resulta a veces que los costos de terminación superan a los beneficios
proyectados.

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.

Todo ha cambiado ahora. Necesitamos un sistema completamente distinto


Un proyecto que se planifica por tiempos largos (más de un año) debe tener en
consideración que el sistema en su concepción de necesidades al cabo de un año puede
cambiar de requisitos, lo que invalidaría el esfuerzo de nuestro equipo técnico.
A medida de que el usuario/cliente conoce mas de las bondades del tener un sistema
informático, crece la tendencia a pedir mas del sistema en desarrollo
También los sucesos externos pueden tener un impacto drástico en la concepcion de los
requerimientos/procesos iniciales del Sistema.
 La Perspectiva del Diseñador
Hemos construido lo que dijeron que querían...
Es necesario dejar Actas de Conformidad respecto a los
requerimientos de los usuarios antes de pasar a cualquier otra
etapa del proyecto, porque una vez finalizado, estas Actas nos
sirven de respaldo para verificar que se ha cumplido con los
requerimientos solicitados.

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:

 No se ha capacitado al usuario final en el uso del sistema, es subsanable.


 No se ha hecho un correcto análisis de los requerimientos. Esto ultimo es un
indicativo de que el producto no es lo esperado por el usuario y/o cliente y que no se
ha hecho un adecuado desarrollo en el equipo de trabajo, esto es critico.
Flynn (1998) Clasificación de fallas en un proyecto
Tipo de Motivo del Fallo Comentarios
fallo
Problemas Se aborda el problema inadecuado Conflictos del sistema con la estrategia
de Calidad empresarial
Se ignoran las influencias más amplias Se puede ignorar la cultura empresarial
El análisis, diseño o implementación se El equipo carece de los conocimientos
realiza incorrectamente necesarios o de los recursos apropiados
Se emprende un proyecto por un motivo Empuje tecnológico o tirón empresarial
equivocado
Problemas Los usuarios cambian de idea
de
Sucesos externos cambian el entorno Nueva legislación
productivid
ad La implementación no es factible Puede que no se haya conocido hasta que el
proyecto haya comenzado
Control pobre del proyecto Gestor del proyecto inexperto
Problemas de Calidad
Un sistema es de calidad por lo general cuando cumple dos objetivos primordiales:
• Cumple con el propósito para el cual fue diseñado.
• Si al medir sus resultados estos son los esperados.

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.

Análisis, Diseño e Implementación incorrecto de los requisitos


Debemos poner énfasis en los requerimientos solicitados por los tres grupos
involucrados.
Por Ejemplo El Cliente podría estar inconforme con los objetivos propuestos por el
equipo de desarrollo si no se han conciliado las necesidades empresariales por lo que es
contratado el equipo. Los Usuarios finales podrían estar inconformes con el
funcionamiento del diseño de las interfaces. Los desarrolladores podrían estar
inconformes con las herramientas disponibles y sus solicitudes de recursos mal
atendidos.
Se emprende el proyecto por un motivo equivocado
Sres. hacemos énfasis en los objetivos por los que debe ser creado un sistema y
que debe estar acorde a las estrategias empresariales. No es posible que la
moda se imponga al raciocinio y se desarrolle sistemas que a la larga solo
generan gastos o el fracasos de la empresa. Por ejemplo se tiene el caso de
Internet, todas la empresas creen que hacer negocios en internet (e-comerce)
es ser competitivo y estar al día con las tecnologías, muchas empresas que
empezaron vendiendo productos en internet, cerraron; el motivo fue que
realmente no analizaron las ventajas y desventajas de usar internet aplicado a la
naturaleza de su empresa. Siempre es necesario sustentar bien las bases en las
que se desarrollará el proyecto, beneficios y costos proyectados ante el cliente a
fin de no cometer errores.
Problemas de Productividad
Los requisitos cambian
El cambio de requisittos en un proyecto pueden retrasar las actividades de la misma y
hacer sentir la sombra del fracaso, es más cuando mas demore el proyecto mas cambios
solicitara el cliente, cosa que podría atascar el proceso y degenerar en un aborto del
proyecto.
Los cambios siempre se darán pero es preferible minimizar los mismos vía acuerdos con
el cliente y usuarios, luego de hacer un exhaustivo análisis de requerimientos.

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 otro caso, el prototipado puede ser


util inmediatamente antes de algún/todo
el desarrollo incremental en modelos
incrementales o evolutivos.
 Es un método menos formal de  No se conoce cuando se tendrá un
desarrollo. producto aceptable.
 El prototipeo es una técnica para  No se sabe cuantas iteraciones serán
comprender las especificaciones. necesarias.
 Un prototipo puede ser eliminado.  Da una falsa ilusión al usuario sobre
 Un prototipo puede llegar a ser parte la velocidad del desarrollo.
del producto final.  Se puede volver el producto aún y
 Útiles cuando los requerimientos son cuando no este con los estándares.
cambiantes.
 Cuando no se conoce bien la
aplicación.
 Cuando el usuario no se quiere
comprometer con los requerimientos.
 Cuando se quiere probar una
arquitectura o tecnología.
 Cuando se requiere rapidez en el
desarrollo.
 Los productos de software son
creados a través de múltiples
repeticiones del proceso del
ciclo de vida. Se rompen un
mini-proyectos.
 Estos modelos han sido
aplicados al desarrollo de
software.
 Aun no han madurado al
punto de ser aplicados como
modelos de desarrollo con
tiempos y limitaciones de
costos.
 El producto avanza a pasos firmes  Es complicado.
solucionado riesgos en cada  Requiere de mucha administración.
iteración.
 El producto termina con todos los  Difícil de definir los objetivos, metas
riesgos resueltos. que indiquen que podemos avanzar
 Se pueden incluir otros métodos de al siguiente ciclo.
desarrollo en las iteraciones.  Se puede caer en un desarrollo de
 A medida que el costo aumenta, los nunca acabar.
riesgos se reducen.
 Se tienen puntos de control en cada
interacción.
 Impulsa un proceso iterativo de
desarrollo.
 Cada ciclo es una versión del
producto.
 Utiliza metas definidas para
marcar la transición entre las
distintas etapas.
 Ofrece mayor poder de decisión
a los usuarios.
 Busca mejorar la calidad y
creatividad.
 Etapas claramente definidas con  Dado que la mayoría de las decisiones
metas, entregables y responsables. son en consenso por el equipo en su
 Se establecen roles asociados al conjunto, en ocasiones toman más
modelo que promueven la tiempo de lo debido.
participación de todos.  Para proyectos pequeños puede
 Involucra muy de cerca al usuario. resultar poco practico.
 El considerar versiones hace que se
dejen de lado algunas decisiones.
 Permite construir el proyecto en etapas incrementales en donde cada etapa agrega
funcionalidad.
 Cada etapa consiste de requerimientos, diseño, codificación, pruebas, y entrega.
 Permite entregar al cliente un producto más rápido en comparación del modelo de
cascada.
Reduce los riesgos ya que:
 Permite ver el progreso a través de sus nuevas  Requiere de mucha
versiones. planeación, tanto
 Provee retroalimentación a través de la administrativa como
funcionalidad mostrada. técnica.
 Permite atacar los mayores riesgos desde el
inicio.  Requiere de metas claras
 Se pueden hacer implementaciones parciales si se para conocer el estado del
cuenta con la suficiente funcionalidad. proyecto.
 Las pruebas y la integración es constante.
 El progreso se puede medir en periodos cortos de
tiempo.
 Resulta más sencillo acomodar cambios al acotar
el tamaño de los incrementos.
 Se puede planear en base a la funcionalidad que
se quiere entregar primero.
 La solución se va mejorando en forma progresiva a
través de las múltiples iteraciones.
 Incrementa el entendimiento del problema y de la
solución por medio de los refinamientos
sucesivos.
Un Proyecto...
Un proyecto es una organización transitoria de individuos dedicados a alcanzar un
objetivo especifico dentro de un periodo de tiempo, un presupuesto, y un objetivo
técnico.

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.

Lo que nos indica que es:


• Temporal y Unico, ya que involucra hacer algo que no se ha hecho antes.
¿ Que Modelo ?
• Dado que cada proyecto es único, no existe un modelo que se aplique al 100% a
todos los proyectos de una organización.
• Una organización puede contar con uno o más modelos de desarrollo para ser
utilizados dependiendo del tipo de proyecto.
• El modelo seleccionado tendrá influencia en el éxito del proyecto y en el tipo de
decisiones que se deberán hacer.

¿ 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:

You might also like