Proceso de software

Una definición de proceso de software viene dada por (Sommerville, 2005) “Un proceso de software es un conjunto de actividades que conducen a la creación de. un producto software”. Otra definición de viene dada por (Pressman, 2010) el cual indica que es un conjunto de actividades, acciones y tareas que se realizan cuando se va a crear un producto.

No se pude afirmar que haya un proceso de creación de software ideal, cada organización utiliza enfoques para mejorarlos o adecuarlos a su forma de trabajo. A pesar de estas variaciones del proceso, existen actividades fundamentales para todos ellos según (Sommerville, 2005): “especificaciones del software, diseño e implementación del software, validación del software y por último evolución del software”.

2.2.1.1.1. Requerimientos

Una definición de requerimiento detalla que:

Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema y sus restricciones operativas. Estos

21 requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema como el control de un dispositivo, hacer un pedido o encontrar información. (Sommerville, 2005, pág. 108)

La autora (Gómez Fuentes, 2011) afirma que “Los requerimientos especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables”.

o Requerimiento del usuario: “Deben describir los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema sin conocimiento técnico detallado. Únicamente deben especificar el comportamiento externo del sistema y deben evitar, las características de diseño del sistema” (Sommerville, 2005).

o Requerimientos del sistema: “Son versiones extendidas de los requerimientos del usuario que son utilizados por los ingenieros de software como punto de partida para el diseño del sistema. Agregan detalle y explican cómo el sistema debe proporcionar los requerimientos del usuario. Pueden ser utilizados como parte del contrato para la implementación del sistema y, por lo tanto, deben ser una especificación completa y consistente del sistema entero” (Sommerville, 2005).

A menudo los requerimientos se clasifican en funcionales y no funcionales:

o Requerimientos funcionales: “Describen una interacción entre el sistema y su ambiente, describen cómo debe comportarse el sistema ante determinado estímulo o entradas particulares” (Gómez Fuentes, 2011). Es decir, los requerimientos están redactados detalladamente, no debe ser ambiguo o contradictorio, todas las solicitudes deben ser definidas con y por el usuario.

22 o Requerimientos no funcionales: “Describen una restricción a los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, el tipo de proceso de desarrollo a utilizar, fiabilidad, tiempo de respuesta, capacidad de almacenamiento” (Gómez Fuentes, 2011). Se podría decir que son restricciones del software y a menudo son requerimientos que son complicados de cumplir, un ejemplo de eso viene dado como la rapidez del producto, facilidad de uso, fiabilidad, portabilidad, etc.

Lenguaje estructurado de requerimientos

Es una forma estándar de redactar los requerimientos; como (Sommerville, 2005) menciona, “La ventaja de este enfoque es que mantiene la mayor parte de la expresividad y comprensión del lenguaje natural, pero asegura que se imponga cierto grado de uniformidad en la especificación.” En las cuales se pueden usar plantillas, formularios o diagramas para especificar los requerimientos.

Para usar un formulario estándar para especificar requerimientos debe incluir información básica:

▪ Descripción de la función o entidad a especificar.

▪ Descripción de la entrada y el origen de la misma.

▪ Descripción de la salida y el destino de la misma.

▪ Indicar que otras entidades se utilizan.

▪ Indicar si existe una precondición y que debe de cumplir antes de ser ejecutada la función, y si existe una postcondición indicar que se debe ejecutar si se cumple la condición.

▪ Si existe efectos colaterales indicarlos.

23 Al cumplir esta información la variabilidad en la descripción de los requerimientos se reduce y la organización es efectiva; sin embargo, si la redacción de los requerimientos sigue siendo ambigua se puede añadir información adicional utilizando tablas, modelos, gráficos (Sommerville, 2005).

En la Tabla 6 veremos un ejemplo de un formulario de especificación de requerimientos.

Tabla 6

Especificación de requerimientos utilizando un formulario estándar.

Función Calcular la dosis de insulina: nivel de azúcar en la sangre Descripción Calcula la dosis de insulina a suministrar cuando el nivel medio actual del azúcar está en la zona segura entre 3 y 7 unidades.

Entrada Lectura del azúcar actual (r2), las dos lecturas previas (r0 y r1).

Fuente Lectura actual del azúcar del sensor. Otras lecturas de la memoria.

Salida CompDose: la dosis en insulina a suministrar.

Destino Bucle de control principal.

Acción. CompDose es cero si el nivel de azúcar está estable o disminuyendo o si el nivel está aumentando, pero la tasa de incremento disminuyendo. Si el nivel está aumentando y la tasa de incremento disminuyendo, CompDose se calcula dividiendo la diferencia entre el nivel de azúcar actual y el nivel anterior por 4 y redondeando el resultado.

Si el resultado se redondea a cero, se fija el CompDose a la dosis mínima que puede ser suministrada.

Requerimientos Las dos lecturas previas para poder calcular la tasa de cambio de azúcar.

Precondición La reserva de insulina contiene al menos el máximo permitido para una única dosis de insulina.

Postcondición r0 es reemplazada por r1 y r1 es reemplazado por r2.

Efectos colaterales

Ninguno.

Fuente: (Sommerville, 2005, pág. 120) Elaborado: Propio

Documento de requerimientos del software.

(Gómez Fuentes, 2011) afirma en su libro que el estándar IEEE/ANSI 830-1998

“especifica las características que deben tener los requerimientos (correctos, consistentes, completos, realistas, rastreables y verificables) los tipos de

24 requerimientos (funcionales y no funcionales), entre otros”. Este estándar IEEE sugiere la siguiente estructura para los documentos de requerimientos como se muestra en la Figura N° 4:

Figura N° 4 Estructura para el documento de requerimientos del software.

Fuente: (Sommerville, 2005, pág. 125) Elaborado: Propio

2.2.1.1.2. Diseño

El proceso de diseño establece la descripción de la arquitectura del software.

“Tiene el propósito de establecer los aspectos lógicos y físicos de las salidas, modelos de organización y representación de datos, entradas y procesos que componen el sistema, considerando las bondades y limitaciones de los recursos disponibles” (Peña Ayala, 2006) es decir, la forma de cómo se va a cumplir los requerimientos críticos tales como: rendimiento del producto, mantenibilidad, escalabilidad, entre otros, y de cómo se organiza un software y la interacción de sus componentes.

25 A menudo la organización del software se entiende como la estructura que va a tener este por lo cual a continuación se va a mostrar tres estilos de organización ampliamente usados los cuales se pueden usar de manera separada o combinarlas de acuerdo a la magnitud del producto.

Modelo repositorio: “Los sistemas que usan grandes cantidades de datos se organizan alrededor de una base de datos compartida. Por tanto, este modelo es adecuado para aplicaciones en las que los datos son generados por un subsistema y son usados por otro” (Sommerville, 2005, pág. 225).

Modelo cliente – servidor: “Es un modelo de sistema en el que dicho sistema se organiza como un conjunto de servicios y servidores asociados, más unos clientes que acceden y usan los servicios” (Sommerville, 2005, pág. 226).

Modelo de capas: “Organiza el sistema en capas, donde cada una de las cuales proporciona un conjunto de servicios” (Sommerville, 2005, pág. 227). Este modelo soporta un desarrollo incremental ya que a menudo que se concluyen capas, la funcionalidad de estas ya pueden estar disponibles para los usuarios.

A su vez en esta etapa de diseño se utiliza el modelos y diagramas el cual nos ayuda a entender mejor, tener una mejor abstracción de lo que se va a realizar.

Lenguaje Unificado de Modelado o UML.

Éste proporciona diagramas que esquematizan los requisitos funcionales en términos técnicos que facilitan el desarrollo del software; es un lenguaje estandarizado que sirve para describir, diseñar, especificar, visualizar, construir y documentar un producto software, sirviéndose de varios diagramas (Wong Durand, 2017). Estos diagramas se clasifican en estructurales y de comportamiento, a continuación, se encuentran los diagramas comúnmente usados en el desarrollo de software.

26 Diagrama de Clases: Se encuentra dentro de los diagramas de estructura, en este diagrama se muestran las clases del sistema y la interrelación entre ellas, las clases se dividen en tres partes, la primera muestra el nombre de la clase, la segunda sus atributos; y la tercera muestra sus acciones (Wong Durand, 2017).

Diagrama de Casos de uso: Se encuentra dentro de los diagramas de comportamiento, describe las acciones que se dan entre el sistema y las entidades externas (actores o sistemas); se describen las actividades funcionalmente para un mejor entendimiento del usuario final (Wong Durand, 2017).

Diagrama de secuencia: se encuentra dentro de los diagramas de interacción y éste se encuentra dentro de los diagramas de comportamiento. Muestra la interacción de objetos en el sistema y en el tiempo, y los mensajes que se transmiten entre objetos; este diagrama de muestra el detalle del escenario a nivel de actividades (Wong Durand, 2017).

2.2.1.1.3. Desarrollo

A menudo la gran mayoría de empresas optan por la obtención de un software con el fin de automatizar procesos, reducir tiempos, tener información disponible en cualquier momento. Sin embargo, el desarrollo basado en la planificación aplicado en proyectos pequeños y medianos consumía un esfuerzo grande durante el desarrollo, por ese motivo muchos desarrolladores de software propusieron métodos ágiles que permitieran centrarse más en el desarrollo y no tanto en la documentación.

“Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos iterativos en los que

27 se entrelazan la especificación, el diseño, el desarrollo y las pruebas”

(Sommerville, 2005).

Programación Extrema:

La programación extrema es una metodología de desarrollo ágil de software, el cual reduce la engorrosa documentación, esta metodología se enfoca en dar prioridad al desarrollo; está basada en el trabajo en equipo entre clientes, gerentes y desarrolladores, en valores como comunicación, sencillez, retroalimentación, respeto y coraje (Extreme Programing, 2013).

La programación extrema tiene varios principios de métodos ágiles según Sommerville, los cuales son:

o El desarrollo incremental y entregas frecuentes de pequeñas partes del software.

o La participación del cliente durante el desarrollo y los cuales definen la aceptación de las pruebas del software.

o El desarrollo en pareja lo que ayuda que cada uno verifique el trabajo el otro asegurándose que siempre se procure hacer un buen trabajo.

o Siempre procurando la mantenibilidad del código y un diseño sencillo.

2.2.1.1.4. Verificación y Validación

Este proceso está dentro de cada etapa del proceso de software, comenzando por las revisiones de los requerimientos, en el diseño, el desarrollo, la implementación hasta la prueba del producto en general. Existe una diferencia entre verificación y validación, donde “el papel de la verificación implica comprobar que el software está de acuerdo con su especificación”

(Sommerville, 2005), es aquí donde se comprueba si satisface los requerimientos funcionales y no funcionales. Por otro lado, el papel de la

28 validación “es asegurar que el sistema software satisface las expectativas del cliente” (Sommerville, 2005), como se pude ver es algo general y se entiende que el sistema software hace lo que el cliente espera que haga. En general la verificación y validación tiene como propósito que el software sea lo aceptablemente bueno para su uso pretendido o para el propósito creado.

Pruebas de Software

Las pruebas se centran en satisfacer los requerimientos funcionales y no funcionales y garantizar que el funcionamiento del software se comporte de forma inesperada. En las pruebas de software mayormente se realiza las siguientes acciones:

o “Definición de la Estrategia de Prueba. Se crea una muestra de datos que reúnan las diversas variedades de casos que se pueden presentar durante la operación del sistema. Así mismo se diseñan datos erróneos para verificar que el sistema los detecta” (Peña Ayala, 2006).

o “Prueba por Módulos. Como el sistema está dividido en varios módulos, se prueba por módulos y luego se unen estos módulos para probar el sistema integro” (Peña Ayala, 2006).

“Un modelo general del proceso de pruebas se muestra en la Figura N° 5. Los casos de prueba son especificaciones de las entradas para la prueba y la salida esperada del sistema más una afirmación de lo que se está probando”

(Sommerville, 2005, pág. 493).

29 Figura N° 5 Modelo del proceso de pruebas de software

Fuente: (Sommerville, 2005, pág. 125) Elaborado: Propio