Ingeniería de software

Tarea No. 01
Estándares para proceso de desarrollo de software

Presentado por:
Camilo Esteban Rodriguez
Andres Mauricio Clavijo
Jhon Alexander Chacon
Brayan Andres Valero

Presentado a:
Juan Carlos Guevara

Universidad Distrital Francisco José de Caldas, Facultad Tecnológica

Bogotá D.C 2016
Contenido

Requerimientos ................................................................................................................................... 3
Análisis................................................................................................................................................. 6
Desarrollo .......................................................................................................................................... 11
Pruebas.............................................................................................................................................. 17
Bibliografía ........................................................................................................................................ 24
Requerimientos

IEEE-STD-830-1998: IEEE PRÁCTICA RECOMENDADA PARA LAS

ESPECIFICACIONES DE REQUISITOS DEL SOFTWARE
El estándar IEEE 830-1998 para el SRS(en inglés) o ERS (Especificación de requerimientos
de software) es un conjunto de recomendaciones para la especificación de los requerimiento
o requisitos de software el cuál tiene como producto final la documentación de los acuerdos
entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias
estipuladas.
Las características para una buena especificación de requerimientos según indica la IEEE
son:
 Correcta
 No ambigua
 Completa
 Verificable
 Consistente
 Clasificada
 Modificable
 Explorable
 Utilizable durante las tareas de mantenimiento y uso

Corrección
La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real.
La corrección de la ERS implica que el sistema implementado será el sistema deseado.
Ambigüedad
Un documento es no ambiguo si y solo si cada requisito descrito tiene una única
interpretación. Cada característica del producto final debe ser descrita utilizando un término
único y, en caso de que se utilicen términos similares en distintos contextos, se deben indicar
claramente las diferencias entre ellos. Incluso se puede incluir un glosario en el que indicar
cada significado específicamente.
Los analistas deben poner un cuidado especial a la hora de especificar los requisitos. El hecho
de utilizar el lenguaje natural para hacer la ERS comprensible a los usuarios supone un riesgo
muy elevado, porque el lenguaje natural puede llegar a ser muy ambiguo.

Completitud
Una ERS es completa si:
•Incluye todos los requisitos significativos del software (relacionados con la funcionalidad,
ejecución, diseño, atributos de calidad o interfaces externas).
•Existe una definición de respuestas a todas las posibles entradas, tanto válidas como
inválidas, en todas las posibles situaciones.
•Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe
razonar suficientemente el por qué no se ha utilizado dicho apartado.
•Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los
términos y unidades de medida empleados.La ERS debe ser siempre completa, aunque en
ocasiones esto no será posible.

Verificabilidad
Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso por
el cual una persona o una máquina pueda chequear que el software satisface dicho
requerimiento.

Consistencia
Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son
contradictorios o entran en conflicto. Se pueden dar tres casos:
•Requisitos que describen el mismo objeto real utilizando distintos términos.
•Las características especificadas de objetos reales. Un requisito establece que todas las luces
son verdes y otro que son azules.
•Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un punto en el que
dos acciones serían perfectamente válidas (¿sumar o multiplicar?)

Clasificación
No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por
diversos criterios:
•Importancia: Pueden ser esenciales, condicionales u opcionales.
•Estabilidad: Cambios que pueden afectar al requisito. Lo ideal es el establecimiento de
prioridades, de modo que la implementación de un requisito de menor prioridad no emplee
excesivos recursos.

Modificabilidad
Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y
consistente. Para ello, es deseable tener una organización coherente y fácil de usar en la que
aparezca el índice o una tabla de contenidos fácilmente accesible. También es deseable evitar
la redundancia, es decir que no aparezca un mismo requisito en más de un lugar de la ERS.
No es un error, pero si se tiene que modificar alguna cosa será mucho más cómodo si no
tenemos que buscar el mismo requisito en varios lugares.

Explorabilidad (traceability)
Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen
que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema
que realizan dicho requisito).
Cuando un requisito de la ERS representa un desglose o una derivación de otro requisito, se
debe facilitar tanto las referencias hacia atrás como hacia adelante en el ciclo de vida. Las
referencias hacia delante de la ERS son especialmente importantes para el mantenimiento del
software. Cuando el código y los documentos son modificados, es esencial poder comparar
el conjunto total de requisitos que puedan verse afectados por estas modificaciones.

Utilizable durante las tareas de mantenimiento y uso

En la ERS también se deben tener en cuenta las necesidades de mantenimiento. El personal
que no ha intervenido directamente en el desarrollo debe ser capaz de encargarse de su
mantenimiento. Así, dicha ERS actúa a modo de plano de la aplicación, permitiendo incluso
modificaciones que no requieran un cambio en el diseño
En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal que se
encargue del mantenimiento no tiene por qué tener. Por esta razón es necesaria una correcta
documentación de las funciones, ya que si no se conoce en detalle su origen, difícilmente
podrán ser modifica
Esquema de ERS definida en IEEE 830-1998

Análisis

Estándar ISO/IEEE 12207.

Es el estándar para los procesos de ciclo de vida del software de la organización ISO, donde
se realiza un enfoque en el análisis del software.

Establece un proceso de ciclo de vida para el software que incluye procesos y actividades
que se aplican desde la definición de requisitos, pasando por la adquisición y configuración
de los servicios del sistema, hasta la finalización de su uso. Este estándar tiene como objetivo
principal proporcionar una estructura común para que compradores, proveedores,
desarrolladores, personal de mantenimiento, operadores, gestores y técnicos involucrados en
el desarrollo de software usen un lenguaje común. Este lenguaje común se establece en forma
de procesos bien definidos.

Los procesos se clasifican en tres tipos: Principales, de soporte y de la organización. Los

procesos de soporte y de organización deben existir independientemente de la organización
y del proyecto ejecutado. Los procesos principales se instancian de acuerdo con la situación
particular.

§ Procesos principales.

§ Adquisición.

§ Suministro.

§ Desarrollo.

§ Operación.

§ Mantenimiento.

§ Procesos de soporte.

§ Documentación

§ Gestión de la configuración.

§ Aseguramiento de calidad.

§ Verificación.

§ Validación.

§ Revisión conjunta.

§ Auditoría.

§ Resolución de problemas.

§ Procesos de la organización.
§ Gestión.

§ Infraestructura.

§ Mejora.

§ Recursos Humanos.

La estructura del estándar ha sido concebida de manera que pueda ser adaptada a las
necesidades de cualquiera que lo use. Para conseguirlo, el estándar se basa en dos principios
fundamentales: Modularidad y responsabilidad. Con la modularidad se pretende conseguir
procesos con un mínimo acoplamiento y una máxima cohesión. En cuanto a la
responsabilidad, se busca establecer un responsable para cada proceso, facilitando la
aplicación del estándar en proyectos en los que pueden existir distintas personas u
organizaciones involucradas, no importando el uso que se le dé a este.

ISO 9126 es un estándar internacional para la evaluación del Software, fue originalmente
desarrollado en 1991 para proporcionar un esquema para la evaluación de calidad del
software.
La normativa define seis características de la aplicación, estas seis características son dividas
en un número de sub- características, las cuales representan un modelo detallado para la
evaluación de cualquier sistema informático.

CARACTERÍSTICAS NORMA ISO 9126

El modelo establece diez características, seis que son comunes a las vistas interna y externa
y cuatro que son propias de la vista en uso.
A continuación se describen las características y sub-características propias de este estándar
que se encuentran dentro de las vistas interna y externa, las cuales usaremos para evaluar el
software de CMI.
Funcionalidad: capacidad del software de proveer los servicios necesarios para cumplir
con los requisitos funcionales.

Sub-características:
 Idoneidad.- Hace referencia a que si el software desempeña las tareas para las
cuales fue desarrollado.
 Exactitud.- Evalúa el resultado final que obtiene el software y si tiene consistencia
a lo que se espera de él.
 Interoperabilidad.- Consiste en revisar si el sistema puede interactuar con otro
sistema independiente.
 Seguridad.- Verifica si el sistema puede impedir el acceso a personal no autorizado.
 Fiabilidad: capacidad del software de mantener las prestaciones requeridas del
sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.
 Subcaracterísticas:
 Madurez.- Se debe verificar las fallas del sistema y si muchas de estas han sido
eliminadas durante el tiempo de pruebas o uso del sistema.
 Recuperabilidad.- Verificar si el software puede reasumir el funcionamiento y
restaurar datos perdidos después de un fallo ocasional.
 Tolerancia a fallos.- Evalua si la aplicación desarrollada es capaz de manejar
errores.
 Usabilidad: esfuerzo requerido por el usuario para utilizar el producto
satisfactoriamente.
 Subcaracterísticas:
 Aprendizaje.- Determina que tan fácil es para el usuario aprender a utilizar el
sistema.
 Comprensión.- Evalúa que tan fácil es para el usuario comprender el
funcionamiento del sistema
 Operatividad.- Determina si el usuario puede utilizar el sistema sin mucho
esfuerzo.
 Atractividad.- Verifica que tan atractiva se ve la interfaz de la aplicación.
 Eficiencia: relación entre las prestaciones del software y los requisitos necesarios
para su utilización.
 Subcaracterísticas:
 Comportamiento en el tiempo.- Verifica la rapidez en que responde el sistema
 Comportamiento de recursos.- Determina si el sistema utiliza los recursos de
manera eficiente
 Mantenibilidad: esfuerzo necesario para adaptarse a las nuevas especificaciones y
requisitos del software.
 Subcaracterísticas:
 Estabilidad.- Verifica si el sistema puede mantener su funcionamiento a pesar de
realizar cambios.
 Facilidad de análisis.- Determina si la estructura de desarrollo es funcional con el
objetivo de diagnosticar fácilmente las fallas.
 Facilidad de cambio.- Verifica si el sistema puede ser fácilmente modificado
 Facilidad de pruebas.- Evalúa si el sistema puede ser probado fácilmente
 Portabilidad: capacidad del software ser transferido de un entorno a otro.
 Subcaracterísticas:
 Capacidad de instalación.- Verifica si el software se puede instalar fácilmente
 Capacidad de reemplazamiento.- Determina la facilidad con la que el software
puede remplazar otro software similar.
 Adaptabilidad.- El software se puede trasladar a otros ambientes
 Co-Existencia.- El software puede funcionar con otros sistemas
Desarrollo

La norma ISO/IEC 9126 de 1991, es la norma para evaluar los productos de

software, esta norma nos indica las características de la calidad y los
lineamientos para su uso, fue desarrollada para dar soporte a aquellas
necesidades; las características de calidad y sus métricas asociadas, pueden ser
útiles tanto como para evaluar el producto como para definir los requerimientos
de la calidad y otros usos.Esta norma definida por un marco conceptual basado
en los factores tales como Calidad del Proceso, Calidad del Producto del Software
y Calidad en Uso; según el marco conceptual, la calidad del producto, a su vez,
contribuye a mejorar la calidad en uso.

La norma ISO/IEC 9126 presentan dos modelos de calidad, el primero referido

a la calidad interna y externa y el segundo modelo referido a la calidad en uso,
a continuación se describe cada uno de ellos.

La calidad externa se define como la totalidad de las características del producto

software desde una perspectiva externa. Es la calidad del software cuando es
ejecutado, la cual es típicamente medida y evaluada mientras se prueba en un
ambiente simulado, con datos simulados y usando métricas externas. Durante
las pruebas, muchas fallas serán descubiertas y eliminadas. Sin embargo
algunas fallas todavía pueden permanecer después de las pruebas. Como es
difícil corregir la arquitectura de software u otros aspectosfundamentales del
diseño del software, el diseño fundamental permanece sin cambios a través de
las pruebas.
 Figura 1. Imagen tomada de la página web:
http://www.mginformatica.com.ar/modelo-de-calidad.htm

La norma ISO/IEC 9126 define la calidad en uso como la perspectiva del usuario
de la calidad del producto software cuando éste es usado en un ambiente
específico y un contexto de uso específico. Éste mide la extensión para la cual
los usuarios pueden conseguir sus metas en un ambiente particular, en vez de
medir las propiedades del software en si mismo.

El modelo de la calidad en uso muestra un conjunto de 4 características:

efectividad, productividad, integridad, y satisfacción.
 Figura 2. Imagen tomada de la página web:
http://olgacarreras.blogspot.com.es/2012/03/estandares-formales-de-
usabilidad-y-su.html

NORMA ISO/IEC - 14598

El estandar ISO/IEC 14598 es actualmente usado como base metodológica para

la evaluación del producto software. En sus diferentes etapas, establece un
marco de trabajo para evaluar la calidad de los productos de software
proporcionando, además, métricas y requisitos para los procesos de evaluación
de los mismos.

La norma define las principales características del proceso de evaluación

 Repetitividad.
 Reproducibilidad.
 Imparcialidad.
 Objetividad.

Para estas características se describen las medidas concretas que participan:

 Análisis de los requisitos de evaluación.

 Evaluación de las especificaciones.
 Evaluación del diseño y definición del plan de evaluación.
 Ejecución del plan de evaluación.
 Evaluación de la conclusión.
La Norma ISO/IEC 14598 define el proceso para evaluar un producto de
software, el mismo consta de seis partes:

 ISO/IEC 14598-1 Visión General: provee una visión general de las otras
cinco partes y explica la relación entre la evaluación del producto software
y el modelo de calidad definido en la ISO/IEC 9126.

 ISO/IEC 14598-2 Planeamiento y Gestión: contiene requisitos y guías

para las funciones de soporte tales como la planificación y gestión de la
evaluación del producto del software.

 ISO/IEC 14598-3 Proceso para desenvolvedores: provee los requisitos

y guías para la evaluación del producto software cuando la evaluación es
llevada a cabo en paralelo con el desarrollo por parte del desarrollador.

 ISO/IEC 14598-4 Proceso para adquirientes: provee los requisitos y

guías para que la evaluación del producto software sea llevada a cabo en
función a los compradores que planean adquirir o reutilizar un producto
de software existente o pre-desarrollado.

 ISO/IEC 14598-5 Proceso para avaladores: provee los requisitos y guías

para la evaluación del producto software cuando la evaluación es llevada
a cabo por evaluadores independientes.

 ISO/IEC 14598-6 Documentación de Módulos: provee las guías para la

documentación del módulo de evaluación.

Los servicios relacionados con la evaluación de software de productos son

generalmente adaptados a las necesidades de los usuarios finales individuales o
proveedores, en función de por qué se pidió la evaluación. Los servicios de
evaluación de software incluyen:

 Definición de perfiles de calidad de referencia de software

 Evaluación de acuerdo con los modelos de calidad predefinidos
 Certificación de la calidad del software de acuerdo a los modelos de
calidad y normas
 Las comparaciones entre productos
 La reingeniería del software
 Servicio de Monitoreo de calidad del producto.
NORMA ISO/IEC 25000 (SquaRE)

ISO 25000:2005 (SQuaRE -Software Quality Requirements and Evaluation) es

una nueva serie de normas que se basa en ISO 9126 y en ISO 14598 (Evaluación
del software). Uno de los principales objetivos de la serie SQuaRE es la
coordinación y harmonización del contenido de ISO 9126 y de ISO 15939:2002
(Measurement Information Model). ISO 15939 tiene un modelo de información
que ayuda a determinar que se debe especificar durante la planificación,
performance y evaluación de la medición. Para su aplicación, cuenta con los
siguientes pasos: Recopilar los datos, Preparación de los datos y Análisis de los
datos.

Su objetivo principal es guiar el desarrollo de los productos de software con la

especificación y evaluación de requisitos de calidad. Establece criterios para la
especificación de requisitos de calidad de productos software, sus métricas y su
evaluación. SQuaRE está formada por las divisiones siguientes:

 ISO/IEC 2500n. División de gestión de calidad. Los estándares que

forman esta división definen todos los modelos comunes, términos y
referencias a los que se alude en las demás divisiones de SQuaRE.
 ISO/IEC 2501n. División del modelo de calidad. El estándar que
conforma esta división presenta un modelo de calidad detallado,
incluyendo características para la calidad interna, externa y en uso.
 ISO/IEC 2502n. División de mediciones de calidad. Los estándares
pertenecientes a esta división incluyen un modelo de referencia de calidad
del producto software, definiciones matemáticas de las métricas de
calidad y una guía práctica para su aplicación. Presenta aplicaciones de
métricas para la calidad de software interna, externa y en uso.
 ISO/IEC 2503n. División de requisitos de calidad. Los estándares que
forman parte de esta división ayudan a especificar los requisitos de
calidad. Estos requisitos pueden ser usados en el proceso de
especificación de requisitos de calidad para un producto software que va
a ser desarrollado ó como entrada para un proceso de evaluación. El
proceso de definición de requisitos se guía por el establecido en la norma
ISO/IEC 15288 (ISO, 2003).
 ISO/IEC 2504n. División de evaluación de la calidad. Estos estándares
proporcionan requisitos, recomendaciones y guías para la evaluación de
un producto software, tanto si la llevan a cabo evaluadores, como clientes
o desarrolladores.
 ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen
requisitos para la calidad de productos de software “Off-The-Self” y para
el formato común de la industria (CIF) para informes de usabilidad.

Al igual que la norma ISO/IEC 9126, este estándar define tres vistas
diferenciadas en el estudio de la calidad de un producto:
  Vista interna: esta vista se ocupa de las propiedades del software como:
el tamaño, la complejidad o la conformidad con las normas de orientación
a objetos.
 Vista externa: vista que analiza el comportamiento del software en
producción y estudia sus atributos, por ejemplo: el rendimiento de un
software en una máquina determinada, el uso de memoria de un
programa o el tiempo de funcionamiento entre fallos.
 Vista en uso: mide la productividad y efectividad del usuario final al
utilizar el software.

La primera puede utilizarse desde las primeras fases del desarrollo, permitiendo
detectar deficiencias en el software en edades muy tempranas del ciclo de vida
del software.

La segunda, sin embargo, necesita que el producto software este completo y se

utilizará por tanto en el pase a producción del producto, siendo muy dependiente
de la máquina donde se ejecute.

Por último la tercera vista que también estudia el producto software finalizado
será dependiente del usuario y estará condicionada a los factores personales del
mismo.

Figura 3. Modelo de Referencia de Medición de la Calidad del Producto

Software, según la ISO/IEC 25000. Imagen tomada de la página web:
http://iso25000.com/index.php/25000.html
Pruebas
Estándares para el ciclo de pruebas en el proceso de desarrollo de software

IEEE 1008 ESTANDAR PARA PRUEBAS DE UNIDAD

Los destinatarios principales de esta norma, son los testers de unidad y supervisores de
unidades de prueba. Este estándar fue desarrollado para ayudar a aquellos que proporcionan
la entrada a, ejecutar, supervisar, monitorear y evaluar las pruebas unitarias.

Las pruebas de unidad de software, son un proceso que incluye la realización de la

planificación de pruebas, la adquisición de un equipo de prueba y la medición de prueba una
unidad contra de sus requisitos o requerimientos.
Nos proporciona información de fracaso, análisis y corrección de fallos de software, que no
especifica un proceso de depuración de software.
Los resultados de algunas de las tareas generales de planificación de prueba se aplican a todos
los niveles de prueba (por ejemplo, identificar la seguridad y restricciones de privacidad).

Esta norma describe un enfoque integrado de la prueba de la unidad sistemática y

documentada.

El enfoque utiliza diseño de la unidad y la información de la unidad de ejecución, además de

los requisitos de la unidad, para determinar la integridad de la prueba.

Esta norma describe un proceso de prueba compuesto por una jerarquía de fases, actividades
y tareas, y define un conjunto mínimo de tareas para cada actividad.
Esta norma requiere la realización de cada actividad, o que los resultados anteriores estar
disponibles y ser revaluados.

ISO/IEC/IEEE 29119 (Mas usado)

Es un conjunto acordado a nivel internacional de normas para las pruebas de software que se
pueden utilizar dentro de cualquier ciclo de vida de desarrollo de software u organización.
Mediante la implementación de estas normas estará adoptando las únicas normas
internacionalmente reconocidas y acordadas para las pruebas de software, lo que
proporcionará a la organización con un enfoque de alta calidad para las pruebas que se puedan
comunicar en todo el mundo. Actualmente hay cinco normas:

ISO/IEC 29119-1: Concepts & Definitions (published September 2013)

ISO/IEC 29119-2: Test Processes (published September 2013)
ISO/IEC 29119-3: Test Documentation (published September 2013)
ISO/IEC 29119-4: Test Techniques (at DIS stage, anticipating publication in late 2014)
ISO/IEC 29119-5: Keyword Driven Testing (at CD stage, anticipating publication in 2015).

Tiene como propósito unificar e integrar las normas BSI, IEEE, and ISO/IEC JTC 1/SC, el
resultado del proyecto será un tratamiento consistente y unificado adoptado por las tres
organizaciones.

La ISO/IEC/IEEE 29119 reemplaza varios estándares de testing de software existentes.

IEEE 829 Test Documentation
IEEE 1008 Unit Testing
BS 7925-1 Vocabulary of Terms in Software Testing
BS 7925-2 Software Component Testing Standard

Estructura:
La norma define un modelo de prueba de proceso genérico que se puede utilizar dentro de
cualquier desarrollo de software y ciclo de vida de la prueba. Este proceso se basa en un
proceso de prueba de cuatro capas de cobertura:

Especificaciones de organización de prueba (por ejemplo, la política organizativa de prueba,

prueba de Estrategia Organizacional)
Gestión de pruebas (por ejemplo, prueba de gestión de proyectos, gestión de la fase de
prueba)
Los procesos dinámicos de prueba, incluyendo el diseño e implementación de prueba,
entorno de prueba puesta a punto y mantenimiento, ejecución de pruebas y notificación de
incidentes

El estándar cubrirá documentación de pruebas en todo el ciclo de vida completo del software
de prueba. Esto incluye plantillas que se pueden personalizar y que cubra todas las fases del
proceso de pruebas, entre ellas:
Prueba de organización Documentación de proceso:
- Política organizativa de prueba
- Estrategia organizativa de prueba

Gestión de pruebas Proceso Documentación:

- Test Plan (incluye la estrategia de prueba)
- Informe de las pruebas de estado
- Prueba de Informe Final

Prueba dinámica de proceso:

- Prueba de las Especificaciones de Diseño
- Especificación de Casos de Prueba
- Procedimiento de Ensayo
- Requisitos de los datos de prueba
- Requisitos detallados entorno de prueba
- Entorno de prueba de la disponibilidad del informe
- Prueba Resultado
- Resultado de la prueba
- Prueba de registro de ejecución
- Prueba de Informe de Incidente

La norma cubre una variedad de técnicas dinámicas comunes de pruebas de software:

Basados en Especificaciones Técnicas de prueba:

- Separación de equivalencia
- Clasificación método del árbol
- Análisis del valor límite
- Examen Estatal de Transición
- Decisión de prueba de la mesa
- Causa-Efecto Graphing
- Sintaxis de Pruebas
- Técnicas de prueba combinatorias, incluyendo:
Todas las combinaciones
Prueba de pares
Cada opción Pruebas
Base Testing Choice
- Escenario de Prueba
- Error Guessing
- Pruebas al azar

Técnicas basadas en la estructura de prueba:

- Declaración de Pruebas
- Rama de pruebas
- Decisión Pruebas
- Condición de prueba, incluyendo:
Branch condición de prueba
Branch condición de prueba de combinación
Modificado Decisión Condición Condición (MCDC) Pruebas

- Datos de pruebas de flujo, incluyendo:

Todas las definiciones
All-c-usa
All-p-usa
Todos los usos
Todos los caminos-du-
También proporciona definiciones informativas de una variedad de calidad relacionados con
los tipos de pruebas:

Pruebas de Acceso
Copia de seguridad / recuperación de Pruebas
Compatibilidad Pruebas
Conversión de Pruebas
Pruebas de recuperación de desastres
Pruebas funcionales
Prueba de Interoperabilidad
Mantenibilidad Pruebas
Rendimiento de carga, tensión, resistencia, volumen y pruebas de capacidad
Portabilidad Pruebas
Procedimiento de la Prueba
Fiabilidad Pruebas
Pruebas de Seguridad
Pruebas de Estabilidad
Test de usabilidad

Documentación

Los estándares son un conjunto de criterios documentados para especificar y determinar la

adecuación de una acción u objeto. Los estándares pueden ser desarrollados por la propia
compañía, por sociedades profesionales, o por organismos internacionales.

Estándares a considerar:
La documentación puede ser el elemento tangible que el usuario ve primero, y por lo tanto
influye en las primeras impresiones del usuario del producto de software.
 ISO/IEC, 26514 DEL 2008.
  IEEE 830.
 PMBOK.
 ITIL.

ISO/IEC, 26514 DEL 2008

Requerimientos de documentación de usuario para diseñadores y desarrolladores. Define
los procesos de documentación desde el punto de vista de su desarrollador. Cubre la
documentación como producto, su estructura contenido y formato.

Sirve para documentación:

 Productos distintos de software.
 Sistemas de animación, video y sonido.
 Programas de capacitación especializados.
 Administradores de sistemas que no son usuarios finales.
 Describe el funcionamiento interno de los sistemas de software.
 Incorporada en la interfaz de usuario propia.
Parte 1:
Se describe como establecer la información que los usuarios necesitan, como
determinar la forma en que esa información debe ser presentada a los usuarios, como
preparar la información y ponerla a disposición.

Parte 2:
Se aplica a los manuales de usuario impreso, ayuda en línea, tutoriales y documentación
de referencia para el usuario.

IEEE 830 SRS

Es un acuerdo documentado entre el cliente y el grupo de desarrollo acerca del producto a
ser construido. Estos documentos tienen por finalidad reunir los requisitos completos del
cliente tal de desarrollar un software de acuerdo a las exigencias del mismo.

 Establece con precisión las funciones y capacidad del software así como sus
restricciones.
  Es la base para toda subsecuente planificación, diseño, codificación, pruebas del
software y la documentación del usuario.

La documentación consta de:

 Introducción:

o Propósito.
o Ámbito del sistema.
o Definiciones, acrónimos y abreviaturas.
o Referencias.
o Visión general del documento.

 Descripción general:

o Perspectiva del producto.

o Funciones del producto.
o Características de los usuarios.
o Restricciones.
o Suposiciones y dependencias.
o Requisitos futuros.

 Requisitos específicos:

o Interfaces externas.
o Funciones.
o Requisitos de rendimiento.
o Restricciones de diseño.
o Atributos del sistema.
o Otros requisitos.

 Apéndices.

Bibliografía

 http://www.icesi.edu.co/departamentos/tecnologias_informacion_comunicaciones/p
royectos/lisa/home/analisis/srs/srs
 http://zeus.inf.ucv.cl/~bcrawford/AULA_ICI441/ERS_IEEE830.pdf
 http://informmatico-juan.blogspot.com.co/
 http://artemisa.unicauca.edu.co/~cardila/CS_08_Estandares_para_pruebas_software
.pdf
 http://in2test.lsi.uniovi.es/gt26/presentations/ISO29119-Presentacion-GT26-
20140618.pdf
 https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=17&ved
=0ahUKEwj2msPFm_zOAhUlyoMKHbAlAIQ4ChAWCEIwBg&url=http%3A%2
F%2Fwww.bibliotecanacional.gov.co%2Fbnwiki%2Ftiki-
download_file.php%3FfileId%3D37&usg=AFQjCNF4ZSPYt4foY-
opRildtO0sT6VKkg&cad=rja
 http://escalidadsw.blogspot.com.co/2014/05/isoieee-12207.html
 https://es.wikipedia.org/wiki/ISO/IEC_12207
 http://bemuserp.blogspot.com.co/2011/09/norma-iso-9126-para-analisis-de.html
 http://evaluaciondesoftware2013.blogspot.com.co/
 https://prezi.com/txqoqmmghhvc/estandares-para-documentacion-de-
proyectos/
 http://brfranciscoosunaiuty.blogspot.com.co/2012/07/estandares-en-el-proceso-
de-desarrollo.html