3. Norma Técnica Peruana:“NTP – ISO / IEC 12207:2004” Contiene procesos, actividades y tareas para aplicar durante la adquisición de un sistema que contiene software, un producto software puro o un servicio software, y durante el suministro, desarrollo, operación y mantenimiento de productos software. Esta Norma Técnica Peruana incluye también un proceso que puede emplearse para definir, controlar y mejorar los procesos del ciclo de vida del software. Esta Norma Técnica Peruana está escrita para adquirientes de sistemas y productos y servicios software, y para proveedores, desarrolladores, operadores, responsables de mantenimiento, administradores, responsables de aseguramiento de calidad y usuarios de productos software.
4. Norma Técnica Peruana:“NTP – ISO / IEC 12207:2004” Esta Norma Técnica Peruana no pretende establecer el nombre, el formato o el contenido explícito de la documentación que se genere. Esta Norma Técnica Peruana no establece un modelo de ciclo de vida concreto para el desarrollo del software. Las partes en esta Norma Técnica Peruana son las responsables de seleccionar un modelo de ciclo de vida para el proyecto software y de elaborar una correspondencia entre los procesos, actividades y tareas de esta Norma Técnica Peruana y los de dicho modelo.
5. ¿Qué es ISO/IEC 12207? Es una norma de la ingeniería de software resultado del esfuerzo internacional de expertos de todo el mundo entre académicos y profesionales. Busca establecer un marco de referencia para la administración de los procesos de la ingeniería de software en el mundo. Define los procesos, actividades y tareas asociadas a los procesos del ciclo de vida del software desde la concepción hasta su retiro. Define los procesos de ingeniería de software como: “un conjunto de actividades que son realizadas por un conjunto de tareas que definen como las acciones transforman las entradas en salidas”
8. ARQUITECTURA La norma establece la arquitectura de alto nivel del ciclo de vida del software: los procesos y sus interrelaciones. El ciclo comienza con la idea y termina con la retirada del software. Se derivan los procesos considerando: Modularidad del proceso: un proceso individual se dedica solamente a una única función. Alta cohesión y bajo acoplamiento. Responsabilidad del proceso: un proceso individual es responsabilidad de una de las partes.
23. Procesos de Apoyo Documentación: Registrar la información producida por un proceso o actividad del ciclo de vida: Diseñar, editar, distribuir y mantener los documentos producidos durante el desarrollo del software. Gestión de la configuración: Actividades que controlan las modificaciones y versiones de los elementos. Registrar las peticiones de cambios e informar de los estados de éstos..
24. Aseguramiento de la calidad: Actividades para asegurar que los productos cumplen los requisitos especificados y se ajustan a los planes establecidos. Revisión conjunta, auditoría, verificación y validación pueden ser utilizadas como técnicas de aseguramiento de la calidad. Verificación: Actividades para determinar el buen funcionamiento de un producto software.
25. Validación: Actividades para determinar si e producto cumple los requisitos previstos. Revisión conjunta: Actividades que permiten determinar el estado de los productos en una determinada actividad del ciclo de vida o en una cierta fase del proyecto. Puede ser una reunión conjunta con el cliente, el grupo de desarrollo y los clientes potenciales para revisar el trabajo hecho.
26. Auditorías: Actividades que permiten determinar en unos momentos determinados si se han conseguido los objetivos propuestos: requisitos, cumplimiento del contrato. Este proceso puede ser empleado por dos partes cualesquiera, donde una de las partes (la auditora) audita los procesos software o actividades de otra parte (la auditada.)
27. Solución de problemas: Actividades que permiten analizar y resolver los problemas o disconformidades con los requisitos o con el contrato, que hayan surgido durante el desarrollo, la operación, el mantenimiento, o en cualquier otro momento. Disponer de un medio documental que permita asegurar que todos los problemas se han tratado.
28.
29. El software debe administrarse durante su ciclo de vida para alcanzar su beneficio potencial.