Resumen Cap.

24-27

Nombre:

Hugo Alfredo Cruz Trujillo

Matrcula:

16103300494

Identificacin de Materia:

Calidad de Software

Fecha:

12 de Mayo del 2014

Regularmente nos encontramos con casos en los que se estima una fecha de entrega de
un desarrollo y este no se cumple la mayora de las razones que son:

Una fecha lmite irrealizable establecida por alguien externo al grupo de ingeniera
del software e Impuesta a los gestores y profesionales del grupo.

Cambo en los requisitos del cliente que no se reflejan en modificaciones a la

calendarizacin

Una subestimacin razonable de Ia cantidad de esfuerzo o de recursos que Se

requerirn para realizar el trabajo.

Riesgos predecibles o impredecibles que no se consideraron cuando comenz el

proyecto.

Dificultades tcnicas que no pudieron preverse

Dificultades humanas imprevisibles

Falta de comunicacin entre cl personal del proyecto, lo que genera demoras.

Una falta en la gestin del proyecto porque no reconoci el retraso ni emprendi

una accin para corregir cl problema

Regularmente las fechas de terminacin de un proyecto son impuestas por las reas
usuarias la gente de mercadotecnia y ventas por ejemplo y cuando se hace un estimado
por la gente que desarrollara los proyectos, se estima que el tiempo es mayor al impuesto
para estos casos el gestor de proyectos tiene que realizar los siguientes pasos:

1. Realizar una estimacin detallada empleando datos histricos de proyectos previos.

Determinar el esfuerzo y la duracin estimados para el proyecto.
2. Aplicar un modelo de proceso incremental y desarrollar una estrategia de ingeniera de
software que entregar la funcionalidad crtica en la fecha lmite impuesta, pero demorara
otra. Documente el plan
3. Reunirse con el cliente y, con la estimacin detalladla, explicarle porque la fecha lmite
impuesta es Irrealizable. Asegrese de sealar que todas las estimaciones estn basadas
sobre el desempeo en proyectos previos. Tambin asegrese de indicar el porcentaje de
mejora que se requerir para lograr la fecha lmite vigente.

4. Ofrezca la estrategia de desarrollo incremental como alternativa:

Tenemos unas cuantas opciones y me gustara que tornase una decisin con base en
ellas Primero, podemos aumentar el presupuesto y conseguir recursos adicionales de
modo que tendremos mucho xito en lograr que este trabajo est hecho en nueve meses.
Pero comprenda que esto aumentar el nesgo de una calidad deficiente debido a La
apretada fecha lmite. Segundo, podemos remover varias de las funciones y capacidades
de software que est solicitando. Esto har que la versin preliminar del producto sea un
poco menos funcional, pero podemos anunciar toda la funcionalidad y luego entregarla en
el periodo dc 14 meses. Tercero, podemos prescindir de la realidad y esperar que el
proyecto se complete en nueve meses Terminaremos con nada que se pueda entregar a
un cliente La tercera opcin, espero que est dc acuerdo, es inaceptable. La historia y
nuestras mejores estimaciones indican que es irreal y un boleto hacia el desastre.

El objetivo del gestor es definir todas las tareas del proyecto. La calendarizacin del
proyecto de software es una actividad que distribuye estimaciones de esfuerzo a travs de
la duracin planificada del proyecto al asignar el esfuerzo a tareas especficas de la
ingeniera del software.
Existen dos perspectivas para la calendarizacin de proyectos la primera se basa en que
ya se ha establecido una fecha irrevocable final para la liberacin del sistema y la
segunda en que la fecha final la establece la organizacin de ingeniera de software. Por
desgracia, la primera situacin se encuentra con mucha ms frecuencia que la segunda.

Los principios bsicos de la calendarizacin son:

Compartimentacin esto quiere decir que proyecto debe dividirse en compartimientos en
varias actividades, acciones y tareas manejables.
Interdependencia. Se debe determinar la interdependencia de cada actividad, accin o
tarea compartimentada.
Asignacin de tiempo a cada tarea se le debe asignar cierto nmero de unidades de
trabajo y una fecha de inicio y fin.
Validacin del esfuerzo. El gestor de proyectos debe asegurarse de que, en un tiempo
dado, no se han asignado ms de un nmero de personas calendarizada.

Definicin de responsabilidades. Toda tarea calendarizada se le debe asignar un miembro

especfico del equipo.
Definicin de resultados. Toda tarea debe tener un resultado definido.
Definicin de hitos. Cualquier tarea debe estar asociada con un hito del proyecto.
Muchos gestores responsables del desarrollo del software creen que si llega existir
retrasan algunas de las tareas con incrementar el nmero de personas asignadas a esa
tarea se podr terminar la tarea tiempo en la mayora de las ocasiones esto es de la forma
contraria se incrementan los tiempos debido a que las personas que se integran a la tarea
no tienen el conocimiento necesario que las personas que iniciaron la tarea.
Una distribucin recomendada del esfuerzo a travs del proceso de software se conoce
como 40-20-40.40 por ciento al anlisis y diseo, cuenta por ciento a las pruebas y por
ltimo un 20% asignado al desarrollo. Esta distribucin slo deben usarse como gua las
caractersticas de cada proyecto debe evitar la distribucin del esfuerzo.
El desarrollo de una calendarizacin del proyecto requiere distribuir en conjunto de tareas
a lo largo de la lnea del tiempo del proyecto. El conjunto de tareas variar segn el tipo
de proyecto y el grado de rigor con el equipo de software decide realizar su trabajo. En la
mayora de las organizaciones del ramo se encuentran los siguientes proyectos:
Proyectos de desarrollo del concepto, los cuales inician para explorar algunas
aplicaciones o conceptos de negocios de alguna nueva tecnologa.
Proyectos de desarrollo de nuevas aplicaciones. Los cuales se llevan a cabo como
consecuencia de una solicitud especfica del cliente.
Proyecto de mejora de la aplicacin. stos ocurren cuando el software existente
experimenta grandes modificaciones en la funcin, el desempeo o las interfaces visibles
para el final.
Proyectos de mantenimiento de aplicaciones. Los cuales corrigen, adaptan o extienden el
software existente en formas que no sean obvias inmediatamente para refinar.
Proyectos de reingeniera. Esto se lleva a cabo con la finalidad de reconstruir un sistema
existente, en todo o en parte.
Los proyectos de desarrollo de conceptos inician conocer debe explorar el potencial para
una nueva tecnologa las tareas aplicables son las siguientes.

Determinacin del mbito del concepto. Precisa el mbito global del proyecto.
Planeacin preliminar del concepto. Establece la habilidad de la organizacin para
acometer el trabajo que entraa el mbito del proyecto.

Valorizacin del riesgo de la tecnologa. Evaluar el riesgo asociado con la tecnologa que
se implantar como parte del mbito del proyecto.
Prueba del concepto demuestra la viabilidad de una tecnologa en el contexto del
software.
Implementacin del concepto pone en prctica la representacin del concepto en una
forma que pueda revisarla un cliente y se utiliza para propsitos de mercadotecnia.
Reaccin del cliente. Al concepto solicita realimentacin acerca de un concepto de nueva
tecnologa y se dirige a aplicaciones especficas de los clientes.
Una red de tareas, tambin denominada red de actividades, es una representacin grfica
de flujo de tareas en un proyecto. En ocasiones utiliza un mecanismo mediante el cual la
secuencia dependencia de las tareas son la entrada a una herramienta automatizada de
calendarizacin de proyecto. Puesto que las caras paralelas ocurren de manera sncrona,
el planificador debe determinar dependencias entre tareas para asegurar el progreso
continuo hacia la finalizacin.
La tcnica de evaluacin y revisin de programa y el mtodo de ruta crtica son dos
mtodos de calendarizacin de proyecto que se pueden aplicar en el desarrollo del
software. Ambas tcnicas reciben impulso de la informacin ya desarrollaban actividades
tempranas de la prelacin del proyecto.

Estimacin del esfuerzo.

Descomposicin de la funcin del producto.
Seleccin del modelo de proceso y conjunto de tareas apropiados.
Descomposicin de tareas.
Cuando se crea una calendarizacin de un proyecto el planificador comienza con un
punto de tareas si se emplea una herramienta automatizada se puede ingresar la duracin
la fecha de inicio la fecha de trmino de cada tarea y como consecuencia se generar un
cronograma o grfico Gantt.
Si se ha desarrollado de manera adecuada, la calendarizacin del proyecto define las
tareas edictos que deben seguir y controlar conforme avance el proyecto. El seguimiento
se puede ser de diferentes maneras:
Con la realizacin peridica de reuniones para valorar el estado del proyecto.
Con la evaluacin de los resultados de todas las revisiones realizadas a lo largo del
proceso.

Con la determinacin de si se han logrado los hitos formales del proyecto en la fecha
programada.
Al comparar la fecha de inicio real con la fecha de inicio prevista.
Al reunirse con los trabajadores para obtener su poblacin subjetiva de progreso hasta la
fecha.
Con el uso de anlisis del valor obtenido para evaluar el progreso cuantitativamente.
El control emplea el gestor del proyecto para administrar recursos del proyecto, lidiar con
los problemas y dirigir el personal del proyecto. Cuando ocurren problemas el gestor de
proyectos debe ejercer control para asegurar solucionarlos tan pronto sea posible.
Existen una tcnica cuantitativa para evaluar el progreso conforme el equipo de software
avanza a travs de las tareas de trabajo asignadas en el calendario del proyecto, se llama
anlisis de valor ganado proporciona una escala de valor comn para cualquier tarea, sin
importar el tipo de trabajo que se realiza. Se estiman las horas totales para realizar todo
proyecto y a cada tarea se da un valor ganado en base en su porcentaje estimado del
total. Es decir permite valorable porcentaje realizado de un proyecto reenviando el anlisis
cuantitativo en lugar de apoyarse en una opinin personal.

Para determinar el valor ganado se realizan los siguientes pasos:

Se determina el costo presupuestado para el trabajo calendarizada (CPTC) respecto de
cada tarea de trabajo representada en la calendarizacin. Durante la estimacin se
planifica el trabajo de cada tarea de ingeniera. Para determinar el progreso en un punto
dado en la calendarizacin del proyecto, el valor de CPTC es la suma de los valores
CPTCi para todas las tareas de trabajo que deben estar completadas en dicho punto en el
tiempo en la calendarizacin del producto.

Los valores CPTC para todas las tareas de trabajo se resumen para obtener el
presupuesto a la terminacin, PAT por lo tanto,
PAT = (PTCk) para todas las tareas k.
A continuacin se calcul el costo presupuestado del trabajo realizado (CPTR) el valor de
CPTR es la suma de los valores CPTC para todas las reas de trabajo que en realidad se
han completado en un punto y en el tiempo de la calendarizacin del proyecto.
La distincin entre CPTC y CPTR es que la primera representa presupuesto de la
actividad que se planea y la ltima el presupuesto de la actividad que en realidad se
complet.

Se pueden calcular importantes indicadores de progreso en base a estos ltimos valores

ndice de desempeo en la calendarizacin IDCa = CPTR / CPTC
Varianza en la calendarizacin VC = CPTR CPTC
En el primero un valor cercano a uno indica que la ejecucin es eficiente y el segundo es
simplemente un indicador absoluto de la variacin a partir de la calendarizacin planeada.
Porcentaje de calendarizado para terminacin = CPTC / PAT ofreci de verificacin
cuantitativa del porcentaje de avance del proyecto que debe ser completado en el tiempo
t.
Porcentaje de completado = CPTR / PAT ofreci la indicacin cuantitativa del porcentaje
de avance del proyecto en un punto dado en el tiempo t.
En ese desempeo del costo IDCo = CPTR/CRTR. Cercano a uno ofrece un fuerte
indicador de que el proyecto est dentro del presupuesto definido.
Varianza de costo Vc = CPTR CRTR. Es un indicador absoluto del ahorro en costo o
recortes en una etapa particular de un proyecto.

El anlisis de valor ganado ilumina las dificultades en la calendarizacin antes de que

puedan advertirse de alguna otra forma. Esto permite que el gestor de proyectos de
software tome medidas correctivas antes de que se desarrolle una crisis en proyecto.

Gestin del riesgo.

El riesgo se relaciona con los acontecimientos futuros. El oro y el ayer estn ms all de
esta relacin, pues ya se ha cosechado lo que previamente se sembr con nuestras
acciones pasadas, esto implica cambio, como cambios de mentalidad, opinin, acciones o
lugares y por ltimo el riesgo implica eleccin y de incertidumbre que sta lleva.

Regularmente todos los gestores promedios de proyectos de software se apoyan

exclusivamente a la estrategia de relativa la cual se presenta cuando se origina un
problema y no se prev este entonces el equipo se precipita en la accin con la finalidad
de corregir el problema rpidamente. Una estrategia considerablemente ms inteligente
para la gestin de riesgo es el prototipo. Una estrategia proactiva comenz mucho antes
de que se inicie el trabajo tcnico. Se identifican nuestros potenciales, se valoran su
probidad e impacto, y se clasifican segn su importancia. Luego, el equipo de software
establece un plan para gestionar el riesgo. El objetivo principal es evitar el riesgo, pero

debido a que no todos los riesgos pueden evitarse, el equipo trabaja para desarrollar un
plan de contingencia que le permite responder una forma controlada y efectiva.

El riesgo siempre tiene dos caractersticas:

Incertidumbre. El riesgo puede ocurrir.
Prdida. Si el riesgo se convierte en realidad.
Si los riesgos del proyecto se vuelven reales es probable que la calendarizacin del
proyecto se altere y que los costos o aumente. Los candidatos para los cinco mayores
riesgos de negocios son la construccin de un producto o sistema excelente que en
realidad nadie quiere, en la construccin de un producto que ya no se encaja en la
estrategia comercial, la construccin de un producto que la fuerza de ventas no sabe
cmo vender, la prdida del apoyo de los altos ejecutivos, la prdida presupuestal o de
personal asignado.

Es extremadamente importante destacar que la simple clasificacin de los riesgos no

siempre funciona. Algunos riesgos simplemente son imprevisibles. Los libros imprevisibles
son el comodn de la baraja, y de hecho ocurre, pero son extremadamente difciles de
identificar con antelacin.

La identificacin de los riesgos es un intento sistemtico encaminado especificar las

amenazas al plan del proyecto. A identificar los riesgos conocidos impredecibles, el gestor
de proyectos de un primer paso para evitarlos cuando es posible y a controlarlos cuando
es necesario.
Existen dos tipos de riesgos los genricos y los riesgos especficos. Los riesgos genricos
son una amenaza potencial para todo proyecto, los riesgos especficos los pueden
identificar slo aquellos con un claro conocimiento de la tecnologa, el personal y el
entorno especfico del software que se construir.

Un mtodo para identificar riesgos consiste en crear una lista de verificacin de riesgos y
encasillarlos en alguna subcategora genrica:
tamao del producto. Riesgos asociados con el tamao global del software.
Impacto en el negocio. Riesgos asociados con las restricciones que impone la gerencia
por mercado.

Caractersticas del cliente. Riesgos asociados con la sofisticacin del cliente y la habilidad
del desarrollador para comunicarse con l en una forma oportuna.
Definicin del proceso riesgos asociados con el grado en el que se ha definido el proceso
de software y en el que le da seguimiento a la organizacin que lo desarrolla.
Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las
herramientas que sucedan en la construccin del producto.
Tecnologa que construir: riesgos asociados con la complejidad del sistema que se
construir y la novedad de la tecnologa.
Tamao y experiencia de la plantilla de personal: riesgos asociados con la experiencia
global tcnica y en el proyecto de los ingenieros de software.
Para generar una lista es importante contestarse algunas de las siguientes preguntas.
1. Los altos ejecutivos de software y del cliente se han comprometido formalmente
para apoyar el proyecto.
2. Los usuarios finales estn comprometidos con el proyecto y el sistema producto
que se construir.
3. Los requisitos los han entendido completamente el equipo de ingeniera de
software y sus clientes.
4. Los clientes estuvieron completamente involucrados en la definicin de los
requisitos.
5. Los usuarios finales tienen expectativas realistas.
6. El mbito del proyecto es estable.
7. El equipo de ingeniera de software tiene la mezcla correcta de habilidades.
8. Los requisitos del proyecto son estables.
9. El equipo de proyecto tiene experiencia con la tecnologa que se implementar.
10. El nmero de personas en el equipo de proyecto es adecuado para realizar el
trabajo.
11. Todos los votantes del cliente usuario estn de acuerdo en la importancia del
proyecto y en los requisitos para el sistema producto que se construir.

Si la respuesta alguna de estas preguntas es negativa se deben instruir sin demorar los
pasos de produccin, supervisin y gestin.

Los componentes de riesgo se definen en la forma siguiente:

riesgo de desempeo. Grado de incertidumbre de qu productos satisfagan los requisitos
y se ajuste al uso que se pretende dar.
Riesgo de costo grado de incertidumbre de que se mantenga el presupuesto del proyecto.

Riesgo de soporte grado de incertidumbre el que software resultante ser fcil de corregir,
adaptar y mejorar.
Riesgo de calendarizacin. Grado de incertidumbre de que se mantenga la
calendarizacin del proyecto y de que el producto se entrega tiempo.
El impacto de cada controlador de riesgo sobre el componente de riesgo se divide en
cuatro categoras de impacto: despreciable, marginal, crtico o catastrfico.
La proyeccin de riesgo tambin llamada estimacin de riesgo, intenta clasificar cada
riesgo en dos formas la posibilidad o probabilidad de que el riesgo sea real y las
consecuencias de los problemas asociados con el riesgo, en caso de que ocurra.El
planificador del proyecto, junto con otros gestores y personal tcnico, realizan cuatro
pasos una proyeccin de riesgo:
Establecimiento de una escala que refleje la posibilidad recibida de un riesgo.
Delineado de las consecuencias del riesgo.
Estimacin del impacto de riesgo en el proyecto y el producto.
Tomar nota de la precisin global de la produccin del riesgo de modo que no haya malas
interpretaciones.
Al priorizar el riesgo los equipos pueden asignar los recursos donde tengan el mayor
impacto por esto es necesario priorizar los riesgos en base a los puntos anteriores.
Tres factores afectan la consecuencia que son probables y un riesgo ocurre: su
naturaleza, mbito y tiempo la naturaleza indica los problemas que son probables si
ocurre. El mbito combina la severidad con su distribucin global. Finalmente el tiempo de
un riesgo considera cuando y durante qu periodo se sentir el impacto.

Se recomienda los siguientes pasos para determinar las consecuencias globales de un

riesgo:
determinar el valor promedio de la probabilidad de que ocurra para cada componente de
riesgo.
Determinar el impacto para cada componente, con base en los criterios mostrados.
Completar la tabla de riesgo y analizar los resultados.
La exposicin globales, ER, se determina mediante la siguiente relacin ER = P x C
donde P es la probabilidad de que ocurran riesgo y se el costo del proyecto en caso de
que ocurra el riesgo.

Conforme pasa el tiempo y se aprende ms acerca del proyecto y riesgo, es posible

refinar de riesgo en un conjunto de riesgos ms detallados, todo uno un poco ms sencillo
de refinar, supervisar y gestionar.
El riesgo se puede establecer en la siguiente forma: dado que <condicin> entonces
existe la preocupacin de que posiblemente <consecuencia>.
Todas las actividades del anlisis de riesgo tienen una sola meta: ayudar al equipo de
proyecto a desarrollar una estrategia para luchar contra riesgo. Una estrategia eficaz debe
considerar tres temas.

Evitar el riesgo.
Supervisar el riesgo.
Gestionan de riesgo en los planes de contingencia.

Si un equipo de software adopt un enfoque proactivo hacia riesgo evitarlos siempre es la

mejor estrategia. sa se logra desarrollando un plan para reducir el riesgo.
En un proyecto grande es posible definir 30 o 40 riesgos. Si para cada uno se identifican
entre 3:07 pasos de gestin de riesgo, esta puede convertirse por s misma en un
proyecto. Por esta razn se adopta la regla 80-20 de parieto al riesgo de software. La
experiencia indica que 80% del riesgo del proyecto global puede explicarse slo un 20%
de los identificados. El trabajo realizado durante los primeros pasos del anlisis de riesgo
ayudar a planificador a determinar cules de los riesgos se encuentran en ese 20%. Por
esta razn, algunos de los riesgos identificados, evaluados y proyectados pueden no
incluirse en el plan RSGR, de que nos ubican en el 20%.
En el plan del proyecto de software se puede incluir una estrategia de gestin de riesgo o
los pasos de gestin de riesgo organizarse por separado en un plan de reduccin,
supervisin y gestin de riesgo. El plan RSGR documenta todo el trabajo realizado como
parte del anlisis de riesgo y el gestor del proyecto emplea como parte del plan global del
proyecto.
La supervisin de riesgos una tubera de seguimiento del proyecto con tres objetivos
principales: valorar si los riesgos predichos de hecho ocurre, asegurar que los pasos para
evitar el riesgo definidos para este se estn aplicando con propiedad; y recopilar
informacin que puede usarse en futuros anlisis de riesgo.

Gestin de la calidad.

Algunos desarrolladores de software continan creyendo que la calidad de este es algo en

lo que se debe comenzar a preocuparse slo despus de que se haya generado un
cdigo. La gestin de la calidad abarca un proceso de garanta de la calidad del software,
tareas especficas de aseguramiento y control de la calidad; prcticas efectivas de

ingeniera de software; control de todos los productos de trabajo del software y los
cambios que genera; un procedimiento para garantizar la concordancia con los
estndares de desarrollo de software, y mecanismos de medicin e informe.

El control de la variaciones y corazn del control de la calidad. De un proyecto a otro se

quiere minimizar la diferencia entre los recursos predichos necesarios para completar un
proyecto y los recursos reales utilizados, que incluyen personal, equipo y tiempo. No slo
se quiere minimizar el nmero de efectos que celebrarn, sino que quiere asegurar que la
varianza en el nmero de bugs tambin se minimiza de una liberacin a otra.
La calidad se refiere a caractersticas mesurables, es decir: cosas que se pueden
comparar para conocer estndares, como longitud, color humano propiedad y mi
debilidad. En el software se incluyen propiedades como complejidad psicosomtica,
cohesin, nmero de puntos de funcin, Ins de cdigo y muchas otras. Se pueden
encontrar dos tipos de calidad: calidad de diseo y calidad de concordancia.

La calidad del diseo se refiere a las caractersticas que los diseadores especifican para
un elemento. La calidad de concordancia es el grado en el que las especificaciones de
diseo se aplican durante la fabricacin.

Muchas veces es conveniente una relacin ms intuitiva:

Satisfaccin del usuario = producto manejable + buena calidad + entrega dentro del
presupuesto y tiempo.
La calidad de un producto es una funcin de cuanto cambia el mundo para mejorar. Esta
visin de la calidad del marqus un producto de software proporciona beneficio sustancial
a sus usuarios finales y estos estn dispuestos a tolerar problemas ocasionales en
confiabilidad y desempeo.
El control de calidad incluye un bucle de retroalimentacin con el proceso que cre el
producto del trabajo. La garanta de la caridad consiste en un conjunto de funciones de
auditora e informacin que evaluar la efectividad y quita completa son las actividades de
control de calidad. El costo de calidad incluye todos los costos que genera la bsqueda de
calidad o que demanda el desarrollo de las actividades relacionadas con la calidad.
La calidad de software se define como la concordancia con los requisitos funcionales y de
desempeo explcitamente establecido, estndares de desarrollo explcitamente
documentados y caractersticas implcitas que se esperan de cualquier software
desarrollado profesionalmente. Y resaltar tres puntos Importantes:
Los requisitos de software con la base de las medidas de la calidad.

Los estndares especificados definen un conjunto de criterios de desarrollo que guan la

forma en que esta se labora.
Con frecuencia no se menciona un conjunto de requisitos implcito.
La garanta de la calidad de software se compone de una variedad de tareas asociadas
con dos integrantes diferentes los ingenieros de software que realicen el trabajo tcnico y
un grupo de SQA que tiene la responsabilidad de planificar, supervisar, guardar registros,
analizar y reportar la garanta de calidad. SQA aborda la planificacin, supervisin,
conservacin de registros, anlisis y elaboracin informes de aseguramiento de calidad.
Preparar un plan de SQA para un proyecto. El plan se desarroll durante la planificacin
del proyecto y lo revisan todos los participantes. Las actividades de garanta de la calidad
del equipo de ingeniera del software y del grupo de SQA las rige el plan.
Participar en el desarrollo de la descripcin del proceso de software del proyecto. El
equipo de software selecciona un proceso para el trabajo que habr de realizarse. El
grupo de SQA revise la descripcin del proceso para que concuerda con las polticas
organizacionales, los estndares internos de software, los estndares impuestos de
manera externa por ejemplo ISO y otras partes del plan de proyecto de software.
Revisar las actividades de ingeniera de software para verificar que se ajuste al proceso
de software definido.
Audita productos de trabajo de software seleccionados para verificar que se ajustan con
los definidos como parte del proceso de software garantiza que las desviaciones en el
trabajo del software y en los productos de trabajo estn documentadas y se manejen de
acuerdo con el procedimiento establecido.
Registra cualquier falta de ajuste informal gestor ejecutivo.
El trabajo tcnico necesita revisarse por una razn que los lpices necesitan gomas. Errar
es humano. La segunda razn por la que se necesitan las revisiones tcnicas es que,
aunque la gente sea buena en captar algunos de sus propios errores, los grandes clases
de errores escapan de su creador con ms facilidad de lo que se escapan a alguien ms.
En la revisin tcnica formal (RTF) es el filtro ms efectivo desde un punto de vista de
seguramente de calidad. Dirigida por los ingenieros de software para ingenieros de
software, la RTF es un medio efectivo para descubrir errores y mejorar la calidad del
software.
El beneficio obvio de las revisiones tcnicas formales es el descubrimiento temprano de
los errores de modo que ya no se propaguen al paso siguiente en el proceso de software.
Las tcnicas de revisin formal han mostrado hasta 75% de efectividad al descubrir fallos
en el diseo. Al detectar y eliminar un gran porcentaje de dichos errores, el proceso de
revisin reduce sustancialmente el costo de las actividades subsecuentes en el proceso
de software.

Los objetivos de una RTF son descubrir errores en la funcin, lgica o implementacin en
cualquier representacin del software, verificar que el software en revisin satisface sus
requisitos; garantizar el software se ha presentado de acuerdo con los estndares pero
definidos; lograr software desarrollado en una manera uniforme; y hacer proyectos ms
manejables.
Sin importar el formato que se elija, cualquier junta de revisin debe atenerse a las
siguientes restricciones:
En la revisin se debe involucrar entre 3 a 5 personas.
Se debe preparar con anticipacin, pero sin que requiera ms de dos horas de trabajo de
cada persona.
La duracin de la junta de revisin debe ser menos de dos horas.
El enfoque de la RTF se dirige a un producto de trabajo por ejemplo una porcin de
cdigo. El individuo que ha desarrollado el producto en forma al jefe del proyecto que
productos se completo y que se requiere una revisin. El jefe de proyecto se pone en
contacto con el jefe de revisin en evaluar la disponibilidad del producto, genera copias
del material de producto y las distribuye a dos o tres revisores para que realicen sus
observaciones.

Al final, todos los asistentes a la RTF deben decidir si aceptan de productos y

modificaciones posteriores, rechazando producto debido a errores severos, o aceptan el
producto provisionalmente.

Al final de la junta se diera un informe resumen de la revisin tcnica formal. Un informe

resumen de la revisin responde tres preguntas: que se revis?; quien lo revis?;
cules fueron los hallazgos y conclusiones?.
La lista de problemas de la revisin completos propsitos: identificar reas de problema
en el producto y funcionar como lista de verificacin de elementos de accin que guan el
productor conforme se hacen las correcciones.
Una revisin descontrolada usualmente es peor que carecer de una. Las siguientes
representan un conjunto mnimo de directrices para las revisiones tcnicas formales:
Revisar el producto, no al productor.
Establecer una agenda y respetarla.
Limitar el debate y la impugnacin.

Enunciar reas de problemas, pero no se intente resolver todos los que se hayan
sealado.
Tomar notas.
Lmite al nmero de participantes de insistir en la preparacin anticipada.
Desarrollar una lista de verificacin para cada producto que tenga probabilidad de ser
revisado.
Asignar recursos y programar las RTF.
Realizar un entrenamiento significativo de todos los revisores.
Analizar las revisiones previas.
Las inspecciones RTF slo son vistas como eficientes y se encuentran muchas fallas
durante su bsqueda. Si, por otra parte, slo se encuentran pocas fallas, la expresin ha
sido una prdida de tiempo para muchas personas involucradas en la tarea. Ms an, los
proyectos de software que estn atrasados con frecuencia disminuyen el tiempo de las
actividades de inspeccin, lo que conduce una falta de calidad. Una solucin sera asignar
jerarquas a los recursos para las actividades de inspeccin y en consecuencia,
concentrar los recursos disponibles en los artefactos ms proclives a las fallas.

Para ser eficaz que sugieren los siguientes pasos:

Inspeccionar una fraccin de cada producto del trabajo de software.
Desarrollaron estimacin brutal del nmero de fallas dentro del producto de trabajo al
multiplicar el nmero de fallas por uno entre la fraccin.

Ordenar los frutos de trabajo en forma descendente de acuerdo con las estimacin bruta
del nmero de fallas en cada uno.
Enfocar los recursos de revisin disponibles en aquellos productos de trabajo con el
mayor nmero estimado de fallas.
La fraccin con la que se ha hecho un muestreo debe ser representativa de producto del
trabajo como un todo, y se lo suficientemente grande de tal manera que sea significativa
para los revisores que realicen en nuestro.
La garanta de la calidad estadstica implica los siguientes pasos:

La informacin acerca de los defectos de software cero compile clasificar.

Se intenta determinar las causas subyacentes de cada efecto.
Mediante el principio de Pareto se asla un 20%.

Una vez que las causas vitales han sido identificadas, se corrigen los problemas
que han provocado los defectos.

Seis Sigma es la estrategia ms ampliamente empleada en la actualidad para

aseguramiento de calidad estadstico en la industria. Utiliza anlisis de datos y estadstico
para medir y mejorar el desempeo operativo de la compaa al identificar y eliminar los
defectos en la fabricacin y procesos relacionados con el servicio.La metodologa seis
Sigma define traspasos centrales:

Definir los requisitos del cliente, entraables y metas del proyecto por medio de
mtodos bien definidos de comunicacin con el cliente.
Medir el proceso existente y su salida para determinar el desempeo de calidad.
Analizar las mtricas de defecto y determinar las causas poco vitales.

Si un proceso de software existente est en marcha, pero se requiere mejora, seis Sigma
sugiere dos pasos adicionales:

Mejorar el proceso eliminando las causas originales de los defectos.

Controlar el proceso para garantizar el trabajo futuro no vuelva a introducir las
causas de defecto.

Se est desarrollando un proceso de software los pasos aumentan de la siguiente

manera:

Disear el proceso para evitar las causas originales de los defectos y satisface los
requisitos del cliente.
Verificar el modelo de proceso, de hecho, gritaron los defectos y satisfagan los
requisitos del cliente.

En el contexto de cualquier anlisis de calidad y fiabilidad del software, la falla es la falta

de concordancia con los requisitos del shock. Las fallas slo pueden ser molestas y
catastrficas. Una falla puede corregirse en segundos, mientras que otra tal vez requiere
semanas o incluso meses.
Si se considera un sistema basado en computadora, una simple medio de fiabilidad ese
tiempo medio entre fallas (TMEF) donde TMEF = TMDF + TMDR
las siglas TMDF y TMDR significan tiempo medio de falla y tiempo medio de reparacin,
respectivamente.

Adems una media de fiabilidad, se debe desarrollar una medida de disponibilidad. La

disponibilidad del software es una probabilidad de que un programa opere de acuerdo con
los requisitos en un punto dado del tiempo y se define como

Disponibilidad = [TMDF /(TMDF + TMDR) ] X 100%

la medida de fiabilidad TMEF igualmente sensible a TMDF y TMDR. La medida de
disponibilidad es un poco ms sensible a TMDR, y es una medida indirecta de la facilidad
de mantenimiento del software.
La seguridad del software es una actividad de aseguramiento de calidad del software que
se enfoca en la identificacin y evaluacin de los peligros potencial que pueden afectar
negativamente al software y provocar una falla todo el sistema.
Como parte de la seguridad del software se llevan a cabo procesos de modelado y
anlisis. Una vez identificados estos peligros en el nivel del sistema, mediante tcnicas de
anlisis asigna seguridad y por la recurrencia. Las tcnicas de anlisis, como el anlisis
del rbol de falla, la lgica de tiempo real o los modelos de red de Petri, se emplean para
predecir la cadena de eventos que pueden provocar peligros y la probidad de que cada
uno de los eventos ocurrir para crear la cadena.
La confiabilidad del software utiliza anlisis estadsticos para determinar la teora de que
ocurra una falla del software. La seguridad del software examinan las formas en las
cuales las fallas resultan en condiciones que pueden conducir a un percance. Esto es, las
fallas no son consideradas en el vaco, sino que se vuelvan en el contexto de todo un
sistema basado en una computadora y en su entorno.

Gestin del cambio.

La gestin del cambio, ms usualmente llamada gestin de la configuracin de software,

es una actividad protectora que se aplica a lo largo del proceso de software. Puesto que
cambio puede ocurrir en cualquier momento las actividades de GCS se desarrollan para
identificar el cambio, controlar el cambio, garantizar que el cambio se implementar de
manera adecuada, y reportar los cambios a otros que pudieran estar interesados.

La salida del proceso de software es informacin que puede dividir en tres amplias
categoras: programas de computadora; productos de trabajo que describen los
programas de computadora, y datos. Los elementos que comprende la informacin
producida como parte del proceso de software se denominan colectivamente
configuracin de software.
Existen cuatro fuentes fundamentales de cambio:

Nuevas condiciones en el negocio mercado dictan los cambios en los requisitos

del producto o las reglas del negocio.
Nuevas necesidades del cliente demanda la modificacin de los datos que
producen los sistemas de informacin, de la funcionalidad entregan los productos
o los servicios que entregan un sistema basado en computadora.
La reorganizacin o el crecimiento o reduccin de negocios provocan cambios en
las prioridades del proyecto o en la estructura del equipo de ingeniera del
software.
Restricciones presupuestales o de calendarizacin inducen una redefinicin del
sistema o producto.

Dado que el producto controla la GC, eficientes y procedimientos formales para sus
intercambios indicar los blogs en el producto.
Idealmente, un sistema de GC utilizando en este escenario podra todas las funciones y
tareas esto es las funciones determinan la funcionalidad requerida de un sistema de GC.
El gestor del proyecto de una GC como mecanismo de auditora; el gestor de
configuracin, como un mecanismo de creacin de control, seguimiento y polticas; el
ingeniero de software, como mecanismo de control de cambio, la construccin y el
acceso; y el usuario, como mecanismo de garanta de la calidad.
Existen cuatro importantes elementos que deben estar presentes con ese desarrollo un
sistema de gestin de la configuracin:

Elementos de componentes: conjunto de herramientas acopladas dentro de un

sistema de gestin de archivos que permite el acceso y la gestin de cada
elemento de configuracin del software.
Elementos de proceso: serie de procedimientos y tareas que definen un enfoque
eficaz en el cual gestionar el cambio para todos los participantes en la gestin,
ingeniera y utilizacin de software de computadora.
Elementos de construccin: conjunto de herramientas que automatizan la
construccin del software para asegurar que se han ensamblado un conjunto
adecuado de componentes vlidos.
Elementos humanos: la implementacin de una GCS eficaz requiere el equipo de
software utilice un conjunto de herramientas y caractersticas de procesos.

Una lnea base es un concepto de gestin de la configuracin del software que ayuda a
controlar el cambio sin pedir seriamente el cambio justificable. Una especificacin o
producto que sea revisado formalmente y se est de acuerdo con los resultados, y que a
partir de ah sirve como la base para el desarrollo ulterior y que puede cambiarse slo por
medio de procedimientos formales de control de cambio.
En el contexto de la ingeniera de software, una lnea base es un hito en el desarrollo del
software. Se marca una lnea base para la entrega de uno o ms elementos de
configuracin del software que se han aprobado como consecuencia de una revisin
tcnica formal.

El elemento de comprensin del software es informacin que se crean como parte del
proceso de ingeniera de software. En el extremo, se puede considerar que un ECS es
una sola seccin de una gran especificacin o en caso de prueba de un gran conjunto de
pruebas.
Los ECS estn organizados para formar objetos de configuracin susceptibles de
catalogar en la base de datos del proyecto con un solo nombre. No objeto de
configuracin tiene un nombre, atributos y est conectado con otros objetos por medio de
relaciones.
El depsito de ECS es el conjunto de mecanismos y estructuras de datos que permite que
un equipo de software maneje el cambio en una forma eficaz. El depsito proporciona las
funciones obvias de un sistema de gestin de base de datos pero, adems, el depsito
realizado impulsa las siguientes funciones:
La integridad de los datos.
El compartir informacin.
La integracin de herramientas.
La integracin de los datos.
El fortalecimiento de la metodologa.
Estandarizacin de los documentos.

Las caractersticas el contenido del depsito se comprenden mejor si se les observa

desde dos perspectivas: que se guardar en el depsito y qu servicios especficos ofrece
este.Un depsito robusto proporcionados clases diferentes de servicios: los mismos tipos
de servicios que se pueden esperar de cualquier sistemas sofisticados de gestin de
bases de datos y servicios especficos del entorno de la ingeniera del software.
Un depsito que atienda a un equipo de ingeniera de software debe integrarse con o
directamente apoyar las funciones de gestin de proceso; apoyar las reglas especficas
que rigen la funcin de GCS y los datos conservados dentro del depsito; ofrecer una
interfaz a otras herramientas de ingeniera de software; y acomodar el almacenamiento de
datos sofisticados.

El apoyo a la GCS requiere que el almacn o depsito tenga un conjunto de herramientas

que fortalezcan el soporte para las siguientes caractersticas:
Versiones el depsito debe ser capaz de guardar todas estas versiones para permitir la
gestin eficaz.

Gestin del seguimiento de la dependencia del cambio. El depsito gestiona una amplia
variedad de relaciones entre los objetos de configuracin que guarda.
Seguimiento de requisitos. Esta funcin especial ofrece la habilidad de seguir todos los
componentes y entraables de diseo y construccin que resulten de una determinacin
especfica de requisitos.
Gestin de la configuracin. Una gestin de la configuracin facilitada conservacin del
resto de una serie de configuraciones que representan hitos especficos de proyecto o
liberaciones de produccin.
Rutas de auditora. Una ruta de auditora gestores informacin adicional acerca de
cundo, porque y por quien se hicieron los cambios.
El proceso de gestin de la configuracin de software define una serie de tareas que tiene
cuatro objetivos principales identificar dos elementos que colectivamente definen la
configuracin del software; gestionar los cambios a uno o ms de dichos elementos;
facilitar la construccin de diferentes versiones de una aplicacin; y garantizar que la
calidad de software se conserva conforme la configuracin evoluciona a lo largo del
tiempo.

Un proceso que lograr estos objetivos no necesita ser burocrtica y molesto, pero s debe
caracterizarse en una forma que permita que un equipo de software desarroll respuestas
a un conjunto de preguntas complejas:

Como identifica un equipo de software los elementos discretos de una

configuracin de software.
Cmo gestiona una organizacin las numerosas versiones existentes de un
programa en una forma que permita que el cambio se acomode eficientemente.
Como controla una alcoholizacin los cambios antes y despus de que el software
se libere eficiente.
Quien tiene la responsabilidad de aprobar clasificar los cambios.
Como se garantiza que los cambios se han realizado adecuadamente.
Con qu mecanismos se valoran otros cambios que se realizan.

Las tareas de la GCS se definen como identificacin, control de la presin, control del
cambio, auditora de la configuracin e informe.
El control y la gestin de elementos de configuracin de software requiere nombrar cada
uno por separado y luego organizarlo mediante un enfoque orientado a objetos. Es
posible identificar dos tipos de objetos bsicos segregados. Un objeto bsico es 1 U de
informacin creada por un ingeniero de software durante el anlisis, diseo, el cdigo o
las pruebas. Un objeto agregado es una coleccin de objetos bsicos y otros objetos

agregados. El control de la versin combina procedimientos herramientas para gestionar

diferentes versiones de objetos de configuracin que se crean durante proceso de
software. Un sistema de control de la versin implementa agostar directamente integrado
un cuento grandes capacidades una base de datos del proyecto que guarda todos los
objetos del configuracin relevantes; una capacidad de gestin de la versin que
almacenar todas las versiones del objeto de configuracin; una facilidad de hechura que
permite al ingeniero de software recopilar todos los objetos de configuracin relevantes y
construir una versin especfica del software.
Es un mecanismo de control de la versin, integrados en el proceso de control de
cambios, implementndose portales elementos de gestin del cambio: control del acceso
y la sincronizacin. El control del acceso rige que ingenieros de software sean autorizados
para ingresar y modificaron objetos de configuracin particular. El control de sentir la
sincronizacin ayuda a garantizar que los cambios paralelos, efectuados por dos
personas diferentes, no se sobrescribirn sobre otro.

La identificacin, el control de la versin y el control de cambio ayudan al desarrollo del

software a mantener el orden en lo que de otro modo sera una situacin catica o
inestable. Cmo se puede garantizar que el cambio sea implementado con propiedad?
La respuesta es doble: revisiones tcnicas formales y auditorio de la configuracin del
software.

La revisin tcnica formal se enfoca en la correccin tcnica del objeto de configuracin

que sea modificado. Una auditora de configuracin de software complementa la revisin
tcnica formal al abordar las siguientes preguntas:
Se ha realizado el cambio especificado en laOCI?
Se ha realizado la revisin tcnica formal para evaluar la correccin tcnica?
Se ha seguido el proceso de software?Se han aplicado adecuadamente los estndares
de ingeniera de software?
El cambio sea resaltado en el ECS?Se han especificado la fecha y el autor del cambio?
Los atributos del objeto de configuracin reflejan el cambio?
Se han seguido los procedimientos de GCS para destacar el cambio, registrarlo e
informar de l?
Todos los ECS relacionados se han actualizado de manera adecuada?

El informe Estado de la configuracin es una tarea deGCS corresponde las siguientes

preguntas qu ocurri?, Quin lo hizo?, Cuando ocurri?, Qu otra cosa ser
afectada?
Conforme las Webapps se vuelven cada vez ms importante para la sobrevivencia y el
crecimiento de los negocios, crece la necesidad de la gestin de la configuracin. Porque
sin controles eficaces los cambios inadecuados conduciran a la difusin no autorizada de
informacin de un nuevo producto; funcionalidad errnea o pobremente probada que
frustra a los visitantes un sitio web, hoyos en la seguridad que ponen en peligro los
sistemas internos de la compaa; y otras consecuencias econmicamente desagradables
o incluso desastrosas.
Se deben considerar cuatro temas conoce desarrollan tcticas para la gestin de la
configuracin de la webapp: contenido, personal, escalabilidad y polticas.

La gestin del contenido se relaciona con la gestin de la configuracin en el sentido en

que un sistema de gestin de contenido establece un proceso que quiere contenido
existente, los estructura en una forma que permite presentarlos al usuario final y luego
nos ofrece el entorno de la del cliente para su despliegue.
El uso ms comn de sistema de gestin del contenido ocurre cuando se construy una
webapp dinmica. En el sentido ms general, un SGC configura contenido para refinar al
invocarle sus sistemas integrados de conexin, de gestin y de publicacin el subsistema
de coleccin abarca todas las acciones que se requieren para crear y adquirir contenido.
El subsistema de gestin guarda en un depsito y cataloga para adquisicin y uso
subsecuente el estado actual, la versin la propiedad del objeto de contenido, y los
objetos de contenido relacionados. El subsistema de publicacin extrae el contenido del
depsito y lo convierte en una forma que est dispuesta para su publicacin informativo
de modo que sea posible transmitirlo a los navegadores del cliente.

La implementacin de la gestin de cambio en el desarrollo de la webapp se debe

clasificar en una de cuatro clases:

Un cambio de contenido funcin que corrija un error o mejore contenido o

funcionalidad local.
Un cambio de contenido funcin que tenga impacto sobre otros objetos de
contenido o componentes funcionales.
Un cambio de contenido funcin que tengan impacto a travs de una webapp.
Un gran cambio de diseo que inmediatamente apreciarn una o ms categoras
usuarios.

Para habitar el sobrescribir versiones sobre el mismo componente se establece un

proceso de control de la versin.
Se debe establecer un depsito central para el proyecto webapp.
Cada ingeniero crea su propia carpeta de trabajo.
Los relojes en las estaciones de trabajo de todos los desarrolladores deben estar
sincronizados.
Conforme se desarrollan nuevos objetos de configuracin o se cambian los objetos
existentes se importan en depsitos entrar.
Conforme los objetos importan al o exportan del depsito se elabora un mensaje
automtico de registro cronometrado.

CONCLUSIONES.
Dentro de la gestin de proyectos es muy indispensable tener en cuenta las tareas de
calendarizacin, gestin del riesgo, gestin de la calidad y gestin del cambio. La
calendarizacin de nuestro proyecto debe reflejar los tiempos que se necesitan para el
desarrollo de este y los problemas principales que siempre nos encontramos en esto es
que regularmente las fechas son impuestas por lo que debemos de tener una gestin
hacia el cliente para poder manejar estas fechas o de lo contrario expone claramente las
alternativas que se pueden implementar para llegar a esas fechas. Se debe especificar en
la calendarizacin todas las tareas involucradas y sus dependencias as como la duracin
de cada una de estas para que al final tengamos claro cunto tiempo y contemplacin se
necesita para el proyecto con esto el gestor del proyecto puede dar seguimiento y
controlar cada uno de estas tareas.
Es muy importante considerar la gestin de riesgo de que si logramos identificar los
riesgos de manera temprana podemos mitigar estos con un costo menor que si se
identifican posterior a la implementacin del desarrollo, regularmente son pocos los
gestores que hacen hincapi en la gestin de riesgo ya que el tiempo en identificarlo es
considerable y muchas veces por las fechas implantadas se omite este paso sin embargo

al hacer esto y cuando se entrega el producto final y se detectan errores que se pudieron
prever en la tapa del anlisis de riesgos se identifica que el costo incrementa ya que
identificar estos riesgos posteriores a la implementacin es ms costoso y difcil.
La gestin de la calidad est relacionada con la revisin de sobres que son las actividades
ms importantes ya que aqu se deben de considerar las polticas los estndares que se
debe de llevar en el desarrollo y est se debe de estar dando dentro de todas las etapas
del desarrollo para poder asegurar el cumplimiento de la calidad del producto.

La gestin del cambio control ayudita las modificaciones que pueden ocurrir durante el
desarrollo del software y an despus de haberlo liberado y conlleva toda la
documentacin necesaria para esto as como controlar las versiones de cada uno de
estos documentos o componentes que estn interrelacionados que suelen llamarse
elementos de configuracin de software todo esto guardado en un depsito.