INSTITUTO TECNOLOGICO SUPERIOR CORDILLERA

CARRERA DE ANLISIS DE SISTEMAS

ASEGURAMIENTO DE LA CALIDAD MEDIANTE LA INGENIERIA

DEL SOFTWARE

BASE DE DATOS

INTEGRANTE:
JONATHAN CHICAIZA
CURSO: 2do A
DOCENTE BASE DE DATOS:
ING. JAIME PADILLA

QUITO, NOVIEMBRE DEL 2014

OBJETIVOS:

Reconocer la importancia de adoptar un enfoque de calidad total para todo el

SDLC(siclo de vida de desarrollo de software)

Crear diagramas de estructura para disear sistemas modulares con un enfoque

descendente (de arriba a abajo)

Usar diversa 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.

La calidad ha sido durante mucho tiempo una preocupacin para as empresas como
lo debe ser para los analistas de sistemas en el diseo de sistemas informticos. Es
arriesgado emprender el proceso de anlisis y diseo sin usar un enfoque de
aseguramiento de la calidad

Hay tres enfoques para el aseguramiento de la calidad del software son :

1.- garantizar el aseguramiento de la calidad total diseando sistemas y software

con un enfoque modular, descendente(de arriba a abajo)

2.-documentar el software con las herramientas adecuadas,

3- probar, mantener y auditar el software

Qu es calidad? Que es calidad del software?

Calidad del software es el grado en Que un cliente y/o usuario percibe que el
producto software satisface sus necesidades.

Calidad del software es la habilidad de un producto software de satisfacer su

especificacin de requerimientos.

Aseguramiento de la calidad mediante la ingeniera de software

En el aseguramiento de la calidad mediante la ingeniera del software se puede
garantizar el aseguramiento de la calidad total diseando sistemas y software con un
enfoque modular, descendente (arriba hacia abajo)
Documentar el software con las herramientas adecuadas, y probara, mantener y auditar
el software.
Dos propsitos guan el aseguramiento de la calidad
El primero es que el usuario del sistema de informacin es el factor individual ms
importante en establecer y evaluar su calidad.
El segundo es que es mucho menos costoso corregir los problemas es sus fases iniciales
que esperar hasta que un problema se manifieste a travs de las quejas o crisis del
usuario.
Enfoque de administracin de la calidad total
La administracin de la calidad total [TQM, por sus siglas en ingles] es esencial a lo
largo de todos los pasos del desarrollo de sistemas.

Segn Dean y Evans (1994), los principales elementos de la TQM solo son
significativos cuando se presentan en un contexto organizacional que favorece un
esfuerzo integral por la calidad.
Elementos de enfoque

En el cliente

Planificacin estratgica y liderazgo

Mejora continua

Facultar al empleado

Trabajo en equipo

Seis sigmas
Cada analista de sistemas necesita estar consciente de Seis Sigma y aplicar algunos de
los principios a sus proyectos de anlisis de sistemas; ms que una metodologa es una
cultura basada en la calidad.
La meta del seis sigma es la de ELIMINAR TODOS LOS DEFECTOS.
En la dcada de 1970 y hasta fines del siglo pasado, el control de calidad se expres en
trminos de tres desviaciones estndar de la media, o tres sigma, lo cual es equivalente a
aproximadamente 67,000 defectos por milln de oportunidades.
Seis sigma implica una meta de solo 3.4 defectos por milln de oportunidades. Seis
Sigma es un enfoque descendente de arriba hacia abajo.
Joseph M. Juran digo toda mejora de la calidad ocurre proyecto tras proyecto y de
ninguna otra forma (Juran 1964).

(fig. 1)
Responsabilidad de la administracin de la calidad total
Apoyo incondicional por partes de los directivos.
No es fcil crear los estndares de calidad, pero es posible y se ha hecho.
Repaso estructurado
Los repasos estructurados involucran por lo menos a cuatro personas:

Un programador o analista.

Un coordinador del repaso.

Un programador o analista experto.

Un experto que toma notas acerca de las sugerencias.

(fig. 2)
Diseo y desarrollo de sistemas
Diseo ascendente
Diseo descendente
Diseo ascendente
Identificar procesos que necesitan computarizarse conforme surgen
Codificar
Comprar software
Significa ver una descripcin amplia del sistema y despus dividirla en partes
ms pequeas o subsistemas.

(fig. 3)

(fig.4)

Desarrollo modular
Implica dividir la programacin en partes lgicas y manejables llamadas mdulos, cada
mdulo debe ser funcionalmente cohesivo.

(fig. 5)
Desarrollo modular
Contiene 3 ventajas principales:

Mdulos ms sencillos de escribir y depurar debido a la independencia.

Los mdulos son ms fciles de mantener.

Los mdulos son ms fciles de entender, debido a que son subsistemas

independientes.

Lineamientos para la programacin

Mantener cada mdulo de un tamao manejableDebida atencin a las interfaces crticas (datos, variables, etc. que pasan

otros

mdulos).
Minimizar el nmero de mdulos que el usuario debe modificar.
Mantener las relaciones jerrquicas establecidas.
Modularidad en el entorno de Windows
Microsoft desarrollo 2 sistemas para vincular los programas en su entorno de Windows.
Intercambio dinmico de datos DDE.
Comparte cdigo al usar archivos de biblioteca de vnculos dinmicos
Vnculos e incrustacin de objetos OLE
Est ligada a los datos y grficos de la aplicacin.
Uso de diagramas de estructura para disear sistemas
La herramienta recomendada para disear un sistema modular descendente se denomina
diagrama de estructura.
Este grafico consiste simplemente en cuadros rectangulares (mdulos) y flechas de
conexin.
Diagramas de estructura
Los mdulos de nivel superior se numerar por 100s o 1000s y los mdulos de nivel
inferior se numeran por 10s o 100s respectivamente.

(fig. 6)
A los lados de las lneas de conexin se dibujan dos tipos de flechas con los crculos
rellenados se denominan banderas de control o interruptores.
Estos indican que algo se pasas hacia abajo al mdulo inferior o hacia arriba al superior.

(fig. 7)
Dibujo de un diagrama de estructuras
Se deben dibujar de arriba hacia abajo.
Se busca informacin en los diagramas de flujo de datos.
El DFD, indica la secuencia de los mdulos en un diagrama de estructuras.

10

(fig. 8)

(fig. 9)
Tipos de mdulos
Categoras:
1.- control

11

2.- transformacional
3.- funcional.
Mdulos de control
No deben ser muy grandes.
Contienen lgica para disear el modulo inferior.
Instrucciones if, perform y do.
La lgica se determina desde un rbol de decisin o tabla de decisin.
Mdulos transformacionales
Creados a partir de un DFD.
Instrucciones if, perform, do, move, add.
Emplean una sola tarea, aunque varias tareas secundarias pueden asociarse con la
principal.
Mdulos funcionales
Son los ms bajos en la estructura.
Solo desempean una sola tarea.
Algunos mdulos se encuentran en un DFD, pero otras se tendran que agregar.
Diagrama de estructura para agregar.

12

(fig. 10)
Subordinacin de modulo
Un mdulo subordinado es una inferior en el diagrama de estructura llamado por
otros mdulos superiores en la estructura.
Subordinacin inadecuada: permite que el mdulo de nivel inferior desempee
una tares que no es requerida por el modulo.
Subordinacin inadecuada.

(fig. 11)

13

Subordinacion adecuada

(fig. 12)
Ingenieria de software
La inegenieria del software es una disciplina de la ingenieria que comprende toda la
produccion de software de software desde las etapas iniciales de la especificacion del
sistema hasta el mantenimiento de este despues que se utiliza.
Ingenieria del software
Aereas de estudio
Metodos y metodologias de desarrollo de software
Procesos de desarrollo de software
Gestion de proyectos de software
Medicion y estimacion de software

14

Ingenieria de requisitos
Ingenieria de software empirica
Gention de riesgos
Usabilidad de software
Evaluacion de software
Metricas de sotware
Calidad de software
Metodos formales
Ingenieria web
Documentacion
La documentacion permite a usuarios, programadores y analistas ver el sistema,m su
software y procesamientos sin tener que interactuar con el.
Tipos de documentacion
Documentacion global
Documentacion de procedimiento
Documentacion de programa
Problemas de documentacion
Sistemas heredados
Actualizacion de sistemas
Compra de sistenas

15

Tiempo y costo
PSEUDOCODIGO
Secuencia de pasos de forma detallada.
Ayuda a entender facilmente un proceso (progrmadores, no otras personas)
DFD se puede usar para describir el pseudocodigo.
No es un tipo de programas codigo, pero sirve de guia.
No es muy utilizado por falta de estandarizacion
Simbologia
IF.. THEN..ELSE
* Y O
MANUALES DE PROCEDIMIENTO

Documentos de apoyo al usuario.

Lo normal es que contenga cualquier tipo de asistencia al usuario.

Pero puede contener cdigos de programa, DFD, etc.

Lo antiguo es

FAQ

Soporte tcnico

Servicios de fax

Lo mas moderno es Manuales en Lnea debe estar actualizada

16

Manueles de procesamiento secciones importantes

Introduccion
Indice
Como usar el software
Que hacer si las cosas salen mal
Referencia tecnica (como esta construido el SW, etc)
Como contactar al fabricante.
Manuales de procesamiento problemas al elaborarlos
Mal organizados
Dificil encontrar la informacion
No apararecen casos especificos
No escrito en espaol

(fig. 13)

17

METODO DEL FOLKLORE

FOLKLORE=TRADICION
Tecnica de documentacion que sirven para complementar otras tecnicas
Sirven para recompilar las costumbres entre las personas
Requieren de entrevistas revision de carteles, etc.
Tiene 4 categorias (proverbios, costumbres, formas artisticas y anecdotas)
Qu se documenta ? Qu contiene?

(fig. 14)
Costumbres
Cmo hacen funcionar el sistemas?
Nos toma 2 dias ingresar las facturas al sistema, el primer dia para ordenarlas por fecha,
el siguiente para ingresarlas al sistema

18

Anecdotas
Cmo pudieron hacer que el sistema funcionara?
el problema ocurrrio en diciembre de ao pasado, no actualizaba los saldos de deudores,
tuve que cerras el programa para que los actualizara
Proverbios
Consejos
guardar archivo
omita esta seccion de codigo y el programa fallara
Formas artisticas
Otros DF, tablas, etc que hacen que el usuario lo entienda mejor
SELECCIN DE UNA TECNICA DE DISEO Y DOCUMENTACION
Es compatible con la documentacion
Se entiende por otros en la organizacin
Le permite regresar a trabjar en el sistema
Sea conveniente para el tamao del sistema
Permite un diseo estructurado
Permite facil madificado
COMO PROBAR, MANTENER Y AUDITAR
Proceso de probar
Pruebas de programa con datos de prueba

19

Prueba de vinculos con datos de prueba

Prueba de vinculos con datos de prueba
Prueba completa de sistema con datos de prueba
Prueba completa de sistema con datos reales
Modelo V

(fig. 15)
Practicas de mantenimiento
El proceso se realiza para mejorar el software existente en lugar de responder a una
crisis o falla del sistema.
Re codificar a los usuarios acceso a un correo electronico para el soporte tecnico
Como auditar
Es una forma de asegrar la calidad de l ainformacion contenida en el sistema

20

Se refiere a pedirle a un experto, que no este involucrado en crear o usar el ssitema,

examinar la informacion para determinar su fiabilidad.