ISO/IEC 25000

El objetivo general de la creacin del estndar ISO/IEC 25000 SQuaRE (Software Product Quality Requeriments and Evaluation) es organizar, enriquecer y unificar las series que cubren dos procesos principales: especificacin de requesitos de calidad del software y evaluacin de la calidad del software, soportada por el proceso de medicin de calidad del software. Las caractersticas de calidad y sus mediciones asociadas pueden ser tiles no solamente para evaluar el producto software sino tambin para definir los requerimientos de calidad.La serie ISO/IEC 25000:2005 reemplaza a dos estndares relacionados: ISO/IEC 9126 (Software Product Quality) e ISO/IEC 14598 (Software Product Evaluation).

Divisiones:

ISO/IEC 2500n. Divisin de gestin de calidad. Los estndares que forman esta divisin definen todos los modelos comunes, trminos y referencias a los que se alude en las dems divisiones de SQuaRE.

ISO/IEC 2501n. Divisin del modelo de calidad. El estndar que conforma esta divisin presenta un modelo de calidad detallado, incluyendo caractersticas para la calidad interna, externa y en uso. ISO/IEC 2502n. Divisin de mediciones de calidad. Los estndares pertenecientes a esta divisin incluyen un modelo de referencia de calidad del producto software, definiciones matemticas de las mtricas de calidad y una gua prctica para su aplicacin. Presenta aplicaciones de mtricas para la calidad de software interna, externa y en uso.

ISO/IEC 2503n. Divisin de requisitos de calidad. Los estndares que forman parte de esta divisin ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificacin de requisitos de calidad para un producto software que va a ser desarrollado como entrada para un proceso de evaluacin. El proceso de definicin de requisitos se gua por el establecido en la norma ISO/IEC 15288 (ISO, 2003).

ISO/IEC 2504n. Divisin de evaluacin de la calidad. Estos estndares proporcionan requisitos, recomendaciones y guas para la evaluacin de un producto software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores.

Scrum

Metodologa SCRUM

Scrum es un marco de trabajo para la gestin ydesarrollo de software basada en un procesoiterativo e incremental utilizado comnmente en entornos basados en el desarrollo gil de software. Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin de programas: Scrum de Scrums.

Proceso Unificado de Rational

El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresaRational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo con las necesidades.

Esfuerzo en actividades segn fase del proyecto.

Top-down y bottom-up
Top-down (de arriba abajo) y bottom-up (de abajo arriba) son estrategias de procesamiento de informacin caractersticas de las ciencias de la informacin, especialmente en lo relativo al software. Por extensin se aplican tambin a otras ciencias sociales y exactas. En el modelo top-down se formula un resumen del sistema, sin especificar detalles. Cada parte del sistema se refina diseando con mayor detalle. Cada parte nueva es entonces redefinida, cada vez con mayor detalle, hasta que la especificacin completa es lo suficientemente detallada para validar el modelo. El modelo top-down se disea con frecuencia con la ayuda de "cajas negras" que hacen ms fcil cumplir requerimientos aunque estas cajas negras no expliquen en detalle los componentes individuales. En contraste, en el diseo bottom-up las partes individuales se disean con detalle y luego se enlazan para formar componentes ms grandes, que a su vez se enlazan hasta que se forma el sistema completo. Las estrategias basadas en el flujo de informacin "bottom-up" se antojan potencialmente necesarias y suficientes porque se basan en el conocimiento de todas las variables que pueden afectar los elementos del sistema.