Fundamentos de Desarrollo de Sistemas Unidad IV FUNDAMENTOS DE DESARROLLO DE SISTEMAS UNIDAD IV MODELOS DE PROCESO DE SOFTWARE Modelo de Proceso de Software (SPM) es una descripción de los aspectos estructurales y de comportamiento de un proceso en el ámbito del desarrollo de software, usando como formalismo algún lenguaje de modelización de procesos (Process Modeling Language, PML). En los últimos 15 años, la modelización de procesos y, particularmente, de procesos de software, ha adquirido una importancia creciente como mecanismo que debe permitir, por un lado, una mejor comprensión de ese proceso con vistas a su evaluación y mejora y, por otro, la posibilidad de lograr un cierto grado de automatización del mismo, tal como es norma en otras disciplinas de la ingeniería. Un reto fundamental de la modelización de procesos de software es el de encontrar un PML (Process Modeling Language, PML) estándar para la descripción de los mismos. En este sentido, en los últimos años se ha hecho un esfuerzo para tratar de adaptar UML (Unified Modeling Language) los requisitos que plantean los procesos de software. Con ese objetivo han nacido perfiles UML y metamodelos, como SPEM o PROMENADE, que tratan de proponer un formalismo de modelización de procesos de software basado en UML. El modelo de proceso de software es como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Instituto Tecnológico de Ciudad.Juárez 59 Fundamentos de Desarrollo de Sistemas Unidad IV 4.1 MODELO DE CASCADA. El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: 1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. 2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. 4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos. La interacción entre fases puede observarse en la Figura 4.1. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas. Instituto Tecnológico de Ciudad.Juárez 60 Fundamentos de Desarrollo de Sistemas Unidad IV Figura 4.1: Modelo de desarrollo en cascada. En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son: Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos. Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases. Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante. Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto. Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos. Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes. Instituto Tecnológico de Ciudad.Juárez 61 Fundamentos de Desarrollo de Sistemas Unidad IV 4.2 MODELO DE ESPIRAL. El Modelo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo son una espiral, cada bucle es una actividad. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior. Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema. CARACTERISTICAS: Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos. Incluye la etapa de análisis de riesgos, no incluida anteriormente. Es ideal para crear productos con diferentes versiones mejoradas como se hace con los softwares modernos de microcomputadoras. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. Este es el enfoque más realista actualmente. El modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Instituto Tecnológico de Ciudad.Juárez 62 Fundamentos de Desarrollo de Sistemas Unidad IV Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto. Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación. Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación. Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente. Instituto Tecnológico de Ciudad.Juárez 63 Fundamentos de Desarrollo de Sistemas Unidad IV VENTAJAS: El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no termina cuando se entrega el software. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemáticos. Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma. La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representa el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo. Instituto Tecnológico de Ciudad.Juárez 64 Fundamentos de Desarrollo de Sistemas Unidad IV PROBLEMAS: Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable. Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la evolución. 4.3 MODELO INCREMENTAL. El modelo incremental mitiga la rigidez del modelo en cascada, descomponiendo el desarrollo de un sistema en partes; para cada una de las cuales se aplica un ciclo de desarrollo (en cascada en la representación gráfica siguiente). Ventajas El usuario dispone de pequeños subsistemas operativos que ayudan a perfilar mejor las necesidades reales del sistema en su conjunto. El modelo produce entregas parciales en periodos cortos de tiempo, comparados con el tiempo necesario para la construcción del sistema en su conjunto, y permite la incorporación de nuevos requisitos que pueden no estar disponibles o no ser conocidos al iniciar el desarrollo. Inconvenientes Se necesitan pruebas de regresión Pueden aumentar el costo debido a las pruebas Instituto Tecnológico de Ciudad.Juárez 65 Fundamentos de Desarrollo de Sistemas Unidad IV Algunas de las desventajas identificadas para este modelo son: Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas). Cada incremento debe aumentar la funcionalidad. Es difícil establecer las correspondencias de los requisitos contra los incrementos. Es difícil detectar las unidades o servicios genéricos para todo el sistema. Combina elementos del modelo lineal con la filosofía de creación de prototipos. El primer incremento a menudo es un producto esencial (núcleo), a partir de la evaluación se planea el siguiente incremento y así sucesivamente. Es interactivo por naturaleza, es útil cuando el personal no es suficiente para la implementación completa. R E Q U I S I T O S Diseño Codificación Diseño Pruebas Codificación Operación Mantenim. Integración Pruebas Diseño Integración Codificación Sub-sistema Sub-sistema Operación Mantenim. Pruebas SISTEMA … Aunque en la representación gráfica de la figura anterior, los desarrollos de cada subsistema se solapan en el tiempo, en su aplicación real, el segundo y siguientes subsistemas pueden comenzar una vez concluido el anterior. Resulta Apropiado: Desarrollo de sistemas en los que el cliente necesita disponer de parte de la funcionalidad antes de lo que costaría desarrollar el sistema completo. Desarrollo de sistemas en los que por razones del contexto interesa realizar la obtención de los requisitos de forma escalonada a través de subsistemas. Instituto Tecnológico de Ciudad.Juárez 66 Fundamentos de Desarrollo de Sistemas Unidad IV Se sugirió el enfoque incremental de desarrollo (Mills 1980) como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Siguiente Figura) . Es una combinación del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo. 4.4 PROCESO DE DESARROLLO UNIFICADO. El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational", donde confluyen 'los tres amigos' como se llaman a sí mismos o los tres grandes OO: Grady Booch, James Rumbaugh e Ivar Jacobson. El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. Instituto Tecnológico de Ciudad.Juárez 67 Fundamentos de Desarrollo de Sistemas Unidad IV El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas. Proceso Unificado y MSF; complementos tecnológicos "Más que una metodología, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guían a una organización sobre como ensamblar los recursos, el personal y las técnicas necesaria para asegurar que su infraestructura tecnológica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relación clara entre los objetivos de negocio y las implementaciones tecnológicas". "MSF se puede utilizar por sí mismo o con otras herramientas y técnicas como el Proceso Rational [Proceso Unificado] para planear, construir y administrar el desarrollo de soluciones de negocio a la medida". "El proceso Unificado es un proceso de desarrollo de software configurable que se adapta a proyectos que varían en tamaño y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología de objetos en el desarrollo de software de misión crítica en una variedad de industrias. Uno de los componentes clave es el UML". MSF proporciona las técnicas ligadas a la tecnología y el Proceso Unificado la guía detallada para el desarrollo de software minimizando los riesgos. El Proceso Unificado ha adoptado un enfoque que se caracteriza por: Interacción con el usuario continua desde un inicio Mitigación de riesgos antes de que ocurran Liberaciones frecuentes Aseguramiento de la calidad Involucramiento del equipo en todas las decisiones del proyecto Anticiparse al cambio de requerimientos Instituto Tecnológico de Ciudad.Juárez 68 Fundamentos de Desarrollo de Sistemas Unidad IV El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reuso. MSF considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa: Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organización y de cómo son apoyados por una infraestructura tecnológica basada en servicios. Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor. Arquitectura de Información – Define qué información es necesaria para apoyar el proceso de negocios y como poner esa información eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes. Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de herramientas, bloques de construcción de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor. El Modelo de Equipo de MSF muestra como estructurar equipos de alto desempeño para crear soluciones más rápido, mejor y más baratas. El Modelo de Equipo de MSF se basa en las formas de organizar equipos para crear los propios productos de Microsoft. Hace énfasis en las comunicaciones claras y en un equipo de iguales con papeles y responsabilidades claras en todo el proyecto. La calidad del producto se asegura por cada miembro del equipo. El Proceso Unificado proporciona más detalle y guía para algunos de los roles en el proyecto. Una vista arquitectónica es "una descripción simplificada (una abstracción) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva". Instituto Tecnológico de Ciudad.Juárez 69 Fundamentos de Desarrollo de Sistemas Unidad IV Las características primordiales del Proceso Unificado son: Iterativo e incremental Centrado en la arquitectura Guiado por casos de uso Confrontación de riesgos El Proceso Unificado es un proceso porque "define quién está haciendo qué, cuándo lo hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software". Según los conceptos clave del Proceso Unificado son: Fase e iteraciones ¿Cuándo se hace? Flujos de trabajo de procesos (actividades y pasos) ¿Qué se está haciendo? Artefactos (modelos, reportes, documentos) ¿Qué se produjo? Trabajador: un arquitecto ¿Quién lo hace?) El ciclo de vida del software en el Proceso Unificado Las fases del ciclo de vida del software son: concepción, elaboración, construcción y transición. La concepción es definir el alcance del proyecto y definir el caso de uso. La elaboración es proyectar un plan, definir las características y cimentar la arquitectura. La construcción es crear el producto y la transición es transferir el producto a sus usuarios. Diagrama ilustrando como el énfasis relativo en las distintas disciplinas cambia a lo largo del proyecto Figura 1. Estructura del Proceso Unificado Instituto Tecnológico de Ciudad.Juárez 70 Fundamentos de Desarrollo de Sistemas Unidad IV Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. El diseño de software se realiza a tres niveles: conceptual, lógico y físico. Figura 2. Arquitectura lógica de tres capas de una aplicación cliente/servidor Características Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. Dirigido por los Casos de Uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el RUP. Instituto Tecnológico de Ciudad.Juárez 71 Fundamentos de Desarrollo de Sistemas Unidad IV Centrado en la Arquitectura El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc. Enfocado en los Riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. 4.5 PROCESO DE SOFTWARE PERSONAL. Cada ingeniero es diferente; para ser más eficiente, debe planificar su trabajo basándose en datos tomados de su propia trayectoria profesional. Para mejorar auténticamente su trabajo, los ingenieros deben usar procesos personales bien definidos y cuantificados. Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos. Los buenos productos no se obtienen por azar, sino como sonsecuencia de un esfuerzo positivo para hacer un trabajo de calidad. El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute). El SEI es un centro de investigación y desarrollo patrocinado por el Instituto Tecnológico de Ciudad.Juárez 72 Fundamentos de Desarrollo de Sistemas Unidad IV Departamento de Defensa de los Estados Unidos de América y gestionado por la Universidad Carnegie-Mellon. "CMM" es una marca registrada del SEI. El Proceso Personal de Software es una versión pequeña de CMM donde se preocupa solo por un conjunto de las KPAs (Key Process Areas). Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros principiantes. El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo, Administración de configuraciones y Administración de requerimientos. KPAs (Key Process Area). Es el conjunto de actividades relacionadas tales que cuando se llevan a cabo, se logran un conjunto de objetivos. Estos objetivos son considerados importantes para mejorar la capacidad del proceso. Para cada Area Clave (Key Process Area) está presentada en el modelo de acuerdo a Características Comunes (Common Features), referidas a su institucionalización: Compromiso en realizar Capacidad de realizar Actividades realizadas Medición y análisis Verificación de implementación Instituto Tecnológico de Ciudad.Juárez 73 Fundamentos de Desarrollo de Sistemas Unidad IV Estructura del Modelo CMM Niveles de Madurez indican contiene Capacidad del proceso Areas Clave del Proceso logra organizada por Características Comunes Objetivos refiere a Implementación o Institucionalización Prácticas Clave describe Infraestructura o actividades El PSP se orienta en el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. Los siguientes son los niveles y las KPAs (Key Process Areas) que se manejan en cada uno: Nivel 1 - Inicial: o Nivel 2- Repetible: o o o o o o Ninguno Gestión de Requerimientos Establecer y mantener un acuerdo con el cliente respecto a los requerimientos para el software Planificación de Proyecto de Software Establecer planes razonables para la construcción del software y para gestionar el proyecto de software Seguimiento y Supervisión de proyectos de Sw Ofrecer adecuada visibilidad Gestión de Subcontratos de Sw Elegir subcontratistas de software calificados y gestionarlos de forma adecuada Aseguramiento de la calidad del Sw Proporcionar a la dirección una visibilidad apropiada sobre el proceso utilizado por el proyecto y los productos construidos Gestión de la Configuración del Sw Establecer y mantener la integridad de los productos del proyecto de software a lo largo de su ciclo de vida; es una parte integral de la mayoría de los procesos de ingeniería y de gestión Nivel 3- Definido: o o o Foco en el proceso de la organización Definición del proceso de la organización Plan de entrenamiento Instituto Tecnológico de Ciudad.Juárez 74 Fundamentos de Desarrollo de Sistemas Unidad IV o o o o Gestión integrada del software Utilizar el proceso definido adecuado para cada proyecto y gestionarlo en base a este Ingeniería del producto de software Las tareas están definidas, integradas y se cumplen de forma consistente, y los productos intermedios se mantienen consistentes Coordinación entre grupos Con otras áreas del proyecto (sistema) Revisión por pares Nivel 4- Gestionado: o o Detección temprana de defectos Gestión de la calidad del sofware Definir objetivos de calidad, establecer planes para alcanzar los objetivos, control y ajuste de los planes, productos y actividades Gestión cuantitativa del proceso Histogramas, listas de comprobación, gráficas Nivel 5– Optimizante: o o o Gestión del cambio del proceso Gestión del cambio de la tecnología Prevención de defectos El PSP tiene varias fases: PSP0: Proceso Base. PSP0.1: Complementos al proceso base. PSP1 y PSP1.1: Planeación personal. PSP2 y PSP2.1: Control de calidad personal. PSP3: Programas más grandes. Principios de PSP El diseño de PSP se basa en los siguientes principios de planeación y de calidad. Cada ingeniero es esencialmente diferente; para ser más precisos, los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales. Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos bien definidos y medidos. Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos. Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes. Es más eficiente prevenir defectos que encontrarlos y arreglarlos. La manera correcta de hacer las cosas es siempre la manera más rápida y más barata de hacer un trabajo. Instituto Tecnológico de Ciudad.Juárez 75