FUNDAMENTOS DE LA INGENIERÍA DEL SOFTWARE

EL SOFTWARE

Es un ingrediente indispensable para el funcionamiento del computador. Está

formado por una serie de instrucciones y datos, que permiten aprovechar todos los recursos

que el computador tiene, de manera que pueda resolver gran cantidad de problemas. Un

computador en sí, es sólo un conglomerado de componentes electrónicos; el software le da

vida al computador, haciendo que sus componentes funcionen de forma ordenada.

El software es un conjunto de instrucciones detalladas que controlan la operación de un

sistema computacional.

 Funciones del software

Administrar los recursos de computacionales

Proporcionar las herramientas para optimizar estos recursos.

Actuar como intermediario entre el usuario y la información almacenada.

Programas de Software

Programa: Conjunto de argumentos o instrucciones para la computadora, almacenado en

la memoria primaria de la computadora junto con los datos requeridos para ser ejecutado,

en otras palabras hacer que las instrucciones sean realizadas por la computadora.

Tipos de Software

Software del sistema: Es un conjunto de programas que administran los recursos de la

computadora. Ejemplos: Unidad central de proceso, dispositivos de comunicaciones y

dispositivos periféricos, el software del sistema administra y controla al acceso del

hardware.

 

Software de aplicaciones: Programas que son escritos para o por los usuarios para realizar

una tarea específica en la computadora. Ejemplo: software para procesar un texto, para

generar una hoja de cálculo, el software de aplicación debe estar sobre el software del

sistema para poder operar.

 Software de usuario final: Es el software que permiten el desarrollo de algunas

aplicaciones directamente por los usuarios finales, el software del usuario final con

frecuencia tiene que trabajar a través del software de aplicación y finalmente a través del

software del sistema

CUALIDADES DEL SOFTWARE

Correcto: Un programa es funcionalmente correcto si se comporta de acuerdo a la

especificación de las funciones (especificación de requerimientos funcionales) que debería

proveer.

Confiabilidad: Informalmente el software es confiable si el usuario puede tenerle

confianza. Formalmente la confiabilidad se define en términos del comportamiento

estadístico: la probabilidad de que el software opere como es esperado en un intervalo de

tiempo especificado.

Robustez (Robustness): Un programa es robusto si se comporta en forma razonable aún en

circunstancias que no fueron anticipadas en la especificación de requerimientos; por

ejemplo cuando encuentra datos de entrada incorrectos o algún malfuncionamiento del

hardware como rotura de disco.

Performance (también Eficciency): En la Ingeniería de Software generalmente

performance equivale a eficiencia. Un sistema de software es eficiente si utiliza los recursos

computacionales en forma económica.

Amigabilidad (Friendliness): Un sistema de software es amigable si un usuario humano lo

encuentra fácil de utilizar. Esta definición refleja la naturaleza subjetiva de la amigabilidad.

Verificabilidad (Verifiability): Un sistema de software es verificable si sus propiedades

pueden ser verificadas fácilmente. Por ejemplo, la correctitud o la performance de un

sistema son propiedades que interesa verificar.

Mantenibilidad (Maintainability): El término mantenimiento del software es utilizado

generalmente para referirse a las modificaciones que se realizan a un sistema de software

luego de su liberación inicial, siendo visto simplemente como “corrección de bugs”.

Reparabilidad (Reparability): Un sistema de software es reparable si permite la

corrección de sus defectos con una carga limitada de trabajo.

Evolucionabilidad (Evolvability): Un sistema es evolucionable si acepta cambios que le

permitan satisfacer nuevos requerimientos. En otros productos de ingeniería las

modificaciones van precedidas de actividades como estudios de factibilidad, diseño

asociado, aprobaciones, evaluaciones y finalmente la introducción de la modificación.

Reusabilidad (Reusability): La reusabilidad es similar a la evolucionabilidad: en la

segunda se modifica un producto para construir una nueva versión del mismo producto, en

la primera se utiliza un producto, posiblemente con modificaciones menores, para construir

otro producto.

Portabilidad (Portability): El software es portable si puede ser ejecutado en distintos

ambientes, refiriéndose este último tanto a plataformas de hardware como a ambientes de

software como puede ser determinado sistema operativo.

Comprensibilidad (Understandability): Algunos sistemas de software son más fáciles de

comprender que otros, algunas tareas son inherentemente más complejas que otras.

Interoperabilidad (Interoperability): La interoperabilidad se refiere a la habilidad de un

sistema de coexistir y cooperar con otros sistemas, por ejemplo, la habilidad de un

procesador de texto de incluir gráficas producidas por un paquete de gráficos.

Productividad (Productivity): La productividad es una cualidad del proceso de

producción de software, mide la eficiencia del proceso y como se vio antes, es la cualidad

de performance aplicada al proceso.

Oportunidad (Timeliness): La oportunidad es una cualidad del proceso que se refiere a la

habilidad de entregar un producto a tiempo.

Visibilidad (Visibility): Un proceso de desarrollo de software es visible si todos sus pasos

y su estado actual son claramente documentados. Otros términos utilizados son

transparencia y apertura.

FACTORES DE CALIDAD DEL SOFTWARE

El desarrollo de software se ha vuelto uno de los principales ejes de conocimiento y

crecimiento profesional y empresarial en los últimos años, debido a la globalización y

aplanamiento del mundo en que vivimos. Todo se está haciendo en torno al software

e Internet. Y es por estos motivos y miles más, que el desarrollo de estos grandes sistemas,

debe ser casi perfecto, y se deben seguir ciertos factores de calidad que así lo aseguran. A

continuación algunos de los más importantes como lo son la reusabilidad, legibilidad

y seguridad.

Reusabilidad: La necesidad de la reutilización surge de la observación de que los sistemas

software a menudo siguen patrones similares; debería ser posible explotar esta similitud y

evitar reinventar soluciones a problemas que ya han sido encontradas con anterioridad.

Capturando tal patrón, un elemento de software reutilizable se podrá aplicar en muchos

desarrollos diferentes.

Reusabilidad-Tipo de factor: La reusabilidad es un factor de tipo externo, ya que es

perceptible por los usuarios o clientes, por ejemplo al momento de utilizar partes de un

software en otro diferente. También en el caso de los usuarios que son programadores,

utilizar partes de códigos creadas en otros desarrollos para su propio trabajo (librerías).

Reusabilidad-Métrica: La reusabilidad está dentro del contexto de las métricas de calidad.

Las métricas de calidad son todas las métricas de software que definen de una u otra forma

la calidad del software; tales como exactitud, estructuración o modularidad, pruebas,

mantenimiento, reusabilidad, entre otras. Estas son los puntos críticos en el diseño,

codificación, pruebas y mantenimiento.

Legibilidad: La legibilidad dentro del contexto del desarrollo del software se refiere al

modo en que se estructura la información con la que se trabaja, es decir, todo debe estar

claramente documentado, espaciado, sin errores, y con una facilidad de uso ágil y de rápido

entendimiento. Así se logra una mayor comprensión del proyecto, y las modificaciones

pertinentes son más fáciles de realizar.

Legibilidad-Tipo de factor: La legibilidad es un factor de tipo interno, ya que solo es

perceptible por los desarrolladores o los profesionales de la computación. Al cliente no le

importa que el sistema por debajo esté legible, solo le importa que funcione óptimamente.

Legibilidad-Métrica: La Legibilidad está dentro del contexto de las métricas de Calidad.

Seguridad

Hay dos tipos

La seguridad es un factor de calidad de uso, definido por la ISO 9126 y se refiere a la

forma en que los atributos miden la habilidad para prevenir accesos no autorizados, ya sea

accidentales o deliberados, tanto a programas como a datos.

Es una actividad de calidad del software que se centra en la identificación de riesgos

que pueden producir un impacto negativo en el software, se dirige un proceso de análisis, se

identifican los riesgos y se clasifican por su importancia y grado de riesgo. Cuando se han

identificado los riesgos, se especifican los requisitos del software relacionados con la

seguridad.

Seguridad-Tipo de factor: Según las dos definiciones anteriores, se puede concluir que es

un factor de tipo tanto externo como interno, ya que los desarrolladores deben tener en

cuenta la seguridad del software al momento de desarrollarlo, pero es a los clientes a los

que a la hora de la verdad, exigen un sistema final totalmente confiable y seguro.

Seguridad-Métrica: La seguridad está dentro del contexto de las métricas de calidad.

INGENIERÍA DEL SOFTWARE

La ingeniería de software es una disciplina formada por un conjunto de métodos,

herramientas y técnicas que se utilizan en el desarrollo de los programas

informáticos (software). Esta disciplina trasciende la actividad de programación, que es el

pilar fundamental a la hora de crear una aplicación. El ingeniero de software se encarga de

toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y

con el presupuesto previsto.

La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el

diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su

correcto funcionamiento y la implementación del sistema. Cabe destacar que el proceso de

desarrollo de software implica lo que se conoce como ciclo de vida del software, que está

formado por cuatro etapas: concepción, elaboración, construcción y transición.

La concepción fija el alcance del proyecto y desarrolla el modelo de negocio; la

elaboración define el plan del proyecto, detalla las características y fundamenta la

arquitectura; la construcción es el desarrollo del producto; y la transición es la transferencia

del producto terminado a los usuarios.

VISIÓN GENERAL DEL PROCESO DE DESARROLLO DE SOFTWARE

Este 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. Son 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. Se sabe que cuanto mayor sea la ayuda de los usuarios en un proyecto de

desarrollo de software, mayores serán las probabilidades de éxito que tenga el mismo. No

obstante es importante hacer algunas matizaciones:

1) El proyecto no se hace sólo, porque incluso existiendo una gran ayuda por parte de los

usuarios, si no se consigue interpretar con precisión lo que quieren y no se dinamiza un

feedback continuo de los mismos durante todo el proceso de desarrollo, se incrementarán

las posibilidades de que algún requisito funcional no se haya recogido adecuadamente o de

que se haya realizado un software con una usabilidad incómoda para los usuarios. Estas

circunstancias son fuente de innumerables problemas en las fases finales del proyecto y

provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, además de

crear conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo.

2) Es importante que entre el grupo usuarios asignados al proyecto haya usuarios que vayan

a estar implicados en el futuro uso del sistema de información, es decir, no es suficiente que

el equipo de usuarios esté formado por ideólogos o teóricos que se nutrirán del resultado

del trabajo de la herramienta, sino que es fundamental que participen usuarios que después

se tengan que poner el mono de trabajo y vayan a trabajar con el software.

3) Los analistas están para ayudar y para colaborar con los usuarios en la especificación y

diseño de la solución, pero no están para dar lecciones a los usuarios y enseñarle cómo

deben hacer su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque

no sea la más ortodoxa, siempre tendrá una justificación que sólo se entendería si realmente

estuvieran haciendo su trabajo durante un tiempo y se vieran los problemas con los que se

enfrentan cotidianamente.

4) Es fundamental documentar el proyecto, en primer lugar con la documentación que se

especifique en las normativas de desarrollo de la organización para la que se realiza el

servicio, con las matizaciones que indique el Director del Proyecto, en segundo lugar con la

documentación que establezcan las normativas internas de calidad de la organización (no

requerirá un sobreesfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo

anterior sumarle toda la documentación de trabajo que sea necesaria para trabajar con los

usuarios, que no tienen por qué entender de modelos de datos, de diagramas de casos de

uso.

PARTICIPANTES EN EL PROCESO DE DESARROLLO DE SOFTWARE

Puesto que la participación de usuarios en el diseño de sistemas de información es un

aspecto relevante, resulta necesario aclarar lo que significa la participación y lo que ella

implica. Una cosa es segura: la participación no es un concepto nuevo en el extenso plano

de las ciencias de la información.

En el entendido de que toda unidad de información trabaja en función del beneficio

social; el participante más importante de ella es, por lo tanto, el usuario. De esta manera, se

puede definir a la participación como un proceso en el cual dos o más partes involucradas

influyen sus decisiones, planes y políticas en torno a los sistemas, servicios y recursos que

ofrece una determinada unidad. Sin embargo, se debe reconocer que es poco el debate que

se hace acerca de las decisiones tomadas, es decir, de los distintos intereses que influyen en

ellas. Si se desea tener un acercamiento más amplio en el diseño de sistemas es necesario

considerar las funciones, la estructura, los intereses y los problemas mismos que influyen

en los participantes implicados. Dentro de todo sistema, existen varios tipos de

participantes que necesariamente intervienen en los sistemas que ellos mismos

implementan para agilizar la recuperación de sus recursos.

Así mismo, también existen tres tipos de participante: participantes unitarios, pluralistas y

coercitivos. La relación de tipo unitaria implica que sus participantes poseen valores,

creencias e intereses idénticos; ellos comparten el mismo propósito. En las relaciones

pluralistas, sus participantes comparten los mismos intereses, no así sus valores o creencias,

lo que debe promover un espacio de intercambio de ideas, acuerdos e incluso conflictos. En

total contraste, en las relaciones coercitivas existen pocos o nulos intereses en común, la

libertad de expresión es muy baja y los valores y creencias de cada individuo resultan ser

muy conflictivas. Las decisiones son tomadas mediante enfoques absolutistas de gente con

poder.

CICLO DEL VIDA DEL SOFTWARE

Es la forma mediante la cual se describen los diferentes pasos que se deben seguir

para el desarrollo de un software, partiendo desde una necesidad hasta llegar a la puesta en

marcha de una solución y su apropiado mantenimiento. El ciclo de vida para un software

comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el

programa que se desarrolló para cumplir con los requerimientos, deja de ser utilizado.

Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo

de vida clásico o en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo

por incrementos y el modelo extremo.

Etapas del ciclo de vida del software

El ciclo de vida clásico del software siendo uno de los más utilizados tal como lo

plantean diferentes autores, está conformado en su versión ampliada por siete etapas que se

pueden representar mediante un modelo en cascada así:

Ingeniería de sistemas: En esta etapa el analista luego de un minucioso y detallado estudio

de los sistemas de una organización, detecta un problema o una necesidad que para su

solución y/o satisfacción es necesario realizar un desarrollo de software.

Análisis: En esta etapa se debe entender y comprender de forma detallada cual es la

problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de

tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva

solución. Esta etapa es conocida como la del QUÉ se va a solucionar.

Diseño: Una vez que se tiene la suficiente información del problema a solucionar, es

importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa

es conocida bajo el CÓMO se va a solucionar.

Implementación: partiendo del análisis y diseño de la solución, en esta etapa se procede a

desarrollar el correspondiente programa que solucione el problema mediante el uso de una

herramienta computacional determinada.

Pruebas: Los errores humanos dentro de la programación de los computadores son muchos

y aumentan considerablemente con la complejidad del problema. Cuando se termina de

escribir un programa de computador, es necesario realizar las debidas pruebas que

garanticen el correcto funcionamiento de dicho programa bajo el mayor número de

situaciones posibles a las que se pueda enfrentar.

Documentación: Es la guía o comunicación escrita en sus diferentes formas, ya sea en

enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un

programa. La importancia de la documentación radica en que a menudo un programa

escrito por una persona, es modificado por otra. Por ello la documentación sirve para

ayudar a comprender o usar un programa o para facilitar futuras modificaciones

(mantenimiento). La documentación se compone de tres partes:

Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente

para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo las

precondiciones y las poscondiciones de cada función.

Documentación Externa: Se define en un documento escrito con los siguientes puntos:

Descripción del Problema

Datos del Autor

Algoritmo (diagrama de flujo o Pseudocódigo)

Diccionario de Datos

Código Fuente (programa)

Manual de Usuario: Describe paso a paso la manera cómo funciona el programa, con el

fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.

Mantenimiento: Una vez instalado un programa y puesto en marcha para realizar la

solución del problema previamente planteado o satisfacer una determinada necesidad, es

importante mantener una estructura de actualización, verificación y validación que

permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o

requerimientos planteados durante su vida útil. Para realizar un adecuado mantenimiento,

es necesario contar con una buena documentación del mismo. Para terminar de entender la

problemática en la cual se desarrolla este libro es importante tener unos conceptos claros y

precisos de lo que es el Análisis y el Diseño de Algoritmos.

FUNDAMENTACIÓN TEÓRICA DEL PARADIGMA DE PROGRAMACIÓN

Los paradigmas de programación son la forma, que determinan los métodos y las

herramientas que un programador usara en la construcción de un software. Mayormente los

lenguajes de programación están basados en uno o más paradigmas, a estos se les puede

llamar multiparadigmas. También menciona los diferentes tipos de paradigmas que se

conocen, pero solamente se hace referencia a los más importante ya que suelen haber

muchos más que no se mencionaran en esta investigación.

Un lenguaje de programación puede soportar distintos paradigmas de programación

con el objetivo de que un programador utilice el más conveniente a la hora de resolver un

problema. Ningún paradigma es capaz de resolver todos los problemas de forma sencilla y

eficiente, por lo tanto, es útil poder elegir entre distintos estilos de programación

dependiendo del tipo de problema. También hay lenguajes que permiten mezclar los

paradigmas que, en principio, parecerían irreconciliables.

Se debe aclarar que hay subparadigmas que se incluyen en paradigmas más generales,

pero hay otros que utilizan métodos de programación totalmente distintos entre sí e

igualmente hay lenguajes que los combinan. Por ejemplo, el lenguaje Oz emplea

programación lógica, funcional, orientada a objeto y otras. Lenguajes como Delphi, C++ y

Visual Basic combinan el paradigma imperativo, el procedural y el orientado a objetos.

Incluso lenguajes más puros en sus paradigmas como Prolog (paradigma lógico) o Scheme

(paradigma funcional) poseen estructuras iterativas típicas de los lenguajes de paradigma

imperativo.

METODOLOGÍA O PROCESOS DE DESARROLLO DE SOFTWARE

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la

diversidad de propuestas y diferencias en el grado de detalle, información disponible y

alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones

utilizadas para especificar artefactos producidos 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 (o también

denominadas Metodologías Pesadas, o Peso Pesado). 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, hacen especial hincapié en

aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el

proceso.

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 Java 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), la

notación Orientada a Objetos más popular en la actualidad.

Algunas metodologías orientadas a objetos que utilizan la notación UML son:

Rational Unified Process (RUP), OPEN, MÉTRICA (que también soporta la notación

estructurada).

Metodologías Tradicionales

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). Entre las metodologías ágiles

identificadas son:

Extreme Programming, Scrum, Familia de Metodologías Crystal, Feature Driven

Development, Proceso Unificado Rational, una configuración ágil, Dynamic Systems

Development Method, Adaptive Software Development, Open Source Software

Development.

MODELADO DE SISTEMAS

Una técnica ampliamente usada es documentar la especificación del sistema como un

conjunto de modelos del sistema. Estos modelos son representaciones gráficas que

describen los procesos del negocio, el problema a resolver y el sistema que tiene que ser

desarrollado. Debido a las representaciones gráficas usadas, los modelos son a menudo más

comprensibles que las descripciones detalladas en lenguaje natural de los requerimientos

del sistema. Ellos constituyen también un puente importante entre el proceso de análisis y

diseño. Pueden usarse modelos en el proceso de análisis para comprender el sistema

existente que debe ser reemplazado o mejorado, o para especificar el nuevo sistema que sea

requerido. Pueden desarrollarse diferentes modelos para representar el sistema desde

diferentes perspectivas. Por ejemplo:

El aspecto más importante de un modelo del sistema es que omite los detalles.

Un modelo del sistema es una abstracción del sistema que se está estudiando en lugar

de una representación alternativa de ese sistema.

Idealmente, una representación de un sistema debería mantener toda la información

sobre la entidad que se está representando.

Una abstracción simplifica y resalta de forma deliberada las características más

relevantes. Por ejemplo, en el caso improbable de que este libro fuese publicado por

capítulos en un periódico, la presentación en este caso sería una abstracción de los puntos

clave del libro. Si fuese traducido del inglés al italiano, ésta podría ser una representación

alternativa. La intención del traductor debería ser mantener toda la información tal y como

se presenta en inglés.

Diferentes tipos de modelos del sistema se basan en distintas aproximaciones de

abstracción. Un modelo de flujo de datos se centra en el flujo de datos y las

transformaciones funcionales sobre esos datos. Se omiten los detalles de las estructuras de

datos. Por el contrario, un modelo de entidades de datos y sus relaciones documentan las

estructuras de datos del sistema en lugar de su funcionalidad.

TÉCNICAS Y HERRAMIENTAS EN EL PROCESO DE DESARROLLO DE

SOFTWARE

Las herramientas de desarrollo de software (HDS) han desempeñado un importante

papel en el desarrollo de aplicaciones. Como consecuencia del avance tecnológico éstas han

experimentado también continuos cambios. Así como se cuenta en la actualidad con

documentación sobre las numerosas HDS disponibles, y con trabajos de investigación que

revelan avances en herramientas particulares.

El Proceso / Técnicas. Permite un desarrollo racional de la IS  y comprende actividades

técnicas y de gestión propias asociadas al ciclo de vida del software. Está  determinado por

un modelo, una representación formal de un sistema. En la IS, un modelo se comporta

también como una estrategia de desarrollo.

El Método. Un método es una guía general para ayudar al desempeño de una actividad. En

la IS, los métodos indican cómo construir el software. Los métodos tienen  dimensiones de

eficiencia y de efectividad, sentido del proceso y del producto,  cualidades que se atribuyen

directamente a la calidad del software.

Las Herramientas. Todo método tiene uno o varios instrumentos y técnicas asociados  a

él, con un grado de adecuación que depende generalmente del contexto de aplicación.

Herramientas de Desarrollo de Software

Actualmente se considera a las HDS como herramientas basadas en computadoras

que  asisten el proceso de ciclo de vida de software, consolidadas en la literatura en la

forma de Ingeniería de software asistida por computadora (CASE, por sus siglas en  inglés).

Esto es, software que se utiliza para ayudar a las actividades del proceso de  software o

software que es utilizado para diseñar y para implementar otro software. 

Permiten automatizar acciones bien definidas, reduciendo también la carga cognitiva

del ingeniero de software, quien requiere libertad para concentrarse en los aspectos

creativos del proceso. Este soporte se traduce en mejoras a la calidad  y la productividad  en

el diseño y desarrollo. Las HDS automatizan metodologías de software y desarrollo de

sistemas y se vinculan con los diferentes conceptos involucrados en el  desarrollo.

Las Herramientas como Área de Conocimiento de la IS

Las disciplinas conforman una visión de contexto de la IS. Hacia lo interno, existen

un conjunto de  áreas de conocimiento que facilitan la comprensión del alcance y las

limitaciones de diferentes temas en la IS.  Estas áreas son: Requerimientos, Diseño,

Construcción, Pruebas y Mantenimiento de software, Gestión de la configuración, Gestión

de la ingeniería y del proceso de la ingeniería de software, Herramientas y métodos de

software, y Calidad de software. De este modo, las herramientas de software y los métodos,

integran un área específica de la IS, y contribuyen a la producción de software  de alta

calidad, con bajo costo y en el menor tiempo posible.