Академический Документы
Профессиональный Документы
Культура Документы
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
Conocimientos
Disponibilidad
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 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.
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
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
• 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 (%%%%%)
• 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
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
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)
• 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
Physiological needs
Motivación
• La necesidad de jerarquías es en la mayoría de los casos una
simplificación
– 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
• 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..
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
. . . . . . .
. . . . . . .
. . . . . . .
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
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