Vous êtes sur la page 1sur 43

CAPITULO 1 INTRODUCCION A LA GUIA Esta gua inicia con una amplia y completa introduccin sobre el concepto de Ingeniera del

Software, desde la ptica de los miembros de la IEEE. La definen como una ciencia relativamente nueva y con reconocimiento en el rea de Ingeniera. La reconoce como una disciplina crucial para la evolucin de la industria de software a nivel mundial y la define como la aplicacin de un enfoque sistemtico, disciplinado y cuantificable para el desarrollo, operacin y mantenimiento de software. Una profesin para ser reconocida como tal debe cumplir con un cuerpo de conocimiento basado en tres aspectos, desde el punto de vista acadmico, moral y cognitivo: 1. Que el conocimiento y las competencias de la profesin, sean validadas por profesionales de la misma rea. 2. Que el conocimiento sea validado desde la base racional y con fundamento cientfico 3. Que el juicio del profesional se enfoque hacia el asesoramiento en el rea de estudio Esta gua no debe ser confundida con el cuerpo de conocimiento de la Ingeniera del Software. La finalidad de SWEBOK (Gua de la Ingeniera del Software Cuerpo de Conocimiento) es describir que parte de ste es aceptado de manera general y se estableci con el fin de cumplir cinco objetivos: 1. Promover una vista general y consistente de la ingeniera del software a nivel mundial. 2. Dar claridad del contexto en el que se aplica la ingeniera del software con respecto a otras disciplinas, como la ingeniera de sistemas, la ciencia de los computadores, la administracin de proyectos y las matemticas. 3. Caracterizar los contenidos de esta disciplina. 4. Proveer acceso temtico al cuerpo de conocimiento de la ingeniera del software. 5. Proveer la fundacin de un ente para apoyar el desarrollo, certificacin y licenciamiento de material de calidad, relacionado con la disciplina. Est estructurada en 12 captulos completamente divididos en subcaptulos, que explican todos los componentes del cuerpo de conocimiento de la ingeniera del software, basados en reas del conocimiento, esquematizadas en los siguientes grficos:

CAPITULO 2 REQUERIMIENTOS DE SOFTWARE El rea del conocimiento de los requisitos de software (KA), se refiere al anlisis, especificacin y validacin de los requisitos de software. Se ha demostrado ampliamente que el hecho de no realizar bien este proceso trae consecuencias fatales en el desarrollo de cualquier producto de software. 1. Fundamentos Un requisito de software es una caracterstica que se debe exhibir para solucionar un cierto problema en el mundo real. Se convierte en una combinacin compleja de requisitos entregados por parte de los usuarios implicados dentro del desarrollo de la solucin, teniendo en cuenta que pueden corresponder a diferentes niveles jerrquicos, ambientes e intereses. Es importante tambin que cada requisito sea comprobable, pensando tambin en las implicaciones que esto puede conllevar. Se pueden clasificar de la siguiente manera: Requisitos de Producto Se refiere a generar los parmetros del problema a solucionar para ser traducido a un software. Requisitos de Proceso Se refiere ya a la parte tcnica y a lo que voy a utilizar para realizar el software (lenguaje de programacin, por ejemplo). Requisitos Funcionales Son las capacidades o funciones del software. Requisitos No Funcionales Son los que actan para obligar a llegar a la solucin pero no son parte integral del software. Caractersticas Inesperadas Son requisitos que se toman pero no pueden comprobarse hasta que est funcionando el software en condiciones reales. Requisitos del Sistema y de Software

Se refiere a todo lo que necesita el software para funcionar desde el punto de vista de hardware, software, recurso humano, informacin, instalaciones, servicios, etc. Los requisitos de software se derivan de los del sistema. 2. Proceso de los requisitos Inicia de manera aislada y se va refinando con el modelo de ciclo de vida del software y necesita ser adaptado a la organizacin y al contexto del proyecto. Agentes de Proceso Incluye a todas las personas, usuarias o no, que participan en el desarrollo del proyecto. Es un grupo interdisciplinario que aporta informacin para la construccin del software. Pueden ser usuarios, clientes, analistas de mercado, reguladores, ingenieros de software, etc. Ayuda y Gerencia de Proceso Se refiere a toda la parte presupuestal y de gerencia para llevar a cabo el proyecto. Calidad y Mejora de Proceso Se refiere al coste generado por control de calidad y a los niveles de cumplimiento para lograr el objetivo principal y por ende, la satisfaccin del cliente. 3. Captura de los Requisitos Se refiere al cmo se van a recolectar los requisitos por parte del ingeniero de software. Es aqu donde es clave la comunicacin con el cliente y con todas las personas implicadas en el proceso. Fuentes de los Requisitos Deben ser confiables y sometidas a verificacin para confirmar que la persona que suministra la informacin es idnea para hacerlo y que se tom el tiempo para analizar su conveniencia. No solo por idoneidad sino porque en ocasiones los usuarios no son buenos escribiendo y no son claros a la hora de hacer una solicitud. Tcnicas de Captura de Requisitos A menudo, el ingeniero de software utiliza tcnicas de captura de requisitos, tales como: Entrevistas Prototipos

Reuniones Observacin

4. Anlisis de Requisitos Es una auditora a todo lo que se recopil. De aqu salen los requisitos del sistema y por ende los de software. Permite establecer limitaciones y viabilidad del proyecto. Clasificacin de los requisitos Pueden clasificarse en: Funcionales o no funcionales De producto o de proceso Derivado Prioritario Estable o Voltil

Modelo Conceptual Se debe elegir un modelo conceptual que ayude a entender de una mejor manera el problema. Es una habilidad con la que debe contar el ingeniero de software, apoyado en herramientas que le ayuden a contextualizar el software, como el caso de UML o el uso de la matemtica discreta. La IEEE tiene tres estndares para el modelado. Estos son: IEEE Std 1320.1 (conceptual) IDEF0 (funcional) IEE Std 1320.2, IDEF1X97 (de informacin) Asignacin Arquitectnica del Diseo y los Requisitos Es la fusin de toda la parte de requisitos con la parte de diseo. Es inseparable esta combinacin; una es parte integral de la otra y es fcil su comprensin, apoyndose en el modelo conceptual. El estndar IEEE Std 1471-2000 puede servir de apoyo en esta prctica. Negociacin de los requisitos

Se llega a esta etapa cuando hay incompatibilidad en dos o ms requisitos y los solicitantes son distintos. El ingeniero de software debe reunirlos y tomar la decisin ms conveniente para el correcto funcionamiento de la solucin. 5. Especificacin de Requisitos Se refiere a plasmar en un documento todos los requisitos aprobados. Someterlos a verificacin por parte de los actores del proyecto. Es usual que se hagan tres documentos: Definicin del sistema o documento de exigencias Requisitos de sistema Requisitos de software

Es importante esta parte porque sin aprobar alguno o todos los documentos, es imposible pasar a la etapa de diseo. El estndar IEEE Std 830 [IEEE830-98], apoya este proceso de especificacin de requisitos. 6. Validacin de los Requisitos Su objetivo es determinar que los documentos realizados sean comprensibles y de acuerdo a los estndares determinados. Por esto, deben someterse a una auditora final realizada por todo el personal implicado en el desarrollo del software (cliente), para asegurarse de que lo plasmado all es lo que se solicit. Revisiones de los requisitos Se nombra un comit revisor, que incluye a un representante del cliente, con el fin de evaluar los documentos ya mencionados. El estndar IEEE Std 1028 proporciona ayuda valiosa en la tarea de revisin. Prototipado Es un medio que utiliza el ingeniero de software para manifestar lo que entendi y para facilitar la correccin, eliminacin o adicin de requisitos. Como se evidencia, la ventaja de hacerlo es grande pero el costo puede ser alto. Pruebas de Aceptacin Son aquellas que se le aplican a cada requisito para determinar si el producto final lo satisface o no. Debe haber total planeacin para aplicar estas pruebas y hacerlo de manera cuantitativa.

Como conclusin para este captulo puede afirmarse que los requisitos de software deben tomarse como una prctica seria, asignndole el tiempo y los recursos necesarios que permitan continuar con un proceso ordenado para llegar a obtener un software de calidad.

CAPITULO 3 DISEO DE SOFTWARE Es definido por la IEEE como el proceso para definir la arquitectura, los componentes, las interfaces y otras caractersticas de un sistema. Visto como proceso, el diseo del software es la actividad del ciclo de vida en la cual se analizan los requisitos del software para producir una descripcin de su estructura interna que servir como base para su construccin. 1. Fundamentos Proceso de diseo de software Se divide en dos etapas: Diseo Arquitectnico

Descompone el software en componentes y describe sus partes a nivel general, de estructura. Diseo Detallado

Describe el comportamiento especfico de estos componentes. Existen tcnicas permisibles que permiten hacer un acercamiento al diseo de software. Estas son algunas: Abstraccin

Es el proceso de olvidarse de la informacin para poder tratar las cosas que son diferentes como si fueran iguales. Acoplador y Cohesin

El acoplador es la fuerza de las relaciones entre los mdulos y la cohesin se refiere a la relacin que existe entre estos mdulos. Descomposicin y Modularizacin

Esta tcnica se utiliza para poner diversas funcionalidades en componentes ms pequeos. Encapsulacin

Permite empaquetar informacin y hacerla invisible. El xito est en darle una buena funcin a esa informacin.

10

El siguiente grfico muestra la descomposicin del proceso de diseo de software.

Separacin de la interfaz y de la puesta en prctica

Define un componente a travs de su interfaz grfica. Desahogo

Asegura que la abstraccin se hizo de manera correcta y que slo se tom lo relevante del componente. 2. Cuestiones claves del diseo de software Contribuye a entender cmo dividir, organizar y constituir los paquetes de software. Se ayuda con las siguientes llaves: Concurrencia Se refiere a cmo descomponer el software en procesos, tareas, hilos de reparto y que conserve la sincronizacin en los procesos. Distribucin de Componentes

11

Como integrar cada parte del software con el hardware necesario para su funcionamiento. Direccin del Error y de Excepcin y Tolerancia a Fallos Define las tcnicas para prevenir y tolerar fallos en el momento en que se presenten.

Interaccin y Presentacin Se refiere a la forma de mostrar y organizar las interacciones con los usuarios y la forma de documentarlas. 3. Estructura y Arquitectura de Software Es una descripcin de los subsistemas y de los componentes de un sistema de software y de las relaciones entre ellos. 4. Anlisis y Evaluacin de la Calidad del Diseo de Software Esta parte es importante porque asegura la calidad del proceso de diseo. Se utilizan mtricas que permiten estimar de manera cuantitativa varios aspectos del tamao, estructura o de la misma calidad del software. Estas pueden ser estructuradas u orientadas a objetos. 5. Notaciones del Diseo de Software Generalmente son grficas y permiten modelar en un diagrama la propuesta de diseo. Entre ellos estn los diagramas de clases y objetos, de componentes, de despliegue, de entidad-relacin, de estructura de Jackson, de estructura de cartas y diferentes lenguajes que permiten describir la arquitectura del software y sus componentes. Tambin existe la notacin para las descripciones de comportamiento dinmico del software, en las cuales tambin se usan diagramas y lenguajes textuales. Entre ellos estn los diagramas de actividad, de colaboracin, organigrama de datos, tablas y diagramas de decisin, de secuencia, de transicin de estado y diagramas de estado de carta, lenguajes de diseo en pseudocdigo, etc. 6. Estrategias y Mtodos del Diseo de Software Permiten dirigir el proceso de diseo. La estrategia est en trminos generales y los mtodos deben ser especficos. Aqu se inicia la aplicacin del paradigma Divide y Vencers y el proceso de refinamiento. Se define tambin si se va a utilizar el diseo estructurado u orientado a objetos o basado en componentes.

12

CAPITULO 4 CONSTRUCCION DEL SOFTWARE Este captulo hace referencia a la creacin detallada de software operativo y significativo, por medio de una combinacin de codificacin, verificacin, pruebas unitarias, pruebas de integracin y depuracin. El rea de Conocimiento de la Construccin del Software est vinculada a todas las otras KAs (reas de Conocimiento), ms fuertemente al Diseo del Software y a las Pruebas del Software. Esto se debe a que el proceso mismo de construccin del software cubre tanto el diseo significativo de software como las actividades de pruebas. En sntesis, esta es la etapa de creacin del cdigo fuente que tendr el software. 1. Fundamentos La construccin del software tiene como objetivos los siguientes: Minimizar la complejidad Anticiparse a los cambios Construir para verificar Aplicacin de estndares en la construccin La descomposicin de los temas de Construccin del Software se detallan en el siguiente grfico:

13

2. Gestin de la Construccin Modelos de Construccin Los ms conocidos y utilizados son los modelos de ciclo de vida en cascada y de entrega por etapas. Estos modelos son robustos pero solo son eficientes si se ha hecho un buen trabajo en la etapa de requisitos y de diseo. Por el contrario, los modelos prototipado evolucionista, programacin extrema y Scrum, son ms flexibles en este tema, dado que son iterativos y permiten, de manera cclica, realizar cambios, al combinar las tres etapas iniciales del desarrollo de un proyecto de software. Planificacin de la Construccin En todo proyecto, la planificacin es vital. Es aqu donde se delimita la aplicacin de requisitos, en qu orden se irn tomando y que grado de cumplimiento tienen, con respecto al objetivo principal del proyecto. De ah la importancia de elegir un modelo de ciclo de vida acorde a los requerimientos. Medicin de la Construccin Se refiere a los procedimientos utilizados para medir la eficiencia del cdigo fuente, en lo que se refiere a extensin, cdigo reutilizado, cdigo destruido, complejidad de cdigo, estadsticas de inspeccin de cdigo, tasas de rectificacin y correccin de errores y los horarios. Esto asegura el control de la calidad. 3. Consideraciones Prcticas Para solucionar un problema de la vida real a travs de un software, es totalmente necesario utilizar un lenguaje de programacin. Aqu radica el xito del proyecto de software, dado que es el ingeniero de software el encargado de aprobar el lenguaje a travs de los argumentos dados por los encargados de la elaboracin del cdigo fuente. Lenguajes de Construccin Son todos los tipos de comunicacin mediante los cuales un ser humano puede especificar una solucin ejecutable para un problema de un ordenador. Pueden ser de configuracin, de herramientas y de programacin. Estos ltimos, a su vez, estn divididos en lingsticos, formales y visuales. Pruebas de Construccin Generalmente son realizadas por el profesional que realiz el cdigo. Pueden ser unitarias o de integracin. Su propsito es reducir el tiempo entre el ingreso de fallas en el cdigo y el tiempo que se puede demorar su deteccin. Para tal fin, las normas estndar IEEE Std 829-1998 para documentacin de pruebas y la IEE Std 1008-1987 para pruebas unitarias, pueden ser de gran utilidad.

14

Reutilizacin Definir de manera objetiva, que parte del cdigo puede ser eficientemente reutilizado para minimizar tiempos de entrega, adems debe ser reportado a las personas que lideran el proyecto, por qu y para que se va a reutilizar, ya que esto puede modificar el valor del proyecto, por ejemplo. Calidad de la Construccin Existen varias tcnicas para evaluar la calidad en la construccin del cdigo fuente de un proyecto de software. Entre ellas tenemos: Las pruebas unitarias y de integracin El cdigo paso a paso Utilizacin de aserciones Depuracin Revisiones tcnicas Anlisis esttico Integracin Una parte clave del proceso de construccin es la integracin de las clases, componentes, rutinas, subsistemas que han sido construidos por separado, sobre todo si hay implicaciones tcnicas de software o hardware.

15

CAPITULO 5 PRUEBAS DEL SOFTWARE Es una actividad que permite evaluar y mejorar la calidad del producto con el fin de detectar fallas y corregir errores. Las pruebas del software consisten en verificar el comportamiento de un programa dinmicamente a travs de un grupo finito de casos de prueba, debidamente seleccionados. Se ha ido cambiando la percepcin de que las pruebas de software se realizan nicamente al final del proceso de creacin de cdigo fuente, siendo muy til hacerlo en todas las etapas del desarrollo del software; esto permite corregir errores y detectar fallas de fondo, a tiempo. En la figura que sigue se pueden apreciar las partes que intervienen en le proceso de pruebas de software.

16

CAPITULO 6 MANTENIMIENTO DE SOFTWARE

INTRODUCCION El proceso de desarrollo de software debe satisfacer los requerimientos planteados, una vez en operacin el proceso de cubrimiento de defectos, operacin y cambio de ambiente debe darse en esta etapa, la fase de mantenimiento empieza con un periodo de garanta y de soporte postimplementacin pero el mantenimiento del software ocurre mucho antes. Aunque la etapa de mantenimiento del software no ha tenido el grado de atencin que se debe este tipo de desarrollo de software ya esta empezando a cambiar ya que muchos errores graves han ocurrido por no prestarle la atencin que se merece. El mantenimiento de software se ha definido como el nmero total de actividades requeridas para proveer soporte efectivo al software, esto incluye un planeamiento efectivo antes. Durante y despus de la implementacin del software. 1. Aspectos Fundamentales en el mantenimiento del software: Aqu se introduce a los aspectos fundamentales del mantenimiento del software: 1.1 Definiciones y terminologa: Est definido en el estndar de la IEEE 1219 como la modificacin del producto de software despus de la entrega para corregir las faltas, tambin se encarga de direccionar las actividades de mantenimiento para darle prioridad a la entrega del producto. El estndar IEEE/EIA 12207 define el mantenimiento como uno de los procesos principales en el ciclo de vida del software, el objetivo es modificar el software existente preservando su integridad tambin lo hacen en estos mismos trminos la ISO/IEC 14764 este enfatiza en las entregas previas para la planeacin del mantenimiento del software. 1.2 Naturaleza del mantenimiento: El mantenimiento de software debe estar dentro del ciclo de vida operacional, un mantenimiento esta definido por la IEEE/EIA 12207 como las actividades de mantenimiento que permiten el desempeo correcto.

17

Identifica las actividades de mantenimiento como un proceso de implementacin y modificacin y anlisis del problema, estas actividades son discutidas en el tpico 3.2 Actividades de Mantenimiento.

Figura 1. Tpicos a tener en cuenta en el mantenimiento del software 1.3 Necesidad de mantenimiento: La necesidad de mantenimiento se da para garantizar que el software cumple satisfactoriamente con los requerimientos solicitados, este se aplica a cualquier desarrollo independiente del modelo de ciclo de vida utilizado, el mantenimiento se da en orden de alcanzar el desempeo adecuado y en el orden de: Corregir fallas. Improvisar el diseo. Implementar correcciones.

18

Interfaces con otros sistemas. Adaptar programas a diferentes tipos de hardware, software, configuracin del sistema y facilidad de uso de telecomunicaciones. Migracin legal de software. Retiro de software. 1.4 Costos Mayoritarios de mantenimiento: Los costos de mantenimiento de software son los mas costosos en todo el ciclo de vida del software, estudios recientes han demostrado que ms del 80% del mantenimiento de software es usado para acciones correctivas hay que entender la categora del mantenimiento del software para entender la estructura del costo de mantenimiento, entendiendo los factores que influyen en el costo se puede ayudar a contener dichos costos, a continuacin se presentan algunos aspectos tcnicos y no tcnicos que afectan los costos de mantenimiento: Tipo de Aplicacin. Disponibilidad del mantenimiento de software. Ciclo de vida del software. Caractersticas de hardware. Calidad del diseo de software, construccin, documentacin y pruebas. 1.5 Evolucin del software: En 1969 Lehman direcciono el mantenimiento del software y la evolucin de los sistemas, durante 20 aos se mantuvo su idea de la formulacin de ocho Leyes de la evolucin donde se mantuvo la idea de la evolucin en el mantenimiento del software para continuar con el desarrollo. Lientz y Swanson inicializaron la definicin de tres categoras de mantenimiento: correctivo, adaptativo y perfectivo.

2. Factores claves en el mantenimiento del software:

Un numero de factores claves debemos tener presentes para asegurar el mantenimiento efectivo del software, es importante comprender que el mantenimiento de software nos proporciona una tcnica nica en los desafos de administracin para los ingenieros de software, podemos apreciar como se planean las liberaciones posteriores as como los parches

19

generados para las versiones anteriores, lo que sigue a continuacin nos presenta una manera de cmo se nos presentan algunos factores de administracin y tcnicos para el mantenimiento de software, estos se agrupan segn los tpicos siguientes: Factores tcnicos. Factores administrativos. Estimacin de costos. Medidas.

3. Proceso de mantenimiento: Provee referencias y estndares utilizados para implementar el proceso de mantenimiento de software. Las actividades de mantenimiento son diferenciadas por el desarrollo mostrado en la relacin a las actividades de ingeniera de otro software.

Figura 2. Actividades en el proceso del mantenimiento

20

En la figura planteada por la ISO/IEC se puede apreciar que es muy parecida a la anterior que es IEEE pero en esta se agrega una pequea diferencia: Cada actividad de mantenimiento primario de software ISO/IEC 14764 es desglosada en los siguientes trminos: Proceso de implementacin. Anlisis del problema y modificaciones. Implementacin y modificacin. Mantenimiento Aceptacin/Revisin. Migracin. Retiro de Software.

Tcnicas para el mantenimiento:

Esta subrea nos introduce a algunas generalidades aceptadas por las tcnicas del mantenimiento de software: 3.1 Comprensin del programa Los programadores gastan tiempo considerable leyendo y entendiendo programas para poder implementar cambios existen distintas herramientas que nos ayudan con este proceso. 3.2 Reingeniera Esta definida como el examen de de la alteracin del software para reconstituir una nueva forma, la reingeniera es la mas radical y expansiva forma de la alteracin otros creen que la reingeniera puede ser usada para cambios menores, siempre est enfocada en mantener la legalidad del software asi como sus tcnicas, casos de estudio y sus riesgos y beneficios. 3.3 Ingeniera inversa Es el proceso de analizar el software para identificar los componentes y sus relaciones para crear representaciones del software dicho de otra forma desde un nivel mas alto de abstraccin, es pasiva, y no hace cambios al software o resulta en otro software. Produce grficas asi como control de flujo y del cdigo fuente, un tipo de reingeniera puede ser la redocumentacin, otro tipo es la reparacin del diseo. Finalmente la reingeniera ha sido de gran importancia en los ltimos aos ya que gracias a sus esquemas lgicos a podido restaurar bases de datos fsicas.

21

CAPITULO 7 ADMINISTRACION DE LA CONFIGURACION DEL SOFTWARE Un sistema puede ser definido como un conjunto de componentes organizados con el propsito de cumplir una funcin o conjunto de funciones especficas. En este sentido la configuracin de un software y sus caractersticas funcionales de hardware, software, firmware o la combinacin de estas son un conjunto de caractersticas tcnicas que se deben cumplir para garantizar su correcto funcionamiento. La administracin de configuracin es la disciplina encargada de identificar la configuracin general de un sistema para as mantener su confiabilidad, adaptabilidad y configuracin a los diferentes ciclos de vida. Est formalmente definida por la IEEE610.12-90 como Disciplina aplicada de manera tcnica y administrativa para la direccin y supervivencia para: Identificar y documentar las caractersticas fsicas y funcionales de la configuracin de los elementos, control en el cambio de sus caractersticas grabar y reportar cambios en el proceso de implementacin as como su estado y verificacin del cumplimiento de sus requerimientos especficos.

1. Administracin de los procesos SCM

22

La SCM administra y controla la evolucin e integridad del software as como su verificacin, control, reportes y configuracin de la informacin. Una implementacin exitosa del SCM requiere un cuidado especial y planeacin y administracin. 1.1 Contexto Organizacional del SCM Para desarrollar un plan SCM es necesario conocer detalladamente los procesos de la organizacin ya que el SCM interacta directamente con todos los elementos y actividades organizacionales.

1.2 Constantes y gua para el proceso SCM Esto proviene de un gran numero de fuentes tiene que ver con las polticas de la organizacin y su influencia en la administracin de los procesos. 1.3 Planeacin del SCM El proceso de planeacin debe ser consistente con el contexto organizacional, y la naturaleza del proyecto (por ejemplo el tamao y su crtica) las actividades ms importantes en este contexto son: control de configuracin, control de estado, control de auditora, control de liberaciones y entregas as como las herramientas de configuracin y control y sus interfaces consideradas. 1.4 Plan de la SCM Los resultados de planeacin del proyecto son guardados en un plan de gestin y configuracin del software, el documento se mantiene y se actualiza o aprueba segn sea necesario a lo largo del ciclo de vida del software. Tambin es muy til hacer mediciones constantes a los procesos para hacer los cambios y/o actualizaciones correspondientes. 1.5 Seguimiento de la gestin de la configuracin del software Despus del cumplimiento del proceso de la SCM puede ser necesario un cierto nivel de seguimiento para asegurarse que los procesos SCM se llevan a cabo adecuadamente, este seguimiento puede hacer parte de un proceso de auditora para garantizar la calidad del software. El uso de herramientas integradas en la SCM facilita el proceso de seguimiento. 1.5.1 Medidas y mediciones de la SCM

23

Proporcionan un buen medio para monitorizar la efectividad de las actividades SCM de una manera continuada, son tiles para caracterizar el estado actual del proceso y para proporcionar una base para hacer comparaciones con el tiempo. Las bibliotecas de software y las diferentes herramientas proporcionan fuentes para extraer la informacin acerca de las caractersticas de los procesos SCM.

2. Identificacin de la configuracin del software Identifica los elementos a ser controlados, establece e identifica esquemas y sus versiones, establece herramientas y tcnicas utilizadas para administrar y controlar dichos elementos. 2.1 Identificar elementos a ser controlados Un primer paso sera identificar cambios en los elementos de software que sern controlados para entender la configuracin del software en el contexto del sistema.

2.2 Biblioteca de software Coleccin controlada de software as como de sus documentos relacionados y est relacionada para ayudar en el desarrollo de software, ah diferentes tipos y nos pueden ayudar en diferentes etapas, son tambin una fuente importante de informacin para mediciones del trabajo realizado y del progreso.

3. Control de la configuracin del software Le concierne la gestin de cambios durante el ciclo de vida, cubre los procesos que determinan los cambios a realizar, la autoridad para hacerlos y el soporte para la implementacin de dichos cambios. La informacin derivada de estas actividades es til para medir el trfico de cambios y ruptura de aspectos por rehacer. 3.1 Peticin, evaluacin y aprobacin de cambios del software

24

El primer paso es determinar los cambios a realizar, se evala el coste e impacto del cambio propuesto se acepta o rechaza dicho cambio, este se origina en cualquier momento del ciclo de vida y puede incluir una solucin propuesta y una prioridad. 3.2 Implementando cambios en el software Se implementan utilizando los procesos de software definidos de acuerdo con los requerimientos de planificacin aplicables. Podran sufrir auditoras de configuracin y verificacin de la calidad del software. Esta soportada por las herramientas de la biblioteca que proporcionan gestin de versiones y soporte para el almacenamiento de cdigo. 3.3 Desviaciones y Remisiones Las limitaciones que se imponen al esfuerzo de la ingeniera del software podran contener necesidades que no pueden ser satisfechas en el punto designado del ciclo de vida. Una remisin es una autorizacin para abandonar una necesidad antes del desarrollo del elemento.

4. Registro del estado de la configuracin del Software La contabilidad del estado de la configuracin del software (SCSA) es la actividad de registrar y proporcionar la informacin necesaria para una gestin efectiva de la configuracin del software.

4.1 Informacin del estado de la configuracin del software Genera un conjunto de informes durante el ciclo de vida, se encarga de recoger y mantener la informacin del estado de la configuracin que se ha de gestionar segn las configuraciones evolucionan. Es necesario algn tipo de soporte de herramientas automticas para llevar a cabo las tareas de recogida de datos y generacin de informes de la SCSA. 4.2 Reportes del estado de la configuracin del software Los reportes pueden ser usados para los elementos del proyecto de la organizacin, incluyendo el equipo de desarrollo, administracin de proyectos y actividades de calidad del software. Tambin sirve para responder algunas preguntas especficas de la etapa de produccin.

25

5. Auditora de la configuracin de software Es una actividad desarrollada independientemente para evaluar la conformidad de los productos de software, se encarga de aplicar regulaciones, estndares, planes de gua y procedimientos. Deben ser cuidadosamente planeadas, existen herramientas que apoyan la planeacin y conduccin de las auditoras para facilitar su proceso. Determina la extensibilidad de los elementos y sus caractersticas fsicas, los informes pueden ser orientados como puntos clave en el ciclo de vida, las auditorias pueden ser un requisito para las lneas base. 5.1 Auditoria funcional de la configuracin del software El propsito es asegurar la consistencia en los elementos de software auditados. La salida de la verificacin y validacin del software es la clave de entrada de este tipo de auditora. 5.2 Auditora de la configuracin fsica del software El propsito es asegurar que el diseo y la documentacin de referencia es consistente con la construccin del producto de software. 5.3 Auditora durante el proceso de una lnea base de software Como lo mencionado puede ser llevado durante el proceso de desarrollo para investigar el estado actual de los elementos especficos de la configuracin. La auditora es aplicada a los elementos de la lnea base para asegurar el desempeo que sea consistente con las especificaciones.

6. Administracin de las entregas y liberaciones de software El trmino liberacin es usado en este contexto para referirnos a las distribuciones de software y los elementos en las actividades de desarrollo. Eso incluye liberaciones internas y correcciones a las variantes de estos elementos. La informacin y documentacin entregada en las liberaciones es conocida como el documento descriptivo, este incluye los contenidos de instalacin y instrucciones de actualizacin.

26

CAPITULO 8 GESTION DE LA INGENIERIA DEL SOFTWARE

Puede ser definida como las actividades de gestin de la aplicacin, planeacin, coordinacin, medicin, monitorizacin, control y reportes para asegurar el desarrollo y mantenimiento del software como sistemtico, disciplinado y cuantificable. Es un aspecto muy importante en la administracin y medicin de la ingeniera del software. En estas actividades se destacan tres niveles: Gestin y organizacin de la infraestructura, gestin de proyectos, y control y planeacin del programa de medidas. Los aspectos de la gestin de la organizacin son importantes en trminos del impacto en la ingeniera del software y en las polticas de gestin, esas polticas pueden ser influenciadas por los requerimientos de un software efectivo, mantenimiento y desarrollo. Un nmero de polticas especficas deben ser establecidos para una efectiva gestin en la ingeniera del software y el nivel organizacional. Haciendo gestin con nfasis en la medicin y un principio de presupuesto en cualquier disciplina de verdadera ingeniera puede ayudar a darle la vuelta a esta percepcin. Una gestin eficaz requiere la combinacin tanto de nmeros como de experiencia. La gestin en la ingeniera del software se descompone en seis subreas principales a continuacin se da un espacio detallado de cada una.

27

1. Iniciacin y Alcance Se centra en la determinacin eficaz de los requisitos del software por medio de varios mtodos de induccin y la valoracin de la viabilidad del proyecto desde distintos puntos de vista, una vez establecida la viabilidad, la tarea pendiente es la especificacin de la validacin de requisitos y del cambio de procedimientos. 2. Planificacin de un Proyecto de Software Esta regulado por los alcances y los requisitos y por la viabilidad del proyecto, se evalan los procesos de ciclo de vida y se selecciona el ms apropiado. Se debe realizar una descomposicin jerrquica de tareas, y la realizacin de un calendario y una estimacin de costos.

28

Ms adelante se le da un presupuesto a las tareas y la imposicin de horarios y uso de materiales, se debe llegar a la determinacin de procesos y responsabilidades para asegurar la calidad del software, verificacin, validacin y revisiones de auditoras. 2.1 Planificacin de un Proceso La seleccin de un modelo de ciclo de vida o la adaptacin de un despliegue de ciclos se emprenden a la luz del alcance particular y de los requisitos del proyecto. Tambin se seleccionan mtodos y herramientas pertinentes. 2.2 Determinar los entregables Se especifica y caracteriza los productos de cada tarea, se evala la posibilidad de reutilizar componentes de desarrollos anteriores y se planifica la utilizacin de terceras personas y del software obtenido y se seleccionan los proveedores. 2.3 Esfuerzo, calendario y clculo del coste Se determina el rango de esfuerzo esperado, utilizando un modelo de estimacin calibrado, basado en datos histricos sobre el esfuerzo empleado. Cuando sea posible se solucionan cuellos de botella, y se elabora el esperado cuadro de tareas con los horarios de inicio, duraciones y horarios de finalizacin bien planificados. Los requisitos de recursos (personas, herramientas) se traducen en estimaciones de costo. 2.4 Reparto de recursos Los equipos, medios y personas se asocian a las tareas programadas, esta actividad est regulada y limitada por la disponibilidad de los recursos y su uso ptimo bajo estas circunstancias. 2.5 Gestin de Riesgos Se completa el anlisis de riesgos, la valoracin crtica de riesgos, la mitigacin de riesgos y la planificacin de contingencias. Los mtodos para la valoracin del riesgo deben utilizarse para resaltar y evaluar riesgos, en esta etapa se deben evaluar las posibilidades de abandono del proyecto en conversaciones con todos los contratistas. 2.6 Gestin de calidad Se define en trminos de atributos pertinentes del proyecto y en los de cualquier producto asociado a l, tanto en trminos cualitativos como cuantitativos.

29

Los lmites de adhesin de calidad se colocan de acuerdo a las expectativas que tenga el contratista sobre el software en cuestin as como los procedimientos de verificacin y validacin del producto entregable. 2.7 Gestin de planes Los informes, la supervisin y el control del proyecto deben encajar en el proyecto de ingeniera del software seleccionado y en las realidades del proyecto y deben reflejarse los artefactos que lo gestionarn. Los cambios a otros procesos de soporte ejemplo: gestin documental, resolucin de problemas tambin deben gestionarse de la misma manera.

3. Promulgacin del proyecto de Software Se ejecutan los planes y se divulgan los procesos incluidos en los planes, en este proceso hay total expectativa de la adhesin plena de los requisitos del contratista y el logro de los objetivos del proyecto, son actividades fundamentales para la promulgacin la gestin, medicin, supervisin, control e informacin del proyecto.

4. Revisin y Evaluacin Se evala el proceso global hacia el logro de los objetivos y satisfaccin de los requisitos del contratista y se llevan a cabo valoraciones sobre la efectividad del proceso global hasta la fecha, del personal involucrado y de las herramientas y mtodos utilizados. 4.1 Determinar la satisfaccin de los requisitos Determinar que el objetivo principal se est cumpliendo es primordial ya que lo que nos interesa es la satisfaccin del usuario o contratista esto se debe hacer peridicamente. Se deben identificar las variaciones a las expectativas para llevar a cabo las acciones adecuadas. Tambin se debe gestionar el control de cambios a los procedimientos y a la configuracin del software. 4.2 Revisar y Evaluar la Ejecucin Las revisiones peridicas a lo realizado nos proporcionan detalles sobre la probabilidad de ser fiel a los planes, as como las posibles reas de dificultad, aqu se evalan los diferentes mtodos, herramientas y tcnicas empleadas para ver su eficacia y adecuacin y se evala constantemente la

30

eficacia de los procesos para ver su utilidad en el contexto del proyecto, cuando sea necesario se gestionan y se llevan a cabo los cambios.

5. Cierre El proyecto llega a su fin cuando todos los planes y procesos implicados se han promulgado y completado, en esta fase se repasan ciertos criterios para el xito del proyecto. Se han entregado los procesos tal como se haban especificado y todos los productos planificados han sido entregados con caractersticas aceptables.

5.1 Determinar el cierre Se logran los objetivos del proyecto y estos procesos por lo general involucran a los contratistas y acaban con la documentacin y de los informes de cualquier otro problema pendiente conocido. 5.2 Actividades de cierre Se archivan los materiales del proyecto y la base de datos de medicin de la organizacin se pone al da con los datos finales del proyecto y se emprende el anlisis post-proyecto. Se hace con el fin de identificar temas. Problemas y oportunidades encontrados durante el proceso, se sacan las lecciones del proceso y luego se alimentan los conocimientos de la organizacin y los intentos de mejora.

6. Medidas de la ingeniera del software Aqu abordamos el tema de la medicin en la ingeniera del software y su importancia para esto se sigue unas mtricas y normas establecidas por entidades como la ISO y la IEEE. 6.1 Establecer y sostener el compromiso de medir Se deben tener ciertos compromisos de medicin establecidos, adems de requisitos que midan los factores que contribuyen a un objetivo en particular para as gestionar los proyectos y hacerle frente a este objetivo. Se debe establecer una unidad u objetivo a medir en la organizacin, adems se debe adquirir un compromiso que se debe comunicar y apoyar en los recursos de la organizacin. Se deben asignar recursos para llevar a cabo el proceso de medicin adems de dar la financiacin y herramientas adecuadas para dirigir este proceso. 6.2 Planificar el proceso de medicin

31

Para esto es necesario identificar la unidad funcional a la cul se le est aplicando para que sea caracterizada y as identificar las necesidades de informacin para proceder con los objetivos primordiales y sus respectivas prioridades. Se deben seleccionar las mediciones a realizar adems como las muestras de informacin que sern tomadas para su posterior anlisis, verificacin e informacin a ser dada. El plan de medicin tambin debe ser revisado y aprobado por los contratistas adecuados adems de mantener disponibles los recursos para dicho plan. Se deben comunicar los resultados adems de documentarse publicarse. 6.3 Evaluar las mediciones Este proceso se debe llevar a cabo con un criterio de evaluacin especfico para determinar las fuerzas y debilidades de los productos, se puede hacer por medio de un proceso de auditora interna o externa y debe incluir una retroalimentacin a los usuarios. Se deben identificar las mejoras potenciales y costos y beneficios de estas, comunicarlas a la persona encargada para su revisin y aprobacin.

32

CAPITULO 9 PROCESO DE INGENIERA DEL SOFTWARE

Se puede examinar en dos niveles desde lo tcnico y desde el meta-nivel o nivel de implementacin, valoracin, medicin y gestin. Existen varios significados sobre el proceso de la ingeniera del software puede verse como una sola manera de realizar el proceso o como muchas maneras que es lo que se quiere y se debe llegar a hacer ya que el proceso de la ingeniera abarca muchos factores, finalmente un tercer significado se refiere al conjunto actual de actividades realizadas dentro de una organizacin que se puede ver como un solo proceso. Los procesos de ingeniera del software son considerados de gran importancia, el objetivo es gestionar nuevos y mejores procesos. 1. Proceso de implementacin y cambios Se centra en los cambios organizacionales, describe la infraestructura, actividades, modelos y consideraciones prcticas de un proceso de implementacin y cambios:

Tambin es denominado el proceso de evaluacin, hay que tener cuidado con las modificaciones ya que puede que tambin sean necesarios cambios en la cultura organizacional. 1.1 Infraestructura del proceso Es necesario que la infraestructura este en su lugar, es decir que los recursos estn al alcance de la mano y que se hayan asignado responsabilidades, es posible que se tengan que establecer comits para supervisar el esfuerzo del proceso de ingeniera del software. Con un grupo de proceso de la ingeniera del software se pretende ser el foco central en el proceso de mejoras y tiene cierto nmero de responsabiidades en la inicializacin y el mantenimiento. El concepto de creadora de experiencias (EF) se centra en el proceso de mejoramiento de los procesos de la ingeniera del software.

2. Definicin de procesos

33

Pueden ser unos lineamientos, polticas o estndares se definen para facilitar el entendimiento en la comunicacin humana, apoyar y mejorar procesos , se deben considerar algunas variaciones como la naturaleza del trabajo, el dominio de la aplicacin, el modelo de ciclo de vida y la madurez de la organizacin. 3. Valoracin del proceso Se lleva a cabo utilizando un mtodo y un modelo de valoracin que en algunos casos es visto como un modelo de apreciacin y muchas veces una evaluacin de capabilidad cuando es para la adjudicacin de algn contrato. 3.1 Modelos de valoracin del proceso Recoge lo que se conoce como las buenas prcticas en el proceso de gestin de la ingeniera del software, la ISO define un modelo ejemplo de valoracin y de requisitos, se han desarrollado tambin un modelo de madurez para sistemas de ingeniera que resulta til cuando un proceso est implicado en el desarrollo y mantenimiento de un sistema incluyendo el software. Existen dos arquitecturas generales para un modelo de valoracin: continua y escalonadamente, son muy diferentes entre ellas y se deben evaluar para conocer cul es la que mejor se adapta a mis necesidades y objetivos. 3.2 Mtodos de valoracin del proceso Es garantizar un mtodo cuantitativo que evaluara los procesos, existen de varios tipos dnde se valoran distintos tpicos todos pensados en las mejoras de los procesos y la eficacia en la organizacin.

4. Medicin de los procesos y los productos Aunque puede resultar compleja la medicin a la ingeniera del software existen varios aspectos que son fundamentales para la medicin y anlisis, estas mediciones se pueden realizar para apoyar los procesos de implementacin y cambio o evaluar consecuencias de estos.

4.1 Medicin del proceso Se recoge, analiza e interpreta informacin cuantitativa sobre el proceso, se utiliza para identificar la fuerza y debilidad en ellos y as mismo evaluarlos despus de haber sido implementados o cambiados.

34

La medicin de un producto software incluye principalmente, la medicin del tamao del producto, la estructura del producto y la calidad del producto. Tambin es importante tener en cuenta la medicin del tamao, de la estructura y de la calidad. Para garantizar la calidad en los resultados de la medicin es necesaria la medicin efectiva de los programas para proveer resultados exitosos.

CAPITULO 10 INSTRUMENTOS Y MTODOS DE LA INGENIERA DEL SOFTWARE Son los instrumentos asistidos por ordenador que son requeridos para ayudar a los procesos de ciclo de vida del software, nos ayuda a reducir la carga cognoscitiva enfocndonos ms en los aspectos creativos del proceso. Los mtodos imponen la estructura a la actividad de la ingeniera del software con el objetivo de hacerla sistemtica, por lo general proporcionan notacin y vocabulario para comprobar tanto el proceso como el producto, aunque existen numerosos materiales sobre los instrumentos de apoyo

35

en la ingeniera del software, los textos sobre las tcnicas sobre estos instrumentos son relativamente escasos, una dificultad es el alto costo que representa un cambio de instrumento de software en general, los instrumentos y mtodos cubren ciclos de vida completos por esto es tan complicado hacer un cambio. Estudio de las herramientas y mtodos de la ingeniera de software

1. Las herramientas de ingeniera de Software Ests corresponden a las cinco primeras reas de conocimiento de la gua, Exigencias de software, diseo de software, construccin de software, pruebas de software y mantenimiento de software. Los cuatro siguientes asuntos corresponden a las reas de conocimiento restantes: La direccin de configuracin de software, la direccin de ingeniera de software, el proceso de ingeniera de software, y la calidad del software. 1.1 Las Herramientas de exigencias de Software Han sido clasificados en dos categoras: modelado e instrumentos de capacidad de rastreo. Exigencias de los instrumentos de modelado: Son usados para la obtencin, anlisis, especificacin y validez de las exigencias de software. Exigencias de los instrumentos de capacidad de Rastreo: Se hacen cada vez ms importantes debido a que la complejidad del software crece, son presentados separadamente de los instrumentos de modelado.

1.2 Las Herramientas de Diseo de Software Cubre los instrumentos para crear y comprobar diseos de software, existe gran variedad de estos gracias a la diversidad en las notaciones de diseo de software y mtodos, a pesar de esta variedad no se ha encontrado una divisin convincente. 1.3 Las Herramientas de Construccin de Software Son instrumentos usados para producir y traducir la representacin de programa mquina, se utilizan los redactores de programa, compiladores y generadores de cdigo, intrpretes y depuradores. 1.4 Herramientas de Pruebas de Software Se incluyen: Generadores de Pruebas, marcos de ejecucin de pruebas, herramientas de evaluacin de pruebas, herramientas de direccin de pruebas y de anlisis y de funcionamiento, todas estas

36

estn enfocadas a la prueba del software construido as como de su funcionalidad, versatilidad y calidad. 1.5 Herramientas de Mantenimiento de Software Abarca los instrumentos utilizados para el mantenimiento de software, dos categoras son identificadas: instrumentos de comprensin y instrumentos de reingeniera. Herramientas de comprensin: Ayudan a la comprensin humana de programas, se incluyen instrumentos como animadores o rebanadores. Herramientas de reingeniera: Es definido como el examen y la alteracin del software sustancial para reconstruirlo de una nueva forma. 1.6 Las herramientas de direccin de configuracin de Software Han sido dividas en tres categoras: rastreo, direccin de versin e instrumentos de liberacin. Rastreo: Son elementos utilizados en la conexin con las cuestiones que rastrean problemas asociados con un producto de software particular. Herramientas de direccin de versin: Estn implicados en la direccin de mltiples versiones de un producto. Herramientas de liberacin y construccin: Son usados para las tareas de liberacin y construccin de un software incluye instrumentos de instalacin que son extensamente utilizados para configurar la instalacin de un producto software. 1.7 Herramientas de direccin en la Ingeniera de Software Esta subdivido en tres categoras: planificacin de proyecto y rastreo, manejo arriesgado, y medida. En la primera se busca una medida de esfuerzo en el proyecto y cuenta la valoracin as como la planificacin del proyecto, en la segunda se identifican la estimacin y riesgos de supervisin, finalmente en la medida se asiste la realizacin de actividades relacionadas con el programa de medida de software. 1.8 Las Herramientas de proceso de ingeniera de Software Est divida en instrumentos que modelan, instrumentos de direccin y ambientes de desarrollo de software. 1.9 Las herramientas de Calidad de Software Dividas en dos categoras: inspeccin e instrumentos de anlisis. En las herramientas de revisin de auditoria se apoyan en revisin y revisiones de cuenta y en las de anlisis estticos se analizan artefactos de software como analizadores sintcticos y semnticos as como datos, el flujo de control y analizadores de dependencia.

37

1.10

Cuestiones de Instrumento Compuestas Cubre el tema aplicable a todas las clases de instrumentos, tres categoras identificadas: tcnicas de integracin de instrumentos, meta-instrumentos, y evaluacin de instrumento.

2. Los Mtodos de la Ingeniera del Software Esta divido en tres temas: Mtodos heursticos que tratan con accesos matemticamente basados, y mtodos de prototipazo que tratan con software que trama accesos basados en varias formas de prototipazo, cada tema trata sus preocupaciones distintas no quiere decir que no tengan que ver el uno con el otro. 2.1 Mtodos Heursticos Este tema contiene cuatro categoras: estructurado, orientado a datos, orientado a objetos, y especfico de dominio. La ltima incluye mtodos especializados para desarrollar los sistemas que implican en tiempo real aspectos relacionados con la seguridad. En el mtodo estructurado se ve desde un punto de vista funcional para refinarlo y hacerlo cada vez ms detallado. En el orientado a datos se estructura el programa y se manipula. En el orientado a objetos el sistema es visto como una coleccin de objetos ms que de funciones. 2.2 Mtodos Formales Aqu se describe como el software se basa en mtodos de ingeniera basado matemticamente y se subdivide segn varios aspectos de mtodos formales entre ellos: Especificacin del lenguaje y notaciones: Aqu se especifica la lengua usada y se clasifica segn la orientacin del modelo las caractersticas o el comportamiento. Refinamiento: Aqu se trata como de refinar o transformar las especificaciones en una forma ms cercana a la deseable en un programa finalmente ejecutable. Propiedades de Verificacin/Confirmacin: Aqu se incluyen confirmaciones de teorema y la comprobacin del modelo. 2.3 Mtodos de Prototipado Cubre mtodos que implican el prototipazo de software y es subdivida en estilos de prototipazo, objetivos y tcnicas de evaluacin.

38

Se deben incluir aspectos como: Estilos de prototipazo, objetivos del prototipazo, y las tcnicas para la evaluacin del prototipo propuesto.

39

CAPITULO 11 CALIDAD DEL SOFTWARE Porque es tan importante la calidad del software que est en todos los aspectos de la gua SWEBOK? Muchos autores le han dado varias definiciones a este trmino pero citar la que le da la ISO 900100 la cul la define como el grado en el que un conjunto de caractersticas inherentes cumple requisitos. En este captulo se abordan los aspectos relativos a la calidad del software los cuales trascienden en cualquier ciclo de vida, en esta gua se describen un conjunto de mtodos para alcanzar la calidad, en este caso se trataran las tcnicas estticas es decir aquellas que no requieren la ejecucin del software para su evaluacin mientras las dinmicas cubren los aspectos de calidad en las pruebas del software.

1. Fundamentos de Calidad del Software Aqu se definen formalmente los aspectos a tratar y la manera como un ingeniero de software debera entender y adoptar los conceptos y caractersticas de calidad y su relevancia en el desarrollo o mantenimiento de software. Los aspectos de calidad deben estar inherentes desde el momento mismo de los requerimientos as como la medicin y criterios de aceptacin que evalan estas caractersticas.

1.1 Modelos y Caractersticas de Calidad La terminologa usada en las caractersticas difiere de una taxonoma a otra ya que cada una posee niveles jerrquicos diferentes, la ISO ha definido tres modelos relacionados con la calidad en un producto de software (la calidad interna, la calidad externa y la calidad en el empleo).

1.2 Mejora de Calidad La tarea de la calidad puede ser mejorada cada vez ms gracias a un proceso iterativo de mejora continua que requiere control de direccin, control y retroalimentacin de muchos procesos simultneos: (1) los procesos de ciclo de vida del software, (2) el proceso de deteccin de error/defecto, retirada de los mismos y prevencin y (3) el proceso de mejora de calidad, estos

40

procesos han sido probados y certificados por expertos en calidad que afirman que la calidad de un producto est directamente relacionada con la calidad del proceso empleado para crearlo. Existen varios instrumentos que nos permiten conocer los objetivos de la calidad como por ejemplo el Total Quality Management (TQM), process of plan, Do, Check and Act (PDCA) con estos podemos identificar fallas, desarrollar acciones detalladas y gestionar el apoyo a la gerencia y a los recursos asignados para el proyecto para trabajar la calidad en la ingeniera del software.

2. Procesos de Gestin de Calidad del Software La gestin de calidad del software (SQM) es de gran importancia y aplicacin a todas las perspectivas de procesos de software, productos y recursos, estos consisten en numerosas actividades, algunos de ellos pueden encontrar errores diariamente mientras que otros pueden resultar ms bien en valiosas revisiones. El SQM puede ser utilizado para evaluar productos intermedios as como el producto final. Algunos de los procesos especficos estn definidos por la IEEE: Procesos de aseguramiento de calidad Procesos de Verificacin Procesos de Validacin Procesos de Revisin Procesos de Auditora

Estos procesos incentivan la calidad y tambin permiten encontrar posibles problemas. Todos los procesos SQM estn enfocados a cumplir tareas y tcnicas para asegurar una calidad de software ptima en un proyecto dado, estos procesos estn estrechamente relacionados, pueden solaparse y hasta en ocasiones estar combinados. Tambin es importante tener en cuenta la gestin de riesgo ya que est juega un papel importante en la entrega de software de calidad. Revisiones de Gestin: El objetivo es supervisar el progreso, determinando el estado de los planes y programas, requerimientos confirmados y su sistema de localizacin o evaluar la efectividad de los enfoques de gestin empleados. Con esto se determina la idoneidad de los proyectos, programas y requerimientos y supervisan su progreso o inconsistencias.

41

Revisiones Tcnicas: El propsito es evaluar el producto software para determinar si es idneo para su correspondiente uso, deben establecerse los roles especficos, una revisin tcnica requiere que las entradas obligatorias estn en su lugar con el objeto de proceder a: exposicin de objetivos, un producto software especfico, el plan especfico de gestin del proyecto, la lista de cuestiones claves asociadas al producto y el procedimiento de revisin tcnica. Inspecciones: Detecta e identifica anomalas en los productos de software, existen dos importantes elementos diferenciadores entre inspeccin y revisin y son los siguientes: un individuo que mantiene una posicin de direccin sobre cualquier miembro del equipo de inspeccin; la inspeccin ha de ser llevada por un inspector con formacin en inspecciones tcnicas. Las inspecciones por lo general requieren el autor de un producto intermedio y tambin a un lder de inspeccin, generalmente son hechas sobre una pequea seccin del producto a la vez, las anomalas encontradas deben ser documentadas y enviadas al responsable de la inspeccin, tambin es recomendable manejar listas de chequeo durante la inspeccin de esta manera se clasifican las anomalas y se determinan su exactitud e integridad. Walk-throughs: El objetivo es evaluar el producto software, los objetivos principales son: Encontrar anomalas, mejorar el producto software, considerar implementaciones alternativas, evaluar la conformidad con estndares y especificaciones. Es similar a una inspeccin pero su desarrollo por lo general es menos formal, generalmente es desarrollado por el ingeniero de software para darle una oportunidad a su equipo de repasar el trabajo como una tcnica de aseguramiento. Auditoras: El objetivo es realizar una evaluacin independiente de la conformidad de productos de software y procesos a regulaciones aplicables, estndares, directrices, planes y procedimientos, est formalmente organizada con participantes que cumplen roles especficos contando con un representante de la organizacin auditada. Puede realizarse sobre casi cualquier proceso o producto en cualquier etapa de mantenimiento o desarrollo.

3. Consideraciones Prcticas: 3.1 Requerimientos de calidad del software: Aqu influyen varios factores como la planificacin la gestin y seleccin de actividades SQM y tcnicas incluyendo: Donde residir el software, requerimientos del sistema y del software, los

42

componentes comerciales, estndares, mtodos y herramientas de software, el presupuesto y los usuarios implicados como tambin el nivel de integridad del sistema. Las tcnicas dinmicas son ejecutadas durante todo el desarrollo y el mantenimiento de software, generalmente son tcnicas de testeo o simulacin. Las pruebas examinan todos los output de la especificacin de requerimientos de software con el objeto de asegurar su trazabilidad, consistencia, completitud, correccin y ejecucin. Existen muchos tipos de pruebas entre ellos la de terceros ya que es la de un facilitador independiente por lo general acreditado por alguna autoridad su objetivo es probar el producto respecto a su conformidad con un conjunto de exigencias.

43

CAPITULO 12 DISCIPLINAS RELACIONADAS CON LA INGENIERIA DEL SOFTWARE

Este captulo se centra en relacionar cada una de las disciplinas de la figura 1 con la Ingeniera del Software. Es especfico en lo que respecta a determinar las temticas de cada una de ellas con respecto a otras.

Vous aimerez peut-être aussi