NTP12207 1

Ao del Centenario de Machu Picchu para el Mundo
NTPNORMA TCNICA PERUANA NTP-ISO/IEC 12207 2006TECNOLOGA DE LA INFORMACION. Procesos del ciclo de vida del software
Ccoica Falcn, Richard Alfredo Mosqueira Ortiz, Walther Armando Enrique Torres Simbrn, Katherine Karol Curso de Logstica Mg. Miguel Daz Matayoshi Ing de Sistemas VIII IX
04 de agosto del 2011 del
NTP-ISO/IEC 12207 2006TECNOLOGIA DE LA INFORMACION. Procesos del ciclo de vida del software
Cdigo Ttulo
NTP ISO/IEC 12207 2006 TECNOLOGIA DE LA INFORMACION. Procesos del ciclo de vida del software. 2a. ed. 2006/07/28 Establece un marco de referencia comn para los procesos del ciclo de vida del software, con una terminologa bien definida a la que puede hacer referencia la industria del software. Contiene procesos, actividades y tareas para aplicar durante la adquisicin NTP ISO/IEC 12207 2004 35.080 Desarrollo de documentacin de sistemas software y
Publicado Resumen
Reemplaza a I.C.S
Descriptores
SOFTWARE / CICLO DE VIDA /
Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS
INDICE
Introduccin Resea Histrica Conceptualizacin 1 Ciclo de vida de desarrollo del software 2 Modelos de Ciclo de Vida 2.1 Modelo en cascada 2.2 Modelo en V 2.3 Modelo iterativo 2.4 Modelo de desarrollo incremental 2.5 Modelo en espiral 2.6 Modelo de prototipos 3 Metodologas de desarrollo de software 3.1 Metodologas pesadas 3.1.1 RUP 3.2 Metodologas giles 3.2.1 Programacin extrema 4 NTP- ISO/IEC 12207-2006 5 Objetivo y campo de aplicacin 6 Referencias Normativas 7 Aplicacin Proceso de Ciclo de Vida Procesos principales Procesos de apoyo Procesos organizativos Proceso de adaptacin 8 Desarrollo de caso practico Conclusiones Bibliografa
4 5 6 8 10 11 11 12 12 13 14 15 15 15 18 18 20 21 23 26 26 27 28 30 31 34 44 45
INTRODUCCIN
La industria del software representa una actividad econmica de suma importancia para todos los pases del mundo dado que ofrece mltiples fuentes de negocio y se perfila como la oportunidad ms grande de los pases en va de desarrollo. Pero, en los pases latinoamericanos la industria del software es incipiente e inmadura, lo cual conlleva a falta de competitividad que a su vez dificulta su crecimiento. En Per las empresas de desarrollo de software no estn preparadas para ser competitivas internacionalmente. El sector informtico se enfrenta a una serie de problemas como la dependencia tecnolgica del pas, el desconocimiento de la importancia que tiene el proceso de desarrollo sobre la calidad del producto y la construccin de software de forma artesanal, emprica y catica. Es por ello que se hace necesario generar estrategias. Una estrategia primordial es desarrollar productos de calidad ntimamente ligada a la calidad de los procesos utilizados para desarrollarlos. Asegurar la calidad a travs del mejoramiento de los procesos software es un paso que las empresa del pas deben dar como respuesta a dos situaciones: la primera por imagen, para poder exportar software y mantenerse en un mercado global: la segunda es por necesidad, para poder hacer de sus proyectos unidades administrativas eficaces y eficientes. A raz de esto el software desarrollado es de baja calidad, el tiempo de desarrollo es inapropiado, los costos no son competitivos, las actividades de operacin y mantenimiento del software son difciles y hay incremento de la insatisfaccin de los clientes y usuarios finales. El objetivo de este trabajo es presentar un modelo ligero de evaluacin de la calidad de procesos de desarrollo de software basado en normas ISO/IEC 12207 aplicable al micro, pequeas y medianas empresas de manera fcil y econmica, con pocos recursos y en poco tiempo.
RESEA HISTRICA
La NTP fue elaborada por el CTNN de Ingeniera de Software y Sistemas de Informacin, mediante el Sistema de adopcin, durante los meses de enero a marzo del 2006 utilizando como antevente a la Norma ISO/IEC 12207:1995/AMD 1:2002/AMD 2:2005 Informacin Tecnologa. Software life cycle processes. El CTNN de Ingeniera de Software y Sistemas de Informacin presento a la CTR con fecha 200604-21, el PNTP-ISO/IEC 12207:2006, para su revisin y aprobacin, siendo sometido a la etapa de Discusin Publica el 2006-06-09. No habindose presentado observaciones fue oficializado como NTP-ISO/IEC 12207:2006 TECNOLOGA DE LA INFORMACIN. Procesos del ciclo de vida del software, 2 Edicin, el 28 de julio de 2006 Esta NTP reemplaza a la NTP-ISO/IEC 12207:2004 y es una adopcin de la ISO/IEC 12207:1995 1:2002/Amd 2:2005. La presente NTP presenta cambios editoriales referidos principalmente a terminologa empleada propia del idioma espaol y ha sido estructurada de acuerdo con las Guas Peruanas GP 001:1995 y GP 002:1995.
INSTITUCIONES QUE PARTICIPARON EN ELABORACIN DE LA NTP
CONCEPTUALIZACIN
IEC: La Comisin Electrotcnica Internacional (CEI o IEC International Electrotechnical Commision) es una organizacin de normalizacin en los campos elctrico, electrnico y tecnologas relacionadas. Numerosas normas se desarrollan conjuntamente con la ISO (normas ISO/IEC) INDECOPI: El Instituto Nacional de Defensa de la Competencia y de la Proteccin de la Propiedad Intelectual (INDECOPI). Tiene como funciones la promocin del mercado y la proteccin de los derechos de los consumidores. Adems, fomenta en la economa peruana una cultura de leal y honesta competencia, resguardando todas las formas de propiedad intelectual: desde los signos distintivos y los derechos de autor hasta las patentes y la biotecnologa. ISO: La Organizacin Internacional de Normalizacin (ISO del griego igual), organismo encargado de promover el desarrollo de normas internacionales de fabricacin, comercio y comunicacin para todas las ramas industriales a excepcin de la elctrica y las electrnica. CRT: La Comisin de Reglamentos Tcnicos y Comerciales (CRT) del INDECOPI es la autoridad nacional en materia de normalizacin y acreditacin. Asimismo, la CRT tiene a su cargo la prevencin de restricciones paraarancelarias al comercio exterior. CTNN: CTNN: Los Comits Tcnicos de Normalizacin Nacional, son rganos reconocidos por la Secretaria de Economa. Su funcin es la de elaborar normas en aquellas reas de la industria en las que no exista un Organismo Nacional de Normalizacin registrado. NTP: Normas Tcnica Peruana Normalizacin: La normalizacin o estandarizacin es la redaccin y aprobacin de normas que se establecen para garantizar el acoplamiento de elementos construidos independientemente, as como garantizar el repuesto en caso de ser necesario y garantiza la calidad de los elementos fabricados la seguridad de funcionamiento Norma Tcnica: o Es un documento tcnico que contiene las especificaciones de calidad, terminologa, mtodos de ensayo, informacin de rotulado, etc. o Es elaborado por el consenso de las partes interesadas (fabricantes, consumidores, Ministerios, universidades, etc.) o Est basada en los resultados de la EXPERIENCIA y el DESARROLLO TECNOLGICO. o Es aprobado por un Organismo de Normalizacin. o Es disponible al pblico. Normalizar: Productos/Materiales. Procesos Servicios.
Por qu se normaliza? Hablar el mismo lenguaje Quin normaliza? Las Normas Tcnicas Peruanas (NTP) son elaboradas por los Comits Tcnicos de Normalizacin, y las NTP son aprobadas por el Instituto Nacional de Defensa de la Competencia INDECOP y de la Proteccin de la Propiedad Intelectual (INDECOPI)I a travs de la Comisin de Reglamentos Tcnicos y Comerciales (CRT). A quin est dirigida? La norma est concebida para ser aplicada a ambas partes implicadas en el negocio (cliente vendedor) o solo a una de ellas para ser usada como contralor. Cualquier organizacin que imponga el uso de esta norma es responsable de especificar un grupo mnimo de: procesos, actividades, tareas. No existe certificacin para el estndar
Ciclo de vida del software Sucesin de etapas por las que pasa el software en su desarrollo, desde que se concibe la idea hasta que el software deja de utilizase. Cada etapa lleva asociada una serie de actividades y tareas que se deben realizar, y una serie de documentos que sern la salida de cada una de estas fases y que servirn de entrada a la fase siguiente. Proceso es un conjunto de actividades, actividades conjunto de tarea, una tarea es una accin que transforma unas entradas en unas salidas.
1
Vida software Ciclo de Vida desarrollo del software
El ciclo de vida es el conjunto de fases por las que pasa el sistema que se est desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere). Tambin se denomina a veces paradigma. Entre las funciones que debe tener un ciclo de vida se pueden destacar: Determinar el orden de las fases del proceso de software Establecer los criterios de transicin para pasar de una fase a la siguiente Definir las entradas y salidas de cada fase Describir los estados por los que pasa el producto Describir las actividades a realizar para transformar el producto Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar.
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Segn el modelo de ciclo de vida, la sucesin de fases puede ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecucin aportaciones a los resultados intermedios que se van produciendo (realimentacin).
Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del
proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupacin temporal de tareas impone requisitos temporales correspondientes a la asignacin de recursos (humanos, financieros o materiales).
Entregables: son los productos intermedios que generan las fases. Pueden ser materiales o
inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuacin o no a los requisitos funcionales y de condiciones de realizacin previamente establecidos.
Tipos de modelo de ciclo de vida

Las principales diferencias entre distintos modelos de ciclo de vida estn en: El alcance del ciclo dependiendo de hasta dnde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o en el extremo, toda la historia del producto con su desarrollo, fabricacin y modificaciones posteriores hasta su retirada del mercado. Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto, o de la organizacin. La estructura y la sucesin de las etapas, si hay realimentacin entre ellas, y si tenemos libertad de repetirlas (iterar).
10
2
Ciclo Modelos de Ciclo de Vida
Un modelo de ciclo de vida del software: Describe las fases principales de desarrollo de software Define las fases primarias esperadas de ser ejecutadas durante esas fases Ayuda a administrar el progreso del desarrollo Provee un espacio de trabajo para la definicin de un proceso detallado de desarrollo de software
En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de vida, y la eleccin de un modelo para un determinado tipo de proyecto es realmente importante; el orden es uno de estos puntos importantes. Existen varias alternativas de modelos de ciclo de vida. A continuacin se muestran algunos de los modelos tradicionales y ms utilizados.
11
2.1 Modelo en cascada

Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida.
2.2 Modelo en V
El modelo en v se desarroll para terminar con algunos de los problemas que se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducan hasta el final del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo ms pronto posible en el ciclo de vida. Tambin muestra que las pruebas no son slo una actividad basada en la ejecucin. Hay una variedad de actividades que se han de realizar antes del fin de la fase de codificacin.
12
2.3 Modelo iterativo

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos. Consiste en la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El cliente es quien despus de cada iteracin evala el producto y lo corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga las necesidades del cliente.
2.4 Modelo de desarrollo incremental

El modelo incremental combina elementos del modelo en cascada con la filosofa interactiva de construccin de prototipos. Se basa en la filosofa de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, slo con los requisitos bsicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin.
13
2.5 Modelo en espiral

Este modelo de desarrollo combina las caractersticas del modelo de prototipos y el modelo en cascada. El modelo en espiral est pensado para proyectos largos, caros y complicados. Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo en explicar las iteraciones. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un sistema operativo. Al ser un modelo de ciclo de vida orientado a la gestin de riesgos se dice que uno de los aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos. Tareas: Para cada ciclo habr cuatro actividades: 1. Determinar o fijar objetivos: a. Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario. b. Fijar las restricciones c. Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos d. Hay una cosa que solo se hace una vez: planificacin inicial o previa 2. Anlisis del riesgo: a. Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos 3. Desarrollar, verificar y validar (probar): a. Tareas de la actividad propia y de prueba b. Anlisis de alternativas e identificacin de resolucin de riesgos c. Dependiendo del resultado de la evaluacin de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. 4. Planificar: a. Revisamos todo lo que hemos hecho, evalundolo y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. El proceso empieza en la posicin central. Desde all se mueve en el sentido de las agujas del reloj.
14
Las cuatro regiones del grfico son: La tarea de planificacin: para definir recursos, responsabilidades, hitos y planificaciones La tarea de determinacin de objetivos: para definir los requisitos y las restricciones para el producto y definir las posibles alternativas La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos como de gestin La tarea de ingeniera: para disear e implementar uno o ms prototipos o ejemplos de la aplicacin
2.6 Modelo de Prototipos

El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente. El diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.
15
3
software Metodologas de desarrollo de software
Metodologas de Desarrollo de Software. Las Metodologas de Desarrollo de Software surgen ante la necesidad de utilizar una serie de procedimientos, tcnicas, herramientas y soporte documental a la hora de desarrollar un producto software. Dichas metodologas pretenden guiar a los desarrolladores al crear un nuevo software, pero los requisitos de un software a otro son tan variados y cambiantes, que ha dado lugar a que exista una gran variedad de metodologas para la creacin del software. Se podran clasificar en dos grandes grupos: Las metodologas orientadas al control de los procesos, estableciendo rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones que se usarn. Estas metodologas son llamadas Metodologas Pesadas. Las metodologas orientadas a la interactuacin con el cliente y el desarrollo incremental del software, mostrando versiones parcialmente funcionales del software al cliente en intervalos cortos de tiempo, para que pueda evaluar y sugerir cambios en el producto segn se va desarrollando. Estas son llamadas Metodologas ligeras/giles.
3.1 Metodologas Pesadas.

Son las ms tradicionales, se centran en la definicin detallada de los procesos y tareas a realizar, herramientas a utilizar, y requiere una extensa documentacin, ya que pretende prever todo de antemano. Este tipo de metodologas son ms eficaces y necesarias cuanto mayor es el proyecto que se pretende realizar respecto a tiempo y recursos que son necesarios emplear, donde una gran organizacin es requerida.
Process) 3.1.1. RUP (Rational Unified Process)

Una de las metodologas pesadas ms conocidas y utilizadas es la Metodologa RUP (Rational Unified Process) que divide el desarrollo en 4 fases que definen su ciclo de vida: -
Inicio: El objetivo es determinar la visin del proyecto y definir lo que se desea

realizar.
Elaboracin: Etapa en la que se determina la arquitectura ptima del proyecto. Construccin: Se obtiene la capacidad operacional inicial. Transmisin: Obtener el producto acabado y definido.
16
3.1.2. 3.1.2. Filosofa RUP.

La metodologa RUP tiene 6 principios clave: -
Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la

organizacin para la que se est desarrollando el software.
Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los

inversores del proyecto.
Colaboracin entre equipos: Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.,... Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad del producto y analizar la opinin y sugerencias de los inversores. Elevar el nivel de abstraccin: Motivar el uso de conceptos reutilizables. Enfocarse en la calidad: La calidad del producto debe verificarse encada aspecto de
la produccin.
3.1.3. Disciplina de desarrollo de RUP

Determina las etapas a realizar durante el proyecto de creacin del software. -
Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio
para el cual se est desarrollando el software.
Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del
sistema.
Anlisis y diseo: Trasladar los requisitos analizados anteriormente aun sistema

automatizado y desarrollar una arquitectura para el sistema.
Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el comportamiento deseado. Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado est presente. Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.
17
Diagrama del esfuerzo de actividades segn la etapa del proyecto
soporte 3.1.4. Disciplina de soporte RUP

Determina la documentacin que es necesaria realizar durante el proyecto. - Configuracin y administracin del cambio: Guardar todas las versiones del proyecto. - Administracin del proyecto: Administrar los horarios y recursos que se deben de emplear. - Ambiente: Administrar el ambiente de desarrollo del software. - Distribucin: Hacer todo lo necesario para la salida del proyecto.
3.1.5. Elementos del RUP.

Actividades: Procesos que se han de realizar en cada etapa/iteracin. Trabajadores: Personas involucradas en cada actividad del proyecto. Artefactos: Herramientas empleadas para el desarrollo del proyecto.
Puede ser un documento, un modelo, un elemento del modelo, etc.,...
18
3.2Metodologas 3.2Metodologas giles

Esta metodologa nace en febrero del 2001 en una reunin celebrada en Utah - EEUU. Principales ideas de la metodologa gil: Se encarga de valorar al individuo y las iteraciones del equipo ms que a las herramientas o los procesos utilizados. Se hace mucho ms importante crear un producto software que funcione que escribir mucha documentacin. El cliente est en todo momento colaborando en el proyecto. Es ms importante la capacidad de respuesta ante un cambio realizado que el seguimiento estricto de un plan.
Extrema 3.2.1. Programacin Extrema o XP (EXTREME PROGRAMMING)

Es una metodologa para el desarrollo de software y consiste bsicamente en ajustarse estrictamente a una serie de reglas que se centran en las necesidades del cliente para lograr un producto de buena calidad en poco tiempo. La Programacin Extrema es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software. Promueve el trabajo en equipo, preocupndose en todo momento del aprendizaje de los desarrolladores y estableciendo un buen clima de trabajo. Este tipo de mtodo se basa en una realimentacin continuada entre el cliente y el equipo de desarrollo con una comunicacin fluida entre todos los participantes, tambin busca simplificar las soluciones implementadas y coraje para los mltiples cambios. Este tipo de programacin es la adecuada para los proyectos con requisitos imprecisos, muy cambiantes y con un riesgo tcnico excesivo.
Programacin 3.2.2. Roles de la Programacin Extrema (XP)

Segn la propuesta de Beck los roles que nos podemos encontrar son los siguientes: -
Programador: El programador escribe las pruebas unitarias y produce el cdigo del

sistema.
Cliente: Escribe las historias de los usuarios y las pruebas funcionales para validar su
implementacin. El cliente da una gran prioridad a las historias de usuarios y decide cual implementar en cada iteracin centrndose en aportar mayor valor al negocio.
19
Encargado de Pruebas (Tester): Ayuda al cliente a escribir las pruebas funcionales.

Se encarga de ejecutar las pruebas con regularidad, difunde los resultados obtenidos al equipo y es el responsable de las herramientas que dan soporte a las pruebas. Encargado de Seguimiento (Tracker): Es el que proporciona la realimentacin al equipo. Realiza el seguimiento del proceso de cada iteracin y verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado en ello para la mejora de futuras estimaciones. Entrenador (Coach): Es el responsable del proceso global. Se encarga de proveer guas al equipo de forma que se apliquen las practicas XP y se vaya siguiendo el proceso correctamente. Consultor: Es un miembro externo del equipo con un conocimiento especfico en algn tema que es necesario para el proyecto, en el que surgen problemas. Gestor (Big boss): Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es la de coordinacin.
20
4
NTP-ISO/ 12207Norma Tcnica Peruana NTP-ISO/IEC 12207-2006
La presente Norma Tcnica Peruana establece un marco de referencia comn para los procesos del ciclo de vida del software, con una terminologa bien definida a la que puede hacer referencia la industria del software. Adems, contiene procesos, actividades y tareas para aplicar durante la adquisicin de un sistema que contiene software, un producto software puro o un servicio software, y durante el suministro, desarrollo, operacin y mantenimiento de productos software. No obstante, esta misma incluye tambin un proceso que puede emplearse para definir, controlar y mejorar los procesos del ciclo de vida del software. Esta norma es de cumplimiento obligatorio por las entidades integrantes del Sistema Nacional de Informtica, quienes tendrn un plazo de dieciocho (18) meses para implantar dicha norma a partir del 13 de mayo del ao 2004, fecha que fue emitida la Resolucin Ministerial N 179-2004-PCM, correspondiente a la aprobacin de uso obligatorio de la "NTP ISO/IEC 12207:2004 Tecnologa de la Informacin. Procesos del Ciclo de Vida del Software. 1 Edicin". Dichas entidades debern considerar en sus respectivos Planes Operativos Informticos (POI) las actividades necesarias con esa finalidad. La NTP ISO/IEC 12207 establece un proceso de Ciclo de Vida para el Software que incluye procesos y actividades que se aplican desde la definicin de requisitos, pasando por la adquisicin y configuracin de los servicios del sistema, hasta la finalizacin de su uso. Esta norma tiene como objetivo principal proporcionar una estructura comn para que compradores, proveedores, desarrolladores, personal de mantenimiento, operadores, gestores y tcnicos involucrados en el desarrollo del software utilicen un lenguaje comn, el cual se establezca en forma de procesos bien definidos.
21
5
Objetivo y campo de aplicacin
Objetivo Objetivo
ESTABLECER un marco referencial comn para los procesos del ciclo de vida del software, con una terminologa bien definida a la que puede hacer referencia la industria de software. CONTENER procesos, actividades y tareas para aplicar durante la adquisicin de un sistema que contiene software, un producto software puro o un servicio software y durante el suministro, desarrollo, operacin y mantenimiento de productos software.
Campo de aplicacin
Adquisicin de sistemas, productos y servicios software, al suministro, desarrollo, operacin y mantenimiento de productos software y a la parte software del firmware. Incluye aspectos de la definicin de sistemas necesarios para proporcionar el contexto de los productos y servicios software Es necesario que los procesos utilizados durante el ciclo de vida del software sean compatibles con los procesos usados durante el ciclo de vida del sistema. 1.1. Adaptacin de esta NTP Contiene un conjunto de procesos, actividades y tareas diseadas para ser adaptadas a los proyectos de software, esta adaptacin consiste en la eliminacin de los procesos, actividades y tareas no aplicables 1.2. Conformidad La conformidad se define como la ejecucin e todos los proceso, actividades y tareas seleccionadas de esta NTP para el proyecto software, mediante el proceso de adaptacin. Se indica que cualquier organizacin que imponga esta NTP como condicin para tener relaciones comerciales es responsable de especificar y hacer pblico el conjunto de procesos, actividades y tareas que constituyen la conformidad de esta NTP por parte del proveedor
22
1.3. Conformidad La conformidad es la ejecucin de todos los procesos, actividades y tareas seleccionadas de esta NTP para el proyecto de software, mediante el proceso de adaptacin.
1.4. Limitaciones Esta NTP describe la arquitectura de los procesos de ciclo de vida del software, pero no especifica los detalles de cmo implementar o llevar a cabo las actividades y tareas incluidas en los procesos, Aqu no se pretende establecer el nombre, el formato o el contenido explcito de la documentacin que se genere. Si bien esta NTP puede requerir la elaboracin de diversos documentos de tipo o clase similares
23
6
Referencias Normativas
Normas Tcnicas Internacionales
ISO/IEC 2382-1:1993 ISO/IEC 2382-20:1990 ISO/IEC 15504-2:2003 Information technology - Vocabulary Part 1: Fundamental terms Information technology - Vocabulary Part 20: System development Software Engineering Software Processes assessment Part 2: Performing an assessment Human-centred design for interactive systems General requirements for establishing anthropometric databases
ISO 13407-1:1999 ISO/IEC 15535:2003
Normas Tcnicas Peruanas

NTP-ISO 9000:2001 NTP-ISO 9001:2001 NTP-ISO 14001:2002 Sistema de gestin de la calidad de Fundamentos y vocabularios Sistemas de gestin de calidad, requisitos Sistemas de gestin ambiental. Especificacin con orientacin para su uso Ingeniera de Software Calidad de Producto- Parte 1: Modelo de calidad Tecnologa de la informacin Paquetes Software- Requerimientos de calidad y pruebas Tecnologa de la informacin Evaluacin de producto de softwareParte1: Vista general Ingeniera de software Calidad de producto- Parte 2: Mtricas externas Ingeniera de software Calidad de producto- Parte 3: Mtricas internas
NTP-ISO/IEC 9126-1:2004
NTP-ISO/IEC 12119:2005
NTP-ISO/IEC 14598-1:2004
NTP-ISO/IEC TR 9126-2:2004
NTP-ISO/IEC TR 9126-3:2004
24
25
26
7
Aplicacin
Es aqu donde se presentan los procesos el Ciclo de Vida del software que se adquiere, suministra, desarrolla, opera y mantiene. Los procesos, actividades, tareas que se pueden llevar a cabo durante el ciclo de vida del software se agrupan en: o o o 5 procesos principales. 8 procesos de apoyo. 4 procesos organizativos.
PROCESOS
ACTIVIDAD TAREAS
PROCESOS DEL CICLO DE VIDA
27
1. PROCESOS PRINCIPALES
Estos procesos dan servicios a las partes principales durante el ciclo de vida del software. Se llama parte principal aquello que da inicio o lleva a cabo el desarrollo, operacin o mantenimiento de los prodcutos del software. Estas parte principales son el adquiriente, el proveedor, el desarrollador, el operador y el responsable de mantenimiento de productos software. Los principales son: 1) Proceso de adquisicion: adquisicion:Define las actividades del adquiriente, la organizacin que adquiere el sistema, producto o servicio software. Este proceso consiste en las siguientes actividades: a. Inicio. b. Preparacion de la solicitud de propuesta. c. Preparacion y actualizacion del contrato. d. Seguimiento del proveedor. e. Aceptacion y finalizacion. 2) Proceso de suministro: Define las actividades del proveedor, organizacion que suministro: proporciona un sistema, producto o servicio software al adquiriente. Este proceso consiste en las siguientes actividades: a. Inicio. b. Preparacion de la respuesta. c. Contrato. d. Planificacion. e. Ejecucin y control. f. Entrega y finalizacion. 3) Proceso de desarrollo: Define las actividades del desarrollador, organizacin que desarrollo: define y desarrolla el producto software. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Analisis de los requerimientos del sistema. c. Diseo de la arquitectura del sistema. d. Analisis de los requerimientos software. e. Diseo de la arquitectura del software. f. Diseo detallado del software. g. Codificaicon y pruebas del software. h. Integracion del software. i. Pruebas de califiacion del software. j. Integracion del sistema. k. Pruebas de calificacion del sistema. l. Instalacion del software. m. Apoyo a la aceptacion del software.
28
4) Proceso de operacin: Define las actividades del operador, organizacin que operacin: proporciona el servicio de operar un sistema informatico en su entorno real, para sus usuarios. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Pruebas de operacin. c. Operacin del sistema. d. Soporte al usuario. 5) Proceso de mantenimiento: Define las actividades del responsable de mantenimiento, mantenimiento: organizacin que proporcina el servicio de mantenimiento del producto software; esto es, la gestion de las modificaciones al producto software para mantenerlo actualizado y operativo. Este proceso incluye la migracin y retirada del producto software. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Analisis de problemas y modificaciones. c. Implementacin de las modificaciones. d. Revisin/aceptacion del mantenimiento. e. Migracion. f. Retirada del sofware.
2. PROCESOS DE APOYO
Un proceso de apoyo es el que apoya a otro proceso como parte esencial del mismo, con un proposito bien definido y contribuye al xito y calidad del proyecto de software. Un proceso de apoyo se emplea y ejecuta por otro proceso,segn sus necesidades. Los proceso de apoyo son: 1) Proceso de documentacion: Define las actividades para el registro de informacion producida por un proceso de ciclo de vida. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Diseo y desarrollo. c. Produccion. d. Mantenimiento. 2) Proceso de gestion de la configuracion: Define las actividades de la gestion de la configuracin. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Identificacion de la configuracion. c. Control de la configuracion. d. Determinacion del estado de la configuracion. e. Evaluacion de la configuracion. f. Gestion de releases y entrega.
29
3) Proceso de aseguramiento de la calidad: Define las actividades para asegurar, de una manera objetiva, que los productos de software y los procesos son coformes a sus requerimientos especificados y se ajustan a sus planes establecidos. Revisin conjunta, auditoria, Verificacin y Validacin pueden ser utilizados como tcnicas de aseguramiento de la calidad. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Aseguramiento del producto. c. Aseguramiento del proceso. d. Aseguramiento del sistema de calidad. 4) Proceso de Verificacin: Define las actividades (para el adquiriente, proveedor o una Verificacin: parte independiente) para verificar hasta un nivel de detalle dependiente del proyecto software, los productos software. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Verificacin. Verifiacion del contrato. Verificacin del proceso. Verificacin de los requerimientos. Verificacin del diseo. Verificacin del codigo. Verificacin de la integracion. Verificacin de la documentacion. 5) Proceso de Validacin: Define las actividades (para el adquiriente, proveedor o una Validacin: parte independiente) para validar los productos software del proyecto software. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Validacin. 6) Proceso de Revisin conjunta: Define las actividades para evaluar el estado y conjunta: productos de una actividad. Este proceso puede ser empleado por cualquiera de las dos partes, donde una de las partes (la revisora) revise la otra parte (la parte revisada), de una manera conjunta. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Revisin de la gestion del proyecto. c. Revisin tcnica.
7) Proceso de auditoria: Define las actividades para determinar la conformidad con los auditoria: requerimientos, planes y contrato. Este proceso puede ser empleado por dos partes
30
cualesquiera, donde una parte (la auditora) audita los productos software o actividades de otra parte (la auditada). Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Auditoria. 8) Proceso de solucin de problemas: Define las actividades para analizar y eliminar los problemas: problemas (incluyendo las no conformidades) que sean descubiertos durante la ejecucin del proceso de desarrollo, operacin, mantenimiento u otros procesos, cualesquiera que sea su naturaleza o causa. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Solucin de problemas.
3. PROCESOS ORGANIZATIVOS
Los procesos organizativos del ciclo de vida se emplean por una organizacin para establecer e implementar una infraestructura constituida por procesos y personal asociado al ciclo de vida y para mejorar continuamente esta infrestructura. Se usa habitualmente fuera del mbito de proyecto y contratos especficos; sin embargo, la experiencia adquirida mediante dichos proyectos y contratos contribuye a la mejora de la organizacin. Los procesos organizativos son: 1) Proceso de gestion: Define las actividades basicas de gestion, incluyendo de proyectos la gestion d eproyectos, durante un proceso del ciclo de vida. Este proceso consiste en las siguientes actividades: a. Inicio. b. Planificacion. c. Ejecucin y control. d. Revisin y evaluacion. e. Finalizacion. 2) Proceso de infraestructura: Define las actividades basicas para establecer la infraestructura de un proceso del ciclo de vida. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Establecimiento de la infraestructura. c. Mantenimiento de la infraestructura. 3) Proceso de mejora de proceso: Define las actividades basicas que una organizacin (adquiriente, proveedor, desarrollador, operador, responsable de mantenimineto o gestor de otro proceso) lleva a cabo para establecer, medir, controlar y mejorar sus proceso del ciclo de vida. Este proceso consiste en las siguientes actividades:
31
a. Establecimiento del proceso. b. Evaluacion del proceso. c. Mejora del proceso. 4) Proceso de recursos humanos: Define las actividades basicas para conseguir personal adecuadamente capacitado. Este proceso consiste en las siguientes actividades: a. Implementacin del proceso. b. Desarrollo del material de formacion. c. Implementacin del plan de formacion.
PROCESO DE ADAPTACION
El proceso de adaptaciones un proceso para llevar a cabo las adaptaciones basicas de esta NTP a un proyecto software. Este proceso consiste en las siguientes actividades: a. Identificacion del entorno del proyecto. Se debera identificar las caracteristicas del entorno del proyecto que van a influir en la adaptacion. Alguna de estas caracteristicas pueden ser: modelo del ciclo de vida; actividad actual del ciclo de vida del sistema; requerimientos del sistema y requerimientos del software; politicas, procedimientos y estrategias de la organizacin: tamao, aspectos criticos y tipo del sistema, producto o servicio de software; numero de personal y partes involucradas. b. Solicitud de entradas. Esta actividad tiene como tarea solicitar entradas de la organizacin que se veran afectadfas por las decisiones de la adaptacion. Sepuede involucrar a los usuarios, personal de soporte, responsables de la contratacion y potenciales ofertantes. c. Seleccin de procesos, actividades y tareas. Se deberan decidir los proceso, actividades y tareas a llevar a cabo inluyendo la documentacion a desarrollar y quien es responsable de ellas. Por este motivo se deberia evaluar esta NTP frente a los relevantes obtenidos en la identifiacion del entorno del proyecto y en la solicitud de entradas. Los procesos, actividades y tareas que se decidieron y no se encuentran en esta NTP se deberan especificar en el propio contrato. Conviene que se evaluen los proceso del ciclo de vida de la organizacin para determinar si pueden contemplar estos proceso, actividades y tareas. En esta NTP, los requerimientos se indican mediante tareas con debera u otros verbos en futuro. Conviene que estas tareas se consideren cuidadosamente por si se deben mantener o eliminar en un proyecto dado o sector de negocios. Factores a tener en consideracion son
32
limitarse a ellos son: riesgo, costo,plazo, rendimiento, tamao, aspectos criticos e interfaz humana. d. Documentacion de las decisiones y razones de las adapataciones. Se deberan documentar todas las decisiones de adaptacion, junto con las razones de las decisiones.
No hay dos proyectos iguales. La variacion en los procedimientos y politicas de las organizaciones, en los metodos y estrategias de adquisicion, en el tamao y complejidad de los proyectos, en los requeriemientos del sistema y metodo de desarrollo, entre otras cosas, influyen en como un sistema se adquiere, desarrolla, opera o mantiene. Enta NTP se ha escrito para que un proyecto generico se adapte a tales variaciones tanto como sea posible. Asi pues, en interes de la reduccion de costos u mejora de la calidad, conviene que esta NTP se adaptada a proyectos concretos. Se deberian incluir en la adaptacion todas las partes involucradas en el proyecto.
33
34
8
Desarrollo de caso prctico
ISOEl Proceso de Mantenimiento en ISO-12207
Como hemos visto en el punto 4, la norma ISO considera el mantenimiento como uno de los procesos principales del ciclo de vida del software, ya que define las actividades de la organizacin (maintainer) que proporciona el servicio de mantener del producto software; es decir, la gestin de las modificaciones del producto software con el fin de mantenerlo actualizado y adecuado a su uso. En la definicin de ISO, el mantenimiento incluye la migracin y la retirada del software y consta de las siguientes actividades:
Implementacin del proceso
En esta actividad se desarrollan los planes correspondientes para llevar a cabo las actividades y tareas del mantenimiento. Tambin se deben definir los procedimientos necesarios para la gestin de problemas y peticin de modificaciones (empleando el proceso de resolucin de problemas), e implementar el proceso de gestin de la configuracin para gestionar las modificaciones del sistema existente.
Anlisis de problemas y modificaciones
Esta actividad consiste en analizar los problemas o peticiones de modificacin con el fin de evaluar su impacto en el sistema y la organizacin existentes, determinando el tipo de modificacin (preventiva, correctiva, etc.), su alcance (tamao, coste, tiempo, etc.) y su gravedad (rendimiento, seguridad, etc.). La organizacin encargada del mantenimiento debe tambin verificar el problema, elaborar distintas opciones para implementar las modificaciones, y documentar el problema o la peticin de modificacin, as como los resultados del anlisis y las opciones de implementacin. Por ltimo, deber obtener la aprobacin para la opcin seleccionada.
Implementacin de las modificaciones
En esta actividad se incluyen todas las tareas relativas a determinar qu documentacin, unidades de software y versiones deben modificarse, y se utiliza el proceso de desarrollo para implementar las modificaciones. Los requisitos del proceso de desarrollo debern complementarse, segn el estndar, de la siguiente manera:
35
a) Se debern definir y documentar los criterios de evaluacin y prueba para probar y evaluar las partes del sistema (unidades, componentes y elementos de la configuracin) modificadas y no modificadas. b) Se deber asegurar la completa y correcta implementacin de los requisitos nuevos y modificados, as como que no se vean afectados los requisitos originales. Tambin se debern documentar los resultados de las pruebas.
mantenimiento Revisin y aceptacin del mantenimiento
Esta actividad consiste en la revisin de la integridad del sistema modificado. La deben llevar a cabo la organizacin encargada del mantenimiento junto con la organizacin que autoriz la modificacin. La organizacin encargada del mantenimiento deber obtener tambin la aprobacin de terminacin satisfactoria de la modificacin.
Migracin
ISO/IEC especifica que se deber asegurar que cualquier software o dato producido o modificado durante la migracin se ajuste a las normas establecidas. El estndar aconseja desarrollar un plan de migracin en el que se especifiquen al menos las siguientes cuestiones: a) b) c) d) e) f) Anlisis de requisitos y definicin de la migracin. Desarrollo de herramientas de migracin. Conversin del software y de los datos. Ejecucin de la migracin. Verificacin de la migracin. Soporte del ento rno antiguo en el futuro.
En esta actividad tambin se incluye una tarea de revisin post-operacin con el fin de evaluar el impacto que suponga el cambio al nuevo entorno. Por ltimo, en el estndar se insiste en que se deber poder acceder a los datos utilizados o asociados al antiguo entorno de acuerdo con los requisitos organizacionales para la proteccin y auditora aplicables a los datos.
Retirada de software
De acuerdo al estndar, es necesario desarrollar y documentar un plan de retirada que aborde cuestiones como las siguientes:
36
Cese de soporte total o parcial despus de un cierto tiempo. Archivo del producto software y su documentacin asociada. Responsabilidad sobre cuestiones de soporte residual futuro. Transicin al nuevo producto. Accesibilidad de copias de datos.
Es importante que se tenga en cuenta a los usuarios a la hora de planificar la retirada del software y que se les notifique el plan. Las notificaciones debern incluir lo siguiente: a) Descripcin de la sustitucin o actualizacin con su fecha de disponibilidad. b) Informe de por qu no se soportar ms el software. c) Descripcin de otras opciones de soporte disponibles una vez que se haya eliminado el soporte. Tambin se recomienda llevar a cabo operaciones en paralelo entre el software nuevo y el retirado, as como proporcionar formacin a los usuarios. Se deber notificar a todos los involucrados el momento previsto para la retirada. Tambin se debe archivar toda la documentacin, ficheros y cdigo apropiados. Por ltimo, al igual que en el caso de la migracin, se deber poder acceder a los datos utilizados por, o asociados con, el software retirado de acuerdo a los requisitos organizacionales de proteccin y auditora aplicables a los datos.
37
TABLA DE RESUMEN
En la Tabla recogemos las diferentes actividades y tareas del Proceso de Mantenimiento.
En la Tabla observamos cmo ISO/IEC propone la introduccin de un nuevo proceso de desarrollo dentro del proceso de mantenimiento, pero considerndolo una tarea ms (la dcima tarea del mantenimiento) de la tercera actividad (implementacin de las modificaciones). Para facilitar el seguimiento de los razonamientos que expondremos a continuacin, fundimos en la siguiente tabla las dos anteriores, y usaremos la notacin 10.1, 10.2, etc. para referirnos a las 13 actividades del proceso de desarrollo que deben realizarse como dcima tarea del mantenimiento
38
39
CASO DE ESTUDIO MANTEMA

Metodologia de mantenimiento de software, basado en el ISO/IEC 12207, una metodologia en un sentido habitual se refiere a una serie de metodos o tecnicas relacionada. Una metodologia tiene: Un modelo de proceso. Un conjunto de tecnicas. Un conjunto de entregables. Guias para la gestion del proyecto, lo que incluye roles, definicion de una estructura del equipo, etc. Un conjunto de metrica. Herramientas
Estructura General del modelo de proceso
Uso del proceso de adaptacion de la propia NTP-ISO/IEC 12207 en actividades y tareas para: Incorporar (Relaciones con Sub-contratistas) Redefinir (Migracion paso hacia el mantenimiento adaptativo) Soportar la contratacion de terceros para el mantenimiento
40
Caracteristicas adicionales de la metodologia

Tcnicas
Ingenieria Inversa. Reingenieria.
Entregables
Documentos de posibles soluciones (en mantenimiento perfectivo). Programa corregido (en mantenimiento correctivo urgente).
Definicion de roles
Cliente. Usuarios. Organizacin de mantenimientos.
Mtricas
Nivel de cumplimiento (medido en dias de retraso).
Herramientas
MANTIS, software que automatiza la metodologia.
38
En las siguientes dos tablas se ofrece resumidamente este conjunto de actividades y tareas.
42
44
Conclusiones
La NTP ISO/IEC 12207:2006 ayuda a ordenar los procesos del ciclo de vida del software siempre en cuando se tenga definida una metodologa de desarrollo de software y la UTILIZA, entonces le ser ms fcil implementarla. Caso contrario en que usted no desarrolla software, pero compra soluciones informticas, debe usar solo las partes que le corresponde y alinearla a las disposiciones vigentes. Conjunto de recomendaciones de como se hacen bien las cosas. Una norma probada por diversos sectores: militar, comercial, industrial.
45
Bibliografa
NTP ISO/IEC 12207 2006 TECNOLOGIA DE LA INFORMACION. Procesos del ciclo de vida del software. 2a. ed. 2006/07/28
Tesis doctoral defendida en del Departamento de Informtica de la Universidad de Castilla-La Mancha el 18 de julio de 2000 - Autor: Macario Polo Usaola
www.indecopi.gob.pe/ www.myt.com.pe Diario El Peruano

NTP12207 1

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

NTP12207 1

Diunggah oleh

Hak Cipta:

Format Tersedia

Ao del Centenario de Machu Picchu para el Mundo

04 de agosto del 2011 del

SOFTWARE / CICLO DE VIDA /

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

INSTITUCIONES QUE PARTICIPARON EN ELABORACIN DE LA NTP

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Tipos de modelo de ciclo de vida

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

2.1 Modelo en cascada

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

2.3 Modelo iterativo

2.4 Modelo de desarrollo incremental

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

2.5 Modelo en espiral

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

2.6 Modelo de Prototipos

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

3.1 Metodologas Pesadas.

Process) 3.1.1. RUP (Rational Unified Process)

Inicio: El objetivo es determinar la visin del proyecto y definir lo que se desea

3.1.2. 3.1.2. Filosofa RUP.

Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la

Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los

3.1.3. Disciplina de desarrollo de RUP

Anlisis y diseo: Trasladar los requisitos analizados anteriormente aun sistema

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Diagrama del esfuerzo de actividades segn la etapa del proyecto

soporte 3.1.4. Disciplina de soporte RUP

3.1.5. Elementos del RUP.

Puede ser un documento, un modelo, un elemento del modelo, etc.,...

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

3.2Metodologas 3.2Metodologas giles

Extrema 3.2.1. Programacin Extrema o XP (EXTREME PROGRAMMING)

Programacin 3.2.2. Roles de la Programacin Extrema (XP)

Programador: El programador escribe las pruebas unitarias y produce el cdigo del

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Encargado de Pruebas (Tester): Ayuda al cliente a escribir las pruebas funcionales.

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

ISO 13407-1:1999 ISO/IEC 15535:2003

Normas Tcnicas Peruanas

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

PROCESOS DEL CICLO DE VIDA

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS

ISOEl Proceso de Mantenimiento en ISO-12207

Implementacin del proceso

Anlisis de problemas y modificaciones

Implementacin de las modificaciones

mantenimiento Revisin y aceptacin del mantenimiento

Universidad Nacional Tecnolgica del Cono Sur de Lima UNTECS