AO DE LA CONSOLIDACIN DEL MAR DE GRAU

CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS E INFORMATICA

Anlisis y Diseo de Sistemas de Informacin II

Aseguramiento de calidad mediante ingeniera de software

INTEGRANTES:

Ligarda Alejandro Gary Keith

Corrales Sols Nitza

Abancay Per
2016

1. Aseguramiento de calidad mediante ingeniera de software

La calidad ha sido durante mucho tiempo una preocupacin para las empresas y para los analistas de
sistemas en el anlisis y diseo de sistemas de informacin.

QU ES LA CALIDAD DEL SOFTWARE?

El grado en que un cliente y/o usuario percibe que el producto software
satisface sus necesidades, cumpliendo las normas y que tenga cero
defectos

Qu es la ingeniera del software?

Es una disciplina de la ingeniera que comprende todos los aspectos de la
produccin de software desde las etapas iniciales de la especificacin del
sistema hasta el mantenimiento de este despus que se utiliza.
El establecimiento y uso de principios de ingeniera robustos orientados a
obtener software econmico que sea fiable y que funcione en mquinas
reales.

1.1

ENFOQUES PARA EL ASEGURAMIENTO DE LA CALIDAD

MEDIANTE LA INGENIERA DE SOFTWARE:
Existen 3 enfoques.

Garantizar el aseguramiento de la calidad total diseando sistemas y

software con un enfoque modular, descendente.
Documentar el software con las herramientas adecuadas.
Probar, mantener y auditar el software

1.2 PRINCIPIOS QUE GUAN HACIA EL

ASEGURAMIENTO DE LA CALIDAD:
o
o

El usuario del sistema de informacin es el factor individual ms

importante en establecer y evaluar su calidad.
Es mucho menos costoso corregir los problemas en sus fases iniciales
que esperar hasta que un problema se manifieste a travs de las
quejas o crisis del usuario.

Forma de minimizar los riesgos, y ayudar a asegurar que el sistema es lo

que se necesita y quiere, y que mejorar evidentemente algunos aspectos
del desempeo del negocio.

1.3 ENFOQUE DE ADMINISTRACIN DE CALIDAD

TOTAL (TQM)
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 estos y en los directivos.
- Debe existir un apoyo incondicional por parte de los directivos.
- La administracin y los usuarios deben desarrollar lineamientos para los
estndares de calidad de los sistemas de informacin.

Repasos estructurados

Una de las acciones ms fuertes de la administracin de calidad

Es una forma para monitorear el desarrollo general y de la programacin

del sistema, resaltar problemas y permitir al responsable de esa parte del
sistema haga los cambios adecuados.

Pueden ser realizados cada vez que se ha terminado una parte del
cdigo, un subsistema o un
sistema.

1.4 Diseo y desarrollo de sistemas

1.4.1 Diseo Ascendente
Se refiera a identificar los procesos que necesitan computarizarse
conforme surgen. Analizarlos como sistemas y codificar los procesos o
comprar software para resolver el problema.
Los problemas que requieren computarizarse normalmente se
encuentran en el nivel ms bajo de la organizacin.
Cuando la programacin interna se hace con un enfoque ascendente,
es difcil interconectar los subsistemas de manera que se
desempeen fcilmente como un sistema.

1.4.2 Diseo descendente

Ver una gran imagen del sistema y luego explotarla a partes o
subsistemas ms pequeos.
Determina los objetivos organizacionales globales.

Ventajas del
diseo
descendente.

Evita el caos de
disear un sistema "todo a la vez, dado que la planeacin e
implementacin de un sistema de administracin de informacin es
complejo.
Nos da la habilidad de tener equipos de anlisis de sistemas
separados trabajando en paralelo en diferentes subsistemas,
ahorrando tiempo.
Se previene que los analistas de sistemas se enfoquen demasiado en
los detalles y pierdan de vista lo que debe hacer el sistema.

1.4.3 Desarrollo Modular

Este enfoque 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 sistemas. Idealmente, cada mdulo individual debe ser
funcionalmente cohesivo de manera que se encargue de realizar una sola
funcin.
El diseo de programa modular tiene 3 ventajas:
Los mdulos son ms fciles de escribir y de depurar porque son
independientes.
Los mdulos son las fciles de mantener. Normalmente las
modificaciones se limitaran a unos mdulos y no seguirn en todo el
programa.
Los mdulos son ms fciles de entender debido a que son
subsistemas independientes.
Algunos lineamientos para la programacin modular incluyen lo
siguiente:
Mantener cada mdulo de un tamao manejable
Poner particular atencin a las interfaces criticas
Minimizar el nmero de mdulos que el usuario debe modificar al
hacer los cambios

Mantener las relaciones jerrquicas establecidas en las fases

descendentes

1.4.4

MODULARIDAD EN EL ENTORNO DE WINDOWS

Microsoft desarrollo dos sistemas para vincular los programas en su entorno
de Windows.
1. Intercambio dinmico de datos (DDE): Comparte cdigo al usar
archivos de biblioteca de vnculos dinmicos (DDL). Al usar DDE, un
usuario puede almacenar datos en otro programa quizs una hoja
de clculo como Excel- y despus usar dichos datos en otro
programa, como Word. El programa que contiene los datos originales
se denomina servidor y el programa que los usa se denomina cliente
2. 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 pegar para vincular datos y no retiene el formato, OLE
retiene todas las propiedades de los datos creados originalmente.

1.5 USO DE DIAGRAMAS DE ESTRUCTURA PARA

DISEAR SISTEMAS
La herramienta recomendada 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. Un diagrama de estructura favorece el

diseo descendente mediante mdulos.

1.6 DIBUJO DE UN DIAGRAMA DE ESTRUCTURA

Los diagramas de estructura se deben dibujar de arriba hacia abajo Al
transformar un diagrama de flujo de datos en un diagrama de estructura, se
deben tener en cuenta varias consideraciones adicionales. El diagrama de
flujo de datos indicar la secuencia de los mdulos en un diagrama de
estructura. Si un proceso se divide en un diagrama de flujo de datos hijo, el
mdulo correspondiente para el proceso padre tendr mdulos
subordinados que correspondan a los procesos encontrados en el diagrama
hijo.

1.7
TI
P
O
S DE MDULOS
Existen tres tipos de mdulos:
1. Control: que generalmente se encuentra cerca de la parte superior
de la grfica de estructura y pueden estar o no presentados en el
diagrama de flujo de datos.
2. Transformacionales: estos mayormente cumplen una sola funcin
primaria o varias secundarias que parten de la primaria y se crean a
partir de un diagrama de flujo de datos.
3. Funcionales o especializados: realizan una sola tarea bien sea
formatear, escribir, leer, etc.; son los ms bajos de la estructura y
algunos se encuentran en un diagrama de flujo de datos, pero hay
otros que deben agregarse. Ej.

1.8

SUBORDINACIN DE MODULO
Un mdulo subordinado es uno inferior en el diagrama de estructura
llamado por otro modulo superior en la estructura. Cada mdulo
subordinado debe representar una tares que es una parte de la funcin del
mdulo de nivel superior. Permitir que el mdulo de nivel inferior
desempee una tarea que no es requerida por el modulo que lo llama se
denomina subordinacin inadecuada. En tal caso, el modulo inferior se debe
mover al nivel superior de la estructura. Ej.

1.9 Documentar el software con las herramientas

adecuadas
Documentacin

Permite al usuario, programadores y analistas ver el sistema, su

software y procedimientos sin tener que interactuar con el.
Proporciona una apreciacin global del propio sistema.
La documentacin de procedimiento detalla lo que se debe hacer
para ejecutar el software en el sistema y;
La documentacin del programa detalla el cdigo del programa que
se usa.

Pseudocdigo

No es un tipo particular de programar cdigo, pero se puede usar

como un paso intermedio para desarrollar el cdigo de programa.
Con frecuencia se usa para representar la lgica de cada mdulo en
un diagrama de estructura.

Manual de procedimiento

Son documentos de apoyo al usuario, asistencia.

Tambin podran contener cdigos de programas, diagramas de flujo,
etc.
Podran contener comentarios de fondo, los pasos requeridos para
lograr diferentes transacciones, instrucciones de cmo solucionar
problemas.
Soporte tcnico, servicio de fax o manuales en lnea

Mtodo Folklore

Folklore = Tradicin = Costumbre

Tcnica de Documentacin que sirve para complementar otras
tcnicas
Sirve para recopilar las costumbres entre las personas.
Requiere de entrevistas, revisin de carteles, etc.
Tiene 4 categoras (Proverbios, Costumbres, Formas Artsticas y
Ancdotas)
Qu se documenta?, Qu contiene?

COSTUMBRES
Cmo hacen funcionar el sistema?
Nos toma 2 das ingresar las facturas al sistema, el primer da para
ordenarlas por fechas, el siguiente para ingresarlas al sistema
ANCDOTAS
Cmo pudieron hacer que el sistema funcionara?
El problema ocurri en Diciembre del ao pasado. No actualizaba los
saldos de deudores, tuve que cerrar el programa para que los
actualizara
PROVERBIOS
Consejos
Guarde el archivo,
Omita esta seccin de cdigo y el programa fallar
FORMAS ARTSTICAS
Otros tablas, etc. que hacen que el usuario lo entienda mejor.

SELECCIN DE UNA TCNICA DE DISEO Y DOCUMENTACION

El analista se encuentra frente a una decisin difcil con respecto al mtodo
seleccionado, Los siguientes son algunos lineamientos para ayudar al
analista a seleccionar la tcnica adecuada:
Escoja una tcnica que:

Es compatible con la documentacin existente

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

1.10PRUEBA, MANTENIMIENTO Y AUDITORA

Proceso de prueba

Las pruebas se realizan a lo largo del sistema y no simplemente al

final.
Es una serie esencial de pasos que ayuda asegurar la calidad del
sistema eventual
La prueba se realiza en subsistemas o mdulos de programas
conforme al trabajo avanza.
Revisa para ver si los mdulos trabajan junto entre ellos, tal como se
plane.

Prcticas de mantenimiento

El mantenimiento se realiza para mejorar el software existente en

lugar de responder a una crisis o falla del sistema.
Re codificar para mejorar la eficacia del programa.
Proporcionar a los usuarios acceso a un correo electrnico para el
soporte tcnico.

Cmo auditar

Es una forma de asegurar la calidad de la informacin contenida en el

sistema.
Se pide un experto, que no est involucrado en crear o usar el
sistema, examinar la informacin para determinar su fiabilidad.