El Software

                                                                

                                                        DEFINICIÓN DE EL SOFTWARE

El software es una palabra que proviene del idioma inglés, pero que gracias a la masificación de uso, ha sido aceptada por la Real Academia Española. Según la RAE, el software es un conjunto de programas, instrucciones y reglas informáticas que permiten ejecutar distintas tareas en una computadora.

Se considera que el software es el equipamiento lógico e intangible de un ordenador. En otras palabras, el concepto de software abarca a todas las aplicaciones informáticas, como los procesadores de textos, las planillas de cálculo y los editores de imágenes.

                                     CUALIDADES DE UN SOFTWARE

Correcto: Un software es correcto si se comporta de acuerdo a su especificación.

Confiable: El software se comporta de acuerdo con lo esperado por el usuario.

Robusto: Un software es robusto si se comporta en forma razonable aun en situaciones no anticipadas.

Eficiencia: Es eficiente si usa recursos en forma económica.

Amigable: si el usuario lo encuentra fácil de usar.

Verificable: si sus propiedades pueden ser comprobadas.

Reusable: ya desarrollado se use con pocos o ningún cambio.

Portables: si pueden usarse y ejecutarse en distintos ambientes.

Interoperable: si puede coexistir y cooperar con otros sistemas.

                           FACTORES DE CALIDAD DE UN SOFTWARE

En los factores que podemos nombrar para que el cliente sienta satisfacción en todas sus necesidades en la presencia del software ya desarrollado serian;

Corrección.

Fiabilidad

Eficiencia

Seguridad

Facilidad

               VISIÓN GENERAL DEL PROCESO DE DESARROLLO DE SOFTWARE

Es proceso es afectado por la creatividad y juicio de las personas  involucradas. En el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente.

Es actividades requeridas para desarrollar un sistema de software de alta calidad y proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Actividades: Diseño, validación, evolución, especificación.

                                                           El Papel del Usuario 

*El proyecto no se puede hacer solo.

*Se debe tener en cuenta que el software debe cubrir las necesidades del usuario.

*Los analistas están para ayudar y colaborar con los usuarios en la especificación y diseño de la solución.

*Es fundamental documentar el proyecto.

    RESPONSANBILIDAD ETICA Y PROFESIONAL EN INGENIERIA DEL SOFTWARE

Existen áreas donde los estándares de comportamiento aceptable no están acotados por las leyes, sino por la responsabilidad profesional, algunas de estas son:

Confidencialidad: Respetar la confidencialidad de sus empleadores o clientes, independientemente de que se haya firmado un acuerdo formal de confidencialidad.

Competencia: No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos que están fuera de su capacidad.

Derechos de propiedad intelectual: Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como las patentes el copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y clientes está protegida.

                              CICLO DE VIDA DE UN SOFTWARE

El ciclo de vida básico de un software consta de los siguientes procedimientos:

Análisis: Construye un modelo de los requisitos

Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.

Codificación: Construye el sistema. La salida de esta fase es código ejecutable.

Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.

Validación: es el proceso de comprobar que lo que se ha especificado es lo que el usuario realmente quería.

Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos.

PRINCIPIOS, MODELOS, METODOS, METODOLOGÍAS TÉCNICAS, ACTIVIDADES Y HERRAMIENTAS EN EL PROCESO DE DESARROLLO DE SOFTWARE

Principios: 

Eliminar Desperdicios

Desperdicio es todo aquello en lo que invertimos recursos pero que no es traducido en valor para nuestro cliente. Este principio nos advierte que siempre hay que estar en la búsqueda de eliminar desperdicios en nuestro proceso, en cualquiera de las formas que este pueda presentar. Crear Conocimiento: El proceso debiera considerar en todas las áreas que sea posible, transmitir el conocimiento de una forma rápida y eficiente para que el equipo esté lo más nivelado en el entendimiento de lo que se produce, cómo se produce y para qué se produce. 

Calidad Intrínseca

Todas las pequeñas partes que conforman el producto final deben ser construidas con calidad desde el primer momento y no esperar que un proceso futuro sea el encargado de agregarla. Esto se traduce en integración continua, automatización de procesos repetitivos (testing, deploy, etc) y eliminación de código duplicado al momento de detectarlo; pero también en facilitar las discusiones cara a cara por sobre e-mail y en la disponibilidad de personas.  

Tomar decisiones con toda la información (Diferir compromiso)

Este principio advierte que no es buena idea tomar decisiones en base a estimados o adivinanzas. Las decisiones se deben postergar hasta el momento en que se tenga la mayor cantidad de información, sin caer en la irresponsabilidad.  

Entregar Rápido: Al entregar rápido se produce un ciclo de feedback óptimo y permite al equipo de desarrollo ajustar su modelo a la realidad con una mayor precisión y menor costo para el proyecto. Esto también se traduce en limitar la cola de tareas pendientes a un mínimo dado, para que siempre el alcance de lo que resta quepa dentro del contexto mental del equipo. Limita el trabajo en curso para cada persona de manera que puedan enfocarse en cada tarea a mano.  

Respetar a las personas

 Entrega el poder de tomar decisiones a quienes tienen el conocimiento y experiencia técnica para hacerlo, es decir, quienes implementarán finalmente las decisiones. Realiza entrenamientos internos o externos e incentiva la curiosidad intelectual. Alienta el espíritu por mejorar el oficio. 

Optimizar el todo

Enfoca tus esfuerzos de optimización en el flujo de valor que sale hacia el usuario y no en cada una de las partes que conforman tu proceso, usa una mirada global para optimizar. Siempre ten en tu nómina los mejores profesionales, técnicos y empleados que puedas conseguir, finalmente es el equipo el que hace la diferencia.

 

MODELOS DE PROCESO DE SOFTWARE  

*Codificar y corregir

*Modelo en cascada

 *Desarrollo evolutivo

*Desarrollo formal de sistemas

*Desarrollo basado en reutilización

*Desarrollo incremental

*Desarrollo en espiral

Codificar y corregir (Code-and-Fix)

 Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:

Escribir código.

Corregir problemas en el código.

Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y Mantenimiento.

 Este modelo tiene tres problemas principales:

Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.

Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.

El código es difícil de reparar por su pobre preparación para probar y modificar.

                                                    Modelo en cascada

El modelo en cascada consta de las siguientes fases:

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.

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.

Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. Departamento de Sistemas Informáticos y Computación.

Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.

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.

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.

                                                    Desarrollo evolutivo

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.

Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos.

El prototipo ayuda a terminar de definir estos requisitos.

Entre los puntos favorables de este modelo están:

La especificación puede desarrollarse de forma creciente.

 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:

Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.

Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.

Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Desarrollo formal de sistemas

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.

Observaciones sobre el desarrollo formal de sistemas:

Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.

 Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.

Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

Desarrollo basado en reutilización

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización.

Este modelo consta de 4 fases ilustradas en la A continuación se describe cada fase:

Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.

Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).

Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.

Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase:

Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.

Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).

Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.

Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

Desventajas de este modelo

Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.

Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.

Procesos iterativos

A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:

Desarrollo Incremental.

Desarrollo en Espiral.

Desarrollo incremental

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.

Entre las ventajas del modelo incremental se encuentran:

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.

Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.

Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.

Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.

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.

Desarrollo en espiral

Es actualmente uno de los más conocidos y fue propuesto por Boehm El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra.

Cada ciclo de desarrollo se divide en cuatro fases:

Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.

Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.

Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.

Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.

Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.

El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema.

MÉTODOS

Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.

METODOLOGÍA

Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.).

Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.

En actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos:

Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales. Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños. A continuación se revisan brevemente cada una de estas categorías de metodologías.

Metodologías estructuradas

 Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación

Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación.

Metodologías orientadas a objetos

Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java11 o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.

En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML)12, la notación OO más popular en la actualidad.

Metodologías tradicionales (no ágiles)

Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.

Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.

Metodologías ágiles

Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento).

ACTIVIDADES

Planificación

La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software.

Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.

Implementación, pruebas y documentación

La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto.

Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores de software lo antes posible.

La documentación del diseño interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un API, tanto interior como exterior.

Despliegue y mantenimiento

El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción.

Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software. El mantenimiento y mejora del software de un software con problemas recientemente desplegado puede requerir más tiempo que el desarrollo inicial del software. Es posible que haya que incorporar código que no se ajusta al diseño original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno rediseñar el sistema para poder contener los costes de mantenimiento.

Técnicas y herramientas

Son un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.

• Las Herramientas CASE son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.

• La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.

 • Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

• Análisis de datos y procesos integrados mediante un repositorio.

 • Generación de interfaces entre el análisis y el diseño.

• Generación del código a partir del diseño.

• Control de mantenimiento.

Tipos de Herramientas CASE

No existe una única clasificación de herramientas CASE, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:

• Las plataformas que soportan.

• Las fases del ciclo de vida del desarrollo de sistemas que abarca.

• La arquitectura de las aplicaciones que produce.

• Su funcionalidad.

Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:

Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.

Las herramientas I-CASE se basan en una metodología. Tienen un repositorio y aportan técnicas estructuradas para todas las fases del ciclo de vida. Estas son las características que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilización de lenguajes de alto nivel o técnicas de prototipo.

Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

Una estrategia posible es utilizar una U-CASE para análisis y diseño, combinada con otras herramientas más modernas para las fases de construcción y pruebas. En este caso, habría que vigilar cuidadosamente la integración entre las distintas herramientas.

SELECCIÓN DEL MODELO APROPIADO SEGÚN LAS CARACTERISTICAS DE LOS PROYECTOS DE SOFTWARE

Cuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a fracasar. Según John Reel, existen 10 razones por las cuales un proyecto puede fracasar:

El personal de software no entiende las necesidades de los clientes.

El ámbito del producto está mal definido.

Los cambios se gestionan mal.

La tecnología elegida cambia.

Las necesidades comerciales cambian.

Los plazos de entrega no son realistas.

Los usuarios se resisten a la utilización del software.

Se pierde el patrocinio.

El equipo del proyecto carece de personal con las habilidades apropiadas.

Los gestores evitan las mejores prácticas y las lecciones aprendidas.

Para tener éxito en la consecución de un proyecto es necesario comenzar con pie derecho, esto se lo logra trabajando duro para entender el problema y dar una solución adecuada. Se debe rastrear el proyecto conforme se elabora el producto y se aprueba por parte del grupo de control de calidad. Es importante que el gestor del proyecto tome decisiones inteligentes para no poner en riesgo el desarrollo de la solución. Por último, se debe analizar los resultados obtenidos para obtener la experiencia necesaria en la construcción de otros proyectos.