Comprobacion - de - Software - 01 Clase 17-11-22

COMPROBACION DE SOFTWARE
Profesor: Juan C. Rojas Farro

Correo: juancho10.jcrf@gmail.com
INSTITUTO SABIO NACIONAL ANTUNEZ DE MAYOLO - ISAM Comprobación de Software
CONCEPTOS PREVIOS
ISAM Diapositiva 2 Prof. Juan C. Rojas Farro

¿Qué es un organigrama de una empresa?

Un organigrama es una representación visual de la jerarquía del personal y la estructura y flujo de la información
dentro de una empresa.
Es posible identificar de un modo directo las diferentes relaciones entre funciones, departamentos, equipos e
individuos. En otras palabras, una imagen clara de la cadena de mando, el flujo de autoridad y la comunicación
de arriba a abajo.
No existen reglas estrictas y rápidas para hacer un organigrama. Mientras el gráfico esté organizado por rango
con ramas claras que exhiban relaciones con los empleados, el dibujo en está abierto a muchas posibilidades
creativas dependiendo de la industria, el número de empleados, etc…
El organigrama refleja la estructura de una empresa, sus niveles y fuerza laboral, lo que facilita la comprensión
organizativa y funcional, siendo una verdadera hoja de ruta para los nuevos empleados y un recurso eficaz para la
empresa.

ORGANIGRAMA DE UN EMPRESA

¿Qué es una fabrica de Software?

Una fábrica de software es una empresa de la industria del software cuya misión es el desarrollo de software para sus clientes de
acuerdo a los requisitos específicos que aquel le solicita.
Típicamente una fábrica de software tiene como su principal fuente de ingreso la venta de proyectos de desarrollo de software, como así
también la venta de horas hombre de desarrollo de software. Generalmente la propiedad intelectual de las aplicaciones informáticas
desarrolladas le pertenecen al cliente. La diferencia principal entre una empresa de Consultoría de Sistemas y un servicio de Fábrica de
Software radica en que la primera cubriría toda el Ciclo de Vida de Software, desde la toma de requerimientos y diseño funcional hasta
la construcción, pruebas de aceptación e implantación; mientras que la segunda ínicia su tarea a partir de un diseño funcional que
"otros" han realizado. Por tanto, los skills de una factoría de software son claramente diferentes: requieren de un menor conocimiento
de la necesidades del futuro usuario de negocio, existe más flexibilidad respecto a la ubicación geográfica de la factoría (al no requerir
cercanía con el futuro usuario del sistema a fin de definir el requerimiento)y se especializan para conseguir calidad de software a menor
coste, automatizando e industrializando los procesos de desarrollo de software donde aplique.
Por lo general la fábrica de software tiene ingresos adicionales por los servicios asociados que brinda a los clientes a los que les
desarrolla las aplicaciones informáticas, tales como el mantenimiento, la capacitación, la actualización, el despliegue, el soporte, etc.
Existe una gran diferencia entre una fábrica de software de una fábrica de productos de software, dado que esta última se dedica al
desarrollo de software para la generación de productos propios basados en aplicaciones informáticas cuya propiedad intelectual le
pertenece.
Es necesario también tener en cuenta que al emprender una fábrica de software se debe capacitar muy bien al personal que va a
trabajar para ser más eficientes y contribuyan al desarrollo continuo y avanzado en el transcurrir del tiempo y de las necesidades.

ORGANIGRAMA DE UNA FABRICA DE SOFTWARE


PROCESO DE PRUEBAS
Las pruebas de software (en inglés software testing) son las investigaciones empíricas y
técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad
del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control
de calidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier
momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software,
así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento
en las actividades de desarrollo.

PROCESO DE PRUEBAS


VERIFICACION Y VALIDACION
La verificación y validación es el nombre que se da a los procesos de comprobación y análisis que aseguran que
el software que se desarrolla está acorde a su especificación y cumple las necesidades de los clientes. La V&V es
un proceso de ciclo de vida completo. Inicia con las revisiones de los requerimientos y continúa con las
revisiones del diseño y las inspecciones del código hasta la prueba del producto. Existen actividades de V&V en
cada etapa del proceso de desarrollo del software.
La verificación y la validación no son la misma cosa , aunque es muy fácil confundirlas, Boehm (1979) expresó la
diferencia entre ellas de forma sucinta:
• Verificación: ¿Estamos construyendo el producto correctamente? El papel de la

verificación comprende comprobar que el software está de acuerdo con su especificación.
Se comprueba que el sistema cumple los requerimientos funcionales y no funcionales que
se le han especificado.

• Validación: ¿Estamos construyendo el producto concreto? La validación es un proceso

mas general. Se debe asegurar que el software cumple las expectativas del cliente. Va mas
allá de comprobar si el sistema está acorde con su especificación, para probar que el
software hace lo que el usuario espera a diferencia de lo que se ha especificado.
Es importante llevar a cabo la validación de los requerimientos del sistema de forma inicial.
Es fácil cometer errores y omisiones durante la fase de análisis de requerimientos del sistema y, en tales casos,
el software final no cumplirá la expectativas de los clientes. Sin embargo, en la realidad, la validación de los
requerimientos no puede descubrir todos los problemas que presenta la aplicación. Algunos defectos en los
requerimientos solo pueden descubrirse cuando la implementación del sistema es completa.

VALIDACION Y VERIFICACION

CALIDAD DE SOFTWARE
Para definir qué es la calidad del software, comencemos definiendo qué es calidad y esta se define como un
conjunto de características subyacentes a un producto o servicio que cumplen determinados requisitos para
satisfacer las necesidades de un cliente. Y ¿qué es un software y cuál es su papel en la sociedad actual?
El software se puede definir como un conjunto de programas intangibles encargados de recibir órdenes, procesar
datos y reflejar resultados, estas son características que hacen que el software sea muy demandado pues facilita,
complementa o automatiza tareas y procesos que se llevan a cabo en el día a día de los diferentes hogares y
organizaciones.
Teniendo claro los dos conceptos anteriores se puede inferir que calidad en el software está en relación directa
con el cumplimiento de los requerimientos formulados por el usuario, de tal forma que si un programa no cumple
con alguno de estos requerimientos, es un software de baja calidad. Aunque el criterio de cumplimiento de los
requerimientos es un factor importante, no es el único, ya que existen condiciones implícitas que el software debe
cumplir como son eficiencia, seguridad, integridad, consistencia, entre otras.

POR LO TANTO
No podemos afirmar que un software es de alta calidad cuando cumple con los
requerimientos del usuario, si:
 No es eficiente al utilizar los recursos de la máquina (programas muy lentos).

 No es confiable; los resultados que entrega varían, no son siempre iguales al procesar los
mismos datos.
 No es fácil de utilizar.
 No es seguro.
 No es fácil hacerle mantenimiento.


ALGUNAS CARACTERISTICAS DE LA CALIDAD DE SW

 Funcionalidad: Lo que el producto puede hacer, asegurando que el producto funciona tal
como estaba especificado.
 Fiabilidad: Probabilidad de que un sistema, aparato o dispositivo cumpla una
determinada función bajo ciertas condiciones y durante un tiempo determinado.
 Usabilidad: Cuando el software es sencillo de usar, cumpliendo las expectativas del futuro
usuario del mismo.
 Eficiencia: Cuando el software alcanza el objetivo fijado, con el tiempo marcado y sin
derrochar recursos.
 Mantenimiento: Capaz de darle mantenimiento de una manera sencilla localizando y
corrigiendo los errores del producto software.
 Portabilidad: Software compatible con otras plataformas.

INSPECCIONES DE SOFTWARE
Analizan y comprueban las representaciones del sistema como el documento de
requerimientos, los diagramas de diseño y el código fuente del programa. Las inspecciones
de software y los análisis automatizados son técnicas estáticas puesto que no requieren que
el sistema se ejecute.
• Implican que las personas examinen la representación de la fuente con el propósito de descubrir anomalías y defectos
• Las inspecciones no requieren la ejecución de un sistema por lo que debe utilizarse antes de la implementación.
• Pueden estar aplicados a cualquier representación del sistema (requerimientos, diseño, configuración, datos, pruebas de
datos, etc).
• Se ha demostrado que es una técnica efectiva para descubrir errores del programa.

Inspecciones y Pruebas
Las inspecciones y pruebas son complementarias y no técnicas opuestas de verificación.
Ambas deben utilizarse durante el proceso V & V.
Las inspecciones pueden comprobar el ajuste con una especificación pero no la conformidad
con los requerimientos reales del cliente.
Las inspecciones no pueden comprobar características no funcionales como rendimiento,
usabilidad, etc.

Inspecciones de programas
Es la aproximación formalizada a las revisiones del documento
Está pensado explícitamente para la detección de defectos (no su corrección)
Los defectos pueden ser errores lógicos, anomalías en el código que pueden indicar una
condición errónea (p.ej: una variable no iniciada) o no conformidad con los estándares.

Precondiciones de la inspección
Debe haber una especificación precisa disponible.
Los miembros del equipo deben estar familiarizados con los estándares de organización.
Debe estar disponible un código sintácticamente correcto u otras representaciones del
sistema.
Debería prepararse una lista de errores.
La gestión debe aceptar que la inspección aumentará los costes pronto en el proceso de
software.
La gestión no debería utilizar inspecciones para la evaluación del personal, es decir, para
encontrar quién comete errores.

Proceso de inspección
• Visión de conjunto del sistema presentado al
equipo de inspección.
• Los códigos y documentos asociados se
distribuyen al equipo de inspección por
adelantado.
• La inspección tiene lugar y se anotan los
errores encontrados.
• Se hacen modificaciones para reparar los
errores descubiertos.
• Puede requerirse o no una re inspección.



Etapas de desarrollo de un software

Cada nueva idea de un programa debe pasar por una serie de etapas de desarrollo. A nivel
general son siempre 6 :
• Análisis
• Diseño
• Desarrollo
• Pruebas
• Pase a Producción
• Mantenimiento.
Cada empresa o incluso cada desarrollador pueden tener una serie de sub-etapas y así mismo
modificar las etapas generales para acomodarse a su estilo. Algunos desarrollos son
denominados así porque necesita de algunos objetos nuevos, pero pueden ser mejoras o
correcciones sobre otros proyectos.

Análisis
Es la primera de las etapas de desarrollo, corresponde a escuchar las peticiones para el sistema.
Se planifica la forma de llevar las ideas a un software, acá no debe ser un impedimento el
lenguaje de programación ni la infraestructura. Desde el consultor de sistemas se proponen
mejoras que a veces el usuario ignora para mejorar el programa. Yo suelo utilizar prototipos para
que el usuario tenga una vista previa y realice modificaciones antes de cualquier otra fase. Al
final de esta fase se verifica si existe un ambiente de sistemas previamente instalado o si es un
desarrollo totalmente nuevo. No olvidar incluir presupuesto de servidores, licencias, bases de
datos entre lo más destacado.

Diseño
En esta fase es cuando se realiza toda la infraestructura que va a sostener el proyecto.
Normalmente hablamos de objetos de base de datos, especialmente las tablas y las relaciones
entre ellas. Se preparan todas las funcionalidades necesarias para suplir los requerimientos
detectados en el análisis. Yo presento un segundo prototipo ya que el primero solo incluye
funcionalidades, este muestra algo de diseño.
El usuario siempre quiere incluir más cosas y se debe dejar en claro que esto influye en el tiempo
y el costo del proyecto. Tras aprobar el prototipo se presenta la propuesta y se llega a un
acuerdo. El problema principal está en calcular el tiempo para las etapas de de desarrollo, para
esto es mejor dar un tiempo previsto pero que se pague sobre las funcionalidades. Si el proyecto
es muy complejo es mejor realizarlo por etapas para evitar desbordar el tiempo y el costo de
todo el programa.

Desarrollo
Es el momento del código es independiente del lenguaje de programación, de las
metodologías, del estilo del programador, etc. Se pueden presentar mejoras u objeciones
sobre el rendimiento del programa. Dentro de las etapas de desarrollo es la más delicada
porque cada modificación puede cambiar toda la planificación. Esta fase tiene en si sub-fases a
implementar:
• Análisis y diseño
• Codificación
• Pruebas ingenieriles
• Ajustes
El avance del software se suele presentar aquí sobre el número de funcionalidades totales
sobre las completadas.

Análisis y Diseño
A diferencia de las etapas de la idea el programador debe identificar procesos y funciones que se puedan reutilizar. Esto con la intención de
llevarlas a una librería para el software. Así mismo dependiendo del lenguaje de programación puede calcular de forma previa el tiempo de
desarrollo sobre los requerimientos.
Codificación
La creación de librerías se termina haciendo de forma dinámica, y se modifica varias veces a medida que se necesita. Esto es así por lo menos en
mi caso, pero puede ser que la persona que hizo el diseño, tenga mucha experiencia lo cual evitaría esta particularidad. Luego de eso se realizan
los formularios, pantallas, reportes entre otras solicitudes. Estas últimas incluyen comunicación con otros programas así como interfaces entre
otros.
Pruebas ingenieriles
Estas son las pruebas de cada funcionalidad en cada pantalla o reporte. Se debe probar la creación, modificación, consulta y eliminación en cada
caso. Algunos ingenieros suelen automatizar este proceso, pero yo prefiero hacerlo por lo menos híbrido. Ya que en el camino se van presentando
ajustes y pruebas sobre los mismos. Es preferible anotar todos los ajustes para adaptarlos después sino esta fase se podría alargar demasiado.
Estas pruebas son diferentes a las pruebas principales ya que estas son realizadas por los programadores y las otras por usuarios que
normalmente no saben de programación.
Ajustes
Algunos incluyen esta fase con la anterior ya que apenas finaliza hay que realizar de nuevo las pruebas. Puede haber varios ciclos que retrasan los
proyectos, pero es inevitable en algunos casos. Por otra parte si los programadores son muy novatos se presentan demasiados bugs (fallas del
sistema). Entonces los equipos de desarrollo deberían tener una combinación entre novatos y experimentados para la totalidad de las etapas de
desarrollo.

Pruebas
Estas son pruebas realizadas por usuarios finales, los cuales debe estar disponibles. Es
recomendable tener varios usuarios ya que uno solo no encontraría todas las posibles fallas. Se
puede presentar una lista de pruebas a realizar para evitar que se salten módulos o pantallas. De
acá se genera una gran lista de bugs detectados que pasan a ajustarse en una serie de ciclos. Es
muy importante dejar en claro que no se van a desarrollar nuevas funcionalidades.

Producción y mantenimiento
Los desarrollos se hacen en ambientes locales, es decir en las máquinas de los desarrolladores.
En el análisis se debe dejar en claro que se necesita para que todo funcione correctamente.
Muchas veces olvidamos la documentación del programa, este es el momento de realizarla.
¿Porque no antes? Bueno habría que modificar la documentación al tiempo con las pruebas. Ya
deben estar disponibles los dominios, redes, servidores o hosting, etc. A partir de acá empieza a
correr términos de garantías, como el soporte y estabilidad. Al finalizar el periodo de garantía es
posible realizar una extensión sobre la misma. Pero es aún mejor ofrecer el servicio de soporte
externo sobre la aplicación o un nuevo proyecto. Esta es la última de las etapas de desarrollo de
un software para una sola versión.


Auditoria informática
Auditoría informática es un proceso llevado a cabo por profesionales especialmente capacitados
para el efecto, y que consiste en recoger, agrupar y evaluar evidencias para determinar si un
sistema de información salvaguarda el activo empresarial, mantiene la integridad de los datos,
lleva a cabo eficazmente los fines de la organización, utiliza eficientemente los recursos, y cumple
con las leyes y regulaciones establecidas.
Así mismo permiten detectar de forma sistemática el uso de los recursos y los flujos de
información dentro de una organización y determinar qué información es crítica para el
cumplimiento de su misión y objetivos, identificando necesidades, duplicidades, costes, valor y
barreras, que obstaculizan flujos de información eficientes.

Objetivos de la auditoria informática

La auditoría informática deberá comprender no sólo la evaluación de los equipos de cómputo, de un sistema o procedimiento
específico, sino que además habrá de evaluar los sistemas de información en general desde sus entradas, procedimientos,
controles, archivos, seguridad y obtención de información.
La auditoría informática es de vital importancia para el buen desempeño de los sistemas de información, ya que proporciona los
controles necesarios para que los sistemas sean confiables y con un buen nivel de seguridad.
Los aspectos relativos al control de la seguridad de la Información tienen tres líneas básicas en la auditoria del sistema de
información:
• La seguridad operativa de los programas, seguridad en suministros y funciones auxiliares, seguridad contra radiaciones,
atmósferas agresivas, agresiones y posibles sabotajes, seguridad físicos de las instalaciones, del personal informático, etc.
• La confidencialidad y la seguridad informática hace referencia no sólo a la protección del material, el logicial, los soportes de la
información, sino también al control de acceso a la propia información.
• En relación a los aspectos jurídicos y económicos relativos a la seguridad de la información hace referencia a analizar la
adecuada aplicación del sistema de información en la empresa en cuanto al derecho a la intimidad y el derecho a la
información, y controlar los cada vez más frecuentes delitos informáticos que se cometen en la empresa.
Además debe evaluar todo lo relacionado a la informática, organización de centros de información, hardware y software.

Características de la auditoria informática

La información de la empresa y para la empresa, siempre importante, se ha convertido en un activo real de la
misma, como sus stocks o materias primas si las hay. Por lo que ha de realizarse inversiones informáticas, materia
de la que se ocupa la auditoría de inversión informática.
Los sistemas informáticos han de protegerse de modo global y particular a ello se debe la existencia de la
auditoría de seguridad informática en general, o a la auditoría de seguridad de alguna de sus áreas, como
pudieran ser Desarrollo o Técnica de Sistemas.
Cuando existen cambios estructurales en la informática, se debe de reorganizar de alguna forma su función se
está en el campo de la auditoría de organización informática. Estos tipos de auditorías engloban a las actividades
auditoras que se realizan en una auditoría parcial.
Cuando se realiza una auditoria del área de desarrollo de proyectos de la informática de una empresa, es porque
en ese desarrollo existen, además de ineficiencias, debilidades de organización, o de inversiones, o de seguridad,
o alguna mezcla de ellas.

AUDITORIA DE SISTEMAS

¿Preguntas?

Comprobacion - de - Software - 01 Clase 17-11-22

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Comprobacion - de - Software - 01 Clase 17-11-22

Cargado por

Copyright:

Formatos disponibles

COMPROBACION DE SOFTWARE

Profesor: Juan C. Rojas Farro

ISAM Diapositiva 2 Prof. Juan C. Rojas Farro

¿Qué es un organigrama de una empresa?

ISAM Diapositiva 3 Prof. Juan C. Rojas Farro

ISAM Diapositiva 4 Prof. Juan C. Rojas Farro

¿Qué es una fabrica de Software?

ISAM Diapositiva 5 Prof. Juan C. Rojas Farro

ORGANIGRAMA DE UNA FABRICA DE SOFTWARE

ISAM Diapositiva 6 Prof. Juan C. Rojas Farro

ISAM Diapositiva 7 Prof. Juan C. Rojas Farro

ISAM Diapositiva 8 Prof. Juan C. Rojas Farro

ISAM Diapositiva 9 Prof. Juan C. Rojas Farro

ISAM Diapositiva 10 Prof. Juan C. Rojas Farro

• Verificación: ¿Estamos construyendo el producto correctamente? El papel de la

ISAM Diapositiva 11 Prof. Juan C. Rojas Farro

• Validación: ¿Estamos construyendo el producto concreto? La validación es un proceso

ISAM Diapositiva 12 Prof. Juan C. Rojas Farro

ISAM Diapositiva 13 Prof. Juan C. Rojas Farro

ISAM Diapositiva 14 Prof. Juan C. Rojas Farro

 No es eficiente al utilizar los recursos de la máquina (programas muy lentos).

ISAM Diapositiva 15 Prof. Juan C. Rojas Farro

ISAM Diapositiva 16 Prof. Juan C. Rojas Farro

ALGUNAS CARACTERISTICAS DE LA CALIDAD DE SW

ISAM Diapositiva 17 Prof. Juan C. Rojas Farro

ISAM Diapositiva 18 Prof. Juan C. Rojas Farro

ISAM Diapositiva 19 Prof. Juan C. Rojas Farro

ISAM Diapositiva 20 Prof. Juan C. Rojas Farro

ISAM Diapositiva 21 Prof. Juan C. Rojas Farro

ISAM Diapositiva 22 Prof. Juan C. Rojas Farro

ISAM Diapositiva 23 Prof. Juan C. Rojas Farro

ISAM Diapositiva 24 Prof. Juan C. Rojas Farro

Etapas de desarrollo de un software

ISAM Diapositiva 25 Prof. Juan C. Rojas Farro

ISAM Diapositiva 26 Prof. Juan C. Rojas Farro

ISAM Diapositiva 27 Prof. Juan C. Rojas Farro

ISAM Diapositiva 28 Prof. Juan C. Rojas Farro

ISAM Diapositiva 29 Prof. Juan C. Rojas Farro

ISAM Diapositiva 30 Prof. Juan C. Rojas Farro

ISAM Diapositiva 31 Prof. Juan C. Rojas Farro

ISAM Diapositiva 32 Prof. Juan C. Rojas Farro

ISAM Diapositiva 33 Prof. Juan C. Rojas Farro

Objetivos de la auditoria informática

ISAM Diapositiva 34 Prof. Juan C. Rojas Farro

Características de la auditoria informática

ISAM Diapositiva 35 Prof. Juan C. Rojas Farro

ISAM Diapositiva 36 Prof. Juan C. Rojas Farro

ISAM Diapositiva 37 Prof. Juan C. Rojas Farro

También podría gustarte