Swebok y Metrica V3

Guía que describe el conocimiento que existe de la disciplina de la ingeniería del software. Comenzó a elaborarse en 1998, liderado por la IEEE Computer Society, quien pensó que era necesario para “convertir a la ingeniería del software en una disciplina legítima y una profesión reconocida”. Es una guía, obviamente no contiene todo el conocimiento, accesible y de manera gratuita y que divide ala ingeniería del software en 10 áreas
Requerimientos de Software: Un requerimiento es definido como una propiedad que debe ser exhibida para resolver algún problema del mundo real.
Diseño de Software: Es una fase que abarca todo el ciclo de vida de un producto software, pues se trata de la administración de los cambios, así como el mantenimiento de los requisitos, de tal forma que se reflejelo que en realidad el ítem final va a ser.
Construcción de Software: Implementación de un producto que sea funcional a través de la combinación de codificación, validación y pruebas unitarias.
Pruebas de Software: Verificación dinámica del comportamiento de un programa, sobre un conjunto finito de casos de prueba.
Mantenimiento de Software: Mejoras a implementar en el software una vez que estáoperativo, producto de anomalías, cambios en el ambiente operativo, nuevos requisitos, etc.
Gestión de la Configuración de Software: Proceso de de control de los cambios en el producto, con el fin de mantener la integridad en el ciclo de vida del mismo.
Gestión de la Ingeniería del Software: Administración de ciertos procesos complejos como la gestión de la organización, de los proyectos y delas métricas del software.
Procesos de Ingeniería del Software: Definición, implementación, medida y cambio de los procesos de ingeniería del software.
Métodos y herramientas de la Ingeniería del Software: Control del ambiente y métodos de desarrollo del software.
Calidad de Software: Consideraciones de calidad que trascienden los procesos del ciclo de vida.


La notificación se proporcionacomo otras áreas de conocimiento estén disponibles para su revisión. Los revisores deben leer las instrucciones de revisión y entrar en sus comentarios de revisión junto con la información solicitada (véase la columna derecha del sitio de la revisión).
El estilo arquitectónico que guía esta organización
Toda arquitectura de software comienza por una arquitectura funcional o vista de casos deuso, un subconjunto del modelo de casos de uso del sistema, compuesto a su vez por los así llamados casos de uso o requisitos arquitectónicos. Después están la vista lógica, que le habla a los analistas y diseñadores sobre la estructura del software. La vista de implementación, que les cuenta a los programadores detalles sobre el manejo del software. Por su parte, la vista de procesos habla dedesempeño, escalabilidad y puesta en marcha a los integradores del sistema. Y también está la vista de despliegue que nos explica de manera lacónica la topología del sistema, aspectos de la entrega del mismo, de instalación y de comunicación subyacentes.
El diseño y la implementación de todo el producto de software debe obedecer a estas restricciones, casi leyes, impuestas por la arquitectura asídescrita. Es lo que hace posible que los casos de uso se diseñen en grupos heterogéneos de paquetes o subsistemas diferentes.
Cambios
Un proceso efectivo de petición de cambio del soft requiere del uso de herramientas de soporte u procedimientos. Desde los formularios de papel y un procedimiento documentado, hasta la herramienta electrónica para generar peticiones de cambio, imponiendo el flujodel proceso de cambios, capturando las deciciones del cbb y produciendo información del proceso de cambio.













METRICA V3
En esta entrada repesco algunos apuntes sobre METRICA V3, uno de los temas estrella del exámen de test de las Oposiciones TIC, sin dejar de recomendar la lectura de los documentos originales de esta metodología de desarrollo de uso obligado en las...