¿Qué es ISO 25000?

ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and Evaluation), es una familia de normas que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad del producto software.

La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores, especialmente de las normas ISO/IEC 9126, que describe las particularidades de un modelo de calidad del producto software, e ISO/IEC 14598, que abordaba el proceso de evaluación de productos software. Esta familia de normas ISO/IEC 25000 se encuentra compuesta por cinco divisiones.

ISO/IEC 2500n – División de Gestión de Calidad: Las normas que forman este apartado definen todos los modelos, términos y definiciones comunes referenciados por todas las otras normas de la familia 25000. Actualmente esta división se encuentra formada por:

• ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la arquitectura de SQuaRE, la terminología de la familia, un resumen de las partes, los usuarios previstos y las partes asociadas, así como los modelos de referencia.

• ISO/IEC 25001 - Planning and Management: establece los requisitos y orientaciones para gestionar la evaluación y especificación de los requisitos del producto software.

ISO/IEC 2501n – División de Modelo de Calidad: Las normas de este apartado presentan modelos de calidad detallados incluyendo características para calidad interna, externa y en uso del producto software. Actualmente esta división se encuentra formada por:

• ISO/IEC 25010 - System and software quality models: describe el modelo de calidad para el producto software y para la calidad en uso. Esta Norma presenta las características y subcaracterísticas de calidad frente a las cuales evaluar el producto software.

• ISO/IEC 25012 - Data Quality model: define un modelo general para la calidad de los datos, aplicable a aquellos datos que se encuentran almacenados de manera estructurada y forman parte de un Sistema de Información.

ISO/IEC 2502n – División de Medición de Calidad: Estas normas incluyen un modelo de referencia de la medición de la calidad del producto, definiciones de medidas de calidad (interna, externa y en uso) y guías prácticas para su aplicación. Actualmente esta división se encuentra formada por:

• ISO/IEC 25020 - Measurement reference model and guide: presenta una explicación introductoria y un modelo de referencia común a los elementos de medición de la calidad. También proporciona una guía para que los usuarios seleccionen o desarrollen y apliquen medidas propuestas por normas ISO.

• ISO/IEC 25021 - Quality measure elements: define y especifica un conjunto recomendado de métricas base y derivadas que puedan ser usadas a lo largo de todo el ciclo de vida del desarrollo software.

• ISO/IEC 25022 - Measurement of quality in use: define específicamente las métricas para realizar la medición de la calidad en uso del producto.

• ISO/IEC 25023 - Measurement of system and software product quality: define específicamente las métricas para realizar la medición de la calidad de productos y sistemas software.

• ISO/IEC 25024 - Measurement of data quality: define específicamente las métricas para realizar la medición de la calidad de datos.

¿Qué es el ISO 12207?

El ISO/IEC 12207 es el estándar para los procesos de ciclo de vida del software de la organización ISO

El estándar comprende 17 procesos lo cuales son agrupados en tres categorías:Este estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. El estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software.

1. Principales
2. de apoyo
3. de organización

Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos organizativos. Cada proceso del ciclo de vida está divido en un conjunto de actividades; cada actividad se sub-divide a su vez en un conjunto de tareas. A continuación se hace una introducción de cada proceso

Estos procesos se ven reflejados en el siguiente esquema.

Procesos Principales

Los procesos principales del ciclo de vida son cinco el cual brinda servicio a las partes principales durante el ciclo de vida del software. Una parte principal es aquella que inicia o lleva a cabo el desarrollo, operación, o mantenimiento de los productos software. Estas partes principales son el adquiriente, el proveedor, el desarrollador, el operador y el responsable de mantenimiento de productos software. Los procesos principales son: 

Proceso de Adquisición

Define las actividades del adquiriente,es decir, la organización que adquiere un sistema,producto software o servicio software.

Proceso de Suministro

Se relaciona con las actividades del proveedor, organización que proporciona sistema,producto o servicio software al adquiriente.

Proceso de Desarrollo

Define las actividades que tiene que llevar a cabo el desarrollador, organización que define y desarrolla el producto software.

Proceso de Operación

Define las actividades del operador, organización que proporciona el servicio, organización que proporciona el servicio de operar un sistema informático en su entorno real.

Proceso de Mantenimiento

Define las actividades del responsable de mantenimiento o la organización que se encarga de esta función;es decir, la gestión de las modificaciones al producto para mantenerlo actualizado y operativo.

Procesos de Apoyo

Las actividades y tareas en un proceso de apoyo son responsabilidad de la organización que lleva a cabo dicho proceso. Esta organización se asegura que el proceso existe y está operativo.Los procesos de apoyo son: 

Proceso de documentación

Define las actividades para el registro de la información producida por un proceso del ciclo de vida.

Proceso de gestión de la configuración

Define las actividades de la gestión de la configuración.

Proceso de Aseguramiento de la calidad

Define las actividades para asegurar, de una manera objetiva, que los productos software y los procesos son conformes a sus requerimientos especificados y se ajustan a sus planes establecido.

Proceso de Verificación

Define las actividades (para el adquiriente, proveedor o una parte independiente) para verificar hasta un nivel de detalle dependiente del proyecto software, los productos software.

Proceso de Validación

Define las actividades para validar los productos software del proyecto software.

Proceso de Revisión Conjunta

Define las actividades para evaluar el estado y productos de una actividad. Este proceso puede ser empleado por cualquiera de las dos partes, donde una de las partes (la revisora) revisa a la otra parte (la parte revisada), de una manera conjunta.

Proceso de Auditoría

Define las actividades para determinar la conformidad con los requerimientos, planes y contrato. Este proceso puede ser empleado por dos partes cualesquiera, donde una parte (la auditora) audita los productos software o actividades de otra parte (la auditada) .

Proceso de Solución de problemas

Define las actividades para analizar y eliminar los problemas que sean descubiertos durante la ejecución del proceso de desarrollo, operación, mantenimiento u otros procesos, cualesquiera que sea su naturaleza o causa.

Procesos Organizativos

Los procesos organizativos del ciclo de vida son cuatro. Se emplean por una organización para establecer e implementar una infraestructura constituida por procesos y personal asociado al ciclo de vida y para mejorar continuamente esta infraestructura. Se usan habitualmente fuera del ámbito de proyectos y contratos específicos; sin embargo, la experiencia adquirida mediante dichos proyectos y contratos contribuye a la mejora de la organización. Los procesos organizativos son:

Proceso de Gestión

Define las actividades básicas de gestión, incluyendo la gestión de proyectos, durante un proceso del ciclo de vida.

Proceso de Infraestructura

Define las actividades básicas para establecer la infraestructura de un proceso del ciclo de vida.

Proceso de Mejora de proceso

Define las actividades básicas que una organización lleva a cabo para establecer, medir, controlar y mejorar sus procesos del ciclo de vida.

Proceso de Recursos Humanos

Define las actividades básicas para conseguir el personal adecuadamente capacitado.

Aqui se muestra eta pequeña explicacion de manera mas clara.

Modelo para el desarrollo del software

1.  El modelo en cascada: Considera las actividades fundamentales del proceso especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera. 

El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:

•  Análisis y definición de requerimientos: Los servicios restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven de manera específica al sistema. 

• Diseño del sistema y del software: El proceso de diseño del sistema divide los requerimientos en sistemas ya sea hardware Soto. Establece una arquitectura completa del sistema, el diseño del software identifique describe los elementos abstractos que son fundamentales para el software y sus relaciones. 

• Implementaciones prueba de unidades: Durante esta etapa el diseño del software se lleva a cabo como un conjunto de unidades de programas, la prueba de unidades implica verificar que cada una cumpla con su función específica. 

• Integración y prueba del sistema: Los programas o las unidades individuales de programas se integran y se prueban como un sistema completo para así asegurar que se cumplan los requerimientos del software, después se entrega al cliente. 

• Funcionamiento y mantenimiento: En esta fase el sistema se instala y se pone en funcionamiento práctico el mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren en nuevos requerimientos.

Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.
                                                                                                                                                                                                                                                                                       

  2. Modelo de espiral La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:

• Crear planes con el propósito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
•   Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
•  La implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;

Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la re-utilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:

•  El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.
• Si la implementación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo.
•  Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.

La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último, se evalúan los resultados y se inicia el diseño de la siguiente fase.

3. El modelo de desarrollo basado en componentes En la mayoría de los proyectos de desarrollo de software existe la reutilización. Por lo general esto sucede informalmente cuando las personas conocen diseños o códigos similares al requerido. Los buscan, los modifican según lo creen necesario y los incorporan en un nuevo sistema. El enfoque evolutivo, la reutilización es indispensable para el desarrollo más ágil de un sistema. Esta reutilización es independiente del proceso de desarrollo que se utilice. Sin embargo, en los últimos años ha surgido un enfoque de desarrollo de software denominado " ingeniería de software basada en componentes", el cual se basa en la reutilización. Este enfoque se basa en la reutilización y se compone de una gran base de componentes de software que son reutilizables.

Aunque la etapa de especificación de requerimientos y la revalidación son comparables con otros procesos, las etapas intermedias en el proceso orientado a la reutilización son diferentes. Estas etapas son:

• Análisis de componentes. En esta se buscan los componentes para implementar los con base en su especificación. Por lo general, no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte de la funcionalidad requerida. 

• Modificación de requerimientos. En esta etapa los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto. Entonces dichos componentes se modifican para reflejar los componentes disponibles, la actividad de análisis de componentes se puede llevar a cabo para buscar soluciones alternativas. 

• Diseño del sistema con reutilización. En esta fase los diseñadores tienen en cuenta los componentes que se reutiliza y que se organizan el marco de trabajo para que los satisfaga. Si dichos componentes no están disponibles se puede diseñar nuevos software. 

• Desarrollo e integración. El software que no se puede adquirir externamente se desarrolla y se integra a los componentes. En este modelo, la integración del sistema es parte del proceso de desarrollo, más que una actividad separada.

El modelo de desarrollo de software basado en componentes creado por Boehm (1988), tiene la ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los costos y los riesgos. También permite una entrega más rápida del software. Sin embargo, los compromisos a los requerimientos son inevitables y esto da lugar a un sistema que no cumpla con las necesidades reales de los usuarios. Pressman (2006), detecto que:

“El software de computadoras moderno se caracteriza por el cambio continuo, los tiempos de entrega son muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es el requisito de gestión más importante. Si se pierde una ventana del mercado, el mismo proyecto de software puede perder su significado”.

Proceso para el desarrollo de software

Un proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo:

Goncalves (2005) plantea que la experiencia ha demostrado que los proyectos exitosos son aquellos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar el proyecto, considerando válido destacar que aquellos procesos que no sigan estos lineamientos corren un alto riesgo de fracasar. Es necesario destacar la importancia de los métodos, pero el éxito del proyecto depende más de la comunicación efectiva con los interesados, el manejo de las expectativas y las personas que participan en el proyecto. 

Existen diferentes modelos y metodologías que han sido en los últimos años herramientas de apoyo para el desarrollo del software. Someerville (2005), menciona que:
• Modelo de desarrollo de software: es una representación simplificada del proceso para el desarrollo de software, presentada desde una perspectiva específica. 

• Metodología de desarrollo de software: es un enfoque estructurado para el desarrollo de software que incluye modelos de sistemas, notaciones, reglas, sugerencias de diseño y guías de procesos.

Modelo para el desarrollo del software

Éstos modelos generales no son descripciones definitivas de los procesos del software, más bien son abstracciones de los procesos que se pueden utilizar para su desarrollo. Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados para crear procesos más específicos. Los modelos que mencionaremos en este punto son:

1) El modelo en cascada: Considera las actividades fundamentales del proceso especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera. 

2) El modelo de desarrollo evolutivo (espiral): Este enfoque entrelaza las actividades especificación, desarrollo y validación. Es decir surge de un sistema inicial que se desarrolla rápidamente a partir de especificaciones abstractas, basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades. 

3)El modelo de desarrollo basado en componentes: Éste se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo se enfoca en integrar estos componentes en el sistema más que en desarrollarlos desde cero. Estos tres modelos se utilizan ampliamente en la práctica actual de la ingeniería del software, no se excluyen mutuamente y a menudo se utilizan juntos especialmente para el desarrollo de grandes sistemas.

Principales datos para realizar un proceso de desarrollo de software

Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay algunos modelos más para representar este proceso.

• Planificación: La importante tarea a la hora de crear un producto de software es obtener los requisitos o su análisis. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software. Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.

• Implementación, pruebas y documentación: La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto. Las pruebas de software son parte esencial del proceso de su desarrollo. Esta parte del proceso tiene la función de detectar los errores  del software lo antes posible.

• Despliegue y mantenimiento: El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción. El mantenimiento y mejora del software con problemas recientemente desplegado puede requerir más tiempo que su desarrollo inicial. Es posible que haya que incorporar un código que no se ajusta al diseño original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno re-diseñar el sistema para poder contener los costes de mantenimiento.

Dato General

La gran cantidad de organizaciones de desarrollo de software implementan metodologías para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un contrato. El estándar internacional que regula el método de selección, implementación y monitoreo del ciclo de vida del software  ISO 12207.

         Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software. 

¿QUE ES EL ISO 25000?

¿Que es ISO 12207?
Conocimiento Previo

Conocimiento Previo.

        Como todo conocimiento nuevo es esencial ordenar nuestras ideas con cada pieza que nos lleve a entender mas claramente el proceso para el desarrollo de un software. De esta manera principalmente se dará a conocer sus entidades o mejor dicho el significado de cada una de sus partes.

                   Proceso                   

     Un proceso puede informalmente entenderse como un programa en ejecución. Formalmente un proceso es "Una unidad de actividad que se caracteriza por la ejecución de una secuencia de instrucciones, un estado actual, y un conjunto de recursos del sistema, que están asociados". 

Para entender lo que es un proceso y la diferencia entre un programa y un proceso, A. S. Tanenbaum propone la analogía  "Un científico computacional con mente culinaria hornea un pastel de cumpleaños para su hija; tiene la receta para un pastel de cumpleaños y una cocina bien equipada con todos los ingredientes necesarios, harina, huevo, azúcar, leche, etcétera". Situando cada parte de la analogía se puede decir que la receta representa el programa (el algoritmo), el científico computacional es el procesador y los ingredientes son las entradas del programa. El proceso es la actividad que consiste en que el científico computacional vaya leyendo la receta, obteniendo los ingredientes y horneando el pastel.

   De esta manera se puede entender como proceso a la acción sinérgica ejercida por el algoritmo, procesador y programa, cumpliendo así una acción en especifico.

Desarrollo

          El desarrollador puede contribuir a la visión general del proyecto, más a nivel de aplicación que a nivel de componentes o en las tareas de programación individuales.

          Conforme pasa el tiempo, las diferencias entre el diseño de sistemas informáticos, el desarrollo de software y la programación se van haciendo más claras. En el nicho de mercado puede encontrarse una separación entre programadores y desarrolladores, siendo estos últimos los que diseñan la estructura o jerarquía de clases. Incluso esos desarrolladores se convierten en arquitectos de sistemas informáticos, aquellos que diseñan la arquitectura a varios niveles o las interacciones entre componentes de un proyecto de software grande.

Software

            Se conoce como software al equipo lógico o soporte lógico de un sistema informático, que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos que son llamados hardware.

            Los componentes lógicos incluyen, entre muchos otros, las aplicaciones informáticas, tales como el procesador de texto, que permite al usuario realizar todas las tareas concernientes a la edición de textos; el llamado software de sistema, tal como el sistema operativo, que básicamente permite al resto de los programas funcionar adecuadamente, facilitando también la interacción entre los componentes físicos y el resto de las aplicaciones, y proporcionando una interfaz con el usuario.

Sin mas preámbulos comenzaré a desarrollar el tema principal y por el cual han llegado a este blog..

proceso para el desarrollo de un software.