Ingeniería de Software

Profesor: Luis A. Castillo F.

Ingeniero Civil en Informática.

Licenciado en Ciencias de la Ingeniería.
Técnico Programador de Computadores.
Ref. Material: Liliana Guzmán R.
 Gestión de Proceso de
Desarrollo de Software

Unidad: 2, Slide: 2
Proceso de Software
“El proceso de software es un conjunto de
actividades asociados que conducen a la
creación de un producto de software”
Cuando el proceso implica la construcción de
algún producto, solemos referirnos al proceso
como “Ciclo de Vida”.
El proceso de desarrollo de software suele
denominarse “Ciclo de vida del software”
 Introducción
• Abarca todas las actividades que contribuyan a
asegurar la entrega del software en el tiempo
fijado, dentro de la calendarización establecida
y de acuerdo a los requerimientos

• Es una necesidad
– El desarrollo de software esta sujeto a restricciones
de tiempo y presupuesto
 Introducción
• Muchas de estas actividades de la gestión de
proyectos de ingeniería son aplicables a la
ISW

• Diferencias
– Producto intangible, maleable
– Proceso de desarrollo de software no esta
estandarizado
– Unicidad de los proyectos de software
 Introducción
• Actividades
– Planificar
– Organizar
– Gestionar el personal
– Liderar
– Controlar
 Introducción
• Planificar
– Establecer metas y objetivos
– Desarrollar políticas
– Prever situaciones futuras
– Gestionar los riesgos
– Determinar cursos de acción
– Gestionar contratistas
– Preparar el presupuesto
– Desarrollar el plan de proyectos
 Introducción
• Organizar
– Identificar y agrupar tareas, actividades y funciones
– Seleccionar la estructuras del proyecto
– Describir las organización el proyecto (interna y
externa)
– Establecer responsabilidades, autoridad e interfaces
– Definir responsabilidades
– Definir la evaluación del personal
 Introducción
• Gestionar el personal
– Seleccionar el personal para cada rol
– Asimilar personal nuevo
– Educar y entrenar el personal
– Mejorar el conocimiento, las actitudes y
habilidades del personal
– Evaluar al personal
– Compensar al personal
– Determinar las asignaciones
 Introducción
• Liderar
– Proveer visión, dirección, y liderazgo
– Supervisar al personal
– Motivar al personal
– Coordinar actividades
– Delegar autoridad
– Facilitar la comunicación
– Resolver conflictos
– Gestionar cambios
– Documentar las decisiones
 Introducción
• Controlar
– Desarrollar estándares de desempeño
– Establecer sistemas de seguimiento
– Medir y analizar resultados
– Iniciar acciones correctivas
– Recompensar y disciplinar
Planificación
 Planificación

• Probablemente, la actividad de gestión de

mayor consumo de tiempo.
• Actividad continua desde la concepción hasta
liberación del producto. Demanda su revisión
continua en virtud de la información
disponible.
• Clave para la buena gestión y el éxito del
desarrollo.
 Planificación
• Actividad - Amplia categoría o grupo de acciones necesarias
para completar un proceso.
• Milestones (hitos) - puntos de termino de una actividad del
proceso.
• Predecesora – conjunto de eventos requeridos para dar inicio
a una actividad.
• Duración – período de tiempo requerido para terminar una
actividad.
• Productos de trabajo - cualquier artefacto creado como parte
de la definición, desarrollo, evolución o uso del proceso de
software.
• Deliverables (entregables) - cualquier producto de trabajo
que debe ser entregado al cliente y/o usuario final.
 Planificación
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled
loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise then
)
Initiate technical review and possible revision
end if
end loop
 Restricciones

• Tiempo - Esfuerzo - Productividad

• Presupuesto - Costos
Especificar:
• Recursos
Habilidades

Conocimientos

Disponibilidad

Duración de las tareas

Personas

Fecha de inicio

Descripción
Herramientas

Disponibilidad
Hardware/Software

Duraciónde uso

Fecha de distribución
 Staff
• No siempre es posible contar con el personal
ideal para un proyecto.
• Se debe definir conjugando las necesidades del
proyecto y las restricciones existentes:
– Límites de presupuesto
– Staff con experiencia adecuada no se encuentra
disponible
– Política organizacional: utilizar los recursos
existentes
 Plan del proyecto
• Su estructura varía • Actividades
según el tipo de • Introducción
proyecto y la • Organización
• Análisis de riesgos
organización
• Requerimientos de HW y
SW
• Descomposición de tareas
• Debe establecer
• Calendarización
– Recursos disponibles • Mecanismos de monitoreo
– WBS
– Calendarización
 P la n d e
E v a lu a c ió n C a lid a d
del
P ro b le m a

A trib u to s d e
M é to d o s E n tre g a b le s C a lid a d

Plan de proyecto
D e fin ic ió n
E v a lu a c ió n de V&V
P ro b le m a
d e l R ie s g o a c tiv id a d e s
& c he que os

M o d e lo d e l
P ro c e s o

P la n Tam año del

T é c n ic o P ro b le m a

P la n d e
R ecurso s E s tim a c ió n
d e E sfu e rz o

W BS
m ás
E sfu e rz o

E s c a la s d e P e r fil d e l
C o n tin g e n c ia C o s to s
tie m p o e q u ip o

P la n e s
Calendarización
 Calendarización
• Descomponer el proyecto en tareas y estimar el tiempo y los
recursos requeridos para completarlas
• Organizar las tareas para obtener un uso óptimo de los
recursos
• Minimizar la dependencia entre tareas para disminuir la
probabilidad de atrasos
• Depende fuertemente de la intuición y experiencia.

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities toactivities charts

Software Activity charts

requirements and bar charts
 Calendarización
• Consideraciones
– Estimar la complejidad del problema y los costos de
desarrollo de la solución
– La productividad no es proporcional al número de
personas que trabaja en una tarea
– Agregar personas a un proyecto atrasado no soluciona
los problemas
– Lo inesperado siempre ocurre. Siempre debe
considerarse las contingencias en la planificación
 Calendarización
“A good rule of thumb is to estimate as if nothing
go wrong, then increase your estimate to cover
anticipated problems.....I always add 30% to my
original estimate for anticipated problems then
another 20% to cover other things I hadn’t
thought of.”

I. Sommerville
 Representación gráfica
• Información
– Descomposición del proyecto en tareas: organización,
dependencias y ruta crítica
– Tiempos
– Distribución de esfuerzo
– Relación gente -trabajo

• Tipos de representación
– WBS
– Red de Tareas - reflejan la dependencia entre las tareas y la
ruta crítica
– Diagramas de barras - muestran la calendarización en el
transcurso del tiempo calendario
 Work Breakdown Structure
Esfuerzo Duración Plazos Recursos Responsable Producto
Requisitos Estado....
1000 Etapa o fase 1
2000 Etapa o fase 2
........
2n00 Subfase 2.n
2n10 Actividad 2.n.1
......
2nm0 Actividad 2.n.m
2nm1 Tarea 2.n.m.1
2nm2 Tarea 2.n.m2
.......
2nmt Tarea 2.n.m.t
..........¡
Red de tareas (Activity Network)
14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 10 days 11/8/99 5/9/99

10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99
 Activity timeline
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T1 1
M8
T12
Finish
 Staff Allocation
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5
Carta Gantt
Gestión de Riesgos
 Gestión de Riesgos
• Propósito
– Identificar riesgos
• Desarrollar planes para minimizar su impacto sobre el
proyecto
• Riesgo
– Posibilidad de pérdida o daño
– Tipos
• Del proyecto - afectan la calendarización y los recursos
• Del producto - afectan la calidad o el desempeño del software
desarrollado
• Del negocio - afectan la organización desarrolladora del
software
 Gestión de riesgos
• Riesgo
– Caracterización
• Impacto – pérdida asociada a un evento
• Probabilidad – probabilidad de ocurrencia de un evento
– Control o Mitigación del riesgo
• Grado en que podemos cambiar el resultado de un evento
• Exposición del riesgo = (probabilidad del riesgo) * (impacto del
riesgo)
 Gestión de riesgos
• Estrategias para minimizar un riesgo
– Evitar el riego – cambiar los requerimientos
– Transferir el riesgo – a otro siste,a
– Asumir el riesgo – aceptarlo y controlarlo
 Gestión de riesgos
• 10 riesgos más serios (Carper Jones)
– Métricas inadecuadas.
– Medición inadecuada.
– Presión excesiva de tiempo.
– Malas prácticas de gestión.
– Estimación imprecisa de costos.
– Síndrome del silver bullet.
– Requerimientos.
– Baja calidad.
– Baja productividad.
– Cancelación de proyectos.
 Gestión de riesgos: Proceso

Risk Risk analysis Risk planning Risk

identification monitoring

List of potential Risk avoidance Risk

Prioritised risk and contingency
risks list assessment
plans
 Identificación de riesgos

• Identificación de riesgos
– Lista de riesgos específicos que pudiesen
comprometer el éxito del proyecto
– Categorías
• Tecnológicos
• Personas
• Organizacional
• Requerimientos
• Estimación
 Identificación de riesgos
– Tecnológicos
• La BD no pude procesar la cantidad de transacciones esperada por seg.
• Los componentes reusados contienen defectos que limitan su funcionalidad
– Personas
• Personal clave para el proyecto se encuentra enfermo durante etapas críticas
• La capacitación requerida no está disponible
– Organizacional
• Reestructuración. Cambio en los responsables del proyecto.
• Problemas financieros fuerzan una disminución del presupuesto.
– Requerimientos
• Cambios con alto impacto sobre el diseño.
• El cliente no comprende el impacto de los cambios solicitados.
– Estimación
• Subestimación de la fecha de entrega/tamaño/ esfuerzo y tiempo de rework.
 Análisis de riesgos
• Evaluación de la magnitud y probabilidad de perdida
– Impacto
• Pérdida asociada a un evento
• Catastrófico, Serio, Tolerable, Insignificante
– Probabilidad
• Ocurrencia
• Muy baja, Baja, Moderada, Alta, Muy alta (%%%%%)

• Los riesgos deben ser priorizados en base al impacto

y la probabilidad
 Planificación

• Planificación
– Preparación y coordinación de estrategias para
gestionar cada riesgo
– Estrategias
• Evitar – disminuir la probabilidad de ocurrencia del
riesgo
• Minimizar – el impacto del evento
• Contingencia – en caso de materializarse, actividades
para lidear con el riesgo
 Monitoreo

• Monitoreo
– Seguimiento del avance de la resolución
(eliminación o solución) de los riesgos y desarrollo
de acciones correctivas
– Re-evaluación de los riesgos
 Monitoreo
• Indicadores potenciales
Risk type Potential indicators
Technology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member, job
availability
Organisational organisational gossip, lack of action by senior management

Tools reluctance by team members to use tools, complaints about CASE

tools, demands for higher-powered workstations

Requirements many requirements change requests, customer complaints

Estimation failure to meet agreed schedule, failure to clear reported defects

 Planning Decision FlowChart
Statements of Risk

Review
Risks
Context
Impact
Probability
Timeframe

Flujo de Decisión
Is it my
Classification Is it
task to deal no no
Rank internal to my
with this
organization?
risk?

yes yes
Responsability:
Keep Delegate Transfer
Is it my risk?

Riesgos
Do I
know no
enough Research
about this Research
risk? Plan
Approach: Can I
do anything?
yes

Can I live Can I act Tracking

no no
with this on this requirements
risk? risk?*

Acceptance
rationale yes yes

Accept Delegate
Mitigate
Keep Watch

Mitigation Plan
Scope and Actions:
What Should I do? Mitigation Plan
yes no Task Plan
Is an action
Risk Action Item List item list WBS
Responsability
enough?
Goals
* Or "Do I Need to act on this risk?" Item 1 - do xxxx Tasks Schedule
Item 3 - do yyyy _______
Item 12 - do zzz ______
ID ABC 23 Risk Information Sheet Identified: 3 / 2 / 95
Priority 6 Statement

Hoja de información de
Probability High W ith our lack of experience in X W indows software, we may not be able to
Impact High complete the GUI code on time and it may not be the quality of code we need.
Timeframe Near Origin Class Personnel Assigned
G. Smith Experience To: S. Jones
Context
The graphical user interface is an important part of the system and we do not have anyone
trained in the X W indow system. W e all have been studying it, but is complex and only
one person in the group has any graphics/user interface experience and that was with a
completely different type of system and interface requirements. There are other personnel
within the company who have relevant experience and training, but they may not be
available in time to support this project.

riesgos
Mitigation Strategy
1. Update coding estimates and schedules to reflect the need for increased training and for
hiring an expert in X W indows (changes due 5/1/95)
2. Coordinate with customer and get approval for changing schedule (approve by 6/1/95)
3. Identify an available expert from other projects in this division (hired by 6/15/95)
4. Bring in outside training source for current programmers (training complete by 7/30/95)

Contingency Plan and Trigger

Plan: Subcontract GUI development to LMN Corp. and accept the increase in our cost,
$25,000. LMN has a level of effort contract with ABC Headquarters and can support with
1 week notice
Trigger: If internal expert is not onboard and training not completed by 7/30/95
Status Status Date
GUI code delivered on time, required quality 1/30/96
GUI code has been delivered for testing on schedule 11/13/95
Code 50% complete and 1 week ahead of schedule 9/15/95
Personnel completed 2 week training; will monitor progress 7/15/95
and quality of work
Brown form project XYZ wil be available on 6/5/95 to 1/6/95
provide quality assurance, mentoring, and critical path programs
Customer approved revised schedule milestones 3/5/95
Revised estimates and schedule complete; indicates a worst-case 4/23/95
3 week slip if we get the additional expert
Approval Closing Date Closing Rationale
J.Q.Jones, ABC Project Manager 2 / 15 / 96 Code delivered on time, Acceptance
test excellent. Risk is gone
Gestión del recurso humano
 Gestión del recurso humano
• Importancia
– Activo de mayor importancia
– La gestión, básicamente, se orienta a las personas
– La ISW es una actividad esencialmente cognitiva

• Actividades de gestión
– Resolución de problemas
– Motivación
– Planificación
– Estimación
– Control
– Organización
 Resolución de problemas
La habilidad de desarrollar software corresponde
a la habilidad de integrar la información del
problema con conocimientos
computacionales para crear un nuevo
conocimiento
 Resolución de problemas
• Etapas
– Integración de diferentes tipos de conocimientos
– Desarrollo de un modelo semántico de la solución y
validación con respecto al problema
– Representación del modelo en una notación apropiada
(lenguaje de programación)

• Consecuencias
– Al seleccionar personal para un proyecto, influye tanto la
habilidad de resolver problemas como el conocimiento
sobre el dominio específicos (lenguajes de programación)
 Motivación
• Uno de los roles más importantes de un jefe
de proyectos es motivar al personal de un
proyecto

• Es una tarea compleja que involucra

diferentes aspectos
– Necesidades básicas
– Necesidades personales
– Necesidades sociales
 Motivación
• Las necesidades
sociales, de autoestima Self-
y de autorrealización realization needs

son más relevantes Esteem needs

desde la perspectiva de
Social needs
la gestión del recurso
humano. Safety needs

Physiological needs
 Motivación
• La necesidad de jerarquías es en la mayoría de los casos una
simplificación

• Debe considerar los diferentes tipos de personalidades

– Orientadas al trabajo
• La motivación de hacer el trabajo en si misma
– Orientadas a si mismas
• El trabajo es un medio para alcanzar un objetivo personal
– Orientadas a la interacción
• La motivación principal es la presencia e interacción con terceros. Las
personas van a trabajar porque les gusta ir al trabajo.
 Motivación
• Equilibrio
– La motivación individual esta compuesta por elementos de cada
tipo personalidad

– El balance puede variara según las circunstancias y eventos

externos

– La motivación de los individuos no depende tan sólo de factores

personales, también forman parte de un grupo y una cultura

– Las personas van a trabajar motivadas por las personas para con
las cuales trabajan y por el trabajo que realizan
 Trabajo en equipo
• La ingeniería por lo
general es una
20%
actividad de equipo Non-productive
activities

50%
Interaction with
• La interacción del 30%
other people
Working alone
grupo de trabajo es
determinante de en su
desempeño y
productividad
 Trabajo en equipo
• Factores
1. Composición - balance entre objetivos, experiencia y
personalidades?
2. Cohesión - se visualizan como un equipo?
3. Comunicación - es efectiva?
4. Organización - todos se sienten valorados y
satisfechos con su rol?
 Trabajo en equipo
1. Composición
– Grupos cuyos miembros tienen el mismo tipo de personalidad:
• Orientados a las tareas – individualismos
• Orientados a si mismos – todos quieren ser el jefe
• Orientados a la interacción – escaso trabajo

– Solución
• Mantener un equilibrio – Cada quien cumple y tiene un rol importante

– Dificultad
• La mayoría de los ingenieros son orientados a las tareas
• Requiere que todos los miembros estén involucrados en las decisiones
que afectan al grupo
 Trabajo en equipo
1. Composición
– Liderazgo
• Es necesario dentro de todo grupo de trabajo
• Idealmente debe recaer en el jefe de proyecto
• Depende del respeto no de un estatus
• Es necesario tanto a nivel técnico y como
administrativo
• No debe ser impuestos
• Debe estar soportado por una carrera basada en
competencias técnicas
 Trabajo en equipo
2. Cohesión
 En un grupo cohesivo, los miembros consideran al grupo más
importante que a cualquier individuo (equipo)

 Ventajas
 Es más robusto ante problemas y situaciones imprevistas
 Es posible establecer estándares de calidad por observación y consenso
 Los miembros trabajan cercanamente. Cada miembro aprende de los otros
de manera tal que las inhibiciones por ignorancia son disminuidas
 Cada miembro conoce el trabajo de los otros, lo que otorga mayor
continuidad
 Se disminuye el ego y autosuficiencia de los programadores.Todos los
miembros sienten que comparten la responsabilidad sobre el desarrollo
software
 Trabajo en equipo
2. Cohesión
 Es influenciada por muchos factores como la cultura
organizacional y las personalidades al interior del grupo

 ¿Cómo fomentar la cohesión?

 Eventos sociales
 Desarrollar la identidad y territorialidad del grupo
 Actividades explícitas
 Asegurando que los miembros del equipo sean tratados
como personas responsables y confiables: entregando
acceso libre a la información
 Trabajo en equipo
2. Cohesión
 Problemas: Lealtad
 Resistencia irracional a un cambio en el liderazgo
 Pensamiento de grupo – preservar un grupo por sobre
los criterios técnicos y objetivos organizacionales
 Trabajo en equipo
3. Comunicación
– Es esencial para el trabajo en equipo.
– En general, se basa en el intercambio de
información sobre el estado del trabajo, las
decisiones y los cambios.
– Una buena comunicación fortalece la cohesión en
un grupo y promueve de mayor comprensión
sobre la motivación, fortalezas y debilidades del
mismo
 Trabajo en equipo
3. Comunicación
– Tamaño
• Links de comunicación= n(n – 1)
– Estructura
• Informal vs. Informal.
• Los altos “cargos” tienden a dominar las conversaciones
• La comunicación mediante un coordinador central tiende a
ser inefectivo
– Composición
• Personalidad
• Sexo
– Ambiente físico
• Actúa como agente facilitador o inhibidor
 Organización
• Deben privilegiarse grupos pequeños (< 8)
organizados en una forma informal y
democrática
• Particionar proyectos complejos
 Organización
• Organización democrática
– El grupo actúa como un todo resolviendo las
decisiones que afectan el sistema por consenso
– El líder sirve básicamente como medio de
comunicación externa
– El trabajo analizado por el grupo y asignado según
habilidades y experiencia
– Si éxito depende de contar con miembros
competentes y experimentados
 Selección del personal
• Perfil ideal versus real

• Bases
– Curriculum
– Habilidades
– Experiencia
– Disponibilidad
– Entrevistas
– Recomendaciones
– Test
Factor Explanation
Application domain For a project to develop a successful system, the
experience developers must understand the application domain.

Factores de selección
Platform experience May be significant if low-level programming is
involved. Otherwise, not usually a critical attribute.
Programming language Normally only significant for shortduration projects
experience where there is insufficient time to learn a new
language.

del personal
Educational background May provide an indicator of the basic fundamentals
which the candidate should know and oftheir ability
to learn. This factor becomes increasinglyirrelevant
as engineers gain experience across a range of
projects.
Communication ability Very important because of the need for project staff to
communicate orally and in writing with other
engineers, managers and customers.
Adaptability Adaptability may be judged by looking the at different
types of experience which candidates have had. This is
an important attribute as it indicates an ability to
learn.
Attitude Project staff should have a positive attitude to their
work andshould be willing to learn new skills. This
is an important attribute but often very difficult to
assess.
Personality Again, an important attribute but difficult to assess.
Candidates mustbe reasonably compatible with other
team members. No particular type of personality is
more or less suited to software engineering.
 Ambiente de trabajo
• Tiene un alto impacto en la productividad y la
satisfacción
– Confort, privacidad, infraestructura
– Salud y seguridad: luminosidad, contaminación acústica,
etc..

• Debe contemplar espacios privados y conjuntos de

forma tal de garantizar el desarrollo sin interrupcioes
de las tareas y facilitar la comunicación formal e
informal.
Gestión de proyectos de software
Seguimiento y control
• Se basa en la los hitos establecidos
• Involucra
– Avance
– Calidad
– Cambio
• Herramientas
– Carta Gantt
– RMS 5
– Panel de Control
 Identificar y corregir
Acuerdo en las defectos y problemas
Gestión del riesgo
interfaces potenciales
Monitoreo de defectos tempranamente
Inspecciones
contra objetivos de formales
calidad
Panel de Calendarización y Planificar y
control gestión basada en seguir/monitorear
métricas
Controles on/off
de calidad en niveles Minimizar re-trabajo
Gestión de causado por cambio
de detalle
configuración incontrolado
Visibilidad del avance
versus planes Usar efectivamente
los recursos de
Gestión consciente de personal
las personas
Gestión de proyectos de software
Mediciones - Propósito
Comprender Hacer proceso y producto visible
Evaluar estado actual, comparar con
Qué sucede durante el baselines
desarrollo y la mantención

Controlar Mejorar
Proyecto Predecir a partir de Procesos y Cambios
baselines y objetivos, productos basados en
hacer cambios mediciones y
predicciones
Gestión de proyectos de software
Mediciones
• Implicancias para la gestión
– Determinar costos, productividad, calidad, satisfacción
del usuario, mejoramientos, etc.
• ¿Qué medir y para qué?
– Proceso - duración, costo, efectividad o eficiencia
– Producto - tamaño, calidad
– Recurso - magnitud, costo, calidad.
• Mediciones directas e indirectas.
Gestión de proyectos de software
Mediciones
• Categorías de métricas
– Tamaño
• LOC, tokens, PF
– Complejidad de datos
• Cantidad y uso de Variables
– Complejidad de algoritmos
• Complejidad de la estructura lógica
– human-oriented
Gestión de proyectos de software
Mediciones
• Tamaño
– LOC, Esfuerzo, Costos
Proyecto Esfuerzo $ KLDC Págs. Doc. Errores Personas
aaa-01 24 168 12,1 365 29 3
ccc-04 62 440 27,2 1224 86 5
fff-03 43 314 20,2 1050 64 6
. . . . . . .
. . . . . . .
. . . . . . .

Métricas orientadas al tamaño

 Gestión de proyectos de software
Mediciones
• Tamaño - Puntos de Función
F ac tor
de
P es o
P a rá m e tro de m e d ida C ue nta S im ple M e dio C o m p lejo
Nú m e ro d e e ntrad a s x 3 4 6 =
d e us ua rio
Núm e ro d e s alid as x 4 5 7 =
d e us ua rio
Nú m e ro d e p e tic ione s x 3 4 6 =
a l us ua rio
Nú m e ro d e a rc hivos x 7 10 15 =

Nú m e ro de inte rfa c es x 5 7 10 =
e xte rnos

C u e n ta T o ta l

C á lc ulo de m é tric a s d e punto s d e func ió n

Gestión de proyectos de software
Mediciones
• Productividad (factores principales)
– Diferencias personales
– Complejidad del problema
– Proceso de desarrollo
– Producto de software
– Disponibilidad de recursos
Gestión de proyectos de software
Mediciones
• Calidad
– Complejidad
– Modularidad
– Facilidad de mantención
– Correctitud
– Integridad
– Facilidad de uso
Gestión de proyectos de software
Estimación
• ¿Arte o ciencia?
• Factores de incerteza
– Complejidad, Tamaño, Estructura
• Bases
– Modelos, Datos históricos, Sentido común
• Preguntas
– Esfuerzo requerido para completar una actividad?
– Tiempo calendario requerido para completar un
actividad?
– Costo total de un actividad?
Gestión de proyectos de software
Estimación
• Métodos
– Algorithmic cost modelling - desarrollo de un
modelo derivado de datos históricos que estima
alguna métrica de sw (usualmente de tamaño) para
predecir el esfuerzo requerido.
– Expert judgement - basado en la experiencia de
expertos calificados.
– Estimation by analogy- basado en la analogía con
proyectso similares.
– Parkison’s Law - se utilizan todos lo recursos
disponibles.
– Pricing to win - el presupuesto del cliente.
Gestión de proyectos de software
Estimación
• Métodos
– Todos tienen fortalezas y debilidades
– Es recomendable basarse en más de un método
– La experiencia siempre es relevante
– No debe perderse de vista la diferencia entre
proyectos
• Modelos
– COCOMO 81
– COCOMO 2
– Putman
Gestión de proyectos de software
Estimación
4x

2x Incerteza

x Code
Feasibility Requirements Design Delivery

0.5x

0.25x
Gestión de proyectos de software
Análisis Post- mortem
• Pasos
– diseñar y distribuir un survey del proyecto
– recolectar información objetiva del proceso
– conducir una reunión complementaria
– conducir un día de la historia del proyecto
– difundir los resultados
Preguntas ?

Dudas ?

Comentarios