ISO/IEC 26514:2008
 |
Cualquier persona que utiliza el software de aplicación las necesidades de información precisa acerca de cómo el software ayuda al usuario realizar una tarea. La documentación puede ser el primer elemento tangible que el usuario ve y, por lo tanto, influye en la del usuario primeras impresiones del producto de software. La nueva Norma Internacional ISO / IEC 26514:2008 documentación ayudará a los diseñadores desarrolladores y apoya el interés de los usuarios de software. La norma define el proceso de documentación de la documentación del desarrollador de vista. Abarca las etapas implicadas en el diseño, especificando, y la elaboración de la documentación de usuario. Se aplica tanto a la documentación impresa y en pantalla la documentación. ISO / IEC 26514:2008 - Sistemas y software de ingeniería - Requisitos para los diseñadores y desarrolladores de documentación de usuario, abarca las fases implicadas en el diseño, especificando, y la elaboración de la documentación de usuario. Se divide en dos partes es:
 |
La segunda parte establece los requisitos mínimos para la estructura, el contenido de la información, y el formato de la documentación de usuario, incluidos los impresos y en la pantalla los documentos utilizados en el entorno de trabajo por parte de los usuarios de los sistemas que contienen software. Se aplica a los impresos de manuales de usuario, ayuda en línea, tutoriales, y documentación de referencia del usuario. La norma recomienda que el desarrollo de la documentación del usuario debería ser parte del desarrollo del producto de software y sigue los mismos procesos como el producto de software de ciclo de vida y no un ejercicio separado. La documentación de usuario sigue siendo un componente esencial de utilizar los productos de software y de ISO / IEC 26514:2008 puede ser útil para el desarrollo de los siguientes tipos de documentación:
- Documentación de productos distintos de software
- Multimedia utilizando sistemas de animación, vídeo y sonido
- Basados en computadoras y programas de capacitación especializados de los materiales del curso destinado principalmente para su uso en los programas de formación
- La documentación producida por los instaladores, operadores de equipo, o los administradores de sistemas que no son usuarios finales
- Mantenimiento de la documentación que describe el funcionamiento interno de los sistemas de software
- Documentación incorporada en la interfaz de usuario propia.
- ISO / IEC 26514 es el primero de una nueva suite de las normas previstas para hacer frente ala documentación de usuario de software. Si bien la norma ISO / IEC 26514 ha sido desarrollada para atender las necesidades de documentación de usuario diseñadores y desarrolladores, otras tres se están desarrollando normas que atiendan a las necesidades de los administradores, compradores y proveedores, y los verificadores y evaluadores de programas informáticos la documentación de usuarios.
- ISO/IEC 26514:2008 - Sistemas y software de ingeniería - Requisitos para los diseñadores y desarrolladores de documentación de usuario, fue desarrollado por el comité técnico conjunto ISO/ IECJTC 1, Tecnología de la información, Subcomité SC 7, ingeniería de software y sistemas. Cuesta 216francos suizos y está disponible de la norma ISO miembro de los institutos nacionales
Ayuda a los diseñadores y desarrolladores a tener una mejor visualización del software desarrollado mediante la documentación adecuada de manera que se clasifique.
Es aplicable tanto en la documentación impresa como la documentación en pantalla.
Determina la cantidad de la información que maneja el usuario y cuál es la que se filtra para los diseñadores.
Resultado de la fase o etapa
Establece los requisitos mínimos para la estructura, el contenido de la información, y el formato de la documentación de usuario.
Los organismos nacionales miembros de ISO e IEC participan en el desarrollo de Normas Internacionales a través de comités técnicos.
Beneficios
Las normas de un proceso especifican las características y los requerimientos funcionales del producto además de la manera en que se va a desarrollar la documentación del mismo.
La Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC) forman el sistema especializado para la normalización mundial.
 |
COSTOS Y FORMATOS
Los organismos nacionales miembros de ISO e IEC participan en el desarrollo de Normas Internacionales a través de comités técnicos.
La publicación como Norma Internacional requiere la aprobación por al menos el 75% de los organismos nacionales con derecho a voto.
Se aplica a los impresos de manuales de usuario, ayuda en línea, tutoriales, y documentación de referencia del usuario.
PROCESOS
La Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC) forman el sistema especializado para la normalización mundial. (Kosutic, 2008)
 |
IEEE 830
EEE-STD-830-1998 :
ESPECIFICACIONES DE LOS REQUISITOS DEL SOFTWARE
 |
Definiciones
En general las definiciones de
los términos usados en estas especificaciones están conforme a las definiciones
proporcionadas en IEEE Std 610.12-1990.
Contrato
Un documento es legalmente
obligatorio y en el estarán de acuerdo las partes del cliente y proveedor. Esto
incluye los requisitos técnicos y requerimientos de la organización, costo y
tiempo para un producto. Un contrato también puede contener la información
informal pero útil como los compromisos o expectativas de las partes
involucradas.
Cliente
La persona (s) que pagan por el
producto y normalmente (pero no necesariamente) definen los requisitos. En la
práctica el cliente y el proveedor pueden ser miembros de la misma
organización.
Proveedor
La persona (s) que producen un
producto para un cliente.
Usuario
La persona (s) que operan o
actúan recíprocamente directamente con el producto. El usuario (s) y el cliente
(s) no es (son) a menudo las mismas personas(s).
Las consideraciones para producir
un buen SRS.
Estas cláusulas proporcionan
información a fondo que deben ser consideradas al momento de producir un SRS.
Esto incluye lo siguiente:
- La Naturaleza del SRS;
- El Ambiente del SRS;
- Las Características de un buen SRS ;
- La preparación de los Joins del SRS;
- La evolución de SRS;
- Prototipos;
- Generando el diseño en el SRS;
- Generando los requisitos del proyecto en el SRS.
 |
| (Sirse, 2012) |
El estándar 830-1998 fue generado
por un equipo de trabajo del IEEE, su finalidad es la integración de los
requerimientos del sistema desde la perspectiva del usuario, cliente y
desarrollador.
Esta ha sido nuestra propuesta durante la existencia como blog, la 830 se encarga de poner las pautas para identificar y esquemagtizar las requierimientos de software. como parte integral del disarrollo de software, sino tambien como base fundamental de este, todo esto con el fin de no caer en cambios, errores o situaciones que pongan en peligro la creacion de una solucion, producto o software; incurriendo en gastos o cambios producto de una mal analisis de requerimientos
Esta ha sido nuestra propuesta durante la existencia como blog, la 830 se encarga de poner las pautas para identificar y esquemagtizar las requierimientos de software. como parte integral del disarrollo de software, sino tambien como base fundamental de este, todo esto con el fin de no caer en cambios, errores o situaciones que pongan en peligro la creacion de una solucion, producto o software; incurriendo en gastos o cambios producto de una mal analisis de requerimientos
Normas y estándares de sistemas
de calidad en TI(García, 2010)
 |
Los principales objetivos que se
identifican en la especificación de requisitos software son
Las características deseables para una buena especificación de requisitos software que se indican en el IEEE son las siguientes
- 1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software: El cliente debe participar activamente en la especificación de requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo
- 2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS permite al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena especificación de requisitos, los costes de desarrollo pueden incrementarse considerablemente, ya que se deben hacer cambios durante la creación de la aplicación.
- 3. Servir de base para desarrollos de estándares de ERS particulares para cada organización: Cada entidad puede desarrollar sus propios estándares para definir sus necesidades. Una buena especificación de requisitos software ofrece una serie de ventajas entre las que destacan el contrato entre cliente y desarrolladores (como ya se ha indicado con anterioridad), la reducción del esfuerzo en el desarrollo, una buena base para la estimación de costes y planificación, un punto de referencia para procesos de verificación y validación, y una base para la identificación de posibles mejoras en los procesos analizados.
 |
| (YeisonJ, 2012) |
Las características deseables para una buena especificación de requisitos software que se indican en el IEEE son las siguientes
- Correcta
- No ambigua
- Completa
- Verificable
- Consistente
- Clasificada
- Modificable
- Explorable
- Utilizable durante las tareas de mantenimiento y uso
(YeisonJ, 2012)
PMBOK
(Skuad,2007)
La guía del PMBOK es un
instrumento desarrollado por el Project Management Institute (o PMI), que
establece un criterio de buenas prácticas relacionadas con la gestión,
la administración y la dirección de proyectos mediante
la implementación de técnicas y herramientas que permiten identificar
un conjunto de 47 procesos, distribuidos a su turno en 5 macroprocesos
generales.
Hoy hablaremos de estos 5
macroprocesos identificados en la guía del PMBOK, y atenderemos a las 10 áreas
de conocimiento que el PMI considera como aspectos clave en la dirección de
proyectos empresariales.
 |
| (Sirze,2012) |
La guía PMBOK y la gestión de
proyectos
PMBOK son
las siglas de Project Management Body of Knowledge, y la realización
de su guía es, como decíamos, responsabilidad del Project Management
Institute (PMI). Publicada en 2013 por la editorial del PMI, goza de un
reconocimiento internacional en lo que a estándares de gestión, administración
y dirección de proyectos se refiere.
Tomada frecuentemente como manual
de buenas prácticas, las alusiones y remisiones a la guía del proyecto
PMBOK son tan universalescomo necesarias en el ámbito de la dirección y la gestión
de proyectos, un ámbito que en el PMBOK se presenta como la
convergencia de dos aspectos fundamentales: macroprocesos, que agrupan todos
los procesos y las actividades implicadas en proyectos estandarizados, y
áreas de conocimiento, es decir, aquellos aspectos clave cuya consideración
debe intervenir en cada uno de los macroprocesos establecidos.
Si estás interesado en este tema,
también te recomendamos la descagra, de forma gratuita, de nuestra guía
sobre estratagia de marca blanca.
 |
| (Chia, 2017) |
Los macroprocesos de la guía
PMBOK
La guía PMBOK identifica 5
macroprocesos en los que se incluyen los 47 procesos estándares que intervienen
en cualquier proyecto:
Inicio: conformado por 2 procesos
menores, cuyo fin es definir un nuevo proyecto o una nueva fase de
ejecución del mismo, y obtener la autorización necesaria para llevarlo a
cabo.
Planificación:
este macroproceso incluye 24 procesos destinados a la concreción y el
establecimiento de objetivos, y al diseño de las estrategias más adecuadas para
lograr su consecución.
Ejecución: incluye 8
procesos implicados en el correcto desempeño, acorde a la estrategia
adoptada, de las actividades definidas en el proyecto para la consecución de
los fines establecidos.
Control y monitorización:
once procesos se inscriben en este macroproceso, todos ellos relacionados con
la supervisión y la evaluación del desempeño del proyecto.
Cierre: último macroproceso,
formado por dos procesos menores, que cierra el proyecto en su totalidad o
alguna fase del mismo refiriendo el grado de aceptación y la satisfacción con
el resultado obtenido.
 |
| (David López, 2012) |
¿Qué es el enfoque del PMI?
Como avanzábamos, en cada uno de
estos macroprocesos intervienen 10 aspectos clave o áreas de conocimiento, que
en la guía PMBOK se enuncian y describen del siguiente modo:
 |
| (David López, 2012) |
- Integración: área directamente relacionada con la dirección de proyectos. Establece los criterios para la correcta gestión, administración y coordinación de los distintos procesos y actividades implicadas.
- Alcance: determina el alcance del proyecto, definiendo todos y cada uno de los procesos y las actividades que se hallan implicados.
- Tiempo: gestión del tiempo de ejecución de los procesos implicados en el proyecto, y monitorización de los mismos con el fin de cumplir los plazos establecidos.
- Costes: gestión de los costes del proyecto y control de los mismos para mantenerlos dentro de su presupuestación inicial.
- Calidad: determina responsabilidades en los resultados de las actividades y los procesos implicados en el proyecto y en sus fases, y establece las políticas de calidad a las que debe remitirse la evaluación de dichos resultados. Sobre esta área tan fundamental, es altamente recomendable la lectura de la guía Las 7 herramientas de calidad imprescindibles, disponible completamente gratis en nuestro apartado de recursos.
- Recursos humanos: gestión y dirección del/los equipos humanos implicados en el proyecto o en cada una de sus fases concretas.
- Comunicaciones: área responsable de la gestión y la administración de los mecanismos, las informaciones, las vías y las estrategias de comunicación entre las distintas estructuras y áreas internas del proyecto, así como de la elaboración de la información sobre el mismo orientada al exterior.
- Riesgos: atiende a la detección, gestión y solución de los riesgos implicados en cada uno de los procesos y fases de los mismos.
- Adquisiciones: área de gestión de procesos de compra de bienes, estructuras, herramientas o servicios externos a los equipos implicados en el proyecto.
- Skateholders: se refiere a la gestión de los
interesados o posibles inversores, a la correcta administración de las
expectativas generadas con el proyecto y a la definición de las posibilidades
de intervención en el mismo por parte de terceros.
- A pesar de que la Guía PMBOK ofrece directrices generales para la gestión de la mayoría de los proyectos la mayor parte del tiempo, existen 3 documentos que funden como extensiones para la misma:"Extensión software de la Guía PMBOK""Extensión para construcción de la Guía PMBOK""Extensión para gobernación de la Guía PMBOK"(Institute, 2018)
 |
(Institute, 2018)ITIL
Estrategia del Servicio de Infraestructura de Tecnologías de Información es una guía para la aplicación del pensamiento estratégico para la gestión de servicios. El objetivo final es diseñar, desarrollar y poner en práctica la gestión del servicio ya que tanto una capacidad organizativa y un activo estratégico. Este volumen pone de relieve cómo puede transformar su organización de TI en un proveedor de servicios de valor para el negocio.
La Biblioteca de Infraestructura de Tecnologías de prácticas para la gestión de servicios de tecnologías de la información, el desarrollo de tecnologías de la información y las operaciones relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.(Sistemas,2016)
Entre los temas en ITIL:
|
 |
(Sistemas,2016)
Componentes de ITIL Al revisar lo que es ITIL, debe uno adentrarse en la gestión de servicios
de TI que ITIL define en dos grupos:
Soporte de Servicios:
Mejora Continua del Servicio
Se utilizan herramientas de medición y feedback para documentar la
información referente al funcionamiento del servicio, los resultados obtenidos,
problemas ocasionados, soluciones implementadas, etc. Para ello se debe
verificar el nivel de conocimiento de los usuarios respecto al nuevo servicio,
fomentar el registro e investigación referentes al servicio y disponer de la
información al resto de los usuarios.(Morries, 2011)
 |
CMMI
 |
| (Lizbeth, 2008) |
Integration (CMMI)
es un modelo para la mejora y evaluación de procesos para el desarrollo,
mantenimiento y operación de sistemas de software. Administrado por el Instituto
CMMI, una subsidiaria de ISACA, se desarrolló en la Universidad Carnegie Mellon(CMU). Es
requerido por muchos contratos del Departamento de Defensa de los
Estados Unidos (DoD) y del Gobierno de los Estados Unidos,
especialmente en el desarrollo de software. CMU pretende que CMMI pueda ser
usado para guiar la mejora de procesos en un proyecto, división o una
organización completa. CMMI define los siguientes niveles de madurez para los
procesos: Inicial, Repetible, Definido, Gestionado y Optimizado. La versión 2.0
se publicó en 2018 (la versión 1.3 se publicó en 2010
CMMI está registrada en la Oficina de Patentes y Marcas de Estados Unidos por CMU.
Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios.
CMMI está registrada en la Oficina de Patentes y Marcas de Estados Unidos por CMU.
Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios.
Hay tres constelaciones de la versión 1.2 disponibles:
- CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.
- CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.
- CMMI (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.
Dentro de la constelación CMMI-DEV, existen dos modelos:
CMMI-DEV
CMMI-DEV + IPPD (Integrated
Product and Process Development)
Independientemente de la constelación\modelo que opta una organización,
las prácticas CMMI deben adaptarse a cada organización en función de sus
objetivos de negocio.
Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una
organización es evaluada (por ejemplo, usando un método de evaluación como
SCAMPI) y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez
(si bien se comienza con el nivel 2). En caso de que quiera la organización,
puede coger áreas de proceso y en vez de por niveles de madurez puede obtener
los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el
"Perfil de Capacidad" de la Organización.
- Nivel 1: No Confiable- Ambiente impredecible donde las organizaciones no tienen actividades de control y no están diseñadas.
- Nivel 2: Informal- Las actividades de control existen, pero no se ponen en practica. Los controles dependen básicamente de las personas. No hay un entrenamiento formal ni comunicación de las actividades de control.
- Nivel 3: estandarizado- Las actividades de control existen y están diseñadas, han sido documentadas y comunicadas a los empleados, las desviaciones de las actividades de control probablemente no se detecten.
- Nivel 4: Monitoreado- Se utilizan herramientas en una forma limitada para soportar las actividades de control
- Nivel 5: Optimizado- Es una estructura integrada de control interno con un monitoreo en tiempo real por la gerencia, así como mejoras continuas-auto control, se encuentran cambios más rápidos al momento de detectar errores en los manejos de las actividades o en las personas.
Muchas organizaciones valoran el medir su progreso llevando a cabo una
evaluación (appraisal) y ganando una clasificación del nivel de madurez o de un
nivel de capacidad de logro. Este tipo de evaluaciones son realizadas
normalmente por una o más de las siguientes razones:
Para determinar que tan bien los
procesos de la organización se comparan con las mejores prácticas CMMI y determinar
qué mejoras se pueden hacer.
Como requisito del cliente en
licitaciones públicas o concursos privados.
Las valoraciones de las organizaciones utilizando un modelo CMMI deben
ajustarse a los requisitos definidos en el documento "Appraisal Requirements
for CMMI" (ARC). La evaluación se enfoca en identificar oportunidades de
mejora, y comparar los procesos de la organización con las mejores prácticas
CMMI. Los equipos de evaluación usan el modelo CMMI y un método conforme a ARC
para guiar su evaluación y reporte de conclusiones. Los resultados de la
evaluación son usados para planear mejoras en la organización. Hay tres clases
de evaluación: Clase A,B,C. El Standard CMMI Appraisal Method for Process
Improvement (SCAMPI) es un Método de evaluación que cumple todos los
requerimientos ARC. Una evaluación de clase A es más formal y es la única que
puede resultar en una clasificación de nivel.
El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es el
método oficial SEI para proveer puntos de referencia de sistemas de
calificación en relación con los modelos CMMI. SCAMPI se usa para identificar
fortalezas y debilidades de los procesos, revelar riesgos de
desarrollo/adquisición, y determinar niveles de capacidad y madurez. Se
utilizan ya sea como parte de un proceso o programa de mejoramiento, o para la
calificación de posibles proveedores. El método define el proceso de evaluación
constando de preparación; las actividades sobre el terreno; observaciones
preliminares, conclusiones y valoraciones; presentación de informes y
actividades de seguimiento.
Referencias
González, M. E. (16 de 07 de 2015). Academia. Obtenido de Academia: https://www.academia.edu/14127263/ISO_IEC_26514
Industrial, F. (12 de 09 de 2008). Foro Industrial. Obtenido de Foro Industrial: http://www.foro-industrial.com/2008/09/nueva-norma-isoiec-265142008-documentacion-software/
KAI WEBER, L. T. (2016). Technical-comunication. Obtenido de Technical-comunication: https://www.technical-communication.org/fileadmin/Bilder/tekom-danmark/event-downloads/2016-10-04_04_Kai_Weber_ISO26515_and_Agile_User_Documentation.pdf
Kosutic, D. (2008). Gestión de documentación ISO: una guía en un lenguaje sencillo. En D. Kosutic,Gestión de documentación ISO: una guía en un lenguaje sencillo.
LD, F. (2 de 03 de 2017). Prezi. Obtenido de Prezi: https://prezi.com/3cegqpfhoelm/isoiec-265142008/
Sirse. (06 de 05 de 2012). Obtenido de Sirse: https://www.google.com/search?biw=1366&bih=608&tbm=isch&sa=1&ei=Z02cXPigMc2osgX06Y7oDQ&q=ISO&oq=ISO&gs_l=img.3..35i39l2j0i67l2j0l6.286752.286914..287216...0.0..0.272.527.2-2......1....1..gws-wiz-img.5qGQhPPH9v4#imgrc=rOhJttDvz6v7GM:
Sites.google.com. (s.f.). Obtenido de Sites.google.com: https://sites.google.com/site/sistemascalidadti/iso-iec-26514-2008
SZ, A. (8 de 04 de 2013). Prezi. Obtenido de Prezi: https://prezi.com/u9zr2hcwxv8z/norma-isoiec265142008/
López, A. (19 de 05 de 2017). ctr-unican. Obtenido de ctr-unican: https://www.ctr.unican.es/asignaturas/is1/IEEE83
Bibliografía
García, A. (05 de 09 de 2010). ctr-unican. Obtenido de ctr-unican: https://www.ieec830.es/asignaturas/is1/IEEE830.html
Sánchez, J. (8 de Febrero
de 1998). Documento de Requerimientos. Obtenido de Documento de
Requerimientos: https://www.google.com/search?q=ieee+830&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjKzLv8nqThAhWEna0KHezGCjkQ_AUIDigB&biw=1366&bih=657#imgrc=6E9RCu2pJKpxRM:
chain, S. (17 de
Noviembre de 2017). Business school. Obtenido de Business school:
https://retos-operaciones-logistica.eae.es/que-es-la-guia-pmbok-y-como-influye-en-la-administracion-de-proyectos/
Institute, p. M. (2018). Guía
de PMBOK. Newtown: GlobalStandard.
Consultoritil. (45 de 02
de 2015). Grupo Arion. Obtenido de Grupo Arión:
http://www.consultoriaitil.com.mx/10.html
Morries, L. G. (2011). ITIL.
Wiley Brand.
