Fundamentos de investigación-Unidad 3 -actividad 2 - Marco Teórico de la investigación.
Unidad 3 -actividad 2 - Marco
Teórico de la investigación.
A continuación se describe el marco teórico (Hernández Sampieri, 2013) 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)."
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.
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.
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) .
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
Stepanek, G.
(2005). Sofware Proyect Secrets: Why software proyects Fail. Berkeley California:
Apress Berkeley.
Comentarios
Publicar un comentario