INSTITUTO TECNOLÓGICO DE TUXTEPEC

Calidad de los sistemas de información

Unidad I. Introducción a la gestión de servicios en TI

MCyTE. María de los Ángeles Martínez Morales

 Unidad 2. Calidad enfocada al desarrollo
de sistemas de información
2.1. Calidad en los sistemas de información.
2.2. Defectos y errores de calidad en los sistemas de información.
2.2.1. El cuaderno de registro de defectos.
2.2.2. Contabilización de defectos y errores.
2.2.3. Formas de encontrar y corregir defectos.
2.2.4. El costo de encontrar y corregir defectos.
2.3. Listas de comprobación.
2.4. Gestión del tiempo para el desarrollo de sistemas de información.
2.5. Obtener calidad en los sistemas de información (métodos, métricas,
metodologías, estándares).
2.6. Controlar la calidad del sistema de información.
2.7. Costo de calidad de los sistemas de información.
Competencia especifica a desarrollar

Conoce y aplica
técnicas y
herramientas para el
medir la calidad de
un sistema de
información.
 Actividades de aprendizaje

No. Evidencia %
1 Exposición sobre las actividades para medir la calidad en los sistemas 40%
de información.
2 Reporte de medición de la calidad (método o herramienta de medición 20%
de la calidad)
3 Cuaderno de registro
4 Diagrama de red
5 Tabla de tiempo
6 Reporte semanal de actividades
7 Portafolio de evidencias 10%
8 Evaluación 20%
9 Asistencia 10%
2.1. Calidad en los sistemas de
información.
Actualmente, las
organizaciones
empresariales son
concebidas como entidades
procesadoras de
información,
independientemente de su
actividad, ya que todas las
empresas tienen necesidad
de obtener y analizar
información actualizada
sobre mercados, costos,
ventas y procesos de
producción.
 2.1. Calidad en los sistemas de
información.

La información procede
tanto de fuentes internas
como externas a la
organización y una vez
procesada y utilizada,
genera , a su vez nueva
información que será
difundida dentro y
fuera de la empresa.
 2.1. Calidad en los sistemas de
información.
 Para toda organización empresarial resulta
imprescindible la implantación de un Sistema de
Información dinámico, garante de una información
efectiva y de calidad, a fin de que la Toma de
Decisiones se realice con el mínimo error posible.

 Si el sistema resulta efectivo, la empresa será

competitiva en su ámbito, pues generará un
producto o servicio de calidad.
 2.1. Calidad en los sistemas de
información.

Sistema de Sistema de
Información Producción

Materia Prima

Bruto Conocimiento

Consumidor/Usuario
 2.1. Calidad en los sistemas de
información.

 Un SI resulta ser un conjunto de procedimientos

ordenados, que proporcionan información efectiva
para apoyar la toma de decisiones y con ello
asegurar el control de la organización.
 2.1. Calidad en los sistemas de
información.

Elementos que conforman el SI:

Humano Información

Soporte
Físico del
sistema
 2.1. Calidad en los sistemas de
información.
 Hablar hoy se SI, es hablar de un sistema que
gestiona y controla los flujos informativos por los
que debe distribuirse una información de calidad,
que reduce el riesgo de error en la Toma de
Decisiones; y hablar de información de calidad
implica tener en cuenta el concepto de Calidad
Total que conlleva a una cultura de trabajo, y el
nacimiento de nuevas estructuras empresariales.
 2.1. Calidad en los sistemas de
información.
 La calidad la define el cliente.
 La empresa debe estar en constante cambio para
adaptarse a las necesidades del cliente y seguir
siendo competitiva.
 Es fundamental compartir información, para evitar
que haya estancamiento, y se pueda generar
retroalimentación que pueda prevenir errores antes
de que se produzcan.
 2.1. Calidad en los sistemas de
información.
 ¿Qué es más dañino?
 Tener un empleado que realiza de forma
rutinaria y burocrático su trabajo
 Tener un empleado autosatisfecho que
piensa que ya no le queda nada por
aprender
 Evidencia 1 Valor 20%

 Todos los equipos llevaran a cabo la exposición del

mismo tema.
 Exposición sobre la a relación entre ingeniería de
software y calidad de los sistemas de información.
 2.1. Calidad en los sistemas de
información.
 Los sistemas de información son diseñados para
satisfacer las necesidades que existen en cualquier
organización.

 Es decir, son sistemas que toman datos de la

organización para una vez manipulados y analizados
producir nueva información que apoye a la toma de
decisiones, combinando metas, operaciones, productos
o relaciones con el entorno de dichas organizaciones
para así lograr ventaja sobre la competencia
 2.1. Calidad en los sistemas de
información.
Morera (2006), establece
que la calidad en los
sistemas de información se
debe considerar como una
responsabilidad que tiene
que ser compartida por
todos los usuarios internos
de la organización.
 2.1. Calidad en los sistemas de
información.

¿Cómo pueden
contribuir los sistemas
de información a la
administración de la
calidad?
 2.1. Calidad en los sistemas de
información.
Los sistemas de
información son la
clave para hacer
que la información
se encuentre
disponible de
manera oportuna
y en formato útil
para quienes la
necesitan para los
fines de calidad.
 2.1. Calidad en los sistemas de
información.
 Funciones de un sistema de información:

1. Procesamiento de transacciones
2. Definición de archivos
3. Mantenimiento de archivos
4. Generación de reportes
5. Procesamientos de consulta
6. Mantenimiento de la integridad de los datos
 2.1. Calidad en los sistemas de
información.

Causas de éxito y fracaso de los SI

 ÉXITO  Inadecuada operación
 Nivel de utilización del de los SI
sistema  Insuficiente o inadecuada
 Satisfacción de los usuarios participación de los
internos usuarios internos en el
 Actitudes favorables de los diseño del sistema
usuarios internos acerca del  Falta de apoyo por parte
personal de sistemas
de la dirección
 Objetivos alcanzados
 Débil administración en el
 Retribución financiera para proceso de implantación
la organización
 Alta complejidad y riesgo
 2.1. Calidad en los sistemas de
información.
 ¿Cuál es un nivel factible y aceptable, desde un
sentido tecnológico, de calidad de un sistema?

 ¿En qué punto deben decir los gerentes de sistemas:

“Dejen de probar, ya hicimos todo lo que pudimos
para perfeccionar este software. ¡Embárquenlo!”?
 2.1. Calidad en los sistemas de
información.
 Es posible hacer responsables a los individuos y las
organizaciones por consecuencias que se puedan
evitar y prever, lo cual tienen el deber de percibir
y corregir.

 Y el área gris es que algunos errores de sistemas

son predecibles y corregibles sólo mediante un
costo muy alto, tan alto que no es económicamente
viable buscar este nivel de perfección; nadie
podría costear el producto.
 2.1. Calidad en los sistemas de
información.

Por ejemplo, aunque las compañías de software tratan de

depurar sus productos antes de liberarlos al mercado, están
conscientes de que embarcan productos defectuosos debido a
que el tiempo y costo para corregir todos los errores pequeños
evitaría que estos productos se liberaran algún día.
 2.1. Calidad en los sistemas de
información.
 ¿Qué pasaría si el producto no se ofreciera en el mercado?

 ¿Acaso no podría avanzar el bienestar social en su totalidad y tal vez hasta

decaería?

 ¿cuál es la responsabilidad de un productor de servicios de computadora?

 ¿Debería retirar el producto que nunca podrá ser perfecto, advertir al

usuario u olvidarse del riesgo (dejar que el comprador se preocupe)?
 2.1. Calidad en los sistemas de
información.
 Las tres principales fuentes de un mal desempeño del
sistema de acuerdo a Laudon y Laudon (2012) son:

1. Bugs y errores de software,

2. Fallas de hardware o de las instalaciones

provocadas por casusas naturales o de otro tipo y

3. Mala calidad de los datos de entrada.

 2.2.Defectos y errores de calidad en los
sistemas de información.
Los programas informáticos
nos facilitan la vida, pero
cuando fallan pueden traer
consecuencias
catastróficas, incluso
muerte y destrucción a
gran escala.
2.2.Defectos y errores de calidad en los
sistemas de información.
2.2.Defectos y errores de calidad en los
sistemas de información.
2.2.Defectos y errores de calidad en los
sistemas de información.
2.2.Defectos y errores de calidad en los
sistemas de información.
 2.2.Defectos y errores de calidad en los
sistemas de información.
Zonas que pueden ser silvestres o pobladas. Por tanto
es claro que la construcción de una represa es difícil
debido a la cantidad de su problemas que originan
como consecuencia de las operaciones de
construcción.
 2.2.Defectos y errores de calidad en los
sistemas de información.
 Si hablamos del impacto del software es necesario
conocer varios conceptos que vienen relacionados
con un mal diseño de este los cuales son:

 Error

 Defecto

 Falla
 2.2.Defectos y errores de calidad en los
sistemas de información.
 Trabajo del ingeniero del SW es entregar productos:
 Alta calidad
 Costes establecidos
 Plazo determinado

 Necesidades:
 Planificar el trabajo
 Ejecutar acorde a un plan
 Esforzarse para producir productos de máxima calidad

 IMPORTANCIA
 Crisis del Software
 Criticidad creciente del software en las organizaciones
 2.2.Defectos y errores de calidad en los
sistemas de información.
 DISCIPLINA DE TRABAJO:
 Disciplina: Actividad o ejercicio que desarrolla o mejora habilidades.
 PSP. ¿Competencia Básica?
 IMPORTANCIA DEL TRABAJO DE ALTA CALIDAD
 En el software las condiciones inusuales se presentan siempre
 Cada ingeniero ha de producir programas de calidad
 MEJORA DE LA CALIDAD
 Para mejorar debes cambiar lo que haces normalmente
 PROCESO DE MEJORA
Definir el objetivo de Medir la calidad del Comprender el
Ajustar el proceso
calidad producto proceso

Usar el proceso
ajustado

Medir los resultados

Comparar resultados
y obejtivos
 2.2.Defectos y errores de calidad en los
sistemas de información.
 Ejercicio
TAREA FRECUENCIA TIEMPO
Ir a la trabajar Diaria 20h/Semana
Trabajo en casa Diario 20h/Semana
Trasladarme al trabajo Diario 1h/Semana
Preparar clases Semanal 20h/Semana
Hacer tesis Semanal 20h/Semana
 2.2.Defectos y errores de calidad en los
sistemas de información.
 El termino defecto se refiere a algo que está equivocado en un
programa, tal como un error sintáctico, una falta tipográfica, un
error de puntuación, o una sentencia incorrecta del programa. Los
defectos pueden estar en los programas, en los diseños o incluso en
los requisitos, las especificaciones o en otra documentación.

 Los defectos pueden ser sentencias extra o redundantes, sentencias

incorrectas o secciones del programa omitidas. Un defecto, es
cualquier cosa que reduce la capacidad de los programas para
cumplir completa y efectivamente las necesidades de los usuarios.
Un defecto es una cosa objetiva. Es algo que puedes identificar,
describir y contabilizar.
 2.2.Defectos y errores de calidad en los
sistemas de información.
 Un defecto es la causa de un fallo.
 Es algo en el producto que:
 Está, pero no debe.

 No está, pero debe.

 No está como debe estar.

 Un defecto es algo OBJETIVO que está equivocado en un programa:

 Error sintáctico, falta tipográfica, error de puntuación, ...

 Pueden estar en los programas, en los diseños o incluso en los requisitos.
 Los errores causan defectos, y todos provienen de errores humanos.
 Es decir, las personas cometen errores y los programas tienen defectos.
 2.2.Defectos y errores de calidad en los
sistemas de información.
 Un defecto es una anomalía física (defecto,
imperfección) en el software, en el hardware o en
los datos que tiene el potencial de causar errores y
fallos .

 Ejemplos de defectos incluyen cortos en circuitos de

hardware, o la división entre cero en un fallo de
software. Los defectos son las causas de los errores,
pero no todo defecto llevan a un error. Un defecto
se dice activo cuando produce un error.
 2.2.Defectos y errores de calidad en los
sistemas de información.
TIPOLOGÍA DE DEFECTOS
No. Tipo Nombre Tipo Descripción
10 Documentación Comentarios, mensajes
20 Sintaxis Ortografía, puntuación, erratas, formato de instrucciones
30 Construir Gestión del cambio, librerías, control de versiones
40 Asignación Declaración, duplicidad de nombres, ámbito, límites
50 Interfaz Llamadas a procedimientos y referencias. E/S, formato de
usuarios
60 Chequeo Mensajes de error, chequeos inadecuados
70 Datos Estructura, contenido
80 Función Lógica, bucles, recursión, punteros, computación, defectos
de la función
90 Sistema Configuración, memoria, temporización
100 Entorno Diseño, compilación, pruebas y otros problemas que
soporta el sistema
 2.2.Defectos y errores de calidad en los
sistemas de información.
 El error (error) es la ocurrencia de la condición invalida o valor in correcto en el sistema. La
interacción entre el defecto y un estímulo es lo que produce el error.

 Un error es la parte del estado del sistema, que es susceptible a ocasionar un fallo.

 Un error es entonces la manifestación de un defecto en el sistema.

 Por ejemplo, una cantidad de voltaje incorrecta en un circuito es un error que puede ser causado por
un corto circuito o un valor incorrecto. Para una variable puede ser el resultado de una división entre
cero. Un error es por naturaleza temporal.

 Existen dos estados posibles de un error:

 Latente: Un error es latente mientras que no ha sido reconocido como tal.
 Detectado: Puede ser detectado por mecanismos de detección de errores que analizan el estado
del sistema, o por los efecto del error sobre el sistema.
 2.2.Defectos y errores de calidad en los
sistemas de información.
 Una falla (failure) de un sistema se da cuando el
mismo no se comporta como esta especificado.

 Múltiples errores se pueden originar de un defecto.

Si se ve al sistema como un conjunto de componentes,
los errores en un componente pueden transformarse
en fallas, que originan defectos que se propagan a
más componentes a través del sistema.
 2.2.Defectos y errores de calidad en los
sistemas de información.
 El tiempo entre la aparición de un defecto y la
primera manifestación de un error se llama latencia
de defecto. El tiempo entre la ocurrencia de un
error y que el mismo es detectado se llama latencia
de error.

Defecto Error Falla

Latencia de defecto Latencia de error

2.2.1. El cuaderno de registro de defectos.

 Está diseñado para ayudarte a reunir datos de defectos.

 Utiliza este cuaderno para reunir datos de defectos para

cada programa que codifiques.

 Describe cada defecto con bastante detalle para que

puedas entenderlo más adelante.

 Después de haber terminado cada programa, analiza los

datos para ver dónde has introducido y eliminado los
defectos y qué tipos de defectos causan los principales
problemas.
2.2.1. El cuaderno de registro de defectos.

 Defecto  Algo equivocado … sintáctico, tipográfico,

incorrección…

 En requisitos, diseños, codificaciones…

 Encontrar defectos antes de entregar el producto final

 El que escribe está + capacitado para encontrar el

defecto
 Los defectos salen a la luz de forma imprevisible

 Si no tratas de no tener defectos, no lo conseguirás

2.2.1. El cuaderno de registro de defectos.

Instrucciones para el cuaderno de registro de defectos

PROPÓSITO Utiliza esta tabla para mantener los datos de cada defecto que
encuentres y corrijas.
Utiliza estos datos para completar el Resumen del Plan del Proyecto.
MÉTODO Anota todas las revisiones, compilaciones y pruebas de defectos en este
cuaderno.
Anota cada defecto de forma separada y completa.
Si necesitas espacio adicional, utiliza otra copia de la tabla.
CABECERA Introduce los siguientes datos:
• Tu nombre
• Fecha actual
• Nombre del profesor
• Número de programa
 2.2.1. El cuaderno de registro de defectos.

Instrucciones para el cuaderno de registro de defectos

FECHA Anota la fecha en la que se encontró el defecto.
NÚMERO Número de cada defecto.
Para cada programa, utiliza una numeración secuencia, comenzando
por el 1 (0 001, etc).
TIPO Anota el tipo de defecto, según la lista de tipos de defectos .
Utiliza tu criterio para seleccionar que tipo aplicar.
INTRODUCIDO Anota la fase en la que se introdujo el defecto.
Utiliza tu criterio
ELIMINADO Anota la fecha en la que se eliminó el defecto.
Generalmente, ésta sería la fase durante la cual encontraste y
corregiste el defecto.
 2.2.1. El cuaderno de registro de defectos.

Instrucciones para el cuaderno de registro de defectos

TIEMPO DE Estima o mide el tiempo necesario para encontrar y corregir el defecto.
CORRECCIÓN Puedes utilizar un cronometro si lo deseas.
DEFECTO Puedes ignorar esta casilla la primera vez.
CORREGIDO Si introduces este defecto mientras estás arreglando otro, anota el
número del defecto incorrectamente corregido.
Si no puedes identificar el número de defecto, anota una X en la
casilla de Defecto corregido.
DESCRIPCIÓN Escribe una breve descripción del defecto.
Haz la descripción lo suficientemente clara para que recuerde
posteriormente, el error que causó el defecto y por qué o hiciste.
2.2.1. El cuaderno de registro de defectos.
2.2.1. El cuaderno de registro de defectos.
2.2.1. El cuaderno de registro de defectos.
 2.2.2. Contabilización de defectos y
errores.
 Uso del cuaderno de defectos.
 Mejorar la programación
 Reducir el número de defectos en tus programas

 Ahorrar tiempo

 Ahorrar dinero

 Hacer tu trabajo de forma responsable

 Proceso del PSP Actualizado (Resumen plan proyecto)

 2.2.2. Contabilización de defectos y
errores.

Las anotaciones en el
cuaderno deben basarse
sólo en las correcciones
que se hacen (un solo
despiste, p. eje. Un punto
y coma) puede provocar
varios errores, pero la
corrección es sólo una .
 2.2.2. Contabilización de defectos y
errores.
Por otro lado, el diseño
puede sufrir cambios
durante el desarrollo
debido a la aparición
de ideas mejores u
optimizaciones (o,
simplemente, cambios en
el parecer del cliente
que también ocurre con
más frecuencia de la
deseada).
 2.2.2. Contabilización de defectos y
errores.

Cometer un error en los

requisitos, con lo que
sería un defecto de
requisitos
 2.2.2. Contabilización de defectos y
errores.

Se considera defecto
aquellos que aparecen
tras la codificación (si se
nota algo mientras se
está codificando y se
corrige antes determinar,
no se considera defecto).
 2.2.2. Contabilización de defectos y
errores.
 Conviene contabilizar los defectos cuando se termine
cada fase (diseño, codificación ).

 Sin embargo, dentro de una misma fase (por ejemplo,

codificación), si se hace un módulo y luego un segundo,
y a mitad del segundo módulo se descubre un defecto
en el primero, sí es un defecto.

 Para aprender a reunir datos de defectos, conviene

comenzar por contabilizar sólo los de compilación y
pruebas hasta que se tome soltura
 2.2.3. Formas de encontrar y corregir
defectos.
 Hay varias formas para encontrar defectos en un
programa, pero en esencia tienen los siguientes
pasos:
1. Identificación de los síntomas del defecto.
2. Deducir de esos síntomas la localización del defecto.
3. Entender lo que es erróneo en el programa.
4. Decidir cómo corregir el defecto
5. Hacer la corrección
6. Verificar que se ha resuelto el problema
 2.2.3. Formas de encontrar y corregir
defectos.
 Con el compilador.
 Pero no detecta los errores semánticos.
 Mediante pruebas.
 Las pruebas de unidad encuentra sobre el 50% de los
defectos lógicos.
 Las de sistema entre un 30% y un 40%. Pero no podemos
probar todos los casos.
 La más común de todas: Que los detecten los usuarios.
 Durante un año, IBM gastó 250 millones de dólares en
reparar y reinstalar correcciones de 13,000 errores
encontrados por los usuarios: 20,000 dólares por defecto.
 2.2.4. El costo de encontrar y corregir
defectos.
 Durante la revisión, se
encuentra 1 error cada 1
ó 2 minutos.

 Durante las pruebas de

unidad, 1 error cada 10 ó
20 minutos.

 En las pruebas de
integración, 10 a 40 horas.
 2.2.4. El costo de encontrar y corregir
defectos.
 Dedicarás el mismo tiempo antes o después de
compilar.

 Antes de la revisión, dedicarás entre un 12% y un

15% del tiempo a compilar.

 Después un 3% o menos.

 Una vez compilado el programa, la revisión no es tan

completa.
 2.2.4. El costo de encontrar y corregir
defectos.
 La compilación es igualmente efectiva antes o
después de la revisión del código.

 La experiencia indica que cuando un programa

tiene muchos defectos durante la compilación,
generalmente tienen muchos defectos en las
pruebas
 2.2.4. El costo de encontrar y corregir
defectos.
 Encontrar los defectos lo antes posible
 No parchear
 Podemos arreglarlo más tarde… NO!!!

 El coste de encontrar los defectos crece

exponencialmente por fase de desarrollo
 2.2.4. El costo de encontrar y corregir
defectos.
Guion para la revisión
Criterios de entrada • Especificaciones de requisitos
• Diseño del programa
• Estándares de codificación
Procedimiento de revisión • Escribe el código fuente completo
• Imprime el código
• Revisa el código chequeando cada línea
Corregir efectos • Corregir defectos encontrados
• Comprobar las correcciones para asegurar su corrección
• Anotar los defectos en el Cuaderno de Registro de
Defectos
Revisar ámbito • Verificar diseño VS especificación de requisitos
• Verificar que el código fuente implementa todo el
diseño
 2.2.4. El costo de encontrar y corregir
defectos.
Guion para la revisión
Revisar lógica de • Verifica si el diseño lógico es correcto
programa • Verifica que el programa implementa correctamente el
diseño lógico
Comprobar nombres y • Verifica que los nombres y tipos se declaran y usan
tipos correctamente
• Chequea la declaración de los tipos de datos int, long
int y float

Comprobar todas las • Asegura la inicialización correcta de variables

variable • Chequea los desbordamientos y fuera de rango
Comprobar la sintaxis • Verifica que el código cumple las especificaciones del
lenguaje
Criterios de salida • Código terminado y corregido
• Cuaderno de Registro de tiempos completo
• Cuaderno de Registro de defectos completo
 2.3. Listas de comprobación.

 La clave para realizar una revisión de código efectiva

es tener un procedimiento de revisión eficiente.

 Por qué ayudan las Listas de Comprobación.

 Una lista de comprobación contiene una serie de pasos de

procedimiento que quieres seguir de forma precisa.
 Cuando las personas tienen cosas importantes que quieren
hacer exactamente tal y como están especificadas, a
menudo, utilizan las listas de comprobación.
 2.3. Listas de comprobación.

 Los pilotos de líneas aéreas, por ejemplo, las utilizan

para hacer una comprobación prevuelo antes de
despegar.

 Aunque hayan hecho una comprobación del mismo avión

una hora antes, la vuelven a hacer.

 Un estudio de los accidentes en una base de las Fuerzas

Aéreas de los EE.UU., encontró que en cada caso, la
lista de comprobación pre-vuelo no se había seguido
rigurosamente.
 2.3. Listas de comprobación.

 Cuando es esencial encontrar y corregir cada

defecto en un programa, debes seguir un
procedimiento preciso.

 Una lista de comprobación te puede ayudar a

asegurarte de que se sigue el procedimiento.
 2.3. Listas de comprobación.

 Pueden ser una fuente de ideas.

 Cuando sigues una lista de comprobación personal, sabes
cómo revisar tu código.
 Si utilizas la lista correctamente, también sabes cuantos
defectos encuentras en cada paso de dicha lista.
 Comparar tu lista de comprobación con las de otros
ingenieros, te puede sugerir aproximaciones útiles para la
revisión.
 a lista de comprobación encapsula la experiencia personal.
 Utilizándola con regularidad y mejorándola, mejorarás en la
detección de los defectos de tus programas.
 La lista de comprobación también te ayudará a encontrar
estos defectos en menos tiempo.
2.3. Listas de comprobación.
2.3. Listas de comprobación.
 2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Probablemente harás esta semana lo mismo que hiciste la semana pasada.

 Para hacer un plan realista, tienes que controlar tu forma de gastar tu

tiempo.

 Para comprobar la exactitud de tus estimaciones de tiempo y planes, debes

documentarlas y posteriormente compararlas con la que realmente haces.

 Para hacer más precisos tus planes, determina las equivocaciones de los
planes anteriores, y qué podrías haber hecho para mejorar.

 Para gestionar tu tiempo, planifica tu tiempo y sigue el plan.

 saber dónde estaba equivocado el plan
 harás el trabajo dela forma que lo has planificado
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Comprende cómo utilizas el tiempo
 Clasificatus principales actividades(3 a 5 categorías).
 Registra el tiempo dedicado a cada una de las
actividades principales.
 Registra el tiempo de forma normalizada.

 Guarda los datos de tiempo en un lugar adecuado

(Cuaderno de ingeniería).
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Cuaderno de ingeniería o cuaderno del Ingeniero de Software
 Control de tiempo, tomar notas, cuaderno de trabajo, ideas…
 EVIDENCIA del trabajo  Protección de activos intelectuales
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Para gestionar tu tiempo
efectivamente, necesitas planificar
tu tiempo y seguir el plan.

 Para hacer planes realistas,

primero tendrás que controlar la
forma de utilizar el tiempo.

 Debes documentar tus planes y

compararlos con lo que haces
realmente.

 Para mejorar la precisión de tu

planificación, determina los
errores de los planes anteriores y
qué podrías hacer para mejorar el
plan.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
¿Por qué controlar el tiempo?

 Laforma de mejorar la calidad

de tu trabajo comienza por
entender que haces realmente.

 Por lo que tienes que conocer:

que haces, cómo lo haces y los
resultados que obtienes.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Seguimiento del tiempo
 Se debe saber establecer las tareas que interesa
medir.
 El objetivo es saber el tiempo real que se esta
gastando.
 La unidad de medida del tiempo debe ser minutos.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Gestión de las interrupciones
 Todo el tiempo somos interrumpidos.
 llamadas telefónicas,
 personas que quieren charlar,

 molestias ocasionales o

 la necesidad de descansar
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
C = Completada
U = Unidades
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Ideas para registrar su tiempo
 Llevar siempre contigo el cuaderno de notas
 Cuando ocasionalmente olvides registrar la hora de
comienzo, la hora de fin o la duración de la
interrupción, haz una estimación tan pronto como lo
recuerdes.
 Puedes utilizar un cronometro para controlar las
interrupciones. Aunque puedes registrar tiempo de
inicio y finalización de cada interrupción.
 Resume tu tiempo puntualmente.
 TAREA

 Utiliza el Cuaderno de Registro de Tiempos para controlar el

tiempo que dedicas a las distintas actividades de este semestre.

 Como parte de este ejercicio, examina la lista de actividades que

pusiste en el Ejercicio Anterior y ajústalas si es necesario.

 Entrega la próxima semana una copia de tu registro

de tiempos.

 Será obligatorio entregar una copia del Cuaderno de Registro

de Tiempos cada semana desde este momento hasta el final del
semestre.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.

 Planificación
 Hay dos clases de
planificación:
 Basada en período de
tiempo (día, semana, mes
o año)
 Basada en la actividad
(desarrollar un programa,
escribir un informe)
 2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Por ejemplo, leer un libro de 20
capítulos
 Estimar el tiempo total: 20 horas

 Tiempo dedicado: 1 hora a la

semana
 Plan del producto: Leer los 20
capítulos en 20 horas.
 Plan del período: La forma de
repartir el tiempo de lectura en
incrementos semanales de 1 hora.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 Resumen semanal de actividades

 Parahacer un plan del período, es importante entender

cómo gasta tu tiempo.

 Elprimer paso es registrar tu tiempo utilizando el

Cuaderno de Registro de Tiempos.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
2.4. Gestión del tiempo para el desarrollo
de sistemas de información.
 2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

 Uno de los problemas que se afrontan actualmente en la

esfera de la computación es la calidad del software. Desde la
década del 70, este tema ha sido motivo de preocupación
para especialistas, ingenieros, investigadores y
comercializadores de software, los cuales han realizado gran
cantidad de investigaciones al respecto con dos objetivos
fundamentales:

 ¿Cómo obtener un software con calidad?

 ¿Cómo evaluar la calidad del software?
2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

 La obtención de un software con calidad implica la

utilización de metodologías o procedimientos
estándares para el análisis, diseño, programación y
prueba del software que permitan uniformar la
filosofía de trabajo, en aras de lograr una mayor
confiabilidad, mantenibilidad y facilidad de
prueba, a la vez que eleven la productividad, tanto
para la labor de desarrollo como para el control
de la calidad del software.
2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

 La política establecida debe estar sustentada sobre tres principios

básicos: tecnológico, administrativo y ergonómico.

 Primero: El principio tecnológico define las técnicas a utilizar en el

proceso de desarrollo del software.

 Segundo: El principio administrativo contempla las funciones de

planificación y control del desarrollo del software, así como la
organización del ambiente o centro de ingeniería de software.

 Tercero: El principio ergonómico define la interfaz entre el usuario y

el ambiente automatizado.
2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

 La medición es fundamental para cualquier

disciplina de ingeniería, y la ingeniería del
software no es una excepción. La medición nos
permite tener una visión más profunda
proporcionando un mecanismo para la evaluación
objetiva.
2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

Lord Kelvin dijo en una ocasión:

"Cuando puedes medir aquello
de lo que hablas, y expresarlo en
números, tú conoces algo acerca
de ello; pero cuando no puedes
medirlo, cuando no puedes
expresarlo en números, tu
conocimiento es insatisfactorio y
escaso: podría ser el comienzo
del saber, pero apenas has
avanzado en tus ideas hacia un
estado científico”.
2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

 El proceso de medición del software persigue tres

objetivos fundamentales:
1. Ayudarnos a entender que ocurre durante el
desarrollo y el mantenimiento
2. Permitirnos controlar que es lo que ocurre en los
proyectos
3. Poder mejorar los procesos y productos.

(Fenton y Pfleeger, 1997)

2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

 Park, Goethert y Florac tratan en su guía de la

medición del software las razones por las que
medimos:

Hay 4
Razones para
medir los
procesos del Caracterizar Evaluar Predecir Mejorar
software, los
productos y
los recursos:
 2.5. Obtener calidad en los sistemas de información
(métodos, métricas, metodologías, estándares).

 Beneficios de la
Medición/Evaluación
 Analizar, Comprender (los
atributos de un ente)
 Controlar (la calidad del
producto, ...)
 Predecir (el tiempo y costo de
un proyecto)
 Mejorar (la calidad de un
producto, procesos)
 2.6. Controlar la calidad del sistema de
información.
 Para controlar la calidad del software es necesario,
ante todo, definir los parámetros, indicadores o
criterios de medición, ya que, como bien plantea
Tom De Marco, "usted no puede controlar lo que
no se puede medir".
 2.6. Controlar la calidad del sistema de
información.
 Las cualidades para medir la calidad del software
son definidas por innumerables autores, los cuales
las denominan y agrupan de formas diferentes. Por
ejemplo, John Wiley define métricas de calidad y
criterios, donde cada métrica se obtiene a partir de
combinaciones de los diferentes criterios.
 2.6. Controlar la calidad del sistema de
información.
 Todos los autores coinciden en que el software posee determinados
índices medibles que son las bases para la calidad, el control y el
perfeccionamiento de la productividad.

 Una vez seleccionados los índices de calidad, se debe establecer el

proceso de control, que requiere los siguientes pasos:

 Definir el software que va a ser controlado: clasificación por tipo,

esfera de aplicación, complejidad, etc., de acuerdo con los
estándares establecidos para el desarrollo del software.

 Seleccionar una medida que pueda ser aplicada al objeto de

control: Para cada clase de software es necesario definir los
indicadores y sus magnitudes.