INSTITUTO TECNOLOGICO SUPERIOR DE LERDO

CALIDAD DE SOFTWARE ASEGURAMIENTO DE LA CALIDAD LICENCIATURA EN INFORMATICA ALUMNO: MANUEL GUTIERREZ GARCIA PROFESOR:

I.S.C. Ricardo de Jess Bustamante Gonzlez

FECHA: 28/0272012 LUGAR: LERDO DURANGO

ASEGURAMIENTO DE LA CALIDAD DE SOFWARE

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO

El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad. El aseguramiento de calidad del software se disea para cada aplicacin antes de comenzar a desarrollar la y no despus. Algunos autores prefieren decir garanta de calidad en vez de aseguramiento. Garanta, puede confundir con garanta de productos Aseguramiento pretende dar confianza en que el producto tiene calidad El aseguramiento de calidad del software est presente en Mtodos y herramientas de anlisis, diseo, programacin y prueba Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo de software. Estrategias de prueba multiescala Control de la documentacin del software y de los cambios realizados Procedimientos Para ajustarse a los estndares (y dejar claro cuando se est fuera de ellos) Mecanismos de medida (mtricas) Registro de auditoria y realizacin de informes Actividades Para el aseguramiento de calidad del software Mtricas de software Para el control del proyecto Verificacin y validacin del software a lo largo del ciclo de vida Incluye las pruebas y los procesos de revisin e inspeccin La gestin de la configuracin del software. Tareas del Anlisis El anlisis de requerimientos puede dividirse en cuatro reas: 1.- Reconocimiento del problema 2.- Evaluacin y sntesis 3.- Especificacin 4.- Revisin. Inicialmente, el analista estudia la especificacin del sistema (si existe) y el plan de proyecto. Es importante comprender el contexto del sistema y revisar el mbito de los programas que se us para generar las estimaciones de la planificacin. A continuacin, debe establecerse la comunicacin necesaria para el anlisis, de forma que se asegure el reconocimiento del problema. El analista debe establecer contacto con el equipo tcnico y de gestin del usuario / cliente y con la empresa que vaya a desarrollar el software. El gestor del programa puede servir como coordinador para facilitar el establecimiento de los caminos de comunicacin. El objetivo del analista es reconocer los elementos bsicos del programa tal como lo percibe el usuario / cliente. La evaluacin del problema y la sntesis de la solucin es la siguiente rea principal de trabajo del anlisis. El analista debe evaluar el flujo y estructura de la informacin, refinar en detalle todas las funciones del programa, establecer las caractersticas de la interface del sistema y descubrir las ligaduras del diseo, Cada una de las tareas sirven para descubrir el CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO problema de forma que pueda sintetizarse un enfoque o solucin global. Las tareas asociadas con el anlisis y especificacin existen para dar una representacin del programa que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente desarrolla una especificacin de requerimientos del software completamente por s mismo. Esto se presenta raramente en el mundo real. En el mejor de los casos, la especificacin se desarrolla conjuntamente entre el cliente y el tcnico. Una vez que se hayan descrito las funcionalidades bsicas, comportamiento, interface e informacin, se especifican los criterios de validacin para demostrar una comprensin de una correcta implementacin de los programas. Estos criterios sirven como base para hacer una prueba durante el desarrollo de los programas. Para definir las caractersticas y atributos del software se escribe una especificacin de requerimientos formal. Adems, para los casos en los que se desarrolle un prototipo se realiza un manual de usuario preliminar. Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana del proceso de desarrollo, Pero de hecho, este borrador del manual de usuario fuerza al analista a tomar el punto de vista del usuario del software. El manual permite al usuario / cliente revisar el software desde una perspectiva de ingeniera humana y frecuentemente produce el comentario: "La idea es correcta pero esta no es la forma en que pens que se podra hacer esto". Es mejor descubrir tales comentarios lo ms tempranamente posible en el proceso. Los documentos del anlisis de requerimiento (especificacin y manual de usuario) sirven como base para una revisin conducida por el cliente y el tcnico. La revisin de los requerimientos casi siempre produce modificaciones en la funcin, comportamiento, representacin de la informacin, ligaduras o criterios de validacin. Adems, se realiza una nueva apreciacin del plan del proyecto de software para determinar si las primeras estimaciones siguen siendo validas despus del conocimiento adicional obtenido durante el anlisis. * Obteniendo de la informacin * Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente. Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lgico que para recabarlos haya que obtener la informacin de primera mano. Esto es, mediante entrevistas con el cliente o recabando documentacin que describa la manera que el cliente desea que funcione el sistema de software. Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentacin original del cliente, as como cada revisin o cambio que se haga a esta documentacin. Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO saber cuales de ellas sern satisfechas por el software y cuales por algn otro producto del sistema. * Especificacin de Requisitos de Software *(SRS) La especificacin de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripcin completa de las necesidades y funcionalidades del sistema que ser desarrollado; describe el alcance del sistema y la forma en como har sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra informacin que sirva de soporte y gua para fases posteriores. Es importante destacar que la especificacin de requisitos es el resultado final de las actividades de anlisis y evaluacin de requerimientos; este documento resultante ser utilizado como fuente bsica de comunicacin entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementacin del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se est proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborar las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolucin del sistema. La SRS posee las mismas caractersticas de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada caracterstica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y as sucesivamente. Las caractersticas de la SRS son verificadas en la actividad de Validacin, descrita en el punto. La estandarizacin de la SRS es fundamental pues ayudar, entre otras cosas, a facilitar la lectura y escritura de la misma. Ser un documento familiar para todos los involucrados, adems de asegurar que se cubren todos los tpicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. Clasificacin de los requerimientos El clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus caractersticas no pueden ser tratados iguales. La siguiente es una recomendacin de como pueden ser clasificados los requerimientos aunque cada proyecto de software pueda usar sus propias clasificaciones. Requerimientos del "entorno" El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto tipo de requerimientos que se clasifican en esta categora por que: El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione. Ejemplos del entorno podemos mencionar:

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO sistemas operativos, sistema de archivos, bases de datos. El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno, tales como congestin en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de considerar dentro de los requerimientos. Requerimientos "ergonmicos" l mas conocido de los requerimientos ergonmicos es la interface con el usuario o GUI (Graphic User Interface). En otras palabras, los requerimientos ergonmicos son la forma en que el ser humano interacta con el ser sistema. Requerimientos de Interface La interface es como interacta el sistema con el ser humano o con otros sistemas (el enfoque es prcticamente el opuesto a los requerimientos ergonmicos), La interface es la especificacin formal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica el protocolo, el tipo de informacin, el medio para comunicarse y el formato de los datos que se van a comunicar. * Actividades de la Ingeniera de Requerimientos * En el proceso de IR son esenciales diversas actividades. En este documento sern presentadas, sin embargo, en un proceso de ingeniera de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado. Dependiendo del tamao del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en nmero como en nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso. A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son: Anlisis del Problema Evaluacin y Negociacin Especificacin Validacin Evolucin * Principios de Especificacin Requerimientos funcionales Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa l Qu? Y no l Cmo?. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema. Requerimientos de desempeo Estos requerimientos nos informan las caractersticas de desempeo que deben de tener el sistema. Que tan rpido?, Que tan seguido?, Cuantos recursos?, Cuantas transacciones? Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeo de un sistema es tan crtico como su funcionamiento.

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO Disponibilidad (en un determinado periodo de tiempo) Este tipo de requerimientos se refiere a la durabilidad, degradacin, potabilidad, flexibilidad, contabilidad y capacidad de actualizacin. Este tipo de requerimientos es tambin muy importante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones crticas que no deben de estar fuera de servicio por periodos prolongados de tiempo. Entrenamiento Este tipo de requerimientos se enfoca a las personas que van usar el sistema. Que tipo de usuarios son?, Que tipo de operadores?, Que manuales se entregarn y en que idioma? Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de cdigo dentro del sistema, son muy importantes en el proceso de diseo ya que facilitan la introduccin y aceptacin del sistema en donde ser implementado. Restricciones de diseo Muchas veces las soluciones de un sistema de software son normadas por leyes o estndares, este tipo de normas caen como "restricciones de diseo". Materiales Aqu se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir los costos de industrializacin del sistema. * Manejo de requerimientos * De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos involucra: "Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de software. Este acuerdo son los requerimientos del sistema alojados al software." ". Este acuerdo cubre requerimientos tcnicos y no tcnicos (como fechas de entrega). El acuerdo forma las bases para estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a travs de todo su ciclo de vida." "Bajo las restricciones del proyecto, el grupo de manejo de requerimientos toma las medidas necesarias para que los requerimientos que estn bajo su responsabilidad estn documentados y controlados" De que manera podemos controlar los requerimientos de software si estos siempre evolucionan con el tiempo?. El CMM nos proporciona las guas para lograrlo. "Para lograr el control de los requerimientos, el grupo de requerimientos revisa los requerimientos antes de que estos sean incorporados al proyecto de software y cada vez que los requerimientos cambian los planes, productos, y actividades son ajustadas para quedar en lnea con los nuevos requerimientos de software". En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientos dbenos de tomar en cuenta dos cosas. Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos, y no son impuestos por en su totalidad por presiones externas ajenas al proyecto. El requerimiento tcnico podr ser impuesto por el mercado o presiones de la competencia, pero entonces los requerimientos no tcnicos (Calidad, Costo y

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO Tiempo de entrega) debern estar especificados de comn acuerdo con el grupo de requerimientos del proyecto de software. Los requerimientos tcnicos y no tcnicos forman un conjunto entre s, si cambia uno forzosamente debern cambiar los dems. Esto es: ms contenido tcnico implica o ms costo, o menos calidad o ms tiempo estimado de entrega. De modo que los cambios tcnicos debern ser aprobados por el grupo de requerimientos y este grupo estimar los impactos en tiempo, costo, calidad. El resultado de la estimacin es la entrada a los lderes del proyecto para decidir si el cambio se acepta o no. * ORGANIZACIN Y CAPTURA DE REQUERIMIENTOS DE USUARIO * Para prosperar en el mercado, cualquier producto debe satisfacer las necesidades de los usuarios, lo cual no resulta posible si no integra y pone al alcance del consumidor de forma comprensible los fundamentos de todos los aspectos del desarrollo. Para captar las necesidades especficas de los usuarios es indispensable que los documentos que recogen los requerimientos se redacten utilizando mtodos pragmticos. Se debe utilizar una metodologa detallada de definicin de los requerimientos de usuario. Organizar entrevistas destinadas a obtener la mxima informacin posible acerca de los requerimientos de los usuarios. Traducir las oportunidades / necesidades en requerimientos del proyecto. Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear un documento de requerimientos generales. Conseguir la participacin y confirmacin del usuario. Los gerentes y usuarios del sistema tambin poseen un papel importante en le diseo del sistema; no es solamente el proyecto del analista. Durante el diseo, a algunos se les pide que revisen los borradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura de los procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada. La participacin del usuario proporciona al analista una retroalimentacin importante conforme avanza en el diseo; adems asegura a los usuarios tengan un conocimiento no tcnico de lo realizara o no el nuevo sistema. Esta visin general del diseo de sistemas subraya los aspectos de diseo que se vern mas adelante en el diseo de la salida de sistema. * REQUERIMIENTOS DEL SISTEMA * Los Sistemas de Informacin por computadora normalmente estn integrados por muchos componentes. En la mayor parte de los casos, es difcil para los analistas entender todos estos componentes an mismo tiempo; por lo tanto los investigadores tienen que comenzar con preguntas de tipo general con relacin al propsito del sistema sus entradas y salidas de los procesos incluidos. En los grandes proyectos de sistema varios analistas llevan a cabo una investigacin en forma seccionada que la distribuye entre ellos mismos, de manera que cada uno pueda trabajar en forma independiente. Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de informacin. Se clasifican en dos tipos:

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO 1.- Flujo de Datos. 2.- Estrategias de Anlisis de Decisin para el Conocimiento para los Sistema de Informacin. * Estrategia del Flujo de Datos * Cuando se siguen un flujo a travs de los procesos de negocio, que es el propsito del anlisis del flujo de datos, le indica a los analistas una gran cantidad de datos sobre como s esta llevando a cabo los objetivos de la compaa. Al manejar las transacciones y completar las tareas, los datos de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten. El anlisis de flujo de datos que muestra el estudio y el uso de cada actividad, documenta los hallazgos en los diagramas de flujo de datos. * Estrategia del Anlisis de Decisiones * La estrategia del anlisis de decisiones es un complemento del anlisis del flujo de datos. Esta estrategia realza el estudio de los objetivos de una operacin y de las decisiones que deben realizarse para cumplir con los objetivos. Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial, la estrategia de anlisis de decisin con frecuencia utiliza por parte de alta gerencia para desarrollar la toma de decisiones. La alternativa que selecciona los gerentes responsables en la toma de decisiones, en cuanto a una estrategia de precios entre un conjunto de alternativas, se maneja de forma diferente a la opcin que toma un supervisor de departamento para aceptar o rechazar pedidos. La decisin de rechazar pedidos generalmente ocurre con ms frecuencia, de manera que las condiciones y acciones normalmente se conocen como un aspecto importante. * Etapas en la Estrategia del Anlisis del Flujo de Datos * 1. - Estudiar las operaciones y procesos en marcha. 2. - Identificar cmo se procesan los datos al manejar transacciones y terminar las tareas. 3. - Seguir el flujo de datos: * Proceso * Almacenamiento * Recuperacin * Salida 4. - Aadir gradualmente detalles a los niveles inferiores. Etapas en la Estrategia del Anlisis de Decisin 1. -Estudiar los objetivos y decisiones necesarias. 2. - Desarrollar un modelo del proceso de decisin. 3. - Probar el modelo con datos de prueba. 4. - Identificar los requerimientos del proceso para los datos. * Requerimientos De Entrada *

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO Es el enlace que une al sistema de informacin con el mundo y sus usuarios, en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son: Objetivos del Diseo de Entrada. Captura de Datos para la Entrada. Objetivo del Diseo de Entrada Consiste en el desarrollo de especificaciones y procedimientos para la preparacin de datos, la realizacin de los procesos necesarios para poner los datos de transaccin en una forma utilizable para su procesamiento as como la entrada de los datos se logra al instruir a la computadora para que lea ya sea documentos escritos, impresos por personas que los escriben directamente al sistema. Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos, controlar los errores y mantener la sencillez de los pasos necesarios, estos son: Control de la Calidad de Entrada Evitar los Retrasos Evitar los errores en los datos Evitar los pasos adicionales Mantener la Sencillez del Proceso Control de la Calidad de Entrada: Existen varias razones por las cuales un buen diseador debe controlar la cantidad de datos en la entrada: - Las Operaciones de preparacin y entrada dependen de las personas dado que los costos de mano de obra son altos y la preparacin de ingreso de los datos tambin lo son. La fase de entrada puede ser un proceso lento que toma mucho ms tiempo que el que necesitan las computadoras para realizar sus tareas. Evitar los Retrasos: Tambin conocido con el nombre de cuello de botella son siempre uno de los objetivos que el analista evita al disear la entrada, una forma de evitarle es utilizar los documentos de retorno. Evitar los errores en los datos: La tasa de errores depende de la cantidad de datos, ya que entre ms pequea sea esta menores sern las oportunidades para cometer errores. Es comn encontrar en las operaciones de ventas por lo menos un 3% de errores en las operaciones de entrada de datos. Evitar los Pasos Adicionales: Algunas veces el volumen de transacciones y la cantidad de datos en preparacin es algo que no se puede controlar por ello el analista experimentado, evitara diseos para la entrada que traigan una mayor cantidad de pasos a seguir. Ya sea aadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso de un da. Mantener la sencillez del Proceso: El sistema mejor diseado se ajusta a las personas que lo utilizarn y al

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO mismo tiempo proporcionarn mtodos para el control de los errores, la simplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajo que los usuarios acepten sistemas complejos o confusos y que no exista ninguna garanta para el xito al instalar un sistema complejo y que domine. Captura de Datos para la Entrada: En una transaccin existen datos importantes y otros que no, el analista debe saber cuales utilizar y cuales en realidad deben formar la entrada. Existen dos tipos de datos: datos variables datos de identificacin Datos Variables: Son aquellos que cambian para cada transaccin o toman de decisin. Datos de Identificacin: Estos son los que identifican en forma nica el artculo que esta siendo procesado. * Requerimientos De Salida * Niveles de diseo El diseo de sistema se representa a travs de dos fases: el diseo lgico y el diseo fsico. Cuando los analistas formulan un diseo lgico; escriben las especificaciones detalladas del nuevo sistema; esto es, describen sus caractersticas: las salidas, entradas, archivos y bases de datos y procedimientos; todos de manera que cubran los requerimientos del proyecto. El diseo lgico de un sistema de informacin es como el plano de un ingeniero para armar un automvil: muestra las caractersticas principales(motor, transmisin y rea para los pasajeros)y como se relacionan unas con otras(donde se conectan entre s los componentes del sistema, o por ejemplo, cuan separadas estn las puertas. Los informes y la produccin del analista son los componentes de todo el mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje. El diseo lgico tambin especifica las formas de entrada y las descripciones de las pantallas de todas las transacciones y archivos a fin de mantener los datos de inventario, los detalles de las transacciones y los datos del proveedor. Las especificaciones de los procedimientos describen mtodos para introducir los datos, corridas de informes copiados de archivos y deteccin de problemas. El diseo fsico, actividad que sigue el diseo lgico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseo indican a los programadores que debe hacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas por parte de los usuarios, procesan los datos, producen los informes y almacenan estos datos en los archivos. Utilizacin de los Datos de Requerimientos: El alcance del diseo de sistemas se gua por el marco de referencia para el nuevo sistema desarrollado durante el anlisis. Los datos de los requerimientos, recopilados durante la investigacin, conforman las

CALIDAD DE SOFWARE

INSTITUTO TECNOLOGICO SUPERIOR DE LERDO actividades y componentes del sistema. Los analistas formulan un diseo lgico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiar como resultado de un nuevo diseo. El diseo lgico va de arriba hacia abajo, como lo hizo la determinacin de requerimientos. En primer lugar se identifican las caractersticas generales, como informes y entradas; en el diseo de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato especfico para establecer cuanto espacio dejar en la informacin, en la pantalla de despliegue visual o archivo. A lo largo de los aos hemos visto una evolucin de ideas y tcnicas en el campo del anlisis de sistemas. La cual cabe en tres perodos amplios segn Yourdon:

CALIDAD DE SOFWARE