Fundamentos de La Ingeniería Del Software
-
Upload
elizabeth-rndon -
Category
Documents
-
view
235 -
download
0
description
Transcript of Fundamentos de La Ingeniería Del Software
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.