Está en la página 1de 32

INGENIERA DE SOFTWARE UN

ENFOQUE PRACTICO: ROGER


PRESSMAN.
PAOLA A. LENIS FRANCO
ISABELLA QUINTERO LEYVA
CRISTIAN AVILA
GESTIN DE PROYECTOS DE
SOFTWARE

ADMINISTRACIN DE PROYECTOS
DE SOFTWARE
CONTENIDO
1. Introduccin Mtricas orientadas a objeto y caso de uso

2. El personal 8. Mtricas para calidad de software


3. El producto Medicin de la calidad

4. El proceso Eficiencia en la remocin del defecto

Fusin de producto y proceso 9. Integracin de mtricas dentro del proceso de


software
Descomposicin del proceso
Establecimiento de una lnea de referencia
5. El proyecto
Recoleccin, clculo y evaluacin de mtricas
6. El principio W5HH
10. Establecimiento de un programa de
7. Medicin del software mtricas del software
Mtricas orientadas a tamao y funcin

Reconciliacin de mtricas LOC y PF


INTRODUCCIN
La gestin de proyectos implica la planificacin, supervisin y control del
personal, del proceso y de los eventos que ocurren mientras evoluciona el
software desde la fase preliminar a la implementacin operacional. (Pressman)
2. EL PERSONAL
Los participantes
1. Gerentes ejecutivos,
2. Gerentes de proyecto (tcnicos)
3. Profesionales.
4. Clientes
5. Usuarios finales
Lideres de equipo
El equipo de software
paradigma cerrado
paradigma aleatorio
paradigma abierto
paradigma sncrono
Equipo agiles
Conflictos de coordinacin y comunicacin
Lideres de equipo
Liderazgo tcnico sugiere un modelo MOI
3. EL PRODUCTO
mbito del software
Contexto. Cmo encaja en un sistema, producto o contexto empresarial ms grande
el software que se va a construir y qu restricciones se imponen como resultado del
contexto?
Objetivos de informacin. Qu objetos de datos visibles para el cliente se producen
como salida del software? Qu objetos de datos se requieren como entrada?
Funcin y desempeo. Qu funcin realiza el software para transformar los datos de
entrada en salida? Existe alguna caracterstica de desempeo especial que deba
abordarse?

Descomposicin del problema


4. EL PROCESO

Fusin de producto y proceso


Descomposicin del proceso

Un proyecto simple y relativamente pequeo puede requerir las


siguientes tareas para la actividad de comunicacin:

1. Desarrollar lista de clarificacin de conflictos.


2. Reunirse con los participantes para abordar la clarificacin de
conflictos.
3. Desarrollar en conjunto un enunciado del mbito.
4. Revisar el enunciado del mbito con todos los interesados.
5. Modificar el enunciado del mbito segn se requiera.
Para un proyecto ms grande
1. Revisar la solicitud del cliente.
2. Planificar y calendarizar una reunin formal facilitada con todos los participantes.
3. Realizar investigacin para especificar la solucin propuesta y los enfoques existentes.
4. Preparar un documento de trabajo y una agenda para la reunin formal.
5. Realizar la reunin.
6. Desarrollar conjuntamente miniespecificaciones que reflejen las caractersticas de datos,
funcionales y de comportamiento del software. De manera alternativa, desarrollar
casos de uso que describan el software desde el punto de vista del usuario.
7. Revisar cada miniespecificacin o usar casos de uso para ver su exactitud, consistencia
y falta de ambigedad.
8. Ensamblar las miniespecificaciones en un documento de mbito.
9. Revisar el documento de mbito o coleccin de casos de uso con todos los interesados.
10. Modificar el documento de mbito o casos de uso segn se requiera.
5. EL PROYECTO
1. El personal del software no entiende las necesidades del cliente.
2. El mbito del producto est pobremente definido.
3. Los cambios se gestionan pobremente.
4. Cambia la tecnologa elegida.
5. Las necesidades empresariales cambian [o estn mal definidas].
6. Las fechas lmite son irreales.
7. Los usuarios son resistentes.
8. Prdida de patrocinio [o nunca obtenido adecuadamente].
9. El equipo del proyecto carece de personal con habilidades
adecuadas.
10. Los gerentes [y profesionales] evitan mejores prcticas y
lecciones aprendidas.
5. EL PROYECTO

1. Comenzar con el pie derecho.


2. Mantener la cantidad de movimiento.
3. Siga la pista al progreso.
4. Tome decisiones inteligentes.
5. Realice un anlisis postmortem.
Ejemplo de descomposicin de un proyecto de software
6. EL PRINCIPIO W5HH

Barry Boehm [Boe96] afirma: necesita un principio de organizacin


que reduzca la escala a fin de proporcionar planes [de proyecto]
simples para proyectos simples. l lo llama principio W5HH:
Por qu (why) se desarrollar el sistema?
Cundo (when) se har?
Quin (who) es responsable de cada funcin?
Dnde (where) se ubicarn en la organizacin?
Cmo (how) se har el trabajo, tcnica y organizativamente?
Cunto (how much) se necesita de cada recurso?
.
MTRICAS DE PROYECTO

Qu es?
Quin lo hace?
Por qu es importante?
Cul es el producto final?
Por que es importante la medicin?
Mtricas proceso de software

Que son las mtricas de proceso?


incluyen medidas de los errores descubiertos antes de liberar el software, defectos entregados
a y reportados por usuarios finales, productos operativos entre-gados (productividad), esfuerzo
humano empleado, tiempo calendario consumido, conformidad con la agenda
Existen del tipo privado y publico
Tener cuidado en el uso de mtricas de software
Mtricas de proyecto
para que se usan?
La intencin de las mtricas de proyecto es doble
aplicacin de las mtricas de proyecto.

Las mtricas de proyecto permiten al gerente de un proyecto de software:


1) valorar el estado de un proyecto en marcha,
2) rastrear riesgos potenciales,
3) descubrir reas problema antes de que se vuelvan crticas,
4) ajustar el flujo de trabajo o las tareas y
5) evaluar la habilidad del equipo del proyecto para controlar la calidad
de los productos operativos del software.
MEDICIN DEL SOFTWARE

Medidas indirectas y directas


Las medidas indirectas del producto incluyen funcionalidad, calidad,
complejidad, eficiencia, confiabilidad, capacidad de mantenimiento
El dominio de la mtrica del software se dividi en mtricas de proceso,
proyecto y producto
Mtricas orientadas a tamao (loc)
Componentes funcionales bsicos
Interaccin Funcin de transaccin
Entrada externa (EI -> External input)
(Pantallas donde el usuario ingresa datos)
Salida externa (EO -> External output)
(Informes, grficos, Listados de datos)
Consulta externa (EQ -> External query)
(Recuperar y mostrar datos al usuario (Buscar))
Registro de Equipos de futbol (EI 4 PF)
Registros de partidos (EI 4 PF)
Buscar partido por fecha (EQ 4 PF)
Actualizacin de datos del equipo (EI 4 PF)
Eliminar equipos (EI 4 PF)
Listado de equipos (EO 5 PF)
1 reporte de los equipos registrados por rango de fechas (EO 5 PF)
1 reporte de partidos (EO 5 PF)
4 Tablas en BD (ILF 40 PF)
Puntos de funcin sin ajustar (PFSA): 75
Tipo /
Baja Media Alta TOTAL
Complejidad
(EI) Entrada
3 PF 4 x 4 PF 6 PF 16
externa
(EO) Salida
4 PF 3 x 5 PF 7 PF 15
externa
(EQ) Consulta
3 PF 1 x 4 PF 6 PF 4
externa
(ILF) Archivo
7 PF 4 x 10 PF 15 PF 40
lgico interno
(EIF) Archivo
de interfaz 5 PF 0 x 7 PF 10 PF 0
externo
PFSA 75
PFA = PFSA*[0.65+(0.01*factor de ajuste)]
PFA = 73.8 74

H/H = PFA * Horas PF promedio


H/H = 74 * 8
H/H = 592 Horas hombre

Ejemplo:
5 horas diarias de trabajo
1 mes = 20 das

592/ 5 = 118,4 das de trabajo


118,4 / 20 = 5,92 meses para desarrollar el software de lunes a
viernes 5 horas diarias con 1 trabajador (ESTIMACIN de duracin
del proyecto)
MTRICAS PARA CALIDAD DE SOFTWARE
Exactitud.
Capacidad de mantenimiento.
Integridad.

Amenaza=0.25 seguridad 0.99 integridad mui alta


Amenaza = 0.5 seguridad 0.25 integridad baja
EFICIENCIA EN LA REMOCIN DEL DEFECTO

una mtrica que proporciona un indicio de la capacidad de filtrado de las actividades de control
de calidad
Estimacin

Qu es? dinero, esfuerzo, recursos y tiempo


Quin lo hace?
Por qu es importante?
Cules son los pasos?
Cules son los pasos?
Cul es el producto final?
La complejidad del proyecto (relativo)
El tamao del proyecto
La disponibilidad de informacin histrica
Incertidumbre (requisitos)
despus del establecimiento del mbito se mide si es factible
Finanzas:
Tiempo
Recursos:
SEGUNDA TAREA EN LA ESTIMACIN: RECURSOS

Cada elemento de hardware debe especificarse como parte de la planificacin.

Recursos humanos
Recursos de software reutilizables
Recursos ambientales
ESTIMACIN NO ES UNA CIENCIA EXACTA

Retrase la estimacin Base las estimaciones en proyectos similares que ya


estn completos.
Use tcnicas de descomposicin relativamente simples para generar
estimaciones de costo y esfuerzo de proyecto
ESTABLECIMIENTO DE UN PROGRAMA DE
MTRICAS DEL SOFTWARE
1. Identificar las metas empresariales.
2. Identificar lo que se quiere conocer o aprender.
3. Identificar las submetas.
4. Identificar las entidades y atributos relacionados con las submetas.
5. Formalizar las metas de medicin.
6. Identificar preguntas cuantificables y los indicadores relacionados que
se usarn para
ayudar a lograr las metas de medicin.
7. Identificar los elementos de datos que se recopilarn para construir los
indicadores que
ayuden a responder las preguntas.
8. Definir las medidas que se van a usar y hacer operativas estas
METAS
1. Mejorar la satisfaccin de los clientes con los productos.
2. Hacer los productos ms fciles de usar.
3. Reducir el tiempo que tarda en salir un nuevo producto al mercado.
4. Facilitar el apoyo a los productos.
5. Mejorar la rentabilidad global.
Bibliografa
Ingeniera de software un enfoque practico 7 edicin. Roger pressman

También podría gustarte