Material Apoyo Ingenieria del Software USAL Argentina
-
Upload
susana-daldin -
Category
Technology
-
view
8.000 -
download
0
Transcript of Material Apoyo Ingenieria del Software USAL Argentina
Lic. Susana Daldin 1
Ingeniería del Software
Lic. Susana Daldin 2
Nuevo orden (Sistemas basados en computadoras)
No hay nada más difícil de llevar a
cabo, más peligroso de realizar o de
éxito más incierto que tomar el
liderazgo en la introducción de un
nuevo orden de cosas.
Maquiavello
Lic. Susana Daldin 3
Concepto La ingeniería del software ocurre como
consecuencia de un proceso denominado ingeniería de sistemas de computadora.
No solo se concentra en el software, sino que se concentra en una variedad de elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información.
Lic. Susana Daldin 4
Gestión de Proyectos –tres “pes”-
Lic. Susana Daldin 5
El Espectro de la gestión El gestor que se olvida de que el trabajo de
ingeniería del SW es un esfuerzo humano intenso, nunca tendrá éxito en la gestión de proyectos.
Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado.
Finalmente, el administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.
Lic. Susana Daldin 6
Conceptos sobre gestión de proyectosLa gestión eficaz de un proyecto de software se centra en las Tres “PES”:
Personal.
Problema.
Proceso.
Lic. Susana Daldin 7
PersonalModelo de madurez de la capacidad de gestión
depersona.
Aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software.
Lic. Susana Daldin 8
PersonalEl MMCGP (Modelo de Madurez de la capacidad de gestión de personal) define las siguientes áreas prácticas clave para el personal que desarrolla software:
Reclutamiento.Selección.Gestión de rendimiento.Entrenamiento.Retribución.Desarrollo cultural.Espíritu de equipo.
Lic. Susana Daldin 9
Personal
Las organizaciones que alcanzan una
gran madurez en el área de gestión de
personal tienen una mayor probabilidad
de implementar unas eficaces prácticas
de ingeniería del software.
Lic. Susana Daldin 10
PersonalLos participantes
Gestores superiores, que definen los aspectos de negocio que a menudo tienen una significativa influencia en el proyecto.Gestores (técnicos) del proyecto, que deben planificar, modificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.Clientes, que especifican los requisitos para la ingeniería del SW.Usuarios finales, que interaccionan con el SW una vez que se ha entregado para la producción.
Lic. Susana Daldin 11
Jefes de Equipos¿Qué es lo que buscamos cuando seleccionamos a alguien para dirigir un proyecto de SW?
Motivación. Organización. Ideas o Innovación.
Lic. Susana Daldin 12
Motivación
La habilidad para motivar al
personal técnico para que
produzca conforme a sus mejores
capacidades.
Lic. Susana Daldin 13
Organización La habilidad para moldear
procesos existentes que permita al concepto inicial transformarse en un proyecto final.
Lic. Susana Daldin 14
Ideas o Innovación La habilidad para motivar al
personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los límites establecidos para un producto o aplicación de SW particular
Lic. Susana Daldin 15
Gestor de Proyectoslas características que definen a un gestor
deproyecto eficiente resalta cuatro apartadosclaves: Resolución del problema. Dotes de gestión. Incentivo de los logros. Influencia y construcción de espíritu de
equipo.
Lic. Susana Daldin 16
Resolución del problema Un gestor puede diagnosticar los
aspectos tecnológicos y de organización.
Estructurar una posible solución Aplicar todo lo aprendido en
proyectos anteriores. Flexibilidad para cambiar la gestión
si los intentos iniciales no dan el resultado esperado.
Lic. Susana Daldin 17
Dotes de Gestión Un buen gestor de proyecto de
SW debe tomar las riendas. Debe tener confianza para asumir
el control cuando sea necesario. garantizar que los buenos
técnicos sigan su instinto.
Lic. Susana Daldin 18
Incentivos de los logros
Recompensar la iniciativa y los
logros. Demostrar, a través de sus
acciones que no se penalizará si
se corren riesgos controlados.
Lic. Susana Daldin 19
Influencia y construcción de espíritu de equipo.
Debe de ser capaz de “leer” a la gente.
Debe se capaz de entender mensajes verbales y no verbales.
Reaccionar ante la necesidades de las personas que mandan señales.
El gestor debe mantener el control en situaciones de gran estrés.
Lic. Susana Daldin 20
El Equipo de SW
Existen casi tantas estructuras de organización de personal para el
desarrollo de SW como organizaciones
que se dedican a ello.
Lic. Susana Daldin 21
las políticas y prácticas de un cambio en la organización no están dentro del alcance de las responsabilidades del gestor de un proyecto de SW.
la organización del personal directamente involucrado en un nuevo proyecto de SW esta dentro del ámbito del gestor del proyecto.
El Equipo de SW
Lic. Susana Daldin 22
La mejor estructura de personas que compondrá el equipo, sus niveles de preparación y la dificultas general del problema.
Se sugieren tres organigramas de equipo genérico. Descentralizado democrático (DD). Descentralizado controlado (DC). Centralizado controlado (CC).
El Equipo de SW
Lic. Susana Daldin 23
No tiene un jefe permanente. Se nombran coordinadores de tareas
a corto plazo. se sustituyen por otros para diferentes
tareas. Las decisiones sobre problemas y
enfoques se hacen por consenso del grupo.
La comunicación entre los miembros del equipo es horizontal.
Descentralizado democrático (DD)
Lic. Susana Daldin 24
Tiene un jefe definido. coordina tareas específicas y jefes secundarios.
La resolución de problemas sigue siendo una actividad del grupo.
La implementación de soluciones se reparte entre subgrupos por el jefe de equipo.
La comunicación entre subgrupos e individuo es horizontal.
Hay comunicación vertical a lo largo de la jerarquía de control.
Descentralizado controlado (DC)
Lic. Susana Daldin 25
El jefe del equipo se encarga de la resolución de problemas de alto nivel y la coordinación interna del grupo.
La comunicación entre el jefe y los miembros del equipo es vertical.
Centralizado controlado (CC)
Lic. Susana Daldin 26
Siete factores a considerar La dificultad del problema que hay que resolver. el tamaño del programa resultante en líneas de
código. el tiempo que el equipo estará junto(Tº de vida del
equipo. el grado en que el problema puede ser modularizado. la calidad requerida y fiabilidad del sistema que se va
a construir. la rigidez de la fecha de entrega. el grado de comunicación requerido para el proyecto.
Factores a considerar
Lic. Susana Daldin 27
Paradigmas de organización
Para equipos de ingeniería del SW
Paradigma cerrado. Paradigma aleatorio. Paradigma abierto. Paradigma sincronizado.
Lic. Susana Daldin 28
Paradigma cerrado Estructura a un equipo con una
jerarquía tradicional de autoridad (similar al equipo CC).
Trabajan bien cuando producen SW similar a otros anteriores.
Menos innovadores.
Lic. Susana Daldin 29
Paradigma aleatorio Estructura al equipo libremente y
depende de la iniciativa individual de los miembros.
se requiere innovación o avances tecnológicos.
son excelentes. chocan cuando se requiere un
“rendimiento ordenado”.
Lic. Susana Daldin 30
Paradigma abierto Intenta estructurar a un equipo de manera que consiga
algunos de los controles asociados con el paradigma
cerrado. Utiliza mucha de la innovación que tiene lugar cuando se
utiliza el paradigma aleatorio. El trabajo se desarrolla con mucha comunicación y toma
decisiones consensuadas. son adecuados para la resolución de problemas complejos. Pueden no tener un rendimiento tan eficiente como otros
equipos.
Lic. Susana Daldin 31
Paradigma Sincronizado
Se basa en la compartimentación natural de un problema.
Organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.
Lic. Susana Daldin 32
Cohesión de equiposTendemos a usar la palabra “equipo”
demasiado libremente en el mundo de los negocios, denominado “equipo” a cualquier grupo de gente asignado para trabajar junta.
Pero muchos de estos grupos no parecen equipos. No tienen una definición común de éxito o un espíritu de equipo identificable. Lo que falta es un fenómeno que denominamos
“cuajar”.
Lic. Susana Daldin 33
Cohesión de equipos
Un equipo cuajado es un grupo de
gente tejido tan fuertemente que el
todo es mayor que la suma de las
partes.
Lic. Susana Daldin 34
Cohesión de equipos
Cuando el equipo empieza a cuajar, la
probabilidad de éxito empieza a subir.
El equipo puede convertirse en
imparable, un monstruo de éxito. No
necesita ser dirigidos de una manera
tradicional y no necesitan que se les
motive. Están en su gran momento.
Comparten una meta en común
Lic. Susana Daldin 35
Técnicas de coordinación de proyectos
Formal, enfoque impersonal. Formal, procedimientos
interpersonales. Informal, procedimientos
interpersonales. Comunicación electrónica. Red interpersonal.
Lic. Susana Daldin 36
Formal, enfoque impersonal
Incluyen documentos de Ingeniería del SW
y entregas (Cod. fuente) memorandos
técnicos, planificaciones del programa y
herramientas de control del proyecto,
peticiones de cambios, informes de
seguimiento de errores e información de
estado e inspecciones de diseño y de
código.
Lic. Susana Daldin 37
Formal, procedimientos interpersonales
Se concentra en las actividades de
garantía de calidad. Aplicada a
productos de ingeniería del SW.
Incluyen reuniones de revisión de
estado e inspecciones de diseño y
de código.
Lic. Susana Daldin 38
Informal, procedimientos interpersonales
Incluye reuniones de grupo para la
divulgación de información y
resolución de problemas.
Definición de requisitos y del
personal de desarrollo.
Lic. Susana Daldin 39
Comunicación electrónica
Agrupa correo electrónico.
Boletines de noticias electrónicos.
Página WEB.
Sistemas de video conferencia.
Lic. Susana Daldin 40
Red interpersonal
Discusiones informales con
personas que no están en el
proyecto pero que pueden tener
experiencia.
discusión de puntos.
Lic. Susana Daldin 41
ProblemaEl gestor del proyecto requiere
estimaciones cuantitativas y un plan organizado. Pero no dispones de
información sólida. Un análisis detallado de los requisitos daría la información necesaria para
las estimaciones. A menudo lleva semanas o
meses.Los requisitos pueden ser fluidos, cambiando a
medida que progresa el proyecto. Aún así, necesita un plan “YA”.Debe examinar el
problema justo al inicio del proyecto
Lic. Susana Daldin 42
Ámbito del SWLa primera actividad de gestión es
determinar el ámbito del SW. Se define
respondiendo a las siguientes cuestiones:
Contexto.
Objetivos de información.
Función y rendimiento.
Lic. Susana Daldin 43
Contexto
Encajar el SW a construir en un
sistema. La limitaciones se
imponen como resultado del
contexto.
Lic. Susana Daldin 44
Objetivos de información
Qué datos visibles se obtienen
del cliente. Qué datos son
requeridos de entrada.
Lic. Susana Daldin 45
Función y rendimiento
Qué función realiza el SW para
transformar la información de
entrada en una salida.
Lic. Susana Daldin 46
Ámbito de proyecto
Los enunciados del SW estar
delimitados. Nº de usuarios
simultáneos, tamaño de la
lista de correo, máximo de Tº
de respuesta.
Lic. Susana Daldin 47
Descomposición del problemaEl particionamiento, es el corazóndel análisis de requerimiento. Seaplica en:
La funcionalidad que debe entregarse.
El proceso que se empleará para entregarlo
Lic. Susana Daldin 48
ProcesoEl gestor del proyecto debe decidir qué modelo de
proceso es le más adecuado para el proyecto,
después debe definir un plan preliminar basado en
un conjunto de actividades válidas. Una vez
establecido el plan preliminar, empieza la
descomposición del proceso. Se debe crear un plan
completo reflejando las tareas requeridas a las
personas para cubrir las actividades.
Lic. Susana Daldin 49
Maduración del problema y proceso La planificación de un proyecto empieza con la
maduración del problema y del proceso. Todas las funciones se deben tratar dentro de un proceso de ingeniería por el equipo de SW.
Conjunto de actividades: Comunicación con el cliente. Planificación. Análisis de riesgo. Ingeniería. Construcción y entrega. Evaluación del cliente.
Lic. Susana Daldin 50
Comunicación con el Cliente
Tareas requeridas para establecer
una comunicación eficiente entre
el desarrollador y el cliente.
Lic. Susana Daldin 51
Planificación
Tareas requeridas para definir los
recursos, la planificación temporal del
proyecto y cualquier información
relativa
a él.
Lic. Susana Daldin 52
Análisis de riesgo
Tareas requeridas para valorar los
riesgos técnicos y de gestión.
Lic. Susana Daldin 53
Ingeniería
Tareas requeridas para construir una
o más representaciones de la
aplicación.
Lic. Susana Daldin 54
Construcción y entrega
Tareas requeridas para construir,
probar
instalar y proporcionar asistencia al
usuario.
Lic. Susana Daldin 55
Evaluación del cliente
Tareas requeridas para obtener información de la opinión del cliente
basadas en la evaluación de las representaciones de SW creadas
durante la fase de ingeniería e implementación
durante la fase de instalación
Lic. Susana Daldin 56
Gestión efectiva de un proyecto de software
Lic. Susana Daldin 57
10 Causas de fracaso
Solución en busca de un problema. Solo el equipo del proyecto esta interesado en el
resultado final. Nadie a cargo. Plan carece de estructura. Plan carece de detalle. Presupuesto inferior al requerido. Recursos asignados insuficientes. No hay seguimiento contra un plan. El equipo no se comunica. El proyecto se aparta de sus metas originales.
Gestión efectiva de un proyecto de software
Lic. Susana Daldin 58
Gestión Efectiva
Ambito de trabajo. Riesgos. Recursos. Tareas. Hitos. Esfuerzo. Plan.
Lic. Susana Daldin 59
Recursos - Software
Gestión de proyectos Soporte Análisis y Diseño Programación Prueba e Integración Simulación y creación de prototipos Mantenimiento
Lic. Susana Daldin 60
Integración de Sistemas
Lic. Susana Daldin 61
La actividad de asumir responsabilidades
contractuales por la combinación
de productos y/o servicios propios y/o de
terceros en una solución que satisfaga los
requerimientos específicos del Cliente.
Integración de sistemas
Lic. Susana Daldin 62
Elementos Esenciales
Manejo del Riesgo.
Manejo de Proyectos.
Integración y Testeo.
Integración de sistemas
Lic. Susana Daldin 63
Integración de SistemasComponentes Típicos
Precio Fijo. Desarrollo Standard. Manejo de Subcontratistas. Test de Aceptación. Garantizar el Funcionamiento.
Lic. Susana Daldin 64
Integración de Sistemas
Etapa
Propuesta Preparación dePropuesta
Desarrollo deContrato
Resultado
Presentarnos óNO
Ganar ó Perder Aceptación delCliente
Lic. Susana Daldin 65
Integración de SistemasFactores Críticos de Éxito Involucrarse tempranamente. Acordar relaciones de trabajo con el cliente. Acordar relaciones de trabajo con los distintos
grupos. Efectiva utilización de terceras partes. Soporte continuo de la gerencia. Capacidad de gerenciamiento Técnico y Comercial
de los recursos y capacidades técnicas. Mediciones /Incentivos apropiados. Seguimiento positivo de logros y éxitos.
Lic. Susana Daldin 66
Integración de Sistemas
¿Qué es un contrato?
Un acuerdo entre dos ó más partes para hacer ó no hacer alguna cosa definida.
Un acuerdo exigible por ley.
Lic. Susana Daldin 67
Desarrollo y GerenciamientoObjetivos del Manejo de Proyectos
Producir un resultado o producto
definido en total concordancia
con el presupuesto y
cronograma.
Lic. Susana Daldin 68
Desarrollo y GerenciamientoConsideraciones:
Cada cliente tiene necesidades únicas. Cada proyecto tiene único requerimientos,
cronogramas, ambientes, etc..
Manejo de un proyecto debe ser: Flexible. Adaptado a un proyecto específico. Trabajado/Adaptado continuamente para
asegurar el éxito.
Lic. Susana Daldin 69
Desarrollo y GerenciamientoPrincipales causas de problemas Tomar compromisos anticipadamente a la
definición de requerimientos. Baja estimación del alcance y complejidad
del proyecto. Aceptar cambios sin una clara valoración
del impacto sobre el costo y plan del proyecto.
No totalmente definido y/o manejado el riesgo.
Incompleto manejo de los Subcontratistas.
Lic. Susana Daldin 70
Desarrollo y Gerenciamiento
La actividad de subcontratar desarrollo de Software es uno de losmayores riesgos.
Para contener el riesgo se debe trabajar con los subcontratistas.Desarrollar un plan de gerenciamiento:
Asegurar que el/los subcontratista/s tengan aceptables desarrollos. Metodología - Ciclo de vida de desarrollo. Estándares - Codificación, Documentación, Planes de Testeo, etc. Asegurarnos que los subcontratistas nos entienden. Requerimientos para inspecciones. Criterios de Aceptación. Educar, entrenar y dar dirección de gerenciamiento donde hay déficit
de conocimientos. Regularmente revisar sus progresos. Proveer un efectiva interface el/los sub/s y el Cliente. Ayudarlos a tener Éxito.
Lic. Susana Daldin 71
Gerente de Proyecto Único punto de responsabilidad para
alcanzar todos los compromisos del Proyecto.
Representar la empresa frente al cliente en todos los temas del Proyecto.
Puede delegar tareas en otros pero retiene la totalidad de la Responsabilidad.
El Cliente y cada subcontratista deben identificar un correspondiente Gerente de Proyecto como la primer interface.
Desarrollo y Gerenciamiento
Lic. Susana Daldin 72
Manejo del Riesgo
El manejo esta siempre presente a través del ciclo de vida de un sistema.
Desafiar cada suposición hecha sobre el programa.
La fase de propuesta es el período de tiempo Crítico.
Se requiere Identificación temprana, Evaluación y Planeamiento de la contención.
Desarrollo y Gerenciamiento
Lic. Susana Daldin 73
Manejo del Riesgo
Resistir la tentación de dimensionar el riesgo demasiado bajo.
Una medida de la calidad de la propuesta es una realista y contenida evaluación del riesgo.
NO BAJO RIESGO.
El Mayor Riesgo determina el Mayor Precio para el Cliente.
VERDADERO- Pero compartiendo parte de nuestra evaluación de riesgo y planes de contención con el cliente se demostrará nuestro profesionalismo.
Desarrollo y Gerenciamiento
Lic. Susana Daldin 74
Sumario
El éxito del Gerenciamiento de Proyecto requiere del Gerente de Proyecto y del Equipo del Proyecto:
Entender
El proceso de desarrollo. Los requerimientos. La solución.
Planificar
La implementación. La organización.
Desarrollo y Gerenciamiento
Lic. Susana Daldin 75
Sumario
Manejar
Los recursos del Proyecto (Propios, del Cliente y Sucontratistas).
El Plan. El Riego.
Controlar
El progreso. Los problemas. Los cambios.
Desarrollo y Gerenciamiento
Lic. Susana Daldin 76
Trabajo en Equipo
¿De quién es el trabajo?
Lic. Susana Daldin 77
Primeras Restricciones
Fechas de entrega.
Presupuesto.
Disponibilidad del Personal.
Lic. Susana Daldin 78
Planificación Temporal
Identificar tareas. Fijar interdependencias entre tareas. Estimar esfuerzo de cada tarea. Asignar personal. Construir la red. Establecer el camino crítico.
Lic. Susana Daldin 79
Análisis de Riesgos
Identificación. Cálculo. Priorización. Estrategias de control. Resolución. Supervisión.
Lic. Susana Daldin 80
Trabajo en Equipo
Esta es la historia acerca de cuatro personas llamadas TODOS, ALGUIEN, CUALQUIERA y
NADIE.
“Había que cumplir una tarea muy importante, y se le
ordenó a TODOS hacerla. TODOS estaban seguros de
que ALGUIEN lo haría, pero NADIE lo hizo. ALGUIEN se
enojó, porque era un trabajo de TODOS.
TODOS pensaron que CUALQUIERA pudo haberlo
hecho, pero NADIE se dio cuenta de que TODOS no lo
iban a hacer. Al fin, TODOS acusaron a ALGUIEN cuando
NADIE hizo lo que CUALQUIERA pudo haberlo hecho”.
Lic. Susana Daldin 81
Trabajo en Equipo
Una aproximación:Una aproximación:
Una reunión de gente trabajando coordinadamente, por un objetivo común, que logra un mejor resultado que los que
obtendrían los mismos individuos trabajando por su cuenta.
Lic. Susana Daldin 82
Trabajo en Equipo
¿Qué es Trabajo en Equipo?(por lo que No es)
No es reunionismo. No es necesariamente toma de
decisiones en equipo. No es perdida de individualidad. No es perdida de autoridad.
Lic. Susana Daldin 83
Trabajo en Equipo ¿Qué es Trabajo en Equipo?
(por lo que Si es)
Tener un objetivo ó meta común. Estar dispuesto a sacrificar intereses.
personales ó del grupo, momentáneamente. Tener confianza en los demás. Disposición a compartir información. Sentir en carne propia los problemas ajenos.
Lic. Susana Daldin 84
Trabajo en Equipo
Diagnosticando la salud del grupo
Intercomunicación entre los miembros del grupo.
Objetividad del grupo con respecto a su propio funcionamiento.
Responsabilidad interdependiente de todos los miembros.
Adecuada coherencia del grupo.
Lic. Susana Daldin 85
Métricas - Línea Base
Beneficios:
Estratégicos. Proyecto. Técnicos.
Lic. Susana Daldin 86
¿Por qué fallan las estimaciones ?
Lic. Susana Daldin 87
Cambio constante en los requerimientos.Falta de técnicas.Falta de planificación.Ausencia de recaudos.Falta de conocimiento de procesos de estimación.Mal manejo de problemas políticos. No tomar como base casos anteriores.
Factores claves
Lic. Susana Daldin 88
Factores clave para estimar bien:
Disponibilidad de registros precisos sobre proyectos anteriores.
Adopción de metodologías estándar.
Estos dos factores ayudaran a concebir las métricas.
Factores Claves
Lic. Susana Daldin 89
Métricas del proyecto
¿Por qué métricas ?
Lic. Susana Daldin 90
Métricas
Que midenProductividadCalidad
Beneficios
Futuras Estimaciones Medidas
DirectasIndirectas
Lic. Susana Daldin 91
¿Qué se puede medir ? El proceso del software (para mejorarlo). El proyecto del software (para ayudar a
estimar, control de calidad, evaluación de productividad, control de proyectos).
Calidad del producto (para ayudar el la toma de decisiones tácticas a medida que el proyecto evoluciona).
Lic. Susana Daldin 92
Medidas , métricas e indicadores Medida: Indicación cuantitativa de extensión,
cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto.
Medición: Es el acto de determinar una medida.
Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado.
Indicador: Es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del SW, del proyecto del SW o del producto en sí.
Lic. Susana Daldin 93
Mediciones del software
Las mediciones del mundo físico se pueden clasificar de dos maneras: Medidas directasMedidas directas:: Ej. Longitud de un tornillo Medidas indirectasMedidas indirectas: Ej. Calidad de los tornillos
producidos, medidos contando los artículos defectuosos
Las métricas del SW, se categorizan de forma similar Directas:Directas: líneas de código producidas (LDC),
velocidad de ejecución, tamaño de memoria Indirectas:Indirectas: funcionalidad, calidad, complejidad.
Lic. Susana Daldin 94
Costo y métricas de calidad
Defecto/fallo Vs. Error Defecto y fallo: son sinónimos
dentro del contexto del proceso del software. Implican un problema de calidad que es descubierto una vez entregado el software al cliente.
Error: Problema de calidad detectado por los ingenieros u otros dentro del proceso del software.
Lic. Susana Daldin 95
Revisiones técnicas formales Encontrar errores durante el proceso
de forma que no se conviertan en defectos después de la entrega.
Tratar de descubrir errores al principio para que no se propaguen al paso siguiente del proceso del software.
Costo y métricas de calidad
Lic. Susana Daldin 96
Las actividades de diseño introducen entre el 50 al 65 % de todos los errores (y en último lugar todos los defectos).
Sin embargo, se ha demostrado que las revisiones técnicas formales (RTF) son efectivas en un 75 % a la hora de detectar errores.
Con la detección y eliminación de un gran porcentaje de errores, el RTF reduce el costo de los pasos siguientes en la fase de desarrollo y de mantenimiento.
Costo y métricas de calidad
Lic. Susana Daldin 97
Datos basados en Experiencia
Implementating software inspections IBM
Error descubierto en diseño cuesta corregirlo 1,0 unidad monetaria
Tomando la medida como base
Antes de la prueba 6,5 unidades Durante la prueba 15 unidades Después de la entrega 60-100 unidades
Costo y métricas de calidad
Lic. Susana Daldin 98
Indicadores Proyecto/Proceso Indicadores de proceso:Indicadores de proceso: Permiten a una
organización de ingeniería del software tener una visión profunda de la eficacia de un proceso ya existente. (las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo)
Indicadores de proyecto:Indicadores de proyecto: Permiten al gestor de proyectos del SW (1) evaluar el estado de un proyecto en curso; (2) seguir la pista de los riesgos potenciales; (3) detectar la áreas de problemas antes de que se conviertan en críticas; (4) ajustar el flujo y las tareas del trabajo; (5) evaluar la habilidad del equipo.
Lic. Susana Daldin 99
Métricas orientadas al tamaño Si una organización mantiene registros
sencillos, se puede crear una tabla de datos orientados al tamaño.
Proyecto LDC Esfuerzo pp.doc Errores Defectos Personas
Alfa 12100 24 365 134 29 3Beta 27200 64 456 2410 88 5Gamma 20200 45 314 1057 64 7
Lic. Susana Daldin 100
Métricas simples -orientadas al tamaño-
Errores por KLDC (miles de líneas de código, KiloLDC).
Defectos por KLDC. Páginas de documentos por
KLDC. Errores/persona-mes. LDC/persona mes.
Lic. Susana Daldin 101
Para lograr buenas métricas Utilice el sentido común y una
sensibilidad organizativa al interpretar datos de métricas.
No utilice métricas para evaluar a particulares.
Trabaje con profesionales y equipos para establecer objetivos claros y métricas que se vayan a utilizar para alcanzarlos.
No utilice nunca métricas que amenacen a particulares y/o equipos.
Lic. Susana Daldin 102
Factor de complejidad
Evaluar cada factor en una escala de 0 a 5Evaluar cada factor en una escala de 0 a 5
0 No influencia.
1 Incidental.
2 Moderado.
3 Medio.
4 Significativo.
5 Esencial.
Lic. Susana Daldin 103
No sabemos si estamos mejorando
No podemos establecer metas
¿Qué pasa si no medimos?
Lic. Susana Daldin 104
Duración de entrevistas.
Extrapolación.
Estándares de programación.
Otras Técnicas
Lic. Susana Daldin 105
Sugerencias para lograr buenas métricas
Utilice el sentido común y una sensibilidad organizativa al interpretar datos de métricas.
No utilice métricas para evaluar a particulares.
Trabaje con profesionales y equipos para establecer objetivos claros y métricas que se vayan a utilizar para alcanzarlos.
No utilice nunca métricas que amenacen a particulares y/o equipos.
Lic. Susana Daldin 106
Estimaciones - Factores de riesgo Tamaño del esfuerzo.
Grado de estructuración,
definición y variabilidad.
Complejidad basada en esfuerzos
pasados.
Lic. Susana Daldin 107
Ambito del Software
Función.
Rendimiento.
Restricciones.
Interfaces.
Fiabilidad.
Lic. Susana Daldin 108
Recursos
Humanos.
Hardware.
Software.
Reusabilidad.
Lic. Susana Daldin 109
Control de calidad
del software
Lic. Susana Daldin 110
Control de calidad del software
MitoMitoLa calidad del software es algo en lo
que se empieza a preocupar una vez que se ha generado el código.
NO !
Lic. Susana Daldin 111
Calidad: Una característica o atributo de algo. Como atributo de un artículo, la calidad se
refiere a las características mensurables. Cosas que se pueden comparar con estándares:
Longitud, color, etc Sin embargo el SW como entidad
intelectual es mas difícil. Complejidad ciclomática, cohesión, líneas de
código.
Control de calidad del
software
Lic. Susana Daldin 112
Calidad De Diseño: características que
especifican los Ingeniería del SW para un artículo.(grado de materiales, tolerancias, especificaciones de rendimiento) – Etapa de diseño.
Calidad de concordancia: grado de cumplimiento de las especificaciones de diseño – Etapa de implementación
Control de calidad del
software
Lic. Susana Daldin 113
Control de calidad Es una serie de inspecciones, revisiones y
pruebas utilizados a lo largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados.
Feedback Las actividades de control pueden ser
Manuales Automatizadas Combinación
Control de calidad del
software
Lic. Susana Daldin 114
Garantía de calidad: o aseguramientoaseguramiento de
La calidad, consiste en la auditoría y las
funciones de gestión.
Esto asegura que la calidad del producto se está cumpliendo y de no ser así es responsabilidad del área de control afrontar los problemas y revisiones
Control de calidad del
software
Lic. Susana Daldin 115
Costo de la calidad Incluye los costos asociados a la búsqueda de la calidad o relacionados en la obtención de la calidad Prevención
Planificación de la calidad Revisiones técnicas formales Equipo de pruebas Formación
Evaluación Inspección en el proceso y entre procesos Mantenimiento de equipos Pruebas
Control de calidad del
software
Lic. Susana Daldin 116
Fallos (antes de ser entregados al cliente) Revisión. Reparación. Análisis de modalidades de fallos.
Fallos externos (ya entregado al cliente) Resolución de quejas. Devolución y sustitución de productos. Soporte en línea. Trabajo de garantía.
Control de calidad del
software
Lic. Susana Daldin 117
Control de calidad del
softwareLa garantía de calidad del software
(SQA)Software Quality assurance) es una
actividad de protección que se aplica a lo largo de todo el proceso de ingeniería del software.
Lic. Susana Daldin 118
La SQA engloba un enfoque de gestión de calidad; tecnología de ingeniería del software efectiva (métodos y herramientas), revisiones técnicas formales que se aplican durante el proceso del software; una estrategia de software multiescalada; control de la documentación del software y de los cambios realizados, un procedimiento que asegure un ajuste a los estándares de desarrollo del software (cuando sea posible); y mecanismos de medición y de generación de informes.
Control de calidad del
software
Lic. Susana Daldin 119
Calidad del software Concordancia con los requisitos
funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado
Control de calidad del
software
Lic. Susana Daldin 120
Variación entre muestrasEjemplos :
Circuitos integrados Rutina de búsqueda
Hay que reducir la variación es el centro de control de calidad.
Control de calidad del
software
Lic. Susana Daldin 121
Ejemplo: Queremos reducir la diferencia entre los recursos necesarios planificados para terminar proyecto y los recursos reales utilizados (personas, equipo y tiempo).
Reducción de errores ocultos. Reducción de diferencias de velocidad. Precisión en respuestas de soporte.
Control de calidad del
software
Lic. Susana Daldin 122
Los requisitos del software son la base de las medidas de calidad.
Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del SW.
Existe un conjunto de requisitos implícitos que a menudo no se mencionan (Ej. buen mantenimiento)
Control de calidad del
software
Lic. Susana Daldin 123
Actividades del SQA Ingeniería del SW: Aplican métodos
técnicos sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas del software bien planificadas.
Auditoria y control de gestión
Control de calidad del
software
Lic. Susana Daldin 124
Propósito del planReferenciaGestión.
Organización.Tareas.Responsabilidad.
Documentación.PropósitoDocumentos requeridos de ingeniería del
softwareOtros documentos
Estándares, prácticas y convenciones
Control de calidad del
software
Lic. Susana Daldin 125
Manejo de Riesgo del Proyecto
Lic. Susana Daldin 126
Manejo de Riesgo del ProyectoUna Definición
En primer lugar, el riesgo concierne a lo que ocurra en el futuro. El hoy y el ayer ya no nos conciernen realmente, porque ahora ya estamos recogiendo los frutos de lo que sembramos en el pasado. La cuestión es si podemos, entonces, modificando nuestras acciones de este momento, crear una oportunidad para una situación diferente y mas esperanzada de nuestro mañana. Esto significa, en segundo lugar, que el riesgo implica un cambio que puede venir dado por cambios de opiniones, acciones ó lugares….(En tercer lugar), el riesgo implica una elección, y falta de certeza de que la elección sea la correcta. Así, paradójicamente, el riesgo, como la muerte ó los impuestos, es una de las pocas cosas inevitables de la vida.
Robert Charette
Lic. Susana Daldin 127
Manejo del Riesgo del Proyecto¿Que es Riesgo?
Riesgo es un evento posible, indeseable y no planificable que puede resultar en la no concreción de uno o más de los objetivos del proyecto.
El Riesgo tiene tres componentes
* Un evento* Probabilidad de ocurrencia de ese evento* Impacto de ese evento
Nota: Todos los proyectos tienen riesgos. Si los riesgos son ignorados, Ud. esta incrementando la probabilidad que el proyecto pueda fallar de alguna manera.
Lic. Susana Daldin 128
Manejo del Riesgo del Proyecto¿Porque Manejo del Riesgo?
Para Proteger Costo. Cronogramas. Requerimientos.
Prevenir sorpresas Focalizarnos en producir la oferta correcta la primer vez. Prevenir a la gerencia por las crisis Prevenir/minimizar los problemas antes de su ocurrencia ó, si
estos ocurren, antes que crezcan.
Lic. Susana Daldin 129
Manejo del Riesgo del ProyectoEl Manejo de Riesgo de un proyecto incluye los procesos relacionados
con la identificación, análisis y tratamiento del riesgo del proyecto.
Lo cual implica la maximización de los eventos positivos y la minimización de las consecuencias de los eventos negativos.
Lic. Susana Daldin 130
Manejo del Riesgo del Proyecto
Los principales procesos del Manejo de Riesgo del proyecto son:
Identificación del riesgo, determinando cuales riesgos son potenciales a afectar el proyecto, documentando las características de cada uno.
Clasificación del riesgo, evaluando riesgos e interacciones entre riesgos para dimensionar los resultados posibles del proyecto.
Desarrollo de la respuesta al riesgo, definición de los paso para la intensificación de las oportunidades y el manejo de las amenazas.
Control de la respuesta al riesgo, respondiendo a los cambios en el riesgo sobre el curso de acción del proyecto.
Lic. Susana Daldin 131
Manejo del Riesgo del ProyectoIdentificación del Riesgo:
Internos/ExternosAsignaciones del Staff/Estimaciones de Costo.Campos del Mercado/Acciones del Gobierno.
Del ProyectoPresupuestarios/de Agenda/de Recursos/del Cliente.
TécnicosDiseño/Implementación/Tecnología de Punta.
Del NegocioExcelente Producto que Nadie Quiere/Pérdida del Soporte de los gestores.Pérdidas Presupuestarias y/o de Personal.
Lic. Susana Daldin 132
Manejo del Riesgo del ProyectoClasificación del Riesgo:
Probabilidad de que riesgo ocurra (sea real).Consecuencias del riesgo sobre el proyecto.
Actividades para la calificación del riesgo.Establecimiento de una escala que refleje la probabilidad del riesgo.Definición de las consecuencias del riesgo.Estimación del impacto del riesgo.Documentación de la exactitud general de la proyección del riesgo.
Lic. Susana Daldin 133
Manejo del Riesgo del Proyecto
Desarrollo de la respuesta al riesgo:Invalidación
Eliminación de una amenaza, usualmente por eliminación de la causa.
MitigaciónReducción de la probabilidad de ocurrencia del riesgo, reducción del impacto del riesgo en el proyecto ó ambos.
AceptaciónActiva, desarrollo de un plan de contingencia.Pasiva, aceptación de una menor ganancia en caso de ocurrencia.
Lic. Susana Daldin 134
Manejo del Riesgo del Proyecto
Mensajes claves del Manejo de Riesgos
Manejar el riesgo es esencial para el éxito del
proyecto.
El riesgo incluye oportunidades de ganar así como
potencialmente de perder.
Manejar el riesgo requiere disciplina.
El Manejo del riesgo es un proceso repetitivo
hecho a través del ciclo de vida del proyecto.
El Riesgo puede ser MANEJADO