universidad regional autÓnoma de los …dspace.uniandes.edu.ec/bitstream/123456789/2825/1/... ·...

UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES

“UNIANDES”

TESIS DE GRADO PREVIO A LA OBTENCIÓN DEL TITULO DE INGENIERO EN SISTEMAS

TEMA:

MÉTRICAS DE CALIDAD Y EL DESARROLLO DE SOFTWARE

COMPETITIVO EN LA EMPRESA J-M SOFTWARE DEVELOPER

DE LA CIUDAD DE AMBATO

AUTORES:

TEC. JORGE AGUAYO

TUTOR:

MGS. EDUARDO FERNÁNDEZ

AMBATO-ECUADOR

2014

DEDICATORIA

A Dios, por permitirme llegar a este momento tan importante en mi formación

Profesional. A mi madre y padre por apoyarme en todos los momentos difíciles y

demostrarme siempre su apoyo incondicional y guiarme por el sendero del progreso y

trabajo inculcándome valores de honestidad, respeto y amor. A mi amada esposa quien

con su amor hemos sabido conllevar de mejor manera todas las adversidades

convirtiéndonos en sustento y apoyo mutuo. A mi adorado hijo quien con sus

ocurrencias nos llena de valor y fortaleza para afrontar las adversidades de este difícil

camino de la vida.

AGRADECIMIENTO

Quiero agradecer a todos quienes me ayudaron en mi formación profesional, a Dios por

darme la vida y orgullo de tener a mis padres conmigo. A mi madre y padre por haber

sembrado en mí la semilla del esfuerzo, la dedicación la constancia, el honor, la lealtad,

la verdad y ser los mejores maestros de mi vida con su ejemplo y guiarme permanente.

A mi esposa que me han ayudado a comprender que lo mejor que se tiene en esta vida

es una familia unida. A mis maestros de la carrera pilar fundamental del conocimiento

quienes con su gran sabiduría, profesionalismo y calidad humana me han ayudado a

explotar mis potencialidades.

ÍNDICE GENERAL

PORTADA ................................................................................................................................... CERTIFICACIÓN DEL ASESOR ........................................................................................... DECLARACIÓN DE AUTORÍA DE LA TESIS .................................................................... DEDICATORIA .......................................................................................................................... AGRADECIMIENTO ................................................................................................................ INDICE GENERAL ................................................................................................................... RESUMEN EJECUTIVO .......................................................................................................... SUMMARY ................................................................................................................................. INTRODUCCIÓN .................................................................................................................... 1 Antecedentes de la investigación ............................................................................................. 1 Planteamiento del problema.- .................................................................................................. 1 Formulación del problema ....................................................................................................... 5 Delimitación del problema ....................................................................................................... 3 Objeto de Investigación y campo de acción ............................................................................ 3 Identificación de línea de investigación .................................................................................. 3 Objetivo General ....................................................................................................................... 3 Objetivos Específicos ................................................................................................................ 3 Idea a Defender y variables ...................................................................................................... 4 Justificación del tema. .............................................................................................................. 4 Metodología ............................................................................................................................... 5 Resumen de la estructura de la tesis ....................................................................................... 6 CAPITULO I ............................................................................................................................. 8 MARCO TEÓRICO ................................................................................................................. 8 1.1 Evolución del Software ....................................................................................................... 8 1.2 Conceptos Generales sobre la Ingenieria del Software ................................................. 12 1.3 Tipos de Software .............................................................................................................. 15 1.4 Etapas en el desarrollo del software ................................................................................ 15 1.5 Estándares de calidad para análisis, diseño, construcción y pruebas de software ..... 18 1.6 El I.E.E.E ......................................................................................................................... 18 1.6.2 IEEE práctica recomendada para requisitos de software especificaciones (IEEE std 830-1998) ............................................................................................................... 20 1.6.2.1 Visión general del producto ...................................................................................... 21 1.6.2.2. Restricciones ............................................................................................................... 23 1.6.3. Estándares del producto fase desarrollo ..................................................................... 24 1.6.4. Estándares del producto fase Mantenimiento .......................................................... 25

1.6.4.1 Estructura del documento del usuario del software ................................................ 26 1.6.4.2. Contenido de información del documento del usuario del software ..................... 27 1.6.4.3. Formato de documentación del usuario del software ............................................ 28 1.6.5. Std 730-1998 norma IEEE para planes de aseguramiento de la calidad del software . .................................................................................................................................. 31 1.6.5.1 .- El plan de aseguramiento de calidad de software. ................................................ 32 1.6.5.2 Descripción del diseño del software (sdd). ................................................................ 33 1.6.5.3 Norma IEEE para los planes de gestión de proyectos de software - IEEE std 1058-1998. ................................................................................................................................ 34 1.6.5.4 IEEE estándar para la verificación y validación de software - IEEE STD 1012-2004 ................................................................................................................................. 40 1.6.5.5. Norma IEEE para planes de gestión de la configuración de software - IEEE STD 828-1998 .......................................................................................................................... 65 1.6.5.6. Estándar iEEE para la documentación de pruebas de software - IEEE STD 829-1998 ................................................................................................................................... 68 1.6.5.7 IEEE practica recomendada para pruebas unitarias de software. IEEE STD 1008 - 1987 (r 2003) ........................................................................................................ 71 CAPITULO II ......................................................................................................................... 78 MARCO METODOLÓGICO Y PLANTEAMIENTO DE LA PROPUESTA ............... 78 2.1. La Empresa ..................................................................................................................... 78 2.2. Diseño Metodológico ....................................................................................................... 78 2.3. Conclusiones parciales del capitulo ............................................................................... 94 CAPITULO III ........................................................................................................................ 95 DESARROLLO DE LA PROPUESTA ................................................................................ 95 3.1 Tema: ................................................................................................................................. 95 3.2 Descripción de la propuesta ............................................................................................. 95 3.3 Desarrollo de la Propuesta ............................................................................................... 95 3.3.1 Métrica propuesta para evaluar la calidad del software ...................................... 1028 3.3.1.1 Métricas para determinar el factor de calidad ...................................................... 98 3.3.2 Aplicación de la metrica. caso practico .................................................................... 100 3.4. Conclusiones parciales del Capitulo ........................................................................... 107 CONCLUSIONES Y RECOMENDACIONES .................................................................. 109 BIBLIOGRAFIA ........................................................................................................................ ANEXOS ......................................................................................................................................

INDICE DE TABLAS

Tabla 1 Población involucrada en la problemática. .................................................. 82

Tabla 2 Resultados obtenidos pregunta 1. .................................................................. 83








Tabla 10 Resultados obtenidos pregunta 3. ................................................................ 91




INDICE DE GRÁFICOS

Gráfico 1 Ilustración gráfica pregunta 1. ................................................................... 83









Gráfico 10 Ilustración gráfica pregunta 4. ................................................................. 92



RESUMEN EJECUTIVO

La propuesta planteada consistió en la implementación de un conjunto de métricas, las

mismas que permitirán evaluar la calidad de un software y permitir su mejoramiento

respectivo. Dichas métricas se han deducido de un modelo de calidad basado en normas

ISO.

Se desarrolló un portal web demostrativo, en el cual se aplicaron dichas normativas

diseñadas. Las herramientas que hemos utilizado para la realización del portal web son las

denominadas de uso libre, así tenemos: Apache, Mysql, Php, y java script, también se utilizó el

manejador de páginas web como es Dreamweaver.

En cuanto a la tesis en sí esta tiene una parte introductoria donde se plantea el problema

relacionado con la baja calidad del software desarrollado, así mismo se plantean

objetivos y la novedad de que dispone este trabajo investigativo. En el denominado

marco teórico se fundamenta teóricamente todo lo que tiene que ver con desarrollo de

software y normas de calidad, así como también a las métricas que pueden aplicarse en

los diferentes estándares definidos como los ISO.

Luego viene el marco metodológico, donde se desarrolla la investigación de campo,

aquí se ratifica la problemática en base a encuestas y entrevistas, dicha problemática

relacionada con el mayor o menor conocimiento de las estándares mínimos de calidad

que debe tener un software para considerarlo de tipo competitivo.

Finalmente tenemos la propuesta de solución que si consiste en la elaboración de un

conjunto de métricas aplicables para evaluar la calidad de un software desarrollado,

estas métricas basada en el modele de estándares ISO 9620.

SUMMARY

The proposal put forward is the implementation of a set of metrics that will enable them

to evaluate the quality of a software and allow respective improvement .

We developed a web portal demonstration , in which these regulations are designed and

implemented a parallel in it that are not taken into account these regulations , then made

a comparative study between the two for validation of the metrics applied .

The tools we have used to implement the so-called web portal are free to use, as

follows: Apache, MySQL, Php, java script and also use the web handler as

Dreamweaver.

As for the thesis itself this is an introductory part where the problem is related to the

low quality of the software developed, also have objectives and the novelty of this

research work available. In the so-called theoretical framework is based theoretically

everything that has to do with software development and quality standards. Then comes

the methodological framework, which develops the field research, the problem here is

ratified based on surveys and interviews. Finally we have the proposed solution is that if

the development of a set of metrics by which to assess the quality of a developed

software.

1

INTRODUCCIÓN

Antecedentes de da investigación

Luego de una investigación previa realizada en la biblioteca de la Universidad, se

pudo apreciar que no existen trabajos realizados directamente con el tema, pero se

procedió a revisar tesis que tienen que ver con el área informática, así por ejemplo

podemos señalar el trabajo de los ingeniero Ing. Carlos Martínez y Freddy Baño

“Sistema de Información para la toma de decisiones sobre el nivel de satisfacción de

la comunidad universitaria de Uniandes en base a las características y estándares de

calidad de las instituciones de educación superior del Ecuador”

Por otro lado se pudo consultar en algunos sitios Web como por ejemplo el de la

Escuela Superior Politécnica del Litoral cuya Tesis titulada “EL IMPACTO DE LA

OMISIÓN DE MÉTRICAS DE CALIDAD EN EL DESARROLLO DE

SOFTWARE". Por la Ing. Irma Guadalupe Luna.

Con toda esta información recopilada se concluye que un software se constituye en

una herramienta importante de ayuda en el proceso de generación, manipulación y

control de la información ya sea esta en una Institución Pública o Empresa privada, y

que esta debe ser procesada en ámbitos de calidad para ello se hace necesario

disponer de las Métricas respectiva durante el desarrollo del Software.

Planteamiento del problema.-

El Aseguramiento de la Calidad del Software es un área que suele ser desatendida

dentro del desarrollo de software; la presión en los tiempos de entrega o la falta de

conocimiento son las principales razones por las que las casas constructoras de

software le restan importancia a este punto tan por demás crítico.

Durante los primeros años de la era de la computadora, el software se contemplaba

como un añadido. Desde entonces el campo se ha desarrollado significativamente. La

programación de computadoras era un “arte de andar por casa” para el que existían

pocos métodos sistemáticos. El desarrollo del software se realizaba virtualmente sin

ninguna planificación, hasta que los planes comenzaron a descalabrarse y los costos a

2

correr. Los programadores trataban de hacer las cosas bien, y con un esfuerzo

heroico, a menudo salían con éxito. Los problemas a ser resueltos eran

principalmente de una naturaleza técnica, el énfasis estaba en expresar algoritmos

conocidos eficazmente en algún lenguaje de programación.

En estos primeros años lo normal era que el hardware fuera de propósito general. Por

otra parte, el software se diseña a medida para cada aplicación y tenía una

distribución relativamente pequeña.

La segunda era en la evolución de los sistemas de computadora se extienden desde la

mitad de la década de los sesenta hasta finales de los setenta. La multiprogramación

y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre -

máquina. Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y

nuevos niveles de sofisticación del hardware y del software. Los sistemas de tiempo

real podían recoger, analizar y transformar datos de múltiples fuentes, controlando

así los procesos y produciendo salidas en milisegundos en lugar de en minutos. Los

avances en los dispositivos de almacenamiento en línea condujeron a la primera

generación de sistemas de gestión de bases de datos.

La segunda era se caracterizó también por el establecimiento del software ya se

desarrollaba para tener una amplia distribución en un mercado multidisciplinario.

Los programas se distribuían para computadoras grandes y para minicomputadoras, a

cientos e incluso a miles de usuarios. Los patronos de la industria, del gobierno y de

la universidad se aprestaban a “desarrollar el mejor paquete de software” y ganar así

mucho dinero.

Conforme crecía el número de sistemas informáticos, comenzaron a extenderse las

bibliotecas de software de computadora. Las empresas desarrollaban proyectos en los

que se producían programas de decenas de miles de sentencias fuente. Los productos

de software comprados al exterior incorporaban cientos de miles de nuevas

sentencias. Una nube negra apareció en el horizonte. Todos esos programas, todas

esas sentencias fuente tenían que ser corregidos cuando se detectaban fallos,

modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos

dispositivos hardware que se hubieran adquirido. Estas actividades se llamaron

colectivamente “mantenimiento del software”.

3

La tercera era en la evolución de los sistemas de computadora comenzó a mediados

de los años setenta y continuó más allá de una década. El sistema distribuido,

múltiples computadoras, cada una ejecutando funciones concurrentemente y

comunicándose con alguna otra, incrementó notablemente la complejidad de los

sistemas informáticos. Las redes de área local y de área global, las comunicaciones

digitales de alto ancho de banda y creciente demanda de acceso “instantáneo” a los

datos, supusieron una fuerte presión sobre los desarrolladores del software. Aún más,

los sistemas y el software que lo permitían, continuaron residiendo dentro de la

industria y de la academia. El uso personal era extraño.

La conclusión de la tercera era se caracterizó por la llegada y amplio uso de los

microprocesadores. El microprocesador ha producido un extenso grupo de productos

inteligentes, desde automóviles hasta hornos microondas, desde robots industriales a

equipos de diagnóstico de suero sanguíneo, pero ninguno ha sido más importante que

la computadora personal. En menos de una década, las computadoras llegarán a ser

fácilmente accesibles al público.

La cuarta era de la evolución de sistemas informáticos se aleja de las computadoras

individuales y de los programas de computadoras, dirigiéndose al impacto colectivo

de las computadoras y del software. Potentes máquinas personales controladas por

sistemas operativos sofisticados, en redes globales y locales, acompañadas por

aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas

informáticas están cambiando de entornos centralizados de grandes computadoras a

entornos descentralizados cliente/servidor. Las redes de información en todo el

mundo proporcionan una infraestructura que iguala a expertos y políticos en pensar

sobre una “superautopista de información” y una “conexión del ciberespacio”. De

hecho Internet se puede observar como un “software” al que pueden acceder usuarios

individuales.

La industria del software ya es la cuna de la economía del mundo. Las decisiones

tomadas por gigantes de la industria tales como Microsoft arriesgan billones de

dólares. A medida que la cuarta generación progresa, han comenzado a surgir nuevas

tecnologías. Las tecnologías orientadas a objetos están desplazando rápidamente los

enfoques de desarrollo de software más convencionales en muchas áreas de

aplicaciones. Aunque las predicciones de las computadoras de “quinta generación””

4

continúan eludiéndonos, “las técnicas de cuarta generación” para el desarrollo del

software están cambiando en forma en que la comunidad del software construye

programas informáticos. Los sistemas expertos y el software de inteligencia artificial

han salido del laboratorio para entrar en aplicaciones prácticas de una gran variedad

de problemas del mundo real.

El software de redes neuronales artificiales junto con la aplicación de lógica difusa

ha abierto posibilidades excitantes para el reconocimiento de patrones y habilidades

de procesamiento de información de carácter humano. La programación de realidad

virtual y los sistemas multimedia ofrecen formas radicalmente diferentes de

comunicar información al usuario final. “Los algoritmos genéticos” ofrecen el

potencial para el software que reside dentro de las computadoras biológicas

masivamente en paralelo. Sin embargo, un conjunto de problemas relacionados con

el software ha persistido a través de la evolución de los sistemas basados en

computadora, y estos problemas continúan aumentado.

En la ciudad de Ambato a principios del año 2011 surge la empresa “J-M Software

Developers®” orientada a dar servicios de desarrollo de software de tipo comercial

orientados tanto a tipo aplicaciones Windows como a Web. Relacionada con el

desarrollo y aplicación de nuevos conocimientos profesionales adquiridos

universitariamente y en la práctica de conocimientos adquiridos bajo soporte de mi

persona como propietario y como pilar fundamental el apoyo incondicional de mis

maestros. En todo este tiempo se han logrado conseguir el desarrollo de algunos

sistemas y portales tanto comerciales como prácticos, pero luego de entregarlos y

hacerlos una evaluación con otros técnicos informáticos se ha podido recoger las

siguientes observaciones:

• Al software le falta generalmente calidad en sus interfaces y en las

combinaciones de colores.

• No se han realizado pruebas adecuadas dentro de las normativas de la

ingeniería del software.

• Varias de las aplicaciones web no cumplen con las normas internacionales de

accesibilidad a la web (herramientas de medición TAW – ERA).

5

Por otro lado la empresa con el deseo de mantenerse y seguir generando trabajo, ha

tratado de buscar entidades en con las cuales se pueda hacer convenios para que “J-

M Software Developer®” se convierta en una desarrolladora de software para estas

Instituciones. La principal dificultad, la falta de confianza ante otras empresas,

además en una ligera evaluación realizada por estas empresas es de que los portales

elaborados no cumplen con ciertos parámetros de accesibilidad, es decir no se ha

considerado el acceso de personas con problemas de oído, visión, movilidad,

dificultades de lectura o comprensión cognitiva, imposibilidad de utilización del

teclado o el ratón, etc.

Esto significa que la empresa está ante un problema relacionado con la calidad de su

trabajo, ya que está desarrollando un software poco competitivo en el mercado y lo

más grave aún es que la empresa no tiene un conjunto de parámetros establecidos

que permitan evaluar dicha calidad del software desarrollado

Formulación del problema

¿Cómo mejorar la calidad del software desarrollado para que sea más competitivo en

el mercado nacional?

Objeto de investigación y campo de acción

Objeto de Estudio: Ingeniería en Sistemas

Campo de Acción: El campo de acción está definido directamente en la Ingeniería

del Software y específicamente en la evaluación de su calidad.

Delimitación: El trabajo investigativo se llevará a cabo en la empresa J-M Software

Developer® de la Ciudad de Ambato, en la Calle Eloy Alfaro y García Moreno que

viene elaborando desde el año 2011.

Identificación de línea de investigación

El trabajo se enmarca en la línea denominada: “Desarrollo de software y

programación de Sistemas”

6

Objetivo General

Elaborar un conjunto de estrategias que se constituyan en una métrica fácil y

eficiente para evaluar la calidad de un software desarrollado por la empresa “J-M

Software Developer®”

Objetivos Específicos

• Analizar fuentes bibliográficas referentes Ingeniería del software, metodologías

de desarrollo, pruebas, Normas ISO referente a la calidad y procesos de

mejoramiento continuo aplicados al desarrollo de software.

• Diagnosticar la aplicación de estándares de calidad utilizados durante el

desarrollo de software actualmente en la empresa.

• Aplicar las métricas propuestas en algunos casos de estudio.

Idea a Defender y variables

Idea a defender: “Con la aplicación de un conjunto de métricas de calidad diseñadas

en esta tesis, se logrará el desarrollo de un software más competitivo en el mercado

por parte de la empresa “J-M Software Developer®”

Variable independiente: Métricas de calidad

Variable Dependiente: Desarrollo de software competitivo

Justificación del tema.

Del planteamiento del problema se deduce que este incide directamente en la calidad

del software, dicha calidad se hace referencia a diversos aspectos del desarrollo como

por ejemplo apariencia, seguridad, utilidad y celeridad de procesos.

La aplicación de las métricas diseñadas en este trabajo investigativo, generan

automáticamente algunas mejoras en el desarrollo de software, así por ejemplo:

7

• La apariencia del mismo mejora considerablemente en base a un mejor diseño y

sobre todo a una adecuada combinación de colores.

• La seguridad de acceso se eleva, esto quiere decir que se tienen mayores

controles en cuanto a validación de datos.

• La celeridad en los procesos es mayor en base al diseño dinámico.

• El software se hace más competitivo y de acuerdo a estándares internacionales.

Por todo lo mencionado anteriormente se justifica plenamente la realización del

presente trabajo investigativo como tesis de grado para la obtención del título de

ingeniero

Metodología

El presente trabajo utiliza la siguiente metodología investigativa

Cualitativa: Determina las características o descripciones de la realidad del

problema planteado, en este caso la poca competitividad que posee el software

desarrollado por la empresa.

Cuantitativa: Permitirá determinar en base a estadísticas las características del

fenómeno y sus relaciones, para proporcionar la manera de establecer, formular,

fortalecer y revisar los procesos de elaboración de software con estándares de calidad

en cada uno de ellos

Los tipos de investigación que se utilizaron son:

Descriptiva mediante este tipo de investigación, que utiliza el método de análisis, se

logra caracterizar el objeto de estudio de una situación concreta, explicativa requiere

la combinación de los métodos analíticos o sintéticos con el deductivo y el inductivo,

se trata de responder o dar cuenta de los porqués del objeto que se investiga. Tiene

que ver esencialmente a los niveles de calidad que se aplican en cada fase de

desarrollo

Bibliográfica que nos ayuda a recabar información para la investigación, para ello se

consulta en libros, documentos de archivos, folletos y páginas web, lo cual es de gran

8

importancia para la elaboración del marco teórico relacionado con Normas ISO,

estándares de calidad, métricas de calidad, arquitectura de software e ingeniería de

software,

De campo se realizará en el lugar establecido donde se sitúa el problema, en este

caso se llevó a efecto en la empresa J-M Software Developer®

Entre las técnicas para recopilar información tenemos:

La encuesta, es la técnica que permite recopilar información mediante un

cuestionario que es elaborado previamente por el investigador, esta encuesta está

orientada a los desarrolladores de software y a los clientes

La entrevista, es un acto de comunicación oral que se establece entre dos o más

personas, en este caso se la aplico al gerente.

Los instrumentos que se emplearan son la guía de entrevistas que permitirá recopilar

información en forma verbal a través de preguntas previamente elaboradas al

gerente, los cuestionarios son unas series de preguntas que realiza el investigador

para determinar las ventajas y desventajas que presenta el fenómeno investigado, en

este caso se los utilizó para encuestar a clientes y desarrolladores

Resumen de la estructura de la tesis

El trabajo investigativo se encuentra estructurada en cuatro secciones bien

diferenciadas que son:

La introducción, la cual recopila aspectos importantes de la investigación como los

antecedentes del presente trabajo, el planteamiento del problema enfocado a las

dificultades para elaborar software de calidad, los objetivos relacionados a elevar la

calidad del software y más.

El Capítulo uno que concierne al marco teórico aborda toda la información

relacionada con la ingeniería del software, el desarrollo del mismo y las normativas

generales de la calidad dada por las normas ISO.

9

En el segundo capítulo se puede encontrar los resultados de la investigación de

campo, la cual corresponde a las encuestas a las personas involucradas con el

desarrollo de software, en este caso programadores y clientes

En el tercer capítulo se presenta el desarrollo de la propuesta donde se estructura el

diseño de algunas normativas y se procede a la aplicación de las mismas para evaluar

un producto sencillo.

Por último se muestran las conclusiones del trabajo investigativo y las

recomendaciones del mismo para que la propuesta de solución cumplan formalmente

con el propósito para el cual fue desarrollado.

Elementos de novedad, aporte teórico y significación práctica, en dependencia

del alcance de la tesis.

El trabajo Investigativo que se ha desarrollado y que se denomina “Métricas de

Calidad y el Desarrollo de Software Competitivo” permitirá al proponente generar

un aporte teórico importante, este aporte tiene esencialmente que ver con aspectos

relacionados a la calidad en el desarrollo de software, el presente trabajo

investigativo es quizás uno de los pocos en su área y recopila datos relacionados a

estándares internacionales aplicados para el desarrollo de software, esto hace que el

aporte teórico sea interesante por ende novedoso.

El tema en sí constituye una novedad ya que se sale de los parámetros normales que

se han venido dando en trabajo de investigación previos a la obtención de un título de

ingeniero.

En cuanto a su significación práctica se puede señalar que una vez diseñadas las

métricas se las aplica en el desarrollo de un prototipo a través del cual se podrá

evidenciar la calidad desigual de los programas desarrollados como ejemplos.

10

CAPITULO I

MARCO TEÓRICO

1.1 Evolución del software

Haciendo un poco de historia se puede señalar que durante los primeros años de la

era de la computadora, el software se contemplaba como un añadido. Desde entonces

el campo se ha desarrollado tremendamente. La programación de computadoras era

un “arte de andar por casa” para el que existían pocos métodos sistemáticos. El

desarrollo del software se realizaba virtualmente sin ninguna planificación, hasta que

los planes comenzaron a descalabrarse y los costos a correr. Los programadores

trataban de hacer las cosas bien, y con un esfuerzo heroico, a menudo salían con

éxito. Los problemas a ser resueltos eran principalmente de una naturaleza técnica, el

énfasis estaba en expresar algoritmos conocidos eficazmente en algún lenguaje de

programación. (PRESSMAN Roger (2006))

En estos primeros años lo normal era que el hardware fuera de propósito general. Por

otra parte, el software se diseña a medida para cada aplicación y tenía una

distribución relativamente pequeña.

Avanzando cronológicamente se puede señalar que la segunda era en la evolución de

los sistemas de computadora se extienden desde la mitad de la década de los sesenta

hasta finales de los setenta. La multiprogramación y los sistemas multiusuario

introdujeron nuevos conceptos de interacción hombre - máquina. Las técnicas

interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de

sofisticación del hardware y del software. Los sistemas de tiempo real podían

recoger, analizar y transformar datos de múltiples fuentes, controlando así los

procesos y produciendo salidas en milisegundos en lugar de en minutos. Los avances

en los dispositivos de almacenamiento en línea condujeron a la primera generación

de sistemas de gestión de bases de datos. (SOMMERVILLE Ian (2004))

Esta segunda era se caracterizó también por el establecimiento del software ya se

desarrollaba para tener una amplia distribución en un mercado multidisciplinario.

Los programas se distribuían para computadoras grandes y para minicomputadoras, a

cientos e incluso a miles de usuarios. Los patronos de la industria, del gobierno y de

11

la universidad se aprestaban a “desarrollar el mejor paquete de software” y ganar así

mucho dinero.

Conforme crecía el número de sistemas informáticos, comenzaron a extenderse las

bibliotecas de software de computadora. Las casas desarrollaban proyectos en los

que se producían programas de decenas de miles de sentencias fuente. Los productos

de software comprados al exterior incorporaban cientos de miles de nuevas

sentencias. Una nube negra apareció en el horizonte. Todos esos programas, todas

esas sentencias fuente tenían que ser corregidos cuando se detectaban fallos,

modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos

dispositivos hardware que se hubieran adquirido. Estas actividades se llamaron

colectivamente “mantenimiento del software”. (SANCHEZ Salvador (2009))

La tercera era en la evolución de los sistemas de computadora comenzó a mediados

de los años setenta y continuó más allá de una década. El sistema distribuido,

múltiples computadoras, cada una ejecutando funciones concurrentemente y

comunicándose con alguna otra, incrementó notablemente la complejidad de los

sistemas informáticos. Las redes de área local y de área global, las comunicaciones

digitales de alto ancho de banda y creciente demanda de acceso “instantáneo” a los

datos, supusieron una fuente presión sobre los desarrolladores del software. Aún

más, los sistemas y el software que lo permitían, continuaron residiendo dentro de la

industria y de la academia. El uso personal era extraño.

La conclusión de la tercera era se caracterizó por la llegada y amplio uso de los

microprocesadores. El microprocesador ha producido un extenso grupo de productos

inteligentes, desde automóviles hasta hornos microondas, desde robots industriales a

equipos de diagnóstico de suero sanguíneo, pero ninguno ha sido más importante que

la computadora personal. En menos de una década, las computadoras llegarán a ser

fácilmente accesibles al público. (PRESSMAN Roger (2006))

La cuarta era de la evolución de sistemas informáticos se aleja de las computadoras

individuales y de los programas de computadoras, dirigiéndose al impacto colectivo

de las computadoras y del software. Potentes máquinas personales controladas por

sistemas operativos sofisticados, en redes globales y locales, acompañadas por

aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas

12

informáticas están cambiando de entornos centralizados de grandes computadoras a

entornos descentralizados cliente/servidor. Las redes de información en todo el

mundo proporcionan una infraestructura que iguala a expertos y políticos en pensar

sobre una “superautopista de información” y una “conexión del ciberespacio”. De

hecho Internet se puede observar como un “software” al que pueden acceder usuarios

individuales.

1.2 Conceptos generales sobre la Ingeniería del software.

La ingeniería del software se trata desde la perspectiva de grupos de ingenieros y

diseñadores fundamentalmente, pero también otros roles profesionales como gestores

del proceso de desarrollo, analista, etc y no desde la perspectiva de un programador

aislado.

La ingeniería del software es una disciplina de la ingeniería cuya meta es el

desarrollo costeable de sistemas de software. Éste es abstracto e intangible. No está

restringido por materiales, o gobernado por leyes físicas o por procesos de

manufactura. De alguna forma, esto simplifica la ingeniería del software ya que no

existen limitaciones físicas del potencial del software. Sin embargo, esta falta de

restricciones naturales significa que el software puede llegar a ser extremadamente

complejo y muy difícil de entender.

La definición más utilizada de Ingeniería de Software es la aplicación de un enfoque

sistemático, disciplinado y cuantificable al desarrollo, la operación y el

mantenimiento del software. (SÁNCHEZ Salvador (2009))

Según esta definición el ingeniero de software es un desarrollador en sentido amplio

que desempeña un rol como profesional en la producción de software

Sin embargo la ingeniería tal y toco hoy la entendemos siempre resulta en algún

artefacto concreto. Estos artefactos pueden ser utilidades finales o elementos para ser

reutilizables en otros procesos de ingeniería. En cambio a la ingeniería del software

su resultado útil son las aplicaciones de las cuales los usuarios se sirven para hacer

más eficaz, controlado o eficiente su trabajo

13

La estructuración de las diferentes ingenierías como disciplinas profesionales

reconocidas donde se enuncian los tres elementos que constituyen una disciplina

son:

• Aspecto colegial: El conocimiento y competencia del profesional debe haber

sido válido por la comunidad de sus pares

• Aspecto cognitivo: Ese conocimiento y competencia consensualmente valido

debe descansar en criterios racionales y científicos

• Aspecto moral: El juicio y los consejos profesionales deben orientarse a un

conjunto de valores sustantivos

Las diferentes ramas o disciplinas ingenieriles difieren en el objeto de la producción,

pero todas ellas tiene en común tres aspectos específicos:

• La ciencia de la ingeniería que se ocupa de los principios y mecanismos

subyacentes de la disciplina

• Procesos de diseño, que generalmente incluyen una fase de

conceptualización, y una fase de diseño detallado

• Aspectos de gestión y organización, pues la tecnología que se produce

implica tanto a las personas como a las organizaciones. Además, las propias

personas que crean tecnología no suelen trabajar aisladas, sino en equipo y

organizaciones

En el caso de la ingeniería del Software, las actividades de diseño serian asimilables

a lo que normalmente conocemos como desarrollo. Es importante distinguir

claramente entre ciencia de la computación e ingeniería del Software, utilizando el

conocimiento que es el objeto de la ciencia de la computación, Hay que separar los

conocimientos de la ingeniería del Software en sí misma y la práctica de la

ingeniería: (SOMMERVILLE Ian (2004))

• Las ciencias que se aplican en la ingeniería del Software son la ciencia de la

computación y otras ciencias que son de utilidad para aspectos determinados,

como las relativas a la organización, la economía, la psicología y por

supuesto las matemáticas en general. Para dominios muy concretos también

14

se necesitan conocimientos específicos de ciertas ciencias. Así, en la

ingeniería del Software aeroespacial se requieren conocimientos de física,

mientras que para el desarrollo del software para biotecnología, serán

necesarios ciertos conocimientos de biología

• La ingeniería del software como ciencia es la aplicación del método científico

a la teorización y creación de conocimientos sobre la propia ingeniería del

Software. Está dedicada al estudio de sus actividades y centrada en generar

teoría, modelos explicativos o enunciados descriptivos sobre la práctica de la

ingeniería.

• La práctica de la ingeniería que está orientada a prescribir como deben

realizarse las actividades propias de la disciplina. Es un aspecto

complementario con la ciencia de la ingeniería, pues la ciencia necesita de la

observación de la práctica, y l practica a su vez se perfecciona de acuerdo con

el conocimiento generado por la ciencia

La ingeniería del software es una disciplina de la ingeniería que comprende todos

los aspectos de la producción de software desde las etapas iníciales de la

especificación del sistema, hasta el mantenimiento de éste después de que se

utiliza. En esta definición, existen dos frases clave:

• Disciplina de la ingeniería. Los ingenieros hacen que las cosas funcionen.

Aplican teorías, métodos y herramientas donde sean convenientes, pero las

utilizan de forma selectiva y siempre tratando de descubrir soluciones a los

problemas, aun cuando no existan teorías y métodos aplicables para

resolverlos. Los ingenieros también saben que deben trabajar con

restricciones financieras y organizacionales, por lo que buscan soluciones

tomando en cuenta estas restricciones.

• Todos los aspectos de producción de software. La ingeniería del software no

sólo comprende los procesos técnicos del desarrollo de software, sino

también con actividades tales como la gestión de proyectos de software y el

desarrollo de herramientas, métodos y teorías de apoyo a la producción de

software.

15

1.3 Tipos de Software

Software de Aplicación: aquí se incluyen todos aquellos programas que permiten al

usuario realizar una o varias tareas específicas. Aquí se encuentran aquellos

programas que los individuos usan de manera cotidiana como: procesadores de texto,

hojas de cálculo, editores, telecomunicaciones, software de cálculo numérico y

simbólico, videojuegos, entre otros.

Software de Programación: son aquellas herramientas que un programador utiliza

para poder desarrollar programas informáticos. Para esto, el programador se vale de

distintos lenguajes de programación. Como ejemplo se pueden tomar compiladores,

programas de diseño asistido por computador, paquetes integrados, editores de texto,

enlazadores, depuradores, intérpretes, entre otros.

Software de Sistema: es aquel que permite a los usuarios interactuar con el sistema

operativo así como también controlarlo. Este sistema está compuesto por una serie de

programas que tienen como objetivo administrar los recursos del hardware y, al

mismo tiempo, le otorgan al usuario una interfaz. El sistema operativo permite

facilitar la utilización del ordenador a sus usuarios ya que es el que le da la

posibilidad de asignar y administrar los recursos del sistema, como ejemplo de esta

clase de software se puede mencionar a Windows, Linux y Mac OS X, entre otros.

Además de los sistemas operativos, dentro del software de sistema se ubican las

herramientas de diagnóstico, los servidores, las utilidades, los controladores de

dispositivos y las herramientas de corrección y optimización, etcétera.

1.4 Etapas en el desarrollo del software

Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se realiza,

y, según el modelo de proceso adoptado, puede casi terminar para pasar a la próxima

etapa (caso de Modelo Cascada Realimentado) o puede hacerse parcialmente para

luego retomarla (caso Modelo Iterativo Incremental u otros de carácter evolutivo).

En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y

especifican las características funcionales y no funcionales que deberá cumplir el

futuro programa o sistema a desarrollar. (PRESSMAN Roger (2006))

http://es.wikipedia.org/wiki/Editor_de_texto

16

Las bondades de las características, tanto del sistema o programa a desarrollar, como

de su entorno, parámetros no funcionales y arquitectura dependen enormemente de lo

bien lograda que esté esta etapa. Esta es, probablemente, la de mayor importancia y

una de las fases más difíciles de lograr certeramente, pues no es automatizable, no es

muy técnica y depende en gran medida de la habilidad y experiencia del analista que

la realice.

Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy

subjetivos y es difícil de modelar con certeza o aplicar una técnica que sea «la más

cercana a la adecuada» (de hecho no existe «la estrictamente adecuada»). Si bien se

han ideado varias metodologías, incluso software de apoyo, para captura, e licitación

y registro de requisitos, no existe una forma infalible o absolutamente confiable, y

deben aplicarse conjuntamente buenos criterios y mucho sentido común por parte del

o los analistas encargados de la tarea; es fundamental también lograr una fluida y

adecuada comunicación y comprensión con el usuario final o cliente del sistema.

El artefacto más importante resultado de la culminación de esta etapa es lo que se

conoce como especificación de requisitos software o simplemente documento ERS.

Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental;

lo común es que el cliente tenga un objetivo general o problema que resolver, no

conoce en absoluto el área (informática), ni su jerga, ni siquiera sabe con precisión

qué debería hacer el producto software (qué y cuantas funciones) ni, mucho menos,

cómo debe operar. En otros casos menos frecuentes, el cliente «piensa» que sabe

precisamente lo que el software tiene que hacer, y generalmente acierta muy

parcialmente, pero su empecinamiento entorpece la tarea de licitación. El analista

debe tener la capacidad para lidiar con este tipo de problemas, que incluyen

relaciones humanas; tiene que saber ponerse al nivel del usuario para permitir una

adecuada comunicación y comprensión.

Escasas son las situaciones en que el cliente sabe con certeza e incluso con

completitud lo que requiere de su futuro sistema, este es el caso más sencillo para el

analista.

17

Las tareas relativas a captura, e licitación, modelado y registro de requisitos, además

de ser sumamente importante, puede llegar a ser dificultosa de lograr acertadamente

y llevar bastante tiempo relativo al proceso total del desarrollo; al proceso y

metodologías para llevar a cabo este conjunto de actividades normalmente se las

asume parte propia de la Ingeniería de Software, pero dada la antedicha complejidad,

actualmente se habla de una Ingeniería de requisitos , aunque ella aún no existe

formalmente. (SÁNCHEZ Salvador (2009))

Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente

abocados a idear modelos, técnicas y procesos para intentar lograr la correcta

captura, análisis y registro de requisitos. Estos grupos son los que normalmente

hablan de la Ingeniería de requisitos; es decir se plantea ésta como un área o

disciplina pero no como una carrera universitaria en sí misma.

Algunos requisitos no necesitan la presencia del cliente, para ser capturados o

analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar

unilateralmente decisiones que considera adecuadas. Por citar ejemplos probables:

Algunos requisitos sobre la arquitectura del sistema, requisitos no funcionales tales

como los relativos al rendimiento, nivel de soporte a errores operativos, plataformas

de desarrollo, relaciones internas o ligas entre la información a almacenar en caso de

bases o bancos de datos, etc. Algunos funcionales tales como opciones secundarias o

de soporte necesarias para una mejor o más sencilla operatividad; etc.

La obtención de especificaciones a partir del cliente (u otros actores intervinientes)

es un proceso humano muy interactivo e iterativo; normalmente a medida que se

captura la información, se la analiza y realimenta con el cliente, refinándola,

puliéndola y corrigiendo si es necesario; cualquiera sea el método de ERS utilizado.

EL analista siempre debe llegar a conocer la temática y el problema que resolver,

dominarlo, hasta cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo

abarque. Por ello el analista debe tener alta capacidad para comprender problemas de

muy diversas áreas o disciplinas de trabajo (que no son específicamente suyas); así

por ejemplo, si el sistema a desarrollar será para gestionar información de una

aseguradora y sus sucursales remotas, el analista se debe compenetrar en cómo ella

18

trabaja y maneja su información, desde niveles muy bajos e incluso llegando hasta

los gerenciales.

Dada a gran diversidad de campos a cubrir, los analistas suelen ser asistidos por

especialistas, es decir gente que conoce profundamente el área para la cual se

desarrollará el software; evidentemente una única persona (el analista) no puede

abarcar tan vasta cantidad de áreas del conocimiento. En empresas grandes de

desarrollo de productos software, es común tener analistas especializados en ciertas

áreas de trabajo. (PRESSMAN Roger (2006))

1.5 Estándares de calidad para análisis, diseño, construcción y pruebas de

software

La calidad es un parámetro difícil de definir y por lo tanto complicado de lograr.

Características del software:

• La complejidad es difícil de estimar

• La calidad es difícil de medir

• El proceso de desarrollo es muy dependiente de factores humanos

o Difícil de controlar

o Está expuesto a altos riesgos

• El mantenimiento es costoso

Se puede definir como un plan de calidad del desarrollo de un software al:

“Conjunto planificado y sistemático de acciones necesarias para proveer la confianza

de un Producto que cumpla con los requerimientos técnicos establecidos”

1.6 El I.E.E.E.

Es la mayor y más importante organización profesional del mundo. Reúne a más de

375.000 miembros en más de 160 países, entre estudiantes, profesionales,

catedráticos y científicos en áreas tales como ingeniería eléctrica y electrónica e

ingeniería informática. Está dividida administrativamente en 10 regiones, integrada

por 300 secciones.

19

Es un desarrollador líder en normas de la industria, la IEEE-SA cuenta con

relaciones estratégicas con el IEC, ISO, y la UIT, cumple con todos los requisitos

establecidos por la ordenanza de la organización mundial del comercio, tiene una

cartera de 1300 proyectos en el marco de las normas y el desarrollo, la IEEE-SA es la

principal fuente para la organización, en una amplia gama de tecnologías, se

desarrolla a nivel mundial las normas en una gran gama de industrias incluyendo,

biomedicina y salud, el poder y la energía, tecnología de la información, la

telecomunicaciones, el trasporte y la nanotecnología y muchas más, los expertos

técnicos del mundo participan en el desarrollo de la IEEE normas.

1.6.1 Estándar de ingeniería de Software

Se define como un estándar a la Regla o base de comparación que se utiliza para

medir algún aspecto del software

¿Por qué utilizar Estándares?

• Son indispensables cuando muchas personas, productos y herramientas deben

coexistir.

o Promueven el buen uso de métodos y herramientas.

o Permite la comunicación entre los desarrolladores.

• Facilitan el mantenimiento del software.

• Facilitan la capacitación del personal.

• Proveen una base para evaluar los diferentes productos de software

20

1.6.2 IEEE práctica recomendada para requisitos de software especificaciones

(IEEE std 830-1998)1

Todas estas actividades permiten definir el proceso de software de una organización.

A continuación se describirá brevemente cada uno de los pasos que hay que aplicar

en este estándar estudiado.

Introducción.- En esta sección se proporcionará una introducción a todo el

documento de Especificación de Requisitos Software. Consta de varias sub

secciones, las cuales son propósito, ámbito del sistema, definiciones, referencias y

visión general del documento.

Propósito.- Se definirá el propósito del documento ERS y se especificará a quién va

dirigido el documento.

1IEEESTANDARDSASSOCIATION, “830-1998 - IEEE Recommended practice for Software Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html

• Introducción

o Propósito o Alcance o Definiciones, Siglas y

Abreviaturas o Referencias o Visión general del producto

• Descripción General

o Perspectiva del Producto o Funciones del Producto o Características de los usuarios o Restricciones o Suposiciones y Dependencias

• Requisitos Específicos

o Requisitos Funcionales o Requisitos de interfaces

Externas o Requisitos de Rendimiento o Atributos

http://standards.ieee.org/findstds/standard/830-1998.html

21

Ámbito del sistema.- En esta sub sección se pondrá nombre al futuro sistema, se

explicará lo que el sistema hará y lo que no hará, se describirán los beneficios,

objetivos y metas que se espera alcanzar con el futuro sistema y se mantendrán

referencias a los documentos de nivel superior que puedan existir.

Definiciones, acrónimos y abreviaturas.- Se definirán aquí todos los términos,

acrónimos y abreviaturas utilizadas en el desarrollo de la ERS.

Referencias. Se presentará una lista completa de todos los documentos referenciados

en la ERS.

1.6.2.1 Visión general del producto.

Esta sub sección describirá brevemente los contenidos y la organización del resto de

la ERS.

Descripción general.- En esta sección se describen todos aquellos factores que

afectan al producto y a sus requisitos. En esta sección no se describen los requisitos,

sino su contexto. Los detalles de los requisitos de describen en la sección 3,

detallándolos y haciendo más fácil su comprensión. Normalmente podemos

encontrar las siguientes sub secciones: perspectiva del producto, funciones del

producto, características de los usuarios, restricciones, suposiciones y futuros

requisitos.

Perspectiva del producto.- Esta sección describe el producto en caso de ser

independiente o si es dependiente de otro sistema más grande entonces debe

especificar los requisitos y las interfaces entre ese sistema y el software, en este caso

deben describir como operará el software. En las interfaces de sistema, usuario,

hardware, software, comunicaciones, memoria, funcionamientos y requisitos de

adaptación de sitio.

Interfaces de sistema.- Esta sección detalla cada interfaz e identifica la

funcionalidad del software para sacar los requisitos del sistema y las interfaces.

22

Interfaces de usuario.- Esta sección describe las características de la configuración

como son formatos de pantalla, reportes, menús, páginas, opciones de mensajes de

error largos o cortos y todos estos requisitos deben ser verificados, los atributos del

sistema se especificarán con el título facilidad de uso.

Interfaces de hardware.- Esta sección específica las características lógicas y los

componentes de hardware del sistema.

Interfaces de software.- Esta sección específica el uso de otros productos de

software e interfaces con otros sistemas. Estos deben identificarse con: nombre,

código, número de la especificación, número de versión y fuente.

Interfaces de comunicaciones.- Esta sección específica varias interfaces de

comunicaciones como los protocolos de las redes locales, etc.

Memoria.- Esta sección específica cualquier característica aplicable y límites en la

memoria primaria y secundaria.

Funcionamientos.- Esta sección específica los funcionamientos normales y

especiales requeridos por el usuario.

Requisitos de adaptación de sitio

Esta sección específica el sitio o los rasgos que se deben relacionar a características

que deben modificarse para adaptar el software a una instalación particular.

Funciones del producto. Esta sección proporciona una síntesis de las principales

funciones que realiza el software.

Características del usuario. Esta sección describe las características generales de

los usuarios del producto que incluye nivel educativo, experiencia y especialización

técnica.

23

1.6.2.2. Restricciones

Esta sección describe en forma general cualquier otro punto que limite las opciones

de los diseñadores. Estos incluyen: políticas reguladoras, limitaciones de hardware,

interfaces a otras aplicaciones, funciones de auditorías, funciones de control,

requisitos de lenguaje, requisitos de fiabilidad, credibilidad de la aplicación y

seguridad.

Suposiciones y dependencias

Esta sección detalla cada uno de los factores que afectan a los requisitos declarados

en el ERS.

Requisitos específicos. Esta sección contiene todos los requisitos de software

apropiadamente detallados para permitirles a los creadores diseñar el sistema para

satisfacer los requisitos, esta sección es la más grande e importante del Ers.

Requisitos funcionales. Esta sección define las funciones que tendrá el software,

aceptando y procesando las entradas y generando las salidas.

Requisitos de interfaces externas. Ésta sección detalla todas las entradas y salidas

del sistema software. Debe completar la descripción de la interfaz y no debe repetirse

la información.

Requisitos de rendimiento. Pretende definir una serie de parámetros mensurables

del sistema que imponen restricciones sobre el mismo. Generalmente están asociados

a tiempos de respuesta, tiempos de espera y duración de tareas batch. Estos

requerimientos son muy importantes ya que la no satisfacción de los mismos implica

un fracaso del sistema, por lo que deben tener una prioridad alta.

1.6.2.3 Atributos

24

Seguridad. Esta sección específica los factores que protegen el software de accesos

provisionales, modificación, destrucción. Los requisitos específicos pueden tener:

• Utilizar técnicas criptográficas

• Mantener registros específicos o una serie de historia de datos

• Asignar ciertas funciones a módulos diferentes

• Restringir comunicaciones entre algunas áreas del programa

• Revisar la integridad de datos para variables críticas.

1.6.3 Estándares del producto fase desarrollo

IEEE práctica recomendada para las descripciones de diseño de software -

IEEE std 1016-19982

IEEE 1016 es un estándar para “descripción de un diseño de software”, entendiendo

por tal la representación que sirve para comunicar cómo está diseñado el sistema.

Especifica la información que una descripción de este tipo ha de contener y la

organización o esquema de presentación recomendada. Puede aplicarse a software de

cualquier tipo destinado a funcionar en un ordenador. Su aplicación no está

restringida por ninguna consideración relativa al tamaño, complejidad o carácter

crítico del software

• Consideraciones para producir un SDD

• Ciclo de vida de software • SDD dentro del ciclo de vida • Propósito de un SDD

• Contenido de información de la descripción de Diseño

• Introducción • Entidades de diseño • Atributos de entidades de diseño

• Organización de la descripción del Diseño

• Introducción • Visión de Diseño



25



Software del ciclo de vida.- El ciclo de vida de un sistema de software se define

normalmente como el período de tiempo que comienza cuando un producto de

software es la concepción y termina cuando el producto ya no está disponible para su

uso. El enfoque de ciclo de vida es una ingeniería eficaz herramienta de gestión y

proporciona un modelo para un contexto en el que para discutir la preparación y uso

de los SDD.

Sdd dentro del ciclo de vida. Para ambos nuevos sistemas de software y sistemas

existentes bajo mantenimiento, es importante asegurarse de que el diseño y

implementación que utiliza un sistema de software para satisfacer los requisitos de

conducción de dicho sistema. La documentación mínima necesaria para hacer esto se

define en IEEE Std 730-1998. El SDD es uno de estos productos requeridos. Se

registra el resultado de los procesos de diseño que se llevan a cabo durante la fase de

diseño.

Propósito de un sdd.- El SDD muestra cómo el sistema de software se estructura

para satisfacer los requisitos identificados en el software requisitos de la

especificación IEEE Std 830-1998. Es una traducción de los requisitos en una

descripción del software estructura, componentes de software, interfaces, y los datos

necesarios para la fase de implementación. En esencia, el SDD se convierte en un

plan detallado para la actividad de ejecución. En un SDD completa, cada requisito

debe ser trazable a una o más entidades de diseño.

1.6.4 Estándares del producto fase Mantenimiento

IEEE estándar para la documentación de software del usuario. IEEE std 1063-

20013



26

En esta norma van los requisitos mínimos para la estructura, el contenido de la

información y el formato de documentación para el usuario, que incluye tanto los

documentos impresos y electrónicos utilizados en el entorno de trabajo de los

usuarios de los sistemas que contengan software, se ofrecen en esta norma.


en este estándar estudiado

1.6.4.1 Estructura del documento del usuario del software.

Esta sección puede ser estructurada en un solo documento o una serie de documentos

impresos o electrónicos.

Estructura general del documento. Esta sección debe estructurar la documentación

en unidades con contenido único, como puede ser:

Estructura del Documento del Usuario del Software

• Estructura General del Documento Componentes Iniciales

Contenido de Información del Documento del Usuario del Software

• Contenido de Datos de Identificación • Información para Uso del documento • Concepto de Operación • Información para Uso General del Software • Información para Procedimientos y Tutoriales • Información sobre Terminología • Información sobre Fuentes de Información Relacio

nadas

Formato de Documentación de Usuario del Software

• Uso de Formato Impreso o Electrónico • Legibilidad • Formatos para Representar Elementos de Interface

s de Usuario • Formatos para Características del Document

o para Acceder a la Información • Formato para Características de navegación

27

• Un documento impreso es estructurado dentro de las unidades lógicas llamadas

capítulos, subdivididos dentro del tema, los cuales pueden ser divididos dentro de

subtemas e impresos en unidades físicas llamadas páginas.

• Un documento electrónico es estructurado dentro de las unidades lógicas

llamadas temas y presentados en unidades físicas llamadas paginas o pantallas.

Componentes iniciales. Esta sección debe empezar con datos de identificación y la

introducción, el primer capítulo o tema del documento es la introducción, describe el

alcance y el propósito del software.

1.6.4.2 Contenido de información del documento del usuario del software

Contenido de datos de identificación. Esta sección debe contener la siguiente

información:

• Título del Documento

• Versión y Fecha del Documento

• Versión del Producto Software

• Responsable del Documento

Información para uso del documento. Esta sección debe incluir información de

cómo manejar el documento y recomendar como consultar las secciones del

documento, si un documento está contenido de varios volúmenes puede tener una

guía separada del contenido. La documentación puede incluir la identificación y la

versión del documento y software.

Concepto de operación.- Esta sección debe explicar los antecedentes para el uso del

software, usando como un antecedente el método visual o verbal del proceso de

trabajo o en forma general lo que hará el software y el documento, este antecedente

debe ser explicado en términos familiares para el usuario.

Información para uso general del software.- Esta sección debe incluir la siguiente

información:

28

• Instalación y desinstalación del software

• Características de interconexión

• Acceso al software.

• Navegación y salida del software mediante el acceso al sistema.

• Operación de datos (editar, guardar, leer, imprimir, actualizar y borrar).

• Métodos de cancelación, interrumpiendo y reinicio de operación.

Información para procedimientos y tutoriales.- Esta sección debe incluir la

siguiente información:

• Visión general del propósito del procedimiento y explicar los conceptos

necesarios no incluido en otras partes.

• Identificar las actividades técnicas y administrativas que deben ser hechas

antes de empezar como pueden ser software adicional, identificación de

drivers, interconexiones o protocolos.

• Advertencias relevantes, prevenciones y notas que aplican al procedimiento

entero.

Información sobre terminología.- Esta sección debe incluir un glosario de términos

ordenados alfabéticamente, tanto de abreviaciones y siglas no familiares al usuario,

el glosario puede ser impreso o electrónico.

Información sobre fuentes de información relacionadas.- Esta sección puede

incluir lo siguiente:

• Especificación de requerimientos, especificación de diseño, estándares

aplicados, para el software y la documentación.

• Planes de prueba y procedimientos para el software y la documentación.

• La documentación del hardware y software.

La documentación debe indicar si la referencia contiene material informativo.

1.6.4.3 Formato de documentación del usuario del software

Esta sección incluye el formato del documento:

• Presentación del documento Impreso o electrónico

• Tipo y tamaño de fuente

29

• Color de la fuente y tamaño del papel

Uso de formatos impresos o electrónicos.- Esta sección debe presentar la siguiente

información, tanto impresa como electrónica:

• Información de Hardware y de software

• Información e instrucciones de instalación

• Instrucciones para utilizar el software.

• Instrucciones para el acceso al software

• Características del software diseñadas para permitir la impresión de

documentos electrónicos.

Legibilidad.- Esta sección describe como debe ser la documentación impresa o

electrónica del usuario:

• La documentación debe ser legible

• Usar papel de color o color de fondo de pantalla, la documentación en línea

debe permanecer legible si el usuario es capaz de agrandar, acortar o reformar

la pantalla o ventana.

Formatos para representar elementos de interfaces de usuario. Esta sección

describe las interfaces gráficas del usuario del software, como los botones, iconos,

usos especiales de claves de teclado o claves de combinaciones y las respuestas

deben ser presentadas en documentación por gráfico consistente o formatos

tipográficos para que cada uno de los elementos sea distinguido del texto. La

documentación debe incluir una representación de elemento. Su propósito y una

explicación de su acción (consecuencia funcional) con ejemplos de operaciones

actuales.

Formatos para características del documento para acceder a la información

Cuadro de contenidos.- Un cuadro de contenidos debe tener encabezados de los

capítulos o títulos de tópicos bajados al tercer nivel. La tabla de contenidos incluye

solo el primer nivel de encabezados, la documentación electrónica puede exhibir

cuadros de contenidos en formato expandibles para proveer el nivel principal y

30

acceso detallado a encabezados. El cuadro de contenidos debe incluir también

apéndices, glosario, e índice.

Lista de ilustraciones. Esta sección contiene las tablas, lista de figuras o una lista de

ilustraciones, si el documento contenido más de 5 ilustraciones numeradas y no es

visible poner una referencia de texto. Las ilustraciones deben tener el número y título

como un punto de acceso a cada uno.

Índice. Esta sección describe cómo organizar el índice, este debe ser

alfabéticamente, los gráficos o conceptos con un punto de acceso para cada uno de

los documentos impresos, cuando tenga más de 40 páginas deben incluir un índice.

Los puntos de acceso puede ser número de páginas, número de tópicos, número de

ilustraciones, o referencias a otro índice de entrada. Los documentos electrónicos con

más de 40 tópicos deben incluir una herramienta de búsqueda un índice de los puntos

de acceso estos son los enlaces electrónicos.

Formatos para características de navegación. Esta sección incluye el encabezado

de los capítulos y tópico, página o título de pantalla y número de pantalla,

encabezados de página, los iconos de navegación deben ser proveídos para que los

usuarios puedan determinar su localización dentro del impreso o documento

electrónico. La documentación puede incluir explicaciones del sistema y

característica específicas.

Las características de navegación deben tener:

• Tabla de contenidos

• Índice

Las características de navegación deben usar formatos consistentes como:

• Enlaces calificados, color o gráfico para distinguirlos el texto simple

• Los enlaces entre tópicos relacionados deben ser bidireccionales, para

cualquier tópico para que los usuarios tengan acceso.

• La referencia electrónica debe ser accesible desde el software que documenta

y debe tener salir de la documentación y retorna al software.

31

El software puede ser enlazado a la ayuda en línea, tutoriales o documentos de

referencia de varias maneras, tales como las siguientes:

• A través de un punto de entrada para ayudar al sistema.

• A través de botones de ayuda en las pantallas del software que proveen

información en un tópico en particular (caja de dialogo y ayudar del nivel de

campo).

• A través de ayuda de contexto sensitivo y texto (claves de herramientas)

1.6.5. Std 730-1998 norma IEEE para planes de aseguramiento de la calidad del

software4

Este estándar especifica el formato y contenido del plan de

aseguramiento de calidad de software, esta etapa tiene como objetivo la consecución

de un primer documento en que queden reflejados los requerimientos y

funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se

va a desarrollar)


Plan de Aseguramiento de Calidad de Software

• Propósito • Documentos de Referencia • Administración • Documentación • Estándares, Practicas y Métricas • Revisiones de Software • Pruebas • Reporte de Problemas y Acciones Correctivas • Herramientas, Técnicas y Metodología • Control de Medios de Comunicación • Control de Proveedor • Colección de Registros, Mantenimiento y Retención • Capacitación • Gestión de Riesgo • Procedimiento de Cambio SQAP e Historia


32



1.6.5.1.- El plan de aseguramiento de calidad de software

El SQAP tiene en la primera página la fecha de emisión, el estado del documento y la

identificación de la organización que realiza el documento, este será aprobado por el

gerente de cada unidad de organización.

Propósito. Está sección detalla el objetivo específico y ámbito particular del SQAP,

se debe incluir el nombre y uso del software señalando en qué fase del ciclo de vida

del software se aplicará el SQAP.

Documentos de referencia. Esta sección lista los documentos que fueron utilizados

para desarrollar el SQAP, estos documentos incluyen las políticas y leyes que

llevaron a desarrollar este plan, La versión y fecha de cada documento debe estar

incluido en la lista.

Administración. Esta sección describe la estructura de la organización del proyecto,

sus tareas, papeles y responsabilidades.

Organización. Esta sección trata la estructura organizacional que interviene y

controla la calidad del software y describe los principales elementos de la

organización, para verificar, evaluar y monitorear la calidad del software, siendo la

organización la responsable de preparar y mantener el SQAP.

Tareas. Esta sección describe:

• Fase del ciclo de vida en la que se aplicara el SQAP

• Tareas a realizarse

• Criterio de entrada y salida de cada tarea

• Relación y secuencia de las tareas

• Horario del plan

33

Papeles y responsables. Esta sección identifica los elementos específicos de la

organización que es responsable de las tareas.

Evaluación de recursos de aseguramiento de calidad

Esta sección evalúa los recursos y costos a ser consumidos en el aseguramiento y

control de la calidad.

Documentación. Esta sección realiza las siguientes funciones:

• Identifica la documentación para controlar el desarrollo, verificando y valida

el uso y mantenimiento del software.

• Lista los documentos que deben ser revisados

Requisitos mínimos de documentación. Esta sección asegura que la

implementación del software cumple con los documentos básicos para satisfacer los

requisitos técnicos.

Descripción de los requisitos del software (srd). Esta sección específica los

requisitos que pueden ser escritos por el proveedor (interno o externo), cliente o

ambos, cada requisito debe ser identificado y definido únicamente para verificar y

validar objetivamente.

1.6.5.2 Descripción del diseño del software (sdd)

Esta sección toma la estructura del software para satisfacer los requisitos (srd). El

SDD debe describir los componentes y subcomponentes del diseño del software

incluyendo la base de datos e interfaz interna para lo cual se puede realizar un

prototipo.

Plan de verificación y validación. Esta sección se utiliza para determinar que el

producto software este acorde a los requisitos y si cumple con las expectativas del

usuario. El plan de verificación y validación puede ser adjuntado a un solo

34

documento y define la verificación y validación de tareas, entrada y salida de

información para salvaguardar el nivel de integridad del software.

Reporte de resultados de verificación y validación. Esta sección describe los

resultados de las actividades realizadas en el software de acuerdo al plan.

Documentación del usuario. Esta sección guía al usuario en la instalación,

operación, administración y mantenimiento del producto software, este documento

describe el control y la secuencia de la información de entrada, opciones,

limitaciones del programa y otra información, con este documento el usuario puede

manipular el sistema.

Plan de gestión de configuración del software (smcp). Esta sección documenta las

actividades del smcp en el que se definen las rutas para mantener, guardar, asegurar,

controlar y documentar las versiones en las bibliotecas, este plan se aplica a la parte

del ciclo de vida que se desarrolle el sqap.

Otra documentación. Esta sección identifica otros documentos aplicables al

proyecto de desarrollo del software, puede incluir los siguientes documentos:

• Plan de proceso de desarrollo

• Métodos de ingeniería de software/proceso/descripción de herramientas.

• Plan de gestión del proyecto software

• Plan de mantenimiento

• Plan de seguridad del software

• Plan de integración del software.

1.6.5.3 Norma IEEE para los planes de gestión de proyectos de software - IEEE

std 1058-19985



35

Este estándar describe el formato y contenido del plan de gestión del proyecto

software, se aplica a cualquier tipo o tamaño de proyecto software

Introducción.

• Visión general del proyecto. • Productos finales. • Evolución del plan de proyecto. • Documentos de referencia. • Definiciones y acrónimos. • Organización

del proyecto.

• Modelos de procesos.

• Estructura organizativa.

• Fronteras e interfaces organizativas.

• Responsabilidades

• Procesos de gestión. • Objetivos y prioridades de gestión. • Suposiciones, dependencias y restricciones. • Gestión de riesgos. • Mecanismos de supervisión y control. • Plan de personal.

• Proceso técnico

• Metodologías, técnicas y herramientas. • Documentación software. • Funciones de apoyo al proyecto.

• Plan de desarrollo.

• Paquetes de trabajo. • Dependencias. • Recursos. • Presupuesto y distribución de recursos.

Calendario.



Introducción

Visión general del proyecto. Esta subsección del pgps incluirá un resumen conciso

de los objetivos del proyecto, el producto a entregar, las principales actividades de

36

trabajo, los principales productos de trabajo, los principales hitos, los recursos

necesarios, y el calendario y el presupuesto maestro.

La descripción del proyecto incluirá asimismo la relación de este proyecto a otros

proyectos, según corresponda. Esta descripción, no se interpretará como una

especificación oficial de los requisitos del producto. La referencia a la especificación

de los requisitos del software se presentará en este tramo de la pgps.

Productos finales. Esta subsección del pgps incluirá en la lista todos los ítems que se

entrega al cliente, las fechas de entrega, los lugares de entrega, y las cantidades

necesarias para satisfacer los términos del acuerdo de proyecto. Esta lista de

entregables del proyecto, no se interpretará como una declaración oficial de los

requisitos del proyecto.

Evolución del plan del proyecto. Esta subsección del pgps debería especificar los

planes para llevar a cabo tanto las actualizaciones planificadas del plan, como las no

planificadas del pgps. Este apartado se especificará también los mecanismos

utilizados para colocar la versión inicial del pgps bajo el cambio de control y para

controlar los cambios posteriores a la spmp.

Documentos de referencia. Esta subsección del pgps debería ofrecer una lista

completa de todos los documentos y otras fuentes de información referenciadas en el

pgps. Cada documento debería ser identificado por un título, número de informe,

autor y organización que lo publicó. Otras fuentes de información tales como

ficheros electrónicos, deberían ser identificadas de una manera no ambigua usando

identificadores, tales como el número de versión y la fecha de su publicación.

Cualquier desviación de los estándares referenciados o políticas debería ser

identificado y aportado las correspondientes justificaciones.

Definiciones y acrónimos. Esta subsección del pgps debería definir o proveer

referencias a los términos y acrónimos necesarios para comprender adecuadamente el

pgps.

Organización del proyecto

37

Modelo de procesos. Esta subsección del pgps debería definir las relaciones entre las

funciones principales del proyecto y las actividades, especificando el calendario de

los hitos principales, documentos bases, revisiones, productos de trabajo, productos

entregables, y el fin del proyecto. El modelo de procesos puede ser descrito

utilizando una combinación de notaciones textuales y gráficas.

El modelo de proceso puede incluir las actividades de iniciación y finalización del

proyecto.

Estructura organizativa. Esta sub sección del pgps debería describir la estructura

para la gestión interna del proyecto. Dispositivos gráficos tales como gráficos de

organizaciones jerárquicas o diagramas de matrices pueden ser usados para

representar las líneas de autoridad, responsabilidad y comunicación dentro del

proyecto.

Límites e interfaces organizativos. Esta subsección del pgps debería describir los

límites administrativos y de gestión entre el proyecto y cada una de las siguientes

entidades: organización que se encarga del proyecto, la organización cliente,

organizaciones subcontratadas o cualquier otra entidad organizativa que interaccione

con el proyecto. Además, las interfaces de administración y gestión de las funciones

de soporte del proyecto, tales como la gestión de configuración, control de calidad y

verificación y validación se especificarán en este apartado.

Responsabilidades. Esta subsección del psmp deberá determinar y precisar la

naturaleza de cada función importante proyecto y actividad, e identificar a los

individuos que son responsables de las funciones y actividades. Una matriz de

funciones y actividades versus las personas responsables pueden ser utilizadas para

representar las responsabilidades del proyecto.

Procesos de gestión. Esta sección de la pgps especificará objetivos y prioridades de

gestión; suposiciones del proyecto, las dependencias y las limitaciones, técnicas de

gestión de riesgos, la supervisión y el control de los mecanismos que se utilizarán, y

el plan de personal.

Objetivos y prioridades de gestión. Esta subsección del pgps dará cuenta de la

filosofía, objetivos y prioridades para la gestión de las actividades realizadas durante

38

el proyecto. Los temas que se especifican pueden incluir, pero no se limitan a, la

frecuencia y los mecanismos para la generación de informes que se utilizarán; la

prioridad de los requisitos, el programa y presupuesto para este proyecto, los

procedimientos de gestión de riesgos que ha de seguirse, y una declaración de

intenciones para adquirir, modificar, o utilizar el software existente

Suposiciones, dependencias y restricciones. Esta subsección del pgps debería

afirmar los supuestos en los que está basado el proyecto, los acontecimientos

externos de los que el proyecto depende y las restricciones que bajo las cuales el

proyecto va a ser guiado.

Gestión de riesgos. Esta subsección del pgps debería identificar y valorar los

factores de riesgos asociados al proyecto. Esta subsección también debería prescribir

mecanismos para el rastreo de varios factores de riesgo e implementar planes de

contingencia. Los factores de riesgos que deberían ser considerados incluyen riesgos

contractuales, tecnológicos, riesgos debidos al tamaño y complejidad del proyecto,

riesgos en la adquisición y retención del personal, y riesgos en lograr que el cliente

acepte el producto.

Mecanismos de supervisión y control. Esta subsección del pgps debería definir los

mecanismos para generar informes, los formatos de los informes, flujos de

información, mecanismos de auditoría y revisión, y otras herramientas y técnicas que

pueden ser usadas para controlar las adiciones al pgps.

El control del proyecto debería ocurrir en el nivel de paquetes de trabajo. La relación

entre los mecanismos para controlar el proyecto y las funciones de soporte deberían

ser trazadas en este nivel.

Plan del personal. Esta sección del pgps especificará el número y tipo de personal

necesario para llevar a cabo el proyecto. Los niveles de cualificación requeridos, los

tiempos de comienzo, la duración de la necesidad, y los métodos de obtención, la

formación, retención y eliminación gradual del personal se especificarán

Procesos técnicos. Esta sección del pgps deberá especificar los métodos técnicos,

herramientas y técnicas analíticas que se utilizarán en el proyecto. Además, el plan

para la documentación de software se especifica, y los planes para las funciones de

39

soporte del proyecto, como garantía de la calidad, gestión de configuración, la

verificación y validación pueden ser especificados

Metodologías, herramientas y técnicas. Esta subsunción de la pgps deberá

especificar el/los sistema informático(s), metodología/s de desarrollo, la/s estructura

del equipo, el/los lenguaje de programación, y otras anotaciones, herramientas,

técnicas y métodos que deben utilizarse para especificar, diseñar, construir, probar,

integrar, documentar, modificar o mantener o ambos (según corresponda) las

prestaciones del proyecto. Además, las normas técnicas, políticas y procedimientos

que rigen el desarrollo o la modificación o ambos de los productos de trabajo y las

prestaciones del proyecto se incluirán, ya sea directamente o por referencia a otros

documentos.

Documentación del software. Esta subsección del pgps debería contener o

referenciar el plan de documentación del proyecto software. El plan del documento

debería especificar los requisitos de documentación, los hitos, líneas base, revisiones

y la finalización de la documentación del software. El plan de documentación

también puede contener una guía de estilo, convenciones en la nomenclatura y

formatos del documento. El plan de documentación podría incluir un resumen de la

agenda y los recursos necesarios para el esfuerzo de la documentación. El estándar

ansi/ieee 829-1983 “standard for software test documentation” ofrece el estándar

para la documentación de pruebas del software.

Funciones de apoyo al proyectos. Esta subsección del pgps debería contener

directamente o por referencia los planes para las funciones de soporte para el

proyecto software. Estas funciones pueden incluir, pero no están limitadas a, gestión

de la configuración, aseguramiento de la calidad del software, y verificación y

validación. Los planes para las funciones de soporte al proyecto deberán ser

desarrollados a un nivel de detalles consistente con las otras secciones del pgps. En

particular, se deben especificar las responsabilidades, requerimientos de recursos,

agendas y herramientas para cada una de las funciones de soporte al proyecto. La

naturaleza y tipo de las funciones de soporte al proyecto variarán de un proyecto a

otro; de todos modos, la ausencia del aseguramiento de calidad software, gestión de

40

la configuración o plan de verificación y Validación debe ser explícitamente

justificado en los planes de los proyectos que no los incluyan.

Plan de desarrollo

Paquetes de trabajo. Esta subsección del pgps debería especificar los paquetes de

trabajo para las tareas y actividades que deben completarse en orden para satisfacer

los acuerdos del proyecto. Cada paquete de trabajo debería ser unívocamente

identificado; la identificación puede estar basada en un esquema numerado y títulos

descriptivos. Se puede usar un diagrama que describa la división de las actividades

en sub-actividades y tareas (estructura de desglose) para describir las relaciones

jerárquicas entre los distintos paquetes de trabajo.

Dependencias. Esta subsección del pgps debería especificar las relaciones de orden

entre los distintos paquetes de trabajo para reflejar de alguna forma las

interdependencias entre ellos y la dependencia de acontecimientos externos al

proyecto. Se pueden usar técnicas tales como las listas de dependencia, redes de

actividades, y método de camino crítico para describir las dependencias entre los

distintos paquetes de trabajo.

Requerimientos de recursos. Esta subsección del pgps debería proporcionar, en

función del tiempo, estimaciones del total de los recursos necesarios para completar

el pgps. El número y tipo del personal, tiempo de computación, software de soporte,

ordenadores, facilidades de laboratorios y oficinas, viajes, y requerimientos de

mantenimiento para los recursos de proyectos deberían ser especificados.

Presupuesto y distribución de recursos. Esta subsección del pgps debería

especificar la localización de las herramientas y recursos de las distintas funciones

del proyecto, actividades y tareas. Se puede usar un esquema de ganancia de valores

para localizar herramientas y recursos, y para llevar un control del gasto y de la

utilización de los recursos.

41

1.6.5.4 IEEE estándar para la verificación y validación de software - IEEE STD

1012-20046

Este estándar describe verificación de software y procesos de validación que se

utilizan para determinar si los productos de software de una actividad cumple los

requisitos de la actividad y para determinar si el software satisface las necesidades

del usuario para el uso previsto. El alcance incluye el análisis, evaluación, revisión,

inspección, evaluación y prueba de productos y procesos.



42

Requerimientos para verificar Estrategia de verificación

• Tipos de pruebas o

• Prueba de integridad de los datos y la base de datos

o Objetivo de la prueba técnica o Técnica o Criterio de aceptación o Consideraciones especiales

• Prueba de funcionalidad

o Objetivo de la prueba o Técnica o Criterio de aceptación o Consideraciones especiales

• Prueba de ciclo del

negocio


• Prueba de interface de

usuario


• Prueba de performance


• Prueba de carga

o Objetivo de la prueba o Técnica o Criterio de aceptación

43

o Consideraciones especiales

• Prueba de esfuerzo (stress, competencia por recursos, bajos recursos)


• Prueba de volumen

o Objetivo de la prueba o Técnica o Criterio de aceptación o Consideraciones

especiales

• Prueba de seguridad y control de acceso


• Prueba de

fallas y recuperación


44

Prueba de configuración


• Prueba de

instalación


• Prueba de documentos


Herramientas

45

1. Recursos

1.1. Roles • Rol • Cantidad mínima de

recursos recomendada o Responsabilidades

• Responsable de verificación

o Identifica, prioriza e implementa los casos de prueba.

o Genera el plan de verificación. o Genera el modelo de prueba. o Evalúa el esfuerzo necesario para

verificar. o Proporciona la dirección técnica. o Adquiere los recursos

apropiados. o Proporciona informes sobre la

verificación. • Asistente de

verificación o Ejecuta las pruebas

o Registra los resultados de las pruebas.

o Recuperar el software de errores. o Documenta los pedidos de

cambio. • Administrador de base

de datos o Realiza la gestión y

mantenimiento del entorno de los datos (base de datos) de prueba y los recursos.

o Administra la base de datos de prueba.

46

Sistema Recurso Nombre/tipo

Servidor de base de datos

red o subred

nombre del servidor

nombre de la base de datos

Pc cliente para pruebas

requerimientos especiales

Repositorio de pruebas

red o subred

nombre del servidor

47

Hitos del proyecto de verificación

Actividad que determina el hito

Esfuerzo Fecha de comienzo

Fecha de finalización

Planificar la verificación

Elaborar casos de prueba

Ajuste y control de verificación

Ejecutar la verificación

Evaluar la verificación

Entregables

o Modelo de casos de prueba o Informes de verificación o Evaluación de la verificación o Informe final de verificación

Dependencias [opcional] o Dependencia de personal [opcional]

o Dependencia de software [opcional] o Dependencia de datos y base de datos de prueba [opcional]

Riesgos [opcional]

o Planificación [opcional] o Técnico [opcional] o Gestión [opcional]

48



Requerimientos para verificar

En la lista a continuación se presentan los elementos, casos de uso, requerimientos

funcionales y requerimientos no funcionales, que serán verificados.

Lista de los requerimientos más importantes a ser verificados. En esta sección

indique qué elementos serán verificados.

Estrategia de verificación

• Esta sección presenta el enfoque recomendado para la verificación. Describe

como se verificarán los elementos.

• Para cada tipo de prueba, proporcione una descripción de la prueba y porque será

implementada y ejecutada.

• Si un tipo de prueba no será implementada y ejecutada, indique brevemente cual

es la prueba que no se implementará o ejecutará y una justificación de ello.

• Se indicarán las técnicas usadas y el criterio para saber cuándo una prueba se

completó (criterio de aceptación).

• Las pruebas se deben ejecutar usando bases de datos conocidas y controladas en

un ambiente seguro.

Tipos de pruebas

En las secciones a continuación, que son los tipos de pruebas a realizar, para cada

tipo de prueba en lugar de explicar el contenido de cada sección y subsección se

incluyen ejemplos.

Prueba de integridad de los datos y la base de datos

Objetivo de la prueba. Asegurar que los métodos y procesos de acceso a la base de

datos funcionan correctamente y sin corromper datos.

49

Técnica

• Invoque cada método o proceso de acceso a la base de datos con datos

válidos y no válidos.

• Inspeccione la base de datos para asegurarse de que se han guardado los datos

correctos, que todos los eventos de la base de datos ocurrieron correctamente,

o repase los datos devueltos para asegurar que se recuperaron datos correctos

por la vía correcta.

Criterio de aceptación

Todos los métodos y procesos de acceso a la base de datos funcionan como fueron

diseñados y sin datos corruptos.

Consideraciones especiales

• La prueba requiere un entorno de administración de dbms o controladores para

ingresar o modificar información directamente en la base de datos.

• Los procesos deben ser invocados manualmente.

• Se deben usar bases de datos pequeñas para aumentar la facilidad de inspección

de los datos para verificar que no sucedan eventos no aceptables.

Prueba de funcionalidad.- La prueba de funcionalidad se enfoca en requerimientos

para verificar que se corresponden directamente a casos de usos o funciones y reglas

del negocio. Los objetivos de estas pruebas son verificar la aceptación de los datos,

el proceso, la recuperación y la implementación correcta de las reglas del negocio.

Este tipo de prueba se basa en técnicas de caja negra, que consisten en verificar la

aplicación y sus procesos interactuando con la aplicación por medio de la interface

de usuario y analizar los resultados obtenidos.

Objetivo de la prueba

• Asegurar la funcionalidad apropiada del objeto de prueba, incluyendo la

navegación, entrada de datos, proceso y recuperación.

50

Técnica

Ejecute cada caso de uso, flujo de caso de uso, o función usando datos válidos y no

válidos, para verificar lo siguiente:

• Se obtienen los resultados esperados cuando se usan datos válidos.

• Cuando se usan datos no válidos se despliegan los mensajes de error o

advertencia apropiados.

• Se aplica apropiadamente cada regla del negocio.


• Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han

sido debidamente identificados.


• Identificar o describir aquellos elementos o problemas (internos o externos) que

impactaron en la implementación y ejecución de las pruebas de funcionalidad.

Prueba de ciclo del negocio

• Esta prueba debe simular las actividades realizadas en el proyecto en el tiempo.

Se debe identificar un período, que puede ser un año, y se deben ejecutar las

transacciones y actividades que ocurrirían en el período de un año. Esto incluye

todos los ciclos diarios, semanales y mensuales y eventos que son sensibles a la

fecha.


• Asegurar que la aplicación funciona de acuerdo a los requerimientos del negocio.

Técnica La prueba debe simular ciclos de negocios realizando lo siguiente:

51

• Las pruebas de funcionalidad se deben modificar para aumentar la cantidad de

veces que se ejecuta cada función, simulando varios usuarios diferentes en un

período determinado.

• Todas las funciones sensibles a la fecha se deben ejecutar con fechas válidas y no

válidas o períodos de tiempos válidos y no válidos.

• Para cada prueba realizada verificar lo siguiente:

• Se obtienen los resultados esperados cuando se usan datos válidos.

• Cuando se usan datos no válidos se despliegan los mensajes de error o

advertencia apropiados.

• Se aplica apropiadamente cada regla del negocio.


• Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han

sido debidamente identificados.


• Las fechas del sistema y eventos requieren actividades de soporte especiales. Se

requieren las reglas del negocio para identificar apropiadamente los

requerimientos y procedimientos a ser verificados.

Prueba de interface de usuario

• Esta prueba verifica que la interface de usuario proporcione al usuario el acceso y

navegación a través de las funciones apropiada. Además asegura que los objetos

presentes en la interface de usuario se muestren como se espera y conforme a los

estándares establecidos por la empresa o de la industria.


• Verificar que: la navegación a través de los elementos que se están probando

reflejen las funciones del negocio y los requerimientos, incluyendo manejo de

52

ventanas, campos y métodos de acceso; los objetos de las ventanas y

características, como menú es, tamaño, posición, estado funcionen de acuerdo a

los estándares.

Técnica

• Crear o modificar pruebas para cada ventana verificando la navegación y los

estados de los objetos para cada ventana de la aplicación y cada objeto dentro de

la ventana.


• Cada ventana ha sido verificada exitosamente siendo consistente con una versión

de referencia o estándar establecido.


• No todas las propiedades de los objetos se pueden acceder.

Prueba de performance

• En esta prueba se miden y evalúan los tiempos de respuesta, los tiempos de

transacción y otros requerimientos sensitivos al tiempo. El objetivo de la prueba

es verificar que se logren los requerimientos de performance. La prueba de

performance es implementada y ejecutada para poner a punto los destinos de

pruebas de performance como función de condiciones de trabajo o

configuraciones de hardware.


Verificar la performance de determinadas transacciones o funciones de negocio bajo

ciertas condiciones:

Condiciones de trabajo normales conocidas.

53

Peores casos de condiciones de trabajo conocidas.

Técnica

Usar procedimientos de prueba desarrollados para verificar funciones o ciclos de

negocio.

Modificar archivos de datos para aumentar el número de transacciones o los

procedimientos de prueba para aumentar el número de iteraciones de ocurrencia de

transacciones.

Las pruebas se deben ejecutar en una máquina (mejor caso de prueba un solo usuario,

una sola transacción) y se debe repetir con múltiples usuarios (virtuales o reales).


• Con una transacción o un usuario: éxito completo de la prueba sin fallas y dentro

del tiempo esperado o requerido.

• Con múltiples transacciones y varios usuarios: éxito completo de la prueba sin

fallas y dentro de un tiempo aceptable.


Las pruebas de performance deben incluir un trabajo de fondo en el servidor. Esto se

puede realizar de distintas formas:

Enviar transacciones directamente al servidor, generalmente en la forma de consultas

(SQL).

Crear usuarios virtuales para simular muchos clientes, generalmente varios cientos.

Se pueden usar herramientas de emulación de terminar remota para lograr este

objetivo. Esta técnica también se usa para cargar la red con “trafico”.

Usar muchos clientes físicos, cada uno corriendo procedimientos de prueba.

La prueba de performance se debe realizar en una máquina dedicada para permitir

control total y medición exacta.

Las bases de datos usadas para las pruebas de performance deben tener un tamaño

similar a las reales.

54

Prueba de carga

La prueba de carga somete los objetos a verificar a diferentes cargas de trabajo para

medir y evaluar los comportamientos de performance y la habilidad de los objetos de

continuar funcionando apropiadamente bajo diferentes cargas de trabajo. El objetivo

es determinar y asegurar que el sistema funciona apropiadamente en circunstancias

de máxima carga de trabajo esperada. Además evaluar las características de

performance, como tiempos de respuesta, tiempos de transacciones y otros elementos

sensitivos al tiempo.


• Verificar el comportamiento de performance de determinados componentes del

software bajo condiciones de trabajo diferentes.

Técnica

• Usar pruebas desarrolladas para funciones o ciclos de negocios y modificar

archivos de datos para aumentar el número de transacciones o las pruebas para

aumentar la cantidad de ocurrencia de transacciones.


• Para múltiples transacciones y múltiples usuarios: realización exitosa de las

pruebas sin fallas y dentro del tiempo aceptable.


• La prueba de carga debe realizarse en una máquina dedicada para tener control

total y exactitud de mediciones.

• Las bases de datos usadas para la prueba deben tener un tamaño similar a las

reales.

55

Prueba de esfuerzo (stress, competencia por recursos, bajos recursos)

La prueba de esfuerzo en un tipo de prueba de performance implementada y

ejecutada para encontrar errores cuando hay pocos recursos o cuando hay

competencia por recursos. Poca memoria o poco espacio de disco pueden revelar

fallas en el software que no aparecen bajo condiciones normales de cantidad de

recursos. Otras fallas pueden resultar al competir por recursos compartidos como

bloqueos de bases de datos o ancho de banda de red. La prueba de esfuerzo también

puede usarse para identificar el trabajo máximo que el software puede manejar.


Verificar que el software funciona apropiadamente y sin error bajo condiciones de

esfuerzo, como son:

• Poca memoria o sin disponibilidad de memoria en el servidor

• Cantidad máxima de clientes conectados

• Múltiples usuarios realizando la misma operación sobre los mismos datos

• Peor caso de volumen de operaciones.

• El objetivo de la prueba de esfuerzo es también identificar y documentar las

condiciones bajo las cuales el sistema falla y no continua funcionando

apropiadamente.

Técnica

• Usar las pruebas desarrolladas para performance y prueba de carga.

• Para probar recursos limitados, las pruebas se deben ejecutar en una sola

máquina, y se debe reducir o limitar la memoria en el servidor.

• Para las pruebas de esfuerzo restantes, deber usarse múltiples clientes, cualquiera

que ejecute las mismas pruebas o pruebas complementarias para producir el peor

caso de volumen de operaciones.


Todas las pruebas planeadas se ejecutaron y se alcanzaron o excedieron los límites

del sistema sin que el software fallara o las condiciones bajo las que ocurre una falla

en el software están fuera de las condiciones especificadas.

56


• Las pruebas de esfuerzo de red pueden requerir herramientas de red para

cargar la red con mensajes o paquetes.

• La cantidad de disco del servidor usada por el sistema debe ser reducida

temporalmente para restringir el espacio disponible para crecimiento de la

base de datos.

• Sincronizar el acceso simultáneo de varios clientes accediendo a los mismos

datos.

Prueba de volumen

La prueba de volumen somete el software a grandes cantidades de datos para

determinar si se alcanzan límites que causen la falla del software. La prueba de

volumen identifica la carga máxima continua que puede manejar el software a prueba

en un período dado.


Verificar que el software funciona correctamente con volúmenes de datos grandes:

Máximo (real o físicamente posible) número de clientes conectados, o simulados,

todos realizando la misma operación (peor caso de operación) por un período de

tiempo extenso. Máximo tamaño de base de datos y múltiples consultas ejecutadas

simultáneamente.

Técnica

Usar pruebas desarrolladas para prueba de performance y prueba de carga.

Se deben usar múltiples clientes, ejecutando las mismas pruebas o pruebas

complementarias para producir el peor caso de volumen de operaciones o mezcla en

un período de tiempo extenso. Se debe crear el tamaño máximo de base de datos

(real, escalado o con datos representativos) y múltiples clientes ejecutando consultas

simultáneamente por un período de tiempo extenso.

Criterio de aceptación Todas las pruebas planificadas se ejecutaron y se han

alcanzado o excedido los límites especificados sin que el software falle.

57


• ¿qué período de tiempo se considera aceptable para condiciones de gran

volumen?

Prueba de seguridad y control de acceso

La prueba de seguridad y control de acceso se enfoca en dos áreas de seguridad:

Seguridad en el ámbito de aplicación, incluyendo el acceso a los datos y a las

funciones de negocios.

Seguridad en el ámbito de sistema, incluyendo conexión, o acceso remoto al sistema.

La seguridad en el ámbito de aplicación asegura que, basado en la seguridad deseada

los actores están restringidos a funciones o casos de uso específicos o limitados en

los datos que están disponibles para ellos.

La seguridad en el ámbito de sistema asegura que, solo los usuarios con derecho a

acceder al sistema son capaces de acceder a las aplicaciones y solo a través de los

puntos de ingresos apropiados.


• Seguridad en el ámbito de aplicación: verificar que un actor pueda acceder solo a

las funciones o datos para los cuales su tipo de usuario tiene permiso.

• Seguridad en el ámbito de sistema: verificar que solo los actores con acceso al

sistema y a las aplicaciones, puedan acceder a ellos.

Técnica

• Seguridad en el ámbito de aplicación: identificar y hacer una lista de cada

tipo de usuario y las funciones y datos sobre las que cada tipo tiene permiso.

• Crear pruebas para cada tipo de usuario y verificar cada permiso creando

operaciones específicas para cada tipo de usuario.

• Modificar el tipo de usuario y volver a ejecutar las pruebas para los mismos

usuarios. En cada caso, verificar que las funciones o datos adicionales están

correctamente disponibles o son denegados.

58

• Acceso en el ámbito de sistema: ver consideraciones especiales más abajo.


• Para cada tipo de actor conocido las funciones y datos apropiados están

disponibles, y todas las operaciones funcionan como se espera y ejecutan las

pruebas de funcionalidad de la aplicación.


• El acceso al sistema debe ser discutido con el administrador del sistema o la

red. Esta prueba no puede requerirse como tal, es una función del

administrador del sistema o de la red.

Prueba de fallas y recuperación

• Las pruebas de fallas y recuperación aseguran que el software puede

recuperarse de fallas de hardware, software o mal funcionamiento de la red

sin pérdida de datos o de integridad de los datos.

• La prueba de recuperación es un proceso en el cual la aplicación o sistema se

expone a condiciones extremas, o condiciones simuladas, para causar falla,

como fallas en dispositivos de entrada/salida o punteros a la base de datos

inválidos. Los procedimientos de recuperación se invocan y la aplicación o

sistema es monitoreado e inspeccionado para verificar que se recupera

apropiadamente la aplicación o sistema y se logre la recuperación de datos.


Verificar que los procesos de recuperación (manual o automáticos) recuperen

apropiadamente la base de datos, aplicaciones y sistema a un estado conocido y

deseado. En la prueba se incluyen los siguientes tipos de condiciones:

• Interrupción de energía al cliente

• Interrupción de energía al servidor

• Interrupción de comunicaciones mediante los servidores de la red

• Interrupción de comunicación o pérdida de energía de los discos del servidor

o con los controladores

59

• Ciclos incompletos (procesos de filtro de datos interrumpidos, procesos de

sincronización de datos interrumpidos)

• Punteros a la base de datos o claves inválidos

• Elementos de datos en la base de datos inválidos o corruptos.

Técnica

Se deben usar las pruebas creadas para probar funcionalidad y ciclos de negocio para

crear una serie de operaciones. Una vez logrado el punto de comienzo deseado, se

deben realizar o simular las siguientes acciones, individualmente:

• Interrumpir la energía del cliente: apagar el pc.

• Interrumpir la energía del servidor: simular o iniciar el proceso de apagado

del servidor.

• Interrupción por medio de los servidores de red: simular o iniciar la pérdida

de comunicación con la red (desconectar físicamente la comunicación o

apagar el servidor de red o router.

• Interrumpir la comunicación o quitar la energía de los discos del servidor o

sus controladores: simular o eliminar físicamente a la comunicación con uno

o más controladores de disco o los discos.

Una vez que se lograron o simularon estas condiciones, se deben invocar los

procedimientos de recuperación.

Las pruebas de ciclos incompletos utilizan la misma técnica excepto que los procesos

de bases de datos deben ser abortados a sí mismos o terminados prematuramente.

Las últimas dos pruebas requieren que se logre un estado conocido de la base de

datos. Se deben corromper manualmente campos de la base de datos, punteros y

claves trabajando directamente sobre la base de datos (utilizando herramientas para

la base de datos). Se deben ejecutar las pruebas de funcionalidad y ciclo de negocio y

verificar que los ciclos se completen.


60

• En todos los casos, la aplicación, la base de datos y el sistema deben, en la

realización procedimientos de recuperación, volver a un estado conocido y

deseable. Este estado incluye corrupción de datos limitada a los campos, punteros

o claves corruptos conocidos, y reportes indicando los procesos u operaciones

que no se completaron debido a las interrupciones.


• Los procedimientos para desconectar cables (simulando falta de energía o

pérdida de comunicación) no son deseables o factibles. Se pueden requerir

métodos alternativos, como software de diagnóstico. Se requieren los grupos

de recursos de sistemas, bases de datos y red.

• Estas pruebas deben ejecutarse fuera del horario de trabajo normal o en una

máquina aislada.

Prueba de configuración

• La prueba de configuración verifica el funcionamiento del software con

diferentes configuraciones de software y hardware.


• Verificar que el software funcione apropiadamente en las configuraciones

requeridas de hardware y software

Técnica

Usar las pruebas de funcionalidad.

• Abrir y cerrar varias sesiones de software que no son objeto de prueba, como

parte de la prueba o antes de comenzar la prueba.

• Ejecutar operaciones seleccionadas para simular la interacción del actor con

el software objeto de prueba y con el software que no es objeto de prueba.

61

• Repetir los procedimientos anteriores minimizando la memoria convencional

disponible en la máquina cliente.


• Por cada combinación de software objeto de prueba y software que no es objeto

de prueba, todas las operaciones son completadas exitosamente sin fallas.


Todo el software que no es objeto de prueba que es necesario y debe estar accesible.

• ¿qué aplicaciones se usan normalmente?

• ¿qué información se maneja en las aplicaciones que se usan normalmente, y que

tamaño de información?

• Los sistemas, red, servidores de red, bases de datos, etc., deben ser documentados

como parte de esta prueba.

Prueba de instalación

• La prueba de instalación tiene dos propósitos. Uno es asegurar que el software

puede ser instalado en diferentes condiciones (como una nueva instalación, una

actualización, y una instalación completa o personalizada) bajo condiciones

normales y anormales. Condiciones anormales pueden ser insuficiente espacio en

disco, falta de privilegios para crear directorios, etc. El otro propósito es verificar

que, una vez instalado, el software opera correctamente. Esto significa

normalmente ejecutar un conjunto de pruebas que fueron desarrolladas para

prueba de funcionalidad.


Verificar que el software objeto de prueba se instala correctamente en cada

configuración de hardware requerida bajo las siguientes condiciones:

Instalación nueva, una nueva máquina, nunca instalada previamente con [nombre del

proyecto]

Actualización, máquina previamente instalada con [nombre del proyecto], con la

misma versión

62

Actualización, máquina previamente instalada con [nombre del proyecto], con una

versión anterior.

Técnica

• Manualmente o desarrollando programas, para validar la condición de la máquina

destino (nueva, nunca instalado, misma versión, versión anterior ya instalada).

• Realizar la instalación.

• Ejecutar un conjunto de pruebas funcionales ya implementadas para la prueba de

funcionalidad.


• Las pruebas de funcionalidad de [nombre de proyecto] se ejecutan exitosamente

sin fallas.

Herramientas

Ingrese una lista con las herramientas usadas en el proyecto, como son herramientas

de gestión de sistema de bases de datos (dbms), herramientas para gestión de

proyecto, seguimiento de errores, monitoreo de cubrimiento de pruebas, etc. Para

cada herramienta indique la tarea para la que se usa, el nombre de la herramienta, el

origen (vendedor o software hecho en la empresa) y la versión.

Recursos

• En esta sección se presentan los recursos recomendados para el proyecto [nombre

de proyecto], sus principales responsabilidades y su conocimiento o habilidades.

Roles En la tabla a continuación se muestra la composición de personal para el

proyecto [nombre del proyecto] en el área verificación del software.

63

Sistema

En la siguiente tabla se establecen los recursos de sistema necesarios para realizar la

verificación. Es recomendable que el sistema simule el entorno de producción,

reduciendo los accesos y los tamaños de bases de datos si fuera apropiado.

Recurso Nombre/tipo

Servidor de base de datos

red o subred

nombre del servidor

nombre de la base de datos

Pc cliente para pruebas

requerimientos especiales

Repositorio de pruebas

red o subred

nombre del servidor

Hitos del proyecto de verificación

La verificación del [nombre de proyecto] debe incorporar actividades de prueba para

cada verificación identificada en las secciones anteriores. Se deben identificar los

hitos del proyecto de verificación separados para comunicar los logros de estado de

proyecto.

Rol CMR Responsabilidades Responsable de verificación (Cantidad

mínima de recursos recomendada)

Identifica, prioriza e implementa los casos de prueba. • Genera el plan de verificación. • Genera el modelo de prueba. • Evalúa el esfuerzo necesario para verificar. • Proporciona la dirección técnica. • Adquiere los recursos apropiados. • Proporciona informes sobre la verificación.

Asistente de verificación • Ejecuta las pruebas • Registra los resultados de las pruebas. • Recuperar el software de errores. • Documenta los pedidos de cambio.

Administrador de base de datos

• Realiza la gestión y mantenimiento del entorno de los datos (base de datos) de prueba y los recursos.

• Administra la base de datos de prueba.

64

• Las últimas tres actividades se repiten en cada iteración. Debería incluir en estas

tablas los datos de todas las iteraciones del proyecto.

Entregables

• En esta sección enumere los documentos, herramientas e informes que se crearán,

por quien, para quién y cuándo serán liberados.

• Para cada entregable deberá indicar las fechas en que son liberadas todas las

versiones del mismo.

1.2. Modelo de casos de prueba

Documento Modelo de casos de prueba Creado por El responsable de verificación, [nombre del responsable

de verificación. Para quien Es la guía para realizar las pruebas del sistema y lo

usarán los asistentes de verificación y el responsable de verificación cuando se ejecuten las pruebas del sistema.

Fecha de liberación Será liberado el [fecha de primera liberación].

Informes de verificación

Documento Se genera un documento informe de verificación unitaria por cada prueba unitaria que se realice al sistema.

Creado por Las personas que ejecutan las pruebas. Para quien Es el retorno para los implementadores de la tarea de

verificación, que detalla los errores encontrados para que puedan ser corregidos.

Fecha de liberación Será liberado luego de cada verificación unitaria. [Indique la versión y la fecha de liberación de todas las versiones de este informe.]

Documento Se genera un documento informe consolidación por cada consolidación que se realice al sistema.

Creado por Las personas que ejecutan las pruebas.

Actividad que determina el hito

Esfuerzo Fecha de comienzo

Fecha de finalización

Planificar la verificación Elaborar casos de prueba Ajuste y control de verificación

Ejecutar la verificación Evaluar la verificación

65

Para quien Es el retorno para los implementadores de la tarea de consolidación, que detalla los errores encontrados para que puedan ser corregidos.

Fecha de liberación Será liberado luego de cada consolidación. [Indique la versión y la fecha de liberación de todas las versiones de este informe.]

Documento Se genera un documento informe de verificación de

integración por cada prueba de integración que se realice al sistema.

Creado por Las personas que ejecutan las pruebas. Para quien Es el retorno para los implementadores de la tarea de


Fecha de liberación Será liberado luego de cada verificación de integración. [Indique la versión y la fecha de liberación de todas las versiones de este informe.]

Documento Se genera un documento informe de verificación de

sistema por cada prueba de sistema que se realice. Creado por Las personas que ejecutan las pruebas. Para quien Es el retorno para los implementadores de la tarea de


Fecha de liberación Será liberado luego de cada verificación de sistema. [Indique la fecha de liberación de este informe.]

Evaluación de la verificación

Documento Se genera un documento evaluación de la verificación por cada prueba que se realice al sistema. Este documento contiene las fallas encontradas en el sistema, la cobertura de la verificación realizada y el estado del sistema.

Creado por El responsable de verificación, que toma como fuente de su trabajo los informes de verificación.

Para quien Es el resumen de la tarea de verificación y es el retorno para todo el equipo de trabajo del estado del sistema.

Fecha de liberación Será liberado luego de cada verificación, unitaria, de integración y de sistema. [Indique la versión y la fecha de liberación de todas las versiones de este informe.]

Informe final de verificación

66

Documento El documento informe final de verificación es el

resumen de la verificación final del sistema antes de que

sea liberado al entorno del usuario.

Creado por El responsable de verificación, que toma como fuente de

su trabajo los informes de verificación.

Para quien Indica el estado del sistema.

Fecha de liberación Será liberado luego de la verificación final del sistema.

Dependencias [opcional]. En esta sección se detallan las dependencias, si existen,

de las actividades de verificación respecto a otros elementos del sistema.

Dependencia de personal [opcional] En esta sección se detallan las necesidades de

personal para el equipo de verificación, la cantidad y habilidades.

Dependencia de software [opcional]. En esta sección se detallan los requisitos que

debe cumplir el software a ser verificado para que se realice la verificación. Por

ejemplo, que debe tener una verificación previa por parte del implementador, que

debe estar en fecha disponible para verificar.

Dependencia de hardware [opcional]. En esta sección se detallan las necesidades

de disponibilidad de hardware para realizar las tareas de verificación. Por ejemplo,

horario, cantidad de horas que debe estar disponible para que las tareas de

verificación se puedan realizar dentro del cronograma establecido.

Dependencia de datos y base de datos de prueba [opcional]. [En esta sección se

detallan las necesidades de disponibilidad de dato y de la base de datos para realizar

las tareas de verificación. Por ejemplo, conjuntos de datos necesarios para la

verificación, horarios de acceso a la base de datos que permitan que las tareas de

verificación se puedan realizar dentro del cronograma establecido.

Riesgos [opcional] En esta sección se detallan los riesgos detectados que puedan

afectar la normal realización de las tareas de verificación.

67

Planificación [opcional]. En esta sección se plantean los riesgos relativos a la

planificación. Por ejemplo, si una cronograma es muy ajustado un pequeño retraso en

la liberación del software para verificar atrasa la verificación y por consiguiente las

actividades que dependen de esta, provocando un retraso en el cronograma de todo el

proyecto.

Técnico [opcional]. En esta sección se plantean los riesgos técnicos que afectan a la

verificación. Por ejemplo, si existe un sistema anterior se deberá hacer una

verificación en paralelo con el anterior en lugar de liberar la versión en un punto de

trabajo a modo de prueba del sistema.

Gestión [opcional]. En esta sección se plantea como mediante la gestión se pueden

mitigar los riesgos en las tareas de verificación.

Niveles de gravedad de error

En muchas actividades del proceso de verificación se deben clasificar los errores

según su nivel de gravedad. Se asigna un nivel de gravedad a los errores para poder

capturar de alguna manera su impacto en el sistema. Además para poder evaluar la

verificación y el sistema. A continuación se da una sugerencia de cuatro niveles

diferentes de gravedad de error:

• Catastrófico: un error cuya presencia impide el uso del sistema.

• Crítico: un error cuya presencia causa la pérdida de una funcionalidad crítica del

sistema. Si no se corrige el sistema no satisfará las necesidades del cliente.

• Marginal: un error que causa un daño menor, produciendo pérdida de efectividad,

pérdida de disponibilidad o degradación de una funcionalidad que no se realiza

fácilmente de otra manera.

• Menor: un error que no causa perjuicio al sistema, pero que requiere

mantenimiento o reparación. No causa pérdida de funcionalidades que no se

puedan realizar de otra manera.

Niveles de aceptación para los elementos verificados

Se debe establecer un nivel de aceptación para los elementos verificados para poder

establecer el estado en el que se encuentra el proyecto.

68

En esta sección defina niveles de aceptación y los criterios de pertenencia a cada

nivel. Como ejemplo de niveles de aceptación:

• No aprobado: el elemento verificado tiene errores catastróficos (uno o varios) que

impiden su uso o tiene errores críticos (uno o varios) que hacen que el elemento

verificado no sea confiable. El usuario no puede depender de él para realizar el

trabajo.

• Aprobado con observaciones: el elemento verificado no tiene errores

catastróficos, ni errores críticos, pero tiene errores marginales (uno o varios) que

hacen que el elemento de software se degrade en algunas situaciones.

• Aprobado: el elemento verificado no tiene errores o tiene errores menores que no

afectan el normal funcionamiento del elemento.

1.6.5.5. Norma IEEE para planes de gestión de la configuración de software -

IEEE STD 828-19987

Este estándar describe una serie de documentos básicos de pruebas de software,

especifica el formato y contenido del documento de pruebas de forma individual

Plan de gestión de configuración software (scmp) • Introducción

• Propósito • Alcance • Definiciones y

acrónimos • Referencias

• Gestión scmp • Identificación de configuración

• Control de configuración

• Auditoria de configuración

• Actividades scmp

• Identificación de configuración





69

• Horario scmp • Recursos scmp • Plan de mantenimiento scmp



Plan de gestión de configuración software (scmp)

La información del SCMP puede ser presentada en cualquier formato, secuencia o

localización, este documento debe tener un título y definir un formato para el

documento.

Introducción. Esta sección incluye: Propósito, Alcance, Definiciones y acrónimos, y

Referencias

Propósito. Está sección detalla el objetivo específico y ámbito particular del scmp.

Alcance: Esta sección describe la aplicación, limitación y antecedentes de desarrollo

del proyecto software e identifica otro software a ser incluido como parte del plan.

Definiciones y acrónimos: Esta sección establece una terminología común entre

todos los usuarios del plan.

Referencias: Esta sección describe los documentos relacionados, estos se identifican

individualmente.

Gestión scmp. Esta sección incluye 3 temas:

• Organización

• Responsables

• Políticas, directivas y procedimientos

Organización: Esta sección identifica los equipos que participan o son responsables

de cualquier actividad en el scmp y las relaciones de equipos.

Responsables: Esta sección asigna responsables para las actividades del scm.

70

Políticas, directivas y procedimientos: Esta sección describe las restricciones

externas del plan.

Actividades scmp

Esta sección incluye:

• Identificación de configuración



Identificación de configuración

Esta sección identifica el nombre y describe las características físicas y funcionales

de la documentación en sus respectivas fases del ciclo de vida del software, los

elementos de configuración a ser controlados se identifican en los ítems de

configuración (ci) y la estructura de cada línea base, tiene la versión y descripción de

cada elemento.

Control de configuración

Esta sección identifica y documenta los cambios de las líneas bases de los ítems de

configuración, los cambios incluyen documentación para realizar el cambio, análisis

y valuación de la petición de cambio, aprobación o desaprobación de la petición,

verificación, implementación y realización del cambio.

Auditoria de configuración: Esta sección describe e identifica las revisiones a ser

aplicadas en el proyecto y define el objetivo, horario, procedimiento, participantes,

registro de acciones correctivas y aprobación.

Horario scmp: Esta sección establece la secuencia y coordinación de la información

para identificar las actividades del scmp y para todos los programas afectados en este

plan, este horario incluye la duración del plan y puede ser representado en un gráfico

o comunicar está información.

Recursos scmp: Esta sección identifica las herramientas, técnicas, equipos, personal

y necesidades de capacitación para implementar el scmp.

71

Plan de mantenimiento scmp Esta sección identifica las actividades y responsables

para asegurar el scmp durante el ciclo de vida del software, está documentación debe

ser revisada al inicio de cada fase con los cambios y aprobaciones.8

1.6.5.6. Estándar iEEE para la documentación de pruebas de software - IEEE

STD 829-1998

Este estándar describe una serie de documentos básicos de pruebas de software,

especifica el formato y contenido del documento de pruebas de forma individual.

Plan de pruebas

• Propósito

• Identificación del plan de pruebas • Introducción • Ítems de pruebas • Características a ser probadas • Características a no ser probadas • Aproximación • Criterio de ítem pasa/falla • Criterios de suspensión y requisitos

de reanudación • Pruebas a entregar • Tareas de pruebas • Necesidades del entorno • Responsabilidades • Necesidades del personal y

capacitación • Horarios • Riesgos y contingencias • Aprobación

Registro de pruebas

• Propósito • Identificador de registro de pruebas • Descripción • Actividades y entradas de sucesos



Plan de pruebas 8IEEESTANDARDSASSOCIATION, “829-1998 - IEEE Recommended practice for Software Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html


72

Propósito. Esta sección describe el alcance, ámbito, recursos, horario de actividades,

responsable para cada tarea y el riesgo asociado con este plan.

Identificación del plan de pruebas. Esta sección asigna el identificador al plan.

Introducción. Esta sección describe las características a ser probadas y la referencia

de los siguientes documentos: autorización de proyecto, plan de proyecto, plan de

aseguramiento de calidad, plan de gestión de configuración y estándares si estos

existen.

Ítems de pruebas. Esta sección específica las características de los requisitos lógicos

o físicos antes de probar, el nivel, versión y revisión del ítems de pruebas. La

siguiente documentación es de referencia en caso de que exista: especificación de

requerimientos, especificación de diseño, guía del usuario, guía de operación y guía

de instalación del software.

Características a ser probadas. Esta sección identifica todas las características y

combinaciones del software a ser probadas.

Características a no ser probadas. Esta sección identifica todas las características y

combinaciones del software que no serán probadas y sus razones.

Aproximación. Esta sección específica las actividades principales, técnicas y

herramientas que se utilizan para probar las características. La aproximación debe ser

descrita para identificar las tareas principales y estimar el tiempo requerido.

Criterio de ítem pasa / falla. Esta sección específica el criterio a ser utilizado para

determinar cada ítem que pasa o falla en la prueba.

Criterios de suspensión y requisitos de reanudación. Esta sección específica el

criterio utilizado para suspender todo o una parte de las actividades de prueba, está

actividad debe repetirse cuando la prueba es resumida.

73

Pruebas a entregar. Esta sección incluye los siguientes documentos: plan de

prueba, especificaciones de diseño de prueba, especificaciones de caso de prueba,

especificaciones de procedimiento de prueba, reportes de transmisión de ítems de

prueba, registro de pruebas, reportes de incidentes de pruebas, reportes de pruebas.

Tareas de pruebas. Esta sección identifica todas las dependencias de tareas internas

y la capacitación requerida.

Necesidades del entorno. Esta sección describe las características físicas y de

comunicaciones, sistema de software, nivel de seguridad y herramientas.

Responsabilidades. Esta sección identifica los grupos responsables de administrar,

diseñar, preparar, ejecutar y revisar las pruebas.

Necesidades del personal y capacitación

Esta sección específica las pruebas al personal por nivel de habilidades e identifica

las opciones de capacitación.

Horarios. Esta sección describe los horarios del proyecto y estima el tiempo

requerido para hacer cada tarea.

Riesgos y contingencias. Esta sección describe las suposiciones de alto riesgo del

plan, especifica los planes de contingencia que requieren horarios que cumplan con

la fecha de entrega.

Aprobación. Esta sección específica los nombres y títulos de todas las personas que

aprobaran el plan. Provee espacio para las firmas y fechas.

Registro de pruebas

Propósito. Esta sección describe la ejecución de las pruebas.

Identificador de registro de pruebas

74

Esta sección asigna el identificador al plan.

Descripción. Esta sección identifica los términos que van hacer probados y los

atributos del entorno, para ejecutar las pruebas.

Actividades y entradas de sucesos. Esta sección registra las fechas de incidencias,

tiempo y responsable.

1.6.5.7. IEEE practica recomendada para pruebas unitarias de software. IEEE

STD 1008 - 1987 (r 2003)9

Esta norma describe un método sólido para las pruebas de software de la unidad, y

los conceptos y supuestos en que se basa. También proporciona orientación e

información de recursos.

Plan de

pruebas

unitarias

Fase de perfeccionamiento

del plan de pruebas

• Aproximación general del plan, recursos y

horarios

• Características a ser probadas

• Desarrollo del plan general

Fase de adquisición:

conjunto de pruebas

• Diseñar el conjunto de pruebas

• Ejecutar el desarrollo del plan y diseño

Fase de medida: pruebas

unitarias

• Ejecutar los procedimientos de pruebas

• Verificar la terminación

• Evaluar el esfuerzo de las pruebas

unitarias



Plan de pruebas unitarias 9IEEESTANDARDSASSOCIATION, “1008-1998 - IEEE Recommended practice for Software Requirements Specifications”,http://standards.ieee.org/findstds/standard/830-1998.html


75

Fase de perfeccionamiento del plan de pruebas

Aproximación general del plan, recursos y horarios. El plan de pruebas unitarias

debe empezarse a realizar cuando se inicie el plan de pruebas de software, ya que

este documento se adjunta al plan general.

Entradas del plan

• Proyecto del plan

• Documentación de los requisitos del software

Tareas del plan

• Especificar una aproximación del plan de pruebas unitarias.

• Especificar las características a ser probadas que serán cubiertas por el plan, cada

tabla debe tener un caso de prueba unitaria.

• Especificar los requerimientos que satisfaga la prueba para que termine esta.

• Determinar los recursos que se requiere para ejecutar las pruebas unitarias

considerando: hardware, comunicaciones, software, herramientas.

• Especificar un horario para las actividades de las pruebas unitarias.

Salidas del plan

Información del plan de pruebas unitarias requisitos generales para las pruebas

unitarias

Características a ser probadas

Determinar entradas

• Documentación de requisitos de unidad

• Documentación de diseño de arquitectura del software

Determinar tareas

• Describir los requisitos para asegurar que estos son únicos.

76

• Identificar los requisitos y procedimientos adicionales que pueden ser

probados en este tipo de prueba.

• Identificar datos de entrada y salida.

• Describir los datos válidos y no válidos para realizar la prueba.

Determinar salidas

• Lista de elementos a ser incluidos en la prueba.

• Clasificar los requisitos.

Desarrollo del plan general

Desarrollar las entradas

• Lista de elementos a incluirse en la prueba.

• Información del plan de pruebas unitarias.

Desarrollo de tareas

• Identificar los casos de prueba existente.

• Identificar los recursos para ejecutar las pruebas unitarias.

• Especificar el horario para las pruebas

Desarrollo de salidas

• Información específica del plan de pruebas unitarias.

• Especificación de los recursos para las pruebas

Fase de adquisición: conjunto de pruebas

Diseñar el conjunto de pruebas

Diseñar las entradas

• Documentación de requerimientos.

• Lista de elementos a ser incluidos en las pruebas.

• Información del plan de pruebas unitarias

• Documentación del diseño

77

• Especificación de pruebas para pruebas previas.

Diseñar las tareas

• Diseñar la arquitectura para las pruebas, basadas en las características a ser

probadas.

• Poner los casos de pruebas, puede estar de acuerdo a la información del

estándar IEEE 829 o especificadas en una sección suplementaria.

Diseñar las salidas

• Especificación del diseño de las pruebas unitarias.

• Especificaciones de pruebas separadas.

• Especificaciones de casos de pruebas separadas.

Ejecutar el desarrollo del plan y diseño

Ejecutar entradas

• Información del plan de pruebas unitarias

• Documentación de especificaciones de los casos y diseño de pruebas unitarias

• Descripción de los datos

• Recursos para las pruebas

• Ítems de pruebas

• Herramientas de pruebas

Ejecutar tareas

• Obtener y verificar los datos de pruebas, incluir datos adicionales necesarios

para asegurar la consistencia y la integridad.

• Obtener los recursos.

• Obtener los ítems de pruebas para asegurar la ejecución y la satisfacción de la

prueba.

Ejecutar salidas

• Verificar los datos de las pruebas

78

• Configuración de los ítems de pruebas

• Información de pruebas

Fase de medida: pruebas unitarias

Ejecutar los procedimientos de pruebas

Ejecutar entradas

• Verificar los datos de prueba.

• Recursos de las pruebas

• Configuración de ítems de prueba

• Especificación de los casos de pruebas

Ejecutar tareas

• Ejecutar las pruebas

• Determinar los resultados

Ejecutar salidas

• Registrar la información de la ejecución de las pruebas en él se incluirá el

ingreso de prueba, descripciones de la prueba, incidentes, resultados de

análisis de fracaso de la prueba, etc.

• Especificación y datos de las pruebas revisadas.

Verificar las entradas

• Terminación de los requisitos.

• Información de la ejecución.

Verificar las tareas

• Información de la ejecución.

• Evaluar las pruebas de unidad

• Si es necesario realizar las pruebas suplementarias o cuando las pruebas no

son satisfactorias, suplementar con las pruebas de serie como son:

• Actualizar las pruebas arquitectónicas y aumentar los casos de pruebas

79

• Modificar las especificaciones de los procedimientos de pruebas

• Obtener los datos de las pruebas

• Ejecutar las pruebas adicionales

Verificar las salidas

• Revisar la información registrada de las pruebas y los casos adicionales de

pruebas

• Verificar los datos de pruebas adicionales si se ha producido

Evaluar el esfuerzo de las pruebas unitarias

Evaluar las entradas

• Especificación del diseño de pruebas unitarias

• Información de ejecución

• Información de revisión

Evaluar las tareas

• Describir el estado de las pruebas, identificar incidentes de pruebas no

resueltas y las razones para la falta de resolución

• Evaluar el diseño e implementación en contra de los requerimientos pasados

sobre los resultados de prueba

Evaluar las salidas

• Completar reporte de resumen de pruebas

Calidad en el sistema web.

Según PIATTINI Mario (2004), con la aparición de la web se observa un cambio

significativo en la manera de especificar y construir software que dificulta mucho

más la estimación de proyectos. El alcance y la complejidad de estas aplicaciones

varían extensamente y pueden abarcar desde servicios de escala reducida hasta

aplicaciones empresariales La evolución de las aplicaciones web, también implica el

80

aumento de la complejidad en diseñar, desarrollar, mantener y manejar estos sistemas

de información.

Para PANTALEO Guillermo (2011), la calidad del software puede ser entendida

como el grado en el cual el usuario percibe que el software satisface sus expectativas.

El tipo y número de actividades de garantía de calidad que es necesario adaptar en

una organización depende mucho del tamaño y complejidad de los productos

software que se estén desarrollando. Actualmente se han publicado una serie de guías

de estilos y criterios que ayudan a mejorar el diseño y autoría de las aplicaciones

web.

PIATTINI Mario (2004) afirma que así como en el software tradicional las

propiedades de los productos web deben ser estructuradas de manera sistemática

para permitir la medición y evaluación de la calidad. La calidad en uso es la visión

del usuario en la calidad que contiene un producto y que se mide en términos de los

resultados del uso del software, más que las propiedades del propio software. La

usabilidad es un factor necesario para el éxito de una aplicación web, pero no es

necesario desarrollar una aplicación usable para que tenga éxito. El triunfo o fracaso

de un proyecto dependerá de la experiencia del usuario.

Una de las métricas más usadas en el ambiente web es l OOmFP que sirve para la

medición del tamaño funcional del sistema web. El método OOmFP ofrece un

entorno de generación automática de código basado en modelos conceptuales.

Existen dos métricas según los autores anteriores que determinan la calidad de un

software en general, estas son:

• Porcentaje de código repetido en el software:

• Complejidad ciclomática

81

CAPITULO II

MARCO METODOLÓGICO Y PLANTEAMIENTO DE LA PROPUESTA

2.1. La Empresa

La empresa “J-M Sotware Developer”, nace de la iniciativa de su gerente-

propietario, como una manera práctica de aplicar los conocimientos adquiridos

durante su vida estudiantil, viendo al desarrollo de software como un medio

diferente de generar ingresos y de hacer empresa. Se inicia con la elaboración de

pequeños programas orientados generalmente al ámbito comercial y usualmente

para utilización en empresas de familiares.

Su filosofía de trabajo se resume en lo siguiente:

Misión: Elaborar software de calidad, utilizando las mejores técnicas y plantillas

para que nuestras clientes se sienta satisfechos.

Visión: Posicionarnos como una de las mejores empresas de la provincia y una de

las más importantes del país dedicada a la elaboración de software con estándares de

calidad a nivel internacional.

2.2. Diseño Metodológico.

La modalidad investigativa que se ha utilizado en esta tesis es la denominada cuali-

cuantitativa. La investigación cualitativa es el procedimiento metodológico que se

caracteriza por utilizar palabras, textos, discursos, dibujos, gráficos e imágenes para

comprender la vida social por medio de significados y desde una perspectiva

holística, pues se trata de entender el conjunto de cualidades interrelacionadas que

caracterizan a un determinado fenómeno y se la aplico para determinar los objetos

cualitativos del problema como el mal servicio, eficiencia y más.

La investigación cuantitativa se caracteriza por recoger, procesar y analizar datos

cuantitativos o numéricos sobre variables previamente determinadas. Esto ya hace

darle una connotación que va más allá de un mero listado de datos organizados como

82

resultado; pues estos datos que se muestran en el informe final, están en total

consonancia con las variables que se declararon desde el principio y los resultados

obtenidos van a brindar una realidad específica a la que estos están sujetos. Dicha

metodología se la aplico para determinar estadísticamente los síntomas de la

problemática.

Los tipos de investigación aplicados son:

• Bibliográfica: Este tipo de investigación se la desarrolla en base a la recopilación

de la información de fuentes primarias, se la utilizó para desarrollar el marco

teórico orientado esencialmente a ingeniería del software y normas ISO

• De Campo: se la lleva a cabo en base a encuestas o entrevistas y se la aplico para

desarrollar el marco metodológico. Se entrevistó a los desarrolladores de la

empresa así como a clientes de la misma

La población involucrada en la problemática descrita en el inicio de este trabajo

investigativo está estructurada de la siguiente forma:

Función Número

Gerente de la empresa 1

Desarrolladores 5

Clientes 25

TOTAL 31

Tabla 1 Población involucrada en la problemática.

Se define como la muestra, a un porcentaje de la población, pero en este caso como

la población es muy pequeña la misma se convierte en la muestra.

Las técnicas de investigación aplicadas fueron: Entrevista al gerente y encuestas a

desarrolladores y clientes

83

Los instrumentos utilizados fueron: Cuestionarios específicos para clientes y

desarrolladores, así como también guía de entrevista para el gerente.

Luego de realizada la investigación de campo se procedió a tabular los resultados de

las encuestas, los cuales se detallan a continuación.

Resultados de la encuesta realizada a los clientes de la empresa

Pregunta # 1. ¿Considera usted muy importante la combinación de colores que se

tenga en un programa cualquiera?

Si………….. No…………

Tabla 2 Resultados obtenidos pregunta 1.

Gráfico 1 Ilustración gráfica pregunta 1.

Para la gran mayoría es muy importante la combinación de colores en el software

que utilizan o que pueden apreciar

No 19%

Si 81%

Respuesta Frecuencia Porcentaje No 11 19% Si 47 81%

Total 58 100%

84

Pregunta # 2. ¿Considera primordial la rapidez con la que se cargue un

software en su máquina?

Si………….. No…………


Para la gran mayoría de los investigados la rapidez con la que se cargue un software

es muy importante

No 22%

Si 78%

Respuesta Frecuencia Porcentaje

No 13 22%

Si 45 78%

Total 58 100%


85

Pregunta # 3. ¿Cree usted que el uso de un software acelera los procesos operativos

de una empresa?

Si………. No………..


Si 53 91%

No 5 9%

Total 58 100%



Casi la totalidad de los clientes investigados señalan que el uso de un software

permite la aceleración de los procesos operativos de una empresa

Si 91%

No 9%

86

Pregunta # 4. ¿Considera usted que los programas que usted usa en su empresa son

totalmente seguros?

Si………. No……


La gran mayoría considera que los programas que utilizan en sus empresas tienen las

seguridades necesarias

Si 71%

No 29%


Si 41 71%

No 17 29%

Total 58 100%


87

Pregunta # 5. ¿Considera usted que las empresas o personas que desarrollan

software en el Ecuador deben elevar la calidad del mismo?

Si…………… No…………


Si 55 95%

No 3 5%

Total 58 100%



Para casi la totalidad de los investigados los desarrolladores de software deben elevar

la calidad de los programas que hacen.

Si 95%

No 5%

88

Pregunta # 6. ¿Cree usted que el desarrollo de software es una actividad muy

lucrativa en el Ecuador?

Si………. No………….


Si 41 71%

No 17 29%

Total 58 100%



Un elevado porcentaje de usuarios creen que el desarrollo de software se ha

convertido en una actividad bastante lucrativa

Si 71%

No 29%

89

Resultados de la encuesta realizada a los desarrolladores

Pregunta # 1. ¿Cree usted que la actividad de desarrollo de software es una actividad

muy lucrativa?

Si………… No…….. Un poco……..


Si 5 50%

No 2 20%

Un poco 3 30%

Total 10 100%



Para la mitad de los investigados la actividad del desarrollo de software esta entre

poco y nada lucrativa.

No 20%

Si 50%

Un poco 30%

90

Pregunta # 2. ¿Cree usted que el software producido en el Ecuador es competitivo a

nivel internacional?

Si………….. No…………


La gran mayoría de los desarrolladores manifiesta que el software producido a nivel

nacional no es competitivo para el ámbito internacional.

Si 20%

No 80%


Si 2 20%

No 8 80%

Total 10 100%


91

Pregunta # 3. ¿Considera usted que le falta calidad al software producido a nivel de

la empresa J-M Software Developer®?

Si………. No………..


Los desarrolladores manifiestan que le falta calidad al software producido por la

empresa

Si 90%

No 10%


Si 9 90%

No 1 10%

Total 10 100%


92

Pregunta # 4. ¿Considera usted que se desconoce de las normas internacionales que

definen la calidad de un software?

Si………. No……..…


La gran mayoría concuerda en que se desconocen las normas internacionales que

definen la calidad de un programa o software

Si 70%

No 30%


Si 7 70%

No 3 30%

Total 10 100%


93

Pregunta # 5. ¿Cree usted que debería estructurarse un conjunto de métricas o

parámetros para que nos ayuden a elevar la calidad del software desarrollado en la

empresa?

Si…………… No…………


Si 9 90%

No 1 10%

Total 10 100%



Casi la totalidad de los investigados señala que debería estructurarse un conjunto de

métricas para definir la calidad de un software desarrollado en la empresa

Si 90%

No 10%

94

Pregunta # 6. ¿Considera usted que la seguridad que tenga un software, eleva su

calidad significativamente?

Si………. No………….


Si 6 60%

No 4 40%

Total 10 100%



La mayoría ratifica que la seguridad de un software para controlar el acceso y sus

datos eleva la calidad del mismo ante el usuario

Si 70%

No 30%

95

Entrevista realizada al gerente de la empresa.

Pregunta N° 1. ¿Cree usted que la actividad de desarrollo de software es una

actividad muy lucrativa?

Bueno, la cultura general de la gente está orientada a la copia de los sistemas, razón

por la cual muchas empresas no invierten en ellos, pero las políticas gubernamentales

están incidiendo en que se deben cumplir estrictamente normas como el pago de

impuesto y transacciones electrónicas entonces se está acrecentando la demanda de

software a medida haciendo que este sea más remunerativo.

Pregunta N° 2. ¿Considera usted que el software desarrollado por el empresa es

competitivo a nivel internacional?

A nivel regional creo que nuestro software si es competitivo, pero para el ámbito

internacional no, tenemos muchas deficiencias en cuanto al desconocimiento de

normas internacionales que definen la calidad de un software a nivel internacional.

Pregunta N° 3. ¿A nivel interno de la empresa, se tiene algún conjunto de

métricas que define la calidad del software desarrollado?

Lamentablemente no tenemos estructurado un conjunto de parámetros que nos

permitan evaluar la calidad de cada proceso de desarrollo de software, normalmente

tratamos de que el software tenga seguridad y fiabilidad de los datos.

Pregunta N° 4. ¿Considera usted que sería beneficioso para la empresa disponer

de un conjunto de métricas para mejorar la calidad del software desarrollado?

Sería muy importante cumplir con los parámetros requeridos en un estándar de

calidad internacional para elevar la calidad de cada proceso de elaboración de un

software para que este al final disponga de una mayor calidad y sea competitivo

incluso a nivel internacional

96

2.3 Conclusiones parciales del capitulo

• Para los usuarios los parámetros de calidad de un software están dados

esencialmente por la presentación, por la rapidez de carga y por la seguridad que

brinde el mismo.

• Se considera que existe un desconocimiento general entre los desarrolladores con

respecto al uso de normas o parámetros internacionales para elevar la calidad de

un software desarrollado.

• La empresa J-M Software Developers® no tiene definido controles o métricas

relacionadas a la calidad de un software, por lo que este a lo mejor es competitivo

localmente pero no a nivel nacional y peor aún a nivel internacional.

• La actividad relacionada al desarrollo de software, está siendo impulsada por

nuevas políticas estatales ya que se está cambiando la cultura de la gente con

relación al respeto que se debe tener para los derechos de autor.

• Se cree que para la empresa “J-M Software Developers®” será muy importante

disponer de un conjunto de métricas que definan y sobre todo eleven la calidad

de un software desarrollado en ella

97

CAPITULO III

DESARROLLO DE LA PROPUESTA

3.1 Tema: Métricas de calidad y el desarrollo de software competitivo en la empresa

J-M Software Developer® de la ciudad de Ambato

3.2 Descripción de la propuesta

La propuesta de solución al problema planteado en la introducción del presente

trabajo investigativo, consiste en seleccionar un grupo de métricas adecuadas para la

empresa y desarrollar un portal web aplicándolas, se espera que la aplicación web

resultante disponga de la calidad requerida para competir con productos similares

desarrollados por empresas similares a nivel nacional o internacional

3.3 Desarrollo de la Propuesta

De manera general se define a un producto como el resultado de un proceso, siendo

el proceso la realización de varias actividades tendientes a lograr un objetivo. De la

experiencia y de la teoría de proyectos se conoce que el desarrollo de un proceso

involucra recursos materiales, económicos y humanos. En el caso de la ingeniería del

software, estos conceptos son plenamente aplicados y se puede entender como

producto al software y como proceso a todas las fases de su elaboración.

Se entiende como métrica una medida del grado en que un sistema, componente o

producto posee un atributo dado. El mayor o menor número de atributos que

contenga un producto y que satisfagan los requerimientos de los clientes, determinan

la calidad del mismo. En la mayoría de casos las métricas nos ayudan a entender el

proceso técnico que se desarrolla para elaborar un producto, el proceso para intentar

mejorarlo. El producto se mide para mejorar su calidad.

Para la presente propuesta se ha tomado como base el modelo de calidad de un

producto de software establecido por el estándar ISO 9126, este modelo señala que

98

todos los componentes de calidad del mismo están inmersos en 6 factores

fundamentales con sus categorías respectivas que son:

– Funcionabilidad

o Adecuación

o Exactitud

o Interoperabilidad

o Conformidad

o Seguridad

– Confiabilidad

o Madurez

o Tolerancia a fallos

o Recuperación

– Usabilidad

o Comprensibilidad

o Facilidad de aprender

o Operabilidad

– Eficiencia

o Tiempo de respuesta

o Uso de recursos

– Mantenibilidad

o Capacidad de análisis

o Capacidad de modificación

o Estabilidad

o Facilidad de prueba

– Portabilidad

o Adaptabilidad

o Facilidad de instalación

o Conformidad

o Capacidad de reemplazo

99

3.3.1 Métrica propuesta para evaluar la calidad del software Es comprensible el hecho de que desarrollar medidas directas de la calidad de un

software es algo bastante complejo y subjetivo, es por ello la razón de ser del

presente trabajo investigativo, como parte medular del mismo se propone la siguiente

fórmula para dicha evaluación.

Fc= c1 * m1 + c2 * m2 + … + cn * mn

Cada factor de calidad Fc se puede obtener como combinación de una o varias

métricas.

Ci. Es el factor de ponderación de la métrica i, que dependerá de cada aplicación

específica, este factor esta dado en porcentaje y representa la importancia del proceso

en el desarrollo o ejecución de la aplicación

Mi. Es la métrica que se puntúa de 0 a 100

Cada parámetro de medición puede tener su propia valoración, eso dependerá del

usuario, para el presente caso se consideran diversos valores por parámetro, la suma

de esos valores debe dar 100 puntos, si el software cumple por lo menos el 60% de lo

requerido se lo puede calificar como un software de calidad que cumple estándares

internacionales.

Igualmente la ponderación queda a criterio de cada caso, aunque en este trabajo se lo

valora específicamente para cada tributo

100

3.3.1.1 Métricas para determinar el factor de calidad

Característica a ser evaluada

FUNCIONABILIDAD Las funciones y propiedades satisfacen las necesidades implícitas y explicitas?

Subcaracteristica Descripción Métrica %

Adecuación Efectúa las tareas especificadas en su definición 0-100 4

Exactitud Resultados acordes a las necesidades 0-100 3

Interoperabilidad Interacción con otros programas especificados previamente 0-100 3

Conformidad Software se adhiere a leyes y prescripciones similares 0-100 4

Seguridad Control adecuado de accesos indebidos 0-100 6


CONFIABILIDAD Puede mantener el nivel de rendimiento bajo ciertas condiciones y determinado tiempo?


Madurez Medida de la frecuencia de fallas por errores 0-100 5

Tolerancia a fallos Habilidad para mantener un nivel especifico de funcionamiento a pesar de existir una falla

0-100 5

Recuperación Recuperación del nivel de operación y de los datos 0-100 5


USABILIDAD El software es fácil de usar y de aprender?


Comprensibilidad El usuario comprende fácilmente su funcionamiento 0-100 10

Facilidad de aprender El usuario puede aprender rápidamente su manejo 0-100 8

Operabilidad Puede ser operado y controlado fácilmente 0-100 12

101


EFICIENCIA Es rápido y mínimo el uso de recursos?


Tiempo de respuesta Celeridad de procesamiento 0-100 6

Uso de recursos Exigencia y uso de recursos 0-100 4

Característica a ser evaluada?

MANTENIBILIDAD Es fácil de modificar y verificar?


Capacidad de análisis Permite identificar las partes a modificar 0-100 3

Capacidad de modificación Se puede modificar fácilmente 0-100 3

Estabilidad Se pueden evaluar riesgos a efectos inesperados por modificaciones 0-100 2

Factibilidad de prueba SE puede validar el software luego de ser modificado 0-100 2


PORTABILIDAD Es fácil de transferir de un ambiente a otro?


Adaptabilidad Se puede adaptar fácilmente a entornos diferentes de trabajo

0-100 4

Facilidad de instalación Es fácil de instalar 0-100 4

Conformidad Tiene estándares de portabilidad 0-100 3

Capacidad de reemplazo

Puede ser fácilmente reemplazado por otro producto 0-100 4

102

3.3.2Aplicación de la métrica. Caso práctico.

Como parte complementaria de la propuesta se ha desarrollado una parte de un

software y se lo ha sometido a una evaluación con la métrica propuesta.

Primeramente con fines ilustrativos se muestran varias de las partes de esta

aplicación web publicada en Internet y luego la sometemos a la métrica propuesta

para obtener un criterio sobre la calidad del mismo.

El presente software es un portal web para hacer comercio electrónico, está instalado

en Internet y posee el dominio http://asaderotungurahua.com.

http://asaderotungurahua.com/

104

El software ha sido evaluado con las métricas propuestas y a criterio del realizador,

estos son los resultados.


FUNCIONABILIDAD Las funciones y propiedades satisfacen las necesidades implícitas y explicitas?


Adecuación Efectúa las tareas especificadas en su definición 50 4

Exactitud Resultados acordes a las necesidades 40 3

Interoperabilidad Interacción con otros programas especificados previamente 70 3

Conformidad Software se adhiere a leyes y prescripciones similares 60 4

Seguridad Control adecuado de accesos indebidos 60 6

El primer factor quedaría aplicando la formula. F1 = m1*p1 + m2*p2 + m3*p3 + m3* p4 Reemplazando valores tenemos F1 = 50*0,04 + 40*0,03 + 70*0,03 + 60*0,04 + 60*0,06 F1 = 2 + 1,2 + 2,1 + 2,4 + 3,6 F1 = 11,3.

105


CONFIABILIDAD Puede mantener el nivel de rendimiento bajo ciertas condiciones y determinado tiempo?


Madurez Medida de la frecuencia de fallas por errores 80 5

Tolerancia a fallos Habilidad para mantener un nivel especifico de funcionamiento a pesar de existir una falla

70 5

Recuperación Recuperación del nivel de operación y de los datos 80 5

El segundo factor quedaría aplicando la formula. F2 = m1*p1 + m2*p2 + m3*p3 Reemplazando valores tenemos F2 = 80*0,05 + 70*0,05 + 80*0,05 F2 = 4 + 3,5 + 4,0 F2 = 11,5


USABILIDAD El software es fácil de usar y de aprender?

Su característica Descripción Métrica %

Comprensibilidad El usuario comprende fácilmente su funcionamiento 90 10

Facilidad de aprender El usuario puede aprender rápidamente su manejo 92 8

Operabilidad Puede ser operado y controlado fácilmente 95 12

El tercer factor quedaría aplicando la formula. F3 = m1*p1 + m2*p2 + m3*p3 Reemplazando valores tenemos

106

F3 = 90*0,1 + 92*0,08 + 95*0,12 F3 = 9 +7,36 + 11,4 F3 = 27,76


EFICIENCIA Es rápido y mínimo el uso de recursos?


Tiempo de respuesta Celeridad de procesamiento 82 6

Uso de recursos Exigencia y uso de recursos 85 4

El cuarto factor quedaría aplicando la formula. F4 = m1*p1 + m2*p2 Reemplazando valores tenemos F4 = 82*0,06 + 92*0,04 F4 = 4,92 +3,68 F4 = 8,6

Característica a ser evaluada?

MANTENIBILIDAD Es fácil de modificar y verificar?


Capacidad de análisis Permite identificar las partes a modificar 30 3

Capacidad de modificación Se puede modificar fácilmente 50 3

Estabilidad Se pueden evaluar riesgos a efectos inesperados por modificaciones 75 2

Factibilidad de prueba SE puede validar el software luego de ser modificado 75 2

El quinto factor quedaría aplicando la formula. F5 = m1*p1 + m2*p2 + m3*p3 + m4*p4

107

Reemplazando valores tenemos F4 = 30*0,03 + 50*0,03+75*0,02 + 75*0,02 F4 = 4,92 +3,68 F4 = 8,6


PORTABILIDAD Es fácil de transferir de un ambiente a otro?


Adaptabilidad Se puede adaptar fácilmente a entornos diferentes de trabajo

90 4

Facilidad de instalación Es fácil de instalar 80 4

Conformidad Tiene estándares de portabilidad 80 3

Capacidad de reemplazo

Puede ser fácilmente reemplazado por otro producto 70 4

El sexto factor quedaría aplicando la formula. F6 = m1*p1 + m2*p2 + m3*p3 + m4*p4 Reemplazando valores tenemos F6 = 90*0,04 + 80*0,04 + 80*0,03 + 70*0,04 F6 = 4,92 +3,68 F6 = 12 Para obtener el factor total se suma cada parámetro FC = F1+F2+F3+F4+F5+F6 FC= 11, 3 + 11, 5 + 27, 76 + 8, 6 + 8, 6 + 12

F9 = 79.76 Como el factor de calidad es superior a 70 se asume que el mismo tiene los

parámetros y normas de calidad para ser aceptado en el ámbito nacional e

108

internacional, es decir en definitiva la aplicación tiene estándares de calidad bastante

aceptable.

3.4 Conclusiones parciales del capitulo

El desarrollo de la propuesta en el presente trabajo investigativo ha generado las

siguientes conclusiones:

– La construcción de un conjunto de métricas que determinen la calidad de un

software implican una serie de conocimientos relacionados con el campo de la

calidad en general. El modelo propuesto se base en un estándar ISO que define la

mayor o menor calidad de un producto, en este caso el producto es un software.

– Se ha trabajado sobre el criterio de evaluar el producto, mas no se ha tratado de

evaluar los procesos de desarrollo, porque eso implicaría definir un rango mayor

de métricas que obviamente saldrían del enfoque original del presente trabajo.

– Existen diversos modelos relacionados con la construcción de métricas

relacionadas a la calidad del desarrollo y a la calidad del software en genera, se

ha considerado que la evaluación del producto era el objetivo fundamental y por

ende se trabajó en base a ello.

– Las métricas son muy variables en dos aspectos: el valor asignado a un atributo y

el peso de influencia en la calidad del mismo, esto significa que cada de ellas es

fácilmente adaptable al criterio que quiera darle cualquier evaluar de software.

109

CONCLUSIONES Y RECOMENDACIONES

De manera general se pueden emitir las siguientes conclusiones:

– La calidad es un factor muy importante hoy en día, pero también su evaluación es

un proceso bastante subjetivo, eso quiere decir que para unos, ciertos factores

serán más importantes que para otros, lo que hace muy dificultoso la designación

de los niveles de calidad de un software para que este sea competitivo en el

mercado.

– Aunque en el presente trabajo investigativo solo se trabajó en el aspecto de las

métricas relacionadas con la evaluación de la calidad de un software ya

desarrollado, sería interesante que se complemente el presente trabajo con un

conjunto de métricas orientadas a ser aplicadas durante el desarrollo de un

software.

– Existen diferentes modelos y parámetros que determinan la calidad de un

producto software, pero estos van cambiando con el tiempo y con las tendencias

en cuanto al desarrollo de software.

– No existen modelos específicos para la evaluación de productos del tipo

aplicación web, tal vez con el tiempo los factores de calidad propuestos en ciertos

modelos se orienten exclusivamente a los portales web.

– Es importante también concluir que la calidad es un factor que cada día va más

intrínseco en todo proceso de fabricación, incluyen a aquellos productos que son

netamente el resultado del intelecto humano, como es el caso de un software.

110

En base a las conclusiones emitidas, se pueden definir las siguientes

recomendaciones:

– Difundir mucho más los conceptos relacionados con la calidad, entre los

estudiantes de Ingeniería de Sistemas, esto debido a que es un aspecto muy poco

tratado durante el estudio de la materia de Ingeniería del software y

programación.

– También es recomendable el hecho de que los estándares de calidad definidos en

ciertos modelos, se orienten adecuadamente para que sean aplicados durante el

desarrollo de software, especialmente durante la fase de diseño y programación.

– Es recomendable también que los desarrolladores de software dispongan de

conocimientos relacionados con otros procesos de evaluación de la calidad de un

software como es el método TAW (Test de accesibilidad web).

0

BIBLIOGRAFÍA

• PIATINNI Mario- GARCIA Félix, “Calidad en el desarrollo y mantenimiento del

software “, Editorial Alfaomega Ra-ma, 2007, Madrid-España.

• PRESSMAN Roger S. (2003). “Ingeniería del software. Enfoque práctico”,

Editorial Prentice-Hall, Madrid-España.

• SOMMERVILLE Ian, “Ingeniería del Software”, Addison-Wesley, México-

México, 2002.

• BOLAÑOS Daniel-ALMUDENA Alonso, “Pruebas de software y JUnit. Un

análisis en profundidad”, Prentice-Hall, Madrid-España, 2007

• MUÑOZ Carlos (2002) “Auditoria de sistemas computacionales”, Prentice

Hall, México.

• LAUDON Kennet “Sistemas de Información Gerencial”, Prentice – Hall,

Madrid-España, 2004

• D'SOUSA Carmen (2004), “Auditoria de sistemas”, www.monografias.com

• KENDALL & KENDALL “Sistemas de Información”, Prentice-Hall, Madrid-

España, 2005.

LABORATORIOS DE SOFTWARE.

http://www.inti.gov.ar/software/LaCis_sanluis

www.inti.gov.ar.

www.inti.gob.ar

http://www.inti.gov.ar/software/LaCis_sanluis

http://www.inti.gov.ar/

http://www.inti.gob.ar/

1

ANEXOS

Cuestionario para los clientes de la empresa

Pregunta # 1. ¿Es para usted muy importante la combinación de colores que se tenga

en un programa cualquiera?

Si………….. No…………

Pregunta # 2. ¿Considera primordial la rapidez con la que se cargue un

software en su máquina?

Si………….. No…………

Pregunta # 3. ¿Cree usted que el uso de un software acelera los procesos operativos

de una empresa?

Si………. No………..

Pregunta # 4. ¿Considera usted que los programas que usted usa en su empresa son

totalmente seguros?

Si………. No……

Pregunta # 5. ¿Considera usted que las empresas o personas que desarrollan

software en el Ecuador deben elevar la calidad del mismo?

Si…………… No…………

Pregunta # 6. ¿Cree usted que el desarrollo de software es una actividad muy

lucrativa en el Ecuador?

Si………. No………….

2

Cuestionario para los desarrolladores internos y externos de la empresa

Pregunta # 1. ¿Cree usted que la actividad de desarrollo de software es una actividad

muy lucrativa?

Si………… No…….. Un poco……..

Pregunta # 2. ¿Cree usted que el software producido en el Ecuador es competitivo a

nivel internacional?

Si………….. No…………

Pregunta # 3. ¿Considera usted que la falta calidad al software producido a nivel de

la empresa J-M Software Developers®?

Si………. No………..

Pregunta # 4. ¿Considera usted que se desconoce de las normas internacionales que

definen la calidad de un software?

Si………. No……..…

Pregunta # 5. ¿Cree usted que debería estructurarse un conjunto de métricas o

parámetros para que nos ayuden a elevar la calidad del software desarrollado en la

empresa?

Si…………… No…………

Pregunta # 6. ¿Considera usted que la seguridad que tenga un software, eleva su

calidad significativamente?

Si………. No………….

3

Guía de entrevista para el gerente

Entrevista realizada al gerente de la empresa.

Pregunta N° 1. ¿Cree usted que la actividad de desarrollo de software es una

actividad muy lucrativa?

Pregunta N° 2. ¿Considera usted que el software desarrollado por el empresa es

competitivo a nivel internacional?

Pregunta N° 3. ¿A nivel interno de la empresa, se tiene algún conjunto de métricas

que define la calidad del software desarrollado?

Pregunta N° 4. ¿Considera usted que sería beneficioso para la empresa disponer de

un conjunto de métricas para mejorar la calidad del software desarrollado?

universidad regional autÓnoma de los …dspace.uniandes.edu.ec/bitstream/123456789/2825/1/... ·...

Documents