Contenido

Contenido ............................................................................................................................................ 1 1 Procesos de la Ingeniera de Requerimientos ............................................................................. 3 1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.2 1.2.1 1.2.2 1.2.3 1.3 1.3.1 1.3.2 1.4 1.4.1 1.4.2 2 2.1 2.1.1 2.1.2 2.2 2.3 2.3.1 2.3.2 2.3.3 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8 Requerimientos de proceso ................................................................................................ 3 Marco de trabajo para el proceso .................................................................................... 3 Integracin del modelo de capacidad de madurez (IMCM) ............................................ 5 Patrones del proceso....................................................................................................... 5 Evaluacin del proceso ................................................................................................... 6 Evaluacin Del Proceso Del Software............................................................................. 7 Requerimientos de los usuarios ........................................................................................ 12 Anlisis del problema .................................................................................................... 12 Clasificar los requerimientos ......................................................................................... 12 Evolucin de los requerimientos ................................................................................... 13 Requerimientos para el anlisis y la negociacin ............................................................. 13 Anlisis de sistemas ...................................................................................................... 13 Negociacin ................................................................................................................... 14 Requerimientos para la administracin ............................................................................. 15 Dificultades para definir los requerimientos .................................................................. 18 Los principales beneficios que se obtienen de la ingeniera de requerimientos ........... 18 Planeacin del tiempo ....................................................................................................... 19 Objetivos de la planificacin del proyecto ..................................................................... 19 Actividades asociadas al proyecto de software. ........................................................... 19 Evaluacin del Costo/Beneficio (investigacin personal).................................................. 19 Estudio de viabilidad.......................................................................................................... 20 Determinacin de la viabilidad del proyecto. ................................................................. 20 Determinacin de recursos ........................................................................................... 21 Evaluacin de la viabilidad ............................................................................................ 21 Planificacin de la Documentacin ................................................................................... 22 Documentacin .............................................................................................................. 23 Documentacin tecnica del desarrollo .......................................................................... 24 Documentacin de construccin ................................................................................... 26 Documentacion de uso .................................................................................................. 27 Normas de presentacin ............................................................................................... 28 Contenido del documento de Especificacion del Sistema ............................................ 29 Contenido del Documento de Diseo del Sistema ........................................................ 30 Contenido del Manual de Operacin del Sistema ......................................................... 31

Planificacin del sistema ............................................................................................................ 19

2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 2.5.8 3 3.1

Gestin de la configuracin del software (GCS) ............................................................... 31 Qu es? ....................................................................................................................... 32 Lnea base ..................................................................................................................... 32 El proceso de gestin de la configuracin de software (GCS)...................................... 32 Identificacin de Objetos de la Configuracin de Software ........................................... 33 Control de versiones...................................................................................................... 33 Control de cambios........................................................................................................ 34 Auditoria de la Configuracin ........................................................................................ 34 Informes de Estado ....................................................................................................... 34 Preparar exposicin........................................................................................................... 36

Metodologas de Anlisis de Riesgo .......................................................................................... 36

1 Procesos de la Ingeniera de Requerimientos

1.1 Requerimientos de proceso
El proceso de software es un marco de trabajo para las tareas que se requieren en la construccin de software de calidad. La ingeniera del software es una tecnologa estratificada. Cualquier enfoque de la ingeniera debe estar sustentado en compromiso de calidad. La base que soporta la ingeniera del software es un enfoque de calidad. La base de la ingeniera del software es el estrato del proceso. El proceso de la ingeniera del software es el elemento que mantiene juntos los estratos de la tecnologa y que permite el desarrollo racional y a tiempo del software de computadora. El proceso define un marco de trabajo que debe establecerse para la entrega efectiva de la tecnologa de la ingeniera del software.

1.1.1 Marco de trabajo para el proceso

Establece la base para un proceso de software completo a identificar un nmero pequeo de actividades del marco de trabajo aplicables a todos los proyectos de
3

software. Adems abarca un conjunto de actividades sombrilla a lo largo del proceso del software. Cada actividad contiene un conjunto de acciones de ingeniera de software. El conjunto de tareas es una serie de tareas de trabajo. Comunicacin. Implica colaboracin y comunicacin con los clientes, adems abarca la investigacin de requisitos y otras actividades relacionadas. Planeacin. Establece un plan para el trabajo de la ingeniera de software. Modelado. Abarca la creacin de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software. Construccin. Combina la generacin del cdigo y la realizacin de pruebas necesarias. Despliegue. El software se entrega al cliente, quien evala el producto y proporciona informacin basada en su evaluacin. Al marco de trabajo lo completa una serie de actividades sombrilla que se aplican durante el proceso del software. Seguimiento y control del proyecto de software: permite que el equipo de software evalu el progreso comparndolo con el plan del proyecto y as tomar las acciones necesarias para mantener el programa. Gestin del riesgo: evala los riesgos que pudieran afectar los resultados del proyecto o la calidad del producto. Aseguramiento de la calidad del software: define y conduce las actividades requeridas para asegurar la calidad del software. Revisiones tcnicas formales: evala los productos del trabajo de la ingeniera del software en un esfuerzo encaminado a descubrir y eliminar los errores antes de que estos se propaguen hacia la siguiente accin o actividad. Medicin: define y recolecta mediciones del proceso, el proyecto y el producto. Gestin de la configuracin del software: maneja los efectos del cambio a travs del proceso del software. Gestin de la reutilizacin: define los criterios para la reutilizacin de productos del trabajo y establece mecanismos para la creacin de componentes reutilizables.

Preparacin y produccin del trabajo de trabajo: abarca las actividades requeridas para crear productos del trabajo como modelos, documentos, registros, formatos y listas.

1.1.2

Integracin del modelo de capacidad de madurez (IMCM)

Una organizacin debe crear un modelo de proceso que se ajuste a las directrices establecidas por la integracin del modelo de capacidad de madurez. El Instituto de Ingeniera del Software (SEI) ha desarrollado un modelo completo de un amplio proceso basado en conjunto de capacidades de sw. El modelo continuo IMCM describe un proceso en 2 dimensiones. Cada rea del proceso se evala de manera formal contra las metas y practicas especficas y se clasifica de acuerdo con los siguientes niveles de capacidades: Nivel 0: Incompleto. Aun no se realiza o todava no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad. Nivel 1: Realizado. Nivel 2: Administrado. Los clientes estn implicados de manera activa en el rea de proceso. Nivel 3: Definido. El proceso est adaptado al conjunto de proceso estndar de la organizacin. Nivel 4: Administrado en forma cuantitativa. El rea de proceso se controla Nivel 5: Mejorado. El rea de proceso se adapta y mejora mediante el uso de medios cuantitativos para conocer las necesidades cambiantes del cliente.

1.1.3 Patrones del proceso

Un patrn de proceso ofrece una plantilla: un mtodo consistente para describir una caracterstica importe del proceso de software. Mediante la combinacin de patrones, un equipo de software puede construir un proceso que satisfaga lo mejor posible las necesidades de un proyecto. Ambler propuso la siguiente plantilla para describir un patrn de proceso: Nombre del patrn. Asignar un nombre que describa su funcin dentro del software. Propsito. Se describe con brevedad el objetivo del patrn Tipo. Se especifica el tipo de patrn. Los patrones de tarea definen una accin de la ing. Del software una tarea de trabajo que es parte del proceso y relevante para una prctica exitosa de la ing. De software. Los patrones de escenario definen una actividad del marco de trabajo para el proceso.

 Los patrones de fase definen la secuencia de actividades del marco trabajo que ocurre junto con el proceso. Contexto inicial. Se describen las condiciones en las cuales se aplica el patrn. Problema. Se describe el problema que debe resolver el patrn. Solucin. Se describe la implementacin del patrn. Contexto resultante. Se describen las condiciones que habr una vez que el patrn haya sido implementado con xito. Patrones relacionados. Se proporciona una lista de todos los patrones de proceso directamente relacionados con este. Usos conocidos/ejemplos. Se indican los ejemplos especficos en los cuales el patrn es aplicable.

1.1.4 Evaluacin del proceso

La existencia de un proceso de sw no es garanta de que este ser entregado a tiempo, de que satisfar las necesidades del cliente, o de que mostrara las caractersticas tcnicas que conducirn a caractersticas.

Proceso del Software

Evaluacin del proceso de sw

Identifica modificadores Conduce a Conduce a Identifica capacidades y riesgos

Mejoramiento de proceso de sw

Motiva

Determinacin de la capacidad

TAREA Los enfoques para la evaluacin del proceso de software Mtodo de IMCM para el mejoramiento del proceso (MEIEMP) CMM mejoramiento del proceso interno (ABC MPI) Estndar SPICE (ISO/IEC15504) ISO 9001:2000 PARA Software

1.1.5 Evaluacin Del Proceso Del Software

La existencia de software no es garanta de que satisfaga las necesidades de los clientes .los patrones de proceso deben ir acompaados de una prctica solida de la Ing. de software. El mtodo de evaluacin de la IMCM estndar para el mejoramiento del proceso (MEIEMP) ofrece 5 pasos para evaluar un proceso de software como. Iniciacin Diagnostico Establecimiento La accin Aprendizaje La apreciacin basada en el CMM para el mejoramiento del proceso interno (ABC MPI) Establece la tcnica de diagnstico que sirve para evaluar la madures relativa de la organizacin de software. El estndar SPICE (ISO /IEC 15504) pretende ayudar a las organizaciones para la evaluacin objetiva con sus requisitos establecidos. La organizacin ISO ha establecido el estndar ISO 9001:2000[ISO00] para elaborar productos de ms alta calidad. Esta organizacin implementa gestiona y mejora la efectividad de los procesos para conseguir los objetivos de la organizacin. Los objetivos de ISO son: Planear.- establecer los objetivos y tareas. Hacer.- implementar el proceso de software. Revisar.- mide el proceso para la gestin de calidad. Acta.- en el mejoramiento de proceso de software. http://www.buenastareas.com/ensayos/Trabajo/24306222.html

10

11

1.2 Requerimientos de los usuarios Es difcil definir cuantos o cuales son los requerimientos de los usuarios, ya que cada usuario piensa de forma diferente y de acuerdo a sus necesidades. Dificultades para definir los requerimientos: Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras. Tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento estn relacionados unos con otros. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

1.2.1 Anlisis del problema

El objetivo es entender las verdaderas necesidades del negocio. Se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Quin usara el sistema que se va a desarrollar? Quin desarrollara el sistema? Quin probara el sistema? Quin documentara el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema? Quin mercadeara, vender, y/o distribuir el sistema? Quin se beneficiara por el retorno de inversin del sistema?

1.2.2 Clasificar los requerimientos

Busca identificar la importancia que tiene un requerimiento en trminos de implementacin. A esta caracterstica se le conoce como prioridad y debe ser usada para establecerla secuencia en que ocurrirn las actividades de diseo y prueba de cada requisito. Evaluar factibilidades y riesgos: involucra la evaluacin de factibilidades tcnicas, factibilidades operacionales, factibilidades econmicas.

12

Actividad de evaluacin y negociacin, se incrementa la comunicacin entre el equipo de desarrollo y los clientes o usuarios. La validacin de requerimientos es importante es de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.

1.2.3 Evolucin de los requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y como los objetivos de la organizacin pueden cambiar. Pueden cambiar por diferentes razones Al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Cambi el problema que se estaba resolviendo. Los usuarios cambiaron su forma de pensar o sus percepciones. Cambio el ambiente de negocios. Cambio el mercado en el cual se desenvuelve el negocio. Ingeniera de requerimientos El proceso de establecer los servicios que el cliente requiere de un sistema y los lmites bajo los cuales opera y se desarrolla son: TAREA Ejemplos. Los requerimientos funcionales y no funcionales

1.3

Requerimientos para el anlisis y la negociacin

1.3.1 Anlisis de sistemas

Significa descomponer en sus componentes para estudiar cada uno tanto como un ente aislado como en interaccin con el resto. Definicin por el estndar IEEE Sed. 610[1990] El anlisis de requisitos es el proceso del estudio de las necesidades de software, as como el proceso de estudio y refinamiento de dichos requisitos. Se define como una condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. La fase de anlisis de requisitos segn el estndar IEEE 1074 [1991] consiste en 3 grandes actividades: Definir los requisitos del sw. Se trata de una tarea iterativa para crear una definicin o especificacin preliminar de los requisitos que debe cumplir el sw.

13

 Definir los requisitos de las interfaces del sw con el resto del sistema y con el exterior. Integrar los requisitos en un documento de la especificacin y asignarles prioridades. Otra manera de describir las actividades que se realizan en la fase de anlisis de requisitos: 1. Extraccin o determinacin de requisitos. 2. Anlisis de requisitos. 3. Especificacin de requisitos. 4. Validacin de los requisitos. Distintas tcnicas para el anlisis Para la extraccin o determinacin de los requisitos se emplean de recopilacin de informacin (observacin, cuestionarios, entrevistas, etc.) Para el anlisis y la especificacin existen no solo tcnicas graficas (como diagramas de flujo de datos) sino tambin como el anlisis estructurado. Para la validacin suele recurrirse a listas de comprobacin de distintos aspectos con tcnicas de revisin. TAREA Explicado cmo se realiza el anlisis costo beneficio Evaluacin de los riesgos. Determina en que el indicador se ver reflejado que un problema se presente, se deben establecer puntos de referencia para cada riesgo, segn su prioridad de atencin, se sale del manejo aceptable. Proyeccin de riesgos. Determina la probabilidad de que un riesgo ocurra y las consecuencias que puede tener, por ejemplo: incremento de costos, cancelacin del proyecto, insatisfaccin del cliente.

1.3.2 Negociacin
Adecuado significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta los riesgos. Descubrir problemas potenciales Clasificar los requerimientos Mandatario, deseable o innecesarios. Requerimiento informativo, puede esperar para fases posteriores, innecesario Incluir requerimiento mandatario, discutir los deseables y descartar los innecesarios. Documentacin de todos los requerimientos Mostrar todos los requerimientos a los involucrados Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos
14

Establecer las relaciones entre requerimientos que indiquen independencias Negociar con flexibilidad para que exista un beneficio mutuo Enfocarse en intereses y no en posiciones.

1.4

Requerimientos para la administracin

La mayor causa de problemas en el desarrollo de sistemas (incumplimiento de fechas, presupuestos errneos, etc.) mbito problema, mbito solucin, mbito recursos El alcance del proyecto (nmero de requerimientos a satisfacer). El alcance del proyecto lo definir el tiempo y el financiamiento.

15

16

Caractersticas de los requerimientos Las caractersticas de los requerimientos son sus propiedades principales. Necesario: es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: es conciso si es fcil de leer y entender. Completo: est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: es consistente si no es contradictorio con otro requerimiento. No ambiguo: cuando tiene una sola interpretacin.

17

Verificable: cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

1.4.1 Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo) Existen muchos tipos de requerimientos y diferentes niveles de detalle La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

1.4.2 Los principales beneficios que se obtienen de la ingeniera de requerimientos

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la Ing. de requisitos (IR) consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento. Disminuye costos y retrasos del proyecto. Mejora la calidad del sw. Mejora la comunicacin entre equipos. Evita rechazos de usuarios finales. Personal involucrado en la Ing. de requerimientos Usuario final Usuario lder Personal de mantenimiento Anlisis y programadores Personal de pruebas

18

2 Planificacin del sistema

2.1 Planeacin del tiempo
Estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.

2.1.1 Objetivos de la planificacin del proyecto

ES proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, costos y planificacin temporal. Las estimaciones deberan definir los escenarios del mejor caso y del peor caso, de modo que los resultados del proyecto pueden limitarse.

2.1.2 Actividades asociadas al proyecto de software.

2.1.2.1 mbito del software Es la primera actividad de llevada a cabo durante la planificacin del proyecto de software.

2.2

Evaluacin del Costo/Beneficio (investigacin personal)

Debido a que el crecimiento de la estimacin de costos es una actividad compleja, existe un crecimiento industrial de compaas dedicadas a ofrecer diferentes marcas comerciales de herramientas de estimacin de costos en el mercado. A partir del 2005, algunas de esas herramientas de estimacin son: COCOMO II, CoStar, CostModeler, CostXpert, KnowledgePlan, PRICE S, SEER, SLIM y SoftCost. Algunas de las herramientas de estimacin de costos ms antiguas, no estn activamente en el mercado pero todava son utilizadas, tales como: CheckPoint, COCOMO, ESTIMACS, REVIC y SPQR/20, ya que su uso no es apoyado por los vendedores, por lo que su utilizacin est en declive. Mientras estos instrumentos de estimacin fueron desarrollados por empresas diferentes y no son idnticos, ellos realmente tienden a proporcionar un ncleo de funciones comunes. Los rasgos principales de instrumentos de estimacin de software comerciales se incluyen estos atributos: Lgica de dimensionamiento para especificaciones, cdigo fuente y casos de evaluacin Nivel de fase, nivel de actividad, y estimacin de nivel de tarea Ajustes para perodos de trabajo especficos, vacaciones y horas extraordinarias Ajustes para salarios locales e ndices de carga Ajustes para varios proyectos de software como militares, sistemas, comerciales, etc. Apoyo para mtricas de puntos de funcin, mtricas de lneas de cdigos o ambas Apoyo para backfiring, es decir, convertir lneas de cdigos a puntos de funcin
19

 Apoyo tanto para nuevos proyectos como a proyectos de mejora y mantenimiento Algunas herramientas de estimacin tambin incluyen funciones ms avanzadas como: Estimacin de fiabilidad y calidad Anlisis de valor y riesgo Retorno de Inversin Posibilidad de compartir datos con herramientas de administracin de proyectos Medios de medicin para reunir datos histricos Costo y tiempo para completar estimaciones que combinan datos histricos con datos proyectados Apoyo para evaluaciones de procesos de software Anlisis estadstico de mltiples proyectos y anlisis de cartera Conversin monetaria para acordar proyectos en el exterior

2.3

Estudio de viabilidad
2.3.1 Determinacin de la viabilidad del proyecto.

El objetivo es recopilar suficientes datos para los directivos a su vez, tengan los elementos necesarios para decidir si debe procederse a realizar un estudio de sistemas. Los datos se pueden recopilar mediante las entrevistas. El tiempo debe ser reducido y abarcar diversas actividades. El analista de sw funge como catalizador y experto de soporte tcnico. Las oportunidades se pueden considerar como la contraparte de los problemas.

Las mejoras a los sistemas se pueden definir como cambios que darn como resultados benficos crecientes y valiosos: 1. Aceleracin de un proceso. 2. Optimizacin de un proceso al eliminar pasos innecesarios o duplicados. 3. Combinacin de procesos. 4. Reduccin de errores en la captura de informacin mediante la modificacin de formularios y pantallas de despliegue. 5. Reduccin de almacenamiento redundante. 6. Reduccin de salidas redundantes. 7. Mejora en la integracin de sistemas y subsistemas. Es til para el analista de sistemas elaborar una cuadricula de impacto de la viabilidad, que le sirva para comprender y evaluar los impactos (si los hay) que tendrn las mejoras a los sistemas existentes.

20

Tambin es importante la manera en que las mejoras a los sistemas existentes (manuales o automatizados) afectan los objetivos corporativos. Estos objetivos incluyen: 1. Mejoras de las ganancias corporativas. 2. Apoyo a la estrategia competitiva de la organizacin. 3. Mayor cooperacin con distribuidores y socios. 4. Incremento del apoyo a las operaciones internas con el fin de producir bienes y servicios de manera ms eficiente y eficaz. 5. Incremento del apoyo a las operaciones internas para que estas sean ms eficaces. 6. Mejora del servicio al cliente. 7. Incremento en la moral de los empleados.

2.3.2 Determinacin de recursos

Viabilidad Tcnica: Agregados al sistema actual, tecnologa disponible para satisfacer las necesidades de los usuarios. Viabilidad Econmica: Tiempo de los analistas de los sistemas, costo del estudio de sistemas, costo estimado del hardware, costo del sw comercial o del desarrollo de software. Viabilidad Operacional: Adquisicin de licencias de sw, contratos y subcontratos. Viabilidad Ambiental: Impacto al medio ambiente, inclyase condiciones de trabajo, riesgo y seguridad ocupacional.

2.3.3 Evaluacin de la viabilidad

No es una decisin del analista de sistemas sino de los directivos de la organizacin. El analista debe exponer a los directivos, los datos sobre la viabilidad recopilada de manera experta y profesional, con conclusiones slidas y con el inters del proyecto vigente. Aunque es muy laborioso, el estudio de la viabilidad vale la pena y al final ahorra a las empresas y los analistas de sistemas tiempo y dinero.

21

2.4

Planificacin de la Documentacin

22

2.4.1 Documentacin

23

2.4.2 Documentacin tecnica del desarrollo

24

25

2.4.3 Documentacin de construccin

26

2.4.4 Documentacion de uso

27

2.4.5 Normas de presentacin

28

2.4.6 Contenido del documento de Especificacion del Sistema

29

2.4.7 Contenido del Documento de Diseo del Sistema

30

2.4.8 Contenido del Manual de Operacin del Sistema

2.5 Gestin de la configuracin del software (GCS) Es una actividad de autoproteccin que se aplica durante el proceso de software. Sirven para: 1. Identificar el cambio. 2. Controlar el cambio. 3. Garantizar que el cambio se implementa adecuadamente. 4. Informar del cambio a todos aquellos que pueden estar interesados.

31

2.5.1 Qu es?
Es un conjunto de actividades diseadas para controlar el cambio identificando los productos del trabajo que probablemente cambien, estableciendo las relaciones entre ellos, definiendo mecanismos para gestionar distintas versiones de estos productos, controlando los cambios realizados, y estudiando e informando de los cambios realizados. Origen de los cambios 1. Nuevos negocios o condiciones comerciales 2. Nueva necesidades del cliente que demandan la modificacin de los datos producidos por sistemas de informacin 3. Reorganizacin o crecimiento /reduccin del negocio que provoca cambios en las prioridades del proyecto. 4. Restricciones presupuestarias o de planificacin que provocan una redefinicin del sistema o producto.

2.5.2 Lnea base

Es un concepto de gestin que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE (Estndar IEEE 610.12-1990) define una lnea base. Es como un punto de referencia en el desarrollo del software y la aprobacin del ECS obtenido mediante una revisin tcnica formal. Elementos de configuracin del software Es la informacin creada como parte del proceso de la ingeniera del software, se puede considerar un ECS como una seccin individual de una gran especificacin o cada caso de prueba de un gran conjunto de pruebas.

2.5.3 El proceso de gestin de la configuracin de software (GCS)

Garanta de calidad del software. Su responsabilidad es el control de cambios y tambin es responsable de la identificacin de ECS individuales y de las distintas versiones del software, auditorias y generacin de informes sobre todos los cambios realizados en la configuracin. 5 Tareas de GCS: 1. Identificacin 2. Control de versiones 3. Control de cambios 4. Auditorias de la configuracin 5. Generacin de informes

32

2.5.4 Identificacin de Objetos de la Configuracin de Software

Para controlar y gestionar los elementos de configuracin, se debe identificar cada uno de forma nica y luego organizarlos mediante un enfoque orientado a objetos. Se pueden identificar 2 objetos: objetos bsicos y objetos compuestos. Un objeto bsico es una unidad de texto, un objeto compuesto es una coleccin de objetos bsicos y de otros objetos compuestos. Cada objeto tiene un conjunto de caractersticas distintas que le identifican de forma nica: un nombre, descripcin, una lista de recursos y una realizacin. El nombre del objeto es una cadena de caracteres que identifica al objeto sin ambigedad. La descripcin del objeto es una lista de elementos de datos que identifican el tipo de ESC (Elemento de configuracin del software) por ejemplo documento, programa, datos, que est representado por el objeto; un identificador del proyecto; la informacin de la versin y/o el cambio. Los recursos son entidades que proporciona, procesa, referencia o son requeridas por el objeto. La realizacin es una referencia a la unidad de texto para un objeto bsico y nulo para un objeto compuesto. Un objeto puede ser identificado como <parte-de> un objeto compuesto. La relacin <parte-de> define una jerarqua de objetos. Por ejemplo: Diagrama E-R 1.4 <parte-de> modelo de datos; Modelo de datos <parte-de> especificacin de diseo; El modelo de datos esta interrelacionado con los diagramas de flujo de datos (suponiendo que se una el anlisis estructurado) y tambin esta interrelacionado con un conjunto de casos de prueba para una clase particular de equivalencia. Las relaciones a travs de la estructura se pueden representar de la siguiente forma: Modelo de datos <interrelacionado>modelo de flujo de datos; Modelo de datos<interrelacionado>caso de prueba de la clase m: En el primer caso, la interrelacin es entre objetos compuestos, mientras que en el segundo caso, la relacin es entre un objeto compuestos (modelo de datos) y un objeto bsico (caso de prueba de la clase m).

2.5.5 Control de versiones

El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuracin creados durante el proceso del software.

33

2.5.6 Control de cambios

Nos preocupamos por el cambio porque una diminuta perturbacin en el cdigo puede crear un gran fallo en el producto. Pero tambin puede reparar un gran fallo o habilitar excelentes capacidades nuevas. Antes de que un ECS se convierta en una lnea base, solo es necesario aplicar un control de cambios informal. El que haya desarrollado el ECS en cuestin podr hacer cualquier cambio justificado por el proyecto y por los requisitos tcnicos (siempre que los cambios no impacten en otros requisitos del sistema ms amplios que queden fuera del mbito de trabajo del encargado del desarrollo). Una vez que el objeto ha pasado la revisin tcnica formal y ha sido aprobado, se crea la lnea base. Una vez que el ECS se convierte en una lnea base, aparece el control de cambios a nivel de proyecto. Ahora, para hacer un cambio, el encargado del desarrollo debe recibir la aprobacin del gestor del proyecto (si el cambio es <local>) o de la ACC (Auditoria de control de cambio) si el cambio impacta en otros ECSs. En algunos casos, se dispensa de generar formalmente las peticiones de cambio, los informes de cambio y las OCI (Orden de Cambio de Ingeniera). Sin embargo, hay que hacer una evaluacin de cada cambio as como un seguimiento y revisin de los mismos.

2.5.7 Auditoria de la Configuracin

La identificacin, el control de versiones y el control de cambios ayudan al equipo de desarrollo de software a mantener un orden que, de otro modo, llevara a una situacin catica y sin salida. Sin embargo, incluso los mecanismos ms correctos de control de cambios hacen un seguimiento al cambio solo hasta que se ha generado la OCI. Cmo se asegura que el cambio se ha implementado correctamente? 1. Revisiones tcnicas formales. 2. Auditorias de configuracin del software. Una auditoria de configuracin del software complementa la revisin tcnica formal al comprobar caractersticas que generalmente no tiene en cuenta la revisin.

2.5.8 Informes de Estado

La generacin de informes de estado de la configuracin (a veces denominada contabilidad de estado) es una tarea de GCS que responde a las siguientes preguntas: 1. 2. 3. 4. Qu paso? Quin lo hizo? Cundo pas? Qu ms se vio afectado?
34

Cuando aparece involucrada mucha gente es muy fcil que se d el sndrome de que <la mano izquierda ignora lo que hace la mano derecha>. Esto que dos programadores intenten modificar el mismo ECS son intenciones diferentes y conflictivas. El IEC (Informes de estado de configuracin) ayuda a eliminar esos problemas, mejorando la comunicacin entre todas las personas involucradas. La gestin de configuracin del software es una actividad de proteccin que se aplica a lo largo de todo el proceso del software. La GCS identifica, controla, audita e informa de las modificaciones que invariablemente se dan al desarrollar el software una vez que ha sido distribuido a los clientes. El control de cambios es una actividad procedimental que asegura la calidad y la consistencia a medida que se realizan cambios en los objetos de la configuracin. El proceso de control de cambios comienza con una peticin de cambio, lleva una decisin de proseguir o no con el cambio y culmina con una actualizacin controlada de ECS que se ha de cambiar. La auditora de configuracin es una actividad de SQA (Aseguramiento de la Calidad del Software) que ayuda a asegurar que se mantiene la calidad durante la realizacin de los cambios. Los informes de estado proporcionan informacin sobre cada cambio a aquellos que tienen que estar informados.

35

3 Metodologas de Anlisis de Riesgo

3.1 Preparar exposicin
9.- AS/NZS: Norma de Gestin de Riesgos publicada conjuntamente por Australia y Nueva Zelanda y ampliamente utilizada en todo el mundo. Si es software libre Si cuesta a cuanto Elaborar un documento y subirlo al dropbox

Introduccin
Segn la real academia espaola, riesgo se define como: -contingencia o proximidad de un dao. Segn Charette: Relacionada con acontecimientos futuros consecuencia de situaciones presentes. Implica cambio de actitud y accin Implica eleccin e incertidumbre. Segn higuera involucra: Incertidumbre: si es seguro no es riesgo Perdida: si ocurre ocurrirn prdidas indeseables Registro de riesgos Un riesgo se expresa como una situacin posible y el efecto adverso que es su consecuencia. Ejemplo: -Con el proyecto avanzado, el cliente solicita cambios grandes a los requerimientos, originando un retraso en la entrega. Categoras Conocidos: se identifican analizando, cuidadosamente: el plan del proyecto, el ambiente de negocios y tcnico. Predecibles: se extrapolan de proyectos anteriores Impredecibles: difciles de anticipar. Tipos de riesgos Los riesgos del proyecto: afectan la calendarizacin o los recursos del proyecto. Los riesgos del producto o tcnicos: perjudican la calidad o desempeo del software que esta desarrollando. Los riesgos del negocio: daan a la organizacin que desarrolla el software.

36

Ejemplos de riesgos del negocio

Riesgo La tecnologa fundamental se sustituye por una nueva, originando dudas en la viabilidad del proyecto. Una compaa rival ofrece un producto similar antes, originando perdida de mercado para el producto. Cambia la alta gerencia del cliente y reduce su inters en el proyecto, originando problemas financieros. Miembros clave del proyecto renuncian, originando un retraso significativo Cambio en la administracin originando desconcierto en el equipo Hardware indispensable no est a tiempo originando retrasos Cambio excesivo de requerimientos originando retraso y mayor costo Se subestimo el tamao, originando mayores costos Se subestima el numero de defectos originando retraso

Ejemplos de riesgos del producto

Riesgo Cambio excesivo de requerimientos origina mala funcionalidad Los componentes de software elegidos no trabajan adecuadamente El manejador de bases de datos no soporta el volumen de transacciones Requerimientos no verificables causan rechazo en usuarios Algoritmo inadecuado no cumple restricciones de tiempo de respuesta.

37