Capítulo 16 Aseguramiento de La Calidad Mediante Ingeniería de SW

Captulo 16
Aseguramiento de la Calidad mediante Ingeniera de

Software
OBJETIVOS

Reconocer la importancia de adoptar un enfoque de calidad total para el SDLC.
Crear diagramas de Estructura para disear sistemas modulares con un enfoque
descendente (de arriba a abajo).
Usar diversas tcnicas para mejorar la calidad del diseo y mantenimiento del
Software.
Entender la importancia de ejecutar una variedad de pruebas durante el desarrollo
de sistemas para identificar problemas desconocidos.

Enfoque de la Administracin de la
Calidad Total
Qu es Six Sigma?
Es una forma inteligente para dirigir un
negocio.
Est enfocado en tres reas principales:

Mejorar la Satisfaccin del Cliente
Reducir el Tiempo de Ciclo
Reducir los Defectos
Six Sigma
Est basado en la Medicin, Anlisis y
Mejora de los Procesos de Negocio.
Utiliza herramientas estadsticas
avanzadas.
No es slo una iniciativa de calidad,
es una Iniciativa Empresarial (Es un
Modelo de Gestin).
Requiere de un compromiso total de
la direccin y una filosofa de
excelencia.

3.4 defectos
por milln
de oportunidades
305 537 defectos
por milln
de oportunidades
697 700 defectos
por milln
de oportunidades
Calidad con Six Sigma

6 SIGMA
54.000 / ao 3 / ao
40.500 / ao 3 / ao
2 h. / mes 1 / 16 aos
27 min. / semana 6 / 100 aos
1.350 / semana 1 / 20 aos
44.000 / ao 5 / ao
Malas Recetas mdicas
Bebes que se caen
Tomar agua contaminada
Corte de seal de TV
Mala Oper. mdica
Devolucin Sacos de Azcar
3 SIGMA
Principios de Six Sigma
Enfoque genuino en el Cliente

Direccin basada en datos y hechos

Los procesos estn donde est la accin

Direccin Proactiva Sentido de Urgencia

Colaboracin sin barreras

Buscar la perfeccin, tolerar el fallo
Metodologa DMAIC
DEFINIR

MEDIR

ANALIZAR

MEJORAR

CONTROLAR

Fases de Proyecto Six Sigma
Por qu Six Sigma?
Seis Sigma integra los principios de la Calidad Total

Estructura Organizacional Six Sigma
Roles en Six Sigma
Champions:
Son altos directivos (vice-presidentes, directores generales adjuntos, etctera) que adquieren
conocimientos sobre la metodologa 6 sigma de tal forma que puedan aprobar los proyectos
y asignar los recursos necesarios para llevarlos a cabo.

Master Black-Belts:
Son consultores internos de tiempo completo, con el mayor conocimiento y experiencia en
proyectos 6 sigma. Actan como guas. Normalmente hay solamente uno por empresa, pero
organizaciones muy grandes pueden tener algunos ms.

Black-Belts:
Tambin son consultores internos de tiempo completo, aunque todava recurren al Master
Black-Belt para que revise y corrobore los resultados derivados de los estudios estadsticos.

Green Belts:
Tienen conocimientos suficientes sobre estadstica y otras herramientas para la solucin de
problemas. No trabajan de tiempo completo en 6 sigma, sino que tienen sus propias
responsabilidades y asignan una parte de su tiempo (alrededor de 20%-30%) al desarrollo de
los proyectos. Los Black-Belts los asesoran constantemente.
Responsabilidad de la Administracin de la
Calidad Total
Gran parte de la responsabilidad por la calidad de los sistemas
de informacin recae en los usuarios de stos y en los
directivos.

Para que la TQM se vuelva una realidad en los proyectos de
sistemas, deben darse dos condiciones.
1. Debe existir un apoyo organizacional incondicional por
parte de los directivos.
2. Es necesario que tanto el analista como la empresa se
comprometan desde el principio con la calidad para
lograr le meta de calidad.

Esfuerzo uniformemente controlado hacia la calidad durante
todo el ciclo de vida del desarrollo de sistemas.

Calidad Total
El apoyo organizacional para conseguir calidad en
sistemas de informacin se puede lograr al
proporcionar el tiempo en el trabajo para los
crculos de calidad de SI.
Consisten de seis a ocho pares organizacionales
especficamente responsables de considerar cmo mejorar
los sistemas de informacin y cmo implementar las
mejoras.

La administracin y usuarios deben desarrollar
lineamientos para los estndares de calidad de
sistemas de informacin.
Preferentemente los estndares se disearn cada vez que
un nuevo sistema o una modificacin mayor se proponen.

Calidad Total
Parte del trabajo del analista de sistemas es alentar a
usuarios a que cristalicen sus expectativas acerca de
los sistemas de informacin y sus interacciones con
stos.

Los estndares de calidad departamentales se deben
comunicar mediante retroalimentacin para el equipo
de anlisis de sistemas.

Los estndares de calidad para los sistemas de
informacin ayudarn al analista a evitar errores
costosos en el desarrollo de sistemas no deseados o
innecesarios.

Repaso Estructurado
Es una de las acciones de administracin de la
calidad ms eficaces que puede emprender un
equipo de anlisis de sistemas.
Los repasos estructurados son una forma de usar
expertos para:

1. Monitorear la programacin y el desarrollo
general del Sistema.
2. Sealar los problemas.
3. Permitir al programador o analista
responsable de dicha parte del sistema hacer
los cambios correspondientes.

Repaso Estructurado
Los repasos estructurados involucran por lo
menos a cuatros personas:

1. La persona responsable de la parte del
sistema o subsistema que se revisar
2. Un programador, analista o coordinador del
repaso,
3. Un programador o analista experto y
4. Un experto que toma notas acerca de las
sugerencias.
Repaso Estructurado
Especialmente adecuados en un enfoque de
administracin de la calidad total cuando se realiza
durante todo el ciclo de vista de desarrollo de
sistemas.
Media hora a una hora cuando mucho.
Debe coordinarse muy bien.
Al igual que con todas las medidas de aseguramiento
de la calidad, el propsito de los repasos es evaluar
el producto sistemticamente de manera continua en
lugar de esperar hasta la terminacin del sistema.

Diseo y Desarrollo de Sistemas
Diseos de sistemas ascendente (de abajo a arriba o bottom-up)

Descendente (de arriba abajo o top-down)

Enfoque modular para la programacin.

Diseo Ascendente
Se refiere a identificar los procesos que necesitan automatizarse conforme surgen.

Analizarlos como sistemas y codificar los procesos, o comprar software
empaquetado para resolver el problema inmediato.

Con frecuencia este tipo de problemas son estructurados y por lo tanto son ms
sensibles a la automatizacin.

Por ejemplo, con frecuencia los negocios toman este enfoque para el desarrollo de
sistemas al adquirir software comercial para la contabilidad, un paquete diferente
para la programacin de produccin y otros para el marketing.

Diseo Ascendente
Es difcil interconectar los subsistemas de manera que se desempeen
fcilmente como sistema.

Es muy costoso corregir las fallas de la interconexin y muchas de ellas no
se descubren, sino hasta que se completa la programacin.

En esta situacin, hay poco tiempo, presupuesto o paciencia del usuario
para la depuracin de las interconexiones delicadas que se han ignorado.

Diseo Ascendente
Al considerar el sistema global hay serias limitantes.

Una es que hay duplicidad de fuerza de software e incluso introducir los
datos.

Se introducen datos invlidos en el sistema.

No se consideran los objetivos organizacionales globales, y por lo tanto
dichos objetivos no se pueden cumplir.

Diseo Descendente
Una descripcin amplia del sistema y despus dividirla en partes ms
pequeas o subsistemas.

Permite a los analistas de sistemas determinar primero los objetivos
organizacionales globales, as como tambin determinar como se renen
mejor en un sistema global.

Despus el analista divide dicho sistemas en subsistemas y requerimientos.

Diseo Descendente
El diseo descendente es compatible con el pensamiento general de Sistema.

Cuando los analistas de sistemas utilizan un enfoque descendente estn pensando
en que las interrelaciones e interdependencia de subsistemas se adaptan a la
organizacin.

Proporciona el nfasis deseable en la colaboracin o interconexiones que los
sistemas y sus subsistemas necesitan.

Evita un problema mayor asociado con un enfoque ascendente; evitar que los
analistas de sistemas se metan tanto en los detalles que pierdan de vista lo que se
supone que el sistema hace.

Diseo Descendente
Diseo Descendente
Riesgo de que el sistema se divida en subsistemas.

Se debe poner atencin a las necesidades que se traslapen y a la
comparticion de recursos de manera que la particin en subsistemas tenga
sentido para todos los sistemas.

Adems, es importante que cada subsistema solucione el problema
correcto.

Desarrollo Modular
Implica dividir la programacin en partes
lgicas y manejables llamadas mdulos.

Este tipo de programacin funciona bien con
el diseo descendente porque da nfasis a
las interfaces entre los mdulos y no los
descuida hasta el final del desarrollo de
sistema.

Idealmente, cada mdulo individual debe ser
funcionalmente cohesivo de manera que se
encargue de realizar una sola funcin.

Desarrollo Modular
Tiene tres ventajas principales.
1. Los mdulos son ms fciles de escribir y
de depurar porque prcticamente son
independientes.
Rastrear un error en un mdulo es menos complicado,
debido a que un problema en un modelo no debe
causar problemas en otros.
2. Los mdulos son ms fciles de mantener.
Normalmente las modificaciones se limitarn a unos
mdulos y no seguirn en todo el problema.
3. Los mdulos son ms fciles de entender,
debido a que son subsistemas
independientes.
Desarrollo Modular
Algunos lineamientos para la programacin modular
incluyen lo siguiente:

1. Mantener cada modulo de un tamao manejable
(incluir a la perfeccin una sola funcin).

2. Poner particular atencin a la interfaces crticas
(los datos y variables de control que se pasan a
otros mdulos).

3. Minimizar el nmero de mdulos que el usuario
debe modificar al hacer los cambios.

4. Mantener las relaciones jerrquicas establecidas
en las fases descendentes.
Modularidad en el Entorno Windows
La modularidad se est volviendo muy importante.
Microsoft desarroll dos sistemas para vincular los programas en
un entorno de Windows.
El primero se llama intercambio dinmico de datos (DDE), el cual
comparte cdigos al usar archivos de bibliotecas de vnculos
dinmicos (DLL).
Al usar DDE, un usuario puede almacenar datos de un programa
quizs en una hoja de clculos tal como Excel y despus usar
dichos datos en otros programas, por decir, en un paquete de
procesamiento de texto tal como Word para Windows.
El programa que contiene los datos originales se denominan
servidor y el programa que los usa se llama cliente.

Ventajas de las DLL:
Reducen el tamao de los archivos ejecutables: Gran parte del cdigo puede
estar almacenado en bibliotecas y no en el propio ejecutable lo que redunda en una
mejor modularizacin.
Pueden estar compartidas entre varias aplicaciones: Si el cdigo es
suficientemente genrico, puede resultar de utilidad para mltiples aplicaciones .
Facilitan la gestin y aprovechamiento de la memoria del sistema: La carga
dinmica permite al sistema operativo aplicar algoritmos que mejoren el rendimiento
del sistema cuando se carguen estas bibliotecas.
Brindan mayor flexibilidad frente a cambios: Es posible mejorar el rendimiento o
solucionar pequeos errores distribuyendo nicamente una nueva versin de la
biblioteca dinmica.

Un segundo enfoque para vincular programas en
Windows se denomina vinculacin e incrustacin de
objetos (OLE).
Este mtodo de vincular programas es superior a
DDE porque est ligado a los datos y grficos de la
aplicacin.
Mientras que DDE utiliza un enfoque de cortar y
pagar para vincular datos y no retiene el formato,
OLE retiene todas las propiedades de los datos
creados originalmente.
Este enfoque orientado a objetos permite al usuario
final permanecer a la aplicacin del cliente y editar
los datos originales en la aplicacin del servidor.

Uso de Diagramas de Estructura para Disear
Sistemas
Una de las herramientas recomendadas para disear un sistema modular
descendente se denomina diagrama de estructura.

Este grfico simplemente es un diagrama que consiste de cuadros
rectangulares, los cuales representan los mdulos, y de flechas de conexin.

Sistemas
La figura muestra tres mdulos que se etiquetan
como 000, 100 y 200 y se conectan mediante lneas
de ngulos rectos.
Los mdulos del nivel superior se numeran por 100s
o 1,000s y los mdulos de nivel inferior se numeran
por 10s o 100s.

Esta enumeracin permite a programadores insertar
mdulos que se usan un nmero entre los nmeros
de mdulos adyacentes.

Por ejemplo, un modulo insertado entre los mdulos
110 y 120 recibira el numero 115. Si se insertarn
dos mdulos, los nmeros podran ser 114 y 117.

Estos esquemas de numeracin varan, dependiendo
de los estndares organizacionales usados.
Sistemas
Sistemas
Sistemas
Dibujo de un Diagrama de Estructura
Tipos de Mdulos
Dibujo de un Diagrama de Estructura
Tipos de Mdulos
Los mdulos del diagrama de estructura entran en una de las tres categora
generales:

(1) Control
(2) Transformacional ( a veces denominado trabajador) o,
(3) Funcional.

Los mdulos de control normalmente se encuentran siempre en la parte superior
del diagrama de estructura y contienen la lgica para desempear los mdulos del
nivel inferior.

La lgica de un mdulo de control se podra determinar desde un rbol de decisin o
una tabla de decisin.

Una tabla de decisin con demasiada reglas se deben dividir en varias tablas de
decisin, con la primera tabla llamando a ejecucin a la segunda tabla. Cada tabla de
decisin producira un modulo de control.

Tipos de Mdulos
Los mdulos transformacionales son aquellos creados de un
diagrama de flujos de datos.

Normalmente desempean una sola tarea aunque varias tareas
secundarias se podran asociar con la principal.

Por ejemplo, un modulo denominado IMPRIMIR LINEA TOTAL DEL
CLIENTE podra formatear toda la lnea, imprimir la lnea, agregarla a
los totales finales y establecer los totales del cliente a cero en la
preparacin para acumular las cantidades del siguiente cliente.

Tipos de Mdulos

Los mdulos funcionales son los ms bajos en la
estructura, rara vez tiene un mdulo subordinado bajos
ellos.

Solo desempean una tarea, tal como formatear, leer,
calcular o escribir.

Algunos de estos mdulos se encuentran en un diagrama
de flujo de datos, pero otros se tendran que agregar, tal
como leer un registro o imprimir una lnea de error.

Tipos de Mdulos
Subordinacin de Mdulo
Subordinacin de Mdulo
Ingeniera de Software y Documentacin


La planeacin y control son elementos fundamentales en
todo sistema exitoso.

Tambin necesitamos tcnicas de diseo que nos ayuden a
separar el esfuerzo de programacin en mdulos
manejables.

Debido a que la mayora de los sistemas no se consideran
desechables, muy probablemente necesitarn ser
mantenidos.

El esfuerzo de aseguramiento de la calidad total requiere
que los programas se documenten adecuadamente.


El software y los procedimientos se documentan de
manera que se codifiquen en un formato que pueda
acceder fcilmente.

El acceso a esta documentacin es necesario para
las nuevas personas que aprenden el sistema y
como un recordatorio para aquellos que no usan el
programa con frecuencia.

La documentacin permite a usuarios,
programadores y analistas ver el sistema, su
software y procedimientos sin tener que interactuar
con l.


Cierta documentacin proporciona una apreciacin
global del propio sistema.

La documentacin de procedimientos detalla lo que se
debe hacer para ejecutar el software en el sistema.

La documentacin del programa detalla el cdigo del
programa que se usa.


La documentacin se requiere para los
siguientes fines:

Aprender a utilizar el sistema
Documentacin del usuario

Realizar modificaciones o mantenimiento
Documentacin tcnica

Algunos sistemas heredados fueron escritos antes de
que un negocio estandarizara sus tcnicas de
documentacin, pero todava se usan (sin
documentacin).

Muchos otros sistemas han sufrido modificaciones
mayores o menores y se han actualizados durante los
aos, pero su documentacin no se ha modificado para
reflejar esto.

Algunos analistas no documentan porque tienen miedo
de hacerlo o piensan que no es su trabajo.

Pseudocdigo

El pseudocdigo es similar al espaol estructurado
porque no es un tipo particular de programar
cdigos, pero se puede usar como un paso
intermedio para desarrollar el cdigo de programa.

Debido a que el pseudocdigo est tan cerca del
cdigo de programa, naturalmente es favorecido
por programadores y por consiguientes no es
favorecido por analista de negocio.

Pseudocdigo

Manuales de Procedimientos

Los manuales de procedimiento son documentos
organizacionales comunes.

Son el componente en espaol de la documentacin,
aunque tambin podran contener cdigos de programas,
diagramas de flujos, etc.

Podran contener los pasos requeridos para lograr
diferentes transacciones, instrucciones de cmo
recuperarse de los problemas y qu hacer si algo no
funciona (solucionar problema).

Actualmente muchos manuales estn disponible en lnea,
con capacidad de hipertexto que facilita el uso.


Para ser til, la documentacin del usuario se debe mantener
actualizada.

El uso de Web ha revolucionado la velocidad con lo que los
usuarios pueden obtener asistencia.

La lista de preguntas frecuentes (FAQ), escritorio de ayuda,
soporte tcnico y servicio de fax para Web.

Adems, muchos vendedores de software incluyen archivos
Lame con descarga o envo de nuevos software.

Documentan cambios,
ajustan o reparan fallas recientemente descubiertas.


Los problemas con los manuales de procedimiento
son:

1. Estn mal organizados.

2. Es difcil encontrar la informacin necesaria en ellos.

3. El caso especfico en cuestin no aparece en el manual.

4. El manual no est escrito en espaol.

Mtodo de Folklore

Es una tcnica de documentacin de sistemas creada para
complementar algunas de las tcnicas ya tratadas.

Recopila informacin que normalmente se comparte entre los
usuarios pero raramente se pone por escrito.

Es una tcnica sistemtica, basada en mtodos tradicionales
usada para recopilar el folklore sobre las personas y leyendas.

Requiere que el analista:

Entreviste a los usuarios
Investigue la documentacin existente en los archivos y
Observe el procedimiento de informacin.

Mtodo de Folklore

El objetivo es recopilar la informacin correspondiente a una de
cuatros categoras:

Costumbres
Ancdotas
Proverbios
Forma artsticas.

Mtodo de Folklore

Al documentar las costumbres, el analista (u otros folkloristas) intenta
capturar por escrito lo que los usuarios hacen para conseguir que los
programas se puedan ejecutar sin problemas.

Normalmente nos toma dos das actualizar los registros mensuales
porque la tarea es bastante grande. Ejecutamos cuentas comerciales
en un da y guardamos las otras para el siguiente da.

Mtodo de Folklore

Las ancdotas son historias que los usuarios dicen respecto a
cmo funcion el sistema.

La exactitud de la ancdotas depende de la memoria del
usuario y es, en el mejor de los casos, una opinin sobre como
funcion el programa.

El problema ocurri de nuevo en 1995. Esa vez, el trabajo LIB409
(actualizacin mensual) solo se ejecut con los registro tipo 6.
Debido a este error no haba registros financieros en el archivo
LIBFIN. Cuando intentamos leer el archivo vaco, ste
inmediatamente se cerraba y por consiguiente los totales se
reportaron como cero. Pudimos corregir este problema agregando un
registro tipo 7 y ejecutando el trabajo
Mtodo de Folklore

Los proverbios son declaraciones breves que representan
generalizaciones o consejos.

En la documentacin de sistemas, tenemos muchos
proverbios, tal como:

Omita esta seccin de cdigo y el programa fallar o
Haga frecuentemente copias de seguridad.

A los usuarios les gusta dar consejos y el analista debe
intentar capturar dichos consejos e incluirlos en la
documentacin del FOLKLORE.

Mtodo de Folklore

Recopilar formas artsticas es otra actividad importante
del folklorista tradicional, y tambin el analista de
sistemas debe entender su importancia.

Los diagramas de flujos, diagramas y tablas que los
usuarios disean algunas veces podran ser mejores o
mas tiles que los diseados por el autor del sistema
original.

Los analistas con frecuencia encontrarn tal arte en los
carteles de anuncios o podran pedir a los usuarios
vaciar sus archivos y recuperar cualquier diagrama til

Mtodo de Folklore

El peligro de confiar en el FOLKLORE es que la
informacin recopilada de los usuarios podran ser
correcta, parcialmente correcta o incorrecta.

Sin embargo, a menos que alguien se tome el tiempo
de rehacer completamente la documentacin de
programa, la descripcin de costumbres, ancdotas,
proverbios y formas artsticas podra ser la nica
informacin escrita acerca de cmo funciona un grupo
de programas.

Seleccin de una Tcnica de Diseo y
Documentacin

Lo siguiente es un grupo de lineamientos para ayudar al
analista a seleccionar la tcnica adecuada.

Escoja una tcnica que:

1. Es compatible con la documentacin existente.
2. Se entiende por otros en la organizacin.
3. Le permite regresar a trabajar en el sistema despus que
ha estado fuera de l por un periodo.
4. Sea conveniente para el tamao del sistema en que est
trabajando.
5. Permita un enfoque de diseo estructurado si se
considera como ms importante que otros factores.
6. Permita fcil modificacin.

Cmo Probar, Mantener y Auditar

El Proceso de Probar

Todos los programas de aplicacin del sistema
recin escrito o modificado as como tambin
nuevos manuales de procedimientos, nuevo
hardware y todas las interfaces del sistema se
deben probar completamente.

Las pruebas se hacen durante todo el proceso
de desarrollo de sistemas, no solo al final.

Se busca descubrir errores desconocidos hasta
ahora, no demostrar la perfeccin de
programas, manuales o equipos.


Aunque probar es tedioso, es una serie esencial de pasos
que ayudan a asegurar la calidad eventual del sistema.

Las pruebas se realizan en subsistemas o mdulos del
programa conforme avance su desarrollo.

Antes de que el sistema se ponga en produccin, todos
los programas se deben verificar en el escritorio, verificar
con datos de prueba y verificar para ver si los mdulos
trabajan entre s como se plane.


El sistema tambin se debe probar como un todo
en funcionamiento.

Incluso hay que probar las interfaces entre los
subsistemas; la exactitud de salida; y la utilidad y
entendimiento de la documentacin y la salida de
sistemas.

Las pruebas de hardware normalmente se
proporcionan como un servicio por los vendedores
de equipo quienes ejecutarn sus propias pruebas
en el equipo cuando se libere en el sitio.


Pruebas de programas con datos de
prueba

En esta fase, los programadores deben hacer pruebas
de escritorio de sus programas para verificar las
formas en que funcionar el sistema.

El programador sigue cada paso en el programa para
verificar si la rutina funciona como se espera.

Luego, los programadores deben crear datos de
pruebas vlidos e invlidos.

Estos datos se ejecutan para ver si la rutinas de base
trabajan y tambin para descubrir errores.

Los datos de pruebas creados deben probar posibles
valores mnimos y mximos as como tambin todas las
variaciones posibles en el formato y cdigos.

A lo largo de este proceso, el analista de sistemas verifica
la salida en busca de errores, avisando al programador de
cualquier correccin necesaria.

El analista normalmente no recomendar o crear datos
de pruebas para las pruebas de programas pero podra
sealar al programador las omisiones de tipos de datos a
ser agregados en pruebas posteriores.


Prueba de vnculos con datos de
pruebas

Tambin se conocen como prueba de cadena.

Estas pruebas verifican si los programas que
realmente son interdependientes trabajan juntos
como se plane.

Es inmensamente difcil resolver los problemas si
intenta probar todo a la vez.

Primero se procesan datos de pruebas tpicos para
ver si el sistema puede manejar transacciones
normales, se agregan las variaciones, incluyendo los
datos invlidos para asegurar que el sistema puede
detectar adecuadamente los errores.


Prueba completa de sistemas con datos de pruebas

Hay varios factores a considerar cuando se prueban los sistemas de datos de pruebas:

1. Examinar si los operadores tienen la documentacin adecuada en los manuales de
procedimientos para asegurar un funcionamiento correcto y eficaz.

2. Verificar si los manuales de procedimientos son lo bastante claros como para
comunicar cmo se deben preparar los datos para la entrada.

3. Determinar si los flujos de trabajos necesarios para el sistema nuevo o modificado
realmente fluyen.

4. Determinar si la salida es correcta y si los usuarios entienden que esta salida es
como se ver en su formulario final.


Prueba completa de sistemas con datos reales

Es recomendable probar el nuevo sistema con lo que se conoce como datos reales, datos que
se han procesado de manera exitosa con el sistema existente.

Comparacin precisa de la salida del nuevo sistema con la salida que ha sido procesada
correctamente.

Slo se usan pequeas cantidades de datos reales en este tipo de pruebas de sistemas.

Pruebas de Mantenimiento

Instalar o modificar sistemas que tienen una vida til
larga.

Reducir los costos de mantenimiento.

El mantenimiento de software puede consumir ms de
50% del presupuesto.

Los costos de mantenimiento excesivo se reflejan
directamente en el diseador de sistemas.

Aproximadamente el 70% de errores de software se
han atribuido al diseo de software inadecuado.

Detectar y corregir los errores de diseos de software
es menos costoso.


Se realiza para mejorar el software existente en lugar de
responder a una crisis o falla del sistema.

Ms de la mitad de todo el mantenimiento est compuesto
de trabajo de mejoras.

El mantenimiento tambin se hace para actualizar el
software en respuestas a la organizacin cambiante.

El mantenimiento de emergencia y de adaptacin
representa menos de la de la mitad de todo el
mantenimiento del sistema.


Los usuarios deben poder comunicar fcilmente los problemas y
sugerencias a aquellos que estarn manteniendo el sistema.

Clasificar las solicitudes permite a programadores de mantenimiento
entender cmo estiman los usuarios la importancia de sus solicitudes.

Cmo Auditar?

Auditar es otra forma de asegurar la calidad de la informacin
contenida en el sistema ampliamente definido.

Auditar se refiere a pedirle a un experto, que no est involucrado en
crear o usar un sistema, examinar la informacin para determinar
su fiabilidad.

Generalmente hay dos tipos de auditores para los usuarios de
informacin: interno y externo.

Los auditores internos trabajan para la misma organizacin que
posee el sistema de informacin, mientras que los externos
(tambin llamados independientes) se contratan por fuera.

Cmo Auditar?

Los auditores externos se usan cuando el sistema de
informacin procesa datos que influyen en las
declaraciones financieras de una compaa.

Auditan el sistema para asegurar la veracidad de las
declaraciones financieras que se producen.

Tambin se podran traer si ocurre algo fuera de lo normal
que involucra a los empleados de la compaa, tal como la
sospecha de un fraude electrnico o un desfalco.

Cmo Auditar?

Los auditores internos estudian los controles usados en el
sistema de informacin para estar seguros de que son
adecuados y que est haciendo lo que deben hacer.

Tambin prueban las suficiencias de controles de seguridad.
Aunque trabajan para la misma organizacin, los auditores
internos informan a las personas responsables del sistema
que est auditando.

El trabajo de los auditores internos con frecuencia es ms
detallado que el de los auditores externos.

Capítulo 16 Aseguramiento de La Calidad Mediante Ingeniería de SW

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Capítulo 16 Aseguramiento de La Calidad Mediante Ingeniería de SW

Transféré par

Droits d'auteur :

Formats disponibles

Captulo 16

Aseguramiento de la Calidad mediante Ingeniera de

Vous aimerez peut-être aussi