MEJORES PRÁCTICAS PARA EL DESARROLLO DE SOFTWARE

INTRODUCCIÓN

El presente documento argumenta el concepto de software, su proceso, modelos y metodologías concernientes previos hacia su desarrollo para un desempeño óptimo de este.

En la actualidad, la importancia del software se encuentra en un plano relevante con respecto al ámbito laboral, pues se torna de carácter necesario el uso de un sistema de apoyo para un mejor funcionamiento con respecto hacia las tareas de un proyecto para lograr un objetivo.

Por ello existe una gran variedad de modelos de procesos para producir un producto de software, el cual será seleccionado con acorde hacia las necesidades que requiera un proyecto. Pues es de suma importancia tener en cuenta las propiedades de la metodología a seleccionar, para tener una visión clara de su funcionamiento respecto a los objetivos del proyecto.

En síntesis, la mejor práctica para el desarrollo de un software será la que mejor se adecue hacia las necesidades de un proyecto. Pues ello optimizará su rendimiento para una misma finalidad.

En el presente trabajo se menciona dos de las metodologías más populares en la actualidad, el por qué de ello se argumentara en los siguientes capítulos.

CAPÍTULO 1

1.SOFTWARE E INGENIERÍA DE SOFTWARESegún Pressman (2004), es común darse cuenta que la invención de una tecnología puede tener efectos profundos e inesperados con otras tecnologías con las que en apariencia no tienen ninguna relación, como en empresas comerciales, en personas y aun en la cultura en su conjunto. Este fenómeno a menudo se denomina “la ley de las consecuencias imprevistas”.Actualmente el software de ordenadores es una tecnología independiente y a su vez de mucha importancia en el espacio laboral. También, haciendo referencia de lo argumentado por Pressman, se puede entonces deducir que es el software un claro ejemplo de “la ley de consecuencias imprevistas”.

1.1 SOFTWARE(Soft que traducido significa blando) nos hace referencia a lo intangible, la parte lógica, como son las instrucciones (programas) quienes serán el medio de interacción entre el factor humano y el hardware correspondiente a un sistema de información.

Según Pressman (2004), el software es un elemento del sistema que es lógico, en lugar de físico. Por tanto el software tiene unas características considerablemente distintas a las del hardware.En síntesis, el software y el hardware diferencian mucho. Aunque uno es necesario del otro para su funcionamiento, los procesos respecto a su elaboración son diferentes. Un software se desarrolla mientras que un hardware se construye.En cuanto a su estructura y funcionamiento básico Campderrich (2004), presenta que un sistema de software, denominado también aplicación o simplemente software, es un conjunto integrado de programas que en su forma definitiva se pueden ejecutar, pero comprende también las definiciones de estructuras de datos (por ejemplo, definiciones de bases de datos) que utilizan estos programas y también la documentación referente a todo ello (tanto la documentación de ayuda en el uso del software para sus usuarios como la documentación generada durante su construcción, parte de la cual también servirá para su mantenimiento posterior).En conclusión, un software hace referencia a toda aplicación o programa que será indispensable para realizar tareas especificas. Este atraviesa un proceso de desarrollo para el cual se establece un método de diseño específico.

1.2 INGENIERÍA DEL SOFTWAREEs la ciencia que principalmente se avocará al desarrollo del software. Para lo cual su proceso se puede definir como el conjunto de diversos periodos, los cuales contienen un orden parcial que tienen como finalidad lograr un objetivo, que involucra la calidad de este en su resultado.Según Somerville (2005), la ingeniería del software es una disciplina de la ingeniería que comprende todos los aspectos de la producción del software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza.En síntesis, la ingeniería de software no solo está dedicada al desarrollo del software, sino también hacia diferentes etapas durante su ciclo de vida. Según Campderrich (2005), en el caso de la ingeniería del software no se suele hablar de ingeniería de proceso; quizá se podría pensar que es la que hace referencia a la programación en sentido estricto, pero cada vez menos nítida la distinción entre la programación y las fases anteriores en el desarrollo de software.

1.2.1 OBJETIVO PRINCIPAL DE LA INGENIERÍA DE SOFTWARE Es necesario como importante, saber el objetivo principal que tiene la ingeniería del software para poder analizar el proceso del desarrollo del software.Según Cortés (2006), el objetivo principal de la ingeniería de software es construir una solución de software eficiente que satisfaga las necesidades requeridas por un cliente.El objetivo en teoría aparenta seguir un proceso sencillo, pero sin embargo el objetivo es difícil de conseguir si no se tiene los procedimientos, las metodologías y las herramientas proporcionadas.

1.2.2 OBJETIVOS ESPECÍFICOS DE LA INGENIRÍA DE SOFTWARESegún Cortés (2006), se pueden inferir que los objetivos específicos de la ingeniería de software son los siguientes:

•Proveer los estándares y los modelos que faciliten la comunicación, tanto como para clientes como para especialistas en la elaboración de un proyecto de software.•Proveer los métodos, herramientas y procedimientos para la “construcción” eficiente del software.•Proveer parámetros y criterios de evaluación de la calidad del software.

En síntesis, para desarrollar un óptimo producto de software se tiene que tomar en cuenta el objetivo específico de este. Ello nos permitirá tener una visión completa sobre su funcionalidad para su posterior uso.

CAPÍTULO 2

2.PROCESO DEL SOFTWARESegún Tuya, Ramos y Dolado (2007), los modelos de evaluación y mejora de procesos de software permiten calcular la capacidad o madurez de todos los procesos que intervienen en el ciclo de vida del software, detectar los puntos fuertes y los débiles de cada uno y proponer un conjunto de actividades o tareas orientadas de guiar la organización hacia una mejora gradual y continua de cada uno de estos procesos.Concluyendo con la idea anterior, los procesos del software serán muy importantes para la mejora de éste. De tal manera que su funcionamiento sea óptimo con respecto a versiones o modelos anteriores.

2.1MODELO DE PROCESO DE SOFTWAREUn modelo de proceso de software especifica la solución que será aplicada para problemáticas o incertidumbres que se presenten durante el desarrollo del sistema de software. Según Somerville (2005), un modelo de procesos del software es una descripción simplificada de un proceso del software que presenta una visión de ese proceso. Estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucradas en la ingeniería del software.

2.1.1ARQUITECTURA DE SOFTWARESegún Gómez y Ania (2008), una arquitectura de software define la estructura general de un sistema. Las arquitecturas varían de acuerdo con el tipo de sistema a desarrollarse. […] la selección de una arquitectura afecta aspectos como la extensibilidad del sistema (qué tan fácil es extenderlo en el futuro para incorporar más funcionalidad o mayor capacidad).Por lo tanto, la selección de la arquitectura a utilizarse debe de ser de tal manera que se encargue de minimizar los efectos que pudiecen producir cambios en un futuro dentro del sistema.

2.1.2ACTIVIDADES Según Weitzenfeld (2005), en el proceso de software las actividades definen los pasos necesarios para lograr las metas y los objetivos; por ejemplo, especificar los requisitos del sistema. Las actividades deben: ser fáciles de definir y seguir, simplificar la comprensión del sistema; y ofrecer

flexibilidad, presión y extensibilidad.Es de suma importancia tener en cuenta el objetivo que realizará un sistema, de software en este caso. Por ello, las actividades dentro de un proceso de software se convierten en un requisito indispensable para un desarrollo óptimo de éste.

2.1.3MÉTODOS Y METODOLOGÍASLos métodos serán quienes definan las pautas para modificaciones internas de las acciones, mientras que las metodologías serán quienes definen el acumulado o conjunto de métodos.Según Gómez y Ania (2008), un método es un procedimiento que define tareas o acciones a realizar, donde cada tarea incluye condiciones de entrada y de salida que se deben satisfacer antes de realizarse y después de completarse. Las diferentes metodologías varían en el alcance del apoyo que proporcionan el desarrollo de software.

2.1.3.1METODOLOGÍAS ESTRUCTURADASSegún Gómez y Ania (2008), las metodologías tradicionales o metodologías estructuradas se enfocan principalmente en la descomposición funcional de un sistema. El objetivo es lograr una definición completa del sistema en término de funciones estableciendo los datos de entrada y de salida correspondientes a cada función que debe cumplir el sistema.En síntesis, las metodologías estructuradas abarcan un funcionamiento amplio dentro de un sistema, ya que tiene un enfoque global de funcionamiento respecto a los datos de entrada y salida.

2.1.3.2METODOLOGÍAS ORIENTADAS A OBJETOSSegún Gómez y Ania (2008), las metodologías orientadas a objetos se enfocan principalmente en el modelado de un sistema en término de los objetos (y clases de objetos) que va a manipular. A diferencia de las metodologías estructuradas, inicialmente se identifican los objetos del sistema, para luego especificar su comportamiento (funciones).En conclusión, las metodologías orientadas a objetos a diferencia de las metodologías estructuradas, serán más específicas en sus procesos para determinados objetos ya que esta técnica no seguirá el mismo flujo de datos que la anterior.

2.1.4ESTRATEGIASSegún Gómez y Ania (2008), Las estrategias afectan aspectos como la arquitectura del sistema, el orden en que se llevan a cabo las actividades del proceso y las metodologías a utilizarse.En síntesis, es importante definir una estrategia dentro del proceso de un software, ya que existen diversos modelos para su desarrollo. Las estrategias ayudaran a definir dicho modelo según sea su funcionalidad y finalidad del proyecto.

2.1.5HERRAMIENTASSegún Gómez y Ania (2008), las herramientas son aplicaciones que apoyan diversos aspectos en la

administración del proceso de software. […] cuyo objetivo es asistir al desarrollador durante las diferentes actividades del ciclo de vida del proceso de software.Las herramientas serán indispensables dentro del proceso del software, asimismo, para la elección de herramientas se debe de tener en cuenta el apoyo a las metodologías en uso.

2.2MODELOS CLÁSICOSSegún Gómez y Ania (2008), los modelos de proceso dependen de las opiniones o creencias de las personas involucradas en un proyecto. […] para que un proceso tenga éxito es importante evaluar y administrar el riesgo y la entrega de etapas intermedias bien definidas aumenta la confianza que se tiene en el resultado final.Por ello se puede inferir que a partir de las creencias acerca del tipo de modelos clásicos se crearan paradigmas respecto a su rendimiento. Por ello será importante conocer el modelo a elegir para que este se adecue al proyecto requerido.

2.2.1MODELO CASCADASegún Somerville (2005), considera las actividades fundamentales del proceso de especificación, desarrollo validación y evolución, presentándolas como faces separadas del proceso. (Ver Anexo 1)

2.2.2MODELO ESPIRAL Según Weitzenfeld (2005), se basa en una estrategia para reducir el riesgo del proyecto en áreas de incertidumbre. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. (Ver Anexo 2)

2.2.3MODELO EVOLUTIVOSegún Somerville (2005), este enfoque entrelaza las actividades de especificación, desarrollo y validación. (Ver Anexo 3)

2.2.4MODELO INCREMENTALSegún Gómez y Ania (2008), consiste de un desarrollo inicial de la arquitectura completa del sistema, seguida de incrementos y versiones parciales de éste. (Ver Anexo 4)

2.3MODELOS NUEVOSEn esta sección se describen algunos modelos de procesos “nuevos” que surgieron después de los clásicos.

2.3.1MODELO GANAR-GANARSegún Gómez y Ania (2008), se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas.

2.3.2MODELO UNIFICADO (UP)Según Gómez y Ania (2008), se basa principalmente en la especificación de requerimientos de un

sistema mediante casos de uso […] considerando las cuatro P del desarrollo de software: personas, proyecto, producto y proceso. (Ver Anexo 5)

2.4 PROCESO PERSONAL Y DE EQUIPO PARA EL DESARROLLO DE SOFTWAREEn el caso del desarrollo de software de alta calidad, se espera que responda a las expectativas de los usuarios. Para ello es fundamental definir procesos tanto personales como para el trabajo en equipo. Entre los más importantes tenemos:2.4.1PSP (Personal software process)Según Gómez y Ania (2008), consiste en especificar la secuencia de pasos requeridos por un programador para desarrollar o mantener software.

2.4.2TSP (Team software process)Según Tuya, Ramos y Dolado (2007), proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad.

2.4.3XP (Extrem programing)Según Weitzenfeld (2005), este modelo toma los principios y prácticas aceptadas, y las lleva a niveles extremos. Tiene como objetivo reducir el riesgo en el ciclo de vida del software mediante grupos de desarrollo pequeños. (Ver Anexo 6)En síntesis, los modelos para los procesos de software varían de acuerdo a los objetivos y finalidades que plantean cada uno. El modelo a elegir dependerá de la finalidad de su uso.

CAPÍTULO 3

3.MEJORES PRÁCTICAS PARA EL DESARROLLO DE SOFTWARELas mejores prácticas para el desarrollo de un software determinado, dependerá de la finalidad de su posterior uso. La organización que requiera de un sistema de software tendrá que acoplar sus necesidades hacia el modelo más adecuado para optimizar su funcionamiento y rendimiento.Se considerará de igual manera las características del modelo del proceso de software, para que de esa manera se pueda tener una visión clara respecto a su calidad y de su posterior funcionamiento. Es decir, por lo anteriormente argumentado, no existe un modelo de proceso de software estándar que se adecue para cualquier tipo de requerimiento. Pero se puede denotar las más populares con respecto a su uso en la actualidad.

3.1 EXTREM PROGRAMING (XP)Las siglas ‘XP’ significan (extreme programing) que traducido al castellano significa (programación extrema), es una metodología que se utiliza para desarrollar un software de alta calidad de la manera más rápida posible, cualidad a la cual se deriva el nombre de dicha metodología. Caracterizada también por brindarle un mayor beneficio al cliente.

Según Borrero (2004), se caracteriza por tener ciclos de desarrollo extremadamente breves, integración constante, retroalimentación continua por parte del cliente, pruebas automatizadas regulares y enfoque de equipo. En síntesis, XP se va a caracterizar principalmente por tener en cuenta al factor humano como componente clave en su desarrollo.Según Gómez y Ania (2008), XP también se caracteriza por tomar en cuenta todas las posibles desventajas en el desarrollo de software y genera práctias para vencerlas o disminuir sus consecuencias.

3.1.1 LAS VARIABLES DE XPLas variables que existen dentro de la metodología XP tienen un valor muy importante durante su ciclo de vida, ya que la interacción entre estas variables y el control de las mismas son indispensables para el éxito del proyecto. Según Gómez y Ania (2008), XP es un modelo de desarrollo de software en la que hay cuatro variables que juegan un papel fundamental: costo, tiempo, calidad y alcance. […] El control de estas variables es llevado a cabo por los programadores, administradores y clientes.

3.1.2 PRINCIPIOS BÁSICOS DE XPSegún Gómez y Ania (2008), Los principios básicos que ofrecen medios mas conretos para aplicarlos son: retroalimentación rápida, simplicidad, cambios incrementales, cambios sin alterar lo ya desarrollado y trabajo de calidad.

3.1.2.1 RETROALIMENTACIÓN RÁPIDASe aplica una retroalimentación en relación al mismo sistema. Todo lo aprendido respecto con la experiencia del sistema se debe aplicar dicho sistema cuanto antes.3.1.2.2 SIMPLICIDADXP promueve soluciones simples que se adecuen hacia necesidades actuales, eso en vez de dedicar empeño en tratar de buscar una solución estándar.3.1.2.3 CAMBIOS INCREMENTALESConsiste en hacer mínimos cambios, que en conjunto sirvan para dar solución a un problema. 3.1.2.4 CAMBIOS SIN ALTERAR LO YA DESARROLLADOCada cambio realizado servirá para aumentar las funcionalidades que se encuentran resueltas, mas no para remplazarlas. 3.1.2.5 TRABAJO DE CALIDADSirve esencialmente para evitar el fracaso en el proyecto. Se basa en que todos los miembros del equipo comparten el mismo objetivo para un desarrollo óptimo.

3.1.3 LAS PRÁCTICAS DE XPConsiderando los principios básicos anteriormente presentados, se plantean las prácticas requeridas para usar una metodología XP en el desarrollo de software de alta calidad.3.1.3.1 PLANEACIÓNSe debe de considerar las prioridades del negocio como al igual que las estimaciones técnicas.

3.1.3.2 ALCANZE PEQUEÑOXP plantea que se realicen planes para periodos cortos como pudieran ser uno o dos meses aproximadamente.3.1.3.3 METÁFORAPermitirá identificar los elementos más relevantes del sistema y la relación existente entre ellos.3.1.3.4 DISEÑO SENCILLOEl diseño hacia la solución de problemas deberá de incluir solamente los elementos que sean necesarios para resguardar los requerimientos actuales.3.1.3.5 PRUEBASSegún Gómez y Ania (2008), XP lleva este concepto al extremo, por lo que sostiene que cualquier función de un programa que no sea provada no existe.3.1.2.6 REESTRUCTURACIÓNSe buscará simplificar el programa después de habérsele agregado nuevas funcionalidades.3.1.3.7 PROGRAMACIÓN DE PARESLa programación se asigna hacia dos personas. Según Gómez y Ania (2008), uno se concentra en buscar la mejor manera de implementar el método, mientras que el otro analiza el problema más globalmente.3.1.3.8 PROPIEDAD COLECTIVATodos los integrantes del equipo son propietarios del sistema, por ello todos tienen la posibilidad de modificar la codificación en indeterminado instante.3.1.3.9 INTEGRACIÓN CONTINUASegún Gómez y Ania (2008), se debe ir integrando y probando el código de manera continua. […] El código integrado devera pasar todas las pruebas definidas.3.1.3.10 CODIFICACIÓN ESTANDARSegún Gómez y Ania (2008), Se requiere establecer un estilo común de codificación. […] XP propone que el estándar sea lo más sencillo posible.En síntesis, la metodología XP (programación extrema) es actualmente una de las más populares por su fácil accesibilidad de uso. Sus propiedades se adecuan más hacia un modelo estándar. El factor humano que interviene en el desarrollo de esta metodología es una pieza clave para la evolución del proyecto.Considera conceptos básicos de un sistema dentro de sus prácticas. Pues la constante evolución de su sistema garantiza un mejoramiento seguro de él.

3.2 METODOLOGÍA RUP

3.2.1 INTRODUCCIÓN A LA METODOLOGÍA RUPConsideramos a la metodología RUP como una de las más importantes o grandes prácticas que hay en el mundo del software; esto debido a los ciclos iterativos, a su vez divididas en grandes fases o etapas, se pueden adaptar al contexto o cualquier necesidad de una empresa.Las características principales de esta metodología son, básicamente, la de ser un proceso cíclico, iterativo e incremental; además de estar dirigidos a los Casos de Uso y arquitectura del software requerido.

La metodología RUP, también consta de 4 grandes fases para lograr un óptimo desarrollo del software; entre las cuales se tiene a la fase de inicio, elaboración, construcción y transición.Una de las causas del porqué elegir la metodología RUP, se inicia cuando una institución o empresa piensa en grande; es ahí donde se toma como modelo de referencia a esta metodología. Teniendo como base la idea de que cada fase es una iteración larga, constante y dinámica. Esto explica el largo tiempo de vida del software una vez adaptado a esta metodología. Como gran consecuencia de un “rato” de espera se obtiene un óptimo resultado.

3.2.2 DEFINICIÓN DE METODOLOGÍA RUP

Según Fowler (2002), el Proceso Unificado Racional (Rational Unified Process en inglés, conocido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.Está basada en una integración de forma unificada, cohesiva y adaptable del desarrollo de sistemas de software. Por tal razón es que este sistema no está del todo definido; sino que, como ya se mencionó, se adaptan al contexto y necesidad de cada organización.

3.2.3 CARACTERÍSTICAS FUNDAMENTALESSe destaca que el proceso de software en esta metodología tiene 3 características fundamentales las cuales son: Casos de Uso, Arquitectura e Iteración e Incremento.

3.2.3.1 CASOS DE USOSegún Kruchten (2002), los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria [sic] bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.Los Casos de Uso, entonces, se refiere a las necesidades que el software requiere como parte para su posterior desarrollo. El encargado de verificar estos requisitos es el usuario quien se dispone a pensar qué es lo fundamental para que el software pueda tener todo lo indispensable.Todo lo que tiene ver con la implementación, prueba y guía del diseño del producto del software también es verificada por los Casos de Uso. No son sólo los que inician el proceso de desarrollo sino que proporcionan una secuencia organizada, estableciendo así el diseño entre las fases que son producidas en las distintas realizaciones del proceso de desarrollo del software.En síntesis, se puede decir que implantar los Casos de Uso en esta metodología RUP constituirá en el proceso, un elemento conciliador o integrador y una gran guía del trabajo para la elaboración del software.

3.2.3.2 ARQUITECTURA

La metodología RUP además de utilizar los Casos de Uso para guiar el proceso, también da especial

atención al temprano establecimiento de una buena arquitectura para que no se vea muy impactada ante posteriores cambios durante la construcción y el mantenimiento del software. El proceso busca entender los aspectos estáticos y dinámicos más resaltantes en términos de arquitectura de software. La arquitectura va a depender de las necesidades de los usuarios y se precisa a partir de los Casos de Uso.La arquitectura de un sistema es la organización o estructura de sus partes más importantes, permite tener una visión usual entre todos los desarrolladores y usuarios; y una perspectiva notable del sistema completo, necesaria para controlar el desarrollo. Debe tomar en cuenta elementos de calidad del sistema, reutilización, rendimiento y capacidad de evolución por lo que debe ser flexible durante todo el proceso.

Existe una interacción entre la arquitectura y los Casos de Uso, estos últimos deben ajustarse en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso necesarios, actuales y posteriores. En pocas palabras, tanto la arquitectura como los Casos de Uso deben evolucionar en paralelo durante todo el proceso de desarrollo de software.

3.2.3.3 ITERATIVO E INCREMENTALSegún Jacaboson, Booch y Rumbaugh (2000), la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración del cual se obtiene un incremento que produce un crecimiento en el producto.Esto quiere decirnos que, el proceso reconoce que es conveniente dividir grandes proyectos en otros más pequeños o mini-proyectos. Cada mini-proyecto alcanza una iteración que resulta en un incremento. Las iteraciones son planeadas en base a los Casos de Uso.Una iteración puede darse por medio de una cascada a menor escala. Se pasa por los flujos fundamentales: Requisitos, Análisis, Diseño, Implementación y Pruebas. También existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

CONCLUSIONES

1. En conclusión con el primer capítulo, es importante tener en cuenta el concepto claro de software y de sus objetivos como herramienta. 2. Los objetivos del software nos permitirán tener una visión clara respecto a su posterior funcionamiento para una determinada finalidad, por ello es importante tenerlos en cuenta.3. Para desarrollar un producto de software se requiere de todo un proceso. El cual esta

predefinido por una diversidad de modelos. Es elemental tener en cuenta los modelos que se adapten para un proyecto requerido, para obtener como producto de ello una funcionalidad óptima del producto.4. Existen diversos modelos dentro del proceso del software, así mismo, existen diversas metodologías y tipos de modelos para desarrollar un software. Producto de ello cada metodología tendrá un modelo de proceso para su desarrollo, el cual se adecua respecto con las necesidades de un proyecto.5. Las mejores prácticas para un desarrollo de software se encontraran ligadas hacia la finalidad del proyecto que requiera de dicho producto. 6. En síntesis, se puede derivar por lo anteriormente argumentado, que no existe un modelo estándar que se adecue ante la diversidad de finalidades que en la actualidad se exige.7. La metodología RUP, cuya característica principal es la de ser iterativa e incremental consta de varias fases; cada fase es una iteración comprendida. Todas las actividades realizadas en estas etapas tienen una complejidad enorme que al pasar del tiempo, el desarrollo del software tendrá un final óptimo.8. En conclusión, esta metodología se adapta mejor para proyectos grandes, ya que para cada iteración en la elaboración de software dependerá de la economía que esté a nuestro alcance. Es por ello que al final del producto se logran grandes resultados. De lo contrario, con ausencia de economía, el tiempo de vida del software no durará y terminará siendo un total fracaso.

REFERENCIAS BIBLIOGRÁFICAS

-BECK, Kent y ANDRES, Cynthia. Extreme Programming Explained: Embrace Change. 2a. ed. EE.UU: Paperback, 2004. 224 p.ISBN: 0321278658

-BOEHM, Barry y TURNER, Richard. Metodología RUP. En su: Balancing agility and discipline: a guide for the perplexed. Boston: Pearson Education, 2004. pp 179-180.ISBN: 0321186125

-BORRERO, Lucía. Tecnologías de la información en internet: guía de las mejores direcciones en la web. Colombia, norma: 2004. 19 p.ISBN: 9580471975

-CAMPDERRICH Falgueras, Benet. Ingeniería de software. Madrid: UOC, 2005. 260 p.ISBN: 8483189976

-CERRADA, José, COLLADO, Manuel, GÓMEZ, Sebastian y ESTÍVIARIS López, José Félix. Fundamentos de programación. Madrid: Centro de estudios Ramón Areces, 2004. 466p.ISBN: 8480045152

-CORTÉS Morales, Roberto. Introducción al análisis de sistemas y la ingeniería de software. 2006.

102 p.ISBN: 9977649618

-GÓMEZ, Andrés y ANIA Briseño, Ignacio de Jesús. Introducción a la computación. México: Cordinadores editoriales, 2008. 552 p.ISBN: 139789706867681

-MINGUET y Hernández, Juan Francisco. La calidad del software y su medida. Madrid: Centro de estudios Ramón Cáceres, 2004. 42 p.ISBN: 8480046112

-ROGER, Pressman. Ingeniería del software: un enfoque práctico 6a ed. Madrid: Concepción Fernández, 2004. 640 p.ISBN: 8448132149

-SOMERVILLE, Ian. Ingeniería del software 7a ed. Madrid: Rivera de Loira, 2005. 165 p.ISBN: 8478290745

-TUYA, Javier, RAMOS, Isabel y DOLADO Cosín Javier. Técnicas cuantitativas para la gestión en la ingeniería del software. Madrid: María Martínez, 2007. 367 p.ISBN: 9788497452045

-WEITZENFELD, Alfredo. Ingeniería de software orientada a objetos con UML, Java e Internet. 1ra ed. México, Publimex: 2005. 704 p.