Embed Size (px)
DESCRIPTION
Este es un fragmento de nuestra tesis de grado como ingeniero en sistemas y es el resultado de nuestra primera investigación del desarrollo de software en el Ecuador desde el 2001
Citation preview
1. INTRODUCCIÓN
“El propósito de toda investigación científica realizada, es el de generar nuevos
conocimientos sobre la realidad en la cual se ha detectado un problema. Es por tanto
necesario que el investigador conozca y maneje adecuadamente el proceso por el cual
se llega a ese conocimiento” [Vej 04, p. 12]
La Universidad Tecnológica Israel (UTECI) requiere sistematizar la escritura
académica de sus documentos y publicaciones técnicas o científicas.
Para el caso de la Facultad de Sistemas, se propone una extensión a las
normas vigentes en el Reglamento del Régimen Académico, en forma
particular, al desarrollar software como tema de tesis.
Como señala Gilberto Vejarano1 -Director del Departamento de Tesis-, la
investigación es ante todo una forma de pensar. Es un proceso que incluye un
conjunto de elementos teóricos, lógicos, estadísticos y técnicos que permiten al
investigador una aproximación al conocimiento verdadero, válido y contrastable
de la realidad.
La investigación científica aplicada al desarrollo de un producto software, se la
conoce como Ingeniería de Software2 (IS) y a su método de desarrollo, bajo la
influencia de la Escuela Pragmática Norteamericana del Software3, como la
“metodología de desarrollo de software” (MDS).
1 Reflexiones sobre la formación del pensamiento científico, investigación y docencia [Vej 04, p. 2]
2 La Sociedad de Computación del IEEE, define a la IS como la “aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y
mantenimiento del software, esto es la aplicación de la ingeniería al software” [*IEEE 90, p. 23]
3 “Se ha convertido en costumbre en parte de la literatura [del software] hablar sobre „metodologías‟ específicas, cuando realmente se quiere decir métodos (de
hecho, incluso menos: variantes de un único método general, el método orientado a objetos)” [Mey 99, p. 630]
“El método práctico (cuyo máximo cultor es EEUU), es 'sucio' e incompleto desde lo formal” [*Pérez]
Desde esta perspectiva, estos métodos permiten considerar a la investigación
realizada a lo largo del desarrollo de software, como una aplicación de
conocimientos que facilitan la generación de espacios propicios para
desarrollar la mente científica, la discusión, el cuestionamiento, el debate y, la
exploración del propio conocimiento.
La elaboración de productos software por parte de la Facultad de Sistemas,
representa un aporte al desarrollo tecnológico de la UTECI y por ende un
acercamiento del país a la tecnología.
En un mundo globalizado por las Tecnologías de Información y Comunicación
(TIC), es urgente la presencia universitaria como respuesta a la necesidad de
generación de tecnología propia para el desarrollo sostenible del Ecuador
(Informe sobre el Desarrollo Humano, Ecuador 2001) [PNUD 01, p. ix], según este
informe, es posible dar literalmente un “salto” en el proceso productivo de
tecnología nacional y así evitar comenzar desde el principio nuevamente.
Este fenómeno se conoce como “Transferencia de conocimientos”.
La ciencia tiene por objetivo generar un nuevo conocimiento, mientras que la
tecnología (en especial la relacionada al desarrollo del software), precisa
concebir un nuevo producto como mercancía.
El carácter de mercancía de la tecnología radica en el hecho de que es un
insumo necesario para producir y comercializar bienes, por lo que se
transforma en objeto de comercio y adquiere precio.
El esfuerzo tecnológico se justifica sólo si existe la posibilidad de que éste
procure satisfacer una necesidad explícita o potencial de determinado usuario.
De modo que el conocimiento tecnológico, solo alcanza utilidad al ser
incorporado al sector productivo, originando un cambio técnico. Este cambio
técnico puede tener alguna de las siguientes formas:
(1) Desarrollo de nuevos procesos productivos.
(2) Mejora de los procesos y productos existentes.
(3) Innovación de sistemas de organización, administración o gestión.
Un cambio tecnológico consiste en un avance en el conocimiento sobre la
forma de producir un determinado bien o servicio, o en una nueva generación
de cualquiera de los dos.
Sin duda, el conocimiento científico es cada vez más el principal insumo de las
tecnologías, pero no es el único. Numerosas tecnologías productivas siguen
basadas en conocimientos empíricos, entre las cuales se incluye el desarrollo
de software, debido a su componente de creatividad.
1.1. Antecedentes
Para entender la problemática detrás de la concepción y desarrollo de un
proyecto de software, se estudió en forma externa al primer proyecto colectivo
de desarrollo de software propuesto por la Facultad de Sistemas: el “Sistema de
Tesis Dirigidas” (SITEDI).
Esta iniciativa se espera sea impulsada tanto por estudiantes como por
autoridades de la UTECI, pues representa una magnífica oportunidad para
conseguir la “experiencia” solicitada a los nuevos profesionales del mercado,
en el desarrollo de proyectos de software.
Sin embargo, debido a que el diseño del software obedece a la creatividad del
programador, no puede considerarse a este proyecto (SITEDI) como una
muestra general aplicable a todas las tesis de grado cuya finalidad sea el
desarrollo de software.
La documentación entregada por los estudiantes que desarrollan software y las
normas establecidas en el reglamento vigente del Régimen Académico para la
elaboración de tesis de grado, deberán conjugarse en forma efectiva a lo largo
del avance del proyecto.
1.1.1. Problemática
En la UTECI no se cuenta con un manual para las tesis de grado, en el cual se
indiquen los lineamientos necesarios para documentar en forma técnica el
desarrollo de software, lo que implica la necesidad de crear un estándar para
su sistematización y preservación.
La documentación del software es realizada en algunos modelos de desarrollo
al final del proyecto, lo que denota la necesidad de utilizar un método apropiado
para dicha documentación.
Este razonamiento implica en forma evidente la aplicación de una MDS,
empero, no se encontraron documentos que mencionen, en forma
coherentemente técnica, información al respecto en la documentación
analizada como muestra extraída del proyecto SITEDI.
El factor técnico que se necesita para documentar el desarrollo de un producto
software, se conoce como el Lenguaje Unificado de Modelado, conocido como
UML (Unified Modeling Language).
Sin embargo, tampoco se presentaron evidencias del uso de UML en la
documentación técnica analizada.
1.2. Objetivos
1.2.1. General
Definir una guía para la documentación técnica de tesis de grado,
específicamente para los estudiantes de la Facultad de Sistemas que desean
desarrollar software como tema de tesis, en base a las experiencias obtenidas
del SITEDI.
1.2.2. Específicos
Establecer el paralelismo entre el método de investigación científica y
el modelo del ciclo de vida del desarrollo del software (CVDS), como
premisa importante para determinar el criterio aplicado a la
investigación tecnológica que se necesita a lo largo del desarrollo de
un proyecto de software.
Definir el tipo de documentación y artefactos que deben ser
entregados al Departamento de Tesis de Grado, cuando el tema de
tesis se relacione al desarrollo de un producto software.
1.3. Justificación
Este trabajo responde a la necesidad de sistematizar y preservar los
documentos presentados como tesis de grado bajo las recomendaciones de la
Facultad de Sistemas y el Departamento de Tesis de Grado.
Representa un primer aporte a la comunidad universitaria, para estandarizar el
tratamiento a la información técnica que se emplea al desarrollar software
como tema de tesis de grado.
Dicho tratamiento deberá expresar los criterios aplicados por el estudiante a lo
largo del proceso de desarrollo de su tesis, manifestando sus cualidades y
conocimientos como futuro profesional.
2. MARCO DE REFERENCIA
2.1. Del Reglamento de Régimen Académico en la UTECI.
Anexo a este trabajo puede referenciarse parte de dicho reglamento, del cual
se extrae a consideración el siguiente artículo.
Art. 86.- El diseño de las tesis, con la concepción de proyecto final de grado, se
realizará, en cada carrera, atendiendo a sus requerimientos y particularidades. Se
dictarán normativas específicas para definir el formato de presentación de los diseños
de las tesis; así como del informe final de las mismas.4
Partiendo de este artículo, es posible definir una documentación coherente del
desarrollo de un proyecto software, bajo las indicaciones del Departamento de
Tesis de Grado y de la Facultad de Sistemas.
2.2. Del SITEDI proyecto comunitario para el desarrollo de software.
Este proyecto de la Facultad de Sistemas, cuya duración fue de 10 meses
(Agosto/2003-Mayo/2004) presenta los siguientes aspectos:
4 Artículo citado por el Director del Dpto. de Tesis de Grado en [Vej 04, pp. 1]
(1) La documentación generada a lo largo del proyecto, obedece
necesariamente a la presencia de una MDS, la cual genera sus
propios documentos técnicos y artefactos5 en cada una de las etapas
del proceso “productivo”.
(2) Por lo tanto, el orden en que estos documentos y artefactos son
producidos y obtenidos no será necesariamente el orden que se
sugiere en el método científico de investigación.
La razón:
Cada proyecto de software, es diferente de otros de acuerdo a su diseño. En base a los
objetivos que se desea alcanzar, el proceso creativo del diseño requerirá de crear sus
propias herramientas, para expresar las distintas acciones que guían a la consecución
de dichos objetivos.
Para cada tipo de proyecto, existe un método de desarrollo de software
apropiado y aceptado por el mercado.
Sin embargo, el estudiante se enfrenta por experiencia al hecho real de que la
documentación de los desarrollos se realiza al final del proyecto, siendo esta
una de las dificultades al documentar su tesis de grado.
2.3. Experiencias en otras universidades.
Existe en la actualidad una fuerte tendencia por acoplar, estrategias de
desarrollo de software más ligeras al proceso “productivo” con técnicas
administrativas para el manejo de proyectos.
5 “Artefacto: Pieza de información tangible que (1) es creada, modificada y usada por los trabajadores al realizar actividades; (2) representa un área de
responsabilidad, y (3) es candidata a ser tenida en cuenta para el control de la configuración. Un artefacto puede ser un modelo, un elemento de un modelo, o
un documento” [RUP 00, pp. 426]
Esta tendencia manifiesta la necesidad de emplear las denominadas
“metodologías ágiles de desarrollo” como una alternativa basada en las mejores
prácticas de sus mentalizadores y la experiencia obtenida en proyectos
importantes de desarrollo de software a nivel mundial.
La Universidad Santa María de la ciudad de Guayaquil, ha emprendido el
proyecto SPICE-XP6 que representa la experiencia de trabajar con dos áreas de
conocimiento encargadas de:
(1) El control de calidad y administración de proyectos (SPICE7) y
(2) Una estrategia de desarrollo de software considerada como ágil (XP8 o
programación extrema).
En México, la Universidad Autónoma de México (UNAM), sugiere a sus
alumnos la necesidad de emplear una metodología de desarrollo reconocida en el
mercado, como Rational Unified Process (RUP) o el Método Unificado del
Desarrollo de Software y la utilización del Lenguaje Unificado de Modelado
(UML). Estos métodos permiten definir un estándar en la documentación
técnica interna de los proyectos de desarrollo de software, aplicable a las tesis
de grado.
En España, se ha establecido una red interdisciplinaria entre grupos de estudio
de la Ingeniería de Software (IS) y de la metodología de la ciencia, cuya
iniciativa pretende establecer los métodos de investigación aplicados en la IS
(MIIS).
6 Sitio Web: http://www.usm.edu.ec/spice-xp/
7 Sitio Web: http://www-sqi.cit.gu.edu.au/spice/
8 Sitio Web: http://www.extremeprogramming.org
Kybele9, es el grupo que lidera esta investigación por parte la Universidad Rey
Juan Carlos de España junto a otras universidades como la Universidad de
Castilla –La Mancha, la Universidad Politécnica de Madrid, la Universidad de
Valladolid y la Universidad Internacional de Cataluña (UNICA), estableciendo
un estudio profundo sobre dicha temática.
Es en base a este último trabajo, la propuesta sugerida para la Facultad de
Sistemas de la UTECI y la necesidad de crear su propio formato de
documentación, en concordancia con las normas internas establecidas por el
Departamento de Tesis de Grado y la Facultad de Sistemas.
2.4. Guía para las bases de conocimiento en la IS.
El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) es mundialmente
reconocido como la organización que determina (entre otros aspectos) las
normas internacionales, al igual que las recomendaciones que soportan la
disciplina relacionada con el desarrollo de software.
La Guía para las bases de conocimientos de la IS -SWEBOK (2001)- es el resultado
de una investigación realizada por la Computer Society del IEEE, que junto a
otras organizaciones internacionalmente reconocidas por sus investigaciones,
dividen en diez áreas de conocimiento a esta disciplina naciente de la IS.
(Véase ilustración 1).
El contenido de esta guía es marcadamente diferente de la denominada
“Ciencia de la Computación” (Computer Science) como una ingeniería eléctrica
que está basada en la ciencia de la física.
9 Sitio Web: http://kybele.escet.urjc.es/MIIS/
La Ingeniería de Software se basa en dicha ciencia, sin embargo, su enfoque
es diferente debido a que para los científicos, el objetivo de una investigación
científica es extender su conocimiento sobre las leyes de la naturaleza,
mientras que para los ingenieros de software, el objetivo es aplicar dichas leyes
de la naturaleza para construir nuevos artefactos bajo un número de
restricciones y condicionantes.
Esta guía necesariamente es considerada como “incompleta” en vista a la
necesidad del apoyo de otras tecnologías y disciplinas que se utilizan en
conjunto para un desarrollo de conocimientos requeridos en la IS.
Ilustración 1 Áreas de conocimiento en la IS [*SWEBOK]
Guía Base de Conocimientos de la Ingeniería de Software (SWEBOK Versión 0.95)
Calidad del Software
Métodos y Herramientas para
la Ingeniería de Software
Procesos de la Ingeniería de
Software
Administración de la Ingeniería
de Software
Administración de
Configuración del Software
Mantenimiento del Software
Pruebas del Software
Construcción del Software
Diseño del Software
Requerimientos del Software
Procesos de la Ingeniería de
Requerimientos
Validación de Requerimientos
Especificación de
Requerimientos
Análisis de Requerimientos
Licitación de Requerimientos
Administración de
Requerimientos
Conceptos básicos del Diseño del Software
Notaciones del Diseño del Software
Análisis de Calidad el Diseño
del Software y Evaluación
Arquitectura y estructura del
Software
Criterios principales en el
Diseño del Software
Métodos y estrategias para el
Diseño del Software
Reducción en Complejidad
Métodos de Construcción Lingüística
Métodos de Construcción
Formal
Métodos de Construcción
Visual
Anticipación a la Diversidad
Métodos de Construcción Lingüística
Métodos de Construcción
Formal
Métodos de Construcción
Visual
Estructuración para Validación
Métodos de Construcción Lingüística
Métodos de Construcción
Formal
Métodos de Construcción
Visual
Uso de Estándares Externos
Métodos de Construcción Lingüística
Métodos de Construcción
Formal
Métodos de Construcción
Visual
Conceptos básicos de Pruebas y
Definiciones
Niveles de Pruebas
Técnicas de Pruebas
Administración del Proceso de
Pruebas
Conceptos básicos de
Mantenimiento
Procesos de Mantenimiento
Criterios principales en el
Mantenimiento del Software
Técnicas para Mantenimiento
Administración del proceso de
ACS
Identificación de la Configuración
del Software
Control de la Configuración del
Software
Contabilización del Status de la
Configuración del Software
Auditoria de la Configuración del
Software
Administración de liberaciones y entregas de
Software
Administración Organizacional
Administración de Procesos y del
Proyecto
Medición de la Ingeniería de
Software
Conceptos de Procesos de la Ingeniería de
Software
Infraestructura de Procesos
Medición de Procesos
Definición de Procesos
Análisis Cualitativo de
Procesos
Implementación y Cambios de
Procesos
Herramientas Software
Herramientas para el Requerimiento
del Software
Herramientas para el Diseño del
Software
Herramientas para la Construcción del
Software
Herramientas para las Pruebas del
Software
Herramientas para los Procesos de la
Ingeniería de Software
Herramientas para la Calidad del
Software
Herramientas para la Administración
de la Configuración del Software
Herramientas para la Administración
de la Ingeniería de Software
Herramientas para el Soporte de Infraestructura
Miscelánea de criterios para Herramientas
Herramientas Software
Métodos y heurísticas
Métodos Formales
Métodos de Prototipado
Miscelánea de criterios para
Métodos
Conceptos sobre Calidad del Software
Definición y Planeación para la
Calidad
Técnicas que requieren dos o más personas
Soporte para otras Técnicas
Técnicas especiales para el Aseguramiento de
la Calidad del Software
Técnicas para encontrar Defectos
Mediciones en el Análisis de Calidad del Software
2.5. Marco teórico
2.5.1. De la Ingeniería de Software (IS)
La IS se encarga de estudiar, aplicar, comprender e investigar todos los
factores necesarios para el desarrollo del software.
Este término acuñado en las famosas reuniones de la OTAN (1968) pretende
entre varias cosas, sistematizar el desarrollo de un proyecto de software en
base a una serie de etapas claramente definidas en su concepción.
El modelo que constituye estas etapas se conoce como “modelo del ciclo de vida
del desarrollo del software” (CVDS) y representa la estrategia aplicada al control
de proyectos de desarrollo de software en base al tiempo (ciclo).
Los estudios realizados por Kybele, tratan de resolver la problemática de la
ciencia y su método de investigación, frente a la tecnología del diseño de
software y su método de desarrollo; métodos que se asemejan cada vez más.
Mario Bunge, manifiesta que las teorías científicas permiten ampliar y
profundizar el conocimiento del mundo, mientras que las teorías tecnológicas
emplean ese conocimiento con fines prácticos, es decir, son teorías
instrumentales que generan herramientas (son un instrumento para lograr fines
utilitarios).
De ahí que no resulte muy apropiado describir a las tecnologías como simples
aplicaciones del conocimiento científico al proceso productivo. [*Kybele] [Esp 89]
Una teoría verdadera puede utilizarse con éxito en la investigación aplicada o
en la investigación tecnológica, sin perder de vista que también puede
funcionar bien una teoría falsa, porque lo importante para la tecnología es que
el resultado sea útil, más allá de si lo que dice es verdadero o falso10.
Al emplear una “metodología de desarrollo” en la concepción de un proyecto de
software, se siguen en esencia los mismos pasos aplicables a la investigación
científica, lo que genera un traslape y una duplicación de información y
esfuerzos, en la documentación entregada como tesis de grado por parte del
estudiante.
Desde la perspectiva del estudiante, es decir, del equipo de desarrollo de
software, el conocimiento científico básico y aplicado, tal como lo generan los
grupos de investigación científica, es un producto muy diferente al de la
tecnología de producción que él utiliza.11
En el diseño de un producto, influyen decenas de miles de datos, de los cuales
generalmente no más de un 5 a un 10% provienen de la ciencia, el resto se
origina en gran medida en la propia actividad productiva y se encuentra
incorporada, por ejemplo, en las normas de diseño de operación y
mantenimiento, o en mejoras a éstas, derivadas de la experiencia de
numerosas personas. [Esp 89, p. 8]
La tecnología es indispensable para que una sociedad pueda alcanzar su
desarrollo armónico e integral y consecuentemente el de todos sus miembros.
10 “Por ejemplo, se puede curar a un neurótico por medio del chamanismo, etc. (falso), siempre y cuando se use también la sugestión, el condicionamiento, los
tranquilizantes, etc. (verdadero). De esto se desprende que la práctica exitosa no garantiza que la teoría de la cual proviene sea verdadera. Una práctica que
da resultados no necesariamente convalida o asegura la verdad de la teoría correspondiente. Entre otras cosas, porque en la práctica se manejan muchas
variables que no se controlan con precisión, pero que se hace uso de ellas para hacer exitosa la operación. En cambio la teoría considera solo algunas
variables, y busca controlarlas artificialmente.” [*Bun 71]
11 “La escuela de pensamiento de EEUU que es muy floja en filosofía y pragmática en exceso, utiliza las temimos en forma demasiado libre. En la bibliografía se
habla de Metodología, cuando se hace referencia a un Método. De Método, cuando se hace referencia a un Proceso. De filosofía, cuando se hace referencia a
una Metodología. De Arquitectura cuando se hace referencia a la Infraestructura, etc. Esto no solo ocurre porque quienes redactan los libros carecen en
mucho de estos conceptos, sino también porque el Marketing gobierna y se eligen los términos que resuenan mejor para vender el producto. De allí en más,
todo esta dado vuelta” [*Pérez]
Generalmente se piensa en las tecnologías de producción, como las únicas o
las más importantes; sin embargo, otras tecnologías de negocio adicionales
son esenciales para el éxito de un proyecto de software.
Tal es el caso de las tecnologías para:
1) Estudios de mercado y de factibilidad.
2) Diseño de equipos, estructuras y sistemas de apoyo.
3) Construcción y montaje de procesos.
4) Comercialización de productos.
5) Manejo administrativo, financiero y de personal.
2.5.2. Del método de investigación científica (IC).
Etimológicamente el término método, proviene de las raíces griegas: metá: que
se entiende como a través, más allá, es una proposición que da idea de
movimiento, y hodós que significa camino.
Entendiéndose entonces como método: “el camino a seguir mediante una serie de
operaciones, reglas y procedimientos fijados de antemano de manera voluntaria y
reflexiva, para alcanzar un determinado fin, que puede ser material o conceptual”12
[Esp 89, p. 10]
Así como la ciencia pura (teorías científicas) dirige su atención a leyes, la
investigación tecnológica dirige su atención a reglas.
Una regla prescribe un curso de acción: indica como debe procederse para
conseguir un objetivo predeterminado. Se trata, más concretamente, de una
12 Fuente citada en [Esp 89, p. 10], ANDER –EGG, Ezequiel: Técnicas de Investigación social, p. 41, Editorial Humanitas, Buenos Aires,
Argentina.
instrucción para realizar una secuencia finita de actos hasta alcanzar un
objetivo.
Las reglas son normas para el comportamiento humano, a diferencia de las
leyes científicas, que son esquemas que apuntan a mostrar como funciona toda
la realidad, y no solamente la acción humana.13
Los métodos de investigación científica no están diseñados formalmente para
el desarrollo de software, pues resultarían lentos en conseguir sus objetivos de
forma lógica.
La Escuela Pragmática Norteamericana del Software, propone un modelo más
ágil en base a la recolección de las mejores prácticas obtenidas en el desarrollo
de proyectos de software. De allí que su método se trate como prototipo
experimental, que se manifiesta por la cantidad de “metodologías” de desarrollo
existentes en el mercado del software.
Esta primera diferencia entre el método de investigación científica y la metodología de
desarrollo de software, responde a la problemática del estudiante a la hora de realizar
la documentación técnica frente a la documentación de investigación científica
requerida.
13 Las reglas tecnológicas, llamadas enunciados nomo pragmáticos, se fundan en leyes científicas, también llamadas enunciados nomológicos. Las reglas
tecnológicas son recetas prácticas sobre como actuar, mientras que las leyes son regularidades observadas y comprobadas en la naturaleza [*Bun 71]
Ilustración 2 Modelo del método de IC por Mario Bunge [*Kybele]
Determinación del Problema
Análisis de Resultados y
elaboración de conclusiones
Resolución
Validación
Verificación
Definición del Método de Trabajo
Creación de la Hipótesis
Redacción del Informe Final
Cuerpo de
conocimientos
Problema
Bús
qued
a de
doc
umet
naci
ón
Nuevo cuerpo de
conocimientos
Nuevo
Problema
2.5.3. Del modelo CVDS.
Antes de iniciar el proceso para lograr el conocimiento de un fenómeno o
problema, es necesario diseñar la estrategia que oriente al investigador.
Esta estrategia se contempla como un plan lógico y racional que le permite
proceder en forma sistemática y ordenada, que lo guíe y lo auxilie para informar
a otros acerca de las características que reviste la investigación en curso.
[Vej 04, p. 12]
Este plan lógico se pone de manifiesto en la definición de la IS y su modelo
CVDS.
En las conferencias patrocinadas por la OTAN (1968) participaron los más
destacados intelectuales del software, representantes de los diversos intereses
del mercado. La idea central puesta de manifiesto en dichas reuniones fue:
¿Cómo lograr producir software en una manera sistematizada?
Se entiende por “producción” al proceso de desarrollar software desde la
abstracción, pasando por el diseño, para concretar una funcionalidad mediante
el uso del hardware; esto es en definitiva la expresión “el ciclo de vida del
desarrollo del software” CVDS.
El software a diferencia de otros productos de la tecnología o de la ingeniería,
se caracteriza por su esencia abstracta <<proceso de abstracción>>.
La elección de un modelo apropiado al proceso de “fabricación” o de aquí en
adelante (desarrollo), es muy importante para el éxito de un proyecto de
software.
Ilustración 3 Modelo CVDS por etapas [*Giménez]
PLAN OPERATIVO
MANTENIMIENTO
VALIDACIÓN Y
VERIFICACIÓN
INTEGRACIÓN
IMPLEMENTACIÓN
DISEÑO
ESPECIFICACIÓN
FUNCIONAL
ESPECIFICACIÓN DE
REQUERIMIENTOS
Definición del Problema y establecimiento del
Proyecto
Visión profunda del desarrollo desde el punto de
vista de desarrolladores y usuarios
Especificación de la información sobre la cual el
software trabajará
Descripción de cómo el software va a satisfacer los
requerimientos
Codificación del Software
Integración de todos los módulos codificados
independienetmente
Verificación por pruebas de la consistencia con la
definición
Modificación al Software por fallos, errores,
cambios, etc.
MODELO CLÁSICO POR ETAPAS
Modelo Lineal que considera el
desarrollo del Software por Etapas.
Cada etapa debe ir a continuación de
la anterior.
Este modelo pone énfasis en la
Documentación que es el resultado
de cada etapa y que sirve de entrada
para la etapa siguiente.
Todo tendiente a formar una cadena
de “producción” del Software.
Este modelo fue propuesto por IBM al
DoD y su proyecto SAGE en 1956
La concepción de una crisis en el desarrollo de software fue evidente,
presentándose la necesidad de contar con una manera organizada de realizar
software, pero ¿cómo?, (este proceso se conoce como metodizar)14.
Para la década de los años 60, el interés principal en el diseño del software se
enfoca como “proyectos de desarrollo de software”, o simplemente como
programación de sistemas, más tarde se conceptúa como desarrollo de sistemas
de software (en vista de la existencia de software anteriormente creado), para en
la actualidad presentarse como el desarrollo de productos software, obedeciendo
a la influencia del marketing en la distribución del software en el mercado
internacional.
¿Qué significa esto?
La concepción actual del proceso de desarrollo del software considera en su
haber, una infraestructura de software más robusta y estable, tendiente a
trabajar con componentes de objetos <<orientación a objetos>>.
Pensar en objetos, involucra necesariamente el uso de la reutilización como
premisa de construcción, puesta de manifiesto por el concepto de herencia.
El problema tradicional de no saber cómo definir un modelo apropiado para el
desarrollo del software, está parcialmente resuelto por la orientación a objetos y
en la actualidad se encuentra aún en estudio como la programación orientada a
aspectos.
Existe sin embargo, una marcada diferencia entre el software y el hardware; el
hardware se caracteriza porque en su proceso productivo se pueden aplicar
economías de escala, lo cual no tiene sentido en el software.
14 “Metodizar: tr. Poner orden y método en una cosa” [UNO 94]
Si la idea de producción se refiriera únicamente al proceso de duplicar
productos software, no tendría sentido la necesidad de una creatividad
constante sujeta al continuo cambio que existe en la relación entre usuario y
programador. [*Kybele]
La idea de aplicar un modelo de producción se establece en el dominio del
software, como la necesidad de adoptar una “metodología” de desarrollo
reconocida como estándar en el mercado.
En 1956, durante la denominada “Guerra fría”, el Departamento de Defensa de
los USA (DoD)15, es el mayor consumidor de la tecnología del software y es
quien pone de manifiesto la necesidad de un tipo de documentación que
corresponda a un plan operativo de inversión.
“Un modelo de ciclo de vida del desarrollo de software, es una vista de las actividades
que ocurren durante el proceso de desarrollo de software, intenta determinar el orden
de las etapas involucradas y los criterios de transición asociadas entre estas etapas.”
[*Giménez]
Sin embargo, se detalla que no todas las “metodologías” de desarrollo de
software pueden ser aplicadas a todos los modelos CVDS, ni todos los
modelos pueden aplicarse de forma efectiva a todos los diseños del software.
El impacto que tienen dichos modelos en el proceso de desarrollo de software
es pues evidente, sin embargo no se encuentran registros de artículos que
estudien este fenómeno a nivel del Ecuador.
15 DoD: Departament of Defense
2.5.4. De las metodologías de desarrollo de software.
Se ha convertido en costumbre en parte de la literatura del software, hablar
sobre “metodologías” cuando realmente se quiere decir métodos (el método
orientado a objetos, etc.)
Históricamente, los primeros intentos por definir una metodología de desarrollo
de software son asignados a E. W. Dijkstra (1968) en base a sus críticas a la
sentencia GO TO16, quien pone de manifiesto la necesidad de obtener una
infraestructura interna más estable en el diseño del software y en particular, de
una muy buena documentación.
El proceso de desarrollar software requiere la utilización de métodos e
instrumentos para conseguir en forma ordenada y controlada su consecución.
Evidentemente, las metodologías no son la panacea para el desarrollo de
software, el proceso creativo que se encuentra implícito en el diseño de
productos de software depende de las personas involucradas en el proyecto.
Una “metodología de desarrollo de software” es una ayuda, una guía de como
visualizar las estrategias a seguirse para conseguir un producto.
Las metodologías no resuelven los problemas, son los hombres quienes
resuelven los mismos en base a un criterio y el uso de su imaginación o
creatividad.
Todas las metodologías consideran al menos cuatro elementos importantes en
su concepción [*San 03].
16 La sentencia GO TO fue utilizada en la sintaxis de los lenguajes de programación para producir un salto incondicional dirigido sin retorno, Edsger W.
Dijkstra: Go To Statement Considered Harmful, forma parte de Communications of the ACM, vol. 15, n.º 10, octubre de 1972, pp. 859-866
Principio rector: considerado como la “filosofía de diseño” que es la
norma o idea fundamental que rige el pensamiento o la conducta del
equipo de desarrollo, define tanto las herramientas que son aplicables en
la metodología como los procedimientos con los que se aplica.
Herramientas: Son todos los artefactos creados por la metodología que
permiten resolver las fases de las IS acorde al principio rector de la
misma, como por ejemplo los casos de uso, diagramas y fundamentos.
Procedimientos: Indican la forma o el modo en que se realizarán los
pasos para conseguir (mediante el uso de las herramientas) los objetivos
planteados, según las estrategias de control de la metodología y
determinan sus resultados para fines de evaluación.
Modelos: Definen las estrategias a seguirse para alcanzar un objetivo,
determinan como organizar los procedimientos y cómo utilizar los
diagramas diversos de la metodología, determinan así, las fases de la IS y
los valores que se desean controlar y administrar, como por ejemplo el
modelo CVDS.
2.5.4.1. Consideraciones sobre metodologías
El primer paso a considerarse, consiste en conseguir una visión consistente del
problema objeto de estudio.
Las reglas de metodología del software deben basarse en una teoría sobre el tema
subyacente.
La teoría es la parte deductiva de la metodología del software. Pero unas
reglas que sólo estuvieran basadas en la teoría podrían ser peligrosas. El
componente empírico es igual de importante.
Las reglas de metodología del software deben estar respaldadas por una amplia
experiencia práctica.
Una experiencia tal, debe incluir todas las actividades del CVDS, por lo tanto,
es preciso definir primeramente las denominadas “mejores prácticas”17 como un
primer paso hacia el objetivo de obtener un método sistematizado de
documentar un proyecto de desarrollo de software, en base al estudio del
SITEDI.
Debido a la diversidad de enfoques existentes en la concepción del software,
este trabajo solo se limita a estudiar las fases de análisis y diseño, dejando
abierta la posibilidad de seguir investigando las demás fases de tan importante
tópico de la IS.
La denominada “guerra de los métodos” se ha establecido para referir a las
diversas técnicas de diseño y producción de software existentes en el mercado
a lo largo de la historia del software y su proceso de desarrollo.
El método de producción de software necesariamente esta relacionado con el
concepto de CVDS y el método de diseño esta asociado a todos aquellos
aspectos técnicos que involucran: el análisis y diseño estructurado, el análisis y
diseño orientado a objetos y en estudio el análisis orientado a aspectos.
17 El término “the best practices” (mejores prácticas) es utilizado para hacer referencia a la experiencia obtenida de todas aquellas prácticas y herramientas que
han sido reconocidas como eficientes para encarar un desarrollo o resolver un problema en un proceso productivo a nivel internacional, teniendo en cuenta
su exactitud y costo.
2.5.4.2. Los modelos CVDS y las metodologías
Se puede mencionar los siguientes modelos CVDS y su reconocimiento en las
diversas “metodologías de desarrollo” registradas en la literatura técnica del
software.
(1) Modelo Codificar y corregir: Modelo flexible dirigido por el código
fuente que surge desde los inicios de la IS.
(2) Modelo por Etapas: Modelo dirigido por la documentación, propuesto
para el desarrollo del software requerido por el DoD y su proyecto
SAGE (1956).18
(3) Modelo en Cascada: Modelo dirigido por la documentación y la
retroalimentación que fue reconocido como estándar por el DoD en la
década de 1970. (Royce)
(4) Modelo en Espiral: Modelo dirigido por el análisis de riesgos a lo largo
del proceso productivo que considera al desarrollo bajo una convicción
dinámica de entrega por etapas. (Boehm, 1980)
(5) Modelo Iterativo e incremental: Modelo dirigido por hitos e
iteraciones a lo largo del desarrollo, que considera al tiempo como uno
de los criterios más importantes en el proceso productivo.
(6) Modelo de prototipado: Modelo cuyas dos escuelas de pensamiento
requieren del uso de un prototipo como guía para el desarrollo del
software. Las dos escuelas se diferencian entre sí, por el tratamiento a
dicho prototipo a lo largo del proceso “productivo”. Por un lado existe
18 El proyecto SAGE es emprendido por IBM para generar software con fines militares para la Fuerza Aérea Norteamericana
la tendencia “no limpia o sucia” que considera al prototipo como una
base inicial del diseño (empleado por el modelo en cascada) que luego
es desechado una vez obtenida la experiencia y el conocimiento
necesario del mismo y, por otro lado, existe la tendencia de un
prototipo “limpio” sobre el cual se trabaja hasta desarrollar el sistema
completo (modelo iterativo e incremental, modelo en espiral).
(7) Modelo de componentes: Modelo dirigido por la reutilización como
premisa de construcción, actualmente usado en el desarrollo de
productos software.
(8) Modelo Unificado: Propuesto por Walker Royce (hijo de quien diseñó
el modelo en cascada) que define un modelo dirigido por hitos, cuya
estructura se establece mediante objetivos y que son alcanzados
mediante la técnica de liberación de versiones de un producto software
en base al modelo iterativo.
3. PARALELISMO ENTRE LOS MODELOS DE IC Y EL CVDS
3.1. Estudio comparativo de los modelos.
Determinación del Problema
Análisis de Resultados y
elaboración de conclusiones
Resolución
Validación
Verificación
Definición del Método de Trabajo
Creación de la Hipótesis
Redacción del Informe Final
Cuerpo de
conocimientos
Problema
Bús
qued
a de
doc
umet
naci
ón
Nuevo cuerpo de
conocimientos
Nuevo
Problema
PLAN OPERATIVO
MANTENIMIENTO
VALIDACIÓN Y
VERIFICACIÓN
INTEGRACIÓN
IMPLEMENTACIÓN
DISEÑO
ESPECIFICACIÓN
FUNCIONAL
ESPECIFICACIÓN DE
REQUERIMIENTOS
MODELO DE INVESTIGACIÓN CIENTÍFICA
MODELO CLÁSICO DE
DESARROLLO DE
SOFTWARE POR ETAPAS
Una comparación por analogía, no constituye de por sí, una inferencia lógica.
La comparación sólo prepara las condiciones para que, basándose en ella,
pueda realizarse una inferencia.
“En realidad, la analogía constituye uno de los grados más importantes del proceso
del conocimiento científico [e ingenieril]. Este grado, empero, no es nunca definitivo,
sino que ha de ser considerado más bien como una fase inicial de investigación. Por
esto, la analogía adquiere sólo su plena importancia científica, cuando la ciencia,
partiendo de dicho grado de conocimiento y comprobándolo en la práctica, lo eleva a
un grado superior, al del conocimiento verdaderamente cierto” [Gor 74, 240]
Como anteriormente se ha manifestado, el Grupo Kybele ha investigado
profundamente la temática sobre el método de investigación científica aplicable
a la IS, que sirve de base para el siguiente análisis comparativo.
Tabla 1 Resumen de problema, ciencia y método de la IS [*Kybele]
PROBLEMAS CIENCIA OBJETO DE
ESTUDIO CARACTER MÉTODOS
TIPO A Ciencias de la Ingeniería de
Software
Construcción de nuevos objetos
Ingenieril Cualitativos y Creativos
TIPO B Ciencias del
Software Objetos
construidos Empírico Cuantitativos
TIPO C
Ciencias de los Sistemas
de Información
Implantación y uso de los
objetos construidos
Cultural y social
Cualitativos
“Los métodos de desarrollo de software, al igual que ocurre con los métodos de
investigación en las Ciencias de la IS, tienen también un fuerte componente cualitativo
(factores humanos, sociales y culturales). Además de que, nadie duda de la importancia
de la creatividad a la hora de concebir un nuevo producto software” [*Kybele]
Kybele propone una clasificación de las ciencias relacionadas a la investigación
del software, según la naturaleza del conocimiento empleado en la resolución
de problemas (Tabla 1):
(1) La investigación enfocada a la construcción de nuevos (procesos,
modelos, metodologías, técnicas, etc.) se realiza en el ámbito de lo que se
denomina Ciencias de la Ingeniería de Software. Esta naturaleza de
investigación requiere de la ingeniería en el sentido de que su objeto
de estudio es la construcción de nuevas herramientas (métodos,
modelos, etc.) para la construcción de software.
(2) La investigación enfocada al estudio de dichas herramientas (métricas,
optimización, etc.) se realiza en el ámbito denominado por Kybele como
Ciencias del software. Su objeto de estudio no difiere del de las ciencias
tradicionales sino en que los objetos de estudio son artificiales en lugar
de naturales.19
(3) La investigación enfocada a la implantación y el uso de dichas
herramientas; este tipo de investigación, sin embargo, se realiza dentro
de los que Kybele denomina como Ciencias de los Sistemas de
Información.
Los problemas de tipo A (Véase Tabla 1), son de naturaleza ingenieril; los problemas
de tipo B tienen, en general, naturaleza empírica; los problemas de tipo C se
centran en el estudio de problemas de carácter cultural y social.
19 Kybele cita a Aracil J, quien expone que “las ciencias se ocupan de lo natural, mientras que el dominio específico de la ingeniería es lo artificial” y define que
su metodología toma en cuenta factores de tiempo y circunstancia, como la urgencia o la rentabilidad, que las ciencias tradicionales no consideran [*Kybele]
3.1.1. El método
El método empleado en la investigación, depende necesariamente del objeto
de estudio, sin embargo, es lógico comprender que habrá problemas que
caigan en más de una de estas clases de ciencias y que requerirán, por lo
tanto, de la combinación de diferentes métodos.
Una clasificación generalmente aceptada de los métodos de investigación, los
divide en métodos cuantitativos y métodos cualitativos.
Los métodos deductivos y empíricos, pueden agruparse dentro de los métodos
de investigación cuantitativos y son apropiados para el estudio de fenómenos u
objetos naturales. Sin embargo, el estudio de fenómenos culturales y sociales
requiere otro tipo de métodos, que no se basen en experimentos ni teorías
formales, sino en entrevistas, cuestionarios, documentos, impresiones y
reacciones del investigador, etc.
Estos métodos pueden agruparse en los denominados métodos cualitativos y
entre ellos se encuentran la investigación en acción, los casos de estudio, etc.,
Los problemas de tipo B, pretenden contestar preguntas como: ¿Cuánto de
bueno es un método? ¿Es posible obtener un método de acceso más eficiente?
Estos problemas se asemejan en su naturaleza a los problemas tratados por
los métodos tradicionales (formales y empíricos) de la ciencia por lo que
pueden ser abordados mediante métodos cuantitativos (aunque no
exclusivamente).
Los denominados problemas de tipo C, requieren del estudio de factores
sociales y culturales, ya que pretenden responder a preguntas como: ¿Cuáles
son los factores por los que un determinado proceso de software no es aceptado en la
empresa? ¿Por qué una herramienta de desarrollo de software tiene más o menos
aceptación que otra?, este tipo de problemas no pueden ser abordados
únicamente mediante los tradicionales métodos puramente cuantitativos. Son
problemas que deben ser abordados por métodos cualitativos.
La resolución de aquellos problemas cuya naturaleza es puramente de
ingeniería, los problemas de tipo A, requieren otro tipo de métodos. En estos
casos, no es posible aplicar métodos empíricos, ya que el objeto de estudio aún
no existe.
Adicionalmente, en las ingenierías cuyo conocimiento tiene un componente
importante de creatividad, se dificulta la elaboración de un método universal
para la resolución de problemas en este ámbito.
Además del componente de creatividad, la investigación en este tipo de
problemas tiene un fuerte componente social y cultural en cuanto la adopción
de nuevos paradigmas, la parte de trabajo en equipo de los procesos software,
el trabajo de colaboración entre programador y usuario, etc. [*Kybele]
Por todo ello, Kybele enfatiza en la necesidad de emplear métodos de carácter
cualitativo y creativo en la investigación aplicada a la IS20.
20 Métodos Cualitativos: Los investigadores cualitativos hacen registros narrativos de los fenómenos que son estudiados mediante técnicas como la observación
participante y las entrevistas no estructuradas. La diferencia fundamental entre ambas metodologías es que la cuantitativa estudia la asociación o relación
entre variables cuantificadas y la cualitativa lo hace en contextos estructurales y situacionales. La investigación cualitativa trata de identificar la naturaleza
profunda de las realidades, su sistema de relaciones, su estructura dinámica. (http://www.fisterra.com/material/investiga/cuanti_cuali/cuanti_cuali.htm)
Métodos Creativos: Son aquellos que utilizan mayoritariamente las artes, si bien la creatividad y ciencia están siendo cada día más relacionados… Aunque la
creatividad podría verse como una característica de la investigación, independiente del método, …hay ciencias cuya investigación requiere de un alto grado
de creatividad en oposición a la observación o la experimentación. Cuando la creatividad marca el proceso de investigación, hablamos de métodos creativos.
Estos métodos se basan en características como la imaginación, premonición, visualización… y en ellos interviene la inteligencia creativa del investigador por
encima de la racional [*Kybele]
3.1.2. La IC en el desarrollo de productos software
Un tipo de IC reconocido es la denominada “Investigación de campo”, que trata
de reunir los datos evidentes de la realidad, por ello se lleva a cabo en el lugar
donde se encuentran los sujetos, hechos o fenómenos que son motivo de
estudio, con quienes el investigador establece un contacto directo.
Este tipo de investigación se caracteriza fundamentalmente por la exploración,
observación y captación del fenómeno en sí, para lo que utiliza técnicas e
instrumentos específicos, tales como entrevistas, observaciones, encuestas,
cuestionarios, registros anecdóticos, etc., que posibilitan la recopilación de
datos e información.
La diferencia fundamental que se presenta entre el modelo del método IC y el
modelo del CVDS, es que el primero consta de partes como la hipótesis y las
variables que, obligatoriamente, deben ser verificadas mediante pruebas
estadísticas específicas (método cuantitativo); mientras que el segundo, se
caracteriza por la ausencia de hipótesis; sin embargo, se asemeja en que el
producto final obtenido, es decir el software, debe verificar que el tratamiento a
dichas variables represente la realidad del entorno del usuario (método
cualitativo creativo).
Si el software no responde a estas características implica una falla en la
creatividad de su diseño.
3.2. Paralelismo IC vs. CVDS
El modelo del método de investigación científica (IC) es sugerido por el
Departamento de Tesis de Grado, fundamentado en el reglamento del Consejo
Nacional de Estudios Superiores (CONESUP) a este respecto y del
Reglamento de Tesis de la UTECI, mientras que el modelo (CVDS) es sugerido
por el método de “producción” del software utilizado por la metodología de
desarrollo de software empleada en las tesis (documento).
Para poder establecer un paralelismo entre el método de investigación aplicado
en la IS y el modelo CVDS clásico por etapas empleado en el proyecto
emprendido por IBM en su proyecto (SAGE), se ha considerado el estudio
externo realizado al SITEDI y las fases empleadas en su proceso “productivo”
de software, frente a los pasos considerados según Mario Bunge, que se deben
seguir en toda investigación científica.
3.2.1. Búsqueda de documentación
La búsqueda de documentación en una IC incluye:
(1) Documentación a cerca del problema a resolver y
(2) Documentación relacionada con el método a utilizar en la
resolución y la validación.
Estas técnicas previas a la definición de un proceso de
investigación, delimitan el objeto de estudio en base a tres preguntas:
(1) ¿Cuál es el problema concreto a investigar?
(2) ¿En qué unidades se va a investigar el problema?
(3) ¿Cómo se va a investigar el problema?
Mientras que en un proceso de desarrollo de software, la búsqueda de
documentación incluye:
Búsq
ueda
de
docu
met
naci
ón
(1) Documentación acerca de las “metodologías” existentes en el mercado.
(2) Documentación sobre productos (lenguajes de programación, sistemas
operativos, hardware, redes, bases de datos, etc.)
(3) Documentación sobre procesos vigentes en el entorno del usuario, etc.
En muchas ocasiones, antes de comenzar un desarrollo es necesario
documentarse también sobre el dominio específico del producto software a
desarrollar respecto a las tecnologías de información.
Estas técnicas permiten definir el límite del diseño del producto software en base a
la pregunta ¿Cuál es el problema concreto a resolver mediante la tecnología del
software?, que corresponde a la etapa de análisis, postergándose la pregunta
¿Cómo se va a resolver el problema?, para las etapas de diseño y codificación.
3.2.2. Formulación del problema
En consecuencia, la formulación del problema es el primer paso del proceso de
investigación, sin embargo el abordar o confrontar uno o varios problemas no
es suficiente, es necesario plantear y formular el problema en forma correcta.
El modelo clásico del desarrollo de software por etapas, define a esta fase
como la concepción de un plan operativo.
PLAN OPERATIVODefinición del Problema y establecimiento del
Proyecto
Problema
El investigador encuentra algún problema que desea
resolver pero no posee los medios para llegar al fin
deseado.
Cuerpo de
conocimientos
Problema
En esta etapa se trata de determinar y definir claramente, partiendo de los
problemas sin resolver dentro del campo de conocimiento del usuario, el
problema que se desea resolver
Ahora bien, no todo problema se constituye de carácter
científico. Para que el problema tenga esta característica,
es necesario plantearlo dentro de un modelo teórico o en
el marco referencial de una ciencia.
Esta característica en el diseño del software, denota la necesidad de emplear
un marco de trabajo o “framework”21 para poder enfocar el desarrollo del
proyecto software en forma ordenada y sistemáticamente acorde a los medios
disponibles en las tecnologías de información.
Una vez identificado el problema, el siguiente
paso consiste en “ir delimitando” cada uno de
los subproblemas que forman parte del área del problema, de modo que
permita el abordaje en su totalidad.
Para ello mucho factores deben considerarse, tales como: disponibilidad de
recursos, de tiempo, limitaciones de orden científico, nivel insuficiente de
avance científico en el área y otros.
Todo esto obliga al investigador a realizar un análisis conducente a depurar y
delimitar progresivamente el “área problema” hasta seleccionar uno o varios
aspectos de ella.
En el diseño del software, esta etapa se conoce como la “captura de
requerimientos”.
21 Framework o marco de trabajo representa un patrón arquitectónico que proporciona una plantilla extensible para las aplicaciones dentro de un dominio.
Determinación del Problema
ESPECIFICACIÓN DE
REQUERIMIENTOS
Visión profunda del desarrollo desde el punto de
vista de desarrolladores y usuarios
Esta fase permite realizar un análisis del problema abordado, así como
delimitar los aspectos funcionales concretos que se tendrán en cuenta para el
futuro sistema.
Esta etapa es una de las más críticas e importantes en el diseño de un
producto software, pues necesariamente refleja la interacción entre el usuario y
el equipo de desarrollo, generando así el denominado “límite del sistema
software”.
Ilustración 4 Captura de requisitos [Arm 00, p. xxviii]
Fred Brooks22 en 1987 escribe un famoso artículo para el IEEE, en el cual
manifiesta que el aspecto más difícil para una exitosa entrega de una solución
software, es conceptuar en forma precisa la especificación del sistema por
construirse.
22 Brooks, F.P., Jr. No silver bullet: essence and accidents of software engineering. Computer (Apr.): 10-19 (1987).
Para ello se requiere no solamente de un profundo entendimiento del problema
que se desea resolver, sino también, un entendimiento de cómo el software
puede ser utilizado como ayuda para establecer una solución a dicho problema.
La complejidad de esta etapa se encuentra estudiada por otra tecnología, en un
área de conocimiento denominada “Ingeniería de Requisitos del Software”.
[*SWEBOK]
ESPECIFICACIÓN
FUNCIONAL
Especificación de la información sobre la cual el
software trabajará
3.2.3. Creación de hipótesis
En la ciencia se llama hipótesis a la
suposición que se hace respecto a un
hecho que no puede observarse directamente o acerca de un orden regular
conjeturado, no observado directamente, que explica un conjunto de
fenómenos conocidos por la experiencia.
Siendo estas conjeturas de los hechos lo que el método científico tendrá que
contrastar y verificar.
Las tesis de grado cuyo tema se establece como el desarrollo de un producto
software, no se basa en la hipótesis para su desarrollo (sin embargo esta
restricción no es exclusiva, como en el caso de las Ciencias de los Sistemas de
Información [*Kybele]).
En el diseño del software, como herramienta tecnológica, se pretende obtener
un nuevo producto que permitirá mejorar o automatizar un proceso (si es que
existe) gracias al cual el usuario puede solucionar su problema.
Creación de la Hipótesis
DISEÑO
ESPECIFICACIÓN
FUNCIONAL
Especificación de la información sobre la cual el
software trabajará
Descripción de cómo el software va a satisfacer los
requerimientos
La creatividad del equipo de desarrollo se pone de manifiesto en esta etapa
sumada a la experiencia anterior en el desarrollo de soluciones software.
El diseño de un producto software es el reflejo de la interacción entre el equipo
de desarrollo y el usuario.
Por lo que, el diseño de hipótesis puede conceptuarse en el desarrollo de un
producto software, como la especificación de aquellos requisitos funcionales
(capturados previamente) del nuevo producto software, que se expresan en
base al diseño funcional y de administración de información que se requieren
en la práctica real del negocio.
Esto se conoce como el factor de corrección23 de la calidad del software.
3.2.5. Definición del método de trabajo
En la IC, el método constituye la herramienta fundamental del investigador,
puesto que, desde que se identifica el problema hasta la redacción del informe
científico, se requiere del método.
Sea cual sea el método empleado, el método científico se caracteriza por ser
un procedimiento formal y riguroso formulado de una manera lógica para lograr
23 Factor de corrección: Factor de la calidad del software que expresa que un producto software hace exactamente lo que su descripción funcional dice debe
hacer.
la adquisición, organización o sistematización y expresión o exposición de
conocimientos, tanto en su aspecto teórico como en su fase experimental.
Resolución
Validación
Verificación
Definición del Método de Trabajo
Diferentes autores, al especificar el campo de la metodología, distinguen varias
categorías de métodos: de organización, de transmisión de conocimientos y de
investigación.
Sin embargo, para alcanzar el conocimiento científico, la ciencia desarrolla
varios métodos; mientras más compleja y profunda sea la visión que se desea
tener del fenómeno, mayor número de métodos se hacen imprescindibles para
lograr tal conocimiento.
Este fenómeno se pone de manifiesto en el diseño de un producto software
respecto al uso de una “metodología de desarrollo”.
Una metodología de desarrollo engloba las mejores prácticas aplicables a lo largo
del ciclo de vida del desarrollo del software.
Al iniciar una investigación, es preciso elegir el paradigma metodológico que se
va a seguir (cualitativo, cuantitativo, etc.), así como el método concreto
(investigación en acción, experimentación, etc.)
Del mismo modo, al iniciar un desarrollo de software se decide el paradigma
metodológico (estructurado, orientado a objetos, etc.) y la “metodología”
concreta a seguir (OMT, XP, RUP, empírica o ninguna, etc.)
No obstante, el uso de una “metodología” no puede ser considerado como algo
rígido, sino tan sólo como una guía basada en dichas “mejores prácticas”
establecidas en el desarrollo anterior de soluciones software.
El método se va refinando mientras se avanza en la resolución del problema,
no concluye hasta que se finaliza la fase de resolución y verificación, el
software a su vez, se modifica continuamente, no es estático.
3.2.6. Resolución, validación y verificación
La hipótesis acerca de un hecho pasa a ser verdad demostrada si resulta que
del hecho supuesto, y sólo de él, se sigue una consecuencia, cuya validez se
averigua mediante la experiencia.
Resolución
Validación
Verificación
Definición del Método de Trabajo
Para validar una hipótesis presentada como respuesta a un fenómeno
investigado, los métodos definidos en la investigación, permiten contrastar y
comparar al modelo diseñado con la realidad.
No solo se debe validar una hipótesis, hay que necesariamente verificarla con
la realidad.
Los métodos de validación y verificación hacen referencia a la lógica aplicada
en el diseño del pensamiento científico a lo largo del estudio del hecho.
En el campo del desarrollo de productos software, la resolución de la
problemática del negocio del cliente, se corresponde necesariamente a la etapa
de diseño e implementación.
IMPLEMENTACIÓN
DISEÑODescripción de cómo el software va a satisfacer los
requerimientos
Codificación del Software
La infraestructura interna del software referida por Dijkstra, obedece a:
estructuras de control, a los denominados tipos de datos y al tratamiento de los
mismos.
El factor de diseño conocido como “corrección” que se emplea para denotar
que el software debe comportarse como se especifica en su diseño, es una
premisa para su concepción.
Sin embargo, existen otros factores igual de importantes como el de
reutilización, robustez, extensibilidad, etc., que no deben olvidarse.
La necesidad de emplear una verificación por pruebas (testing) tanto del
comportamiento, como de la funcionalidad de un producto software
(performance), requiere en los momentos actuales del uso de prototipos, lo que
denota el factor experimental como uno de los más influyentes en el diseño.
Es la etapa de mantenimiento la que verifica en la realidad del usuario la
usabilidad y practicidad del software.
La retroalimentación que se produce al usar prototipos, determina el método de
validación y verificación del software. Pero no es determinante el uso de los
mismos como premisa en el desarrollo del software.
Esta escuela de pensamiento es reconocida en la literatura del software a
inicios de los años 80s.
MANTENIMIENTO
VALIDACIÓN Y
VERIFICACIÓN
INTEGRACIÓNIntegración de todos los módulos codificados
independienetmente
Verificación por pruebas de la consistencia con la
definición
Modificación al Software por fallos, errores,
cambios, etc.
El modelo CVDS cambia en su concepción, mientras la tecnología de
desarrollo del software avanza.
La denominada filosofía de desarrollo [*Kybele] aplicada al diseño del software se
ve reflejada en los factores que determinan la “calidad del software”.24
3.2.7. Análisis de resultados y elaboración de conclusiones
En la IC se trata de contrastar la hipótesis planteada al comienzo de la
investigación con los resultados obtenidos de ésta. Se debe comprobar hasta
24 Por una parte se consideran cualidades tales como la velocidad o la facilidad de uso, cuya presencia o ausencia en un producto de software puede ser
detectada por sus usuarios. Estas propiedades pueden ser denominadas factores de calidad externos....
...Otras cualidades aplicables a un producto de software, como la modularidad, legibilidad son factores internos, perceptibles sólo por los profesionales de la
informática que tienen acceso al código fuente.
En última instancia, sólo importan los factores externos. Si se usa un navegador Web o se vive cerca de una planta nuclear controlada por computadora,
importa poco que el software sea legible o modular si los gráficos tardan años en cargarse o si la introducción de datos erróneos hace explotar la planta. La
clave para obtener los factores externos radica en los internos; para que los usuarios disfruten de las cualidades visibles, los diseñadores y los
implementadores deben aplicar técnicas internas que aseguren las cualidades ocultas.” [Mey 99, p. 3]
qué punto se han cumplido los objetivos, en qué medida se han podido resolver
y que otros nuevos problemas han surgido como consecuencia de la
investigación, los cuales pasarán a ser puntos de partida de nuevas
investigaciones.
Análisis de Resultados y
elaboración de conclusiones
El desarrollo del software se caracteriza por su concepción dinámica, por lo que
equivaldría a contrastar con el usuario hasta qué punto se han cumplido sus
expectativas y analizar si es posible realizar alguna mejora, aunque incluso no
hubiera sido tenida en cuenta al inicio del proyecto.
La experiencia adquirida en la actualidad en el desarrollo de la IS, manifiesta
que el proyecto cambia en el transcurso de su desarrollo por la tendencia del
usuario a requerir más funcionalidad del software.
Esta idea pone de manifiesto la complejidad del desarrollo de software, siendo
necesario considerar que el producto software no se ejecuta de forma aislada,
como podría darse en el campo de la IC.
El software interactúa necesariamente con información procesada por el
usuario mediante el uso de las tecnologías de la información y comunicación
(TIC) dentro del negocio.
3.2.8. Redacción del informe final
Consiste en la redacción del informe en el que se expone paso a paso, la
investigación realizada. En él se detalla: hipótesis, método de investigación,
conclusiones, bibliografía y cualquier otro dato que se considere de relevancia
para la comprensión y evaluación del trabajo realizado.
Redacción del Informe Final
Paralelamente, en el desarrollo del software, al finalizar un proceso productivo
es indispensable dejar documentado el mismo.
Adicionalmente a la documentación y artefactos generados a lo largo del
proceso de desarrollo que incluye (requisitos de usuario, modelos, diagramas y
el mismo código fuente) se incluirán manuales de usuario y una guía
especificando tanto la funcionalidad del producto, como sus limitaciones, en
especial una descripción del método seguido durante el desarrollo.
Al finalizar la investigación, el cuerpo de conocimientos iniciales se ha
modificado (en general se habrá ampliado).
Al finalizar el desarrollo de un producto software, el conocimiento inicial del
cliente a cerca de lo que puede obtener en base a dicho producto se habrá
modificado (en general, se habrá ampliado) y los problemas de los que se
partió inicialmente ya no serán los mismos. Algunos se habrán solucionado,
otros se habrán modificado (reduciéndose o no) y aparecerán, además, nuevos
problemas fruto de la implantación del software desarrollado.
Nuevo cuerpo de
conocimientos
Nuevo
Problema
Tabla 2 Comparativa de los métodos en cada Etapa [*Kybele]
ETAPAS MÉTODO DE
INVESTIGACIÓN EN CIENCIAS DE LA IS
MÉTODO DE DESARROLLO DE
SOFTWARE
E0: Documentación
Problema a resolver Método de investigación
Dominio de la aplicación Metodologías, técnicas,
herramientas, etc. E1:
Determinación del problema
Estudio de campo Delimitación del problema
Análisis de dominio. Captura de requisitos
E2: Creación de
hipótesis
Descripción del objeto a construir
Especificación de requisitos
E3: Definición del
Método
Selección del paradigma (cualitativo, cuantitativo, etc.)
Selección del método (experimental, investigación
en acción, etc.) Adaptación al problema
(técnicas de experimentación, marcos de validación, etc.)
Selección del paradigma (estructurado, OO, etc.)
Selección del método (XP, RUP, etc.)
Adaptación al problema (técnicas que se utilizarán,
notación, etc.)
E4: Resolución, validación y verificación
Casos de estudio, creatividad.
Casos de prueba Prototipo herramienta.
Investigación en acción.
Casos de estudio, creatividad
Juego de pruebas (test) Prototipo
E5: Análisis
Contrastación de hipótesis Contrastación de requisitos
de usuario E6:
Informe Final Hipótesis, métodos, conclusiones, etc.
Requisitos, manual de usuario, etc.
3.3. Conclusiones a la comparación por paralelismo y analogía
Para poder establecer el paralelismo entre los métodos de desarrollo de
software y la investigación científica aplicada a la IS, se ha partido de un
razonamiento por analogía, en vista de que la IS además de ocuparse de la
creación (de nuevas técnicas y métodos), tiene similitudes importantes con la
aplicación misma de la IS, que también se ocupa de la creación (de nuevos
productos software).
Este primer objetivo específico alcanzado, tiene por finalidad esbozar el modelo
que se estudia a continuación (en el punto siguiente) para determinar una
documentación coherente al proceso de investigación aplicado al desarrollo del
documento de tesis de grado, cuando su temática se refiera al diseño de un
producto software.
Ahora bien, por muy extendida que esté en la actividad discursiva del hombre
la comparación, no constituye de por sí, una inferencia lógica.
La comparación sólo prepara las condiciones para que, basándose en ella,
pueda realizarse una inferencia.
El término “analogía” en la lógica, se utiliza no solo a la mera comparación o al
paralelismo existente entre dos objetos, sino a un determinado tipo de
razonamiento.
Se llama razonamiento por analogía al que se efectúa cuando dos objetos tienen
semejantes partes de sus caracteres y de ello se infiere que probablemente
tienen semejantes los caracteres restantes, hallados ya en un objeto, pero
todavía no en el otro (implicación).
De ahí que toda conclusión por analogía ha de ser comprobada y mientras no
lo sea, deberá considerarse simplemente como probable.
La comprobación del paralelismo existente entre el método de investigación
científica y el método de desarrollo del software es respaldada por los trabajos
emprendidos por el IEEE y el proyecto SWEBOK al igual que la experiencia del
Grupo Kybele de España.
Por otro lado, para poder establecer este paralelismo, se analizó en forma
externa el proyecto SITEDI y se comparó su proceso general de desarrollo de
software (modelo CVDS), con el modelo propuesto por Mario Bunge que refleja
los pasos que se deben seguir en toda investigación científica.
Aunque estos pasos están basados en el método hipotético-deductivo, por su
generalidad, son aplicables, con ciertas modificaciones, a cualquier tipo de
investigación.
Sin embargo, es necesario destacar que el modelo CVDS por etapas, refleja en
su concepción, las fases del proceso productivo del software generalmente
aceptadas en todos los modelos CVDS existentes en el mercado.
Este razonamiento lógico permite establecer una guía sobre la
esquematización del documento entregado como Tesis de Grado acorde a los
estatutos internos de la UTECI.
