Fundamentos de investigación-Unidad 4 -actividad 2 – Diseño de investigación.
Unidad 4
-actividad 2 – Diseño de investigación.
A continuación se describe el marco teórico (Hernández Sampieri, 2013) , el objetivo y el
diseño de mi investigación acerca de la complejidad del software.
Complejidad
del Software
Según (Stepanek, 2005) la complejidad es uno de los mayores
problemas de ingeniería de software. Según (Ortiz Herrera, 2010) la complejidad del
software se define así:
¨Un pequeño programa, fácilmente puede
ejecutar decenas de miles de líneas de código, otros más importantes, como las
últimas versiones de Microsoft Windows, decenas de millones. Además, la
complejidad de un programa no depende sólo del número de instrucciones
(sentencias) que se ejecutan, sino
también de las interacciones entre dichas instrucciones, haciéndolo aún más
complejo, ya que cada iteración puede ser diferente a las previas¨.
Según (Booch, 1998) la complejidad de
los sistemas de software se deriva de cuatro elementos:
1. La
complejidad del dominio del problema,
2. La
dificultad de gestionar el proceso de desarrollo,
3. La
flexibilidad que se puede alcanzar a través del software
4. Los
problemas de caracterizar el comportamiento de sistemas discretos.
A continuación se definirán los cuatro elementos
mencionados.
La complejidad del dominio del problema.
Según (Allende Hernández, 2002) este problema se
define así:
¨Cuando
los problemas del mundo real se desean resolver con modelos de sistemas
computacionales, trae consigo una cantidad indefinida de requisitos que
compiten entre sí y algunas veces se contradicen. Dar funcionalidad a un
sistema es difícil e incluso comprender los requerimientos como: facilidad de
uso, rendimiento, costo, capacidad de supervivencia, fiabilidad, son parte de
la complejidad externa que infiere determinantemente en la complejidad interna
del sistema. Bajo este contexto nace la importancia de la relación entre
desarrolladores y usuarios del sistema. Habitualmente los usuarios suelen tener
dificultades en expresar sus necesidades e ideas. Esto se da en ocasiones por
falta de conocimiento del ámbito de cada uno de los grupos. Los usuarios y los
desarrolladores tienen perspectivas diferentes sobre la naturaleza del
problema. Contar con herramientas que permitan plasmar estos requisitos de
forma clara para ambos grupos es uno de los retos de la Ingeniería de
Software¨.
La dificultad de gestionar el proceso de desarrollo.
De acuerdo a (Allende Hernández, 2002) este problema se
define así:
“La
mayoría de los grandes sistemas contienen un alto número de código que impide
dar un mantenimiento óptimo a los programas. Cuando los equipos de desarrollo
son grandes y heterogéneos la administración de las actividades se hace
complicada debido a que se desarrollan por muchos equipos de trabajo. Hoy en
día, tanto el hardware como el software, deben ser capaces de contar con una arquitectura
abierta, reusabilidad, facilidad de reconfiguración, aplicación de estándares y
diseño modular. Estas características permiten escribir menos códigos y poder
reutilizar el software, en un software diferente al que fue diseñado
originalmente. La adición debe ser transparente para el sistema receptor”.
La flexibilidad que se puede alcanzar a través del software.
En (Allende Hernández, 2002) este problema se
define así:
“El software ofrece la flexibilidad al desarrollador
para expresar y representar procesos triviales y complejos del conocimiento
humano en un sistema computacional. Esta propiedad no debe producir cambios en
los procedimientos y prácticas de las entidades. El sistema debe ser
suficientemente flexible para incorporarse a las actividades de las entidades y
hacerlas más eficientes, sin causar gastos que eleven el precio de los sistemas“
Los problemas de caracterizar el comportamiento de sistemas discretos.
De nueva cuenta (Allende Hernández, 2002) define esto así:
“En una aplicación de gran tamaño puede haber
cientos o hasta miles de variables, así como más de un flujo de control. El
conjunto de todas estas variables, sus valores actuales, y la administración
del sistema son procesos que constituyen el estado actual de la aplicación. Al
ejecutarse el software en computadoras digitales, se tiene un sistema con
estados discretos. En contraste, a los sistemas analógicos (vgr. El movimiento
de una pelota lanzada al aire) son sistemas continuos. Parnas sugiere que
“cuando se afirma que un sistema se describe con una función continua, quiere
decir que no puede contener sorpresas ocultas. Pequeños cambios en las entradas
siempre producirán cambios consecuentemente pequeños en las salidas”. Por el
contrario, los sistemas discretos por su propia naturaleza tienen un número
finito de estados posibles. Todos los eventos externos a un sistema de software
tienen la posibilidad de llevar a ese sistema a un nuevo estado, y más aún, la
transición de estado a estado no siempre es determinista. En las peores
circunstancias, un evento externo puede corromper el estado del sistema, porque
sus diseñadores olvidaron tener en cuenta ciertas interacciones entre eventos”.
En (SG Buzz equipo de editores, 2017) aparecen las
siguientes definiciones de complejidad de software:
¨Podemos hablar de dos vistas de la complejidad de un producto
de software: la externa, que tiene que ver con el problema que resuelve el
sistema (el proceso de negocio); y la interna, que se refiere a la manera como
está programada la solución¨.
Siguiendo esta división la complejidad externa del
software corresponde a los tres primeros criterios de Booch, mientras que la complejidad interna
corresponde al cuarto elemento. También en dicha referencia se distinguen dos
aspectos de la complejidad interna de un software:
· Tamaño. Entre más grande sea un
programa, mayor será su complejidad. Una métrica de tamaño primitiva, pero
común es la cantidad de líneas de código (LCs).ya sea en total o por función o
módulo.
· Estructura. Esto se refiere a la
cantidad de posibles caminos de ejecución que tenga un programa, módulo o
función.
En esta investigación
nos vamos a centrar en la complejidad interna de un software.
¿Cómo se mide la complejidad del software?
En (Pressman, 2010) Roger Pressman cita a
(Fenton, 1991) dando un concepto de medición en
ingeniería de software:
¨
Medición es el proceso mediante el cual se asignan números o símbolos a los
atributos de las entidades en el mundo real, de manera que se les define de
acuerdo con reglas claramente determinadas [...] En ciencias físicas, medicina,
economía y más recientemente en ciencias sociales, ahora es posible medir
atributos que anteriormente se consideraban inmensurables [...] Desde luego,
tales mediciones no son tan refinadas como muchas mediciones en las ciencias
físicas [...], pero existen [y con base en ellas se toman decisiones
importantes]. Sentimos que la obligación de intentar “medir lo inmensurable”
para mejorar la comprensión de entidades particulares es tan poderosa en la
ingeniería del software como en cualquiera otra disciplina¨.
Según (Sáez Vacas, 1992) las
métricas son la forma de conocer y controlar la complejidad de un programa:
Las métricas de complejidad
del software serán el primer eslabón de la cadena que puede llevarnos a
controlar esa complejidad. Nos dan una base objetiva para identificar
estructuras y técnicas que nos lleven a producir programas de menor (o mayor)
complejidad. También nos permiten identificar zonas de un programa
especialmente complejas, que sería conveniente rediseñar, y donde probablemente
se centren los problemas que aparecerán en la fase de mantenimiento.
Normalmente, cuanto más complejo sea un programa, más difícil será su
mantenimiento posterior (más propenso a fallos que habrá que arreglar, mayor
dificultad de realizar cambios, etc.).
Medidas, métricas e indicadores
En (Pressman, 2010) se afirma que los términos medida,
medición y métrica tienen sutiles diferencias entre ellos.
· Medida:
proporciona un indicio cuantitativo de la extensión, cantidad, dimensión,
Capacidad o tamaño de algún atributo de un producto o proceso.
o
Ejemplo:
Cuando se ha recolectado un solo punto de datos por ejemplo, el número de
errores encontrados dentro de un solo componente de software, se crea una
medida.
· Medición:
es el acto de determinar una medida. La medición ocurre como resultado de la
recolección de uno o más puntos de datos.
o
Por
ejemplo: algunas revisiones de componente y pruebas de unidad
se investigan para recolectar medidas del número de errores de cada uno. Las
mediciones generalmente son soportadas u obtenidas por herramientas o programas
dedicados a eso.
· Métrica: El IEEE
Standard Glosary of Software Engineering Terminology (IEEE editores, 1993) define métrica como
“una medida cuantitativa del grado en el que un sistema, componente o proceso
posee un atributo determinado”.
o
Ejemplo:
Una métrica de software relaciona en alguna forma las medidas individuales para
producir una evaluación compuesta. Ejemplo de esto podría ser las líneas
totales de código de un programa.
·
Indicador:
el objetivo de recolectar medidas y desarrollar métricas es que se obtengan
indicadores. Un indicador es una métrica o combinación de métricas que
proporcionan comprensión acerca del proceso de software, el proyecto de
software o el producto en sí. Un indicador permite al líder del proyecto o a
los ingenieros de software ajustar dicho proceso, el proyecto o el producto
para mejorarlos.
¿Qué nos permite saber dichas métricas de complejidad de
software?
Dichas métricas nos permiten saber que tan propenso es un software a tener bugs, pero no solo eso sino también que tan
difícil será elaborarlo. Con respecto a esto (Sáez Vacas, 1992) dice:
Además, al analizar mediante métricas las
especificaciones y los primeros documentos del diseño, podemos estimar de una
forma más exacta el tiempo de desarrollo (Booch, 1990) , o predecir con
bastante aproximación la complejidad que tendrá el código (Selig & Henry, 1990) . Parece, por lo
dicho hasta aquí, que las métricas son muy útiles. Pero ¿qué es lo que
realmente miden las métricas? Según Mills y Dyson (Mills & Dyson, 1990) , "las métricas
[de complejidad del software] son simplemente medidas cuantitativas de ciertas características
de un proyecto de desarrollo. Pueden medir alguno de los siguientes objetos:
·
Productos (como el código o la documentación).
·
El proceso de desarrollo como tal (aspectos de las
actividades del desarrollo).
·
El dominio del problema (como las telecomunicaciones, los
sistemas de tratamiento de información, y el control de procesos).
·
Las características ambientales (como las personas, las
organizaciones y las herramientas)."
Software libre
Debido al interés de esta investigación en la
complejidad interna del software, se hace necesario acceder a software del cual
tengamos código fuente. Los ejemplos más accesibles son programas de software
libre.
Según Richard Stallman (Stallman, 2004) , el software libre se define así El
«software libre» es una cuestión de libertad, no de precio. Para comprender
este concepto, debemos pensar en la acepción de libre como en «libertad de
expresión» y no como en «barra libre de cerveza». Con software libre nos
referimos a la libertad de los usuarios para ejecutar, copiar, distribuir,
estudiar, cambiar y mejorar el software.
También según Stallman el software libre se caracteriza por cuatro
libertades:
· Libertad 0: la
libertad para ejecutar el programa sea cual sea nuestro propósito.
· Libertad 1: la
libertad para estudiar el funcionamiento del programa y adaptarlo a tus
necesidades —el acceso al código fuente es condición indispensable para esto.
· Libertad 2:
la libertad para redistribuir copias y ayudar así a tu vecino.
· Libertad 3:
la libertad para mejorar el programa y luego publicarlo para el bien de toda la
comunidad —el acceso al código fuente es condición indispensable para esto.
Bugs de software
Según (Pressman, 2010) los defectos o Bugs
de software se definen así:
En el contexto del proceso del software, los
términos defecto y falla son sinónimos. Los dos implican un problema de calidad
descubierto después de haberse liberado el software a los usuarios finales (o a
otra actividad estructural del proceso del software). En capítulos anteriores
se empleó el término error para denotar un problema de calidad descubierto por
ingenieros de software (o de otra clase) antes de entregar el software al usuario
final (o a alguna actividad estructural del proceso del software).
También según
Pressman uno de los objetivos de
ingeniera de software es encontrar los errores antes de que se conviertan en
defectos, debido a que el costo de los defectos es mayor que el de los errores
encontrados antes de liberar el software y no solamente en términos de esfuerzo en ingeniería, sino
que también de reputación y credibilidad del producto.
Objetivo
En esta
investigación nos centraremos en definir la complejidad interna de los
productos de software, es decir la complejidad del código o la documentación,
en particular recabando
definiciones probadas o aceptadas en la
industria basadas en métricas. Una vez definidas las métricas de interés se
aplicaran sobre ejemplos de software libre o
de código abierto para hacer un análisis comparativo.
Se favorecerán
aquellas definiciones que posean métricas claras y precisas, así como herramientas de software
libre o accesible de forma gratuita para su extracción. Así como ejemplos de
software libre donde se tenga información disponible acerca de sus fallos
La razón de escoger
herramientas de software libre o gratuito
es para utilizarlas sin restricciones en ejemplos de software real
utilizado por la industria.
Justificación
·
De
acuerdo con (Booch, 1990) entender la
complejidad nos permite estimar de una
forma más exacta el tiempo de desarrollo. Lo cual puede resultar en
ganancias de tiempo, dinero y esfuerzo si
se sabe utilizar las definiciones
adecuadas de complejidad para cada aspecto del desarrollo.
·
También
entender la complejidad del código
permite saber que partes de un programa
o software son más susceptibles a bugs (Ortiz Herrera, 2010) , especialmente si se
usan herramientas que automaticen la medición de dicha complejidad. En el presente los bugs de software son todavía unos de los problemas más graves y comunes
del software (Sáez Vacas, 1992) , (Stepanek, 2005) .
Alcance
Esta investigación tendrá un alcance Correlacional. Se intenta demostrar
la relación entre las métricas de complejidad y los Bugs o fallos encontrados
en el software.
Diseño de investigación
Esta investigación es mixta de enfoque dominante
CUAN-cual. Las fases de esta investigación son:
Fase cualitativa
1. Investigación cualitativa usando el método fenomenológico para definir los
conceptos de complejidad y las métricas de interés en la literatura.
2. Definición de métricas a recabar:
se escogerán las métricas que sean aplicables al software que se utilizará como
ejemplo, y que tenga herramientas para su extracción.
3. Definición de software de ejemplo:
se escogerán programas de código abierto disponible en el internet, para los cuales
sea posible extraer la información de interés.
Fase cuantitativa
1. Extracción de los datos:
se obtendrá el software libre de ejemplo, para
su instalación y se adecuara para extraer las métricas. Las cuales se
recabaran para su análisis posterior.
2. Análisis
de los resultados: se compararán las métricas obtenidas de los ejemplos con
la lista de Bugs conocidos intentando
encontrar las correlaciones entre ellos.
3. Conclusiones:
se presentarán los resultados del análisis matemático de los resultados.
Bibliografía
Allende Hernández, O. (2002). La tecnología orientada a
objetos y la ingeniería de software ante la complejidad inherente al
software. Temas de ciencia y tecnología. Obtenido de
http://www.utm.mx/temas/temas-docs/nfnotas217.pdf
Booch, G. (1990).
Work-product analysis: the philosopher's stone of software? IEEE Software, 26-34.
Booch, G. (1998). Análisis
y Diseño Orientado a Objetos. . Massachusetts, E.U.A: Addison Wesley Longman.
Fenton, N. E.
(1991). Software Metrics: A Rigorous Approach. Londres, Reino Unido: Chapman
& Hall, Ltd.
Hernández Sampieri, R.
(6 de junio de 2013). El marco teórico. Obtenido de youtube:
https://www.youtube.com/watch?v=TH9YF3Y2GDE
IEEE editores.
(1993). Standard Glossary of Software Engineering Terminology. IEEE.
Mills, H., &
Dyson, P. (Marzo de 1990). Using Metrics to Quantify Development. IEEE Software., 15-16. Obtenido de
http://trace.tennessee.edu/cgi/viewcontent.cgi?article=1056&context=utk_harlan
Ortiz Herrera, M.
(2010). e-REdiNG Trabajos y proyectos fin de estudios E..T.S.I.
Obtenido de Universidad de Sevilla:
http://bibing.us.es/proyectos/abreproy/70193
Pressman, R. S. (2010).
Ingeniería del software: un enfoque práctico. Ciudad de México:
McGraw-Hill Interamericana.
Sáez Vacas, F. (1992). Complejidad
y Tecnologías de la Información. Madrid: Instituto Tecnológico Bull.
Obtenido de http://dit.upm.es/~fsaez/intl/libro_complejidad/
Selig, C., & Henry,
S. (Marzo de 1990). Predicting Source-Code Complexity at the Design Stage. IEEE Software, 7, 36-44.
SG Buzz equipo de
editores. (2017). SG Buzz. Obtenido de
https://sg.com.mx/content/view/691
Stallman, R. (2004). Software
libre para una sociedad libre. (T. d. Sueños, Ed.) Madrid, España,
España: Free Software Foundation. Obtenido de https://www.gnu.org/philosophy/fsfs/free_software2.es.pdf
Stepanek, G.
(2005). Sofware Proyect Secrets: Why software proyects Fail. Berkeley California:
Apress Berkeley.
Comentarios
Publicar un comentario