Métodos de Ingeniería de Software

...

Grandes empresas a nivel mundial utilizan buenas prácticas de software como Amazon, Apple Computers, Google, IBM, Microsoft y Unisys, por nombrar las más reconocidas, para poder dimensionar la importancia de aplicar y aprender a usar estas buenas prácticas, que no tan solo ayudan de forma teórica dentro del curso de métodos de ingeniería de software, sino también la comprensión de las metodologías de trabajo que utilizan estas grandes empresas podrán aportar e implementarse a futuro de una forma más práctica en el entorno laboral.

CAPÍTULO 2: PRÁCTICAS DE INGENIERÍA DE SOFTWARE

En la ingeniería de software el desarrollo de un proceso de software, tiene un enfoque flexible que permite al equipo buscar y decidir el conjunto de acciones y tareas más apropiadas para realizar de la mejor manera el proyecto. Siempre se busca entregar el software en el tiempo decidido, con el menor costo y con la mayor funcionalidad y valor para el cliente. El proceso de software está compuesto por actividades que ayudan a dar forma a la estructura que se desea del proyecto, los cuales son descritos a continuación:

- Comunicación: Antes de comenzar el desarrollo del proyecto y durante este mismo es importante conversar y colaborar en conjunto con el cliente para comprender de mejor forma los objetivos de los participantes respecto al proyecto.

- Planeación: Es importante desarrollar un camino para el equipo de software por medio de las tareas técnicas a realizar, los posibles riesgos, los recursos necesarios, los productos que se obtendrán y una programación de las actividades.

- Modelo: El ingeniero crea modelos para comprender y visualizar mejor los requerimientos del software y el diseño que los cumplirá.

- Construcción: El equipo de desarrollo comienza la generación manual o automatizada de código, además de las pruebas necesarias para descubrir los errores del software.

- Despliegue: Se entrega el software terminado o un incremento funcional al cliente, el cual lo evalúa y genera un feedback al equipo.

Dependiendo del tamaño del proyecto el equipo evalúa si se puede realizar todo en un solo ciclo o si es necesario desarrollarlo de forma iterativa con entregas incrementales del producto a medida que avanza el proyecto.

Otro punto importante en la práctica de ingeniería de software son los principios propuestos por David Hooker, los cuales son siete principios que se centran en la práctica de la ingeniería de software como un todo, y se enumeran a continuación: (Pressman, 2010)

- Primer principio: “La razón de que exista todo”

Un sistema de software existe por una razón: dar valor a sus usuarios. Todas las decisiones deben tomarse teniendo esto en mente. Antes de especificar un requerimiento del sistema, antes de notar la funcionalidad de una parte de él, antes de determinar las plataformas del hardware o desarrollar procesos, plantéese preguntas tales como: “¿Esto agrega valor real al sistema?” Si la respuesta es “no”, entonces no lo haga. Todos los demás principios apoyan a éste.

- Segundo principio: “MSE (Mantenlo sencillo, estúpido…)”

Todo diseño debe ser tan simple como sea posible, pero no más. Esto facilita conseguir un sistema que sea comprendido más fácilmente y que sea susceptible de recibir mantenimiento, lo que no quiere decir que en nombre de la simplicidad deban descartarse características o hasta rasgos internos. En realidad, los diseños más elegantes por lo general son los más simples. La recompensa es un software más fácil de mantener y menos propenso al error.

- Tercer principio: “Mantener la visión”

Una visión clara es esencial para el éxito de un proyecto de software. Sin ella, casi infaliblemente el proyecto terminará siendo un ser “con dos o más mentes”. Comprometer la visión de la arquitectura de un sistema de software debilita y, finalmente hará que colapsen incluso los sistemas bien diseñados. Tener un arquitecto que pueda mantener la visión y que obligue a su cumplimiento garantiza un proyecto de software muy exitoso.

- Cuarto principio: “Otros consumirán lo que usted produce”

Rara vez se construye en el vacío un sistema de software con fortaleza industrial. En un modo u otro, alguien más lo usará, mantendrá, documentará o, de alguna forma, dependerá de su capacidad para entender el sistema. Así que siempre establezca especificaciones, diseñe e implemente con la seguridad de que alguien más tendrá que entender lo que usted haga. La audiencia para cualquier producto de desarrollo de software es potencialmente grande. Elabore especificaciones con la mirada puesta en los usuarios. Diseñe con los implementadores en mente. Codifique pensando en aquellos que deben dar mantenimiento y ampliar el sistema. Alguien debe depurar el código que usted escriba, y eso lo hace usuario de su código. Hacer su trabajo más fácil agrega valor al sistema.

- Quinto principio: “Abrase al futuro”

Un sistema con larga vida útil tiene más valor. En los ambientes de cómputo actuales, donde las especificaciones cambian de un momento a otro y las plataformas de hardware quedan obsoletas con sólo unos meses de edad, es común que la vida útil del software se mida en meses y no en años. Sin embargo, los sistemas de software con verdadera “fortaleza industrial” deben durar mucho más tiempo. Para tener éxito en esto, los sistemas deben ser fáciles de adaptar a ésos y otros cambios. Los sistemas que lo logran son los que se diseñaron para ello desde el principio. Nunca diseñe sobre algo iniciado. Siempre pregunte: “¿qué pasa si…?” y prepárese para todas las respuestas posibles mediante la creación de sistemas que resuelvan el problema general, no sólo uno específico. Es muy posible que esto lleve a volver a usar un sistema completo.

- Sexto principio: “Planee por anticipado la reutilización”

La reutilización ahorra tiempo y esfuerzo. Al desarrollar un sistema de software, lograr un alto nivel de reutilización es quizá la meta más difícil de lograr. La reutilización del código y de los diseños se ha reconocido como uno de los mayores beneficios de usar tecnologías orientadas a objetos. Sin embargo, la recuperación de esta inversión no es automática. Para reforzar las posibilidades de la reutilización que da la programación orientada a objetos, se requiere reflexión y