2324

UNIDAD
CONCEPTOS SOBRE GESTION DE

PROYECTOS
1
1. INTRODUCCION
¿Qué es la Gestión de Proyectos?
Implica la planificación, supervisión y control

del personal, del proceso mientras evoluciona el
software (desde la fase preliminar hasta la
implementación)
2
Gestión de Proyectos
Para comprender mejor debemos
respondernos las siguientes preguntas:
1. ¿Quién lo hace?
2. ¿Por qué es importante?
3. ¿Cuáles son los pasos?
4. ¿Cuál es el producto obtenido?
3
¿Quién lo hace?
Un INGENIERO DE SOFTWARE gestiona sus actividades
diarias, y planifica, supervisa y controla las labores
técnicas.
Los GESTORES DEL PROYECTO planifican, supervisan y
controlan el trabajo del equipo.
Los GESTORES EJECUTIVOS coordinan la relación entre
el negocio y los profesionales de software
4
¿Por qué es importante?
La construcción de software es una empresa compleja,

sobre todo cuando trabaja mucha gente durante un
tiempo relativamente largo, por esto es importante la
planificación. Supervisión y control.
Es muy importante que los Proyectos Software sean gestionados5

¿Cuáles son los pasos?
Las cuatro “P`s”
Personal Producto Proceso Proyecto
Debe estar Se debe planificar

organizado para Debe haber Debe
Comunicación Con seleccionarse el para estimar el
Desarrollar esfuerzo y el
software con el proceso adecuado
Cliente para que para el personal tiempo
efectividad
sea comprensible el como para el
ámbito y los producto
requisitos
6
¿Cuál es el producto obtenido?
Un plan de proyecto se realiza al comienzo de cada

gestión, este plan define el proceso y las tareas a
realizar, el personal que hará el trabajo y los
mecanismos para evaluar los riesgos, controlar el
cambio y evaluar la calidad.
7
2. EL ESPECTRO DE LA GESTION
La gestión eficaz de un proyecto de software se centra en las 4 P`s.

Un gestor que no establece una buena comunicación con el usuario al
principio de la evolución del proyecto se arriesga a construir una
elegante solución para un problema equivocado. Por otro lado, un
Adm. que presta poca atención al proceso corre el riesgo de arrojar
métodos técnicos y herramientas eficaces al vació.
El gestor que comprende un proyecto sin un plan

sólido arriesga el éxito del producto.
Personal
Producto
ESPECTRO DE LA GESTION
Proceso
Proyecto
8
2.1 Personal
Este factor es tan importante que el Instituto de Ing. de Software

ha desarrollado un Modelo de Madurez de Capacidad de Gestión
de Personal MMCGP, para llevar a cabo las cada vez más
complicadas APLICACIONES ayudando a atraer, aumentar,
motivar, desplegar y retener talento necesario para mejorar su
capacidad de desarrollo de software.
Atraer
Aumentar
El TALENTO necesario
Motivar para mejorar su
CAPACIDAD DE
Desplegar DESARROLLO DE
SOFTWARE
Retener
9
2.1 Personal
EL MMCGP define las siguientes áreas calve practicas para el personal de

software:
RECLUTAMIENTO
ELECCIÓN
GESTION DEL DESEMPEÑO MAYOR
ENTRENAMIENTO PROBALIDAD
RETRIBUCION de implementar
DESARROLLO DE LA CARRERA efectivas
DISEÑO DE LA ORGANIZACIÓN practicas de
DESARROLLO DE LA CULTURA DE EQUIPO ingeniería de
software
10
2.1 Personal
PARTICIPANTES
1. Gestores ejecutivos Definen los aspectos del negocio
2. Gestores del proyecto Planifican, motivan, organizan y

(técnicos) controlan a los profesionales que
realizan el software
3. Profesionales Proporcionan las habilidades técnicas

necesarias para realizar la ingeniería
4. Clientes Especifican la ingeniería de software
5. Usuarios finales Quienes interactúan con el software
Para los LIDERES DEL EQUIPO se debe utilizar la técnica MOI 11

2.1 Personal
EQUIPO DE SOFTWARE
Existen SIETE aspectos importantes que se deben considerar cuando se
planifica la estructura de los equipos de INGENIERIA DE SOFTWARE.
12
2.2 Producto
Antes de planificar un proyecto, se debe establecer:
 Los objetivos y el ámbito del producto

 Considerar las soluciones y alternativas
 Identificar las dificultades técnicas o de gestión.
Sin esta información es imposible definir unas estimaciones razonables

de:
 coste
 Valoración efectiva del riesgo
 Subdivisión realista de las tareas del proyecto
 Una planificación del proyecto asequible que proporcione una
indicación fiable del proyecto.
13
2.2 Producto
El desarrollador y el cliente deben reunirse para definir los objetivos del

producto.
 Es parte del proceso de ingeniería del sistema o del negocio

 Se conforma como el primer paso en el análisis de los requisitos
de software
Los objetivos identifican las metas generales del proyecto sin considerar
como se conseguirán.
 El ámbito identifica los datos primarios, funciones y comportamientos

que caracterizan al producto.
 Una vez que se han entendido los objetivos y ámbito del producto
se consideran soluciones alternativas.
14
2.2 Producto
AMBITO DE SOFTWARE
CONTEXTO: ¿Cómo encaja el software que se desarrollará en un sistema

mas grande?
OBJETIVOS DE INFORMACION: ¿Qué objetos de datos visibles al
usuario se producen como resultado del software?
FUNCIONES Y DESEMPEÑO: ¿Qué funciones realiza el software para
transformar los datos?
El AMBITO EL PROYECTO no debe ser ambiguo ni incomprensible a
niveles de gestión y técnico. Se debe describir:
DATOS CUANTITATIVOS (número de usuarios, tiempo de respuesta)

RESTRICCIONES Y LIMITACIONES (costo del producto, tamaño de la
memoria)
FACTORES QUE REDUCEN RIESGOS (algoritmos deseados)
15
2.2 Producto
DESCOMPOCISON DEL PROBLEMA
Llamada PARTICION O ELABORACION DEL

PROBLEMA, es una actividad que se asienta en el
núcleo del análisis de requisitos de software.
16
2.3 Proceso
Proporciona el marco de trabajo desde el cual se puede establecer un plan

detallado para el desarrollo de software.
El problema es seleccionar el MODELO DE PROCESO apropiado para

que un equipo de proyecto someta el software a ingeniería.
17
2.3 Proceso
Inicio del Proyecto

COMUNICACION
Recopilación de requisitos
Inicio del Proyecto

PLANEACION
Recopilación de requisitos
MODELADO Análisis
Diseño
CONSTRUCCION Código Prueba
Entrega
DESPLIEGUE
Soporte
18
2.3 Proceso
El Modelo de Cascada, sugiere un enfoque sistemático, secuencial

hacia el desarrollo del software, que se inicia con la especificación de
requisitos del cliente y que continua con la planeación, el modelado, la
construcción y el despliegue para culminar con el soporte de software
terminado.
El Modelo Cascada es el mas antiguo parar al Ingeniería de Software.
COMUNICACION
PLANEACION
MODELADO
CONSTRUCCION
DESPLIEGUE
19
2.3 Proceso
El Modelo Incremental combina elementos del modelo de cascada

aplicado en forma iterativa. Aplica secuencias de líneas de manera
escalonada conforme avanza el tiempo en el calendario . Cada
secuencia produce “incrementos de software” .
Modelo incremental se enfoca en la entrega de un producto

operacional con cada incremento. Los primeros incrementos son
versiones “incompletas” del producto final, pero proporcionan al
usuario la funcionalidad que necesita y una plataforma para evaluar.
El desarrollo incremental es útil sobre todo cuando el personal

necesario para una implementación completa no esta disponible, por lo
cual las primeros implementos se puede hacer con menos personas20.
2.3 Proceso
Funcionalidad y características del software
COMUNICACION
PLANEACION
MODELADO
CONSTRUCCION
COMUNICACION DESPLIEGUE
PLANEACION
MODELADO
CONSTRUCCION
COMUNICACION DESPLIEGUE
PLANEACION
MODELADO
CONSTRUCCION
DESPLIEGUE
21
Tiempo del calendario del proyecto
2.3 Proceso
El Modelo DRA Modelo de Desarrollo Rápido de aplicaciones, es un

modelo de proceso de software incremental que resulta un ciclo de
desarrollo corto. Es una adaptación a “alta velocidad” del modelo en
cascada.
Cumple con las actividades: Comunicación, Plantación el Modelado

incluye tres grandes fases: MODELADO DE NEGOCIOS,
MODELADO DE DATOS, y MODELADO DE PROCESOS, la
Construcción resulta reutilización de componentes, generación de
código automático, y pruebas; Por ultimo el despliegue establece la
base para las iteraciones subsecuentes.
Si una aplicación de negocios se puede modular de forma que cada
22
gran función pueda completarse en tres meses.
2.3 Proceso
23
2.3 Proceso
Se utiliza cuando el cliente no identifica correctamente los requisitos

de entrada, o el responsable del desarrollo del software esta inseguro
de la eficacia de un algoritmo.
comunicación PLAN RAPIDO
Desarrollo entrega y
Modelado del
retroalimentación diseño rápido
Construcción del
prototipo
24
2.3 Proceso
TRABAJO EN GRUPO
1. PROCESOS UNIFICADO
2. MODELOS AGILES DE PROCESO
a) PROGRAMACION EXTREMA (PE)
b) DESARROLLO ADAPTATIVO DE SOFTWARE (DAS)
c) METODO DE DESARROLLO DE SISTEMAS DINÀMICOS (MDSD)
d) DESARROLLO CONDUCIDO POR CARACTERISTUCAS (DCC)
e) MODELO AGIL
Presentar un informe y una breve explicación acerca del modelo
25
2.4 Proyecto
Es la única manera de gestionar la complejidad que existe en la

construcción de software.
Se define riesgos en el proyecto de software:
1. El personal de software no entiende las necesidades de sus clientes.

2. El ámbito del producto esta mal definido.
3. Los cambios se gestionan mal.
4. Los plazos de entrega no son realistas.
5. El equipo de proyecto carece de personal con las habilidades
apropiadas.
Para evitar el fracaso del proyecto, un gestor y los ingeriros de software

que contribuyen al producto, deben desarrollar un enfoque común para
PLANIFICAR, SUPERVISAR Y CONTRLAR EL PROYECTOS.
26
27
UNIDAD 2
PLANIFICACION DE PROYECTOS
DE SOFTWARE
28
PLANIFICACION DE PROYECTOS DE SOFTWARE
La gestión de un proyecto de software comienza con

un conjunto de actividades que globalmente se
denominan PLANIFICACIÓN DEL PROYECTO.
Antes de que el proyecto comience, el gestor y el

equipo de software deben realizar una ESTIMACIÓN del
trabajo a realizar, de los recursos necesarios y del
tiempo que transcurrirá desde el comienzo hasta el
final de su realización. Siempre que ESTIMAMOS,
estamos mirando hacia el futuro y aceptamos
resignados cierto grado de incertidumbre.
29
La primera de estas actividades es la ESTIMACIÓN de

costes y tiempos
Como la estimación es la base de la planificación, hay

que prestarle especial atención.
La estimación la lleva a cabo el gestor del proyecto

La estimación y planificación de un proyecto software
requiere:
Experiencia.
Buena información histórica.
Coraje de confiar en las métricas y la
experiencia. 30
2.1. OBSERVACION SOBRE LA ESTIMACION
Hay cuatro factores que influyen

significativamente en las estimaciones:
La complejidad del proyecto.

El tamaño del proyecto.
El grado de incertidumbre estructural.
Disponibilidad de información histórica.
31
2.1.1. Complejidad del proyecto
La complejidad es relativa a la experiencia en

proyectos anteriores.
Existen medidas sobre la complejidad de
proyectos basadas en el diseño y código
(métricas, técnicas).
En la fase de estimación no son aplicables porque
no hay ni diseño ni código.
Por eso hay que utilizar medidas más subjetivas
(e.j. PF)
32
2.1.2. TAMAÑO DEL PROYECTO
En los proyectos grandes, crece la interdependencia

entre los componentes del proyecto.
descomposición del
dificulta el
Interdependencia proceso de
producto en elementos
estimación
33

2.1.3. GRADO DE INCERTIDUMBRE ESTRUCTURAL
Estructura:
Grado en que los requisitos se han definido.

Facilidad con la que se pueden compartir funciones.
Naturaleza jerárquica de la información a procesar.
Incertidumbre mejor descomposición

mejor estimación.
estructural baja del producto
34

2.1.4 INFORMACIÓN HISTÓRICA
“Aquellos que no pueden recordar el pasado, están condenados a

repetirlo”.
La existencia de métricas del software de proyectos anteriores facilita la

estimación.
TAMBIEN SE DEBE TOMAR EN CUENTA:
En cualquier caso, la estabilidad de los requisitos por parte del

cliente es fundamental para la estimación
Si los requisitos cambian, la estimación no vale
Por eso son buenos los modelos de proceso ágiles

35
2.2.5 OBJETIVO DE LA ESTIMACION

Definir los escenarios del mejor caso y del peor caso de forma que
los resultados del PROYECTO DE SOFTWARE puedan limitarse
¿Qué es el peor caso en un proyecto

real de ingeniería?
36
2.2 PLANIFICACION DE PROYECTO
2.2.1 OBJETIVO DE LA PLANIFICACION

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, coste 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 a medida que progresa el proyecto.
37
2.2.2 AMBITO DE SOFTWARE

Es la primera actividad de la planificación del proyecto de software,
se debe delimitar su declaración.
El ámbito del software describe:
El control y los datos a procesar

La función
El rendimiento
Las restricciones
Las interfaces
38

El cliente es el único que puede ayudarnos a determinar el ámbito
Por tanto la comunicación con el cliente es fundamental
La comunicación se puede iniciar con las preguntas de contexto
libre
Hay tres grupos dentro de estas preguntas
El primer grupo se centra en el cliente, los objetivos globales y

los beneficios:
El segundo grupo permiten comprender mejor el problema y
que el cliente exprese sus percepciones sobre una solución:
El último grupo se centra en la efectividad de la reunión.
39

El primer grupo se centra en el cliente, los objetivos globales
y los beneficios:
¿Quién está detrás de ¿Quién está detrás ¿Hay otro camino
la solicitud de este de la solicitud de este para la solución?
trabajo? trabajo?
¿Quién utilizará ¿Cuál será el beneficio

esta solución? económico de una buena40
solución?

El segundo grupo permiten comprender mejor el problema y que el
cliente exprese sus percepciones sobre una solución:
¿Cómo caracterizaría (el cliente) un ¿Con qué problemas se
resultado correcto que se generaría
enfrentará esta solución?
con una solución satisfactoria?
¿Hay aspectos o limitaciones

especiales de rendimiento que ¿Puede mostrarme (describirme) el
afecten a la forma en que se entorno en el que se utilizará la
aborde la solución? solución?

El último grupo se centra en la efectividad de la reunión. Se denominan
metacuestiones:
¿Es usted la persona apropiada para responder a estas

preguntas? ¿Son oficiales sus respuestas?
Son relevantes mis preguntas para su problema

¿Estoy realizando muchas preguntas?
¿Hay alguien más que pueda proporcionar información adicional?
¿Hay algo más que debiera preguntarle?
Estas preguntas y otras similares ayudan a romper el hielo y a iniciar la

comunicación esencial para establecer el ámbito del proyecto
42

Sin embargo esto es el comienzo, y solo sirve para el primer encuentro
Después deberían utilizarse técnicas de especificación más concretas. Por

ejemplo disponemos de las TÉCNICAS ÚTILES PARA LA
ESPECIFICACIÓN DE APLICACIONES (TUE).
Las TUE presentan variaciones de la siguiente aproximación:
Se realiza la reunión en un lugar a convenir por clientes y desarrolladores.

Se propone una agenda lo suficientemente formal para cubrir todos los
puntos importantes, pero lo suficientemente informal para permitir
el flujo de ideas.
43

LA REUNION
Un moderador (desarrollador o cliente) controla la reunión.

Se establece un mecanismo de presentación (transparencias, pizarra,
etc.).
Los objetivos son:
Identificar el problema.
Proponer elementos de la solución.
Negociar las distintas aproximaciones.
Especificar un conjunto preliminar de requisitos.
44

Hay una preparación antes de la primera reunión TUE:
Antes de la reunión se debe realizar una entrevista en la que se realizan

preguntas de contexto libre para ayudar a establecer el ámbito.
De esta reunión salen una o dos páginas de requisitos del

producto.
Se eligen lugar, fecha, participantes y moderador de la reunió
45

ANTES DE LA REUNIÓN LOS ASISTENTES DEBEN REDACTAR:
- Una lista de objetos que son parte del entorno que rodea al
sistema (e.j. archivos, dispositivos, etc.), que serán producidos
por el sistema y que utiliza el sistema para llevar a cabo su
funcionalidad.
- Una lista de operaciones que manipulan o interactúan con los
objetos.
- Una lista de restricciones (e.j. coste, tamaño) y criterios de
prestaciones (e.j. velocidad, precisión.).
46

DURANTE EL DESARROLLO DE LA REUNIÓN TUE:
La primera Se presentan No se Después de que

cuestión que las listas permiten cada persona
se debe tratar utilizando el críticas ni expone su lista
es la medio debate. sobre un tema
necesidad y convenido de determinado, se
razón del tal forma que realiza una lista
nuevo se puedan aditiva combinada
producto. modificar. para cada tema
(objetos,
operaciones y
restricciones).
47

Una vez completadas las listas:
Se forman para una o varias

entradas de la lista
subequipos que realizan
una miniespecificación
Aquí se añaden o eliminan

ideas y se permite la discusión.
Por lo general serán necesarias varias reuniones TUE

48

Además del ámbito el software interactúa con otros elementos
Hardware.
Por tanto el
concepto de interfaz
Procedimientos también es vital Software.
para la planificación
temporal
De usuario.
49

OTRO ASPECTO IMPORTANTE DURANTE LA ESTIMACIÓN ES EL DE
LA FIABILIDAD DEL SOFTWARE
El gestor/planificador tendrá que

aproximarla lo más posible
mediante la declaración del ámbito
50
2.2.3 RECURSOS
La segunda tarea de la planificación del desarrollo de software es la
ESTIMACIÓN DE RECURSOS requeridos para acometer el
esfuerzo de desarrollo
Estos recursos pueden considerarse una pirámide:
Personas.
Componentes software reutilizables.
Herramientas de hardware/software.
2.2.3 RECURSOS
52

2.2.3 RECURSOS
Cada recurso queda especificado mediante cuatro

características:
Descripción del recurso.
Informe de disponibilidad.
Fecha cronológica en la que se requiere el recurso.
Tiempo durante el que será aplicado el recurso
.
2.2.3 RECURSOS
RESPECTO AL PERSONAL HAY QUE ESPECIFICAR SU POSICIÓN EN LA
ORGANIZACIÓN Y SU ESPECIALIDAD
El número de personas requerido debe estimarse

2.2.3 RECURSOS
GRAN PARTE DE LA REUTILIZACIÓN DEL SOFTWARE SE DEBE A LA
TECNOLOGÍA DE COMPONENTES
Ya Ya Con experiencia
Nuevos
desarrollados. experimentados parcial
Respecto a la planificación, tenemos cuatro tipos de componentes:

2.2.3 RECURSOS
Componentes ya desarrollados
Componente adquirido o existente.
Validados.
Listos para utilizarse

2.2.3 RECURSOS
Componentes ya experimentado
Especificaciones, diseños, códigos o datos de prueba ya existentes

desarrollados anteriormente y similares a los requeridos.
Miembros del equipo con experiencia completa en el dominio de

aplicación de los componentes.
Riesgo bajo ante las modificaciones.

2.2.3 RECURSOS
Componentes con experiencia parcial
Especificaciones, diseños,
códigos o datos de prueba ya Experiencia limitada del equipo
existentes desarrollados en el dominio de aplicación de los
anteriormente y relacionados componentes.
con los requeridos.
Requieren una modificación

Alto riesgo ante las modificaciones.
sustancial.

2.2.3 RECURSOS
Componentes nuevos
Componentes a construir.
Directrices
En cuanto para laa
elección
los derecursos
componentes:
de entorno
También hay que planificar el acceso a
debemos
hardware constatar
o recursos
1. Adquirir queespecíficos
componentes yano hay problemas
(e.J. la
desarrollados.
con el
2.software
barrera) de desarrollo
Modificar componentes (E.J. número de
ya experimentados.
3. No aceptar componentes con experiencia parcial
licencias)
2.3 TECNICAS DE ESTIMACION
 Estimar el coste del software es vital

 Las estimaciones nunca podrán ser exactas
 Cuanto mejor estimemos, más rentable será nuestro
proyecto
 Basar las estimaciones en proyectos similares que ya
hayan sido completados.
 Emplear técnicas de descomposición relativamente
simples para generar estimaciones de costo y esfuerzo de
proyecto.
 Estimar es difícil, ya que:
Los requisitos iniciales no están totalmente
delimitados.
Puede que necesitemos utilizar tecnologías nuevas.
2.4 TECNICAS DE DESCOMPOSICION

2.4.1 Tamaño de Software
La precisión de la estimación de un Proyecto de Software se
manifiesta en varios factores:
1. El grado con el cual el planificador ha estimado

adecuadamente el tamaño del producto que se
CONSTRUIRA.
2. La habilidad para traducir la estimación del tamaño en
esfuerzo humano, programa de trabajo y dinero
3. El grado en el cual el Plan de Proyecto refleja las
habilidades del equipo de software
4. La estabilidad de los requisitos del producto y el entorno
que soporta el esfuerzo de Ingeniería de Software

Se refiere a un
resultado PROYECTO DE SOFTWARE
cuantificable
El TAMAÑO DE SOFTWARE Desafió del Planificador
Líneas de Código Puntos de Función

LDC PF

Se sugieren cuatro diferentes enfoques al problema del tamaño
1. Tamaño en lógica difusa

2. Tamaño de punto de función
3. Tamaño de componentes estándar
4. Tamaño del cambio

Tamaño en lógica difusa: Este enfoque usa técnicas

aproximadas de razonamientos, establece su magnitud en
una escala CUALITATIVA y luego refine la magnitud
dentro del rango original.
Tamaño de componentes estándar: El planificador de

proyectos desarrolla estimaciones de características del
dominio de información (PF)

Tamaño de componentes estándar: El software se compone de
un número de “componentes estándar” que son genéricos para un
área en particular para un sistema de información son:
subsistemas, módulos, pantallas, informes, programas interactivos.
El planificador de proyectos estima el número de incidencias de
cada uno de los componentes estándar y utiliza datos de proyectos
históricos para determinar el tamaño de entrega por componente
estándar.
Tamaño del cambio: El enfoque se utiliza cuando un proyecto

comprende la utilización de software existente que se debe
modificar de alguna manera como de un proyecto como parte de
un proyecto. El planificador estima el número y tipo de
modificaciones que se deben llevar a cabo.

2.4.2. Estimación basada en el problema
El planificador del PROYECTO DE SOFTWARE comienza
estimando una gama de valores para cada función o valor de
dominio de información. Al emplear datos históricos o
intuición, el planificador estima un valor de tamaño optimista,
más probable y pesimista para cada función.
Líneas de Código
LDC
≠ Puntos de Función
PF

Al emplear LDC como variable de estimación de descomposición es
absolutamente esencial y con frecuencia se lleva a grados considerables
de detalle: Mientras mayor sea el grado de partición es más probable que
se desarrolle una estimación razonablemente precisa.
En las estimaciones de PF la descomposición funciona de manera diferente.

Mas que enfocarse sobre la función, se estima cada uno de las cinco
características:
1. Número de entradas externas (EE)

2. Número de Salidas externas (SE)
3. Número de consultas externas (CE)
4. Número de archivos lógicos internos (ALI)
5. Número de archivos de interfaz externos (AIE)

Cuando se especifica un rango de valores se proporciona
un indicio implícito del grado de incertidumbre.
Entonces se puede calcular un valor de tres puntos o uno
esperado. El valor esperado para la variable de
estimación (tamaño ) S, se calcula como un promedio
ponderado de las estimaciones optimistas (Sopt), más
probable (Sm) y pesimista (Spes).
S=(Sopt + 4Sm + Spes)/6
Cualquier técnica de estimación, no importa cuán sofisticada sea,

debe contrastarse con otra. Incluso debe prevalecer el sentido común
y la experiencia

Ejemplo de estimación basada en LDC
Considérese un paquete de software que será

entregado para una aplicación de diseño asistido
por computadora destinado a componentes
mecánicos. El Software se ejecutara en una
estación de trabajo de ingeniería y debe tener
interfaz con varios periféricos que incluyen
ratón, digitalizador, monitor de color de alta
resolución e impresión láser.

1. Determinar el Ámbito del Software
El software mecánico aceptara del Ingeniero datos
geométricos de dos y tres dimensiones. El Ingeniero
interactuará y controlará el sistema a través de una interfaz del
usuario que exhibirá características de buen diseño de interfaz
humano-maquina. Todos los datos geométricos y otra
información de soporte se conservaran en una base de datos.
Se desarrollaran módulos de análisis de diseño para producir
la salida requerida, la cual se desplegará en una diversidad de
dispositivos periféricos que incluyen ratón, digitalizador,
impresora la ser y ploter.
2. Identificación de las funciones de software:
FUNCION Sopt SM Spes
Facilidades de Interfaz del
usuario y control
Análisis geométrico
bidimensional
Análisis geométrico
tridimensional
4.600 6.900 8.600
Facilidades de presentación
gráfica de computadora
Módulos de análisis de diseño
Total
3. Aplicar la formula respectiva para hallar el valor esperado para
la variable de estimación (tamaño ) S.
S=(Sopt + 4Sm + Spes)/6
Para cada una de las funciones

4. Construir la TABLA DE ESTIMACIONES PARA METODOS LDC
FUNCION LDC
Estimado
Facilidades de Interfaz del usuario y control
Análisis geométrico bidimensional
Análisis geométrico tridimensional 6.800
Facilidades de presentación gráfica de
computadora
Módulos de análisis de diseño
LINEAS DE CÓDIGO ESTIMADOS
5.Realizar una revisión de los DATOS HISTORICOS que indiquen el
promedio del nivel de productividad para sistemas similares.
620 LDC/pm
Tarifa laboral de 7.500 Bs. Por mes incluye impuestos de Ley
Costo Total de Proyecto 55.00 Bs.
7.500/620 = 12 Bs X= (55.000 * 1)/7.500

X = 7 personas
Costo de cada línea de código
Esfuerzo estimado
6. Realizar la ESTIMACION DEL PROYECTO
Por lo que cada línea de código costo 7.500/620 = 12 Bs
EL ESFUERZO ESTIMADO ES:
X= (LDCE* 1 persona) / (LDC/pm)
X= (55.000 * 1)/620 X=(5500 personas
COSTO TOTAL DEL PROYECTO Esfuerzo estimado
X= (# personas * Monto a cancelar)
X=(5500 personas COSTO DEL PS

Considere la situación de una Empresa denominada “MUNDO FELIZ”, con
sucursales en La Paz, Cochabamba y Santa Cruz cuenta en cada sucursal con
35,50,40 empleados respectivamente. La empresa requiere los servicios de
consultaría en Software para el inicio de un proyecto que le permita contar con
un sistema integrado que permita el control de del inventario existente de los
productos que ofrece, el control de asistencia y sanciones al personal, además
como se cuentan con lectores en código de barra se desea que las ventas se
controlen usando el mismo así como su registro en inventarios, se desea llevar
u registro de toda la clientela de modo que si se tiene alguna promoción éstos
resulten primeramente beneficiados, Se desean registrar los activos fijos que
tiene la empresa en cada sucursal, también hacer un seguimiento del record de
trabajo de cada persona de modo que se las pueda categorizar para el pago de
su salario, también en cuanto a ventas se desea realizar un seguimiento de los
pedidos y compras realizados a los proveedores, así como las ventas al por
mayor bajo convenio con instituciones.
Considere la siguientes funciones:
Control de inventario (Productos Stock, activos fijos)

Control de Personal
Elaboración de planillas de sueldos
Transacciones de productos (Compras , Ventas, Promociones)
Según la experiencia obtenida se sabe que se puede realizar 1500

LDC/pm
Tarifa laboral de 1.000 $ por mes
Coste total del proyecto 10.000$
Tipo de cambio 8.07 Bs
REALIZAR EL TRABAJO EN AULA
Ejemplo de estimación basada en FD
La descomposición de la estimación basada en PF se centra
en los valores de dominio de información más que en las
funciones de software
PF = CONTEO TOTAL * [0,65+ (0,01 * ∑Fi)]
VALORES DE DOMINIO DE
INFORMACION
• Número de entradas externas (EE)
• Número de Salidas externas (SE)
• Número de consultas externas (CE)
• Número de archivos lógicos internos (ALI)
• Número de archivos de interfaz externos (AIE)
FACTORES DE COMPLEJIDAD
• Respaldo y recuperación
• Comunicación de datos.
• Procesamiento distribuido
• Desempeño crítico
• Entorno operativo existente
• Entrada de datos en Línea
• Transacción de entrada sobre pantallas múltiples
• ILF actualizado en línea
• Complejo de valores de dominio de información
• Complejo de procesamiento interno
• Código diseñado para reutilización
• Conservación/instalación en diseño
• Instalaciones múltiples
• Aplicación diseñada para cambio
1. Determinar Mediante un Modelo Casos de Uso, Modelo Diagrama
de Flujo de Datos o Análisis del Proyecto de Software
Número de entradas externas (EE)

Número de Salidas externas (SE)
Número de consultas externas (CE)
Número de archivos lógicos internos (ALI)
Número de archivos de interfaz externos (AIE)
2. Realizar el conteo y operaciones
VALOR DEL DOMINIO DE CONTE FACTOR DE PONDERACION CONTEO

O PF
INFORMACIÓN SIMPLE PROMEDIO COMPLEJO
Número de entradas externas (EE) 3 3 4 6
Número de Salidas externas (SE) 2 4 5 7
Número de consultas externas (CE) 2 3 4 6
Número de archivos lógicos internos 1 7 10 15

(ALI)
Número de archivos de interfaz 4 5 7 10
externos (AIE)
CONTEO TOTAL
Conteo * factor de ponderación

FACTORES VALOR
3. Estimar cada uno
Respaldo y recuperación 4
de los factores
Comunicación de datos. 2
ponderados de
Procesamiento distribuido 0
complejidad con la
Desempeño crítico 4
escala de 0-5. Donde
Entorno operativo existente 3
0 No importante o
Entrada de datos en Línea 4
aplicable – 5
Transacción de entrada sobre pantallas múltiples 5
absolutamente
ILF actualizado en línea 3
esencial
Complejo de valores de dominio de información 5
Complejo de procesamiento interno 5
Código diseñado para reutilización 4
Conservación/instalación en diseño 3
Instalaciones múltiples 5
Aplicación diseñada para cambio 5
FACTOR DE AJUSTE DE VALOR 52

4. Reemplazar valor en la formula
PF = CONTEO TOTAL * [0,65+ (0,01 * ∑Fi)]
PF = 50 * [0,65+ (0,01 * 52)]

PF= 58.5
5. Revisar datos históricos
6. Realizar la estimación del Proyecto de Software

2324

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2324

Încărcat de

Drepturi de autor:

Formate disponibile

UNIDAD

CONCEPTOS SOBRE GESTION DE

¿Qué es la Gestión de Proyectos?

Implica la planificación, supervisión y control

La construcción de software es una empresa compleja,

Es muy importante que los Proyectos Software sean gestionados5

Personal Producto Proceso Proyecto

Debe estar Se debe planificar

Un plan de proyecto se realiza al comienzo de cada

La gestión eficaz de un proyecto de software se centra en las 4 P`s.

El gestor que comprende un proyecto sin un plan

Este factor es tan importante que el Instituto de Ing. de Software

EL MMCGP define las siguientes áreas calve practicas para el personal de

2. Gestores del proyecto Planifican, motivan, organizan y

3. Profesionales Proporcionan las habilidades técnicas

4. Clientes Especifican la ingeniería de software

5. Usuarios finales Quienes interactúan con el software

Para los LIDERES DEL EQUIPO se debe utilizar la técnica MOI 11

Antes de planificar un proyecto, se debe establecer:

 Los objetivos y el ámbito del producto

Sin esta información es imposible definir unas estimaciones razonables

El desarrollador y el cliente deben reunirse para definir los objetivos del

 Es parte del proceso de ingeniería del sistema o del negocio

 El ámbito identifica los datos primarios, funciones y comportamientos

CONTEXTO: ¿Cómo encaja el software que se desarrollará en un sistema

DATOS CUANTITATIVOS (número de usuarios, tiempo de respuesta)

DESCOMPOCISON DEL PROBLEMA

Llamada PARTICION O ELABORACION DEL

Proporciona el marco de trabajo desde el cual se puede establecer un plan

El problema es seleccionar el MODELO DE PROCESO apropiado para

Inicio del Proyecto

Inicio del Proyecto

CONSTRUCCION Código Prueba

El Modelo de Cascada, sugiere un enfoque sistemático, secuencial

El Modelo Incremental combina elementos del modelo de cascada

Modelo incremental se enfoca en la entrega de un producto

El desarrollo incremental es útil sobre todo cuando el personal

El Modelo DRA Modelo de Desarrollo Rápido de aplicaciones, es un

Cumple con las actividades: Comunicación, Plantación el Modelado

Se utiliza cuando el cliente no identifica correctamente los requisitos

comunicación PLAN RAPIDO

Presentar un informe y una breve explicación acerca del modelo

Es la única manera de gestionar la complejidad que existe en la

Se define riesgos en el proyecto de software:

1. El personal de software no entiende las necesidades de sus clientes.

Para evitar el fracaso del proyecto, un gestor y los ingeriros de software

La gestión de un proyecto de software comienza con

Antes de que el proyecto comience, el gestor y el

La primera de estas actividades es la ESTIMACIÓN de

Como la estimación es la base de la planificación, hay

La estimación la lleva a cabo el gestor del proyecto

2.1. OBSERVACION SOBRE LA ESTIMACION

Hay cuatro factores que influyen

La complejidad del proyecto.

2.1. OBSERVACION SOBRE LA ESTIMACION

2.1.1. Complejidad del proyecto

La complejidad es relativa a la experiencia en

2.1. OBSERVACION SOBRE LA ESTIMACION

2.1.2. TAMAÑO DEL PROYECTO

En los proyectos grandes, crece la interdependencia

2.1. OBSERVACION SOBRE LA ESTIMACION

Grado en que los requisitos se han definido.

Incertidumbre mejor descomposición