Todas las fases de la Ing. de Software son importantes?

Introducción

La Ingeniería de Software es todo lo que necesitamos hacer para producir software exitoso. Incluye los pasos para tomar una idea en bruto y convertirla en una poderosa e intuitiva aplicación que puede ser mejorada para ajustarse a las necesidades cambiantes del cliente en los años venideros.

La Ingeniería de software es importante ya que incluye técnicas para evitar las diversas trampas que podrían hacer que nuestro proyecto fracase. La Ingeniería de Software nos proporciona la flexibilidad de hacer cambios que cumplan las demandas inesperadas (algo que sucede muy a menudo), sin tener que completamente destruir nuestros tiempos de entrega y limitaciones de presupuesto.

Etapas comunes en la Ingeniería de Software

• Requerimientos y negociación del proyecto. El software siempre forma parte de un contexto más grande, que puede ir desde una empresa hasta un sistema. El trabajo comienza estableciendo requisitos de todos los elementos del sistema, y asignando al software algún subgrupo de estos requisitos. Uno de los primeros pasos en un proyecto de software es descubrir y entender los requerimientos: 1) Qué necesita el cliente, 2) Cuándo lo necesita,  y 3) Cómo lo necesita. También deben fijarse los objetivos, metas, procedimientos y reglas, así como desarrollar estrategias, políticas, planes del proyecto, etcétera.
• Estimación y planeación del proyecto. Identificar el equipo de trabajo (físico y humano), así como establecer fechas, entregables y costos. De igual forma debe identificarse y agrupar las funciones, actividades y tareas del proyecto. Seleccionar y crear posiciones organizacionales. Definir responsabilidades y autoridades, así como definir el perfil de cada puesto.
• Análisis y diseño orientado a objetos. En general, la actividad del diseño se refiere al establecimiento de las estructuras de datos, la arquitectura general del software, representaciones de interfaz y algoritmos. El proceso de diseño traduce requisitos en una representación de software. Dentro del proceso de análisis es fundamental que a través de una colección de requerimientos funcionales y no funcionales, el desarrollador o desarrolladores del software comprendan completamente la naturaleza de los programas que deben construirse para desarrollar la aplicación, la función requerida, comportamiento, rendimiento e interconexión. Lo que hace el análisis y programación orientado a objetos es representar y agrupar elementos en clases que son óptimas para reutilizarse y darles mantenimiento.
• Diseño de interfaces. El proceso de diseño de la interfaz se basa en tomar en cuenta cuidadosamente las características de la población objetivo, y en crear modelos preliminares que posteriormente son ajustados y modificados en base a las recomendaciones y observaciones que hagan los usuarios finales.
• Arquitectura de software. El diseño de la arquitectura del software se refiere a la estructura global del software y las maneras en que esa estructura proporciona integridad conceptual a un sistema. De acuerdo con Pressman, en su forma más simple, la arquitectura es la estructura jerárquica de los módulos del programa, la manera de interactuar de estos componentes, y la estructura de los datos usados por estos módulos.
• La codificación y su control.  Esta actividad consiste en traducir el diseño en una forma legible por la máquina. El control implica monitorear los avances y asegurar el apego a los requerimientos.
• Fases de pruebas. Una vez que se ha generado código, comienzan las pruebas del software o sistema que se ha desarrollado. De acuerdo con Pressman, el proceso de pruebas se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales, es decir, la realización de las prueba para la detección de errores.
• Aseguramiento de la calidad. Que un código se encuentre libre de errores no asegura la calidad, ya que la calidad es la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente. Es decir que la calidad estará relacionada al cumplimiento de las expectativas del cliente plasmadas en los requerimientos. Para esto las pruebas funcionales nos ayudarán a identificar si existen fallas en la calidad que deben ajustarse.
• Liberación y mantenimiento. La liberación es la puesta en marcha del software, y aunque podría ser una tarea sencilla, la mayoría de las veces implica otras muchas actividades más allá de la instalación del software, tales como configuración de equipos o redes, entrenamiento a los usuarios, migración y/o sincronización de datos, etcétera. El software indudablemente sufrirá cambios, y habrá que hacer algunas modificaciones a su funcionalidad. Es de suma importancia que el software de calidad pueda adaptarse con fines de acoplarse a los cambios de su entorno externo. Durante su periodo de vida, un software efectivo estará en constante evolución, generalmente añadiendo nuevas funcionalidades.

Reflexión

• ¿Considera que todas las fases son indispensables?  

Ciertamente todo el proceso de Ingeniería de Software puede parecer un poco aburrido, principalmente para los desarrolladores. La razón es que la gran mayoría de los desarrolladores solo están interesados en codificar. Es por esto que si nos cerramos solamente al proceso que más nos gusta o en el que tenemos mayor participación, podemos fácilmente pensar que las demás etapas no son importantes y pueden ser desechadas. La verdad es que cada fase cumple un propósito específico y de vital importancia para la realización de un proyecto exitoso.

Otro punto a considerar es que si pensamos en proyectos muy pequeños, podríamos omitir algunos pasos y aun así seríamos capaces de realizarlos sin mayor complicación, pero en donde la importancia de cada etapa es más evidente, es en los grandes proyectos.

Es por eso que considero que todas las fases son indispensables para asegurar la correcta y exitosa ejecución del proyecto de software.

• ¿Hay alguna fase que se pueda saltar o no incluir?

Si pensamos en un proyecto pequeño, de interés personal, podríamos eliminar varios puntos como la negociación, ya que el proyecto es para nosotros mismos, y alomejor no es tan indispensable una planeación formal, ni la recolección de requerimientos, ya que todo eso está en nuestra propia mente. En este caso somos nuestro propio cliente, y el proceso puede simplificarse.

Sin embargo, en un proyecto profesional, no es recomendable omitir ninguna de estas fases, ya que hacerlo va a generar grandes impactos negativos en el proyecto. No se debería saltar ni omitir ninguna fase. Es importante mencionar que diversas fases pueden ejecutarse al mismo tiempo, en caso de que se estuviera pensando en omitir alguna por falta de tiempo.

• ¿Qué pasaría si no se incluyera la fase de aseguramiento de la calidad?

Si esto llegara a ocurrir sería algo terrible, ya que esta fase es la encargada de asegurar que el producto desarrollado se apega a los requerimientos, y todas las expectativas y necesidades del cliente (las identificadas, documentadas, y acordadas) han sido cumplidas. La calidad es, a mi consideración, una característica crítica para asegurar el éxito del proyecto, la satisfacción del cliente y la continuidad de las relaciones de negocio futuras.

• ¿Cómo lo lleva a cabo o lo aplica en su ámbito laboral?

Dentro de mi ámbito laboral trabajamos con una metodología de desarrollo ágil llamada Scrum. Trabajamos en iteraciones de tres semanas en las que desarrollamos ciertas funcionalidades solicitadas por nuestro cliente. En este proceso logro identificar la ejecución de las fases descritas en la Ingeniería de Software de la siguiente manera:

• Requerimientos y negociación del proyecto: Contamos con un Product Owner que representa los intereses del cliente y controla el Product Backlog que es la lista de funcionalidades pendientes de implementar y ordenadas por prioridad. También contamos con un Scrum Master que nos ayuda a coordinar los esfuerzos del equipo y guiarnos. El Product Owner recolecta los requerimientos del cliente, los prepara y los pone en el Product Backlog. El equipo, junto con la ayuda del Scrum Master se reúne con el Product Owner al inicio de cada iteración para elegir y planear las tareas que se van a trabajar. Aquí se hace una negociación en cuanto a qué tareas son prioridad para el Product Owner y cuántas puede el equipo comprometerse a entregar.
• Estimación y planeación del proyecto. Después de elegir las Historias a desarrollar, el equipo realiza su descomposición en tareas específicas. También se hace la valoración del esfuerzo asignando puntos de acuerdo a su complejidad, y se reparten las tareas de la forma más conveniente para una óptima utilización de recursos.
• Análisis y diseño. El diseño ocurre de diferentes maneras durante la iteración y depende del tipo de tareas a desarrollar. A veces se realizan diseños de interfaces, de base de datos, o de arquitectura. El equipo coordina con los encargados de cada área para la revisión de los diseños.
• Codificación. Los desarrolladores codifican enfocados en TDD (Test Driven Development), lo que implica crear pruebas unitarias antes de la funcionalidad. Esto para reducir la posibilidad de errores, y asegurar el cumplimiento de los requerimientos. También se hace uso de Code Reviews y Peer Programming.
• Pruebas y aseguramiento de la calidad. Adicionalmente a las pruebas unitarias del desarrollador, se realizan Code Reviews, que consisten en que el líder técnico hace una revisión de los cambios realizados, para identificar posibles errores, sugerir mejoras, o asegurar el uso de los estándares y mejores prácticas. A parte de eso existe un proceso formal para la liberación del código a producción, que demanda la aprobación del Tester de que los cambios han sido probados exitosamente en el ambiente de desarrollo y en el ambiente de pruebas.
• Liberación. Tenemos un proceso de liberación con fechas establecidas a nivel organizacional para que todos los equipos puedan liberar sus cambios a producción. Las liberaciones se hacen cada dos semanas, pero existe un calendario que especifica en qué fecha el código debe estar listo para pruebas, cuándo la aprobación de los Tester debe estar lista, y cuando el código debe estar mezclado con el de los demás para hacer pruebas de integración. En caso de no cumplir con las fechas, el cambio se descarta y se pospone para la siguiente liberación.
• Mantenimiento. Contamos con un área de mantenimiento y soporte a producción que se encarga de darle seguimiento a los nuevos cambio introducidos para asegurar que funcionen correctamente en producción, o tomar acciones de restauración de versiones anteriores en caso de que los nuevos cambios causen conflictos.

Referencias Bibliográficas

• Beginning Software Engineering

Rod Stephens

Wrox (2015)

• Ingeniería del Software, Un Enfoque Práctico.

Pressman, Roger

Editorial McGraw-Hill, Cuarta edición (1998)