Auditoría de la adquisición, desarrollo e implementación de sistemas de información

Ciclo de Vida de Desarrollo de Software

Etapas del Ciclo de Vida Tradicional

Muchas compañías utilizan el Ciclo de Vida tradicional para el desarrollo del software. Este ciclo de vida ha sido utiliza- do durante muchos años y es muy probable que un Auditor de Sistemas se tope con este ciclo de vida. El Ciclo de Vida tradicional consta de fases secuenciales, tal como se muestra en la figura 1.

1. Estudio de Factibilidad 2. Requerimientos 3a. Diseño 3b. Adquisición de Software 4a. Desarrollo 4b Configuración 5. Implementación 6. Post- Implementación

Como se puede apreciar en la figura 1, el Ciclo de Vida considera actividades de adquisición de software. Ud. podría preguntarse qué hace la adquisición en un ciclo de vida de desarrollo. Esto es lógico ya que mucho del software ya se encuentra escrito y podría ser muy ventajoso adquirir software en lugar de construirlo.

Ciclo de Vida de Desarrollo de Software I

Estudio de Factibilidad

El estudio de factibilidad es la primera etapa de un ciclo de vida de desarrollo de software. En esta etapa se realizan las siguientes actividades:

• Definir los beneficios tangibles e intangibles del futuro sistema. Los beneficios tangibles siempre están relaciona- dos a dinero e incluyen ahorro de costos, incremento de las ventas, reducción de personal (suena feo, pero es un beneficio tangible), entre otros. Los beneficios intangibles incluyen mejora en los procesos, rapidez en la entrega de productos o servicios, etc.
• Determinar el costo y tiempo aproximado para implementar el sistema. Se debe tener una idea de cuánto costaría y cuánto tiempo podría tomar implementar la solución. Una buena práctica seria formular un Request for Infor- mation (RFI) y enviarlo a proveedores. Este documento solicita a los proveedores que indiquen las capacidades que tienen sus sistemas y nos permite tener una idea inicial de que existe en el mercado y cuánto tiempo y dinero costaría.
• Escribir el Business Case (Caso de Negocio). El Business Case es un documento importante en el que se deben defi- nir las alternativas existentes para implementar el sistema. Por ejemplo un Business Case podría tener 4 alternativas:
  • Mejorar el software existente
  • Desarrollar un nuevo software
  • Adquirir el software del proveedor A
  • Adquirir el software del proveedor B

Dado que se tienen alternativas, se puede tomar una decisión de que alternativa seguir. Recuerde que tomar una deci- sión es seleccionar una alternativa entre varias alternativas posibles.

• Determinar si es necesario desarrollar o adquirir

Ciclo de Vida de Desarrollo de Software: Requerimientos

Requerimientos del Ciclo de Vida

El análisis de requerimientos es la etapa más importante del ciclo de vida (Alguien dijo curso de Ingeniería de Re- querimientos). Dado que el software a construir es intangible (no se puede tocar, no se puede sentir), no es lo mismo construir software que construir un tangible como por ejemplo un edificio.

Muchos de los proyectos de desarrollo de software fracasan por que no se logra un entendimiento claro de los reque- rimientos de los usuarios, por lo que es vital la participación de los usuarios.

En esta etapa se realizan las siguientes actividades:

• Detallar el problema o necesidad que requiere solución.
• Identificar y consultar a todos los interesados para identificar sus requerimientos.
• Identificar los requerimientos funcionales y no funcionales (de calidad, de seguridad, etc.).
• Convertir los requerimientos de los usuarios en requerimientos de sistemas.
• Analizar los requerimientos para detectar y corregir conflictos y determinar prioridades.
• Verificar que los requerimientos están completos, consistentes, probables y rastreables.
• Determinar si se va a desarrollar el sistema o adquirir un sistema ya existente.

Ciclo de Vida de Desarrollo de Software: Diseño

Fase de Diseño

En caso de que se decida desarrollar, entonces la siguiente fase será la de diseño. La fase de diseño solo puede hacerse después de que se tenga definidos claramente los requerimientos.

En esta fase es muy común utilizar algún lenguaje de modelado de software tal como el Unified Modeling Language (UML) para diseñar, especificar, desarrollar y documentar un sistema.

En esta etapa se deben formular las siguientes actividades:

• Especificaciones de los componentes del Sistema
• Especificaciones de las interfaces del Sistema
• Especificaciones de los programas
• Especificaciones de los datos

La fase de diseño es equivalente a realizar un plano en la construcción de un edificio. El plano indica cómo será el edificio. De manera similar en la fase de diseño se construyen los planos para realizar un software. El plano no puede estar cambiando por lo que es imprescindible implementar un procedimiento de control de cambios para prevenir que se creen nuevos requerimientos o se modifiquen los requerimientos sin control.

Ciclo de Vida de Desarrollo de Software: Adquisición

Adquisición del Software

En caso de que se decida no desarrollar, entonces la siguiente fase después de la fase de Requerimientos es la fase de Adquisición del software. Al igual que la fase de Diseño, la adquisición de software solo puede ocurrir después de cerrar la fase de requerimientos, ya que no podemos adquirir un software sin saber lo que necesitamos.

En esta etapa básicamente se prepara el Request For Proposal ( RFP). EI RFP es un documento que contiene todos los requerimientos funcionales y no funcionales que necesitamos adquirir. Asimismo, el RFP contiene los requerimientos técnicos, operacionales y de soporte por parte del proveedor.

El RFP es enviado a todos los proveedores para que puedan enviar sus propuestas. Una vez que se tienen las propuestas se debe comparar las propuestas y seleccionar la propuesta más conveniente. Es común que las propuestas sean evalua- das en función a su peso técnico y económico. Por ejemplo la evaluación técnica puede pesar 70-80% y la evaluación económica puede pesar 20 % - 30 %.

Una vez declarado ganador, se debe firmar el contrato con el proveedor, el cual debe tener las penalidades adecuadas, en caso de un incumplimiento por parte del proveedor.

Ciclo de Vida de Desarrollo de Software: Desarrollo

Fase de Desarrollo

Esta fase es la continuación de la fase de Diseño. Con los documentos de especificaciones de diseño, se realiza la co- dificación utilizando diversos métodos, técnicas y lenguajes de programación. Es muy común que los desarrolladores utilicen ambientes integrados de desarrollo integrado (IDE) que facilitan la programación del código fuente.

En esta etapa se debe considerar las pruebas que garanticen la calidad del software construido. No se puede conceptua- lizar desarrollo sin pruebas. Las pruebas son inherentes al desarrollo (por ese motivo no existe una fase de pruebas).

Una pregunta que se debe hacer en esta fase es: ¿ Cuánto tiempo se le debe dedicar a las pruebas? ¿ Cuál es la relación optima de tiempo entre el desarrollo y las pruebas? Por ejemplo si tomo 1 mes para codificar, ¿Cuánto tiempo se debe estimar para las pruebas? Muchas compañías le dedican el 20% a la codificación y el 80% del tiempo a las pruebas. Eso significa que si se estima un mes para la codificación, se debería tener 4 meses de codificación. Ahora le pregunto ¿Ud. considera que esta bien la relación 20%-80% ¿ Está un poco exagerada? ¿ Será esta la práctica de los desarrollos de software en el país? Lo cierto es cada equipo de desarrollo tiene sus propios estándares. Pero, no dedicarle suficiente tiempo a las pruebas hace que muchos proyectos de desarrollo de software no logran la suficiente calidad, y eso genera muchos riesgos en el ciclo de vida.

Ciclo de Vida de Desarrollo de Software: Tipos de Pruebas

Pruebas a Considerar en el Desarrollo

Entre las pruebas que se deben considerar se tiene:

• Prueba unitaria. Consiste en probar un único programa. Esta es la prueba que los desarrolladores normalmente realizan cuando verifican sus programas.
• Prueba de interface o de integración. Esta prueba verifica que la información fluya correctamente entre varios componentes del software.
• Prueba del sistema. Las pruebas de sistema indican si diversos componentes de un Sistema funcionan de manera colectiva.
• Pruebas de recuperación. Verifican que el software funcione adecuadamente después de una falla de hardware o software.
• Pruebas de seguridad. Verifican la seguridad de un software.
• Pruebas de estrés/volumen. Verifican la performance de un software con grandes volúmenes de datos.
• Pruebas de volumen. Determina el número máximo de transacciones que un software puede procesar.
• Pruebas de Stress. Determina el número máximo de usuarios / servicios que un software puede procesar.
• Pruebas de rendimiento. Compara el rendimiento de un software a otros sistemas equivalentes usando benchmarks definidos.
• Pruebas de aceptación final - User Acceptance Test(UAT). Esta prueba se da en la fase de implementación, donde el usuario aprueba la funcionalidad de un sistema.

Ciclo de Vida de Desarrollo de Software: Pruebas Adicionales

Otros Tipos de Pruebas

Existe un conjunto grande de pruebas. Otro tipo de pruebas incluyen:

• Alfa y beta. Esta prueba es utilizada por los fabricantes de software. La prueba Alfa es una primera prueba interna y el software podría no estar completamente terminado. La prueba Beta es una prueba con el software terminado y enviada a un grupo de usuarios externos para que prueben el software en condiciones reales.
• Piloto. Esta es una prueba para probar una parte específica de un sistema.
• Caja blanca. Evalúa la efectividad del código fuente de un sistema.
• Caja negra. Evalúa la efectividad funcional de un sistema.
• Función/validación. Evalúa la funcionalidad de un sistema contra los requerimientos para verificar que se esté construyendo e software de acuerdo a los requerimientos.
• Regresión. Esta prueba está orientada a probar nuevamente funcionalidades cuando se introducen cambios o co- rrecciones a un sistema. Esta prueba verifica que no hayan impactos no deseados en otras partes del software.
• Paralela. Esta prueba consiste en probar dos sistemas, normalmente el viejo sistema y el nuevo sistema para com- parar los resultados.
• Sociabilidad. Esta prueba consiste en verificar que un cambio en un software no afecta a otros sistemas. Es decir que el sistema "es amigo" de los demás sistemas y no genera conflictos con los otros sistemas.

Todas las pruebas deben ser planificadas y se debe realizar un Plan de pruebas. Las pruebas deben ejecutarse y docu- mentar los resultados de las pruebas. Los errores y fallas deben ser incorporados en el desarrollo.