1

Ingeniería de requerimiento (ir): es el proceso de descubrir, analizar, documentar y verificar estos servicios y
restricciones.
Requerimientos: son la descripción de los servicios proporcionados por el sistema y sus restricciones
operativas. reflejan la necesidad de los clientes de un sistema que ayude a resolver algún problema como el
control de un dispositivo, hacer un pedido, encontrar información. es una declaración abstracta de alto nivel de
un servicio que debe proporcionar el sistema o una restricción. definición detallada y formal de una función del
sistema. existen dos tipos
• requerimiento del usuario: requerimientos abstractos de alto nivel.
• requerimiento del sistema: descripción detallada de lo que el sistema debe hacer.
Requerimiento del usuario: son declaraciones, en lenguaje natural y en diagramas, de los servicios que se
espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
Requerimiento del sistema: establecen con detalle las funciones, servicios y restricciones operativas del
sistema. el documento de requerimientos o especificación funcional del sistema debe ser preciso. puede ser
parte del contrato entre el comprador del sistema y los desarrolladores de software. se clasifican en
• requerimientos funcionales: se declaran los servicios que debe hacer el sistema, se debe declarar
como se debe comportar para entradas particulares. como lo que el sistema no debe hacer.
• requerimientos no funcionales: son restricciones de los de los servicios o funciones ofrecido por el
sistema. restricciones de tiempo sobre el proceso de desarrollo y estándares.
• requerimientos de dominio: provienen del dominio de aplicación del sistema y que refleja las
características y restricciones del sistema.
Requerimientos no funcionales:
- requerimientos del producto: especifican el comportamiento del producto. se dividen en:
a. usabilidad: esta categoría define aspectos relacionados con las dificultades que pueden
encontrar los usuarios al enfrentarse al uso del nuevo sistema. facilidad de aprendizaje: tiempo
de formación, número de cuadros de ayuda. ej: la interfaces del usuarios deberá ser simple
empleando componentes ajax.
b. eficiencia: esta categoría define aspectos que indican la proporción entre el nivel de
cumplimiento del sistema y la cantidad de recursos necesitados bajo condiciones establecidas.
rendimiento: es la rapidez de ejecución del sistema. (transacciones procesadas por segundo)
(tiempo de respuesta al usuario y a eventos), (tiempo de actualización de la pantalla) espacio
cuanta memoria se requiere. espacio en k bytes, número de chips de ram.
c. fiabilidad: es la probabilidad de que durante un determinado período de tiempo el sistema
funcione correctamente tal como espera el usuario. tiempo medio entre fallos .probabilidad de
no disponibilidad. tasa de ocurrencia a fallos (frecuencia de ocurrencia). disponibilidad. ej:
contará con una disponibilidad de 24 hs. del sistema. permitir ingresar tres veces como
máximo mal el usuario y contraseña.
d. portabilidad: la capacidad de un sistema para ser transferido desde una plataforma a otra.
capacidad de instalación, capacidad de sustitución, adaptabilidad, coexistencia, compatibilidad
con hardware o software, etc. ej: utilizará interfaces que se generan response que corren tanto
en browser de máquinas de escritorio como dispositivos móviles.

- requerimientos organizacionales: se derivan de políticas y procedimientos existentes en la

organización del cliente y del desarrollador. ej: estándares que se deben utilizar. requerimientos de
implementación en cuanto al lenguaje de programación. requerimientos de entrega: cuando se
entregará el producto y la documentación. su subclasificación: entrega, implementación, estándares.
se dividen en:
 2

• entrega: cuando se entregará el producto.

• de implementación: como los lenguajes de programación, el método de diseño a emplear.
• de estándares: definición de estándares en los procesos que deben utilizarse.
• requerimientos externos: ej: requerimiento de interoperabilidad con sistemas de otras
organizaciones, requerimientos legislativos y de ética. se dividen en:
• interoperabilidad: la manera en que el sistema interactúa con sistemas de otras organizaciones.
• ético: se definen para poder asegurar que será aceptado por los usuarios y por el público en
general.
• legislativo: deben seguirse para asegurar que el sistema funcione dentro de la ley.
• seguridad: esta categoría define aspectos relativos a las políticas de privacidad del sistema a
desarrollar. accesos al sistema, identificación y autenticación, protección de datos y privacidad.
Características de los requerimientos: las características de un requerimiento son sus propiedades principales:
• necesario: si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad,
características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del
producto o del proceso.
• conciso: un requerimiento es conciso si es fácil de leer y entender. su redacción debe ser simple y
clara para aquellos que vayan a consultarlo en un futuro.
• completo: un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir,
si se proporciona la información suficiente para su comprensión.
• consistente: un requerimiento es consistente si no es contradictorio con otro requerimiento.
• no ambiguo: un requerimiento no es ambiguo cuando tiene una sola interpretación. el
lenguaje usado en su definición, no debe causar confusiones al lector.
• verificable: un requerimiento es verificable cuando puede ser cuantificado de manera que permita
hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
Documentos para especificar requerimientos: el documento de requerimientos del sistema (algunas veces
denominado especificación funcional) debe ser preciso. debe definir exactamente qué es lo que se va a
implementar. puede ser parte del contrato entre el comprador del sistema y los desarrolladores del software.
• ieee/ansi 830 -1998
• uml (notación gráfica) notación de casos de usos
• xp historias del usuario
• up visión
• scrum pila de producto (product backlog), la pila del sprint (sprint backlog)
Lenguaje estructurado: el lenguaje natural estructurado es una forma de redactar los requerimientos del
sistema donde la libertad del redactor de los requerimientos está limitada y donde todos los requerimientos se
redactan de una forma estándar. este enfoque asegura que se imponga cierto grado de uniformidad en la
especificación.
Modelo de dominio: el modelo del dominio muestra (a los modeladores) clases conceptuales significativas en
un dominio del problema; es el artefacto más importante que se crea durante el análisis orientado a objetos.
un modelo del dominio es una representación de las clases conceptuales del mundo real, no de componentes
del software. no se trata de un conjunto de diagramas que describen clases de software, u objetos de software
con responsabilidad. el modelo de dominio debe construirse en la disciplina de modelado de negocio, fase
elaboración. porque se construye en la fase de elaboración y no en la fase inicio se debe a que en la fase
inicio se realiza con el objetivo de realizar el estudio de factibilidad o viabilidad y para el cual los casos de
usos se deben hacer en formato breve y solo el 10 % es aconsejable realizarlo completo, esto lleva a la falta
de información necesaria de comprender en detalle de los distintos procesos de negocios organizacionales
 3

para que se pueda determinar adecuadamente las clases conceptuales que muestran el modelo de dominio.
también se debe a la utilización del tiempo en forma óptima.
Clase conceptual: informalmente, una clase conceptual es una idea, cosa u objeto. más formalmente, una
clase conceptual podría considerarse en términos de su símbolo, intensión, y extensión:
• Símbolo: palabras o imágenes que representan una clase conceptual.
• Intensión: la definición de una clase conceptual.
• Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual.

a continuación se presentan dos técnicas para la identificación de las clases conceptuales:

1. utilización de una lista de categorías de clases conceptuales: se comienza la creación de un modelo
del dominio haciendo una lista de clases conceptuales candidatas.
2. identificación de frases nominales: otra técnica útil (debido a su simplicidad) es el análisis lingüístico:
identificar los nombres y frases nominales en las descripciones textuales del dominio, y considerarlos como
clases conceptuales o atributos candidatos. los casos de uso en formato completo constituyen una descripción
excelente a partir de la cual extraer este análisis.
Asociaciones: es una relación entre tipos (o más concretamente instancias de estos tipos) que indica alguna
conexión significativa e interesante. existen dos tipos: -asociaciones de las que es necesario conservar el
conocimiento de la relación durante algún tiempo (asociaciones “necesito-conocer”). - asociaciones derivadas
de la lista de asociaciones comunes.
Atributos: un atributo es un valor de datos lógico de un objeto. se deben incluir en un modelo del dominio
aquellos atributos para los que los requisitos (o los casos de uso) sugieren o implican una necesidad de
registrar la información.
Proceso de ingenieria de requerimientos: la meta del proceso de ingeniería de requerimientos es crear y
mantener un documento de requerimientos del sistema. el proceso general corresponde cuatro subprocesos
de alto nivel de la ingeniería de requerimientos. éstos son:
- estudios de viabilidad: la entrada de éste es un conjunto de requerimientos de negocio preliminares,
una descripción resumida del sistema y de cómo éste pretende contribuir a los procesos del negocio.
los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la
pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema.

- obtención y análisis de los requerimientos: en esta etapa el analista trabaja con los clientes y usuarios
para determinar el dominio de la aplicación, que servicios debe proporcionar el sistema, las
restricciones de hardware, etc. stakeholder se refiere a las personas o grupos que serán afectados por
el sistema en forma directa o indirecta. ej: ing. que mantienen otros sistemas pero que se relacionan,
gerentes de negocios, expertos en el dominio del sistema y representante del trabajador. esta actividad
se puede pensar en una tarea espiralada, dada por:

o descubrimiento de los requerimientos: se interactúa con los stakeholders para recopilar los
requerimientos.
o clasificación y organización de los requerimientos: se deben organizar en forma coherente.
o ordenamiento por prioridad y negociación de los requerimientos: se deben priorizar los
requerimientos. resolver los requerimientos en conflictos.
 4

o documentar los requerimientos: se documenta y entra en una vuelta el espiral. esa

documentación puede ser formal o informal.

- descubrimiento de los requerimientos: es el proceso de recoger información sobre el sistema

propuesto y existente. extraer los requerimientos del usuario y del sistema de esta información. las
fuentes de información durante esta fase son documentación, los stakeholders y la especificación de
sistemas similares. se emplean técnicas de descubrimiento de los requerimientos como entrevistas,
escenarios y etnografía y podemos construir prototipos de sistema entre otras.

o entrevistas: es una conversación dirigida a con un propósito específico que usa un formato de
preguntas y respuestas. se quiere obtener la opinión del entrevistado y sus sentimientos acerca
del estado actual del sistema. los objetivos de la organización, los personales y los
procedimientos informales. se realiza entre el equipo de ingeniería de requerimiento y los
stakeholders del sistema. el objetivo es obtener una comprensión global de lo que hacen los
stakeholders, como interactúan con el/los sistema/s .las dificultades de los sistemas actuales.

o cuestionarios: técnica de recopilación de información que permite que los análisis estudien
actitudes, creencias, comportamientos y características de varias personas en la organización.
las actividades son lo que la gente de la organización dice que quiere, las creencias son los
que la gente piensa que es, el comportamiento es lo que hacen los miembros de la
organización y las características son propiedades de las personas o cosas. los cuestionarios
pueden ser usados para investigar a una gran muestra de usuarios de sistemas, para tratar de
encontrar problemas o recoger cosas importantes antes de que las entrevistas sean realizadas.

o etnografía: es una técnica de observación que se puede utilizar para entender los
requerimientos sociales y organizacionales. un analista se sumerge por sí solo en el entorno
laboral donde se utilizará el sistema. observa el trabajo diario y anota las tareas reales en las
que los participantes están involucrados. el valor de la etnografía es que ayuda a los analistas a
descubrir los requerimientos implícitos que reflejan los procesos reales más que los formales
en los que la gente está involucrada. la etnografía es especialmente efectiva para descubrir 2
tipos de requerimientos:
•los requerimientos que se derivan de la forma en la que la gente trabaja realmente
•los requerimientos que se derivan de la cooperación y conocimiento de las actividades de
gente.
- validación de los requerimientos: trata de mostrar que éstos realmente definen el sistema que el cliente
desea. es importante debido a que los errores en el documento de requerimiento es preferible sobre
los costos en que se incurrirían luego de la codificación. se debe validar en los documentos de
requerimiento. la verificación comprende:

o verificaciones de validez: un usuario puede pensar en la necesidad de un sistema que realice

ciertas funciones. pero el análisis puede llevar a que se necesiten funciones adicionales o
diferentes.
o verificación de consistencia: los requerimientos no pueden contradecirse.
o verificación de completitud: el documento debe incluir todos los requerimientos que definen las
funciones y restricciones propuestas por el usuario del sistema
o verificaciones de realismo: se deben poder implementar los requerimientos y se debe
confeccionar una agenda para el desarrollo del sistema
 5

Verificabilidad: los requerimientos se deben redactar de forma que el cliente interprete y pueda verificar.
podemos usar técnicas de validación de requerimientos:
1-revisiones de requerimientos: tener un equipo de revisores de requerimientos que lo hacen en forma
permanente
2-construcción de prototipos: un modelo del sistema
3-generación de casos de pruebas: someter cada requerimiento a una serie de pruebas ante de llegar
a la codificación.

las revisiones pueden comprobar:

• verificabilidad: puede probarse el requerimiento en forma realista?
• comprensibilidad: las personas involucradas en el sistema comprenden el requerimiento?
• rastreabilidad: esta establecido el origen del requerimiento? pude volver a la fuente el
requerimiento para evaluar el impacto del cambio. es importante la rastreabilidad porque permite
verificar el impacto del cambio en el nuevo sistema.
• adaptabilidad: es adaptable el requerimiento? se puede cambiar sin causar efecto a gran escala en
los otros requerimientos del sistema?
Prototipos:
son una visión preliminar del sistema futuro que se implantará. una técnica valiosa para la recopilación rápida
de información específica acerca de los requerimientos de información de los usuarios. los prototipos
complementan el ciclo de vida de desarrollo de un sistema tradicional. tipos de prototipos:
- prototipos parchados: es la construcción de un sistema de información que tiene todas las
características propuestas pero es realmente un modelo básico que eventualmente será mejorado. son
modelos operables pero que no es eficiente.
- prototipos no operacionales: es un modelo a escala no funcional para probar determinado aspectos de
diseño. se pueden realizar prototipos de entradas /salidas. ej el prototipo de interfaces o la realización
de un dfd.
- prototipos primeros de una serie: es la realización de un prototipo completo del sistema, llamado piloto
pero que se pondrá posteriormente en otros lugares.
- prototipos de características seleccionadas: construir un modelo operacional que incluye alguna, pero
no todas, las características que tendrá el sistema total.
Prototipito del software:
•versión inicial de un sistema de software que se utiliza para demostrar conceptos, probar opciones de diseño,
informarse del problema y posible soluciones.
•desarrollo rápido de un prototipo de modo que los costos sean controlados y los stakeholders del sistema
puedan experimentar con el prototipo en las primeras etapas del proceso del software.
 6

prototipo de interfaz de usuario (piu)

el propósito es permitir al usuario una experiencia directa con la interfaz. en la construcción se trabaja en dos
etapas
papel o maqueta de diseño de pantalla automatizados
•enfoque poco costoso y efectivo •el sistema debe poseer alguna funcionabilidad con la
•no se emplea software cual el usuario debe interactuar
•no se basa en estándares profesionales •la construcción se hace al principio del desarrollo del
•versiones ilimitadas de escenarios alternativos para sistema
simular como se usará el sistema •el usuario interactúa con lo que parece ser un sistema
informático
•el sistema simula las respuestas requeridas
•no se necesita software ejecutable
•enfoques para el prototipado
•enfoque dirigido por secuencia de comandos:
pantallas con elementos visuales (botones, menús, etc)
y se asocia la secuencia de comandos con estos
elementos
•lenguaje de programación visual
•prototipado basado en navegadores web o browsers

Evaluación del piu: la evaluación de piu se realiza para verificar el uso de la interfaz y su cumplimiento con los
requerimientos. Técnicas:
 cuestionarios de opinión
 la observación directa (piensa en voz alta)
 instantánea en el uso de videos
 inclusión de código en el software que recopila información de los recursos más
utilizados y de errores más comunes.
Prototipo evolutivo (desarrollo de software incremental): entrega a los usuarios finales un sistema en
funcionamiento. Se utiliza cuando los requerimientos se entienden claramente.
Prototipo desechable: valida u obtiene los requerimientos del sistema. se utiliza en aquellos requerimientos
que no se comprenden.
ventajas de realizar un prototipo:
-posibilidad de cambiar el sistema en etapas tempranas de su desarrollo.
-detener el desarrollo de un sistema que no funciona
-posibilidad de desarrollar un sistema que satisfaga en mejor forma las necesidades y expectativas de
los usuarios en función de los requerimientos del mismo proceso de desarrollo de prototipos
7
 8

Casos de uso: los casos de uso son un mecanismo ampliamente utilizado para descubrir y registrar los
requisitos, especialmente los funcionales. es tan importante saber de los casos de uso como crearlos,
influencian muchos aspectos de un proyecto.
Caso de uso: un caso de uso es una colección de escenarios con éxitos y fallos relacionados, que describe a
los actores utilizando un sistema para satisfacer un objetivo. los casos de uso se escriben con varios grados
de formalidad:
- breve: resumen conciso de un párrafo, normalmente del escenario principal con éxito.
- informal: formato de párrafo en estilo informal. múltiples párrafos que comprenden varios escenarios.
- completo: el más elaborado. se escriben con detalle todos los pasos y variaciones, y hay secciones de
apoyo como precondiciones y garantías de éxito.
Diagrama de casos de uso:
Un diagrama de casos de uso es una representación del contexto de un sistema, muestra sus límites, su
ambiente y a los actores involucrados. Sirve como herramienta de comunicación que resume el
comportamiento de un sistema y sus actores. Es utilizado durante el desarrollo del modelo de caso de uso,
como artefacto, durante la fase de inicio, en la disciplina de requerimientos del proceso unificado.
- actores: representan un tipo de usuario del sistema. se entiendo como usuario cualquier cosa externa
que interactúa con el sistema. no tiene por qué ser un ser humano, puede ser otro sistema informático
o unidades organizativas o empresas. hay 3 tipos de actores:
• actor principal: tiene como objetivo de usuario que se satisface mediante el uso del sistema
• actor de apoyo: proporciona un servicio al sistema. el servicio de pago con tarjeta de crédito
es un ejemplo.
 9

• actor pasivo: está interesado en el comportamiento

del caso de uso, pero no es el principal ni de apoyo.

- caso de uso: es un proceso que debe poder llevarse a cabo con

el apoyo del sistema. se representan mediante un óvalo. cada
caso de uso debe detallarse, habitualmente mediante una
descripción textual. debe especificar un comportamiento
deseado, pero no imponer cómo se llevará a cabo ese
comportamiento, es decir, debe decir qué pero no cómo. esto
se realiza utilizando escenarios.
- asociaciones: hay una asociación entre un actor y un caso de uso si el actor interactúa con el sistema
para llevar a cabo el caso de uso.

Caso de uso <<include>>:

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. el primer caso
de uso depende del resultado del caso de uso incluido. el segundo es parte esencial del primero. sin el
segundo, el primero no podría funcionar bien; pues no podría cumplir su objetivo.
Caso de uso <<extend>>:
Es otra forma de interacción, un caso de uso dado puede extender a otro. cuando decimos que un caso de
uso extiende a otro indicamos que opcionalmente lo necesita. la extensión, es el conjunto de objetos a los que
se aplica un concepto. los objetos de la extensión son los ejemplos o instancias de los conceptos.
documentan el comportamiento de un sistema desde el punto de vista de un usuario
Glosario:
El glosario es un documento simple en el cual se definen términos. define los términos más importantes del
dominio del problema. el objetivo es proveer de un vocabulario común creado mediante el acuerdo de todo el
personal interesado. sirve para ayudar a personas de diferentes grupos funcionales a alcanzar un
conocimiento mutuo del sistema. el objetivo no es registrar todos los términos posibles, sino sólo aquellos que
son poco claros, ambiguos o requieren elaboración. también puede servir para unificar la terminología
utilizada.
Diccionario de datos:
El diccionario de datos es una obra de consulta con información acerca de los datos compilada por los
analistas de sistemas para guiarse en el análisis y diseño. como un documento, el diccionario de datos
recopila y coordina términos de datos específicos, y confirma lo que cada término significa para las diferentes
personas en la organización.
Contrato:
Los contratos describen el comportamiento detallado del sistema en función de los cambios de estado de los
objetos del modelo del dominio, después de la ejecución de una operación del sistema. se pueden definir
contratos para las operaciones del sistema. los contratos pueden sugerir modificaciones en el modelo del
dominio.
Cuando crear contratos:
Normalmente basta con elaborar las descripciones de los casos de uso. es conveniente elaborar contratos
sólo cuando: sea más fácil redactarlos que refinar la descripción del caso de uso para que refleje los cambios
 10

importantes que provocan en los objetos del dominio. una señal de que algo falla: verse obligado a redactar
contratos para todas las operaciones.
Modelo de analisis:
El propósito fundamental del modelo de análisis es resolver analizando los requisitos con mayor profundidad,
pero con la diferencia de que puede utilizarse el lenguaje de los desarrolladores de proyectos para describir
los resultados. en consecuencia podemos razonar más sobre los aspectos internos del sistema, y por tanto
resolver aspectos relativos a la interferencia de casos de uso y demás. se puede considerar como una primera
aproximación al modelo de diseño y es por tanto, una entrada fundamental cuando se da “forma” al sistema
en el diseño y la implementación.
Clase de analisis:
Una clase de análisis representa la abstracción de una o varias clases y/o subsistemas del diseño del sistema.
esta abstracción posee las siguientes características:
• una clase de análisis se centra en el tratamiento de los requisitos funcionales.
• una clase de análisis también define atributos, aunque esos, atributos son de alto nivel, pero
normalmente estos pasan hacer una clase en el diseño.
• las clases del análisis siempre encajan en uno de tres estereotipos básicos: interfaz, control,
entidad.
Clase interfaz:
las clases de interfaz se utilizan para modelar la interacción entre el sistema y los actores. las clases de
interfaz modelan las partes del sistema que dependen de sus actores, lo cual implica que clasifican y reúnen
los requisitos en los límites del sistema. las clases de interfaz representan a menudo abstracciones de
ventanas, formularios, paneles, interfaces de comunicaciones.
Clase gestor:
las clases de control representan coordinación, secuencia, transacciones y control de otros objetos y se usan
con frecuencia para encapsular el control de un caso de uso en concreto. los aspectos dinámicos del sistema
se modelan con clases de control, debido a que ellas manejan y coordinan las acciones y los flujos de control
principales, y delegan trabajo a otros objetos.
Clase entidad:
las clases de entidad modelan información y el comportamiento asociado de algún fenómeno o concepto,
como persona o un objeto. las clases de entidad reflejan la información de un modo que beneficia a los
desarrolladores al diseñar e implementar el sistema, incluyendo su soporte de, persistencia. las clases de
entidad suelen mostrar una estructura de datos lógica y contribuyen a comprender de qué información
depende el sistema.
gestión de proyecto:
la gestión de proyectos tiene como finalidad principal la planificación, el seguimiento y control de las
actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un sistema de
información. como consecuencia de este control es posible conocer en todo momento qué problemas se
producen y resolverlos o paliarlos de manera inmediata.
Actividades de gestion de proyecto:
• redacción de la propuesta
• planificación y calendarización del proyecto
• estimación de costes del proyecto
 11

• supervisión y revisión del proyecto

• selección y evaluación del personal
• redacción y presentación de informes
•
Calendarización del proyecto:
Segmentar el proyecto en tareas y estimar tiempo y recursos requeridos para completar cada tarea. organizar
tareas concurrentemente para hacer uso óptimo de la fuerza de trabajo. minimizar la dependencia de tareas
para evitar atrasos causados por una tarea que espera el fin de otra. depende de la intuición y experiencia de
administradores de proyectos. se usan notaciones gráficas para ilustrar el calendario del proyecto. mostrar el
proyecto descompuesto en tareas. las tareas no deberían ser muy pequeñas. deberían tomar cerca de una
semana o dos. los gráficos de actividad muestran las dependencias de tareas y la ruta crítica. los gráficos de
barras muestran el calendario programado contra el tiempo real transcurrido.
planificación del proyecto:
el objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al
gestor hacer estimaciones razonables de recursos costos y planificación temporal. estas estimaciones se
hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse
regularmente medida que progresa el proyecto. además las estimaciones deberían definir los escenarios del
mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. el objetivo de la
planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones
razonables.
Hito: un hito de proyecto es un estado predecible donde se presenta a la administración algún reporte formal
del progreso.
12