Modelado de negocio

Con esta disciplina se pretende llegar a un mejor entendimiento de la organización donde se va a implantar el sistema de software. Los principales motivos para ejecutar esta disciplina son los siguientes: asegurarse de que el producto será algo útil y no un obstáculo; conseguir que se ajuste de la mejor forma posible en la organización donde se va a implantar; y tener un marco común para el equipo de proyecto, los clientes y los usuarios finales. Esta disciplina no será siempre necesaria. Si sólo se añaden funcionalidades que no verán los usuarios directamente, no hará falta. Los objetivos específicos del modelado de negocio son:

• Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.

• Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo en su mejora.

• Entender el problema actual en la organización objetivo e identificar potenciales mejoras.

• Entender la estructura y la dinámica de la organización para la cual el sistema va a ser desarrollado (organización objetivo).

Para lograr estos objetivos, el modelado de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un Modelo de Casos de Uso del Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia para la definición de los requerimientos del sistema.

La importancia de esta disciplina radica en que sin el panorama completo del alcance del negocio y sin el entendimiento de sus procesos no podrán identificarse las necesidades inmediatas de mejora y continuidad relativa a las actividades relacionadas con los sistemas informáticos, que son el producto final del desarrollo.

Evaluar el estatus del negocio

Esta actividad busca evaluar la situación actual del negocio y fijar los objetivos de modelado del negocio.

Su flujo de trabajo detallado es el siguiente:

Visión del negocio

Muchos documentos que sirven para este artefacto podrían encontrarse ya elaborados dentro de la organización, de ser así no es necesario volver a trabajar en general estos, se puede hacer referencia dentro del documento de visión del negocio a estos.

Este artefacto describe los objetivos principales del proyecto, funcionalidades y restricciones en forma concisa; es un resumen del proyecto apto para la toma de decisiones, ofrece una descripción del sistema a ser desarrollado desde la perspectiva de los requerimientos más importantes. Este documento captura las expectativas de los que soportan el desarrollo del proyecto.

Este documento describe los objetivos del esfuerzo de un modelado de negocio. Proporciona la entrada al proceso de aprobación del proyecto. Comunica el por qué y el qué relacionado al proyecto y es una medida contra las cuales deben validarse todas las decisiones futuras.

El empleo completo o parcial de este artefacto está sujeto al propósito del sistema que se desea desarrollar:

• Creación de un negocio: consiste en aplicar ingeniería al negocio para crear un nuevo proceso de negocio, una nueva línea de negocio o una nueva organización.

• Reingeniería del negocio: reingeniería es la revisión fundamental y el rediseño radical de procesos del negocio para alcanzar mejoras satisfactorias en medidas críticas y actuales de rendimiento, tales como costos, calidad, servicio y rapidez. El objetivo es hacer las tareas que ya se están haciendo, pero hacerlo mejor, trabajar más inteligentemente.

• Mejoras al Negocio: consiste en aplicar ingeniería al negocio para mejorar algunos procesos locales y que no afectan al negocio entero.

Se recomienda aplicar este documento en su totalidad si lo que se va a realizar es una creación de un negocio o una reingeniería del negocio. Si el propósito es realizar mejoras al negocio se recomienda que se utilice este artefacto, pero no en su totalidad sino enfocándose en las secciones de introducción, Posición y objetivos del modelado del negocio.

Necesidades del Cliente

La calidad del software debe ser construida desde el comienzo, no es algo que puede ser añadido después. Para que el producto final sea de calidad, el proceso por medio del cual éste es elaborado debe ser también de calidad.

Para nadie es un secreto que muchas empresas de desarrollo de software, siguen pensando que el proceso de las pruebas se debe realizar en la última etapa para consolidar la calidad de su producto, equivocarse no es un problema si el coste del error es bajo, sin embargo, cuanto más tarde se detecten los errores, más esfuerzo se requiere para solucionarlos. 

La posibilidad de que aparezca un error humano en el proceso de desarrollo de software es enorme. La identificación de los riesgos es de suma importancia, ya que permitirá concentrarse en los fallos que se pueden llegar a materializar en cada fase del desarrollo del software.

El impacto de los errores de software va mucho más allá del coste de su reparación. La reducción de ingresos, las oportunidades de mercado perdidas, los pedidos tramitados incorrectamente y los errores de facturación, son factores que hacen perder dinero a la empresa. De ahí que la insatisfacción de los clientes sea el coste que más impacto tiene para las compañías de desarrollo de software.

Esta situación es mucho más fácil de comprender cuando visualizamos como un “bug” puede agigantarse frente a la percepción de nuestros clientes y en la línea de costos asociados a solventarlo. Fallas en las fases de concepción y diseño – por ejemplo- pudieran percibirse como errores de bajo impacto en la calidad y en los costos. Pero cuando el “bug” solo es detectado en ciclos como el de prueba o incluso en el lanzamiento, su impacto es inmenso. Tal como lo ejemplifica la siguiente empleada en un reciente post, en el que se advierte sobre la importancia de no permita que los errores entren a los entornos de producción.

 

Hablar de calidad del software implica que contemos con parámetros que permitan establecer los niveles mínimos que un producto de este tipo debe alcanzar para que se considere de calidad. El problema es que la mayoría de las características que definen al software no se pueden cuantificar fácilmente; generalmente, se establecen de forma cualitativa, lo que dificulta su medición, ya que se requiere establecer métricas que permitan evaluar cuantitativamente cada característica dependiendo del tipo de software que se pretende calificar.

Conseguir software de calidad es algo muy complejo que implica no sólo una alta calificación de los profesionales encargados del desarrollo, sino también la existencia de flujos de trabajo orientados a la calidad por parte de la empresa. De modo que cuando hablamos de la calidad del software a nivel de empresa, nos referimos a las acciones que se toman de forma común para asegurar que se desarrolla software de calidad en todos los proyectos.

Un software de calidad compromete la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y pruebas que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

En resumen, la calidad software viene determinada por la calidad del proceso con el que se desarrolla. Teniendo un proceso definido y aplicando mejoras sobre este proceso, podremos incrementar la calidad de nuestros productos continuamente. 

Mejorar la calidad del software no es algo que sucede una vez y queda ahí para siempre, ni tampoco es cuestión de realizar un drástico cambio en el proceso de desarrollo y pensar entonces que el problema de la calidad ha quedado definitivamente resuelto. Se trata de entender la calidad como la satisfacción de las necesidades del cliente en el plazo y presupuesto adecuado, evolucionando cada vez más hacia un concepto de valor global aportado al cliente en términos de servicio.