TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

Técnicas de
Auditoría en el
Desarrollo de
INTEGRANTES:

Software CARRILLO ODAR, LADY

FASANANDO LAM, OLENKA

DOCENTE:

ING. LUIS DÁVILA HURTADO

5 JULY

1
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

AUDITORÍA DE LA FASE DE ANÁLISIS

Análisis
[ CITATION Rog10 \l 3082 ] , Establece que la tarea del análisis de requisitos es un proceso
de descubrimiento, refinamiento, modelado y especificación. Se refina en detalle el ámbito del
Software, y se crean modelos de los requisitos de datos, flujo de información y control, y del
comportamiento operativo.

Para realizar el modelo de análisis primero hay que extraer las

necesidades del cliente.

 Entrevistas
Es un método que se utiliza bastante.
Se suele seleccionar a un grupo de personas que pertenezcan a todos los órganos más
importantes de la empresa, de este modo se tiene una visión general de las necesidades.
Durante las entrevistas se hace un mayor énfasis en aquellos sectores que
más van a usar la nueva aplicación a desarrollar.

 Talleres
Consiste en realizar discusiones entre las personas implicadas en la organización para
descubrir nuevos requisitos o la implicación de las necesidades.
Las técnicas más utilizadas son el brainstorming (donde se busca generar el mayor
número de ideas posibles con una técnica más coloquial) y el JAD (Join Application
Development, donde se busca generar la interfaz y los requisitos del sistema de un modo
más organizado).

 Formularios
Para este método se aportan a aquellos que van a utilizar la herramienta una serie de
formularios o contratos que deben rellenar indicando los requisitos que desean que la
nueva aplicación cumpla.
El inconveniente de esta herramienta es que en el caso de sistemas complejos los
formularios pueden ser realmente largos.

2
TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

 Prototipos
Los prototipos permiten a los clientes finales conocer una pequeña muestra de cómo va a
ser el producto final una vez se termine.
Este tipo de técnica ayuda a rectificar aquellos aspectos con los que los
usuarios no estén de acuerdo antes de tener el producto final.

 Los Requisitos
“La parte más difícil de construir un sistema es precisamente saber qué construir.
Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos
técnicos detallados, incluyendo todas las interfaces gente, máquinas y otros sistemas.
Ninguna otra parte del trabajo afecta tanto al sistema si se hace mal.
Ninguna es tan difícil de corregir más adelante.
...
Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la
extracción iterativa y el refinamiento del producto.”
Frederick P. Brooks

 Requisitos funcionales
Son aquellos servicios que el usuario espera del sistema. En principio, los requisitos
funcionales de un sistema deben ser completos y consistentes. Por completo se entiende
que todos los servicios requeridos por el usuario deben especificarse, y la consistencia
significa que ninguna definición de requisitos debe contradecir a otra.
En la práctica, para sistemas grandes y complejos, es casi imposible lograr que los
requisitos sean consistentes y completos en la versión inicial del documento. A medida
que se descubren los problemas durante las revisiones o en las etapas posteriores del
ciclo de vida, el documento debe modificarse en consecuencia. Hay tres maneras de
expresar los requisitos funcionales de un sistema:
• En lenguaje natural.
• En un lenguaje estructurado o en un formato que tenga algunas reglas, pero no una
especificación sintáctica o semántica rigurosa.
• En un lenguaje formal de especificación con una sintaxis y semántica definidas.

 Requisitos no funcionales
3
TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

Son restricciones u obligaciones impuestas al servicio de este. Ejemplos de requisitos no

funcionales son las obligaciones impuestas a los tiempos de respuesta del sistema, las
limitaciones en la cantidad de memoria que ocupará el software y las restricciones en la
representación de los datos del sistema.
Aunque tanto los requisitos funcionales como los no funcionales están sujetos a cambios,
los requisitos no funcionales se ven especialmente afectados por los cambios en la
tecnología de hardware.
• Rendimiento del sistema: fiabilidad, tiempo de respuesta, disponibilidad.
• Interfaces: dispositivos de E/S, usabilidad, interoperabilidad.
• Proceso de desarrollo: estándares, herramientas, plazo de entrega.
Estos requisitos engloban la tecnología con la que se debe trabajar.

AUDITORÍA DE LA FASE DE DISEÑO

Diseño
De acuerdo con [ CITATION Rog10 \l 3082 ], el objetivo del diseño es producir un
modelo o representación de una entidad que se va a construir posteriormente.

Para [ CITATION Rog10 \l 3082 ], El diseño de Software engloba cuatro etapas

diferentes:

 El diseño de datos o clases transforma los modelos de clases en realizaciones de

clases de diseño y en las estructuras de datos que se requieren para implementar el
Software.

 El diseño de la arquitectura define la relación entre los elementos principales de la

estructura del Software, los estilos y patrones de diseño de la arquitectura que pueden
usarse para alcanzar los requerimientos definidos por el sistema y las restricciones que
afectan la forma en la que se implementa la arquitectura.

 El diseño de la interfaz describe la forma en la que el Software se comunica con los

sistemas que interactúan con él y con los humanos que lo utilizan. Una interfaz implica

4
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

un flujo de información (por ejemplo, datos o control) y un tipo específico de

comportamiento. Entonces, los modelos de escenarios de uso y de comportamiento
dan mucha de la información requerida para diseñar la interfaz.

 El diseño en el nivel de componente transforma los elementos estructurales de la

arquitectura del Software en una descripción de sus componentes en cuanto a
procedimiento. La información obtenida a partir de los modelos basados en clase, flujo
y comportamiento sirve como la base para diseñar los componentes.

Figura 1.- Traducción del modelo de requerimientos al modelo de diseño.

Según [ CITATION KEN11 \l 3082 ], Los seis diagramas de UML que se utilizan
con más frecuencia son:

1. Un diagrama de casos de uso, que describe la forma en que se utiliza el sistema.

2. Un escenario de caso de uso (aunque técnicamente no es un diagrama). Este escenario
es una articulación verbal de excepciones para el comportamiento principal descrito por el
caso de uso principal.

5
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

3. Un diagrama de actividad, que ilustra el flujo de actividades en general. Cada caso de uso
puede crear un diagrama de actividad.
4. Los diagramas de secuencia, que muestran la secuencia de las actividades y las
relaciones entre las clases.
Cada caso de uso puede crear uno o más diagramas de secuencia. El diagrama de
comunicación es la alternativa a un diagrama de secuencia, el cual contiene la misma
información pero enfatiza la comunicación en vez de la sincronización.
5. Los diagramas de clases, que muestran las clases y sus relaciones. Los diagramas de
secuencia se utilizan (junto con las tarjetas CRC) para determinar las clases. El diagrama de
generalización/especialización (gen/spec) es un derivado del diagrama de clases.
6. Los diagramas de estados, que muestran las transiciones de estado. Cada clase puede
crear un diagrama de estados, el cual es útil para determinar los métodos de la clase.

6
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

Figura 3.- Una vista general de los diagramas de UML que muestra cómo cada
diagrama conduce al desarrollo de otros diagramas de UML.

[ CITATION KEN11 \l 3082 ], Por medio de una técnica de análisis estructurado conocida
como diagramas de flujo de datos (DFD), el analista de sistemas puede ensamblar una
representación gráfica de los procesos de datos a través de la organización. Al usar
combinaciones de sólo cuatro símbolos, el analista puede crear una descripción ilustrada de
los procesos con el fin de elaborar una documentación sólida para el sistema.

Ventajas de la metodología del flujo de datos

1. No hay que comprometerse demasiado pronto con la implementación técnica del sistema.

7
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

2. Permite comprender con más detalle la capacidad de interrelación de los sistemas y

subsistemas.
3. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de
diagramas de flujo de datos.
4. Se puede analizar un sistema propuesto para determinar si se han definido los datos y
procesos necesarios.

Figura 2.- Los cuatro símbolos básicos que se utilizan en los diagramas de flujo de
datos, sus significados y ejemplos.

AUDITORÍA DE LA FASE DE CONSTRUCCIÓN

Se desarrolla completamente el software y los documentos necesarios que componen el sistema. El resultado
de esta fase es un producto listo para que los usuarios lo puedan operar y consiste en el software integrado en
las plataformas adecuadas, los materiales para soporte del usuario y una descripción de la versión actual (esta
versión del sistema se llama la versión “beta”)

Se programarán y probarán los distintos componentes y se pondrán en marcha los procedimientos para que los
usuarios puedan trabajar con el sistema.

Objetivos

 Obtener la construcción completa del software.

 Documentación Técnica completa.

8
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

 Materiales para Soporte al Usuario completa.

 Materiales para Capacitación.

 Informe final de Verificación (conteniendo toda la información de la versión).

 Evaluación de la calidad del producto.

Actividades críticas

 Especificar los Requerimientos.

 Definir el Alcance del Sistema.

 Validar con Prototipo.

 Diseñar el Sistema.

 Especificar los Casos de Prueba.

 Ajustar y controlar el desarrollo.

 Planificar la Integración de la Iteración.

 Integrar el Sistema.

 Documentación de Usuario.

 Desarrollar los Materiales para Capacitación.

 Verificación Unitaria.

 Verificar el software.

 Verificar el Sistema.

 Seguimiento de la Línea Base.

 Seguimiento de Proyecto.

 Estimaciones y Mediciones.

 Planificar la Transición.

 Describir la Versión.

Actividades no críticas

 Revisión Técnica Formal (Interfase de Usuario, Materiales para Soporte al Usuario, Documentación

Técnica, Informes de Verificación).

 Revisar el Ajuste al proceso.

 Documentación Técnica.

Desarrollo de los Componentes del Sistema (DCS):

Se desarrollan los distintos componentes, se prueban individualmente como integrados y se desarrollan los
procedimientos de operación.

OBJETIVO DE CONTROL: Los componentes o módulos deben desarrollarse utilizando técnicas de programación
correctas.
9
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

1. Debe prepararse el entorno de desarrollo y de pruebas, así como los procedimientos de operación.
2. Debe programarse, probar y documentar cada uno de los componentes.
3. Deben realizarse las pruebas de integración para asegurar que las interfaces entre los componentes o
módulos funcionan.

Desarrollo de los Procedimientos de Usuario (DPU):

Se definen los procedimientos y formación para que los usuarios puedan utilizar el nuevo sistema. Instalación,
conversión de datos y operación/explotación.

OBJETIVO DE CONTROL: Los futuros usuarios deben estar capacitados y disponer de los medios para hacer buen
uso del sistema.

1. Desarrollo de los componentes debe estar planificado.

2. Debe especificarse los perfiles de usuario.
3. Deben desarrollarse todos los procedimientos de usuario con arreglo a los estándares.
4. Deben definirse los procesos de formación o selección de personal.
5. Deben definirse los recursos materiales necesarios para el trabajo de los usuarios.

AUDITORÍA DE LA FASE DE IMPLANTACIÓN

Se realiza la aceptación del sistema por parte de los usuarios y las actividades de puesta en marcha.

Pruebas, Implantación y Aceptación del Sistema (PIA):

Se verifica que el sistema cumple con los requisitos establecidos. Ya probado y aceptado, se pondrá en
explotación.

OBJETIVO DE CONTROL 1: El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en
explotación.

1-1: Deben realizarse las pruebas del sistema que se especificaron.

1-2: Debe revisarse el plan de implantación y aceptación para adaptarlo al final del proyecto.

10
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

1-3: Debe aceptarse el sistema por los usuarios antes de ponerse en explotación.

OBJETIVO DE CONTROL 2: El sistema se pondrá en explotación formalmente y pasará a estar en mantenimiento

sólo cuando haya sido aceptado y esté preparado.

2-1: Deben instalarse todos los procedimientos de explotación.

2-2: El sistema nuevo se pondrá en explotación de forma coordinada con la retirada del antiguo (si existe)
migrando los datos si es necesario.

2-3: Debe firmarse el final de la implantación por parte de los usuarios.

2-4: Debe supervisarse el trabajo de los usuarios durante las primeras semanas.

2-5: Para terminar el proyecto se pondrá en marcha el mecanismo de mantenimiento.

LINKOGRAFIA

 http://informatica.uv.es/docencia/iiguia/asignatu/2000/IPI/material/tema9.pd
f
 http://bdigital.unal.edu.co/50720/1/Auditoriadeproyectos_GermanGomez.pdf
11
 TECNICAS DE AUDITORIA EN DESARROLLO DE SOFWARE

 https://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/dvd01/experiencia
2005/MUM/dat/DimTiempo/fasec.htm

Referencias Bibliográficas
Brooks, F. P. (s.f.).

KENDALL, K., & KENDALL, J. (2011). Análisis y Diseño de Sistemas, Octava edición, Kendall & Kendall. México,:
Pearson Educación de México, S.A. de C.V.

Pressman, R. (2010). Ingeniería del Software Un enfoque práctico, Séptima edición. New York: McGraw-Hill.

12