Está en la página 1de 37

FACULTAD DE INGENIERIA

UNIDAD ACADEMICA SANTA CRUZ

Facultad de Ingeniería

Ingeniería de Sistemas

OCTAVO SEMESTRE

SYLLABUS DE LA ASIGNATURA
INGENIRÍA DE SOFTWARE

Elaborado por: Ing. Yoelma Y. Melendres de Gonzales

Gestión Académica II/2006

U N I V E R S I D A D D E A Q U I N O B O L I V I A
1
FACULTAD DE INGENIERIA

UNIDAD ACADEMICA SANTA CRUZ

VISION DE LA UNIVERSIDAD

Ser la Universidad líder en calidad educativa.

MISION DE LA UNIVERSIDAD

Desarrollar la Educación Superior Universitaria con calidad y competitividad al


servicio de la sociedad.

Estimado (a) alumno (a):


La Universidad de Aquino Bolivia te brinda a través del Syllabus, la oportunidad de
contar con una compilación de materiales que te serán de mucha utilidad en el desarrollo
de la asignatura. Consérvalo y aplícalo según las instrucciones del docente.

U N I V E R S I D A D D E A Q U I N O B O L I V I A
2
FACULTAD DE INGENIERIA

2.1. El espectro de la gestión de


proyectos de software
SYLLABUS GENERICO 2.2. Personal
2.2.1. Los participantes
Asignatura: Ingeniería del Software 2.3. Producto
Código: CMP-518 2.3.1. Ámbito del software
Requisito: CMP-425 2.3.2. descomposición del problema
2.4. Proceso
80 horas Teórico
Carga Horaria: 2.4.1. Maduración del producto y el
Prácticas
proceso
Créditos: 4
2.4.2. Descomposición del proceso
2.5. Proyecto
I. OBJETIVOS GENERALES DE LA
ASIGNATURA TEMA 3. Proceso de software y métricas
de proyectos
 Aplicar técnicas y conceptos de
Ingeniería del Software en el desarrollo y 3.1. Medidas, métricas e indicadores
mantenimiento del software. del proceso de desarrollo de
software.
 Efectuar mediciones y aplicar métricas 3.2. Mediciones del software
sobre el proceso de desarrollo y 3.2.1. Métricas orientadas al tamaño
mantenimiento del software. 3.2.2. Métricas orientadas a la
 Identificar las técnicas de planificación función
y gestión de proyectos de software. 3.2.3. Métricas ampliadas de punto
de función
 Estimar ajustadamente el esfuerzo y el 3.3. Integración de las métricas dentro
costo de un proyecto de software. del proceso de ingeniería
 Identificar las técnicas para
mantenimiento, reingeniería e ingeniería TEMA 4. Planificación de proyectos de
inversa del software. software y gestión de riesgos

4.1. Objetivos de la planificación del


II. PROGRAMA ANALÍTICO DE LA proyecto
ASIGNATURA 4.2. Ámbito del software
4.2.1. Obtención de la información
UNIDAD 1. Gestión de proyectos necesaria para el ámbito
4.2.2. Viabilidad
TEMA 1. Introducción a la Ingeniería de 4.3. Recursos
Software 4.4. Estimaciones.
4.5. Técnicas de descomposición.
1.1. Roles en ingeniería software 4.6. Modelos empíricos de estimación.
1.2. Evolución del software 4.7. La decisión de desarrollar o
1.3. Características del software comprar
1.4. Mitos del software 4.8. Análisis y Gestión del riesgo.
1.5. El proceso del software 4.9. Identificación del riesgo.
1.6. Modelos de proceso del software 4.10. Proyección del riesgo.
4.11. Reducción, supervisión y gestión
TEMA 2. Gestión de proyectos del riesgo
4.12. El plan de gestión del riesgo

U N I V E R S I D A D D E A Q U I N O B O L I V I A
3
FACULTAD DE INGENIERIA

7.2. Ingeniería inversa


UNIDAD 2. Gestión de aseguramiento de la 7.2.1. Para comprender el
calidad procesamiento
7.2.2. Para comprender los datos
TEMA 5. Aseguramiento de la calidad del 7.2.3. De interfaces de usuario
software SQA/GCS 7.3. reestructuración.
7.3.1. Reestructuración. del código
5.1. Conceptos de calidad 7.3.2. Reestructuración de los datos
5.2. Revisiones del software. 7.4. Ingeniería directa
5.3. Estándares de calidad ISO 9001. 7.4.1. Para arquitecturas
5.4. Plan de aseguramiento de la cliente/servidor
calidad. 7.4.2. Para arquitecturas orientadas
5.5. Gestión de configuración del a objetos
software 7.4.3. Para interfaces de usuario
5.6. El proceso de gestión de la calidad 7.5. La economía de la reingeniería
del software
5.7. Control de versiones y de cambios III. ACTIVIDADES PROPUESTAS PARA
5.8. Auditoria de la configuración. LAS BRIGADAS UDABOL

TEMA 6. Pruebas del software Las Brigadas están destinadas a incidir de


manera significativa en la formación
6.1. Fundamentos de las pruebas del profesional integral de nuestros estudiantes y
software revelan las enormes potencialidades que
6.1.1. Objetivos y principios de las presenta esta modalidad de la educación
pruebas. superior no solamente para que conozcan a
6.1.2. Facilidad de las pruebas. fondo la realidad del país y se formen de
6.2. Casos de prueba. manera integral, sino, además, para que
6.3. pruebas de caja blanca. incorporen a su preparación académica los
6.3.1. Prueba del camino básico problemas de la vida real a los que resulta
6.3.2. Prueba de la estructura de imperativo encontrar soluciones desde el
control campo profesional en el que cada uno se
6.3.3. Prueba de caja negra desempeñará.
6.3.4. Prueba de entornos
especializados, arquitectura y El trabajo de las Brigadas permite que
aplicaciones nuestros estudiantes se conviertan a mediano
6.4. Estrategias de prueba de software. plazo en verdaderos investigadores, capaces
de elaborar y acometer proyectos de
6.4.1. Enfoque estratégico para las desarrollo comunitario a la vez que se
pruebas. acostumbren a trabajar en equipos
6.4.2. Prueba de unidad. interdisciplinarios o multidisciplinarios como
6.4.3. Prueba de integración corresponde al desarrollo alcanzado por la
6.4.4. Prueba de validación ciencia y la tecnología en los tiempos
6.4.5. Prueba del sistema actuales.
6.4.6. El arte de la depuración
La ejecución de diferentes programas de
TEMA 7. Reingeniería
interacción social y la elaboración e
implementación de proyectos de desarrollo
7.1. Reingeniería del software
comunitario derivados de dichos programas
7.1.1. Mantenimiento del software
confiere a los estudiantes, quienes son, sin
7.1.2. Modelo de procesos de
reingeniería

U N I V E R S I D A D D E A Q U I N O B O L I V I A
4
FACULTAD DE INGENIERIA

dudas, los más beneficiados con esta - Realizar investigaciones multidisciplinarias


iniciativa, la posibilidad de: en un momento histórico en que la ciencia
- Desarrollar sus prácticas pre- atraviesa una etapa de diferenciación y en
profesionales en condiciones reales y que los avances tecnológicos conllevan la
tutorados por sus docentes con procesos aparición de nuevas y más delimitadas
académicos de enseñanza y aprendizaje especialidades.
de verdadera “aula abierta”
- Trabajar en equipos, habituándose a ser Desarrollar una mentalidad, crítica y solidaria,
parte integral de un todo que funciona con plena conciencia de nuestra realidad
como unidad, desarrollando un lenguaje nacional.
común, criterios y opiniones comunes y
planteándose metas y objetivos comunes A continuación se describe las actividades a
para dar soluciones en común a los realizar por las brigadas Udabol.
problemas.

TEMAS CON
TAREAS LUGAR DE FECHA
LOS QUE SE
PROPUESTAS ACCIÓN PREVISTA
RELACIONA
Desarrollo de un software a medida, aplicando
ingeniería para empresas del medio, en grupo Diferentes
Todo el
de dos estudiantes, proyecto que será Todos empresas
semestre
presentado en la feria de proyectos de la carrera del medio
al final del semestre.
Fechas
Se realizará una participación activa en las Ciudad de
previstas
incursiones al medio planificadas por la 5 Santa Cruz
por la
Universidad. de la Sierra.
universidad
Realizar visitas técnicas a empresas del medio Empresas
Antes del
con el objetivo de conocer la tecnología de de la ciudad
1, 2 primer
software que utilizan y el proceso de desarrollo de Santa
parcial.
que siguen según la institución. Cruz
ACTIVIDADES DE INCURSIÓN actividades planificadas para las Brigadas
MASIVA EN LA COMUNIDAD. UDABOL. Estas evaluaciones tendrán una
calificación entre 0 y 50 puntos.
A lo largo del semestre se realizarán dos
incursiones masivas en la comunidad,  PROCESO DE APRENDIZAJE O
comprendida la primera entre el 2 y el 8 de SUMATIVA.
octubre y la segunda entre el 13 y el 19 de
noviembre. Con la finalidad de realizar  Se realizarán dos evaluaciones parciales
trabajos ya sean de recojo de información, con contenidos teóricos y prácticos.
extensión o relacionada con los proyectos a
desarrollar en la asignatura o la carrera.  En la etapa final se presentará un
proyecto que se desarrollará a lo largo
IV. EVALUACIÓN DE LA ASIGNATURA. de todo el semestre dando aplicación a
los diferentes temas avanzados, y un
 PROCESUAL O FORMATIVA. examen final de todo lo avanzado en el
semestre. Estas evaluaciones tendrán
En todo el semestre se realizarán una calificación entre 0 y 50 puntos.
preguntas escritas, trabajos prácticos,
trabajos de investigación además de las V. BIBLIOGRAFIA

U N I V E R S I D A D D E A Q U I N O B O L I V I A
5
FACULTAD DE INGENIERIA

BASICA  BERTOGLIO, OSCAR JOHANSEN.


“Introducción a la Teoría General de
 PRESSMAN, ROGER. “Ingeniería del Sistemas”. 4ta. Edición. Editorial Limusa.
Software un enfoque practico”. 5ta. 1989
Edición. McGRAW-HILL. 2002.
 JAMES RUMBAUGH, IVAR JACOBSON, VI. CONTROL DE EVALUACIONES.
GRADY BOOBH. “El Lenguaje unificado
de modelado. Manual de referencia”. 1° evaluación parcial
Pearson Educación S.A., 2000. Fecha
Nota
COMPLEMENTARIA
2° evaluación parcial
 GHEZZI P. “Fundamentals of software Fecha
engineering”. Prentice Hall. 1992 Nota

 KENDALL & KENDALL. “Análisis y Diseño Examen final


de Sistemas”. 3ra. Edición. Editorial. Fecha
PRENTICE HALL HISPANOAMERICANA Nota
S.A. 1997

APUNTES

U N I V E R S I D A D D E A Q U I N O B O L I V I A
6
FACULTAD DE INGENIERIA

VII. PLAN CALENDARIO

SEMANA ACTIVIDADES ACADÉMICAS OBSERVACIONES


1ra. Tema 1(1.1 – 1.6)    
2da. Tema 2(2.1 – 2.5)    
3ra. Tema 3(3.1 – 3.2.1)    
Tema 3(3.2.2 –
4ta.    
3.2.3)
5ta. Tema 3(3.3)
6ta. Tema 4(4.1 – 4.4.)
Primera
7ma. Tema 4(4.5)
Evaluación
 Primera
8va. Tema 4(4.6)  
Evaluación
9na. Tema 4(4.7)    Presentación de Notas
10ma. Tema 4(4.8-4.9)    
11ra. Tema 4(4.10-4.12)
12da. Tema 5(5.1-5.2)
13ra. Tema 5(5.3-5.4)
Segunda
14ta. Tema 5(5.5-5.6)
Evaluación
 Segunda
15ta. Tema 5(5.7-5.8)  Presentación de Notas
Evaluación
16ta. Tema 6(6.1-6.3.3)
17ma. Tema 6(6.3.4-6.4.6)
18va. Tema 7(7.1-7.2.3)
19na. Tema 7(7.3-7.5)
20ma. Evaluación final Presentación de Notas
21ra. Evaluación final Presentación de Notas
22da. Segunda instancia Presentación de Notas

U N I V E R S I D A D D E A Q U I N O B O L I V I A
7
FACULTAD DE INGENIERIA

PROGRAMA DE CONTROL DE CALIDAD

WORK PAPER # 1

UNIDAD O TEMA: Introducción a la Ingeniería de Software


TITULO: Mitos del software
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: 1er Parcial

Los mitos surgieron durante los primeros años ordenada. Además si sacamos a gente de
del desarrollo del software. otros proyectos, en último término
retrasaremos otros proyectos.
• Son actitudes erróneas que causan serios
problemas tanto a gestores como a técnicos. 1.2. Mitos del cliente
• Pueden afectar a: a) Mito: Una declaración general de objetivos
es suficiente para comenzar a escribir los
– Gestores. programas, y podemos dar los detalles más
– Clientes. adelante.
– Programadores. Realidad: Una mala definición inicial conlleva
trabajo inútil.
1. Mitos del software
b) Mito: Los requisitos del proyecto cambian
1.1. Mitos del gestor continuamente, pero los cambios pueden
a) Mito: Tenemos un manual de desarrollo de acomodarse fácilmente porque el software es
software. ¿Qué más necesitamos? flexible.

Realidad. ¿Se entiende? ¿Se utiliza? ¿El Realidad: Es cierto que los requisitos
personal tiene práctica en su aplicación?. cambian, pero el impacto del cambio varía en
función del momento en que se introduzcan
b) Mito: Disponemos de las herramientas de los cambios, mientras más tarde el costo es
desarrollo más avanzadas, ya que mas alto.
compramos siempre los mejores equipos.
1.3. Mitos de los desarrolladores
Realidad: ¿Se invierte en herramientas
CASE? ¿Y en entornos de desarrollo? a) Mito: Una vez que escribamos el programa
y hagamos que funciones, nuestro trabajo ha
c) Mito: Si fallamos en la planificación, terminado.
podemos añadir más programadores y
adelantar el tiempo perdido. Realidad: Entre el cincuenta y el setenta por
ciento de todo el esfuerzo dedicado a un
Realidad: En el proceso de software añadir programa se realiza después de que se
gente puede retrasar más el proyecto. La entregue al cliente por primera vez.
gente debe añadirse de forma planificada y

U N I V E R S I D A D D E A Q U I N O B O L I V I A
8
FACULTAD DE INGENIERIA

CUESTIONARIO WORK PAPER Nro. 1


b) Mito: Hasta que no tenga el programa 1. ¿Considera que es importante tomar en
ejecutándose, no tengo forma de medir su cuenta estos mitos?
calidad.
2. Durante su experiencia, en el desarrollo
Realidad: Revisiones Técnicas Formales de software; ¿cuales de estos mitos y
durante el desarrollo de software. realidades a experimentado?.
c) Mito: Lo último que se entrega al terminar 3. ¿Qué otros mitos podría agregar a estos?,
el proyecto es el programa funcionando. tanto para:
Realidad: software = programas + datos + a) Gestores de proyectos de software
documentación.
b) Cliente
Conclusión: Cuidado con los mitos.
c) Desarrolladores

PROGRAMA DE CONTROL DE CALIDAD

WORK PAPER # 2

UNIDAD O TEMA: Introducción a la Ingeniería de Software


TITULO: Modelos de proceso del software
FECHA DE ENTREGA: Agosto-2006
PERIODO DE EVALUACIÓN: 1er Parcial

Un Paradigma de Ingeniería de Software o Figura 1. Modelo Lineal Secuencial


Modelo de Proceso, contempla una serie de
pasos a seguir para el desarrollo de un
Sistema de Información.
Ingeniería de
Sistemas/Información
Se debe elegir el modelo de Proceso según:
Análisis Diseño Código Prueba
• La naturaleza del proyecto y de la Análisis Diseño Código Prueba
aplicación.
• Los métodos y herramientas a utilizar.
• Los controles y entregas que se requieren.

1. El modelo Lineal Secuencial

U N I V E R S I D A D D E A Q U I N O B O L I V I A
9
FACULTAD DE INGENIERIA

ETAPAS: ETAPAS:

1. Ingeniería y modelado de a) Modelado de Gestión


Sistemas/Información
2. Análisis de los requisitos del software Tiene como objetivo responder a las
3. Diseño siguientes preguntas:
4. Generación de Código
5. Pruebas • ¿Qué información conduce el proceso
6. Mantenimiento de gestión?
• ¿Qué información se generará?
2. Modelo de Construcción por Prototipos • ¿Quién la genera?
• ¿A dónde va la información?
Figura 2. Modelo de Construcción por • ¿Quién la procesa?
Prototipos
b) Modelado de Datos

• Se modela la información como un


conjunto de objetos.
• Se definen los atributos de dichos
Construir/revisar
Escuchar objetos.
la maqueta
al cliente • Se identifican las relaciones entre los
objetos.

c) El modelado de proceso

• Los objetos de datos definidos en la


El cliente fase de modelado de datos quedan
prueba transformados para lograr el flujo de
la maqueta información requerido.

ETAPAS: • Se realizan las descripciones de


procesos, tales como agregar,
a) Recolección de requisitos modificar, eliminar o recuperar un
b) Diseño rápido objeto de datos.
c) Construcción del prototipo
d) Evaluación del Cliente/Usuario d) Generación de Aplicaciones
e) Refinación de requisitos
Se utilizan herramientas para facilitar la
3. El modelo DRA (Desarrollo Rápido de construcción del software, tales como:
Aplicaciones)
• Técnicas de 4ta Generación para la
Es una adaptación a “alta velocidad” del generación de Aplicaciones.
modelo lineal secuencial en el que se logra el
• Reutilización de componentes de
desarrollo rápido utilizando una construcción
basada en componentes. programas ya existentes.

Si se comprenden los requisitos permite al 5) Pruebas y entrega


equipo de desarrollo crear un sistema
• El tiempo de prueba se reduce, ya que
funcional dentro de períodos cortos de tiempo
el proceso DRA enfatiza la
(Ej. de 60 a 90 días).
reutilización, y muchos de los

U N I V E R S I D A D D E A Q U I N O B O L I V I A
10
FACULTAD DE INGENIERIA

componentes del programa ya se han Figura 3. El modelo DRA


probado.

Se deben probar todas las interfaces a fondo.

Equipo No 2 Equipo No 3
Equipo No 1
Modelado
de gestión
Modelado
Modelado de gestión Modelado
de gestión de datos
Modelado
Modelado de procesos
Modelado de datos
Gener. de
de datos Aplicaciones
Modelado
de procesos
Pruebas
Modelado y entrega
de procesos Generación
de
Aplicaciones
Generación
de Pruebas
Aplicaciones y entrega

Pruebas
y entrega

4. El modelo incremental

Figura 4. Modelo incremental

Ingeniería de
Sistemas/Información Incremento 1
Entrega del
Análisi Diseño Código Prueba 1er Incremento

Incremento 2 Análisi Diseño Entrega del


Código Prueba 2do Incremento
s

Entrega del
Incremento 3 Análisi Diseño Código Prueba 3er Incremento
s
Entrega del
Análisi
Incremento 4 Diseño Código Prueba 4to Incremento
s
Se centra en la entrega de un producto operacional con cada incremento.

U N I V E R S I D A D D E A Q U I N O B O L I V I A
11
FACULTAD DE INGENIERIA

Este método es útil cuando la dotación de personal no está disponible para una implementación
completa en la fecha límite que se haya establecido para el proyecto. Se caracteriza por modularizar
el problema y resolver los módulos uno a uno, poniendo en funcionamiento cada modulo una vez
terminado.

5. Modelo Espiral

Figura 5. Modelo Espiral

a) Planificación
En esta etapa se realiza la determinación de objetivos, alternativas y restricciones.

b) Análisis de riesgo

U N I V E R S I D A D D E A Q U I N O B O L I V I A
12
FACULTAD DE INGENIERIA

Se realiza el análisis de alternativas e identificación/resolución de riesgos.


c) Ingeniería
Se desarrolla del producto del "siguiente nivel“.

d) Evaluación del cliente


En esta etapa el cliente realiza la valorización de los resultados de la ingeniería.

6. El modelo espiral WINWIN (Victoria & Victoria)

Figura 6. Modelo espiral WINWIN

2. Identificar las 3.a. Reunir las


condiciones de condiciones de victoria
1. Identificar el victoria de los 3.b. Establecer los
siguiente nivel directivos. objetivos, restricciones
para los y alternativas del
directivos. siguiente nivel.

4. Evaluar las alternativas


del producto y del proceso
7. Revisión y y resolución de riesgos.
comentarios.

6. Validar las 5. Definir el siguiente


definiciones del nivel del producto y
producto y del proceso. del proceso.

La obtención de requisitos del software 2. Determinación de las “condiciones de


requiere una negociación. Tiene éxito cuando victoria” de los directivos.
ambos partes “ganan”.
3. Negociación de las condiciones de
Actividades de Negociación al principio de “victoria” de los directivos para
cada paso alrededor del Sistema: reunirlas con un conjunto de
condiciones “victoria-victoria” para
1. Identificación del sistema o todos los afectados.
subsistemas clave de los “directivos”.

7. El modelo de desarrollo concurrente


Figura 7. Modelo de desarrollo concurrente

U N I V E R S I D A D D E A Q U I N O B O L I V I A
13
FACULTAD DE INGENIERIA

Ninguna

Bajo Desarrollo

Cambios en Bajo
espera revisión

Bajo modificación En línea base

Realizado

Se centra en el estado por el que pasa un continúa con la línea de desarrollo hasta
Sistema de Información, donde inicialmente terminar la tarea, una vez en este punto, es
parte de Ninguna, luego entra a Bajo posible, nuevamente volver a Cambios en
desarrollo, si es un nuevo Sistema pasa a Espera; pero si el propósito es realizar el
Cambios en espera, una vez teniendo un mantenimiento de un, este puede pasar de
avance en el desarrollo pasa a bajo bajo desarrollo a bajo revisión, luego volver a
modificación, donde el cliente tiene la línea base, hasta terminar la tarea.
posibilidad de revisar el avance, luego se

8. Desarrollo basado en Componentes


Figura 8. Desarrollo basado en Componentes
Identificar
componentes
candidatos

Construir la Buscar
iteración del componentes en
sistema Biblioteca

Poner Extraer
componentes en componentes
la Biblioteca disponibles

Desarrollar
componentes si
no están
disponibles

Es un ciclo de vida de desarrollo de software a) La planificación


iterativo basado en el ciclo de vida en espiral,
conformado por cuatro etapas: b) Análisis de riesgo

U N I V E R S I D A D D E A Q U I N O B O L I V I A
14
FACULTAD DE INGENIERIA

c) Ingeniería CUESTIONARIO WORK PAPER NRO. 2


d) Evaluación del Cliente 1. El centro de procesamiento de Datos de la
universidad UDABOL pretende desarrollar
A diferencia del modelo en espiral, el desarrollo un editor de presentaciones como el
basado en componentes, al cursar la etapa de Microsoft PowerPoint, ¿De entre los
ingeniería se centra en insertar componentes siguientes paradigmas de desarrollo cual de
de sistemas, ya disponibles para acelerar el ellos recomienda usted aplicar?
desarrollo.
a) Modelo de Prototipo
8. Técnicas de 4ta Generación
b) Modelo DRA
Abarca un amplio espectro de herramientas de
software que: c) Modelo Incremental
Facilitan al Ing. de Software la especificación d) Modelo en espiral
de algunas características de software a alto
nivel. Luego la herramienta genera 2. El equipo de desarrollo OMEGA formado
automáticamente el código fuente basándose por 3 ingenieros de sistema, iniciará un
en la especificación del técnico. Sistema de información para control de
inventario y ventas de medicamentos de la
Un entorno de desarrollo que soporte el cadena de farmacias Santa María, se tiene
paradigma T4G puede incluir todas o algunas como requisito la entrega del proyecto en
de las siguientes herramientas: seis meses máximo, ¿Qué paradigma de
desarrollo les recomienda usted aplicar para
• Lenguajes procedimentales de consulta desarrollar este Sistema y por qué?.
a BD.
3. Identifique el modelo de proceso a seguir
• Generación de informes. para el desarrollo del proyecto de la
• Manejo de datos. materia.
• Capacidades gráficas de alto nivel. 4. Realice una planificación del desarrollo del
proyecto siguiendo el modelo de proceso
• Capacidades de hoja de cálculo. seleccionado y utilizando el Diagrama de
• Generación de Código. Gantt y Red.

U N I V E R S I D A D D E A Q U I N O B O L I V I A
15
FACULTAD DE INGENIERIA

PROGRAMA DE CONTROL DE CALIDAD

WORK PAPER # 3

UNIDAD O TEMA: Proceso de software y métricas de proyectos


TITULO: Medidas, métricas e indicadores del proceso de desarrollo de software
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: 1er Parcial

1. Introducción Ejemplo: Ana será la encargada de medir las


LDC de cada módulo del sistema.
• La existencia de medidas numéricas facilita el
conocimiento de un fenómeno. • Una métrica es una medida cuantitativa del
grado en que un sistema, componente o
• Las métricas del software miden el software
proceso posee un atributo dado.
de computadora
Ejemplo: La productividad de este proyecto fue
• Estas métricas sirven para:
de 500 (LDC/persona-mes)
- Utilizarlas en el proyecto para ayudar en la
• Las medidas no sirven para comparar,
estimación, control de calidad, evaluación
necesitamos métricas
de la productividad y control de proyectos.
Ejemplo: En el país A ganan 1000 $us/mes y en
- El desarrollador de software evalúe la
el país B ganan 1500 $us/mes
calidad de los productos y trabajos técnicos.
¿viven mejor en el país B que en el país A?
- Ayudar en la toma de decisiones tácticas
según avanza el proyecto. Una King Burger (KB) cuesta 3 $us en el país
A, y en el país B cuesta 5 $us. Entonces
- Aplicarlas al proceso con la idea de
calculemos:
mejorarlo.
País A: 1000($us /mes)/3($us/KB) = 333,33
• Hay cuatro razones para medir:
(KB/mes)
– Caracterizar.
País B: 1500($us /mes/5($us/KB) =300
– Evaluar. (KB/mes)
– Predecir. Conclusión: no sabemos donde se vive mejor,
– Mejorar. pero en el país A una persona durante un mes
puede comer un 33% más de King Burger que
2. Medidas, métricas e indicadores en el país B
• Una medida proporciona una indicación
cuantitativa de la extensión, cantidad,
dimensiones, capacidad o tamaño de algunos Es decir:
atributos de un proceso o producto.  La medida captura una característica
Ejemplo: Un programa tiene 10.000 LDC (líneas individual.
de código).  La medición permite capturar dicha
• La medición es el acto de determinar una característica.
medida.

U N I V E R S I D A D D E A Q U I N O B O L I V I A
16
FACULTAD DE INGENIERIA

 La métrica permite relacionar y comparar 2. ¿Dos razones para medir un proyecto son:
mediciones. Evaluar y predecir?
Las métricas son el fundamento de los V F
indicadores. 3. ¿Qué diferencias existe entre la medida y la
• Un indicador es una métrica o combinación de métrica?
métricas que proporcionan una visión profunda ___________________________________
del proceso del software, del proyecto de
software o del producto en si. ___________________________________
Ejemplo: En el país A no han aumentado los
sueldos en los últimos tres años, pero el índice ___________________________________
King Burger se ha duplicado en ese periodo.
4. Un indicador es una medida que
• Ejemplo: La productividad media de nuestra proporcionan una visión profunda del proceso
empresa es de 500(LDC/mes) y en el último del software, del proyecto de software o del
proyecto ha sido de 250(LDC/mes). producto en si.
CUESTIONARIO WORK PAPER NRO. 3 V F
1. ¿Las métricas sirven para que el 5. La métrica permite relacionar y comparar
desarrollador de software evalúe la calidad mediciones.
de los productos y trabajos técnicos?
V F
V F

PROGRAMA DE CONTROL DE CALIDAD

WORK PAPER # 4

UNIDAD O TEMA: Ingeniería de Requerimientos


TITULO: Estudio de Factibilidad
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: 2do Parcial

El estudio de Factibilidad de un proyecto  ¿Existe o se puede adquirir


tiene como objetivo la viabilidad del mismo; se tecnología necesaria para realizar lo que
lo debe realizar bajo tres puntos de vistas: se pide?
Factibilidad técnica, factibilidad económica, y
factibilidad operativa.  ¿El equipo propuesto tiene la
capacidad técnica para soportar todos los
1. Factibilidad Técnica datos requeridos para usar el nuevo
Tiene como objetivo responder a las sistema?
siguientes preguntas:

U N I V E R S I D A D D E A Q U I N O B O L I V I A
17
FACULTAD DE INGENIERIA

 ¿El sistema propuesto ofrecerá  ¿El sistema propuesto causará


respuestas adecuadas a las peticiones sin perjuicios?, ¿Producirá resultados pobres
importar el número y ubicación de los en algún aspecto o área?, ¿Se perderá el
usuarios? control en alguna área?
 Si se desarrolla el sistema, ¿puede  ¿La productividad de los empleados será
crecer con facilidad? menor después que antes de la
implantación?
 ¿Existen garantías técnicas de
exactitud, confiabilidad, facilidad de  ¿Los clientes se verán afectados en forma
acceso y seguridad de los datos? poco favorable?
2. Factibilidad Económica: Análisis de CUESTIONARIO WORK PAPER NRO. 4
Costo/Beneficio
1. ¿Considera importante realizar un estudio
Se deben realizar las siguientes tareas: de falibilidad antes de iniciar el desarrollo
de un proyecto de sistemas, porque?
 Determinar el costo de llevar a cabo la
investigación completa de sistemas. 2. ¿Cuál es el objetivo del análisis
costo/beneficio de un proyecto?
 El costo del hardware y software para la
aplicación que se está considerando. 3. ¿Por qué se considera importante la
participación de los usuarios del sistema
 Beneficios en la forma de reducción de en el desarrollo del mismo?
costos o de menos errores costosos.
4. Realice una tabla comparativa de los
 El costo de no llevar a cabo el proyecto. aspectos relevantes que se deben tomar
3. Factibilidad Operativa en cuenta en el estudio de factibilidad
técnica, factibilidad económica y
Tiene como objetivo responder a las factibilidad operativa de un proyecto de
siguientes preguntas: sistemas.
 ¿Trabajará el sistema cuando esté 5. Realice el estudio de factibilidad del
terminado e instalado? proyecto de sistemas, que esta
 ¿Existen barreras importantes para la desarrollando en grupo.
implantación? 6. Si una Pyme está muy interesada en
 ¿Existe apoyo suficiente para el proyecto automatizar sus procesos de trabajo en el
por parte de la administración y de los área comercial, esta Pyme cuenta con
usuarios? PC’s de ultima tecnología para el trabajo
requerido, pero no cuenta con los
 ¿Los métodos que actualmente se recursos necesarios para licencias de
emplean en la empresa son aceptados por software, que solución usted propone
los usuarios? para la viabilidad del proyecto de
software.
 ¿Los usuarios han participado en la
planeación y desarrollo del proyecto?

U N I V E R S I D A D D E A Q U I N O B O L I V I A
18
FACULTAD DE INGENIERIA

PROGRAMA DE CONTROL DE CALIDAD

WORK PAPER # 5

UNIDAD O TEMA: Pruebas del software


TITULO: pruebas del software
FECHA DE ENTREGA: noviembre-2006
PERIODO DE EVALUACIÓN: Examen final

1. El proceso de prueba 1. Prueba de componentes


En el proceso de prueba del software se 1.1.1. Pruebas de defectos
deben realizar dos tipos de pruebas:  Objetivo de la prueba de defectos es
descubrir defectos en los programas.
PRUEBA DE PRUEBA DE  Un test de defectos tiene ÉXITO si causa
COMPONENTES INTEGRACIÓN que el programa se comporte de forma
anómala.
 Las pruebas revelan la presencia, y no la
Desarrollador del software Grupo independiente de pruebas
ausencia de defectos.
Prueba de componentes  Solamente las pruebas exhaustivas
 Se deben probar los componentes pueden probar que el programa no tiene
individualmente defectos. Sin embargo, las pruebas
 El responsable de la prueba suele ser el exhaustivas son IMPOSIBLES.
desarrollador de dicho componente Casos y Datos de prueba
 Basada en una comprensión intuitiva de  DATOS de prueba: Son entradas que son
cómo dichos componentes deberían ideadas para probar el sistema
operar  CASOS de prueba: Son las entradas del
Prueba de integración sistema y las salidas esperadas a partir de
esas entradas, para probar si el sistema
 Pruebas sobre grupos de componentes,
funciona de acuerdo con su especificación
que son integrados para crear un sistema
o subsistema  Proceso de pruebas de defectos.
 El responsable es un grupo independiente
de prueba
 Basada en la especificación del sistema.

Criterios para elegir las pruebas

U N I V E R S I D A D D E A Q U I N O B O L I V I A
19
FACULTAD DE INGENIERIA

 Puesto que es imposible hacer una  Intentan garantizar que todos los caminos
prueba de defectos exhaustiva, de ejecución del programa quedan
utilizaremos un subconjunto de casos de probados.
prueba Pruebas de estructura de control:
 Probar las capacidades del sistema es
 Del camino básico: Diseñar un caso de
más importante que probar sus
prueba por cada camino independiente.
componentes.
 De condición: Diseñar casos de prueba
 Probar las capacidades anteriores es más
para que todas las condiciones del
importante que probar capacidades
programa se evalúen a cierto/falso
nuevas.
 Probar situaciones típicas es más  De bucles: Diseñar casos de prueba para
importante que probar los casos límite. que se intente ejecutar un bucle 0,1,…,n-
1,n y n+1 veces (siendo n el número
a) Métodos de caja blanca máximo)
Aseguran que la operación interna del b) Pruebas de caja negra
programa se ajusta a las especificaciones y
que todos los componentes internos se han Considera el sistema como una caja negra,
probado adecuadamente. cuyo comportamiento es determinado
únicamente a partir de sus entradas y salidas
 Usa la estructura de control para obtener
Los casos de prueba se basan en la
los casos de prueba.
especificación del sistema

U N I V E R S I D A D D E A Q U I N O B O L I V I A
20
FACULTAD DE INGENIERIA

Métodos de caja negra inferiores, reemplazando los componentes del


 Se centra en los requisitos funcionales del nivel superior por DRIVERS hasta que se crea
software. el sistema completo
En la práctica, el proceso de integración se
 Permite obtener un conjunto de
realiza combinando ambas estrategias
condiciones de entrada que ejerciten
completamente los requisitos funcionales Comparación de estrategias
del programa.  La estrategia top-down descubre antes los
 No es una alternativa a la prueba de caja errores en la arquitectura del sistema
blanca. Demostración del sistema
 Complementan a las pruebas de caja  La estrategia top-down permite una
blanca demostración limitada del sistema en
etapas tempranas del desarrollo
 Se deben probar los valores límite, ya que
los errores suelen situarse en los límites.  Implementación de las pruebas
 Si la entrada se encuentra en el rango  A menudo es más sencilla cuando se usa
a..b entonces hay que probar con los la estrategia bottom-up
valores a -1, a, a + 1, b - 1, b y b + 1  En general, las ventajas de una son
 Si la entrada es un conjunto de valores inconvenientes de la otra
entonces hay que probar con los c) Pruebas de interfaz
valores max-1, max, max+1, min-1, min
y min+1.  Tienen lugar cuando se integran módulos o
sub-sistemas para crear sistemas mayores
Es mejor diseñar los casos de prueba usando
los dos tipos de técnicas  El objetivo es encontrar errores debidos
fallos o asunciones inválidas con respecto
1.2. Pruebas de integración
a las interfaces
 Consiste en probar sistemas completos o
 Resultan particularmente importantes para
subsistemas, formados por componentes
desarrollos orientados a objetos ya que
integrados
éstos se definen a partir de sus interfaces
 Tiene lugar después de la prueba de Tipos de interfaz
componentes
 Interfaces mediante parámetros
 Las pruebas de integración deberían ser
pruebas de caja negra derivadas de la Datos "pasados" de un componente a otro
especificación  Interfaces mediante memoria compartida
 La principal dificultades la localización de Bloques de memoria compartida entre
los errores componentes
 Una integración incremental reduce este  Interfaces procedurales
problema Un subsistema encapsula un conjunto e
Aproximaciones de integración procedimientos que pueden ser "llamados"
a) Pruebas top-down desde otro subsistema
Comienzan en el nivel superior del sistema y la  Interfaces mediante paso de mensajes
integración se realiza a partir de los niveles Los subsistemas requieren servicios de
superiores reemplazando los componentes otros subsistemas mediante el envío de un
individuales por los STUBS adecuados mensaje
b) Pruebas bottom-up Errores comunes de interfaz
Se procede a la integración de los
componentes individuales desde los niveles

U N I V E R S I D A D D E A Q U I N O B O L I V I A
21
FACULTAD DE INGENIERIA

 Mal uso de la interfaz por ejemplo eventos que provocan que el objeto cambie
parámetros en orden incorrecto o número de estado
de parámetros incorrecto Pruebas de integración
 No entendimiento de la interfaz  En sistemas orientados a objetos no hay
 Se realizan asunciones incorrectas sobre el una distinción clara en niveles(no se
comportamiento del componente al que se pueden aplicar estrategias top-down o
"llama" Errores temporales botton-up)
 El componente que realiza la llamada y el  Se utilizan las denominadas pruebas de
componente al quese llama operan con "clusters", consistentes en probar grupos
velocidades diferentes y se accede a de objetos que cooperan entre sí
información "no actualizada"  Para identificar los clusters se usa el
Guía para pruebas de interfaz conocimiento sobre las operaciones de los
objetos y las características del sistema
 Diseñar pruebas para que los parámetros
que son implementadas por dichos clusters
de un procedimiento sean ejercitados en
los valores extremos de sus rangos Pruebas de "clusters"
 Si se utilizan punteros, probar siempre con  Pruebas basadas en escenarios
punteros nulos Las pruebas se obtienen a partir de las
 En interfaces procedurales, diseñar interacciones del usuario con el sistema.
pruebas para ocasionar un fallo en el Tienen la ventaja de que permiten probar
componente Usa rpruebas de "resistencia" las características del sistema tal y como
en sistemas con paso de mensajes las utilizan los usuarios
 En sistemas con memoria compartida,  Pruebas en "hebras"
variar el orden en el que los componentes Prueban la respuesta del sistema a
son activados Ejercitar el sistema con su eventos de entrada considerando la
carga máxima. secuencia de acciones implicadas para
Pruebas orientadas a objetos tratar dichos eventos
 Los componentes a probar son clases, que  Pruebas de interacción de objetos
se instanciarán a objetos Se prueban secuencias de interacciones
 No son obvios los niveles en la arquitectura entre objetos que terminan cuando una
para poder utilizar estrategias top-down operación de un objeto ya no requiere los
servicios de otro objeto
 Niveles de pruebas Probar las operaciones
asociadas con los objetos Probar las clases Pruebas de "WeatherStation"
de objetos Probar grupos de objetos que  Hebra de métodos ejecutados
colaboran (clusters) CommsController:request→WeatherStation
 Probar el sistema completo :report→WeatherData:summarise Entradas
y salidas
1.3. Pruebas de clases de objetos
 Entrada de una petición de informe con la
Las pruebas de clases de objetos implican aceptación asociada y una salida final de
 Probar todas las operaciones asociadas dicho informe
con dicho objeto  Se puede proba rcreando datos ficticios y
 Asignar y consultar valores para todos los asegurándose de que en el informe se
atributos del objeto incluyen dichos datos de forma correcta
 Ejercitar el objeto en todos sus posibles  Se usarán los mismos datos para probar el
estados: se deben simular todos los objeto WeatherData
Herramientas automáticas

U N I V E R S I D A D D E A Q U I N O B O L I V I A
22
FACULTAD DE INGENIERIA

 La prueba es una fase del proceso "muy  La integración de sistemas orientados a


cara". Existen herramientas automáticas de objetos se basa en las pruebas de
prueba (testing workbenches) que permiten "clusters"
reducir el tiempo requerido para las CUESTIONARIO WORK PAPER NRO. 5
pruebas y el coste total asociado
1. Diseñar:
 La mayoría de estas herramientas deben
a) un caso de prueba de caja blanca.
ser adaptadas para servir a los propósitos
del plan de pruebas, que es muy específico b) un caso de prueba de caja negra
para cada aplicación basado en los valores límites.
 Resultan difíciles de integrar con c) un caso de prueba de interfaz de
herramientas automáticas de análisis y usuario gráfica.
diseño para el caso de uso ENTRAR EN EL SISTEMA
Puntos clave que se describe a continuación.
 Las pruebas intentan descubrir la presencia Flujo de eventos del caso de uso ENTRAR
de errores, no la ausencia de los mismos EN EL SISTEMA
Se deben probar los componentes – El usuario escribe su nombre y el password
individualmente y luego se procede a su – El sistema comprueba que existe una
integración para crear el sistema cuenta con ese nombre y password y, si es
 Las pruebas de caja negra se basan en la así, se le da permiso para entrar en el
especificación del sistema sistema.
 Las pruebas estructurales identifican casos – Si existe el nombre de usuario pero el
de prueba que permiten ejecutar todos los password es incorrecto permite reintroducir
"caminos" en un programa, asegurando el password hasta un máximo de tres
que todas las sentencias se ejecutan al veces.
menos una vez Requisitos no funcionales del caso de uso
 Los errores en la interfaz están ENTRAR EN EL SISTEMA
relacionadas principalmente con errores en – El password no debe ser visible.
los parámetros, no comprensión de la
Los nombres de usuarios sólo pueden
especificación o asunciones temporales
contener letras y como mínimo 5
inválidas
letras.
 Los sistemas orientados a objetos deben
probar las clases de objetos, sus
operaciones, atributos y estados

U N I V E R S I D A D D E A Q U I N O B O L I V I A
23
FACULTAD DE INGENIERIA

PROGRAMA DE CONTROL DE CALIDAD

WORK PAPER # 6

UNIDAD O TEMA: Planificación de proyectos de software y gestión de riesgos


TITULO: Riesgos del software (Primera Parte)
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: 2do Parcial

1. Introducción de la planificación temporal y al éxito en


general? Para terminar, nos enfrentamos con
En su libro sobre análisis y gestión del riesgo,
elecciones ¿qué métodos y herramientas
Robert Charette presenta la siguiente
deberíamos emplear, cuánta gente debería
definición de riesgo:
estar implicada, qué importancia hay que darle
En primer lugar, el riesgo afecta a los futuros a la calidad?
acontecimientos. El hoy y el ayer están más
Peter Drucker dijo una vez: "Mientras que es
allá de lo que nos pueda preocupar, pues ya
inútil intentar eliminar el riesgo y cuestionable
estamos cosechando lo que sembramos
el poder minimizarlo, es esencial que los
previamente con nuestras acciones del
riesgos que se tomen sean los riesgos
pasado. La pregunta es, podemos por tanto,
adecuados". Antes de poder identificar los
cambiando nuestras acciones actuales, crear
"riesgos adecuados" que se pueden tomar en
una oportunidad para una situación diferente y,
un proyecto de software, es importante poder
con suerte, mejor para nosotros en el futuro.
identificar todos los riesgos que sean obvios a
Esto significa, en segundo lugar, que el riesgo
jefes de proyectos y profesionales del
implica cambio, que puede venir dado por
software.
cambios de opinión, de acciones, de lugares...
En tercer lugar, el riesgo implica elección y la Estrategias de riesgo reactivas y proactivas
incertidumbre que entraña la elección. Por
Las estrategias de riesgo reactivas se han
tanto, el riesgo, como la muerte, es una de las
denominado humorísticamente "Escuela de
pocas cosas inevitables de la vida.
gestión del riesgo de Indiana Jones". En las
Cuando se considera el riesgo en el contexto películas, Indiana Jones, cuando se enfrentaba
de la ingeniería del software, los tres pilares a una dificultad insuperable, siempre decía
conceptuales de Charette se hacen "¡No te preocupes, pensaré en algo!". Nunca
continuamente evidentes. El futuro es lo que se preocupaba de los problemas hasta que
nos preocupa, ¿qué riesgos podrían hacer que ocurrían, entonces reaccionaba como un
nuestro proyecto fracasara? El cambio es héroe.
nuestra preocupación ¿cómo afectarán los
Como el jefe del proyecto de software
cambios en los requisitos del cliente, en las
normalmente no es Indiana Jones y los
tecnologías de desarrollo, en los ordenadores
miembros de su equipo no son sus fiables
a las que van dirigidas, el proyecto y todas las
colaboradores, la mayoría de los equipos de
entidades relacionadas con él, al cumplimiento
software confían solamente en las estrategias

U N I V E R S I D A D D E A Q U I N O B O L I V I A
24
FACULTAD DE INGENIERIA

de riesgo reactivas. En el mejor de los casos, proyecto se hacen realidad, es probable que la
la estrategia reactiva supervisa el proyecto en planificación temporal del proyecto se retrase y
previsión de posibles riesgos. Los recursos se que los costos aumenten. Los riesgos del
ponen aparte, en caso de que pudieran proyecto identifican los problemas potenciales
convertirse en problemas reales. Pero lo más de presupuesto, planificación temporal,
frecuente es que el equipo de software no personal (asignación y organización), recursos,
haga nada respecto a los riesgos hasta que cliente y requisitos y su impacto en un proyecto
algo va mal. Después el equipo vuela para de software.
corregir el problema rápidamente. éste es el
Los riesgos técnicos amenazan la calidad y
método denominado a menudo "de bomberos".
la planificación temporal del software que hay
Cuando falla, "la gestión de crisis" entra en
que producir. Si un riesgo técnico se convierte
acción y el proyecto se encuentra en peligro
en realidad, la implementación puede llegar a
real.
ser difícil o imposible. Los riesgos técnicos
Una estrategia considerablemente más identifican problemas potenciales de diseño,
inteligente para el control del riesgo es ser implementación, de interfaz. verificación y de
proactivo. La estrategia proactiva empieza mantenimiento. Además. las ambigüedades de
mucho antes de que comiencen los trabajos especificaciones, incertidumbre técnica,
técnicos. Se identifican los riesgos potenciales, técnicas anticuadas y las "tecnologías punta"
se valoran su probabilidad y su impacto y se son también factores de riesgo. Los riesgos
establece una prioridad según su importancia. técnicos ocurren porque el problema es más
Después el equipo de software establece un difícil de resolver de lo que pensábamos.
plan para controlar el riesgo. El primer objetivo Los riesgos del negocio amenazan la
es evitar el riesgo, poco común no se pueden viabilidad del software a construir Los riesgos
evitar todos los riesgos. el equipo trabaja para del negocio a menudo ponen en peligro el
desarrollar un plan de contingencia que le proyecto o el producto. Los candidatos para los
permita responder de una manera eficaz y cinco principales riesgos del negocio son:
controlada. A lo largo de lo que queda de este
1. Construir un producto o sistema excelente
work paper, estudiamos la estrategia proactiva
que no quiere nadie en realidad (riesgo de
para el control de riesgos.
mercado).
2. Riesgos del software
2. Construir un producto que no encaja en la
Se han producido amplios debates sobre la estrategia comercial general de la
definición adecuada para riesgo de software, y compañía (riesgo estratégico).
hay acuerdo común en que el riesgo siempre
3. Construir un producto que ei departamento
implica dos características:
de ventas no sabe cómo vender.
• Incertidumbre: El acontecimiento que
4. Perder el apoyo de una gestión experta
caracteriza al riesgo puede o no puede
debido a cambios de enfoque o a cambios
ocurrir; por ejemplo, no hay riesgos de un
de personal (riesgo de dirección).
100 por ciento de probabilidad.
5. Perder presupuesto o personal asignado
• Pérdida: Si el riesgo se convierte en una
(riesgos de presupuesto).
realidad, ocurrirán consecuencias no
deseadas o pérdidas. Es extremadamente importante recalcar que
no siempre funciona una categorización tan
Cuando se analizan los riesgos es importante
sencilla. Algunos riesgos son simplemente
cuantificar el nivel de incertidumbre y el grado
imposibles de predecir. Otra categorización
de pérdidas asociado con cada riesgo. Para
general de los riesgos ha sido propuesta por
hacerlo, se consideran diferentes categorías
Charette. Los riesgos conocidos son todos
de riesgos.
aquellos que se pueden descubrir después
Los riesgos del proyecto amenazan al plan
de una cuidadosa evaluación del plan del
del proyecto. Es decir, si los riesgos del

U N I V E R S I D A D D E A Q U I N O B O L I V I A
25
FACULTAD DE INGENIERIA

proyecto, del entorno técnico y comercial en  Tamaño del producto: riesgos asociados
el que se desarrolla el proyecto y otras fuentes con el tamaño general del software a
de información fíables (por ej.: fechas de construir o a modificar.
entrega poco realistas, falta de especificación
de requisitos o de ámbito del software, o un  Impacto en el negocio: riesgos asociados
entorno pobre de desarrollo), los riesgos con las limitaciones impuestas por la
predecibles se extrapolan de la experiencia en gestión o por el mercado.
proyectos anteriores (ej.: cambio de personal,  Características del cliente: riesgos
mala comunicación con el cliente. disminución asociados con la sofisticación del cliente y
del esfuerzo del personal a medida que la habilidad del desarrollador para
atienden peticiones de mantenimiento). comunicarse con el cliente en los
Pueden ocurrir pero son extremadamente momentos oportunos.
difíciles de identificar por adelantado.
 Definición del proceso: riesgos asociados
2. Identificación del riesgo con el grado de definición del proceso del
La identificación del riesgo es un intento software y su seguimiento por la
sistemático para especificar las amenazas al organización de desarrollo.
plan del proyecto (estimaciones, planificación  Entorno de desarrollo: riesgos asociados
temporal, carga de recursos, etc). Identificando con la disponibilidad y calidad de las
los riesgos conocidos y predecibles, el gestor herramientas que se van a emplear en la
del proyecto da un paso adelante para construcción del producto.
evitarlos cuando sea posible y controlarlos
cuando sea necesario.  Tecnología a construir: riesgos asociados
con la complejidad del sistema a construir y
Existen dos tipos diferenciados de riesgos para la tecnología punta que contiene el
cada categoría presentada en el apartado sistema.
anterior: genéricos y específicos del producto.
Los riesgos genéricos son una amenaza  Tamaño y experiencia de la plantilla:
potencial para todos los proyectos de software. riesgos asociados con la experiencia
Los específicos de producto sólo los pueden técnica y de proyectos de los ingenieros del
identificar los que tienen una clara visión de la software que van a realizar el trabajo.
tecnología, el personal y el entorno específico La lista de comprobación de elementos de
del proyecto en cuestión. Para identificar los riesgo puede organizarse de diferentes
riesgos específicos del producto se examinan maneras. Se pueden responder a cuestiones
el plan del proyecto y la declaración del ámbito relevantes de cada uno de los temas
del software y se desarrolla una respuesta a la apuntados anteriormente para cada proyecto
siguiente pregunta: ¿Qué características de software. Las respuestas a estas
especiales de este producto pueden estar preguntas permiten al planificador del
amenazadas por nuestro plan del proyecto? proyecto estimar el impacto del riesgo. Un
Tanto los riesgos genéricos como los formato diferente de lista de comprobación de
específicos del producto se deberían identificar elementos de riesgo contiene simplemente las
sistemáticamente. Tom Gilb tiene toda la razón características relevantes para cada
cuando dice: "Si no atacas activamente a los subcategoría genérica. Finalmente, se lista un
riesgos, ellos te atacarán activamente a ti", Un conjunto de "componentes y controladores del
método para identificar riesgos es crear una riesgo" junto con sus probabilidades de
lista de comprobación de elementos de riesgo. aparición. Los controladores del rendimiento,
La lista de comprobación se puede utilizar para el soporte, el coste y la planificación temporal
identificar riesgos y se enfoca en un del proyecto se estudian como respuesta a
subconjunto de riesgos conocidos y preguntas posteriores.
predecibles en las siguientes subcategorías CUESTIONARIO WORK PAPER # 6
genéricas:

U N I V E R S I D A D D E A Q U I N O B O L I V I A
26
FACULTAD DE INGENIERIA

1. ¿Qué es un riesgo? 4. ¿Por qué es importante administrar los


riesgos de un proyecto?
2. ¿Cuáles es la diferencia entre las
estrategias de riesgo reactivas y preactivas? 5. Identifique un conjunto de riesgos de un
y cuáles usted recomienda para asegurar la proyecto de sistemas de acuerdo al Impacto
calidad del producto a desarrollar? en el negocio, Tecnología a construir y
Tamaño y experiencia del equipo de
3. ¿Qué características implica el riesgo?, de
desarrollo.
dos ejemplos de cada una de ellas.

PROGRAMA DE CONTROL DE CALIDAD

WORK PAPER # 7

UNIDAD O TEMA: Planificación de proyectos de software y gestión de riesgos


TITULO: Riesgos del software (Segunda Parte)
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: 2do Parcial

A continuación se describen los tipos de  ¿Porcentaje de desviación en el tamaño


riesgos referentes al desarrollo del proyecto de del producto respecto a la medida de
software. productos anteriores?
4. Riesgos del tamaño del producto  ¿Tamaño de la base de datos creada o
Pocos gestores experimentados discutirían la empleada por el producto?
siguiente frase: El riesgo del proyecto es  ¿Número de usuarios del producto?
directamente proporcional al tamaño del
producto. La siguiente lista de comprobación  ¿Número de cambios previstos a los
de elementos de riesgo identifica riesgos requisitos del producto? ¿Antes de la
genéricos asociados con el tamaño del entrega? ¿ Después de la entrega?
producto (software):  ¿Cantidad de software reutilizado?
 ¿Tamaño estimado del producto en LDC o En cada caso, la información del producto a
FP? desarrollar debe compararse con la
 ¿Grado de seguridad en la estimación del experiencia anterior. Si ocurre una gran
tamaño? desviación del porcentaje o si las magnitudes
son similares; pero si los resultados anteriores
 ¿Tamaño estimado del producto en fueron poco satisfactorios, el riesgo es grande.
número de programas, archivos y
transacciones? 5. Riesgos del impacto en el negocio

U N I V E R S I D A D D E A Q U I N O B O L I V I A
27
FACULTAD DE INGENIERIA

Un gestor de ingeniería de una gran compañía clientes tienen diferentes necesidades.


de software colocó una placa con el texto: Algunos saben lo que quieren; otros saben lo
"¡Dios me concedió el cerebro para ser un que no quieren. Algunos están deseando saber
buen jefe de proyectos y el sentido común para todos los detalles, mientras que otros se
correr como un diablo cuando marketing quedan satisfechos con vagas promesas.
establece las fechas límite del proyecto!". Al
Los clientes tienen diferentes personalidades.
departamento de marketing le guían las
Algunos disfrutan siendo clientes (la tensión, la
consideraciones del negocio, y éstas entran a
negociación, las recompensas psicológicas de
veces en conflicto directo con las realidades
un buen producto).
técnicas. La siguiente lista de comprobación de
elementos de riesgo identifica riesgos Otros preferirían no ser clientes en absoluto.
genéricos asociados con el impacto en el Algunos aceptarían felizmente cualquier cosa
negocio: que se les entregara y le sacarían el mejor
provecho a un producto pobre. Otros se
 ¿Efecto de este producto en los ingresos quejarán amargamente cuando les falte
de la compañía? calidad; algunos darán las gracias cuando la
 ¿Viabilidad de este producto para los calidad es buena; unos pocos se quejarán por
gestores expertos? todo.
 ¿Es razonable la fecha límite de entrega? Los clientes también tienen varios tipos de
asociaciones con sus suministradores. Algunos
 ¿Número de clientes que usarán este conocen bien a sus proveedores y sus
producto y la consistencia de sus productos; otros no se han visto nunca las
necesidades relativas al producto? caras y se comunican siempre mediante
 ¿Número de otros productos/sistemas con correspondencia escrita y algunas llamadas
los que este producto debe tener telefónicas breves.
interoperatividad? Los clientes se contradicen a menudo. Quieren
todo para ayer y gratis. A menudo, el producto
 ¿Sofisticación del usuario final? se ve cogido entre las propias
 ¿Cantidad y calidad de la documentación contraindicaciones del cliente.
del producto que debe ser elaborada y Un "mal" cliente puede tener un profundo
entregada al cliente? impacto en la habilidad del equipo de software
 ¿Limitaciones gubernamentales en la para completar el proyecto a tiempo y dentro
de presupuesto. Un mal cliente representa una
construcción del producto?
amenaza significativa al plan del proyecto y un
 ¿Costos asociados por un retraso en la sustancial riesgo para el jefe del proyecto. La
entrega? siguiente lista de comprobación de elementos
de riesgo identifica riesgos genéricos
 ¿Costos asociados con un producto
asociados con diferentes clientes:
defectuoso?
 ¿Ha trabajado con el cliente
Cada respuesta para el producto a desarrollar
anteriormente?
debe compararse con la experiencia anterior.
Si se obtiene una gran desviación del  ¿Tiene el cliente una idea formal de
porcentaje o si las magnitudes son similares, lo que se requiere? ¿Se ha
pero los resultados anteriores fueron poco molestado en escribirlo?
satisfactorios, el riesgo es grande.
 ¿Aceptará el cliente gastar su tiempo
6. Riesgos relacionados con el en reuniones formales de requisitos
cliente para identificar el ámbito del
No todos los clientes son iguales. Pressman y proyecto?
Herron tratan este aspecto cuando dicen: Los

U N I V E R S I D A D D E A Q U I N O B O L I V I A
28
FACULTAD DE INGENIERIA

 ¿Está dispuesto el cliente a  ¿Se emplea este proceso del software para
establecer una comunicación fluida otros proyectos?
con el desarrolador?
 ¿Ha desarrollado o adquirido su
 ¿Está dispuesto el cliente a participar organización cursos de formación de
en las revisiones? ingeniería del software para jefes de
proyecto y personal técnico?
 ¿Es sofisticado técnicamente el área
del producto?  ¿Se ha proporcionado una copia de los
estándares de ingeniería del software
 ¿Está dispuesto el cliente a dejar a
publicados a cada desarrollador y gestor de
su personal hacer el trabajo? Es
software?
decir, ¿resistirá la tentación de mirar
por encima del hombro durante el  ¿Se han desarrollado diseños de
trabajo técnico? documentos y ejemplos para todas las
entregas definidas como parte del proceso
 ¿Entiende el cliente el proceso del
del software?
software?
 ¿Se llevan a cabo regularmente revisiones
Si la respuesta a alguna de estas
técnicas formales de las especificaciones
preguntas es "no", se debería hacer una
de requisitos, diseño y código?
investigación más profunda para valorar
el potencial de riesgo.  ¿Se llevan a cabo regularmente: revisiones
7. Riesgos del proceso técnicas de los procedimientos de prueba y
de los casos de prueba?
Si el proceso del software no está bien
definido; si el análisis, diseño y pruebas se  ¿Se documentan todos los resultados de
realizan sobre la marcha; si la calidad es un las revisiones técnicas, incluyendo los
concepto que todo el mundo estima errores encontrados y recursos
importante, pero por la que nadie actúa de empleados?
manera tangible para alcanzarla, entonces el  ¿Existe algún mecanismo para asegurarse
proyecto está en peligro. Las siguientes de que el trabajo realizado en un proyecto
preguntas se han extraído sobre la evaluación se ajusta a los estándares de ingeniería del
de la ingeniería del software desarrollado por software?
Roger Pressman & Associates. Inc. Las
preguntas se han adaptado del cuestionario de  ¿Se emplea una gestión de configuración
evaluación del proceso del software del para mantener la consistencia entre los
Instituto de Ingeniería del Software (IIS). requisitos del sistema/software, diseño,
código y casos de prueba?
Aspectos del proceso
 ¿Hay algún mecanismo de control de
 ¿Apoyan sus gestores senior unas normas cambios de los requisitos del cliente que
escritas que hagan hincapié en la impacten en el software?
importancia de un proceso estándar para el
desarrollo del software?  ¿Hay alguna declaración de trabajo
documentada, una especificación de
 ¿Ha desarrollado su organización una requisitos software y un plan de desarrollo
descripción escrita del proceso del software del software para cada subcontratación?
a emplear en este proyecto?
 ¿Se sigue algún procedimiento para hacer
 ¿Están de acuerdo los miembros del un seguimiento y revisar el rendimiento de
personal con el proceso del software tal y las subcontraciones?
como está documentado y están
dispuestos a usarlo? Aspectos técnicos

U N I V E R S I D A D D E A Q U I N O B O L I V I A
29
FACULTAD DE INGENIERIA

 ¿Se emplean técnicas de especificación de Alcanzar los límites de la tecnología es un reto


aplicaciones para ayudar en la excitante. Es el sueño de casi todos los
comunicación entre el cliente y el técnicos, porque fuerza al profesional a
desarrollador? emplear su talento al máximo. Pero también es
muy arriesgado. La ley de Murphy parece
 ¿Se emplean métodos específicos para el mantener su imperio en esta parte del universo
análisis del software? del desarrollo, haciendo extremadamente difícil
 ¿Emplea un método específico para el predecir los riesgos, y mucho menos hacer
diseño de datos y arquitectónico? ningún plan sobre ellos. La siguiente lista de
comprobación de elementos de riesgo
 ¿Está escrito su código en más de un 90 identifica riesgos genéricos asociados con la
por ciento en lenguaje de alto nivel? técnica a construir.
 ¿Se han definido y empleado reglas  ¿Es nueva para su organización la
específicas para la documentación del tecnología a construir?
código?
 ¿Demandan los requisitos del cliente la
 ¿Emplea métodos específicos para el creación de nuevos algoritmos o tecnología
diseño de casos de prueba? de entrada o salida?
 ¿Se emplean herramientas de software  ¿El software interactúa con hardware
para apoyar la planificación y el nuevo o no probado?
seguimiento de las actividades?
 ¿Interactúa el software a construir con
 ¿Se emplean herramientas de software de productos software suministrados por el
gestión de configuración para controlar y vendedor que no se hayan probado?
seguir los cambios a lo largo de todo el
proceso del software?  ¿Interactúa el software a construir con un
sistema de base de datos cuyo
 ¿Se emplean herramientas de software funcionamiento y rendimiento no se han
para apoyar los procesos de análisis y comprobado en esta área de aplicación?
diseño del software?
 ¿Demandan los requisitos del producto una
 ¿Se emplean herramientas para crear interfaz de usuario especial?
prototipos software?
 ¿Demandan los requisitos del producto la
 ¿Se emplean herramientas de software creación de componentes de programación
para dar soporte a los procesos de prueba? distintos de; los que su organización haya
 ¿Se emplean herramientas de software desarrollado hasta ahora?
para soportar la producción y gestión de la  ¿Demandan los requisitos el empleo de
documentación? nuevos métodos de análisis, diseño o
 ¿Se han establecido métricas de calidad pruebas?
para todos los proyectos de software?  ¿Demandan los requisitos el empleo de
 ¿Se han establecido métricas de métodos de 'desarrollo del software no
productividad para todos los proyectos de convencionales, tales como los métodos
software? formales, enfoques basados .... en IA y
redes neuronales?
Si la mayoría de las cuestiones anteriores se
han respondido negativamente, el proceso del  ¿Imponen excesivas restricciones de
software es débil y el riesgo es alto rendimiento los requisitos del producto?
8. Riesgos tecnológicos  ¿No está seguro el cliente de que la
funcionalidad pedida sea factible?

U N I V E R S I D A D D E A Q U I N O B O L I V I A
30
FACULTAD DE INGENIERIA

Si la respuesta a alguna de estas preguntas  ¿Es adecuada la ayuda en línea y la


es afirmativa, se debería realizar una documentación de las herramientas?
investigación más profundidad para valorar el
Si se ha contestado negativamente a la
riesgo potencial.
mayoría de las preguntas anteriores, el
9. Riesgos del entorno de desarrollo entorno de desarrollo es débil y el riesgo es
Si a un carpintero se le pidiera que construyera alto.
un mueble de calidad con una simple sierra de CUESTIONARIO WORK PAPER # 7
mano, se dudaría de la calidad del producto
1. Identifique tres riesgos respecto al tamaño
final. Las herramientas inapropiadas o
del producto que considera que tienen
ineficaces pueden estropear los esfuerzos de
mayor probabilidad de ocurrir.
incluso un experimentado profesional.
2. Identifique tres riesgos relacionados con el
El entorno de ingeniería del software soporta al
cliente que considera que mayormente
equipo del proyecto, al proceso y al producto.
ocurren.
Pero si el entorno es malo, puede ser una
fuente de riesgos significativa. La siguiente 3. Documentar todos los resultados de las
lista de comprobación de elementos de riesgo revisiones técnicas, incluyendo los errores
identifica riesgos genéricos asociados con el encontrados y recursos empleados. ¿A qué
entorno de desarrollo: tipo de riesgo corresponde?
 ¿Tenemos disponible una herramienta de 4. Para el proyecto de software que esta
gestión de proyectos de software? desarrollando en grupo, responda a las
siguientes preguntas asociadas con el
 ¿Tenemos disponible una herramienta de tamaño de la plantilla de personal y su
gestión del proceso del software? experiencia:
 ¿Existen herramientas de análisis y diseño ¿Disponemos de la mejor gente?
disponibles?
 ¿Tiene el personal todos los conocimientos
 ¿Proporcionan las herramientas de análisis adecuados?
y diseño, métodos apropiados para el
producto a construir?  ¿Tenemos suficiente personal?
 ¿Hay disponible? compiladores o
generadores de código apropiados para el  ¿Se ha asignado al personal para toda la
producto a construir? duración del proyecto?
 ¿Hay disponibles herramientas de pruebas  ¿Habrá parte del personal del proyecto que
apropiadas para el producto a construir? trabaje sólo durante parte de él?
 ¿Tenemos disponibles herramientas de  ¿Dispone el personal de las expectativas
gestión de configuración software? correctas sobre el trabajo?
 ¿Hace uso el entorno de bases de datos o  ¿Ha recibido el personal la formación
información almacenada? adecuada?
 ¿Están todas las herramientas de software  ¿Será mínimo el movimiento del personal
integradas entre sí? para permitir la continuidad?
 ¿Se ha formado a los miembros del equipo
del proyecto en todas las herramientas? Si la respuesta a alguna de estas
preguntas es "no", se debería hacer una
 ¿Existen expertos disponibles para investigación más profunda para valorar el
responder todas las preguntas que surjan potencial de riesgo.
sobre las herramientas?

U N I V E R S I D A D D E A Q U I N O B O L I V I A
31
FACULTAD DE INGENIERIA

PROGRAMA DE CONTROL DE CALIDAD


DIF´s # 1

UNIDAD O TEMA: Gestión de proyectos


TITULO: Ingeniería del software asistida por computadora
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: 1er Parcial

Revise la siguiente bibliografía, donde usted  http://www.monografias.com/trabajos24/h


encontrará información a cerca de Ingeniería erramientas-case/herramientas-
del software asistida por computadora. case.shtml
 http://ceds.nauta.es/informes/case04.htm
 PRESSMAN, ROGER. “Ingeniería del  http://es.wikipedia.org/wiki/Herramienta_C
Software un enfoque practico”. 5ta. ASE
Edición. McGRAW-HILL. 2002. Capítulo  http://www.di.uniovi.es/~cueva/investigaci
31. Ingeniería del software asistida por on/lineas/CASE/index.html
computadora

CONCLUSIONES (deberán sintetizar la opinión del grupo):

COMENTARIOS (deberán sintetizar la opinión del grupo

U N I V E R S I D A D D E A Q U I N O B O L I V I A
32
FACULTAD DE INGENIERIA

GRUPO (máximo cinco integrantes):


AP. PATERNO AP. MATERNO NOMBRES FIRMA

PROGRAMA DE CONTROL DE CALIDAD


DIF´s # 2

UNIDAD O TEMA: Gestión de proyectos


TITULO: El futuro del software
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: Examen final

Revise los siguientes libros de texto y páginas Edición. McGRAW-HILL. 2002. Capítulo
Web, donde usted encontrará información a 32. Perspectivas futuras
cerca de el futuro del software.  http://www.microsoft.com/spain/sharedsou
rce/Articles/Future.mspx
 PRESSMAN, ROGER. “Ingeniería del  http://pulsar.unizar.es/gluz/manual-
Software un enfoque practico”. 5ta. sl/x199.html

CONCLUSIONES (deberán sintetizar la opinión del grupo):

U N I V E R S I D A D D E A Q U I N O B O L I V I A
33
FACULTAD DE INGENIERIA

COMENTARIOS (deberán sintetizar la opinión del grupo

GRUPO (máximo cinco integrantes):


AP. PATERNO AP. MATERNO NOMBRES FIRMA

PROGRAMA DE CONTROL DE CALIDAD

DIF´s # 3

UNIDAD O TEMA: Reingeniería


TITULO: Reingeniería del software
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: Examen final

Revise los siguientes libros de texto y páginas Edición. McGRAW-HILL. 2002. Capítulo
Web, donde usted encontrará información a 30. Reingeniería.
cerca de los Diagramas de Colaboración.  http://alarcos.inf-
cr.uclm.es/doc/ISOFTWAREI/Tema16.p
 PRESSMAN, ROGER. “Ingeniería del df
Software un enfoque practico”. 5ta.

U N I V E R S I D A D D E A Q U I N O B O L I V I A
34
FACULTAD DE INGENIERIA

 http://www.tribunalmmm.gob.mx/conferenc  http://www.conocimientosweb.net/dcmt/fic
ias/2ReunionInformatica/txtConfeHidalg ha11385.html
o.htm

CONCLUSIONES (deberán sintetizar la opinión del grupo):

COMENTARIOS (deberán sintetizar la opinión del grupo

GRUPO (máximo cinco integrantes):


AP. PATERNO AP. MATERNO NOMBRES FIRMA

U N I V E R S I D A D D E A Q U I N O B O L I V I A
35
FACULTAD DE INGENIERIA

PROGRAMA DE CONTROL DE CALIDAD


DIF´s # 4

UNIDAD O TEMA: Aseguramiento de la calidad del software


TITULO: Normas de calidad
FECHA DE ENTREGA:
PERIODO DE EVALUACIÓN: Examen final

Revise los siguientes libros de texto y páginas  http://gidis.ing.unlpam.edu.ar/downloads/p


Web, donde usted encontrará información a dfs/Calidad_software.PDF
cerca de normas de calidad del SW.  http://www.buscarportal.com/articulos/iso_
9001_gestion_calidad.html
 PRESSMAN, ROGER. “Ingeniería del  http://www.kmkey.com/productos/kmkey-
Software un enfoque practico”. 5ta. ISO
Edición. McGRAW-HILL. 2002.

CONCLUSIONES (deberán sintetizar la opinión del grupo):

U N I V E R S I D A D D E A Q U I N O B O L I V I A
36
FACULTAD DE INGENIERIA

COMENTARIOS (deberán sintetizar la opinión del grupo

GRUPO (máximo cinco integrantes):


AP. PATERNO AP. MATERNO NOMBRES FIRMA

U N I V E R S I D A D D E A Q U I N O B O L I V I A
37

También podría gustarte