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.......................................................................................................................................22

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ónLa 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üedadUn 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.

CompletitudUna 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.

VerificabilidadUn 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.

ConsistenciaUna 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ónNo 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.

ModificabilidadUna 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 usoEn 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ñoEn 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/ proyectos/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%2F%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.blogspo t.com.co/2012/07/estandares-en-el-proceso-

de-desarrollo.html