Yadira Pérez Agusti

Licenciada en Información Científico Técnica y Bibliotecología. Dirección de Desarrollo. Empresa DESOFT S. A. Cuba.

El desarrollo científico y tecnológico de la primera mitad del siglo XX permitió acumular avances que provocaron que a mediados de esta centuria y coincidiendo con el fin de la Segunda Guerra Mundial, emergieran amplios campos del conocimiento como la computación y las ciencias de la información.

]]> La computación como herramienta y la información como portador del conocimiento dieron lugar a la información digital, que apoyada en el desarrollo de las Nuevas Tecnologías de la Información, modificó la sociedad y acrecentó como nunca antes el consumo de este recurso, convertido en imprescindible para el mejoramiento humano y que se ha extendido a nivel social para crear una interdependencia a escala global que se autogenera día a día, y que ofrece nuevas posibilidades de desarrollo en todas las esferas de la vida.

A nivel organizacional, estos avances han llevado a la empresa moderna a un contexto donde se produce una gran sobrecarga de información digital, a menudo irrelevante, falsa, obsoleta o sencillamente inoportuna, que va más allá de su ámbito de control y que, lejos de proporcionarle poder, la puede conducir por caminos marcadamente erróneos. El poder entonces, no lo establece la posesión de grandes volúmenes de información digital, sino de aquella de valor, que una vez evaluada y analizada, sea veraz, precisa, actualizada y relevante; de aquella que pueda estructurarse, recuperarse y compartirse, en el momento y lugar oportuno, a cualquier nivel administrativo, operativo o gerencial, según se requiera como base para la toma de decisiones y de aquella que pueda introducirse con seguridad en la actividad de la organización para mejorar sus procesos, su desempeño y reducir sus costos.

Desafortunadamente, el matrimonio ideal entre información y comunicación no se ha conseguido con el uso de los sistemas automatizados de información, debido a la existencia de una serie significativa de fallos, incumplimientos, problemas de calidad y presupuestos sobregirados en el desarrollo de estos, que llevan a que las organizaciones no puedan disponer de la calidad requerida de ellos para sus servicios, toda vez que estos últimos dependen de la idoneidad de la información que debe brindar el producto automatizado.

MODELADO DE NEGOCIO Y GESTIÓN DE REQUISITOS

Esta situación ha llevado a comprender que, debido a la complejidad y exigencia de los procesos a automatizar, se requiere de grandes cambios en el proceso de producción de los software y se ha hecho imprescindible la práctica de nuevos métodos, que permitan coordinar, supervisar y establecer el trabajo en equipo entre el grupo de desarrollo de cada proyecto de software y sus clientes, como vía para lograr que los requisitos identificados sean viables, adecuados y permitan decidir, con el mayor por ciento de exactitud posible, qué se desea y qué es posible automatizar en definitiva.

Estas prácticas se hacen efectivas por medio de las etapas de Modelado del negocio y Gestión de requisitos, las fases primarias del proceso de desarrollo de un sistema automatizado. En general, cada vez, existe un reconocimiento mayor de su importancia y los riesgos en que se incurre si estas se cumplen de manera incorrecta o insuficiente. Son estas actividades las que definen la dirección y el alcance del proyecto y se realizan según los intereses de la entidad encargada del desarrollo del producto final, es por ello que, amén de la existencia de metodologías reconocidas, -como RUP (Rational Unified Process), algunas organizaciones dedicadas a la actividad de informatización han creado metodologías propias internas según sus intereses de captura de información. ]]>

Con el modelado de negocio se logra "conocer" la organización: misión, funciones, estructura, expertos, tecnología, debilidades, fortalezas; comprender el entorno en el que va a funcionar el sistema, identificar sus procesos, la información, los actores participantes en dichos procesos y los papeles que representan cada uno de ellos, con respecto a cada porción de la información.

Una vez identificados los procesos -flujo de actividades para producir un resultado de valor, es posible determinar su viabilidad, si son los correctos o si necesitan alguna modificación, claro, sin llegar a un análisis tan amplio como el que pudiera comprender una consultoría de procesos. Igualmente, es posible determinar la localización de la información; si existe duplicidad en ella; así como el acceso innecesario a la información que no corresponde o la carencia de otra que sí es necesaria; se puede conocer también la responsabilidad de cada actor -función que asume una persona, sistema o entidad que interactúa con el sistema- con respecto a la información que utiliza para realizar su actividad laboral y el rol -conjunto de funciones, normas, comportamientos y derechos definidos para un cliente registrado- que desempeña en el sistema.

La gestión de requisitos se identifica actualmente como una muy buena práctica que contribuye, como ninguna otra, al éxito de los proyectos de software, al posibilitar un entendimiento común entre el cliente y el grupo de desarrolladores de los requisitos del cliente que deben concebirse en el producto final, la comprensión de los problemas que se necesitan solucionar y las posibles vías de resolverlos. Asimismo, esta etapa se considera y se ha demostrado que es una de las más difíciles de todo el proceso de ingeniería de software y que, de ser errada, más afecta la construcción del sistema y más difíciles son de corregir los problemas resultantes.

Es en este paso donde se establece la especificación preliminar de los requisitos funcionales y no funcionales; así como los casos de uso de los procesos que se desean automatizar: constituye el documento legal primario para el diseño y construcción de la aplicación futura. Asimismo, los procesos, informaciones, actores y roles se relacionan con las funciones que van a desempeñar en el sistema a desarrollar.

Un requisito funcional se define como una característica requerida por el cliente para solucionar un problema o conseguir un objetivo. Es lo que el cliente le solicita al sistema, porque es lo que necesita. Los requisitos funcionales son descripciones del problema, no de la solución, pertenecen al ámbito del problema. ]]>

Un requisito no funcional, por su parte, es aquel que, no por ser no funcional deja de tener funcionalidad, puede comprometer el funcionamiento del producto desarrollado y permite que el resultado, es decir, el software sea atractivo, usable, rápido; y tiene como premisa que, una vez conocido lo que el sistema debe hacer, se determine cómo ha de comportarse y qué cualidades debe tener este.

Los requisitos no funcionales pueden ser, entre otros:

De apariencia o interfaz externa.

De usabilidad.

De rendimiento.

De soporte.

De portabilidad.

]]> De seguridad.

Legales.

El caso de uso es una técnica para la captura de los requisitos potenciales de un nuevo sistema o la actualización de un software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el cliente o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de uso se evita el empleo de jergas técnicas, y se prefiere en su lugar un lenguaje más cercano al cliente final.¹

El caso de uso es una representación que puede expresarse, por medio de gráficos, de tablas o de descripciones textuales, de las funcionalidades del sistema, referido a los requisitos funcionales, es la explicación de qué funcionalidad se llevará a cabo y la relación de esta con los actores participantes en el sistema.

Es importante resaltar que ninguna de estas expresiones están pensadas para representar el diseño, por ello no describen los elementos internos de un sistema; únicamente sirven para facilitar la comunicación con el cliente y resultan útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los casos de uso describen qué es lo que debe hacer el sistema y no cómo lo hará.

  ]]> CONSIDERACIONES FINALES

La primera de estas etapas, el modelado de negocio, ofrece una visión general de la organización a la que se le va a desarrollar el sistema automatizado de información mientras que la gestión de requisitos centra su actividad en la especificidad de las informaciones correspondientes a cada proceso a automatizar y la manera en que se van a representar estas, en el producto final y para ello, se apoya en los requisitos funcionales, no funcionales y casos de uso. Igualmente, puede concluirse que el correcto desarrollo de estas etapas resulta imprescindible para la obtención de un producto final de calidad.

REFERENCIAS BIBLIOGRÁFICAS

1. Wikipedia. Caso de uso. Disponible en: http://es.wikipedia.org/wiki/Caso_de_uso [Consultado: 10 de diciembre de 2007].

  ]]>  

Recibido: 19 de febrero de 2008.
Aprobado: 23 de febrero de 2008.

Lic. Yadira Pérez Agusti. Dirección de Desarrollo. Empresa DESOFT S. A. Calle 27 entre Paseo y 2. El Vedado. Código postal: 10 400. Ciudad de La Habana. Cuba. Correo electrónico: yadira.perez@hab.desoft.cu

  ]]>

Ficha de procesamiento

Términos sugeridos para la indización

Según DeCS¹

SISTEMAS DE INFORMACIÓN ]]> INFORMATION SYSTEMS

Según DeCI²

SISTEMAS DE INFORMACIÓN

INFORMATION SYSTEMS

¹BIREME. Descriptores en Ciencias de la Salud (DeCS). Sao Paulo: BIREME, 2004.

Disponible en: http://decs.bvs.br/E/homepagee.htm

²Díaz del Campo S. Propuesta de términos para la indización en Ciencias de la Información. Descriptores en Ciencias de la Información (DeCI). Disponible en: http://cis.sld.cu/E/tesauro.pdf

]]>

Copyright: © ECIMED. Contribución de acceso abierto, distribuida bajo los términos de la Licencia Creative Commons Reconocimiento-No Comercial-Compartir Igual 2.0, que permite consultar, reproducir, distribuir, comunicar públicamente y utilizar los resultados del trabajo en la práctica, así como todos sus derivados, sin propósitos comerciales y con licencia idéntica, siempre que se cite adecuadamente el autor o los autores y su fuente original.

Cita (Vancouver): Pérez Agusti Y. Modelado de negocio y gestión de requisitos como etapas imprescindibles para el desarrollo de los sistemas automatizados de información. Acimed 2008;17(3). Disponible en: http://bvs.sld.cu/revistas/aci/vol17_3_08/aci09308.htm [Consultado: día/mes/año]. ]]>