12.1 Tipos de procesos
Cualquier empresa que desee mejorar la calidad del producto que entrega a su cliente, debe revisar el proceso que utiliza para generarlo, de otra manera sólo estará esperando mejorar un resultado de forma fortuita. El problema con el proceso del software es que agrega una dimensión que no se presenta en otro tipo de industria. Chemuturi (2010) ofrece el siguiente ejemplo:
Los productos en otras industrias pueden hacer lo que se espera que hagan o bien no lo hacen. Un automóvil puede correr o no correr, pero no vuela. En cambio, en el desarrollo del software, además de la funcionalidad esperada, puede incluso realizar funciones maliciosas que no se esperaban, como robo de información.
Proceso de software
Es posible llegar a un mismo resultado cuando se realizan los mismos pasos. En muchos procesos, cualquier variación puede arrojar diferentes resultados. Piensa por ejemplo en la elaboración de un pastel, si no sigues la receta tal y como te la propone un chef, no esperes tener un delicioso pastel.
Documentar un proceso tiene algunos beneficios para la organización. Chemuturi (2010) propone los siguientes:
- Dan una idea a los directores ejecutivos de cómo se realizó el trabajo.
- Permiten realizar un análisis a los expertos en la materia, que les ayuda a identificar lagunas en el proceso, así como mejorar la calidad y la productividad.
- Facilitan la programación y planificación del trabajo.
- Ayudan a descubrir oportunidades para la automatización.
- Facilitan el desarrollo de estándares para los métodos de trabajo, así como para sus componentes.
Los procesos relacionados con el desarrollo del software han sido considerados como un trabajo creativo y por esa razón ha sido difícil poder incluir metodologías de control de calidad que se han aplicado con éxito en los procesos industriales de manufactura. Es como tratar de comparar el proceso que sigue un pintor de arte al que sigue un robot al pintar un automóvil. Este ha sido el motivo por el que la industria del software ha presentado grandes variaciones en sus productos. Sin embargo, tras revisar el proceso que hay en cada fase de la elaboración de un sistema de cómputo, se ha podido demostrar que los problemas en la calidad del software se pueden resolver mejorando el mismo proceso, aplicando mejores herramientas y un adecuado entrenamiento del personal. Siguiendo con Chemuturi (2010), para alcanzar un proceso de calidad en el desarrollo de software que no se limite a la detección de errores por inspección o pruebas del código, se deben seguir estos tres pasos:
Haz clic en cada paso para conocer más detalle
Detallando un poco más el proceso de mejora del software, puedes observar el siguiente diagrama de flujo:
Recuperado de Chemuturi, M. (2010). Mastering Software Quality Assurance. EEUU: J. Ross Publishing.
Procesos del desarrollo de software
Según Chemuturi (2010), las organizaciones dedicadas a la construcción del software tienen los siguientes procesos básicos:
Procesos de ingeniería de software
- Estos procesos determinan cómo debe ser construido el software. Están conformados por los procesos de gestión de requerimientos, diseño, construcción e implementación.
Procesos de aseguramiento de la calidad
- Son procesos que tienen que ver con la calidad del producto final, entre ellos están los procesos de verificación, validación, inspección, medición y análisis, y auditorías.
- Estos procesos definen la forma en la que el resto de los procesos deben ser administrados: administración de proyectos, planeación, estimación del software, gestión de la configuración, administración de recursos, gestión de las expectativas del cliente y cierre de proyectos.
- Incluyen todos aquellos procesos que ofrecen algún servicio a la organización: procesos de recursos humanos, reclutamiento, infraestructura de red y sistemas, y apoyo técnico.
¿Cuál proceso te llama más la atención? ¿Qué proceso desearías enfocar en tu carrera profesional?
12.2 Confiabilidad del software
Vivimos en una sociedad que utiliza objetos que son controlados por software, desde los más comunes como las televisiones, celulares, lavadoras, relojes, hasta los más complejos como los automóviles, aviones, satélites, etc. Incluso en muchas ocasiones has puesto tu propia vida a merced de estos objetos sin darte cuenta pues confías que realizarán adecuadamente el trabajo. Sin embargo, la realidad es que el software presenta deficiencias, tal y como lo hace el hardware que lo contiene, particularmente porque en su fabricación interviene el ser humano que por naturaleza es imperfecto y puede cometer errores. Desafortunadamente este tipo de errores puede costar dinero y poner en riesgo la vida de las personas.
Imagen obtenida de http://nssdc.gsfc.nasa.gov/image/spacecraft/mars_polar_lander.jpg Sólo para fines educativos
“El elemento humano es crucial en el desarrollo de software, y no es una exageración decir que el mayor costo en el desarrollo de software se gasta en los seres humanos” (Chemuturi, 2010).
El vuelo 2904 de Lufthansa (1993) tuvo un accidente al aterrizar a una velocidad mayor a la estándar que provocó que el avión no pudiera detenerse antes de terminarse la pista de aterrizaje. El ala izquierda tocó el terraplén, lo que generó un incendio en la cabina de pasajeros. Este problema se debió a un error del software en los controles del avión.
En 1999, el vehículo Polar Lander falló al apagar sus motores 40 metros antes de tocar la superficie de Marte, debido a que el software identificó erróneamente las vibraciones en una de las piernas del vehículo; el choque provocó la pérdida total del mismo. Estos han sido casos que han provocado graves pérdidas, y eso constituye una de las principales preocupaciones de los organismos de seguridad gubernamental y de las empresas, por contar con software confiable libre de defectos.
Un software confiable es aquel que realiza sus funciones de manera diligente durante su vida útil, la cual depende de la vida del hardware que lo contiene. Si el software mantiene un rendimiento sin defectos, podrías afirmar que es confiable. El principal problema que tiene el software para seguir siendo confiable, es que requiere de frecuentes mantenimientos por las siguientes causas:
- Adaptarse a las necesidades cambiantes del usuario.
- Poder mejorar la seguridad de la información.
- Adaptarse a las modificaciones del sistema operativo, cambios de configuración o de algunas utilerías.
- Posibles ajustes a defectos que aún no han provocado daños al cliente.
Causas de las fallas en el software
De acuerdo con Chemuturi (2010), las fallas al software pueden ser causadas principalmente por fallas en el diseño, codificación, problemas del aseguramiento de la calidad y fallas en los datos.
Haz clic en cada falla para conocer la información
El software puede tener fallas en el diseño que fueron provocadas por errores, ambigüedades, omisiones, suposiciones incorrectas, mala interpretación de los requisitos o especificaciones, el mal funcionamiento de las herramientas de terceros que no fueron suficientemente probadas, cambios inesperados en la plataforma del hardware, errores del diseño de pruebas y validación de requisitos, normas o estándares impuestos por entidades externas a la organización.
El mismo proceso de codificación es también uno de los principales problemas que provoca fallas o defectos en el software, y se debe a errores de omisión, estructuras de código ineficientes, prácticas poco limpias del programador, problemas de la conversión numérica de variables, uso de patrones o algoritmos inadecuados o ineficiencia en el uso de memoria.
Realizar actividades de manera ineficaz en relación al QA del software se pueden hacer pasar por alto defectos que afecten al usuario, por ejemplo una inadecuada verificación y/o validación, utilizar personas con poca experiencia durante las pruebas, fallas al diseñar un caso de prueba o al verificar sus resultados o establecer métricas poco adecuadas para medir la calidad del producto del software.
Hacer uso de datos incorrectos sin duda provocará errores en el software, por ejemplo, si el software utiliza una fuente de información errónea, los datos se encuentran dañados, datos maestros incorrectos o con errores, problemas en la precisión de los datos, problemas provocados por falta de integridad o inconsistencia en los datos.
12.3 Procesos confiables
De acuerdo con Sommerville (2011), las empresas desarrolladoras buscan diseñar procesos de software confiables para producir un software confiable, es decir, tratan de enfocarse en el uso de técnicas de desarrollo adecuadas, un proceso de documentación y acciones de QA, con la esperanza de tener mejores posibilidades de producir un software de calidad que cumpla con las expectativas del cliente y con menos errores. Para considerar que un proceso de software es confiable debe cumplir con las siguientes características:
Característica del proceso |
Descripción
|
| Documentable |
El proceso debe tener un modelo de proceso definido que establezca las actividades en el proceso y la documentación que debe producirse durante dichas actividades. |
| Estandarizado |
Tiene que estar disponible un conjunto amplio de estándares de desarrollo de software que cubren la producción y la documentación del software. |
| Auditable |
El proceso debería ser comprensible para los individuos y los participantes del proceso, quienes pueden verificar el seguimiento de dichos estándares de proceso y hacer sugerencias para la mejora del proceso. |
| Diverso |
El proceso debe comprender actividades de verificación y validación redundante y diversa. |
| Robusto |
El proceso tiene que recuperarse de fallas de actividades de proceso individual. |
Recuperado de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación.
En algunas ocasiones, contar con evidencia de haber construido un producto de software mediante un proceso confiable, permite cumplir con los requisitos regulatorios de entidades de seguridad o auditorías externas de sistemas. Los procesos confiables tienen una definición explícita y son repetibles, es decir, siguen un modelo específicamente diseñado para generar un software de calidad y además es posible mantener la calidad de cualquier producto en el que trabajen, independientemente de las personas que estén involucradas, porque dependen de la ejecución de las tareas del proceso en lugar del criterio, interpretación o juicio de las personas.
Actividades de los procesos confiables
Si deseas diseñar un proceso confiable de software, será necesario que consideres las siguientes actividades:
- Realizar una revisión exhaustiva del documento de especificaciones de requerimientos por todos los involucrados. Este documento expresa las necesidades y solicitudes del usuario, y determinará los criterios que se utilizarán para evaluar el producto de software. Esta revisión debe buscar que los requerimientos estén completos, redactados sin ambigüedades y consistentes.
- Establecer un mecanismo de control de cambios a los requerimientos del usuario. Si el equipo técnico involucrado y los stakeholders conocen la forma en la que se pueden realizar cambios, es posible tener una base homogénea para gestionarlos. El control de cambios incluye desde la forma en la que se solicitan, analizan sus riesgos e impactos, aprueban, negocian, documentan e implementan.
- Se documenta el diseño del sistema. El diseño y arquitectura del sistema deben ser documentados haciendo uso de modelos gráficos, diagramas UML y casos de pruebas. Estos documentos deben ser analizados y entendidos por el equipo técnico de desarrollo. Es importante que el trabajo de diseño tenga una vinculación con cada uno de los requerimientos del sistema.
- Establecer un estándar de codificación en el que el desarrollador realice un pequeño plan, recopile la información necesaria, documente el diseño del programa, lo implemente, documente los resultados de sus pruebas unitarias y lo ponga a disposición para inspeccionarlo por una entidad ajena a su organización.
- Se lleva a cabo un plan de verificación y validación. Se verifica que el software no tenga defectos y se valida que el producto realice lo que se espera.
Como puedes observar, estas actividades están enfocadas a las actividades relacionadas con la construcción del software hasta ponerlo en producción para el usuario. Las actividades posteriores a la implementación deben ser parte del monitoreo del desempeño del producto.
Procesos de arquitecturas confiables
El diseño de la arquitectura del software es un proceso que también debe realizarse pensando en generar un producto confiable. Eso significa utilizar patrones arquitectónicos tolerantes a las fallas que incluyan mecanismos y componentes redundantes.
Imagina un sistema utilizado para operar aeronaves, todos los controles críticos para operar un avión deben de tener un mecanismo alterno que permita corregir un mal funcionamiento. Si el control del tren de aterrizaje falla, el piloto debe tener alguna alternativa de operación si su juicio determina que el sistema no está respondiendo de forma adecuada. Las arquitecturas redundantes pueden ser implementadas duplicando la capacidad de cómputo; por ejemplo, en un sistema es posible colocar una réplica del servidor principal, de tal manera que un servidor secundario se encuentre realizando las mismas tareas que el principal, este servidor entraría en operación en una situación eventual, en la que el servidor principal debe de funcionar. Esta redundancia en la infraestructura implica necesariamente mayores gastos operativos, por lo que sólo se utilizan para las operaciones más críticas para el negocio.
Sistemas de protección
Los sistemas de protección son aquellos que monitorizan eventos o estados específicos de un sistema. Si aparece un evento o cambio de estado no esperado que ponga en riesgo la operación del sistema, toman el control del sistema principal para colocarlo en un estado seguro; por ejemplo, la activación de los frenos de un tren que se acerca a gran velocidad a una estación en la que se supone debe detenerse. Si el tren llega a una sección de la vía a una velocidad superior a la requerida, entra un sistema de protección que aplica los frenos de manera automática, evitando así cualquier posible desastre.
Para que la arquitectura de los sistemas de protección sea eficaz, debe ser independiente de la infraestructura de producción y sólo contiene la funcionalidad crítica que protege, por lo que suelen ser más sencillos.
Según Sommerville (2011), el software de control del transbordador espacial tiene un sistema de respaldo que incluye la funcionalidad “llevar a casa”, si falla el sistema de control principal, el sistema de respaldo logrará aterrizar el vehículo.
Arquitectura de un sistema de protección.
Recuperado de Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson Educación.
