Desarrollo de software en equipo TSPUnidad 2. Actividad 2. Plan de proyectoUnidad 1. La libertad: facultad inherente a todo ser humano

Plan de proyecto

Unidad 2

Actividad 2

En esta actividad generars el plan del proyecto con base en un problema planteado por tu Facilitador(a). Realiza los siguientes pasos:La empresa Eurocan S.A. de C.V requiere de un sistema que administre sus ventas diarias as como poder saber qu productos hacen falta de acuerdo a lo que se vaya vendiendo.El sistema debe de ser capaz de permitir al administrador dar de alta sus productos y obtener reportes de ventas diarias, semanales y por mes.

Identifica en el problema planteado por el (la) Facilitador(a) los elementos del plan del proyecto.En base al problema anterior integra hipotticamente un plan de calidad y un plan de riesgos. De conformidad con los temas abordados en la presente unidad.Plan de Calidad1. Qu tipo de defectos se introdujeron durante el diseo y la codificacin?En la fase de diseo los defectos ms introducidos fueron los de tipo 70 y 80, pues ambos ocurrieron con una frecuencia de 4 y porcentaje de 33.3%, como se muestra en la tabla de abajo. Asimismo los defectos de tipo 20 fueron los que tuvieron la mayor ocurrencia en la fase de codificacin con una ocurrencia de 30 y un porcentaje de 52.6% como se puede observar en la siguiente tabla:Nmero InyectadoPorcentaje Inyectado

TipoDiseoCdigoDiseoCdigo

10010.0%1.8%

2023016.7%52.6%

30030.0%5.3%

40128.3%3.5%

50128.3%3.5%

60000.0%0.0%

704933.3%15.8%

804633.3%10.5%

90040.0%7.0%

100000.0%0.0%

Total1257

Tabla. Defectos introducidos en las fases de diseo y codificacinEl nmero de defectos introducidos en la fase de diseo fueron doce, como se indica en la tabla anterior. En un nmero aceptable de errores de diseo pues son los ms costosos en tiempo, tanto para encontrarlos como para corregirlos. A diferencia de la fase de codificacin, los defectos de tipo 20 no figuraron entre los ms comunes; tal como se muestra en la siguiente tabla.TipoNmero InyectadoPorcentaje Inyectado

1000.0%

20216.7%

3000.0%

4018.3%

5018.3%

6000.0%

9000.0%

10000.0%

Tabla. Defectos menos introducidos en la fase de diseoEn la fase de codificacin, el nmero de errores fue mucho mayor en comparacin con la de diseo. Los errores ms comunes fueron de tipo 20, con 30 ocurrencias y un porcentaje de 52.6%.Es necesario hacer una clasificacin de errores ms comunes tanto en la fase de diseo como en la de codificacin. Vale la pena tener una clasificacin de stos, pues ocurrieron por distintos motivos.TipoClasificacin del defectoNmero de defectos introducidos

71Mal clculo de la funcin2

72Error de parmetros2

Total4

Tabla. Clasificacin de los errores tipo 70 introducidos en la fase de diseo

TipoClasificacin del defectoNmero de defectos introducidos

81Mal funcionamiento3

82Recodificacin1

Total4

Tabla. Clasificacin de los errores tipo 80 introducidos en la fase de diseo

TipoClasificacin del defectoNmero de defectos introducidos

21Error de dedo18

22Inicializacin de variables5

23Tipo de dato incompatible6

24Error de parmetros1

Total30

Tabla. Clasificacin de los errores tipo 20 introducidos en la fase de codificacin

2. Qu tendencias son evidentes en defectos/KLOC encontradas en las revisiones, en la compilacin y en las pruebas?

Grficas de defectos eliminados durante las revisiones de diseo y codificacin

En la grfica anterior se muestra la tendencia a dejar pasar cada vez menos defectos a las fases posteriores; esto ayud a que los programas se hicieran con mayor calidad. En las fases de compilacin y pruebas se observaron cada vez menos errores, situacin favorable originada por la intervencin de las revisiones de diseo y codificacin, donde ms errores se encontraron.

Grficos de defectos eliminados en las fases de compilacin y pruebas3. Qu tendencias son evidentes en el total de defectos/KLOC? El nmero de errores en la primera mitad del curso fue muy elevado, como se observa en la grfica anterior; pero cuando se introdujeron las revisiones de diseo y cdigo, el nmero de errores baj considerablemente. La tendencia que se advierte es que, si se integraran revisiones personales adicionales (checklist) que permitan tener un menor nmero de defectos, se obtendra una mayor calidad en los programas.

Grfica del total de defectos por programa y por KLOC4. Cmo se comparan las tasas de defectos removidos (en defectos eliminados/KLOC) con la revisin de diseo, la revisin de cdigo, la compilacin y las pruebas? En la primera mitad del curso todos los errores eran captados por las fases de compilacin y pruebas; pero en la segunda mitad, ya introducidas las revisiones de diseo y cdigo, se redujo el nmero de errores que llegaba a compilacin y pruebas. Esto se nota claramente en la siguiente tabla. Si se hubieran realizado estas revisiones desde el inicio, las revisiones de diseo y cdigo tendran la mayor tasa de defectos eliminados.FaseNmero de defectos eliminadosTasa de defectos eliminados (%)

DLDR57.0%

CR1115.5%

Compile3143.7%

Test2433.8%

Total71100%

Tabla. Tasa de defectos eliminados en las fases de revisin de diseo, revisin de cdigo, codificacin y pruebas5. Cules son las influencias de defectos removidos por revisin de diseo, revisin de cdigo y compilacin contra pruebas unitarias? Las pruebas unitarias se realizan despus de las revisiones de diseo, cdigo, y de la fase de compilacin; por lo tanto el nmero de defectos encontrados y eliminados en esta fase es mucho menor que en las anteriores. 6. Cules son las tasas de revisin (en LOC revisadas/hora) para revisiones de diseo y de cdigo? En la siguiente figura se muestra la tendencia a aumentar las LOC revisadas por hora, tanto en la revisin de diseo como en la de cdigo.

LOC revisadas por hora en revisiones de diseo de cdigoEn la siguiente tabla se muestran las tasas de revisin para diseo y cdigo. En las revisiones por separado, la tasa est en un promedio de 261 LOC revisadas por hora; para diseo, cdigo 267 LOC por hora; pero tomndolas juntas se cuenta con una revisin promedio de 130 LOC revisadas por hora.ProgramaTasa de revisin de diseo (LOC revisadas/hora)Tasa de revisin de cdigo (LOC revisadas/hora)Tasa para ambas revisiones (LOC revisadas/hora)

7231.4237.1113.7

8246246117.1

9230235.9115.3

10335.4346.8170.5

Tabla. Tasa de revisin (en LOC revisadas por/hora para revisiones de diseo y cdigo)

7. Hay una relacin entre el yield y el A/FR para los programas del siete al diez?La relacin que hay entre el yield y el A/FR de las tareas en la segunda parte del curso estuvieron muy relacionadas. En la grfica siguiente se puede observar que cuando el AF/R aumentaba, tambin lo hacia el yield, y viceversa.

Grficas de yield y AF/R de las tareas 7A a la 10AEn la grfica anterior se observa que el yield siempre crece, a excepcin de la tarea nueve. El promedio del yield para la segunda mitad del curso fue de 76.785%, esto indica que una gran parte de los defectos se eliminaron antes de llegar a la fase de desarrollo. El AF/R de la grfica representa una tendencia creciente, eso significa que como los valores de A/FR siempre fueron mayores a uno, el tiempo dedicado a las revisiones tanto de diseo como de cdigo fue mayor que los tiempos de compilacin y pruebas. 8. Cmo se puede hacer el proceso ms efectivo y eficiente? Es necesario realizar pruebas de escritorio despus de la fase de revisin de diseo para eliminar los errores de pruebas que se pudieran introducir. El tiempo en el diseo aumentara, pero eso beneficiara al tiempo de pruebas y calidad del programa. 9. Basados en los datos histricos Cules son los objetivos de calidad? Obtener una tasa menor que 20 defectos/KLOC. Reducir el nmero de los errores ms comunes. Alcanzar un yield promedio del 85%.

10. Cmo se puede cambiar el proceso para llegar a esos objetivos? Para mejorar la tasa de defectos, que en estos momentos es de 29 defectos/KLOC, es necesario dedicar ms tiempo a entender los requerimientos del programa, pues stos han presentado los ms difciles de resolver. Para reducir el nmero de defectos comunes es necesario agregar validaciones al checklist y dedicar ms tiempo a su aplicacin, pues por realizarlo rpido no se eliminaron defectos detectables. El yield actual es de 76.785%, para alcanzar 85% es necesario usar con ms eficiencia el estndar de diseo; parte de esto conlleva el incluir documentacin entre el cdigo con el fin de que pueda interpretarse fcilmente. Para lograr los objetivos es necesario integrar nuevos checklist que permitan reducir errores y tiempos.

Plan de RiesgoEl plan de riesgo TSP contempla cinco directrices bsicas:Aprender de los errores del pasado

La gran mayora de los riesgos son conocidos; son pocos los errores nuevos que se llegan a presentar. Al conocer los problemas ms comunes de los proyectos pasados, los equipos pueden determinar los problemas ms comunes que se pueden presentar en los proyectos futuros.

Todos los equipos deben gestionar los riesgosLos participantes del proyecto conocen mejor los riesgos, por esta razn los equipos de trabajo pueden anticipar de una manera ms fcil los problemas y solucionarlos cuando an sea posible.

Empoderar a los miembros del equipo para gestionar los riesgosLos participantes que estn directamente relacionados con el plan de riesgos deben de ser tratados como si fueran parte de la gestin del sistema; esto ayudar a tener una mejor cooperacin y participacin. Empoderar a los miembros del equipo es darles cierta responsabilidad para que tomen las decisiones adecuadas, y as dar seguimiento y solucin a un riesgo. Pero esto slo se har con personas que estn involucradas en el desarrollo del proyecto.

A cada riesgo significativo se debe asignar un propietarioCuando se identifica un riesgo significativo, tiene que asignarse a un responsable, con esto se lograr que la cobertura sea la ms adecuada y que, al darle seguimiento, se tomen las medidas necesarias para mitigar, corregir el riesgo y evitar futuros problemas. A manera de ejemplo, si se encontr un riesgo relacionado con el entorno de desarrollo y programacin, el responsable de darle seguimiento ser el programador.

Revisar peridicamente los riesgosDebe llevarse a cabo despus de que el equipo identific los riesgos de ms importancia, para as darles el seguimiento adecuado y asignar al responsable que se encargara de hacer una revisin peridica junto con el equipo; esto depender de la importancia del riesgo y sus consecuencias.

Para la administracin de los riesgos llevamos a cabo las siguientes acciones:1. Identificar los riesgos.2. Analizar los riesgos.3. Elaborar planes de contingencia.4. Controlar el estado de los riesgos.5. Analizar los resultados y aprender de ellos.Identificar los riesgosEn la identificacin de los riesgos se recuperaron todas las inquietudes y preocupaciones que estaban ligadas con la elaboracin del proyecto. Para ello, los miembros del equipo trabajaron en conjunto mediante reuniones en las que se gener una lluvia de ideas; cada participante expuso los posibles riesgos que consideraba podan presentarse durante el desarrollo del proyecto. A continuacin, se muestra una tabla de identificacin de riesgos del sistema en web en la que se evala la seguridad.IDTipoDescripcin del riesgoPosibles consecuencias

InternoExterno

R18MSXAtaques contra contraseas de usuariosPrdida de acceso a informacin

R19MSXDes encriptacin de informacinCopia de datos

R20MSXVulnerabilidad del antivirusInestabilidad en el servicio

R21MSXVulnerabilidad en los puertosPrdida de servicios

R22MSXAtaques de SQL a la base de datosPrdida de consistencia

R23MSXVulnerabilidad en el firewallsContaminacin por virus informticos

R24MSXVulnerabilidad en el servidorRobo de informacin

R25MSXRobo de conexin Wi-FiPrdida de calidad en el servidor

R26MSXVulnerabilidad de certificados digitalesPrdida de datos

R27MSXVulnerabilidad de cach ARP (Address Resolution Protocol)Retraso de servicios

Tabla. Identificacin de riesgos* ID: Clave con la que se identificar el riesgo en las siguientes tablas para su control y seguimiento. Tipo: Debe ser evaluado y clasificado por los involucrados en el desarrollo del proyecto. Puede sr interno o externo, dependiendo el rea de afectacin que pueda provocar el riesgo Descripcin del riesgo: Se explican a detalle sus caractersticas. Posibles consecuencias: Se describe la forma en que puede afectar al proyecto.

Analizar los riesgosCuando tuvimos identificados los riesgos, realizamos un anlisis cualitativo en el que priorizamos los ms significativos con base en lo siguiente: Probabilidad: puede ser 1 a 100 porcentual, que es el grado de probabilidad de que ocurra. Impacto: efecto que tendr el riesgo si se llegara a presentar.Para clasificar los eventos y la magnitud utilizamos la escala del uno a cien porcentual; pero para realizar el clculo utilizamos 0.10 cuando el riesgo era de bajo impacto, y 1.0 cuando fue de mayor impacto. Tomamos en cuenta que si el valor es de 90%, ser 0.90 para realizar la operacin. La magnitud la obtuvimos al multiplicar la probabilidad por el impacto del riesgo en el proyecto.0.50 x 0.90 = 0.45Finalmente, para representar el resultado obtenido utilizamos una matriz cualitativa del riesgo que contiene la probabilidad y la magnitud del impacto, la cual presentamos a continuacin.ImpactoEscala de prioridad de eventos de riesgo

Probabilidad0,100.350.500.801.00 Riesgo bajo Riesgo Medio Riesgo Alto

0.900.090.320.450.720.90

0.700.070.250.350.560.70

0.500.050.180.250.400.50

0.300.030.110.150.240.30

0.100.010.040.050.080.10

Tabla. Matriz cualitativa de riesgoEn la siguiente tabla se muestra nuestro anlisis de riesgo.IDAnlisis del riesgo

18MSMagnitud:AltaDescripcin:Las cuentas de usuarios pertenecientes a un sistema Microsoft Windows estn guardadas en pares de datos; es decir, hacen referencia a sus respectivas contraseas.Impacto:En la seguridad. Otras personas podran adquirir los privilegios de administrador y cambiar ciertas funciones.Estrategia para tratar el riesgo:Establecer mtodos de autentificacin como: NTLM y SSOKerberos.

Tabla. Anlisis del riesgo y estrategiasElaborar planes de contingencia Conjunto de procedimientos alternativos a la operativa normal de cada empresa, cuya finalidad es permitir su funcionamiento, aun cuando alguna de sus funciones deje de operar por culpa de algn incidente tanto interno como ajeno a la organizacin. Se elaboraron con la finalidad de disminuir riesgos; contienen recomendaciones para reducir las amenazas e incrementar las oportunidades dentro de los objetivos del proyecto. Controlar el estado de los riesgos Dentro del control de los riesgos se implementaron planes de respuesta contra los que se identificaron. Analizar los resultados y aprender de ellos

Redacta tus conclusiones acerca de los elementos que integran el plan del proyecto; identifica cules son los riesgos que podran afectar el desarrollo.

Conclusin: Los resultados de las observaciones en proyecto pasados nos sirvieron para aprender de stos y as estimar y prever la presencia de los riesgos. Para llevar un anlisis y gestin tuvimos que generar una matriz de riesgos, la cual se aplicar en las reuniones con los participantes en el desarrollo del proyecto, y as dar el seguimiento necesario. La utilizacin de un plan de riesgos es muy importante porque ayuda al equipo a identificar los riesgos potenciales dentro del proyecto. En la mayora de los casos pueden ser evitados, lo que reduce problemas en el proyecto.

Guarda la actividad con el nombre DDSE_U2_A2_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido.Enva la actividad a tu Facilitador(a) mediante la herramienta Tareas.* No olvides consultar el documento Criterios de evaluacin de actividades U2 donde podrs conocer los parmetros de evaluacin de esta actividad.

14NOMBRE: Roberto lvarez GranadosMATRCULA: AL12501836CARRERA: Ingeniera en Desarrollo de Software