Métricas de calidad y el desarrollo de software competitivo en la empresa J-M software developer de la ciudad de Ambato

(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

(2)

(3)

(4)

DEDICATORIA

(5)

AGRADECIMIENTO

(6)

Í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

(7)

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

(8)

INDICE DE TABLAS

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

Tabla 2 Resultados obtenidos pregunta 1. ... 83

INDICE DE GRÁFICOS Gráfico 1 Ilustración gráfica pregunta 1. ... 83

Gráfico 2 Ilustración gráfica pregunta 2. ... 84

(9)

(10)

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.

(11)

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.

(12)

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.

(13)

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.

(14)

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.

(15)

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.

(16)

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

(17)

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.

(18)

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

(19)

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.

(20)

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.

(21)

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))

(22)

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))

(23)

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

(24)

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))

(25)

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.

(26)

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

(27)

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.

(28)

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.

(29)

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.

(30)

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.

(31)

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.

1

IEEESTANDARDSASSOCIATION, “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

(32)

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.

(33)

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.

(34)

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.

(35)

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

2

(36)

25 A continuación se describirá brevemente cada uno de los pasos que hay que aplicar en este estándar estudiado.

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

3

(37)

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.

A continuación se describirá brevemente cada uno de los pasos que hay que aplicar 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 U suario del Software

• Estructura General del Documento Componentes Iniciales

Contenido de Información del D ocumento del Usuario del Softw are

• 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

(38)

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.

(39)

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:

(40)

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

(41)

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.

(42)

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)

4

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

Plan de Asegura miento de Calid ad 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

(43)

32 A continuación se describirá brevemente cada uno de los pasos que hay que aplicar en este estándar estudiado

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

(44)

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.

(45)

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

5

(46)

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.

A continuación se describirá brevemente cada uno de los pasos que hay que aplicar en este estándar estudiado

Introducción

(47)

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.

(48)

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.

(49)

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