UNIDAD 2

PLANIFICACION DEL SISTEMAS

Objetivo: Realizar la planificacin de un proyecto de software de una organizacin

UNIDADII/PLANIFICACIONDELSISTEMA

2.1. PLANIFICACIN DEL TIEMPO

Uno de los factores ms conocidos por los participantes de un proyecto es el del tiempo. Podrn no conocer el costo financiero, podrn no conocer que recursos (que tambin integran los costos, porque al final tambin se traducen en gastos) se utilizan en dicho proyecto, pero lo que si se suele saber es para cuando el proyecto debe estar concluido. Por lo tanto, el tiempo es la delimitacin ms conocida. Todo proyecto est sujeto al tiempo, a una duracin. La mayora de los proyectos tienen una fecha lmite para la que el proyecto deber estar concluido. Adems, el proyecto posiblemente disponga de una serie actividades que se deben cumplir.La duracin de las tareas es el periodo de tiempo que transcurre entre la fecha de comienzo de una tarea y su fecha de finalizacin. Como podemos establecer la duracin de una tarea? Existe alguna tcnica que nos ayude a definirla?

LA DURACIN DE LAS TAREAS SE ESTABLECE APLICANDO ALGUNO DE ESTOS FACTORES: La Historia: Consiste en establecer una consultora sobre similares proyectos

realizados con anterioridad y recoger datos histricos. Como se hicieron, cuanto duraron sus tareas. etc. La Participacin: Consiste en contar con personas que tengan experiencia en

proyectos idnticos (mismo) aunque sean bajo otras circunstancias. La Intuicin: Contar con personas que hayan realizado un proyecto con similares

caractersticas. La Indeterminacin.: Hacer una estimacin, a veces no basada en nada

concreto. (por impulsos).

2.2. EVALUACION DEL COSTO BENEFICIO

FACTORES EN EL COSTO DEL SOFTWARE Existen muchos factores que influyen en el costo de un producto de programacin. El efecto de estos factores es difcil de estimar y, por ende tambin lo es el costo del esfuerzo en el desarrollo o en el mantenimiento.

38

UNIDADII/PLANIFICACIONDELSISTEMA
Entre los factores que afectan se observan, en forma primordial, las capacidades individuales del personal asignado al proyecto y su familiaridad con el rea de aplicacin, la complejidad del producto, el tamao de ste, el tiempo asignado, el nivel de confiabilidad, el nivel tecnolgico utilizado; la disponibilidad, familiaridad y estabilidad del sistema donde se desarrolla el producto. ESTIMACIN DE COSTOS Al principio, el costo del software constitua un pequeo porcentaje del costo total de los sistemas basados en computadora. Un error considerable en las estimaciones del costo del software tena relativamente poco impacto. Hoy en da, el software es el elemento ms caro de la mayora de los sistemas informticos. Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y prdidas. Sobrepasarse en el costo puede ser desastroso para el equipo de desarrollo. La estimacin del costo y del esfuerzo del software nunca ser una ciencia exacta. Son demasiadas las variables humanas, tcnicas, de entorno, polticas que pueden afectar al costo final del software y al esfuerzo aplicado para desarrollarlo. Sin embargo, la estimacin del proyecto de software puede dejar de ser un oscuro arte para convertirse en una serie de pasos sistemticos que proporcionen estimaciones con un grado de riesgo aceptable. PARA REALIZAR ESTIMACIONES SEGURAS DE COSTOS Y ESFUERZOS TENEMOS VARIAS OPCIONES POSIBLES: Dejar la estimacin para ms adelante (obviamente, podemos realizar una

estimacin al cien por cien fiable tras haber terminado el proyecto!). Basar las estimaciones en proyectos similares ya terminados. Utilizar tcnicas de descomposicin relativamente sencillas para generar las

estimaciones de costo y de esfuerzo del proyecto. Desarrollar un modelo emprico para el clculo de costos y esfuerzos del

software. Desafortunadamente, la primera opcin, aunque atractiva, no es prctica. Las estimaciones de costos han de ser proporcionadas a priori. Sin embargo, hay que reconocer que cuanto ms tiempo esperemos, ms cosas sabremos, y cuanto ms sepamos, menor ser la probabilidad de cometer serios errores en nuestras estimaciones.

39

UNIDADII/PLANIFICACIONDELSISTEMA
La segunda opcin puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Desafortunadamente. La experiencia anterior no ha sido siempre un buen indicador de futuros resultados. Las opciones restantes son mtodos viables para la estimacin del proyecto de software. Desde un punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas. Usando cada una de ellas como comprobacin de las otras. Las tcnicas de descomposicin utilizan un enfoque de divide y vencers para la estimacin del proyecto de software. Dentro de la mayor parte de las organizaciones, la estimacin de costos de la programacin se basa en las experiencias pasadas. Los datos histricos se usan para identificar los factores de costo y determinar la importancia relativa de los diversos factores dentro de la organizacin. Lo anterior, por supuesto, significa que los datos de costos y productividad de los proyectos actuales deben ser centralizados y almacenados para un empleo posterior. La estimacin de costos puede llevarse acabo en forma jerrquica hacia abajo o en forma jerrquica hacia arriba (Bottom-Up).

La estimacin jerrquica hacia abajo Se enfoca primero a los costos del nivel del sistema, as como a los costos de manejo de la configuracin, del control de calidad, de la integracin del sistema, del entrenamiento y de las publicaciones de documentacin. Los costos del personal relacionado se estiman mediante el examen del costo de proyectos anteriores que resulten similares. La estimacin jerrquica hacia arriba Primero se estima el costo del desarrollo de cada mdulo o subsistema; tales costos se integran para obtener un costo total. Esta tcnica tiene la ventaja de enfocarse directamente a los costos del sistema, pero se corre el riesgo de despreciar diversos factores tcnicos relacionados con algunos mdulos que se desarrollarn. La tcnica subraya los costos asociados con el desarrollo independiente de cada mdulo o componente individual del sistema, aunque puede fallar al no considerar los costos del manejo de la configuracin o del control de calidad.

40

UNIDADII/PLANIFICACIONDELSISTEMA
En la prctica, ambas tcnicas deben desarrollarse y compararse para que iterativamente se eliminen las diferencias obtenidas. PARA ANALIZAR UN ANLISIS DE COSTO-BENEFICIO SE DEBE TOMAR EN CUENTA LAS SIGUIENTES RECOMENDACIONES:

Para obtener el costo. 1.-Identificar primeramente el costo de la inversin ms importante de acuerdo a su monto. 2.-Identificar los costos complementarios consecuencia del punto1.

Para obtener el beneficio Es necesario que los beneficios que genere un proyecto sean traducidas al mismo tipo de unidad que se manejan en los costos para que estos puedan ser comparados y por lo tanto se facilite la toma de decisiones.

PARA OBTENER ESTA INFORMACIN SE RECOMIENDA LO SIGUIENTE: Identificar todo el problema que se pretenda resolver con la implantacin del proyecto. Cada problema debe ser traducido a la unidad de referencia del costo y referenciado a una cierta unidad de tiempo, por ej. Costo por da, por hora, etc.

2.3. ESTUDIO DE VIABILIDAD

Todos los proyectos son posibles: si se tiene infinitos recursos y tiempo! Desgraciadamente, el desarrollo de un sistema o producto basado en computadora es muy probable que est plagado de escasese de recursos y de fechas de entrega difciles (o totalmente no realistas). Es necesario y prudente evaluar la

viabilidad de un proyecto cuanto antes. Se pueden evitar meses o aos de esfuerzo, miles o millones de dlares y un bochorno profesional indecible si se reconoce un sistema mal concebido en la pronta fase de definicin. La viabilidad y el anlisis de riesgo estn relacionados de muchas maneras. Si el riesgo del proyecto es alto la viabilidad de producir software de calidad se reduce. Durante la ingeniera de producto, sin embargo, concentramos nuestra atencin en cuatro reas principales de inters:

41

UNIDADII/PLANIFICACIONDELSISTEMA
Viabilidad econmica. Una evaluacin del costo de desarrollo sopesado con los ingresos netos o beneficios obtenidos del sistema o producto desarrollado. Viabilidad tcnica. Un estudio de funcin, rendimiento y restricciones que puedan afectar a la consecucin de un sistema aceptable. Viabilidad legal. Determinar cualquier infraccin, violacin o responsabilidad legal en que se podra incurrir por el desarrollo del sistema. Viabilidad alternativa. Una evaluacin de los enfoques alternativos al desarrollo del sistema o producto. No es necesario un estudio de viabilidad para sistemas en que la justificacin econmica es obvia, el riesgo tcnico es bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable. Sin embargo, si falla alguna de las condiciones anteriores, se debera hacer un estudio del rea en cuestin. La justificacin econmica incluye una amplia gama de aspectos a tener en cuenta como son el anlisis de costes/beneficios, las estrategias de ingresos de la empresa a largo plazo, el impacto en otros productos o centros de beneficios, coste de recursos necesarios para el desarrollo y crecimiento potencial del mercado. La viabilidad tecnolgica es frecuentemente el rea ms difcil de valorar en esta etapa del proceso de ingeniera del producto. Como los objetivos, funciones y rendimiento son poco claros, cualquier cosa parece posible si se hacen las suposiciones correctas. Es esencial que el proceso de anlisis y definicin se realice en paralelo con una valoracin de la viabilidad tcnica. De esta manera se pueden juzgar especificaciones concretas a medida que se establecen.

42

UNIDADII/PLANIFICACIONDELSISTEMA

2.4. PLANIFICACION DE LA DOCUMENTACION

Plan de documentacin. Su funcin es definir y controlar la documentacin asociada con el proyecto. La buena documentacin proporciona una explicacin de la forma en que opera el sistema y qu caractersticas tienen los modelos y algoritmos utilizados en l. Muchos paquetes de hoja de clculo y de ayuda para la toma de decisiones guardan todos estos detalles en forma automtica a medida que se van especificando. Aunque esta informacin es transparente para el usuario, se puede recuperar cuando sea necesario ya sea en forma impresa o a travs de una pantalla. Muchos lenguajes de cuarta generacin son auto-documentados, lo que significa que los propios programas son tan fciles de entender que ellos se convierten en su propia documentacin. La lectura del cdigo explica lo que hace el programa. IMPORTANCIA DE LA DOCUMENTACION La documentacin de los programas es un aspecto sumamente importante, tanto en el desarrollo de la aplicacin como en el mantenimiento de la misma. Mucha gente no lo hace parte del desarrollo y no se da cuenta de que pierde la posibilidad de la reutilizacin de parte del programa en otras aplicaciones, sin necesidad de conocerse el cdigo al dedillo. La documentacin de un programa empieza a la vez que la construccin del mismo y finaliza justo antes de la entrega del programa o aplicacin al cliente. As mismo, la documentacin que se entrega al cliente tendr que coincidir con la versin final de los programas que componen la aplicacin. Una vez concluido el programa, los documentos que se deben entregar son una gua tcnica, una gua de uso y de instalacin. TIPOS DE DOCUMENTACIN: La documentacin que se entrega al cliente se divide claramente en dos categoras: Interna: Es aquella que se crea en el mismo cdigo, ya puede ser en forma de comentarios o de archivos de informacin dentro de la aplicacin. Externa: Es aquella que se escribe en cuadernos o libros, totalmente ajena a la aplicacin en si. Dentro de esta categora tambin se encuentra la ayuda electrnica.

43

UNIDADII/PLANIFICACIONDELSISTEMA
La gua tcnica En la gua tcnica o manual tcnico se reflejan el diseo del proyecto, la codificacin de la aplicacin y las pruebas realizadas para su correcto funcionamiento. Generalmente este documento esta diseado para personas con conocimientos de informtica, generalmente programadores. El principal objetivo es el de facilitar el desarrollo, correccin y futuro mantenimiento de la aplicacin de una forma rpida y fcil. ESTA GUA ESTA COMPUESTA POR TRES APARTADOS CLARAMENTE

DIFERENCIADOS: Cuaderno de carga: Es donde queda reflejada la solucin o diseo de la

aplicacin. Esta parte de la gua es nicamente destinada a los programadores. Debe estar realizado de tal forma que permita la divisin del trabajo Programa fuente: Es donde se incluye la codificacin realizada por los

programadores. Este documento puede tener, a su vez, otra documentacin para su mejor comprensin y puede ser de gran ayuda para el mantenimiento o desarrollo mejorado de la aplicacin. Este documento debe tener una gran claridad en su escritura para su fcil comprensin. Pruebas: Es el documento donde se especifican el tipo de pruebas realizadas a

lo largo de todo el proyecto y los resultados obtenidos. La gua de uso Es lo que comnmente llamamos el manual del usuario. Contiene la informacin necesaria para que los usuarios utilicen correctamente la aplicacin. Este documento se hace desde la gua tcnica pero se suprimen los tecnicismos y se presenta de forma que sea entendible para el usuario que no sea experto en informtica. Un punto a tener en cuenta en su creacin es que no debe hacer referencia a ningn apartado de la gua tcnica y en el caso de que se haga uso de algn tecnicismo debe ir acompaado de un glosario al final de la misma para su fcil comprensin. La gua de instalacin Es la gua que contiene la informacin necesaria para implementar dicha aplicacin. Dentro de este documento se encuentran las instrucciones para la puesta en marcha del sistema y las normas de utilizacin del mismo. Dentro de las normas de utilizacin se incluyen tambin las normas de seguridad, tanto las fsicas como las referentes al acceso a la informacin.

44

UNIDADII/PLANIFICACIONDELSISTEMA

GUIA PARA ELABORAR UN REPORTE

Formato del reporte escrito El formato del escrito depende de la cantidad de informacin disponible, la complejidad del asunto, la naturaleza del trabajo y otros factores que se toman en cuenta para la preparacin de bosquejos. Puede estar determinada por los reglamentos de la institucin, organizacin o empresa. A CONTINUACIN SE MUESTRA EL FORMATO PARA LA ELABORACIN DEL REPORTE DE UN PROYECTO: 1. Portada. 2. ndice. 3. Introduccin. 4. Justificacin. 5. Objetivos generales y especficos. 6. Problemas resueltos. 7. Alcances y limitaciones de las soluciones. 8. Procedimientos y descripcin de las actividades realizadas. 9. Resultados (planos, grficas, prototipos, programas, etc.). 10. Conclusiones y recomendaciones. 11. Referencias bibliogrficas.

2.5. GESTION DE LA CONFIGURACION DE SOFTWARE

Se denomina Gestin de la Configuracin el conjunto de procesos destinados a asegurar la validez que todo producto obtenido durante cualquiera de las etapas del desarrollo de un Sistema de Informacin (S.I.), a travs del estricto control de los cambios realizados sobre los mismos y de la disponibilidad constante de una versin estable de cada elemento para toda persona involucrada en el citado desarrollo. Estos dos elementos (control de cambios y control de versiones de todos los elementos del S.I.) facilitan tambin el mantenimiento de los sistemas al proporcionar una imagen detallada del sistema en cada etapa del desarrollo.

45

UNIDADII/PLANIFICACIONDELSISTEMA
La gestin de la configuracin se realiza durante todas las fases del desarrollo de un sistema de informacin, incluyendo el mantenimiento y control de cambios, una vez realizada la puesta en produccin. La gestin de la configuracin del software es uno de los procesos clave para toda organizacin dedicada a la Ingeniera del Software, ya que posibilita una mejor organizacin del desarrollo y mantenimiento, producto, facilitando el resto de procesos de produccin. Durante el proceso de construccin de un software, los cambios son inevitables. Los cambios provocan confusin e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniera. El arte de coordinar el desarrollo de software para minimizarla confusin, se denomina gestin de la configuracin. La gestin es el arte de identificar, organizar y controlar las modificaciones que sufre el softwarela meta es maximizar la productividad minimizando errores. LOS CAMBIOS DENTRO DEL DESARROLLO DEL SOFTWARE PUEDEN OCURRIR EN CUALQUIER MOMENTO POR LO TANTO DEBEMOS ESTAR PREPARADOS, LAS ACTIVIDADES DE CGS SIRVEN PARA: Identificar el cambio de nuestro software. Controlar ese cambio. Garantizar que el cambio quede bien implantado. Informar el cambio.

La gestin de configuracin del software no es un mantenimiento del software, el mantenimiento es la etapa final de la ingeniera hasta que se retire el producto del equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina slo una vez que el software queda fuera de circulacin. Desgraciadamente, en el proceso de ingeniera del software existe una variable importantsima que entra en juego, el cambio.

46

UNIDADII/PLANIFICACIONDELSISTEMA
La primera Ley de la ingeniera de sistemas establece: Sin importar en que momento del ciclo de vida del sistema nos encontremos, el sistema cambiar y el deseo de cambiarlo persistir a lo largo de todo el ciclo de vida. Entonces nos hacemos diferentes preguntas: Por qu cambiar el sistema? Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software: Nuevos requisitos del negocio o condiciones que dictan los cambios en las

condiciones del producto o en las normas comerciales. Nuevas necesidades del los clientes que demandan la modificacin de los datos

producidos por un sistema basado en computadora. Reorganizacin y/o reduccin del volumen comercial que provoca cambios en las

prioridades del proyecto o en la estructura del equipo de ingeniera del software. Restricciones presupuestarias o de planificaciones que provocan una redefinicin

del sistema o del producto. La gestin de configuracin del software realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora. La GCS es una actividad de garanta de calidad del software que se aplica en todas las fases del proceso de ingeniera del software. LINEAS BASE Una lnea base es un concepto de gestin de configuracin del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define una lnea base como: Una especificacin o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ah en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a travs de procedimientos formales de control de cambios. En el contexto de la ingeniera del software definimos una lnea base como un punto de referencia en el desarrollo del software y que queda marcado por el envo de uno o ms elementos de configuracin del software (ECS) y la aprobacin de ECS obtenido mediante una revisin tcnica formal.

47

UNIDADII/PLANIFICACIONDELSISTEMA
Por ejemplo, los elementos de una especificacin de diseo se documentan y se revisan. Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se han revisado corregido y aprobado, la especificacin de diseo se convierte en lnea base. Solo se pueden realizar cambios futuros en la arquitectura del software (contenidos en la especificacin del diseo) tras haber sido evaluados y aprobados. ELEMENTO DE CONFIGURACIN DE SOFTWARE Un elemento de la configuracin del software es la informacin creada como parte del proceso de ingeniera un ECS (elemento de configuracin de software) es un documento, un conjunto completo de casos de prueba o un componente de un programa dado. Los siguientes ECS son el objetivo de las tcnicas de gestin de configuracin y forman un conjunto de lneas base: 1) Especificacin del sistema 2) Plan de proyecto 3) Especificacin de requisitos 4) Prototipo ejecutable o en papel 5) Manual de usuario preliminar 6) Especificacin de diseos 7) Descripcin del diseo de datos 8). Descripcin del diseo arquitectnico 9) Descripciones del diseo de los mdulos 10) Descripciones del diseo de interfaces 11) Descripciones de los objetos (si se utilizan tcnicas de P.O.O) 12) Listados del cdigo fuente 13). Plan y procedimiento de pruebas

48

UNIDADII/PLANIFICACIONDELSISTEMA
14) Casos de prueba y resultados registrados 15) Manuales de operacin de y de instalacin 16) Programas ejecutables 17) Mdulos, cdigo ejecutable 18) Mdulos enlazados 19) Descripcin de la base de datos 20) Esquema y estructura de archivos 21) contenido inicial 22) Manual del usuario final 23) Documentos de mantenimiento 24). Informes de problemas del software 25) Peticiones de mantenimiento 26). Ordenes de cambios e ingeniera

Es importante considerar poner las herramientas de desarrollo de software bajo control de configuracin. Es decir congelar la versiones de editores, compiladores y otras herramientas CASE utilizadas durante el desarrollo, un cambio en las versiones utilizadas puede que produzca resultados diferentes que la versin original. Los ECS se organizan como objetos de configuracin que deben ser catalogados por la base de datos del proyecto con un nombre nico. Un ECS tiene un nombre y atributos, y est conectado a otros objetos mediante relaciones.

49

UNIDADII/PLANIFICACIONDELSISTEMA

La figura se muestra el modelo de datos de los elementos de al configuracin, cada objeto esta relacionado con otro, si se lleva a cabo un cambio sobre un objeto la interrelaciones sealan a que otros objetos afectar. EL PROCESO DE GESTIN DE LA CONFIGURACIN DEL SOFTWARE La GCS es un elemento importante de garanta de calidad es responsable de controlar los cambios. Sin embargo tambin se debe identificar los ECS individuales. El proceso se puede definir en cinco tareas de CGS: Identificacin Control de versiones Control de cambios Auditorias de configuracin Generacin de informes

AUDITORIA DE LA CONFIGURACION Cmo podemos asegurar que el cambio se ha implementado correctamente? La respuesta es doble: 1) Revisiones tcnicas formales 2)Aauditorias de configuracin del software.

50

UNIDADII/PLANIFICACIONDELSISTEMA
Las revisiones tcnicas formales se centran en la correccin tcnica del elemento de configuracin que ha sido modificado. Los revisores evalan el ECS para determinar la consistencia con otros ECS, las omisiones o los posibles efectos secundarios. Una auditoria de configuracin del software complementa la revisin tcnica formal al comprobar caractersticas que generalmente no tiene en cuenta la revisin. La auditoria se plantea y responde con las siguientes preguntas: Se ha hecho el cambio especificado en la OCI? Se han incorporado

modificaciones adicionales? Se ha llevado a cabo una revisin tcnica formal para evaluar la correccin

tcnica? Se han seguido adecuadamente los estndares de ingeniera de software? Se han "recalcado" los cambios en el ECS?Se han especificado la fecha del

cambio y el autor?Reflejan los cambios los atributos del objeto de configuracin? Se han seguido procedimientos del GCS para sealar el cambio, registrarlo y

divulgarlo? Se han actualizado adecuadamente todos los ECS relacionados?

INFORMES DE ESTADO La generacin de informes de estado de la configuracin es una tarea de GCS que responde a las siguientes preguntas: 1) Qu pas? 2) Quin lo hizo? 3) Cundo pas? 4) Que ms se vio afectado? La generacin de informes de estado de la configuracin desempea un papel vital en el xito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es muy fcil que no exista una buena comunicacin.

51

UNIDADII/PLANIFICACIONDELSISTEMA
Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda a eliminar esos problemas, mejorando la comunicacin entre todas las personas involucradas. La gestin y configuracin del software 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. La configuracin se organiza de tal forma que sea posible un control organizado de los cambios. La configuracin del software est compuesta por un conjunto objetos interrelacionados, denominados elementos de configuracin del software, que son provocados par la actividades del desarrollo, de la ingeniera del software. Las lneas base nos permiten guiarnos para desarrollar los cambios, los objetos forman un asociacin que refleja las variantes y relaciones creadas, el control de versiones son procedimientos y herramientas que ayudan a gestionar el uso de los objetos. El control de cambios es una actividad procedimental que asegura la calidad en los cambios del los ECS. La auditoria de configuracin es una actividad de SQA (Aseguramiento de la calidad del software) para asegurar la calidad durante los cambios. Durante el proceso de construccin de un software, los cambios son inevitables. Los cambios provocan confusin e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. La finalidad de la Gestin y configuracin del Software el conocer la estructura de procesos y herramientas para aplicar dentro de la construccin del software que nos ayudan a controlar los cambios. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniera para asegurar su control y calidad.

52