ingenieriadesoftwarecabj.files.wordpress.com€¦ · web viewel estándar ieee 830-1998 para el...
Post on 17-Sep-2020
17 Views
Preview:
TRANSCRIPT
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
top related