Ddse U2 A2 Roag

NOMBRE: Roberto lvarez Granados
MATRCULA: AL12501836
CARRERA: Ingeniera en Desarrollo de Software
1
Desarrollo de software en equipo TSP
Unidad 2. Actividad 2. Plan de proyecto

Unidad 1. La libertad: facultad inherente a todo ser humano

Plan de proyecto

Unidad 2

Actividad 2

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 Calidad
1. 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 Inyectado Porcentaje Inyectado
Tipo Diseo Cdigo Diseo Cdigo
10 0 1 0.0% 1.8%
20 2 30 16.7% 52.6%
30 0 3 0.0% 5.3%
40 1 2 8.3% 3.5%
50 1 2 8.3% 3.5%
60 0 0 0.0% 0.0%

3


70 4 9 33.3% 15.8%
80 4 6 33.3% 10.5%
90 0 4 0.0% 7.0%
100 0 0 0.0% 0.0%
Total 12 57
Tabla. Defectos introducidos en las fases de diseo y codificacin
El 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.
Tipo Nmero Inyectado Porcentaje Inyectado
10 0 0.0%
20 2 16.7%
30 0 0.0%
40 1 8.3%
50 1 8.3%
60 0 0.0%
90 0 0.0%
100 0 0.0%
Tabla. Defectos menos introducidos en la fase de diseo
En 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.

4


Tipo Clasificacin del
defecto
Nmero de defectos
introducidos
71 Mal clculo de la funcin 2
72 Error de parmetros 2
Total 4
Tabla. Clasificacin de los errores tipo 70 introducidos en la fase de diseo

defecto
Nmero de defectos
introducidos
81 Mal funcionamiento 3
82 Recodificacin 1
Total 4
Tabla. Clasificacin de los errores tipo 80 introducidos en la fase de diseo

defecto
Nmero de defectos
introducidos
21 Error de dedo 18
22 Inicializacin de variables 5
23 Tipo de dato incompatible 6
24 Error de parmetros 1
Total 30
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?

5


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 pruebas
3. 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

6


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 KLOC
4. 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.
Fase Nmero de defectos
eliminados
Tasa de defectos
eliminados (%)
DLDR 5 7.0%
CR 11 15.5%
Compile 31 43.7%
Test 24 33.8%
Total 71 100%

7


Tabla. Tasa de defectos eliminados en las fases de revisin de diseo, revisin de cdigo,
codificacin y pruebas
5. 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 cdigo
En 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.
Programa
Tasa de revisin de
diseo (LOC
revisadas/hora)
Tasa de revisin de
cdigo (LOC
revisadas/hora)
Tasa para ambas
revisiones (LOC
revisadas/hora)
7 231.4 237.1 113.7
8 246 246 117.1

8


9 230 235.9 115.3
10 335.4 346.8 170.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 10A
En 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


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 Riesgo
El 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 riesgos
Los 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.

10


Empoderar a los miembros del
equipo para gestionar los riesgos
Los 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 propietario
Cuando 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 riesgos Debe 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:

11


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 riesgos
En 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.
ID Tipo Descripcin del riesgo Posibles
consecuencias
Interno Externo
R18MS X Ataques contra contraseas
de usuarios
Prdida de acceso a
informacin
R19MS X Des encriptacin de
informacin
Copia de datos
R20MS X Vulnerabilidad del antivirus Inestabilidad en el
servicio
R21MS X Vulnerabilidad en los puertos Prdida de servicios
R22MS X Ataques de SQL a la base de
datos
Prdida de
consistencia
R23MS X Vulnerabilidad en el firewalls Contaminacin por
virus informticos
R24MS X Vulnerabilidad en el servidor Robo de informacin
R25MS X Robo de conexin Wi-Fi Prdida de calidad en
el servidor
R26MS X Vulnerabilidad de certificados Prdida de datos

12


digitales
R27MS X Vulnerabilidad 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 riesgos
Cuando 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.45
Finalmente, 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.
Impacto Escala de prioridad de eventos
de riesgo
Probabilidad 0,10 0.35 0.50 0.80 1.00

13


0.90 0.09 0.32 0.45 0.72 0.90 Riesgo bajo
Riesgo Medio
Riesgo Alto
0.70 0.07 0.25 0.35 0.56 0.70
0.50 0.05 0.18 0.25 0.40 0.50
0.30 0.03 0.11 0.15 0.24 0.30
0.10 0.01 0.04 0.05 0.08 0.10
Tabla. Matriz cualitativa de riesgo
En la siguiente tabla se muestra nuestro anlisis de riesgo.
ID Anlisis del riesgo
18MS Magnitud:
Alta
Descripcin:
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 SSO
Kerberos.
Tabla. Anlisis del riesgo y estrategias
Elaborar planes de contingencia

14


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.

Ddse U2 A2 Roag

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ddse U2 A2 Roag

Transféré par

Droits d'auteur :

Formats disponibles

NOMBRE: Roberto lvarez Granados

Vous aimerez peut-être aussi