Fundamentos de investigación - Unidad 1 - Actividad 3

UnADM Unidad 1 Actividad 3 / Problemas abiertos de desarrollo desoftware.

Tipos de problemas de software

De acuerdo a (Ortiz Herrera, 2010), (Stepanek, 2005) hay 12 tipos de problemas desoftware:

1. El software es complejo2. El software es abstracto3. Los requerimientos son incompletos4. La tecnología cambia rápidamente5. Las mejores prácticas no están suficientemente maduras:6. La tecnología es un dominio muy vasto7. La experiencia en tecnología es incompleta8. El desarrollo de software implica investigación9. El trabajo repetitivo es automatizable10. En realidad, la construcción es diseño11. Los cambios se consideran fáciles12. El cambio es inevitable

Según (Ortiz Herrera, 2010), (Stepanek, 2005) estos problemas afectan a todos losproyectos de Desarrollo de Software.Complejidad del 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 demillones. Además, la complejidad de un programa no depende sólo del número deinstrucciones (sentencias) que se ejecutan, sino también de las interacciones entre dichasinstrucciones, haciéndolo aún más complejo, ya que cada iteración puede ser diferente alas previas¨.

(Ortiz Herrera, 2010), (Stepanek, 2005)

Según (Booch, 1998) la complejidad de los sistemas de software se deriva de cuatroelementos:

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 software4. Los problemas de caracterizar el comportamiento de sistemas discretos.

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 sistemascomputacionales, 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 inclusocomprender los requerimientos como: facilidad de uso, rendimiento, costo, capacidad desupervivencia, fiabilidad, son parte de la complejidad externa que infieredeterminantemente en la complejidad interna del sistema. Bajo este contexto nace laimportancia de la relación entre desarrolladores y usuarios del sistema. Habitualmente losusuarios suelen tener dificultades en expresar sus necesidades e ideas. Esto se da enocasiones por falta de conocimiento del ámbito de cada uno de los grupos. Los usuarios ylos desarrolladores tienen perspectivas diferentes sobre la naturaleza del problema.Contar con herramientas que permitan plasmar estos requisitos de forma clara paraambos 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 darun mantenimiento óptimo a los programas. Cuando los equipos de desarrollo son grandesy heterogéneos la administración de las actividades se hace complicada debido a que sedesarrollan por muchos equipos de trabajo. Hoy en día, tanto el hardware como elsoftware, deben ser capaces de contar con una arquitectura abierta, reusabilidad, facilidadde reconfiguración, aplicación de estándares y diseño modular. Estas característicaspermiten escribir menos códigos y poder reutilizar el software, en un software diferente alque fue diseñado originalmente. La adición debe ser transparente para el sistemareceptor”.

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 procesostriviales y complejos del conocimiento humano en un sistema computacional. Estapropiedad no debe producir cambios en los procedimientos y prácticas de las entidades. Elsistema debe ser suficientemente flexible para incorporarse a las actividades de lasentidades 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 laaplicación. Al ejecutarse el software en computadoras digitales, se tiene un sistema conestados discretos. En contraste, a los sistemas analógicos (vgr. El movimiento de unapelota lanzada al aire) son sistemas continuos. Parnas sugiere que “cuando se afirma queun sistema se describe con una función continua, quiere decir que no puede contenersorpresas ocultas. Pequeños cambios en las entradas siempre producirán cambiosconsecuentemente pequeños en las salidas”. Por el contrario, los sistemas discretos por supropia naturaleza tienen un número finito de estados posibles. Todos los eventos externos aun sistema de software tienen la posibilidad de llevar a ese sistema a un nuevo estado, ymás aún, la transición de estado a estado no siempre es determinista. En las peorescircunstancias, un evento externo puede corromper el estado del sistema, porque susdiseñadores olvidaron tener en cuenta ciertas interacciones entre eventos”.

(Booch, 1998) , (Allende Hernández, 2002)

Tres problemas abiertosLos 3 problemas que me interesan más son:

1. La complejidad del dominio del problema2. La dificultad de gestionar el proceso de desarrollo3. Los problemas de caracterizar el comportamiento de sistemas discretos.

Técnicas de investigación para resolver los problemas ya descritos.

Considerando las descripciones dadas por los autores (Allende Hernández, 2002), (Booch,1998), (Ortiz Herrera, 2010), (Stepanek, 2005) los problemas de interés se podrían abordarde la siguiente forma:

La complejidad del dominio del problemaEsto se podría abordar con una investigación cualitativa, al tratarse sobre todo de unproblema de comunicación entre los usuarios y clientes y los programadores. Elinvestigador debe de entender el ambiente (las herramientas y las organizaciones dedicadasa crear software), las ideas, y las expectativas de ambos grupos para poder proponer unanueva solución intentando cubrir el mayor grupo posible de soluciones para ambos.

La dificultad de gestionar el proceso de desarrollo.Esto se podría abordar de forma mixta, porque se pueden investigar de forma cuantitativaal medir cuantas líneas de código se escriben para ser reusables, o que se ahorran usandolibrerías o productos pre existentes. También se podría abordar de forma cualitativa alentender las prácticas o procedimientos que resultan en mayores ahorros de códigosescritos.

Los problemas de caracterizar el comportamiento de sistemas discretosEsto se podría abordar de forma mixta, debido a que la complejidad se puede medirnuméricamente. Por ejemplo usando las cantidades de líneas de código por función omodulo del software.

También se puede abordar de forma cualitativa al estudiar las prácticas que incrementan lacomplejidad cuantitativa de software y proponer algunas nuevas prácticas que la reduzcan.

BibliografíaAllende Hernández, O. (2002). La tecnología orientada a objetos y la ingeniería de software ante lacomplejidad inherente al software. Temas de ciencia y tecnología. Obtenido dehttp://www.utm.mx/temas/temas-docs/nfnotas217.pdf

Booch, G. (1998). Análisis y Diseño Orientado a Objetos. . Massachusetts, E.U.A: Addison WesleyLongman.

Ortiz Herrera, M. (2010). e-REdiNG Trabajos y proyectos fin de estudios E..T.S.I. Obtenido deUniversidad de Sevilla:http://bibing.us.es/proyectos/abreproy/70193

Stepanek, G. (2005). Sofware Proyect Secrets: Why software proyects Fail. Berkeley California:Apress Berkeley.