Beruflich Dokumente
Kultur Dokumente
24-27
Nombre:
Matrcula:
16103300494
Identificacin de Materia:
Calidad de Software
Fecha:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
Evitar el riesgo.
Supervisar el riesgo.
Gestionan de riesgo en los planes de contingencia.
Gestin de la calidad.
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.
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.
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.
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.
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:
Una vez que las causas vitales han sido identificadas, se corrigen los problemas
que han provocado los defectos.
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:
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.
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:
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:
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.
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:
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
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.