material apoyo ingenieria del software usal argentina

Lic. Susana Daldin 1

Ingeniería del Software


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


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.


Gestión de Proyectos –tres “pes”-


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.


Conceptos sobre gestión de proyectosLa gestión eficaz de un proyecto de software se centra en las Tres “PES”:

Personal.

Problema.

Proceso.


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.


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.


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.


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.


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.


Motivación

La habilidad para motivar al

personal técnico para que

produzca conforme a sus mejores

capacidades.


Organización La habilidad para moldear

procesos existentes que permita al concepto inicial transformarse en un proyecto final.


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


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.


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.


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.


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.


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.


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.


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


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


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)


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)


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)


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


Paradigmas de organización

Para equipos de ingeniería del SW

Paradigma cerrado. Paradigma aleatorio. Paradigma abierto. Paradigma sincronizado.


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.


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”.


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.


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.


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”.


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.


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


Técnicas de coordinación de proyectos

Formal, enfoque impersonal. Formal, procedimientos

interpersonales. Informal, procedimientos

interpersonales. Comunicación electrónica. Red interpersonal.


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.


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.


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.


Comunicación electrónica

Agrupa correo electrónico.

Boletines de noticias electrónicos.

Página WEB.

Sistemas de video conferencia.


Red interpersonal

Discusiones informales con

personas que no están en el

proyecto pero que pueden tener

experiencia.

discusión de puntos.


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


Á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.


Contexto

Encajar el SW a construir en un

sistema. La limitaciones se

imponen como resultado del

contexto.


Objetivos de información

Qué datos visibles se obtienen

del cliente. Qué datos son

requeridos de entrada.


Función y rendimiento

Qué función realiza el SW para

transformar la información de

entrada en una salida.


Á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.


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


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.


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.


Comunicación con el Cliente

Tareas requeridas para establecer

una comunicación eficiente entre

el desarrollador y el cliente.


Planificación

Tareas requeridas para definir los

recursos, la planificación temporal del

proyecto y cualquier información

relativa

a él.


Análisis de riesgo

Tareas requeridas para valorar los

riesgos técnicos y de gestión.


Ingeniería

Tareas requeridas para construir una

o más representaciones de la

aplicación.


Construcción y entrega

Tareas requeridas para construir,

probar

instalar y proporcionar asistencia al

usuario.


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


Gestión efectiva de un proyecto de software


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


Gestión Efectiva

Ambito de trabajo. Riesgos. Recursos. Tareas. Hitos. Esfuerzo. Plan.


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


Integración de Sistemas


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


Elementos Esenciales

Manejo del Riesgo.

Manejo de Proyectos.

Integración y Testeo.

Integración de sistemas


Integración de SistemasComponentes Típicos

Precio Fijo. Desarrollo Standard. Manejo de Subcontratistas. Test de Aceptación. Garantizar el Funcionamiento.



Etapa

Propuesta Preparación dePropuesta

Desarrollo deContrato

Resultado

Presentarnos óNO

Ganar ó Perder Aceptación delCliente


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.



¿Qué es un contrato?

Un acuerdo entre dos ó más partes para hacer ó no hacer alguna cosa definida.

Un acuerdo exigible por ley.


Desarrollo y GerenciamientoObjetivos del Manejo de Proyectos

Producir un resultado o producto

definido en total concordancia

con el presupuesto y

cronograma.


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.


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.


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.


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.



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.



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.



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.



Sumario

Manejar

Los recursos del Proyecto (Propios, del Cliente y Sucontratistas).

El Plan. El Riego.

Controlar

El progreso. Los problemas. Los cambios.



Trabajo en Equipo

¿De quién es el trabajo?


Primeras Restricciones

Fechas de entrega.

Presupuesto.

Disponibilidad del Personal.


Planificación Temporal

Identificar tareas. Fijar interdependencias entre tareas. Estimar esfuerzo de cada tarea. Asignar personal. Construir la red. Establecer el camino crítico.


Análisis de Riesgos

Identificación. Cálculo. Priorización. Estrategias de control. Resolución. Supervisión.


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”.


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.


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.


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.


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.


Métricas - Línea Base

Beneficios:

Estratégicos. Proyecto. Técnicos.


¿Por qué fallan las estimaciones ?


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


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


Métricas del proyecto

¿Por qué métricas ?


Métricas

Que midenProductividadCalidad

Beneficios

Futuras Estimaciones Medidas

DirectasIndirectas


¿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).


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í.


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.


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.


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.



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.



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



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.


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


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.


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.


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.


No sabemos si estamos mejorando

No podemos establecer metas

¿Qué pasa si no medimos?


Duración de entrevistas.

Extrapolación.

Estándares de programación.

Otras Técnicas


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.


Estimaciones - Factores de riesgo Tamaño del esfuerzo.

Grado de estructuración,

definición y variabilidad.

Complejidad basada en esfuerzos

pasados.


Ambito del Software

Función.

Rendimiento.

Restricciones.

Interfaces.

Fiabilidad.


Recursos

Humanos.

Hardware.

Software.

Reusabilidad.


Control de calidad

del software


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 !


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


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


software


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


software


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


software


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


software


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.


software



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.


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.


software


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


software


Variación entre muestrasEjemplos :

Circuitos integrados Rutina de búsqueda

Hay que reducir la variación es el centro de control de calidad.


software


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.


software


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)


software


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


software


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


software


Manejo de Riesgo del Proyecto


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


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.


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.


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.


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.


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.


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.



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.



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

material apoyo ingenieria del software usal argentina

Technology