Your SlideShare is downloading. ×
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Estándar IEEE-12207
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,931
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
1
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Estándar IEEE-12207 Marcos Raúl Córdova Bayas Facultad de Ingeniería de Sistemas, Escuela Politécnica Nacional Campus “José Rubén Orellana”, Ladrón de Guevara E11-253, Quito, Ecuador raul.cordova@epn.edu.ec Resumen El presente trabajo contiene una descripción del estándar IEEE-12207, que determina los Procesos del Ciclo deVida del Software, como parte de la colección de estándares de la IEEE referente a Tecnología de la Información.Esta norma determina la existencia de 5 procesos principales, 8 procesos de apoyo y 4 procesos organizativos delCiclo de Vida del Software, donde cada proceso está dividido en actividades y éstas a su vez en tareas. En estedocumento se definen cada uno de esos procesos, se listan las actividades de los procesos de Adquisición ySuministro y se detallan algunas de las tareas de las principales actividades de estos procesos, lo que permiteilustrar el uso y aplicación de la norma. El trabajo intenta promover el uso de este estándar dentro de la industriadel software, con el fin de que las empresas, los profesionales, la academia y todos aquellos que estén involucradosde alguna manera en el área de la Ingeniería del Software y los Sistemas de Información, lo usen como una normapara dialogar en un lenguaje común y para ejecutar procesos comunes. Se pretende también contribuir a la mejorade la industria del software en el Ecuador, ya que el uso de esta norma permitiría a las empresas obtener una basesólida para mejorar la calidad de sus procesos y productos, permitiendo que su competitividad aumente tanto anivel nacional como internacional.Palabras Claves: proceso de adquisición, auditoría, gestión de la configuración, proceso de desarrollo, procesode mantenimiento, proceso de operación, aseguramiento de la calidad, proceso de suministro, proceso deadaptación, validación, verificación. Abstract The present work contains a description of the IEEE-12207 standard, used to define Software Life CycleProcesses, as part of the IEEE Information Technology standards collection. It includes 5 primary life cycleprocesses, 8 supporting life cycle processes and 4 organizational life cycle processes, each divided in activities andtasks. This document define every process, lists the activities of the Acquisition and Supply processes and detailssome of the tasks of the principal activities of these processes, allowing illustrate the use and the application of thisstandard. The work try to promote the use of this standard into the software industry, with the objective that thecompanies, the professionals, the academic and all involved into the Software Engineering and InformationSystems, use it as a regulation that helps to talk in a common language and put in practice common processes. Ittries as well to contribute to improve the Ecuadorian software industry, because the uses of this standard wouldallow the companies obtain a solid foundation to improve the processes and products quality, allowing raise theirnational and international competitiveness.Key words: acquisition process, audit, configuration management, development process, maintenance process,operation process, quality assurance, supply process, tailoring process, validation, verification
  • 2. 1. Introducción están incluidos en este estándar, como los procesos de Adquisición y Suministro del software, vitales para la La industria del software ha logrado un gran avance adecuada relación entre clientes y proveedores deen los últimos 40 años. Nuevos métodos, software.metodologías, procesos, técnicas y herramientas hanaparecido con el fin de mejorar los procesos de De igual manera, se incluyen en la norma comodesarrollo y mantenimiento del software, procesos de apoyo, algunos procesos que no siemprefundamentalmente. Desde la aparición del primer son considerados como esenciales durante lamodelo de ciclo de vida de desarrollo del software, se ejecución de los procesos de Desarrollo, Operación ohan impuesto como grandes fases del proceso de Mantenimiento de software, tales como los procesosdesarrollo las de Análisis, Diseño, Implementación y de Auditoria, Revisiones Conjuntas y Solución dePruebas del Software (Pressman, 2005). Algunas han Problemas.incluido al proceso de Mantenimiento como parte deeste ciclo de vida, pero se ha comprobado que este Adicionalmente, existen procesos que no sonproceso no está incluido dentro de él (Bohem, 1988) técnicos sino de Gestión y que contribuyen a una(IEEE, 1993), por lo que desde hace algún tiempo, se mejor planificación, ejecución, control y evaluaciónlo ha considerado como un proceso separado, aunque de los procesos técnicos. Estos también estáncuando se incluyen nuevos requerimientos para un incluidos en la norma como Procesos Organizativossistema ya elaborado, se debe seguir el mismo ciclo de del Ciclo de Vida del Software, y son definidos comovida anterior, pero como un proceso propio de procesos de Gestión (básicamente de proyectos),mantenimiento de software. Infraestructura, Mejora y Formación (de recursos humanos). Los procesos anteriores, sin embargo, no han sidosuficientes para conseguir una mejora en la calidad de Por otra parte, existe una amplia gama de términoslos procesos del software, lo que ha redundado que se usan dentro del SLC, pero que no todos lostambién en que no se alcance una mejora en la calidad actores involucrados dentro de la Ingeniería delde los productos de software. Por esta causa, se han Software y de los Sistemas de Información los usanagregado nuevos procesos al ciclo de vida del con la misma acepción, lo cual dificulta lasoftware (Software Life Cycle – SLC: ciclo que comunicación adecuada entre ellos. Así, el términocomienza cuando se tiene la idea inicial del producto a Desarrollo (del inglés Development) tiene variaselaborar y que termina cuando el producto deja de ser acepciones: todo el proceso de creación de un nuevoutilizado), entre los cuales los más conocidos son el producto, solamente una fase (la de Implementación oproceso de Aseguramiento de la Calidad (Quality Codificación o Programación), o incluso alguna otraAssurance), el de Gestión de la Configuración (como Análisis o Diseño). Esta confusión y uso(Configuration Management) y los de Verificación y indiscriminado de términos ha ocasionado que tantoValidación (Verification and Validation) las empresas como los profesionales involucrados en(Sommerville, 2006), todos los cuales han contribuido la creación y uso del software, así como la propiaa mejorar la calidad del proceso y, potencialmente, del academia no puedan usar un lenguaje común, ni estarproducto software. de acuerdo en procesos comunes a ser utilizados para el software. También, la generación de la Documentación quepermita documentar la forma como se llevan los Por todas estas razones, el estándar IEEE-12207,procesos, así como el contenido de los productos intenta estandarizar los procesos del Ciclo de Vida delelaborados a lo largo de esos procesos, ha generado Software, así como la terminología utilizada dentro deserias dificultades en los desarrolladores de software. esos procesos.Muchos no documentan los procesos porqueconsideran que es una pérdida de tiempo, otros porque Este trabajo describe el estándar IEEE-12207, yno tienen tiempo y otros documentan de manera tiene por propósito difundirlo y promoverlo como elparcial y no completa. Ha sido necesario, pues, estándar a ser utilizado en la industria del software ydeterminar que el Proceso de Documentación es en el ámbito académico, con el fin de que todosindispensable también para mejorar procesos y quienes participan en la producción, comercializaciónproductos software (Thayer, 1990). Y este proceso y enseñanza del software en el Ecuador, lo utilicenestá incluido en la norma que se va a describir, lo cual como el medio que permita tener un lenguaje común yasegura su importancia. Asimismo, algunos procesos unos procesos comunes, que atenúen la complejidadque no han sido considerados a lo largo del tiempo inherente del software (Brooks, 1987), permitiendo
  • 3. elevar la calidad del software, componente Esta norma es aplicable a la adquisición de sistemas,fundamental de la tecnología en la época actual. productos y servicios software, al suministro, desarrollo, operación y mantenimiento de productos2. Condiciones generales para el uso de la software, y a la parte software del firmware,norma independientemente de que sea hecho interna o externamente a una organización. Incluye también A continuación se describe el ámbito de la norma, el aquellos aspectos de la definición del sistemaobjeto de la misma, el campo de aplicación, la necesario para proporcionar el contexto de losadaptación de la norma para su uso, qué significa su productos y servicios software.cumplimiento y las limitaciones para su aplicación(IEEE/EIA 12207.0-1996, 2003). NOTA - Es necesario que los procesos usados durante el ciclo de vida del software sean compatibles 2.1 Ámbito con los procesos usados durante el ciclo de vida del sistema. Este estándar o marco de referencia cubre el ciclo devida del software desde la conceptualización de ideas Esta norma está orientada para ser usada enhasta su retirada, y consta de procesos para adquirir y situaciones en las que haya dos partes, incluido el casosuministrar productos y servicios software. Cubre en que estas dos partes pertenezcan a la mismaademás el control y la mejora de estos procesos. organización. La situación puede ir desde un acuerdo informal, hasta un contrato con responsabilidades Los procesos que hay en esta norma forman un legales. Esta norma puede ser usada por una sola parteconjunto exhaustivo. Una organización, dependiendo como una auto imposición.de sus necesidades, puede seleccionar un subconjuntoapropiado para satisfacer dichas necesidades. Esta Esta norma no está dirigida a productos software prenorma está, así pues, diseñada para ser adaptada a una elaborados, a no ser que formen parte de un productoorganización, proyecto o aplicación concreta. Está entregable.también diseñada para ser usada tanto cuando elsoftware es una entidad independiente, como cuando Esta norma está escrita para adquisidores deestá empotrado o forma parte del sistema total. sistemas y productos y servicios software, y para suministradores, desarrolladores, operadores, 2.2. Objeto mantenedores, gerentes, responsables de aseguramiento de calidad y usuarios de productos  Esta norma establece un marco de referencia software. común para los procesos del ciclo de vida del software, con una terminología bien definida 2.4 Adaptación de esta norma a la que puede hacer referencia la industria del software. Esta norma contiene un conjunto de procesos, actividades y tareas pensadas para ser adaptadas a los  Contiene procesos, actividades y tareas para proyectos software. El proceso de adaptación consiste aplicar durante la adquisición de un sistema en la eliminación de los procesos, actividades y tareas que contiene software, un producto software no aplicables. puro o un servicio software, y durante el suministro, desarrollo, operación y NOTA - Los contratos pueden contemplar la mantenimiento de productos software. El adición de procesos, actividades o tareas únicas o software incluye la parte software del especiales. firmware. 2.5 Cumplimiento  Esta norma incluye también un proceso que puede emplearse para definir, controlar y Se define como cumplimiento de esta norma la mejorar los procesos del ciclo de vida del ejecución de todos los procesos, actividades y tareas software. seleccionados de esta norma para el proyecto software, mediante un Proceso de Adaptación. La 2.3 Campo de aplicación ejecución de un proceso o una actividad es completa cuando todas las tareas requeridas por el proceso o actividad se llevan a cabo de acuerdo con los criterios
  • 4. prestablecidos y los requisitos especificados en el cada actividad se subdivide a su vez en un conjunto decontrato como aplicables. tareas. A continuación se hace una introducción de cada proceso, apareciendo representados en la Figura Cualquier organización (nacional, asociación 1 (IEEE/EIA 12207.0-1996, 2003). La numeraciónindustrial, compañía, etc.) que imponga esta norma corresponde al aparecimiento del proceso dentro de lacomo condición para tener relaciones comerciales, es norma. Así, el proceso de Adquisición aparece en elresponsable de especificar y hacer público el conjunto capítulo 5 de la norma como 5.1, mientras que elmínimo de procesos, actividades y tareas que proceso de Gestión aparece en el capítulo 7 como 7.1.constituyen el cumplimiento de esta norma por parte Las actividades se numeran dentro de los procesos ydel suministrador. las tareas dentro de las actividades. Así, la primera actividad dentro del proceso de Adquisición se 2.6 Limitaciones numera como 5.1.1, mientras que la primera tarea dentro de esta actividad se numera como 5.1.1.1. Esta norma describe la arquitectura de los procesosdel ciclo de vida del software, pero no especifica los 3.1 Procesos principales del ciclo de vida.detalles de cómo implementar o llevar a cabo lasactividades y tareas incluidas en los procesos. Esta  Los procesos principales del ciclo de vidanorma no pretende prescribir el nombre, el formato o son cinco procesos que dan servicio a lasel contenido explícito de la documentación que se partes principales durante el ciclo de vida delgenere. Si bien esta norma puede requerir la software.elaboración de diversos documentos de parecido tipo  Una parte principal es la que inicia o lleva ao clase (un ejemplo son los distintos tipos de planes), cabo el desarrollo, operación oesto no implica que dichos documentos se desarrollen, mantenimiento de productos software.agrupen o se mantengan separados de alguna manera.  Estas partes principales son el adquisidor, elEstas decisiones se dejan para el usuario de esta suministrador, el desarrollador, el operador ynorma. el mantenedor de productos software. Esta norma no prescribe un método o un modelo deciclo de vida concreto para el desarrollo del software.Las partes en esta norma son las responsables deseleccionar un modelo de ciclo de vida para elproyecto software, y de elaborar una correspondenciaentre los procesos, actividades y tareas de esta normay los de dicho modelo. Las partes son también responsables de seleccionary aplicar los métodos de desarrollo del software, y dellevar a cabo las actividades y tareas adecuadas para elproyecto software. Esta norma no pretende entrar en conflicto con laspolíticas, normas o procedimientos actualmente envigor en ninguna organización. Sin embargo, esnecesario resolver cualquier conflicto que surja,documentando por escrito en forma de excepcióncualquier incumplimiento autorizado de esta norma.3. Procesos del Ciclo de Vida del Software Esta norma agrupa las actividades que puedenllevarse a cabo durante el ciclo de vida del software encinco procesos principales, ocho procesos de apoyo ycuatro procesos organizativos. Cada proceso del ciclode vida está dividido en un conjunto de actividades; Figura 1. Esquema estructural norma IEEE-12207
  • 5. 4. Proceso de verificación. Define las actividades (para el adquisidor, suministradorLos procesos principales son: o una parte independiente) para verificar 1. Proceso de adquisición. Define las hasta un nivel de detalle dependiente del actividades del adquisidor, organización que proyecto software, los productos software. adquiere un sistema, producto software o 5. Proceso de validación. Define las actividades servicio software. (para el adquisidor, suministrador o parte 2. Proceso de suministro. Define las actividades independiente) para validar los productos del suministrador, organización que software del proyecto software. proporciona el sistema, producto software o 6. Proceso de revisiones conjuntas. Define las servicio software al adquisidor. actividades para evaluar el estado y 3. Proceso de desarrollo. Define las actividades productos de una actividad. Este proceso del desarrollador, organización que define y puede ser empleado por dos partes desarrolla el producto software cualesquiera, donde una de las partes (la 4. Proceso de operación. Define las actividades revisora) revisa a la otra parte (la revisada), del operador, organización que proporciona de una manera conjunta. el servicio de operar un sistema informático 7. Proceso de auditoría. Define las actividades en su entorno real, para sus usuarios. para determinar el cumplimiento de los 5. Proceso de mantenimiento. Define las requisitos, planes y contrato. Este proceso actividades del mantenedor, organización que puede ser empleado por dos partes proporciona el servicio de mantenimiento del cualesquiera, donde una parte (la auditora) producto software; esto es, la gestión de las audita los productos software o actividades modificaciones al producto software para de otra parte (la auditada). mantenerlo actualizado y operativo. Este 8. Proceso de solución de problemas. Define un proceso incluye la migración y retirada del proceso para analizar y eliminar los producto software. problemas (incluyendo las no conformidades) que sean descubiertos3.2 Procesos de apoyo del ciclo de vida. durante la ejecución del proceso de desarrollo, operación, mantenimiento u otros  Hay ocho procesos de apoyo del ciclo de procesos, cualesquiera que sea su naturaleza vida. o causa.  Un proceso de apoyo es el que apoya a otro proceso como parte esencial del mismo, con 3.3 Procesos organizativos del ciclo de vida. un propósito bien definido, y contribuye al éxito y calidad del proyecto software.  Se emplean por una organización para  Un proceso de apoyo se emplea y ejecuta por establecer e implementar una infraestructura otro proceso según sus necesidades. constituida por procesos y personal asociados al ciclo de vida, y para mejorarLos procesos de apoyo son: continuamente esta estructura y procesos.  Se usan habitualmente fuera del ámbito de 1. Proceso de documentación. Define las proyectos y contratos específicos; sin actividades para el registro de la información embargo, la experiencia adquirida mediante producida por un proceso del ciclo de vida. dichos proyectos y contratos contribuye a la 2. Proceso de gestión de la configuración. mejora de la organización. Define las actividades de gestión de la configuración. Los procesos organizativos son: 3. Proceso de aseguramiento de la calidad. Define las actividades para asegurar, de una 1. Proceso de gestión. Define las actividades básicas manera objetiva, que los productos software de gestión, incluyendo la gestión de proyectos, y los procesos son conformes a sus requisitos durante un proceso del ciclo de vida. especificados y se ajustan a sus planes 2. Proceso de infraestructura. Define las establecidos. Se pueden emplear Revisiones actividades básicas para establecer la Conjuntas, Auditorías, Verificación y infraestructura de un proceso del ciclo de vida. Validación como técnicas de Aseguramiento 3. Proceso de mejora. Define las actividades básicas de la Calidad. que una organización (adquisidor, suministrador,
  • 6. desarrollador, operador, mantenedor o el gestor sistema, el adquisidor aprobará los requisitos de otro proceso) lleva a cabo para establecer, analizados. medir, controlar y mejorar su proceso del ciclo de 5.1.1.4 El adquisidor puede llevar a cabo él mismo vida. la definición y análisis de los requisitos software, o4. Proceso de formación. Define las actividades puede contratar a un suministrador para llevar a cabo para conseguir personal adecuadamente formado. dicha actividad. 5.1.1.5 Conviene que se use el Proceso de Desarrollo (5.3) para llevar a cabo las tareas de los4. Actividades y tareas de los procesos de apartados 5.1.1.2 y 5.1.1.4. 5.1.1.6 El adquisidor considerará las opciones paraAdquisición y Suministro la adquisición a partir del análisis de los criterios apropiados para incluir los riesgos, costes y beneficios En esta sección se listarán las actividades de dos de de cada opción.los procesos principales del ciclo de vida del software:el de Adquisición y el de Suministro, así como Posibles opciones son:también algunas de las tareas asociadas a esasactividades (IEEE/EIA 12207.0-1996, 2003). El a) Comprar un producto software preelaborado quepropósito es ilustrar la forma como la norma lista las satisfaga los requisitos.actividades y describe las tareas de los procesos del b) Desarrollar el producto software u obtener elciclo de vida, de tal manera que las organizaciones o servicio software internamente.personas interesadas en adoptarla, profundicen su c) Desarrollar el producto software u obtener elconocimiento y la apliquen en los proceso de software servicio software mediante un contrato.que llevan a cabo. d) Una combinación de a, b y c.. e) Mejorar un producto o servicio software ya existente. Actividades del Proceso de Adquisición (5.1): 5.1.1.7 Cuando se vaya a adquirir un producto Este proceso consta de las siguientes actividades: software preelaborado, el adquisidor se asegurará de que se satisfacen las siguientes condiciones: 5.1.1 Inicio. 5.1.2 Preparación de la petición de ofertas a) Se satisfacen los requisitos del producto[licitación]. software. 5.1.3 Preparación y actualización del contrato. b) La documentación está disponible. 5.1.4 Seguimiento del suministrador. c) Se satisfacen los derechos de marca, uso, 5.1.5 Aceptación y finalización. propiedad, garantía y licencia. d) Se ha planificado el soporte futuro al productoA continuación se muestran las tareas de la actividad software.de Inicio, para mostrar la forma en que se detallan lastareas en el estándar. 5.1.1.8 Conviene que el adquisidor prepare, documente y ejecute un plan de adquisición. El plan 5.1.1 Inicio. Esta actividad consta de las debería incluir lo siguiente:siguientes tareas: a) Requisitos del sistema. 5.1.1.1 El adquisidor inicia el proceso de b) Empleo previsto del sistema.adquisición describiendo un concepto o una necesidad c) Tipo de contrato a emplear.de adquirir, desarrollar o mejorar un sistema, producto d) Responsabilidades de las organizacionessoftware o servicio software. involucradas. 5.1.1.2 El adquisidor definirá y analizará los e) Tipo de soporte que se va a usar.requisitos del sistema. Conviene que los requisitos del f) Riesgos considerados y procedimientos parasistema incluyan requisitos de negocio, organizativos, gestionar dichos riesgos.de usuario, así como de seguridad física y de acceso yotros requisitos críticos, junto con los procedimientos 5.1.1.9 Conviene que el adquisidor defina yy normas de diseño, pruebas y conformidad documente la estrategia y condiciones (criterios) derelacionados. aceptación. 5.1.1.3 Si el adquisidor contrata a un suministradorpara llevar a cabo el análisis de los requisitos del
  • 7. Actividades del Proceso de Suministro (5.2): Actividades del Proceso de Suministro (5.2): Este proceso consta de las siguientes actividades: Este proceso consta de las siguientes actividades:1) Inicio. 1) Inicio.2) Preparación de la petición de ofertas [licitación]. 2) Preparación de la respuesta.3) Preparación y actualización del contrato. 3) Contrato.4) Seguimiento del suministrador. 4) Planificación.5) Aceptación y finalización. 5) Ejecución y control. 6) Revisión y evaluación.A continuación se muestran las tareas 5.1.16 a la 7) Suministro y finalización.5.1.1.8, consideradas de las más importantes para laactividad de inicio, A continuación se muestran dos tareas para la actividad 4 de este proceso, Planificación del5.1.1.6 El adquisidor considerará las opciones para la Suministro:adquisición a partir del análisis de los criteriosapropiados para incluir los riesgos, costes y beneficios 5.2.4.4 Una vez están establecidos los requisitos parade cada opción. los planes, el suministrador deberá considerar las opciones para desarrollar el producto software oPosibles opciones son: proporcionar el servicio software, a partir del análisis de los riesgos asociados con cada opción. Posiblesa) Comprar un producto software preelaborado que opciones son:satisfaga los requisitos.b) Desarrollar el producto software u obtener el a) Desarrollar el producto software o proporcionar elservicio software internamente. servicio software usando recursos internos.c) Desarrollar el producto software u obtener el b) Desarrollar el producto software o proporcionar elservicio software mediante un contrato. servicio software subcontratándolo.d) Una combinación de a, b y c. c) Obtener productos software preelaborados dee) Mejorar un producto o servicio software ya fuentes internas o externas.existente. d) Una combinación de a, b y c.5.1.1.7 Cuando se vaya a adquirir un producto 5.2.4.5 El suministrador deberá desarrollar ysoftware preelaborado, el adquisidor se asegurará de documentar el plan o planes de gestión del proyectoque se satisfacen las siguientes condiciones: basados en los requisitos para los planes y en las opciones seleccionadas en 5.2.4.4. Los aspectos aa) Se satisfacen los requisitos del producto software. considerar en el plan incluyen (pero no están limitadosb) La documentación está disponible. a) lo siguiente:c) Se satisfacen los derechos de marca, uso,propiedad, garantía y licencia. a) Estructura organizativa del proyecto y autoridad yd) Se ha planificado el soporte futuro al producto responsabilidad de cada unidad organizativa,software. incluyendo las organizaciones externas. b) Entorno de ingeniería (para desarrollo, operación, o5.1.1.8 Conviene que el adquisidor prepare, mantenimiento, según proceda), incluyendo el entornodocumente y ejecute un plan de adquisición. El plan de pruebas, bibliotecas, equipos, instalaciones,debería incluir lo siguiente: normas, procedimientos y herramientas. c) Descomposición estructurada del trabajo de losa) Requisitos del sistema. procesos y actividades del ciclo de vida, incluyendob) Empleo previsto del sistema. los productos software, servicios software y elementosc) Tipo de contrato a emplear. no entregables que deban desarrollarse, junto con losd) Responsabilidades de las organizaciones presupuestos, personal, recursos físicos, tamaño delinvolucradas. software y plazos asociados a las tareas.e) Tipo de soporte que se va a usar. d) Gestión de las características de calidad de losf) Riesgos considerados y procedimientos para productos o servicios software. Se pueden elaborargestionar dichos riesgos planes separados para la calidad.
  • 8. e) Gestión de la seguridad física y de acceso, y otrosrequisitos críticos de los productos o servicios Las demás actividades y tareas de los procesos delsoftware. Se pueden elaborar planes por separado para ciclo de vida del software, tanto principales, como dela seguridad, tanto física como de acceso. apoyo y organizativos se las puede encontrar en elf) Gestión de subcontratistas, incluyendo su selección, documento que describe el estándar (IEEE/EIAy la relación entre el subcontratista y el adquisidor, si 12207.0-1996, 2003).existe.g) Aseguramiento de la calidad (véase 6.3). 5. Definicionesh) Verificación (véase 6.4) y validación (véase 6.5);incluyendo el enfoque para la interacción con el Puesto que a lo largo de este documento, así como aagente de verificación y validación, si está lo largo del estándar descrito, se encuentra unespecificado. apreciable número de términos que deberían definirsei) Involucración del adquisidor; esto puede hacerse de manera única, a continuación se hace unapor medios tales como revisiones conjuntas (véase recopilación de las definiciones más importantes6.6), auditorías (véase 6.7), reuniones informales, (IEEE/EIA 12207.0-1996,2003):informes, modificaciones y cambios; implementación,aprobación, aceptación y acceso a instalaciones. acuerdo: Definición de los términos y condicionesj) Involucración del usuario; esto puede hacerse por bajo las cuales se ha de desarrollar una relación demedio de ejercicios de establecimiento de requisitos, trabajo.demostración de prototipos y evaluaciones.k) Gestión de riesgos; esto es, gestión de las áreas del adquisición: Proceso de obtener un sistema, productoproyecto que conllevan riesgos potenciales software o servicio software.relacionados con aspectos técnicos, costes y plazos. adquisidor: Organización que adquiere u obtiene unl) Política de seguridad de acceso; esto es, reglas para sistema, producto software o servicio software, de unlo que necesita saber y a la información que puede suministrador.acceder cada nivel de la organización del proyecto. NOTA - Adquisidor podría ser el:m) Aprobación requerida por regulaciones, comprador, cliente, propietario, usuario,certificaciones requeridas y derechos de marca, uso,propiedad, y garantía y licencia. pagador.n) Mecanismos para preparar los plazos, hacer el aseguramiento de la calidad: Todas las actividadesseguimiento y hacer los informes. planificadas y sistemáticas, implementadas dentro delo) Formación del personal (véase 7.4). sistema de calidad, y que se demuestren como necesarias para proporcionar la confianza adecuada en Como se observa, las actividades se detallan en que una entidad cumplirá los requisitos de calidad.tareas a realizarse, las mismas que entregan una guíabastante completa de qué se debe hacer para cumplir NOTAS:en la actividad y a su vez, en el correspondiente 1 Hay motivos tanto internos como externosproceso del ciclo de vida del software. Esto garantiza para el aseguramiento de la calidad:un alto grado de calidad en el proceso, lo que a) Aseguramiento de la calidad interno:seguramente desembocará en obtener un producto de dentro de una organización, el aseguramientoalta calidad. de la calidad proporciona confianza a los gerentes; o Es importante recalcar que las actividades y lastareas no se llevan a cabo de manera aislada, sino que b) Aseguramiento de la calidad externo: encon frecuencia están relacionadas a otros procesos, situaciones contractuales, el aseguramientoactividades o tareas, ya sea dentro del mismo proceso de la calidad proporciona confianza al clienteo con otros procesos. Esto se lo puede observar en la o a otros.tarea 5.1.1.5, en la que se indica que se debe usar otro 2 Hay actividades de aseguramiento de laproceso, en este caso, el de Desarrollo, para realizar calidad interrelacionadas con actividades delas tareas indicadas en los apartados 5.1.1.2 y 5.1.1.4. control de la calidad.Lo mismo acontece con la tarea 5.2.4.5, en losliterales g), h), i) y o), donde se hace mención a los 3 A no ser que los requisitos de calidadprocesos de Aseguramiento de la Calidad (6.3), reflejen completamente las necesidades deVerificación (6.4), Validación (6.5), Revisiones los usuarios, el aseguramiento de la calidadConjuntas (6.6) y Auditorías (6.7).
  • 9. puede no proporcionar la confianza sustitución total o parcial por un nuevo sistema, o adecuada. instalación de un sistema mejorado. seguridad de acceso: Protección de información yauditoría: Conducida por una persona autorizada con datos de manera que las personas o sistemas noel propósito de proporcionar una evaluación autorizados no puedan leerlos o modificarlos, alindependiente de productos y procesos software, con tiempo que no se deniega el acceso a las personas oel fin de evaluar cumplimiento de requisitos. sistemas autorizados.contrato: Acuerdo vinculante entre dos partes, servicio software: Ejecución de actividades, trabajosespecialmente exigible por ley, o acuerdo del mismo o tareas ligadas a un producto software, tales como suestilo totalmente interno a una organización, para el desarrollo, operación y mantenimiento.suministro de un servicio software, o para el sistema: Agregado de elementos consistente en uno osuministro, desarrollo, producción, operación o más de los procesos, hardware, software, instalacionesmantenimiento de un producto software. y personal que proporcionan la capacidad de satisfacerdesarrollador: Organización que lleva a cabo una necesidad u objetivo definido.actividades de desarrollo (incluyendo análisis de los software: Soporte lógico.requisitos, diseño y pruebas hasta la aceptación) suministrador: Organización que contrata con eldurante el proceso del ciclo de vida del software. adquisidor el suministro de un sistema, productofirmware: Combinación de un dispositivo hardware e software o servicio software, bajo los términos delinstrucciones o datos de computadora que residen contrato.como software de solo lectura en el dispositivo NOTAS:hardware. Este software no puede modificarse 1 El término “suministrador” es sinónimo defácilmente bajo el control del programa. contratista, fabricante, productor o vendedor.mantenedor: Organización que lleva a cabo 2 El adquisidor puede designar a parte de suactividades de mantenimiento. organización como suministrador.modelo de ciclo de vida: Marco de referencia que usuario: Individuo u organización que usa un sistemacontiene los procesos, actividades y tareas en operación para llevar a cabo una funcióninvolucradas en el desarrollo, operación y específica.mantenimiento de un producto software, y que abarca NOTA - El usuario puede llevar a cabo otrostoda la vida del sistema, desde la definición de sus papeles tales como el de adquisidor,requisitos hasta el final de su uso. desarrollador o mantenedor.operador: Organización que opera el sistema. validación: Confirmación mediante el examen y lapetición de ofertas [licitación]: Documento usado aportación de evidencia objetiva, de que se cumplenpor el adquisidor como mecanismo para anunciar su los requisitos particulares para un uso previstointención a potenciales ofertantes, de adquirir un específico.sistema especificado, un producto software o un NOTAS:servicio software. 1 En el diseño y el desarrollo, la validaciónproceso: Conjunto de actividades interrelacionadas se refiere al proceso de examinar un productoque transforman entradas en salidas. para determinar su conformidad con las NOTA - El término “actividades” incluye necesidades del usuario. uso de recursos. [Véase UNE-EN ISO 2 La validación se lleva normalmente a cabo 8402:1994, 1.2.] sobre el producto final bajo condiciones deproducto preelaborado: Producto ya desarrollado y operación definidas. Puede ser necesariadisponible, utilizable “tal cual” o con modificaciones. también en etapas anteriores.producto software: Conjunto de programas de 3 El término “validado” se usa para designarcomputadora, procedimientos y posiblemente el estado correspondiente.documentación y datos asociados. 4 Se pueden llevar a cabo múltiplesretirada: Cese del soporte activo por parte de la validaciones si hay diferentes usos previstos.organización de operación y mantenimiento,
  • 10. verificación: Confirmación mediante el examen y la IEEE-12207.0. No se han tratado las otrasaportación de evidencias objetivas, de que se han variantes por cuestiones de tiempo y porquesatisfecho unos requisitos especificados. inicialmente sería más complicado el NOTAS: entendimiento de la norma. 1 En el diseño y el desarrollo, la verificación se refiere al proceso de examinar el resultado  Este estándar define la existencia de 5 procesos de una actividad dada, para determinar su principales del ciclo de vida del software, conformidad con los requisitos establecidos añadiendo a los ya conocidos Desarrollo y para dicha actividad. Mantenimiento, uno más bien técnico, como el de 2 El término “verificado” se usa para Operación, y dos más bien de gestión, como los designar el estado correspondiente. procesos de Adquisición y Suministro deversión: Ejemplar identificado de un elemento. sistemas, productos software y servicios software.NOTA - Modificar una versión de un productosoftware dando como resultado una nueva versión,  La norma incluye 8 procesos de apoyo,requiere una actuación de gestión de la configuración. denominados así porque sirven justamente de apoyo a cualquiera de los 5 procesos principales o Estas definiciones no son todas las que incluye elestándar, solamente aquellas que están relacionadas a alguno de los otros procesos de apoyo del ciclocon los procesos, actividades y tareas descritas en de vida del software.este trabajo. Adicionalmente, se recomienda usar elestándar IEEE-610.12, IEEE Standard Glossary of  Los 4 procesos organizativos se aplican a todosSoftware Engineering Terminology - Glosario los demás procesos que incluye la norma, esestándar para la terminología en Ingeniería del decir, a los procesos principales y a los procesosSoftware (Estándares IEEE, 2003), para acceder a de apoyo del ciclo de vida del software. Estostoda la terminología estándar de la Ingeniería del están más bien relacionados a cuestiones deSoftware, lo que permitirá a quienes se desenvuelven administración involucradas en todos los procesosen este campo y en el de los Sistemas de del software.Información, usar e intercambiar términos con unsolo significado, contribuyendo a que todas las  El nivel de descripción de las actividades y tareasentidades, profesionales y usuarios del software de cada proceso es de alto detalle, lo quetrabajen en un ambiente de terminología común,ampliamente beneficioso para el progreso de la convierte a la norma en fácil de usar y de aplicar.industria del software en el Ecuador.  Algo que se debe resaltar es el hecho de que esta7. Conclusiones norma, a semejanza de todas las que existen en cualquier campo de la tecnología, solamente El estándar IEEE-12207 está formado por tres define el “qué” hacer y no el “cómo” hacerlo. variantes: IEEE-12207.0, IEEE-12207.1 e IEEE- Esto implica que las organizaciones y personas 12207.2. La primera describe los procesos del que la adopten, deberán especificar de manera ciclo de vida del software con sus actividades y detallada cómo implementar la norma para usarla tareas, la segunda describe la forma de de manera adecuada. administrar los datos obtenidos a lo largo de los procesos del ciclo de vida del software y la  La norma incluye un anexo denominado Proceso tercera contiene las consideraciones de de Adaptación, que permite a los interesados en implementación del estándar, que es una guía de usarla, seguir un proceso bien definido para cómo aplicar cada uno de los procesos, adaptarla a su realidad. actividades y tareas definidas. En este documento se han descrito los procesos, actividades y tareas correspondientes a la variante
  • 11. 8. Referencias [1] IEEE/EIA 12207.0-1996. Industry Implementation of International Standard ISO/IEC 12207 : 1995. 2003 [2] Pressman, Roger. Ingeniería del Software: un enfoque práctico. 6a. edición. Editorial McGraw-Hill, Madrid, 2005. [3] Bohem, Barry. A Spiral Model of Software Development and Enhancement. Computer, vol. 21, n. 5, Mayo 1988. [4] IEEE. Software Engineering: Standards Collection. 1993 [5] Sommerville, Ian. Ingeniería del Software. 7ma. Edición. Pearson Addison Wesley. Madrid. 2005 [6] Thayer, Richard. Software System Engineering. System and Software Requirements Engineering, IEEE Computer Society Press Tutorial, 1990. [7] Brooks, Frederick. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, vol. 20, n.4, abril 1987.

×