Tareas extraclase

INDICE
ACTIVIDAD N°1
ACTIVIDAD N°2
ACTIVIDAD N°3
ACTIVIDAD N°4
ACTIVIDAD N°5
ACTIVIDAD N°6
ACTIVIDAD N°7
ACTIVIDAD N°8
ACTIVIDAD N°9
ACTIVIDAD N°10
ACTIVIDAD N°11
ACTIVIDAD N°12
ACTIVIDAD N°13
ACTIVIDAD N°14
ACTIVIDAD N°15
ACTIVIDAD N°16
ACTIVIDAD N°17
ACTIVIDAD N°18
ACTIVIDAD N°19
ACTIVIDAD N°20
ACTIVIDAD N°21
ACTIVIDAD N°22
ACTIVIDAD N°23
ACTIVIDAD N°24
ACTIVIDAD N°25
ACTIVIDAD N°26
ACTIVIDAD N°27
ACTIVIDAD N°28
ACTIVIDAD N°29
ACTIVIDAD N°30
ACTIVIDAD N°31
ACTIVIDAD N°32
ACTIVIDAD N°33
ACTIVIDAD N°34
ACTIVIDAD N°35
ACTIVIDAD N°36
ACTIVIDAD N°37
ACTIVIDAD N°38
ACTIVIDAD N°39
ACTIVIDAD N°40
ACTIVIDAD N°41
ACTIVIDAD N°42
ACTIVIDAD N°43
ACTIVIDAD N°44
ACTIVIDAD N°45
ACTIVIDAD N°46
ACTIVIDAD N°47

ACTIVIDADES DE
APRENDIZAJE
EXTRA CLASE

UNIDAD I:
INTRODUCCIÓN Y
CONCEPTOS BÁSICOS
1

2
ACTIVIDAD N°: 1 FECHA
ENVIO:
13/05/2014 FECHA
ENTREGA:
15/05/2014
TEMA: ¿Cuáles son las consecuencias de una deficiente APS?
Definir una empresa para aplicar la administración de proyectos de software mediante
el desarrollo de un sistema.
UNIDAD N°: 1 Introducción y Conceptos básicos.
OBJETIVO: Caracterizar y describir los principios de administración de proyectos de software.
PROBLEMA: Necesidad de caracterizar y describir los principios de administración de proyectos de
software.
INDICADOR DE
EVALUACION:
DESCRIPCIÓN
Asuntos
contemporáneos
Entender los problemas actuales y más comunes en la Administración de Proyectos,
que se resuelvan con el uso de buenas prácticas en la Gerencia de los mismos.
Criterios de Evaluación PARA EXPOSICIÓN
La exposición desarrollada:
Siempre
(1)
A veces
(0.5)
Nunca
(0.1)
CONOCIMIENTO SOBRE EL TEMA.
 Responde claramente a las preguntas que se le realizan.
 Demuestra seguridad en el tratamiento de los temas.
EXPRESIÓN.
 Toma en cuenta los elementos vocales
 Toma en cuenta los elementos verbales
 Toman en cuenta los elementos visuales
MATERIAL:
 Entrega documentación impresa y digital.
 Los recursos para presentar la exposición.
 Lo realiza a tiempo.
EJEMPLOS.
 Incluye ejemplos claros que permiten un mejor entendimiento del tema.
CONTENIDO.
 Los temas y el contenido presentado son fáciles de entender.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Intraclase
▪Extraclase
▪Individual
□Grupal
□Taller
□Síntesis, esquemas
□Caso de estudio
□Investigativa
□Vinculación con la colectividad
□Práctica en laboratorio
□Práctica en clase
□Resolución de problemas,
ejercicios
▪Ensayo, artículo
□Informe de exposición
CALIFICACIÓN
ROLES Y RESPONSABILIDADES DE LOS PARTICIPANTES EN LA TAREA:
NOMBRE ROL DESCRIPCIÓN
Kevin Valarezo Investigador – Analista Describe los nuevos conceptos
Danilo Sánchez Investigador – Analista Describe los nuevos conceptos
Andrea Buele Investigador – Analista Describe los nuevos conceptos

Desarrollo de la Actividad, Solución o Procedimiento
¿Cuáles son las consecuencias de una deficiente APS?
Las principales consecuencias de una deficiente Administración de Proyectos de Software, son las
siguientes:
 Necesidades no satisfechas o no identificadas
 Cambio incontrolado del ámbito del proyecto
 Exceso de costo
 Retrasos en la entrega
 Retraso de actividades precedentes
 Falta de comunicación con usuarios
 Falta de control de calidad
 Cambio de requerimientos
3
Bibliografía
Hughes, B. y.-H. (s.f.). Administracion de Proyectos de Software.

ACTIVIDAD AUTÓNOMA
Definir una empresa para aplicar la administración de proyectos de software mediante el desarrollo de
un sistema.
BAZAR Y PAPELERIA “ISRAEL”
4
DATOS GENEREALES:
Propietario: Miguel Oña Díaz
Direccion: Eloy Alfaro/ Olmedo y Guayas
Cantón: Santa Rosa
ANTECEDENTES
Eloy Alfaro
G
u
a
y
a
s
O
l
m
e
d
o
Bazar y Papelería “Israel” una empresa ecuatoriana con 10 años de experiencia en el mercado
papelero, ofreciendo a nuestros clientes la mejor selección en marcas y productos. Nuestra
especialidad es brindar lo mejor en papelería, suministros de oficina y útiles escolares, para oficinas,
colegios, papelerías y empresas con el mejor surtido. Nuestros clientes nos prefieren por la excelente
calidad de los productos, precios competitivos y el servicio personalizado.
MISIÓN
Somos una empresa ecuatoriana especializada en la comercialización de suministros de oficina y útiles
escolares, complementada con artículos de bazar; que brinda servicio con personal capacitado y
precios competitivos en el mercado.
VISIÓN
Ser la empresa líder en el mercado, en la comercialización de suministros de oficina y útiles escolares,
reconocida por su excelencia en el servicio, productos de alta calidad y responsabilidad social
empresarial.

5
ORGANIGRAMA
DESCRIPCIÓN DE FUNCIONES:
VENTAS
• Promocionar el producto mediante la atención directa y / o telefónica a clientes.
• Conocer el mercado de los productos que comercializa la empresa, así mismo las acciones de la
competencia e informar a Mercadotecnia de las condiciones de precios y descuentos que imperan en el
mercado.
• Estar pendiente del buen servicio a los clientes así como atender sus recomendaciones y canalizar a
las personas o áreas que involucre.
• Verificar y garantizar el cumplimiento de las actividades que aseguren el óptimo servicio y atención a
los clientes.
MERCADOTECNIA
• Establecer los volúmenes necesarios de stock mediante previos de órdenes de compra, con la
finalidad de mantener niveles óptimos de inventarios para cubrir las necesidades que el mercado
demanda.
• Investigar y buscar nuevos mercados donde sea posible la introducción del producto.
• Planear, organizar y controlar las actividades de comercialización de la compañía a través del área de
ventas.
COMPRAS
Se encarga del óptimo control, manejo de recursos económicos y financieros de la empresa, esto
incluye la obtención de recursos financieros tanto internos como externos, necesarios para alcanzar los
objetivos y metas empresariales y al mismo tiempo velar por que los recursos externos requeridos por
la empresa sean adquiridos a plazos e intereses favorables.

6
ENVIO:
15/05/2014 FECHA
ENTREGA:
16/05/2014
TEMA: Profundizar la investigación sobre responsabilidades y funciones de un
Administrador.
Definir en la empresa seleccionada las responsabilidades y las
funciones del administrador.
OBJETIVO: Caracterizar y describir los principios de administración de proyectos de
software.
PROBLEMA: Necesidad de caracterizar y describir los principios de administración
de proyectos de software.
INDICADOR DE
EVALUACION:
DESCRIPCIÓN
Asuntos
contemporáneos
Entender los problemas actuales y más comunes en la Administración
de Proyectos, que se resuelvan con el uso de buenas prácticas en la
Gerencia de los mismos.
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- CONOCIMIENTO SOBRE EL TEMA.
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
▪Individual
□Grupal
□Taller
□Caso de estudio
□Investigativa
ejercicios
CALIFICACIÓN
INTRODUCCION

El administrador, es la persona que se encarga de controlar, organizar y dirigir dicha entidad; una
empresa u organización que está bien manejada, liderada y organizada tiende a crecer, y esto es, en
gran parte, gracias a la buena administración de la persona a cargo de la empresa u organización.
•Responsabilidad Civil y
Mercantil.
•Responsabilidad Penal.
•Responsabilidad Tribuitaria.
•Responsabilidad Laboral y de
Seguridad Social.
7
MARCO TEORICO
¿Cuáles son las responsabilidades y funciones de un administrador?
El Administrador de una empresa es la persona encargada, entre otras funciones, de realizar las
cuentas anuales al cierre del ejercicio contable. No es necesario ser socio de la empresa para ser su
administrador, pero su cargo debe ser nombrado y recogido en los Estatutos Sociales de la misma.
Todas las empresas están obligadas por Ley a tener uno o varios Administradores 1.
El administrador de una empresa debe cumplir funciones y responsabilidades que satisfagan con las
necesidades de la entidad en cuestión. Por ejemplo, si en una empresa X, el administrador no cumple
con sus funciones sencillamente la empresa fracasara en sus actividades, en cambio, si el
administrador cumple con sus funciones tales como organizar, liderar, coordinar, controlar e innovar, el
ambiente de la empresa en la que esté a cargo mejorara y su producción aumentara en beneficio de
los objetivos de la empresa.
RESPONSABILIDADES:
*
*
1 RedAutono.es. (s.f.). Recuperado el 15 de Mayo de 2014, de
http://redautonomos.es/pymes/responsabilidad-administrador

1. Planificar
4.
Controlar
3. Dirigir 2. Organizar
 Kevin Valarezo: lidera y organiza las actividades de la realización
 Danilo Sánchez: encargado de la programación del proyecto
 Andrea Buele: encargada de la coordinación de las actividades del
8
FUNCIONES:
ACTIVIDAD AUTONOMA:
DEFINIR EN LA EMPRESA SELECCIONADA LAS RESPONSABILIDADES Y FUNCIONES DEL
ADMINISTRADOR
CONCLUSION
del proyecto
proyecto
 El administrador de una empresa u organización, es un papel fundamental para el desarrollo y
crecimiento de la entidad en cuestión, ya que, de él depende si la empresa u organización
prospera o fracasa en sus funciones.
WEBGRAFIA:
Astarloa, E. (2011). Actualidad Juridica.
Ernesto1, B. M. (201). Debates IESA.
RedAutono.es. (s.f.). Recuperado el 15 de Mayo de 2014, de
http://redautonomos.es/pymes/responsabilidad-administrador

9
ENVIO:
16/05/2014 FECHA
ENTREGA:
20/05/2014
TEMA: Investigar sobre el ciclo de vida de un proyecto de software.
Definir en la empresa seleccionada el perfil del administrador.
OBJETIVO: Caracterizar y describir los principios de administración de proyectos de
software.
PROBLEMA: Necesidad de caracterizar y describir los principios de administración
de proyectos de software.
INDICADOR DE
EVALUACION:
DESCRIPCIÓN:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
▪Individual
□Grupal
□Taller
□Caso de estudio
□Investigativa
ejercicios
CALIFICACIÓN
Kevin Valarezo Investigador - Analista Describe los nuevos conceptos
Danilo Sánchez Investigador - Analista Describe los nuevos conceptos
Andrea Buele Investigador - Analista Describe los nuevos conceptos

DESARROLLO DE LA ACTIVIDAD, SOLUCIÓN O PROCEDIMIENTO
CICLO DE VIDA DE UN ROYECTO
Según (Project Management Institute, 2008), el ciclo de vida de proyectos es “un conjunto de fases del
mismo, generalmente secuenciales y en ocasiones superpuestas, cuyo nombre y número se
determinan por las necesidades de gestión y control de la organización u organizaciones que participan
en el proyecto, la naturaleza propia del proyecto y su área de aplicación. Un ciclo de vida puede
documentarse con ayuda de una metodología. El ciclo de vida del proyecto puede ser determinado o
conformado por los aspectos únicos de la organización, de la industria o de la tecnología empleada.”
El ciclo de vida de un proyecto es un enfoque por fases del análisis y diseño que sostiene que, los
proyectos son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del
administrador y del usuario del proyecto. Si bien es cierto, el ciclo de vida de un proyecto determina el
éxito de un sistema dentro del medio, la mayoría de proyectos fracasan o no logran ser culminados, el
claro ejemplo para esto es, la construcción de sistemas sin tener ninguna reunión con el cliente para
determinar problemas, siendo el mayor problema para que un proyecto fracase, ya que no sigue un
debido ciclo dentro de la vida del proyecto.
10
Estructura del ciclo de vida del proyecto
Los proyectos varían en tamaño y complejidad. Todos los proyectos, pueden configurarse dentro de la
siguiente estructura del ciclo de vida2:
 Inicio,
 Organización y preparación,
 Ejecución del trabajo
 Cierre.
2 (Project Management Institute, Inc., 2008)

En la fase de inicio, se realiza un estudio preliminar del problema a solucionar con nuestro proyecto. Al
entrar en la fase de Organización y Preparación, se reúne con el cliente para definir los problemas que
desea resolver con el sistema, se definen los costos y los requerimientos de recursos para la
realización de nuestro proyecto. En la fase de Ejecución, se procede a la realización del proyecto, su
evaluación de funcionamiento, sus debidas correcciones ante posibles fallos. Para culminar, la fase de
cierre se efectúa el proceso de instalación, entrega de documentación y capacitación a las personas
que manejaran el software realizado.
Esta es una estructura básica de un ciclo de vida de proyecto, ya que, se puede desplegar muchas
más fases según convenga en la realización de un proyecto.
11
Características del ciclo de vida del proyecto
 Define el comienzo y el fin del proyecto.
 Define el trabajo técnico y los involucrados en cada fase.
 Los entregables usualmente deben ser aprobados antes que se inicie el trabajo de la
siguiente fase.
 El riesgo e incertidumbre son altos al comienzo y decrecen al avanzar el proyecto.
 Los costos y riesgos de cambios y correcciones generalmente crecen cuando el proyecto
avanza.
 Las prácticas comunes de la industria a menudo conducen a usar un ciclo de vida preferido
dentro de dicha industria.

12
ACTIVIDAD AUTONOMA
DEFINIR EN LA EMPRESA SELECCIONADA EL PERFIL DEL ADMINISTRADOR
PERFIL DEL ADMINISTRADOR
Dentro del perfil del administrador para nuestro proyecto:
 Capacidad para asumir riesgos
 Capacidad organizativa
 Carisma y capacidad de dirigir personas
 Balance entre ser realista / idealista
 Dejarse influir por personas con experiencia
 Capacidad de tomar decisiones acertadas tomando en cuenta las consecuencias de las
mismas.
Bibliografia
Project Management Institute, Inc. (2008). FUNDAMENTOS PARA LA DIRECCION DE PROYECTOS
(GUIA DEL PMBOK (R)). EEUU.
Webgrafía:
http://formulaproyectosurbanospmipe.wordpress.com/2012/03/27/ciclo -de-vida-del-proyecto-y-la-organizacion-
la-guia-del-pmbok-capitulo-2-sesioon-7-19-03-2-012-primera-parte/
http://ruben-apaza.blogspot.com/2013/07/ciclo-vida-proyecto.html#.U3jXldJ5N0I

UNIDAD II: GUÍA DE LOS
FUNDAMENTOS PARA LA
DIRECCIÓN DE PROYECTOS.
PMBOK
13

14
ENVIO:
20/05/2014 FECHA
ENTREGA:
22/05/2014
TEMA: Profundizar en la investigación sobre el ciclo de vida de un proyecto.
Identificar las necesidades del cliente para determinar la metodología
de desarrollo de software en la empresa seleccionada.
UNIDAD N°2: Guía de los fundamentos para la dirección de proyectos. PMBOK.
OBJETIVO: Aplicar metodologías de acuerdo a las necesidades del usuario
PROBLEMA: Carencia de metodologías de acuerdo a las necesidades del usuario
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

15
CONCEPTOS GENERALES
PROJECT MANAGEMENT INSTITUTE (MPI)
La gestión de proyectos reúne un conjunto de herramientas y técnicas que describen,
organizan y supervisan las actividades y trabajos del proyecto.
Existen varios procesos de gestión de proyectos establecidos que puede utilizar para
administrar u proyecto.
PROYECTO
La Guía del PMBOK, es un estándar en la gestión de proyectos desarrollado por Project
Management Institute (PMI).
 Temporal
Significa que todo proyecto tiene un comienzo y un final definido. Tiene una duración
determinada: 2 meses, 1 año, etc.
GESTIÓN DE PROYECTOS
La gestión de proyectos es la aplicación de conocimientos, habilidades, herramientas y
técnicas a las actividades del proyecto para cumplir los requisitos del mismo.
Procesos de la gestión de proyectos:
• Iniciación
• Planificación
• Ejecución
• Seguimiento y control
• Cierre.
o Iniciación
Se crean los primeros documentos del proyecto como el Acta de Constitución del Proyecto
que describe los objetivos la justificación, una descripción de alto nivel del producto o
servicio del proyecto y mucho más. Así mismo que se debe identificar y documentar a los
interesados es decir a las personas u organizaciones que reciben el impacto del proyecto.

16
o Planificación
Los procesos de planificación son fundamentales para el funcionamiento de los grupos de
procesos restantes. Los logros d este grupo de procesos son los siguientes:
- Documentar y publicar las definiciones del alcance del proyecto
- Establecer un presupuesto del proyecto
- Definir las actividades del proyecto.
o EJECUCIÓN
Es donde se realiza el trabajo del proyecto.
Logros de este grupo de procesos:
- Formar y motivar al equipo de proyecto
- Dirigir y liderar el equipo de proyecto.
o SEGUIMIENTO Y CONTROL
Es donde el trabajo del proyecto se mide, verifica y es aceptado o donde se toman
medidas para corregir el trabajo que no está de acuerdo con el plan del proyecto.
o Cierre.
Finaliza el proyecto de modo formal y ordenado. Los logros de este grupo de procesos:
1. Obtener la aprobación de los entregables.
2. Documentar las lecciones aprendidas.
o INFLUENCIA DE LA ESTRUCTURA ORGANIZACIONAL
Los proyectos se desarrollan dentro de organizaciones más grandes que el proyecto en sí. La
forma en que están estructuradas influirá directamente en la conformación, administración y
dependencia de cada uno de los integrantes del equipo de trabajo.
ORGANIZACIÓN FUNCIONAL
Tiene una estructura piramidal y jerarquía, donde cada empleado tiene un jefe inmediato y bien
señalado a quien reportar.
Las organizaciones funcionales ejecutarán proyectos, pero el alcance de los mismos estará
circunscripto a los límites de su función.

17
ORGANIZACIÓN MATRICIAL
Las Organizaciones matriciales tienen una mezcla de características de las funcionales y de
las orientadas a proyectos. Dentro de este tipo de organización, se identifican tres subtipos
1. Matricial débil
2. Matricial fuerte
3. Matricial balanceada.
ORGANIZACIÓN ORIENTADA A PROYECTOS
Las organizaciones orientadas a proyectos suelen contar con unidades organizacionales
llamadas “departamentos”, peo estos grupos dependen del gerente de proyectos o bien
prestan sus servicios a varios proyectos.
ORGANIZACIÓN MIXTA
En los últimos años, se ha desarrollado en las organizaciones modernas un tipo de estructura
llamada matricial compuesta donde se involucran todas estas estructuras en varios niveles. Ello
hace que la organización gane dinamismo y flexibilidad ante cambios no previstos.
o INTERESADOS DEL PROYECTO (STAKEHOLDERS)
Un interesado es una persona, grupo u organización que puede afectar, verse afectado o
percibir que puede ser afectado por una decisión, actividad o resultado de un proyecto.
PRINCIPALES INTERESADOS DE UN PROYECTO
 Patrocinador (sponsor)
 Cliente/Usuario
 Vendedoras
 Socios de negocios
 Grupos organizacionales
 Gerentes funcionales
 Otras partes interesadas
o EQUIPO DEL PROYECTO
Son las personas asignadas full time y parte time al proyecto y quienes trabajan directamente
en la obtención de los entregables del proyecto.
Incluyen roles como:
- Personal de gestión del proyecto
- Personal del proyecto
- Expertos de apoyo

- Representante de los usuarios o de los clientes
- Vendedores (proveedores o contratistas)
- Miembros de los socios de negocios
- Los socios de negocios.
o EL CICLO DE VIDA DEL PROYECTO
Es una serie de faces por la que pasa un proyecto desde su inicio hasta su cierre.
CARACTERÍSTICAS DEL CICLO DE VIDA DEL PROYECTO
18
 Inicio del proyecto
 Organización y preparación
 Ejecución del trabajo del proyecto.
 Cierre el proyecto
FASES DEL PROYECTO
Un proyecto puede dividirse en cualquier número de fases. Una fase del proyecto es un
conjunto de actividades del proyecto relacionadas lógicamente que culmina con la realización
de uno o más entregables.
ACTIVIDAD AUTÓNOMA
El proyecto se centra en la automatización de los procesos de ventas, compras, el control de inventario
y control del personal, mediante un sistema online, minimizando el tiempo de operación que toma
realizar dichos procesos manualmente.
NECESIDADES DEL NEGOCIO
En cuanto a Ventas:
- Promocionar los productos, precios y descuentos mediante una página web.
- Estar pendiente del buen servicio a los clientes así como atender sus recomendaciones, a
través de la página web.
- Verificar y garantizar el cumplimiento de las actividades que aseguren el óptimo servicio y
atención a los clientes.
- Conocer y apoyar las operaciones de Mercadotecnia.
- Automatizar los procesos.

19
En cuanto a Mercadotecnia:
- Establecer los volúmenes necesarios de stock mediante previos de órdenes de compra, con la
finalidad de mantener niveles óptimos de inventarios, para cubrir las necesidades que el
mercado demanda.
- Mantener actualizado el stock.
- Planear, organizar y controlar las actividades de comercialización de los productos.
- Realizar el diseño de la publicidad.
En cuanto a Compras:
- Se encarga del óptimo control, manejo de recursos económicos y financieros de la empresa.
- Mantener información con los proveedores como Negociar precios, tiempos de entrega, plazos
de pago.
- Automatizar el proceso de pedidos de productos.
Identificar las necesidades del cliente para determinar la metodología de desarrollo de software en la
empresa seleccionada
Una metodología es un conjunto de procedimientos, técnicas, herramientas y un soporte documental
que ayuda a los desarrolladores a realizar un nuevo software. Puede seguir uno o varios modelos de
ciclo de vida, es decir, el ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del
proyecto pero no cómo hacerlo. La metodología indica cómo hay que obtener los distintos productos
parciales y finales.
Microsoft Solutions Framework
Según (Microsoft) “Microsoft Solutions Framework (MSF) es un enfoque personalizable para entregar
correcta y más rápidamente soluciones tecnológicas, con menos personas y menos riesgo, pero con
resultados de más calidad. MSF ayuda a los equipos a resolver directamente las causas más comunes
de error en el proyecto de tecnología, lo cual mejora los índices de buenos resultados, de calidad de la
solución y de impacto comerciales”
Es una flexible e interrelacionada serie de conceptos, modelos y prácticas de uso que controlan la
planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de
proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.
Ciclo de Vida MSF
El modelo de proceso de MSF combina el concepto de la administración de proyectos tradicional
(cascada), con los modelos en espiral (mejora continua) para capitalizar en las fortalezas de cada uno

de estos enfoques. MSF combina los beneficios de la planeación en cascada basado en el alcance de
hitos, con los entregables iterativos e incrementales del modelo en espiral.
20
Fases de la metodología3.
- Visión
Obtener una visión clara del proyecto compartida con los objetivos del negocio. Se necesitan
Identificar los beneficios que trae el proyecto como también sus restricciones y alcances. En
ésta fase se debe identificar primeramente el propósito del proyecto, es decir, ¿Qué vamos a
realizar?; tomando en cuenta los objetivos específicos, los que deben ser claros, medibles y
alcanzables en un tiempo determinado y ciclo.
- Planeación
En esta fase se desarrolla la planificación en base al objetivo del proyecto y la arquitectura de
la solución plasmada en la fase de Visión y Alcance, ajustada a un cronograma de trabajo que
cumpla con lo especificado.
- Desarrollo.
Esta Fase comienza desde el momento en que iniciamos a escribir el código de la
aplicación. MSF recomienda iniciar a construir código a partir de las funcionalidades más
bases e ir haciendo entrega de cada funcionalidad desarrollada para someterse a pruebas
unitarias, y evaluaciones de experiencia de usuario. Esto incluye ajustes de cronograma
necesarios.
- Estabilización.
Versión final del producto probada, ajustada y aprobada en su totalidad.
- Implantación.
Entregar (instalar) al cliente el producto finalizado en su totalidad.
3 Cabrera, L. T. (2010). Scribd. Recuperado el 21 de mayo de 2014, de
http://es.scribd.com/doc/35187708/Modelo-MSF

21
- Soporte.
Brindar garantía al producto durante un tiempo estipulado en el contrato, registrando los
reportes de soporte y mantenimiento recibidos así como ajustes que estén dentro de lo escrito
en los documentos de la fase de Visión.
VENTAJAS Y DESVENTAJAS
Ventajas
- Crea una disciplina de análisis de riesgos que ayuda y evoluciona con el proyecto.
- Tiene facilidad de soporte y mantenimiento.
- Es adaptable, se puede utilizar para proyectos de cualquier magnitud.
- El modelo tiene facilidad de manejo por ser de una empresa conocida.
- Es una metodología que se puede ajustar a equipos de trabajo compuestas por 3 o más
personas.
Desventajas
- Al estar basado en tecnología Microsoft, trata de obligar a usar sus propias herramientas.
- Si el análisis de riesgos se hace muy exhaustivo puede retardar el proyecto.
CONCLUSIÓN
MSF se ha diseñado para ayudar a las organizaciones o empresas a ofrecer soluciones de tecnología
de alta calidad. Se ha utilizado un enfoque bien disciplinado orientado hacia proyectos de tecnologías
de información basándose en un conjunto definido en principios, modelos y disciplinas que ayudan a
mejorar a la empresa. Consideramos que esta herramienta ayudará mucho a las empresas pequeñas,
que quieran expandirse y formar un conjunto de personas altamente capacitadas para desarrollar
proyectos de tecnologías de información con el fin de maximizar sus producciones, sea desarrollo de
software o cualquier otro proyecto tecnológico.
Bibliografía
Cabrera, L. T. (2010). Scribd. Recuperado el 21 de mayo de 2014, de
http://es.scribd.com/doc/35187708/Modelo-MSF
Microsoft. (s.f.). Microsoft Developer Network. Recuperado el 22 de mayo de 2014,
de http://msdn.microsoft.com/es-es/library/jj161047.aspx

22
ENVIO:
22/05/2014 FECHA
ENTREGA:
23/05/2014
TEMA: Identificar los requisitos funcionales y no funcionales.
Determinar los roles del grupo del proyecto en la empresa
seleccionada.
UNIDAD N°2: Guía de los fundamentos para la dirección de proyectos. PMBOK.
OBJETIVO: Establecer los roles y las actividades del proyecto.
PROBLEMA: Carencia de roles y de actividades del proyecto.
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

DESARROLLO DE LA ACTIVIDAD, SOLUCION O PROCEDIMIENTO
IDENTIFICAR LOS REQUISITOS FUNCIONALES Y NO FUNCIONALES.
23
Identificación de Requerimientos funcionales
Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la
manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos
funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación
de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un
requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo
que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al
sistema, retrasando la entrega de éste e incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser
consistente. La compleción significa que todos los servicios solicitados por el usuario están definid os.
La consistencia significa que los requerimientos no tienen definiciones contradictorias.
En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de
consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente del
sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas
inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas
emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes
revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de
requerimientos.
Identificación de Requerimientos no funcionales
Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el
sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la
capacidad de almacenamiento. De forma alternativa, definen las restricciones de l sistema como la
capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la
interface del sistema.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el
presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas
de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de
privacidad, entre otros.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
• Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos
de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad
que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la
organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse;
requerimientos de implementación como los lenguajes de programación o el método de diseño a
utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su
documentación.
• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de
desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema
interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse
para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son
impuestos al sistema para asegurar que será aceptado por el usuario.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es posible
traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las de mantenimiento,
no existen métricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no
funcionales cuantitativos es muy alto.
En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de
requerimientos. En la práctica, esto es difícil. Si un requerimiento no funcional se declara de forma
separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los
requerimientos funcionales, es difícil separar las condiciones funcionales y no funcionales e identificar
los requerimientos que se refieren al sistema como un todo. Se debe hallar un balance apropiado que
dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se refieren
a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocándolos en una
sección aparte o diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
24
Bibliografía:
https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-requisitos-funcionales-y-no-
funcionales
http://es.scribd.com/doc/37187866/Requerimientos-funcionales-y-no-funcionales

25
ACTIVIDAD AUTÓNOMA
DETERMINAR LOS ROLES DEL GRUPO DEL PROYECTO EN LA EMPRESA SELECCIONADA.
ADMINISTRADOR DE PROYECTO
Buele Blacio Andrea
ANALISITA DE
REQUERIMIENTOS
Valarezo Paz Kevin
PROGRAMADOR
Sanchez Chuico
Danilo
PATROCINADOR
Oña Diaz Miguel

26
ADMINISTRADOR DEL PROYECTO
DATOS PERSONALES
NOMBRES Y APELLIDOS : BUELE BLACIO ANDREA STEFANIA
DOCUMENTO DE IDENTIDAD : 0706402732
FECHA DE NACIMIENTO : OCTUBRE 7,1993
ESTADO CIVIL : SOLTERA
DIRECCIÓN : CALLE SIXTO DURAN B.
TELÉFONO : 0983068400
E-MAIL : andreabuele0@gmail.com
RESPONSABILIDADES
 Tener el producto “a tiempo”, “bajo presupuesto” y con los requisitos especificados.
 Terminar el proyecto con los recursos asignados. activamente en la etapa de análisis, así
como en todas aquellas actividades de revisión y aceptación.
 Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus integrantes a
cumplir sus objetivos particulares.
 Cumplir con éxito las diferentes fases de un proyecto, utilizando herramientas de
administración.
 Observar cada actividad para detectar errores, realizar reuniones generales y seminarios de
actividades donde concluirá metas de evaluación y planificación.
 Realizar reuniones de evaluación con cada rol.
 Obtener información continua sobre el estado el proyecto para lograr cumplir con éxito las
metas definidas. para el equipo y para el cliente.
 Construir un plan de trabajo específico que cubra todas las necesidades del proyecto y un
plan de distribución del equipo de trabajo.
 Definir una estructura organizacional
 Capacitar al grupo en las metodologías y normas que se aplicaran en el proyecto
 Definir protocolos para asignar y evaluar actividades.
 Realizar reuniones generales para evaluación y planificación
 Lograr la entrega total del grupo del trabajo y el compromiso de entregar un producto de
calidad.

ANALISTA DE REQUERIMIENTOS DEL PROYECTO
27
DATOS PERSONALES
NOMBRES Y APELLIDOS : VALAREZO PAZ KEVIN ADRIAN
DOCUMENTO DE IDENTIDAD : 0704640333
FECHA DE NACIMIENTO : AGOSTO 27,1993
ESTADO CIVIL : SOLTERO
DIRECCIÓN : LAS LOMAS Y PIÑAS
TELÉFONO : 0998173686
E-MAIL : nivek.adrian123@gmail.com
RESPONSABILIDADES
 Utilizar técnicas que faciliten que todos los interesados en el proyecto participen, colaboren
y lleguen a un consenso sobre el conjunto priorizado de funcionalidades de alto nivel que
deben ser desarrolladas.
 Asegurar de que estas funcionalidades están justificadas y que tienen correspondencia con
las necesidades de negocio.
 Recopilar la información necesaria de los procesos realizados en la empresa.
 Organizar la información obtenida.
 Plasmar los requerimientos del sistema en lenguaje para que el programador entienda.
 Coordinar las actividades del control de avance del proyecto con el administrador.
 Efectuar reuniones con el programador para dejar en claro los requisitos del proyecto y así
efectuar la programación del sistema.
 Gestionar reuniones con el patrocinador para entregar avances del sistema y aplicar un
control de cambios, en caso de que estos existiesen.
 Desarrollar los diagramas del modelado del negocio.
 Colaborar en la elaboración de las pruebas funcionales.

28
ENVIO:
23/05/2014 FECHA
ENTREGA:
27/05/2014
TEMA: Norma para la direccion de proyectos.
Identificar los requisitos funcionales y no funcionales de la empresa.
UNIDAD N°: 2 Guía de los fundamentos para la dirección de proyectos. PMBOK.
OBJETIVO: Establecer los roles y las actividades del proyecto.
PROBLEMA: Carencia de roles y de actividades del proyecto.
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

29
Norma para la dirección de Proyectos
Define los procesos de dirección de proyectos y define las entradas y salidas para cada proceso.
El Capítulo 3, Procesos de Dirección de Proyectos para un Proyecto, define los cinco grupos de
procesos: Iniciación, Planificación, Ejecución, Seguimiento y Control, y Cierre. Este capítulo relaciona
las Áreas de Conocimiento de la Dirección de Proyectos con los grupos de Procesos específicos de la
dirección de proyectos.
Iniciación
Compuesto por aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un
proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto o fase.
Dentro de los procesos de iniciación, se define el almacén inicial y se comprometen los recursos
financieros iniciales.
Planificación
Consta de aquellos procesos realizados para establecer el almacén total del esfuerzo, definir y refinar
los objetivos, y desarrollar la línea de acción requerida para alcanzar dichos objetivos.
Ejecución
Procesos realizados para completar el trabajo definido en el plan para la dirección de proyectos a fin de
cumplir con las especificaciones del mismo.
Este grupo de proceso implica coordinar personas y recursos, así como integrar y realizar las
actividades del proyecto de conformidad con el plan para la dirección del proyecto.
Seguimiento y Control
Está compuesto por aquellos procesos requeridos para supervisar, analizar y regular el progreso y el
desempeño del proyecto, para identificar áreas en las que el plan requiera cambios y para iniciar los

cambios correspondientes. El beneficio clave de este grupo radica en que el desempeño del proyecto
se observa y se mide de manera sistemática y regular, a fin de identificar variaciones respecto del plan
para la dirección del proyecto.
30
Cierre
Procesos realizados para finalizar todas las actividades a través de todos los grupos de procesos de la
dirección de proyectos, a fin de completar formalmente el proyecto, una fase del mismo u otras
obligaciones contractuales.
Este grupo de procesos, una vez completado, verifica que los procesos definidos se hay an completado
dentro de todos los grupos de procesos a fin de cerrar el proyecto o una fase del mismo, según
corresponda, y establece formalmente que el proyecto o fase del mismo ha finalizado.
Bibliografía
https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-requisitos-funcionales-y-no-
funcionales

ACTIVIDAD AUTÓNOMA
31
REQUISITOS FUNCIONALES
INTERESADO
PRIORIDAD
OTORGADA
POR EL
INTERESADO
REQUISITOS
CÓDIGO DESCRIPCIÓN
Empleado
(Usuario)
Alta R01 El sistema permitirá agregar nuevos clientes que se
acerquen a comprar en la librería.
Alta R02
El sistema permitirá gestionar los datos de los clientes
registrados.
Alta R03
El sistema permitirá agregar nuevos proveedores que
brinden sus servicios a la librería.
Alta R04
El sistema permitirá gestionar los datos de los
proveedores registrados.
Alta R05
El sistema permitirá llevar el control de asistencia del
empleado, marcando la llegada y salida de los
mismos.
Alta R06 El sistema permitirá generar facturas de venta.
Alta R07
El sistema permitirá actualizar el stock de los
productos mediante la emisión de facturas de venta y
factura de compra.
Alta R08
El sistema permitirá generar cuentas por cobrar a
partir de facturas de venta a crédito.
Alta R09
El sistema permitirá emitir comprobantes de cuentas
por cobrar.
Administrador
Alta R10
El sistema permitirá registrar las facturas de compra.
Alta R11
El sistema permitirá gestionar los precios de venta de
los productos.
Alta R12 El sistema permitirá agregar nuevos empleados.
Alta R13 El sistema permitirá gestionar los datos de empleados.
Alta R14 El sistema permitirá registrar pedidos de productos.
Alta R15 El sistema permitirá gestionar las cuentas por cobrar
Media R16 El sistema permitirá generar reportes de venta
Alta R17 El sistema permitirá anular facturas de venta
Alta R18
El sistema permitirá registrar clientes dentro de una
factura de venta
Alta R19
El sistema permitirá registrar proveedores dentro de
una factura de compra

32
REQUISITOS NO FUNCIONALES
INTERESADO
PRIORIDAD
OTORGADA
POR EL
INTERESADO
REQUISITOS
Administrador
Alta R20
La interacción con el sistema debe ser a través de teclado y
mouse.
Alta R21 Se utilizará como base de datos: postgresql .
Alta R22
El sistema será accesible desde cualquier estación de
trabajo que cuente con un S.O., un navegador web Mozilla
Firefox (2.0 o superior), Internet Explorer (6.0 o superior) o
Google Chrome.
Alta R23
El sistema se ejecutará sobre un servidor de hosting web
que soporte el framework django y el lenguaje Python.
Alta R24
El tiempo de respuesta para la obtención de datos a través
del sistema no deberá exceder los 5 segundos.
Patrocinador
Alta R25
Contar con especificaciones técnicas completas y claras del
sistema ADIS, con quién interactuará para ejecutar
fácilmente los procesos de la empresa.
Alta R26 Todos los entregables deben iniciarse y completarse en las
fechas programadas.
Alta R27 Cumplir con los acuerdos presentados en la propuesta,
respetando los requerimientos del cliente.
Reglas del negocio
 Los requerimientos serán proporcionados por el cliente.
 Emitir informes periódicos del rendimiento del proyecto y tomar acciones correctivas de ser el
caso.
 Mantener una comunicación fluida entre las diferentes áreas del negocio con respecto a la
ejecución del proyecto.
 Emitir informe final que evaluará el desenvolvimiento del equipo y el nivel de cumplimiento del
proyecto.

UNIDAD III:
PMBOK. NORMA PARA
LA DIRECCIÓN DE
PROYECTOS
33

34
ENVIO:
27/05/2014 FECHA
ENTREGA:
29/05/2014
TEMA: Investigar la Herramienta COCOMO II y similares.
Realizar un cronograma, determinando las actividades del proyecto
utilizando Open Project.
UNIDAD N°:3 PMBOK Norma para la Dirección de Proyectos.
OBJETIVO: Conocer normas para la Dirección de Proyectos. PMBOK
PROBLEMA: Carencia de norma para la Dirección de Proyectos. PMBOK
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

35
INTRODUCCIÓN
Todo proyecto de ingeniería de software debe partir con un buen plan, pero lamentablemente, la
planificación es una tarea nada trivial. Uno de los aspectos que dificultan la labor de administradores y
jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y
plazos realista.
Existen técnicas para la estimación de costos, pero para ello se requiere experiencia, acceso a una
buena información histórica y coraje para confiar en medidas cuantitativas cuando todo lo que existe
son datos cualitativos.
DESARROLLO
COCOMO II
Como se conoce, una de las tareas de mayor importancia en la planificación de proyectos de software
es la estimación, la cual consiste en determinar, con cierto grado de certeza, los recursos de hardware
y software, costo, tiempo y esfuerzo necesarios para el desarrollo de los mismos.
COCOMO II posee tres modelos denominados Composición de Aplicación, Diseño Temprano y Post-
Arquitectura. Cada uno de ellos orientados a sectores específicos del mercado de desarrollo de
software y a las distintas etapas del desarrollo de software.
Definición del modelo
Los objetivos principales que se tuvieron en cuenta para construir el modelo COCOMO II fueron:
 Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que se
adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras.
 Construir una base de datos de proyectos de software que permitiera la calibración continua
del modelo, y así incrementar la precisión en la estimación.
 Implementar una herramienta de software que soportara el modelo.
 Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que evaluaran
el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en las diferentes
etapas del ciclo de vida de desarrollo.
Que es la Herramienta COCOMO II
COCOMO II es un modelo que permite estimar el coste, esfuerzo y tiempo cuando se planifica una
nueva actividad de desarrollo software. Está asociado a los ciclos de vida modernos. El modelo
original COCOMO ha tenido mucho éxito pero no puede emplearse con las prácticas de desarrollo
software más recientes tan bien como con las prácticas tradicionales. COCOMO II apunta hacia los
proyectos software de los 90 y de la primera década del 2000, y continuará evolucionando durante los
próximos años.

En resumen, los objetivos a la hora de la creación del modelo COCOMO II fueron:
1. Desarrollar un modelo de estimación de tiempo y de coste del software de acuerdo con los
ciclos de vida utilizados en los 90 y en la primera década del 2000.
2. Desarrollar bases de datos con costes de software y herramientas de soporte para la mejora
36
continua del modelo.
3. Proporcionar un marco analítico cuantitativo y un conjunto de herramientas y técnicas para la
evaluación de los efectos de la mejora tecnológica del software en costes y tiempo de l ciclo de
vida software.
Los cuatro elementos principales de la estrategia que ha seguido COCOMO II son:
- Preservar la apertura del COCOMO original.
- Desarrollar COCOMO II de forma que sea compatible con el futuro mercado del software
- Ajustar las entradas y salidas de los submodelos de COCOMO II al nivel de información
disponible.
- Permitir que los submodelos de COCOMO II se ajusten a las estrategias de proceso
particulares de cada proyecto.
COCOMO II sigue los principios de apertura usados en el COCOMO original. De esta manera todos
sus algoritmos y relaciones están disponibles públicamente.
¿Cuál es su base?
El COCOMO II se basa en las líneas de código la cual le hace muy poderoso para la estimación de
costos y no como otros que solamente miden el esfuerzo en base al tamaño.
Características
Es el modelo empírico más extenso para la estimación costos en cuanto a software se refiere hasta la
fecha.
Existen herramientas automáticas que estiman costos basados en COCOMO como ser: Costar,
COCOMO 81.
Es indicado para proyectos construidos con herramientas modernas de construcción de interfaces
gráficos para usuario.
UTILIZACIÓN DEL MODELO DE COMPOSICIÓN DE APLICACIONES
Las primeras fases o ciclos en espiral utilizados en proyectos software de Generador de Aplicaciones,
Integración de Sistema e Infraestructura implicarán generalmente prototipado y utilizarán las utilidades
del Módulo de Composición de Aplicaciones. El Modulo de Composición de Aplicaciones COCOMO II,

soporta estas fases y cualquier otra actividad de prototipado que se realice más adelante en el ciclo de
vida.
Dado que el Modelo de Composición de Aplicaciones incluye esfuerzos de prototipado para resolver
asuntos potenciales de alto riesgo tales como interfaces de usuario, interacción software/sistema,
ejecución o grado de madurez tecnológica, los costes de este tipo de esfuerzo se estiman mejor
mediante dicho modelo.
UTILIZACIÓN DEL MODELO DE DISEÑO ANTICIPADO
El Diseño Anticipado incluye la exploración de arquitecturas de software/sistema alternativas y
conceptos de operación. En esta fase no se sabe lo suficiente como para dar soporte a la estimación
de grano fino.
La correspondiente capacidad de COCOMO II incluye el uso de Puntos de Función y un conjunto de
siete drivers de coste de grano grueso (por ejemplo, dos drivers de coste para capacidad del personal y
experiencia del personal en lugar de los seis drivers de coste del Modelo Post-Arquitectura que cubren
varios aspectos de capacidad del personal, continuidad y experiencia).
OTRA DE LAS HERRAMIENTAS PARA ESTIMACION DE COSTOS ES:
37
ESTIMACS
Este método de estimación de centra en la fase de desarrollo del ciclo de vida del sistema, dejando el
mantenimiento a futuras extensiones del método.
ESTIMACS hace hincapié en lograr la estimación en términos de negocio.
También hace hincapié en la necesidad de realizar análisis de sensibilidad y mercado prematuramente,
no sólo con el producto en mano, sino también sobre cómo el actual proyecto se ajustará al proceso de
desarrollo a largo plazo de la compañía desarrolladora, en términos de personal y costes y riesgos
asociados.
Identifica seis dimensiones importantes de la estimación y se crea un mapa en el que se muestran las
relaciones entre las mismas. La premisa básica de ESTIMACS es que las especificaciones a groso
modo del negocio, o “factores del proyecto”, determinan las dimensiones de estimación. Se definen los
“fac tores del proyecto” como “aspectos de la funcionalidad del sistema objeto que son bien definidos al
comienzo del proceso “. En la siguiente tabla se muestran los factores de proyecto importantes.

Los elementos de la tabla anterior forman la base de los cinco submodelos que componen ESTIMACS.
Los submodelos estás diseñados para ser usados secuencialmente, de tal forma que las salidas de
uno son las entradas del siguiente. De forma general, se realiza un proceso iterativo que lleva a la
estimación final de desarrollo. El proceso en cada modelo sería:
1.- Estimación de la evolución de los datos de entrada
38
2.- Resumen de estimación
3.- Análisis de sensibilidad
4.- Revisión del paso 1 basado en el resultado del paso 3
Los cinco submodelos de ESTIMACS en el orden de uso son:
 Estimación de esfuerzo en el desarrollo del sistema.
 Estimación de personal necesario y coste.
 Estimaciones de configuración de Hardware
 Estimación de riesgos
 Análisis de “portfolio” (análisis a largo plazo del proyecto en el proceso global de la compañía)
La principal ventaja/diferencia de ESTIMACS es su habilidad para estimar y analizar las sensibilidades
no sólo de software, sino también de hardware, y su objetivo de planificación orientada al negocio.

39
ACTIVIDAD AUTÓNOMA
Realizar un cronograma, determinando las actividades del proyecto utilizando Open Project.
 Cronograma
 Diagrama de Gantt

40
CONCLUSIONES
COCOMO II es una herramienta basada en las líneas de código la cual le hace muy poderoso para la
estimación de costos y no como otros que solamente miden el esfuerzo en base al tamaño. Hoy en día
es necesario para un administrador de proyectos poseer una herramienta de estimación de costos; y
esta herramienta puede ser COCOMO II o ESTIMACS.
Con la realización de este trabajo ampliamos nuestros conocimientos acerca de la estimación de costos
que es fundamental para un analista, administrador de proyecto.
Bibliografia:
bibing. (s.f.). Recuperado el 28 de Mayo de 2014, de sitio web de Bibing:
http://bibing.us.es/proyectos/abreproy/10977/fichero/Memoria%252F2.pdf
cnti. (s.f.). CNTI. Recuperado el 28 de Mayo de 2014, de
http://190.9.128.249/cnti/images/stories/documentos_pdf/modelo_estimacion_costos_cuba_v2.
pdf
spyderlib. (s.f.). spyderlib. Obtenido de https://code.google.com/p/spyderlib/

[Amadeus 1994] Amadeus, Amadeus Measurement System User’s Guide, Version 2.3a, Amadeus
Software Research, Inc., Irvine, California, July 1994.
Engineering Institute, Pittsburgh, PA, November 1989.
[Boehm 1995/2] Boehm B.W.,Clark B., Horowizt E., Westland C., Madachy R., Selby R., The
COCOMO 2.0 Software Cost Estimation Model, http://sunset.usc.edu/COCOMOII/cocomo.html.
[Chidamber and Kemerer 1994] Chidamber, S. and C. Kemerer , A Metrics Suite for Object Oriented
Design, IEEE Transactions on Software Engineering, 1994.
[COCOMO II.0] Documentos de la ayuda del software COCOMO II.0.
[Fenton 1997] Fenton, N.E. Pfleeger, Software Metrics. A Rigorous & Practical Approach, PWS
Publishing Company, Boston, 1997, S.L. Capitulo 7.
41

42
ENVIO:
29/05/2014 FECHA
ENTREGA:
30/05/2014
TEMA: Investigar sobre el acta de constitución.
Verifica en el proyecto a desarrollar los requisitos funcionales y no
funcionales.
OBJETIVO: Establecer los requisitos funcionales y no funcionales
PROBLEMA: Carencia de requisitos funcionales y no funcionales.
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

43

Se puede registrar desde el
momento de emitir una factura o
registrar previamente al cliente.
Se puede dar d baja al cliente o
actualizar sus datos.
48
Descripción del proyecto
Nuestro proyecto cosiste en la elaboración de un sistema de facturación y control
de inventario online que se encuentra distribuido de la siguiente manera:
Área Acción Descripción Desarrolladores
Empleados
Registrar, eliminar,
actualizar y
controlar el acceso
a los mismos.
El administrador está en la
libertad de crear usuarios
(empleados) con ciertas
restricciones, eliminarlos y
actualizarlos.
Los empleados no pueden darse
de baja.
Registrar, eliminar y
actualizar.
Clientes Andrea Buele
Control de
Asistencia
Marcar Entrada y
Salida del Personal.
Los usuarios deberán marcar su
horario de entrada y salida del
establecimiento.
Proveedores
Registrar, eliminar y
actualizar.
Se puede registrar desde el
momento de emitir una factura o
registrar previamente al
proveedor.
Se puede dar d baja al proveedor
o actualizar sus datos.
Danilo Sánchez
Factura de
Compra
Registrar y
actualizar el stock
de los productos.
Al registrar la factura en la base
de datos, se actualizara el stock o
registro de los productos.
Pedidos Registrar, ejecutar
El administrador puede registrar
el pedido de productos a un
proveedor especifico, para llevar
un control de pedido.
Facturas de
Venta
Registrar, cancelar.
Cualquier usuario puede emitir
una factura de venta, y según ello
se actualizara el stock en los
productos.
Kevin Valarezo
Cuentas por
Cobrar
Registrar, cancelar.
En este caso que se haya emitido
una factura, y no se haya
cancelado (pagado) esa venta
asa a cuentas por cobrar, para
llevar un registro de las facturas
no cancelados aun.
Productos
Registrar, actualizar
y eliminar.
La gestión de productos, su
actualización e ingreso del
producto a la papelería.

49
ALCANCE DEL PROYECTO
El proyecto se centra en la automatización de los procesos de ventas,
compras, el control de inventario y control del personal, mediante un sistema
online, minimizando el tiempo de operación que toma realizar dichos procesos
manualmente.
SUPOSICIONES
 Las actividades a realizarse dentro del proyecto deben ser
planificadas, controladas, dirigidas y organizadas por el
administrador, las misma que deben estar dentro del
cronograma elaborado al inicio del proyecto.
 Además la metodología, lenguaje de programación y tendencia
deben ser aplicados de acuerdo a las necesidades de dicha
entidad seleccionada.
RESTRICCIONES
Tiempo: Tiempo acordado, es decir no puede ni adelantarse ni
atrasarse la entrega del proyecto.
Recurso: Los Recursos Humanos asignados a este proyecto son de
tres personas.
Metodología: Metodología adaptable, escalable y flexible.
Lenguaje de Programación: Utilizar el lenguaje de programación
orientado al diseño web.

50
Hitos y Entregables del proyecto
Hitos Fecha
Asignación de Roles y Funciones del equipo de trabajo 22/05/14
Identificar necesidades del cliente 02/06/14
Redactar Visión del Proyecto 04/06/14
Definir Personajes 06/06/14
Crear el Escenario 09/06/14
Requerimientos de Servicio de Calidad 11/06/14
Estimación de costos 16/06/14
Diagramas de Caso de Uso 23/06/14
Definir Arquitectura del Proyecto 27/06/14
Diseño Modelo de Base de Datos 01/07/14
Diseño Interfaces Graficas de Usuario 07/07/14
Guía de Iteraciones 10/07/14
Programación del Sistema 14/07/14
Pruebas del Sistema 01/08/14
Correcciones del Sistema 08/08/14
Pruebas de la versión final del Sistema 15/08/14
Aprobación de la versión final del Sistema 20/08/14
Instalación del sistema 22/08/14
Entrega de manuales de usuario e instalación 26/08/14
Control de Funcionamiento 27/08/14
Entrega del proyecto 05/09/14
Presupuesto
Recursos Humanos
CANTIDAD CARGO COSTO INDIVIDUAL TOTAL
1 Administrador del Proyecto $ 0.00 $ 0.00
1 Programador $ 0.00 $ 0.00
1 Analista $ 0.00 $ 0.00
Total $ 0.00
Recursos Materiales y Varios
CANTIDAD CARGO COSTO
INDIVIDUAL
TOTAL
2 Resmas papel A4 $ 4.50 $ 9.00
1 Tinta impresora $ 9.00 $ 9.00
1 Transporte $ 10.00 $ 10.00
Total $ 28.00
Flujo de Pago
RECURSOS TOTAL
Recursos Humanos $ 0.00
Recursos Materiales y Varios $ 28.00
Imprevisto 5% (A+B) $ 1.40
Total $ 29.40

51
Aprobación del Acta
Cargo Nombre Firma Fecha
Representante
del Sponsor o
Patrocinador
Sr. Miguel Oña Diaz
Gerente del
Programa
Buele Andrea
Gerente de
Proyectos
Ing. Jimmy Rolando Molina
Ríos

52
ACTIVIDAD AUTÓNOMA:
Verificar en el proyecto a desarrollar los requisitos funcionales y no
funcionales de la empresa.
INTERESADO
PRIORIDAD
OTORGADA
POR EL
INTERESADO
REQUISITOS
Empleado
(Usuario)
Alta R02
registrados.
Alta R03
Alta R04
Alta R05
mismos.
Alta R06
El sistema permitirá generar facturas de venta.
Alta R07
factura de compra.
Alta R08
Alta R09
por cobrar.
Administrador
Alta R10
El sistema permitirá registrar las facturas de compra.
Alta R11
los productos.
Alta R18
factura de venta
Alta R19

53
INTERESADO
PRIORIDAD
OTORGADA
POR EL
INTERESADO
REQUISITOS
Administrador
Alta R20
mouse.
Alta R22
trabajo que cuente con un S.O., un navegador web Mo zilla
Google Chrome.
Alta R23
Alta R24
Patrocinador
Alta R25
Alta R26
Todos los entregables deben iniciarse y completarse en las
fechas programadas.
Reglas del negocio
 Emitir informes periódicos del rendimiento del proyecto y tomar acciones correctivas de
ser el caso.
 Mantener una comunicación fluida entre las diferentes áreas del negocio con respecto
a la ejecución del proyecto.
 Emitir informe final que evaluará el desenvolvimiento del equipo y el nivel de
cumplimiento del proyecto.

54
ENVIO:
30/05/2014 FECHA
ENTREGA:
03/06/2014
TEMA: Investigar sobre el Plan para la Direccion de Proyectos de Software.
Diseñar las ventanas de presentación del software de la empresa
definiendo el Front End a utilizar.
OBJETIVO: Evaluar conocimiento sobre norma para la dirección de proyectos.
PROBLEMA: Carencia de conocimiento sobre norma para la dirección de proyectos
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

Investigar sobre el Plan para la Direccion de Proyectos de Software.
El Plan para la Dirección del Proyecto es un documento o conjunto de documentos formalmente
aprobados, que se utilizan para dirigir la ejecución, el monitoreo y control y el cierre del proyecto.
El Director del proyecto (DP), junto con el equipo del Proyecto, es el encargado de crearlo. Es un
proceso de planificación que se repetirá a lo largo de toda la vida del Proyecto y que está
interrelacionado con las diferentes áreas de conocimiento.
El contenido del plan de gestión del proyecto variará de acuerdo con el área de aplicación y la
complejidad del proyecto. Documenta el conjunto de salidas de los procesos de planificación del
Grupo de Procesos de Planificación y debe incluir, al menos:
-Los procesos de dirección de proyectos seleccionados por el equipo de dirección del proyecto y
su nivel de implementación, junto con las descripciones de las herramientas y técnicas que se
utilizarán para llevar a cabo esos procesos y cómo se utilizarán para dirigir el proyecto específico
- Cómo se ejecutará el trabajo para alcanzar los objetivos del proyecto
- Cómo se supervisarán y controlarán los cambios
- Cómo se realizará la gestión de la configuración
- Cómo se actualizará y usará la integridad de las líneas base para la medición del
55
rendimiento
-La necesidad y las técnicas para la comunicación entre los interesados
-El ciclo de vida del proyecto seleccionado
-El Plan para la Dirección del Proyecto puede ser resumido o detallado, y constar de uno o más
planes subsidiarios y otros componentes. Cada uno de los planes subsidiarios y componentes se
detallan en la medida en que lo exija el proyecto:
- Plan de Gestión del Alcance
- Plan de Gestión de Requisitos
- Plan de Gestión del Cronograma
- Plan de Gestión de Costos
- Plan de Gestión de Calidad
- Plan de Mejoras del Proceso
- Plan de Recursos Humanos
- Plan de Gestión de las Comunicaciones
- Plan de Gestión de Riesgos
- Plan de Gestión de las Adquisiciones
- Plan de Gestión de los Interesados
Bibliografia:
Project Management Body Of Knowledge (PMBOK® Guide - Fifth Edition)

56
ACTIVIDAD AUTÓNOMA
Diseñar las ventanas de presentación del software de la empresa definiendo el Front End
a utilizar.
FLAT DESIGN
El flat design es una tendencia creciente en diseño gráfico y especialmente en el diseño web que
se basa en la máxima funcionalidad para el usuario, además de ofrecer un aspecto limpio,
estético y agradable.
¿Qué es el flat design?
El flat design (diseño plano) es un estilo de diseño que se basa en el uso de un número reducido
de elementos decorativos, además se usan colores solidos o planos (flat color), evitando el uso
de degradados, sombreados, biselados u otro tipo de efectos, quizá como respuesta al uso de
estos en el diseño gráfico de la última década, debido en parte a la popularización de photoshop
y otros programas de diseño, que hizo que hoy se asocie el excesivo uso de filtros y efectos con
un diseño aficionado y poco profesional.
Uno de los mejores ejemplos de la popularización de este diseño, es el radical cambio
experimentado por la interfaz del correo web de Microsoft; antiguo hotmai l, ahora outlook, que ha
cambiado completamente el diseño de su interfaz para adecuarla a las líneas claras y limpias
adoptadas en las últimas versiones de windows.
Elementos del flat design
La gama de colores usados en flat design suele ser reducida, y optarse más por el mismo tono
con diferente saturación, para crear leves contrastes entre las imágenes, el texto y el fondo,
aunque hay que tener en cuenta que esos contrastes tan leves funcionan bien en una pantalla de
ordenador, pero no tanto en un documento para imprenta.
Los diseños vectoriales también se asocian al flat design, no sólo en el diseño web sino también
a la imagen corporativa y a los logotipos e iconos, siguiendo el diseño impuesto por el
omnipresente Apple, los logos usan cada vez más de siluetas en si diseño y huyen del
recargamiento.El flat design muy usado en el diseño web, también usa de tipografías ‘sans serif’,
o ‘sin remate’ (arial, futura, tahoma, etc..) y con el menor recargamiento posible. También es
importante que exista un diseño estructurado en cuadrícula con abundantes espacios entre
líneas, igualmente suele usarse una justificación con un tamaño de columna reducido para los
textos y anchos márgenes que den respiro al lector.
Ventajas del flat design
Una de las ventajas del flat design es su sencillez de ejecución, aunque no hay que engañarse,
esa sencillez no lo es tanto de concepto, pues los diseños minimalista no son tan fáciles de
concebir como podría parecer.

No obstante, en el flat design, la sencillez y claridad de líneas, suele venir acompañada
reducción de elementos visuales, elementos interactivos y opciones, muchas veces redundantes,
que saturan la web con exceso de información, haciendo la experiencia de navegar por la web
más sencilla e intuitiva.
En cualquier caso, como cualquier tendencia o estilo, el flat design está sujeto a continua
revisión y cambio, y geguramente esta tendencia derivará en otra. ¿Cómo será?, puede que eso
sólo se sepa con el tiempo, de momento, hoy por hoy el flat design sigue en contínua expansión.
57
PROTOTIPOS
- Inicio de Sesión
- Menú Contextual

58
- Gestión de Proveedores
-
Gestión Clientes

59
- Gestión Usuarios
- Edición de datos del usuario

60
- Gestión de inventario
- Factura de compra

61
- Factura de venta
- Lista facturas de compra

62
- Lista facturas de venta
- Cuentas por cobrar

63
- Comprobante Cuenta por Cobrar
- Pedido

UNIDAD IV: PMBOK.
ÁREAS DE
CONOCIMIENTO
65

66
ENVIO:
03/06/2014 FECHA
ENTREGA:
05/06/2014
TEMA: Profundizar en la investigación sobre los factores ambientales en la
administración de proyectos de software.
Definir en la empresa seleccionada las entradas, herramientas
técnicas y salidas.
UNIDAD N°:4 PMBOK Áreas de Conocimiento
OBJETIVO: Identificar procesos y actividades en la gestión de integración del
proyecto.
PROBLEMA: Carencia sobre conocimiento de la gestión de integración del proyecto
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

67
INTRODUCCIÓN
Los factores ambientales pueden tener un impacto en la gestión de proyectos, incluso en
ambientes que son relativamente estables. Desde el acceso al capital, para tener acceso a la
tecnología, al acceso a las personas, los proyectos tienen éxito o fracasan según la capacidad
de los líderes del proyecto para aprovechar al máximo los recursos disponibles.
MARCO TEORICO
Factores Ambientales de la Empresa
“Los factores ambientales de la empresa se refieren a elementos, tanto internos como externos,
que rodean el éxito de un proyecto o influyen en él. Estos factores pueden provenir de cualquiera
de las empresas implicadas en el proyecto”4.
Los factores ambientales de la empresa pueden aumentar o restringir las opciones de la
dirección de proyectos, y pueden influir de manera positiva o negativa sobre el resultado.
Al desarrollar el acta de constitución del proyecto, se deben tener en cuenta todos y cada uno de
los factores ambientales de la empresa y de los sistemas de la organización que estuvieran
relacionados con el éxito del proyecto o pudieran influir sobre él de alguna manera.5 Esto incluye,
entre otros, conceptos tales como:
 Cultura y estructura de la organización o empresa
 Normas gubernamentales o industriales (por ejemplo, reglamentaciones de agencias
reguladoras, normas de productos, estándares de calidad y normas de fabricación)
 Infraestructura (por ejemplo, instalaciones existentes y equipos de capital)
4 (david, 2013)
5 (Project Management Institute, Inc., 2008)

 Recursos humanos existentes (por ejemplo, habilidades, disciplinas y conocimientos,
tales como diseño, desarrollo, legales, contrataciones y compras)
 Administración de personal (por ejemplo, guías de contratación y despido, evaluaciones
del rendimiento de los empleados y registros de formación)
 Sistema de autorización de trabajo de la compañía
 Condiciones del mercado
 Tolerancia al riesgo de los interesados
 Bases de datos comerciales
 Sistemas de información de la gestión de proyectos (por ejemplo, los conjuntos de
herramientas automatizadas, tales como las herramientas de software para la
elaboración de cronogramas, los sistemas de gestión de la configuración, los sistemas
de recogida y distribución de información, o las interfaces web con otros sistemas
automatizados en línea).
FACTORES AMBIENTALES EN EL DESARROLLO DE NUESTRO PROYECTO
Los factores ambientales que influyen en el desarrollo de nuestro proyecto son:
 Disponibilidad. ¿Quiénes están disponibles y cuándo?
 Capacidad. ¿Qué competencias poseen las personas?
 Experiencia. ¿Las personas han realizado trabajos similares o relacionados? ¿Los han
68
realizado bien?
 Intereses. ¿Las personas están interesadas en trabajar en este proyecto?
 Cultura y estructura de la organización o empresa
ACTIVIDAD AUTÓNOMA
DEFINIR LAS ENTRADAS, HERRAMIENTAS, Y SALIDAS
Gestión de Integración
ENTRADAS HERRAMIENTAS Y
TECNICAS
SALIDAS
• Enunciado del trabajo del
proyecto (SOW)
• Caso de Negocio
• Factores ambientales de la empresa
• Activos de los procesos de
la organización
• Juicio de expertos
• Técnicas de Facilitación
• Reuniones
• Acta de constitución
del proyecto

69
Gestión de Interesados
ENTRADAS HERRAMIENTAS Y
TECNICAS
SALIDAS
• Enunciado del trabajo del proyecto
(SOW)
• Caso de Negocio
• Activos de los procesos de la
organización
• Análisis de los
interesados
• Juicio experto
• Reuniones
•Registro de
interesados
BIBLIOGRAFIA:
david. (19 de julio de 2013). wordpress. Recuperado el 4 de junio de 2014, de
http://daviddmb.wordpress.com/2013/07/19/10-factores-ambientales-de-la-empresa/
Project Management Institute, Inc. (2008). FUNDAMENTOS PARA LA DIRECCION DE
PROYECTOS (GUIA DEL PMBOK (R)). EEUU.
Richards, L., & Media, D. (s.f.). La voz de Houston. Recuperado el 4 de junio de 2014, de
http://pyme.lavoztx.com/qu-factores-ambientales-en-una-empresa-pueden-afectar-la-forma-en-que-
un-proyecto-es-administrado-4261.html

70
ENVIO:
05/06/2014 FECHA
ENTREGA:
06/06/2014
TEMA: Identificar acciones que permitan monitorear y controlar el trabajo del
proyecto.
Definir la información sobre el desempeño del trabajo en la empresa
seleccionada y relacionarlo con la Gestión de Seguimiento y Control.
OBJETIVO: Esclarecer las áreas de conocimiento – Gestión de la Integración del
Proyecto.
PROBLEMA: Necesidad de definir las áreas de conocimiento – Gestión de la
Integración del Proyecto.
INDICADOR DE
EVALUACION:
DESCRIPCIÓN:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

Identificar acciones que permitan monitorear y controlar el trabajo del proyecto.
De acuerdo al PMBOK, Monitorear y Controlar el trabajo del proyecto es el proceso que consiste
en monitorear, analizar y regular el avance a fin de cumplir con los objetivos de desempeño
definidos en el plan para la dirección del proyecto. El seguimiento es un aspecto de la dirección
del proyecto que se realiza a lo largo del proyecto. Consiste en recopilar, medir y distribuir la
información relativa al desempeño, y en evaluar las mediciones y las tendencias que van a
permitir efectuar mejoras al proceso. El seguimiento continuo proporciona al equipo de dirección
del proyecto conocimientos sobre la salud del proyecto y permite identificar las áreas
susceptibles de requerir una atención especial. El control consiste en determinar acciones
preventivas o correctivas, o en modificar los planes de acción y hacer un seguimiento de los
mismos a fin de determinar si las acciones emprendidas permitió resolver el problema de
desempeño. El proceso monitorear y controlar el trabajo del proyecto consiste en:
• Comparar el desempeño real del proyecto con respecto al plan para la dirección del proyecto.
• Evaluar el desempeño para determinar la necesidad de una acción preventiva o correctiva y
para recomendar aquéllas que se consideran pertinentes.
• Identificar nuevos riesgos y analizar, revisar y monitorear los riesgos existentes del proyecto,
para asegurarse de que se identifiquen los riesgos, se informe sobre su estado y se implementen
los planes apropiados de respuesta a los riesgos.
• Mantener, durante la ejecución del proyecto, una base de información precisa y oportuna
relativa al producto o a los productos del proyecto y su documentación relacionada.
• Proporcionar la información necesaria para sustentar el informe de estado, la medición del
avance y las proyecciones.
• Proporcionar proyecciones que permitan actualizar la información relativa al costo y al
cronograma actual.
• Monitorear la implementación de los cambios aprobados cuando éstos se produzcan.
Realizar un análisis de cómo va el proyecto es una tarea que se debe realizar constantemente, y
el proceso de monitorear y controlar el proyecto nos permite realizar de manera adecuada este
análisis.
71
Bibliografia:
http://whatisprojectmanagement.wordpress.com/2012/10/23/monitorear-y-controlar-el-trabajo/

72
ENVIO:
06/06/2014 FECHA
ENTREGA:
10/06/2014
TEMA: Norma para la direccion de proyectos.
OBJETIVO: Evaluar conocimiento sobre la Gestión de la Integración del proyecto.
PROBLEMA: Falta de conocimiento sobre la Gestión de la Integración del proyecto.
INDICADOR DE
DESCRIPCIÓN:
EVALUACION:
Asuntos
contemporáneos
Siempr
e
(2)
A veces
(1)
Nunc
a
(0.5)
- EXPRESIÓN.
- MATERIAL:
- EJEMPLOS.
- CONTENIDO.
TIPO DE ACTIVIDAD
LUGAR ALCANCE FORMA
□Int raclase
▪Extraclase
□Individual
▪Grupal
□Taller
□Caso de estudio
▪Investigativa
ejercicios
CALIFICACIÓN

73
Norma para la dirección de Proyectos
Define los procesos de dirección de proyectos y define las entradas y salidas para cada proceso.
El Capítulo 3, Procesos de Dirección de Proyectos para un Proyecto, define los cinco grupos de
procesos: Iniciación, Planificación, Ejecución, Seguimiento y Control, y Cierre. Este capítulo
relaciona las Áreas de Conocimiento de la Dirección de Proyectos con los grupos de Procesos
específicos de la dirección de proyectos.
Iniciación
Compuesto por aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de
un proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto
o fase. Dentro de los procesos de iniciación, se define el almacén inicial y se comprometen los
recursos financieros iniciales.
Planificación
Consta de aquellos procesos realizados para establecer el almacén total del esfuerzo, definir y
refinar los objetivos, y desarrollar la línea de acción requerida para alcanzar dichos objetivos.
Ejecución
Procesos realizados para completar el trabajo definido en el plan para la dirección de proyectos a
fin de cumplir con las especificaciones del mismo.
Este grupo de proceso implica coordinar personas y recursos, así como integrar y realizar las
actividades del proyecto de conformidad con el plan para la dirección del proyecto.
Seguimiento y Control
Está compuesto por aquellos procesos requeridos para supervisar, analizar y regular el progreso
y el desempeño del proyecto, para identificar áreas en las que el plan requiera cambios y para

iniciar los cambios correspondientes. El beneficio clave de este grupo radica en que el
desempeño del proyecto se observa y se mide de manera sistemática y reg ular, a fin de
identificar variaciones respecto del plan para la dirección del proyecto.
74
Cierre
Procesos realizados para finalizar todas las actividades a través de todos los grupos de procesos
de la dirección de proyectos, a fin de completar formalmente el proyecto, una fase del mismo u
otras obligaciones contractuales.
Este grupo de procesos, una vez completado, verifica que los procesos definidos se hayan
completado dentro de todos los grupos de procesos a fin de cerrar el proyecto o una fase del
mismo, según corresponda, y establece formalmente que el proyecto o fase del mismo ha
finalizado.
Bibliografía
https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-requisitos-funcionales-
y-no-funcionales

ACTIVIDAD AUTÓNOMA
75
INTERESADO
PRIORIDAD
OTORGADA
POR EL
INTERESADO
REQUISITOS
Empleado
(Usuario)
Alta R02
registrados.
Alta R03
Alta R04
Alta R05
mismos.
Alta R06
El sistema permitirá generar facturas de venta.
Alta R07
factura de compra.
Alta R08
Alta R09
por cobrar.
Administrador
Alta R10 El sistema permitirá registrar las facturas de compra.
Alta R11
los productos.
Alta R18
factura de venta
Alta R19

76
INTERESADO
PRIORIDAD
OTORGADA
POR EL
INTERESADO
REQUISITOS
Administrador
Alta R20
mouse.
Alta R22
trabajo que cuente con un S.O., un navegador web Mo zilla
Google Chrome.
Alta R23
Alta R24
Patrocinador
Alta R25
Alta R26
Todos los entregables deben iniciarse y completarse en las
fechas programadas.
Reglas del negocio
 Emitir informes periódicos del rendimiento del proyecto y tomar acciones correctivas de
ser el caso.
 Mantener una comunicación fluida entre las diferentes áreas del negocio con respecto
a la ejecución del proyecto.
 Emitir informe final que evaluará el desenvolvimiento del equipo y el nivel de
cumplimiento del proyecto.

Tareas extraclase

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Similar a Tareas extraclase

Similar a Tareas extraclase (20)

Tareas extraclase