Actividades Práctica Profesional I

BUENAS PRACTICAS PARA EL DESARROLLO Y EL DISEÑO DE SOFTWARE, SEGÚN LOS ESTÁNDARES IEEE – std - 830 - 1998 E ISO/IEC/IEEE 42010 – 2011 (REEMPLAZO A LA IEEE – std – 1471 – 2010).

Las diversas necesidades para realizar buenos software y productos de calidad crean la necesidad de ajustar y realizar modificaciones sobre la forma de trabajo original en los software y utilizar alternativas que permitan estabilidades, acuerdos, compromisos y sobre todo equidad entre el desarrollador y el cliente/usuario; es de ahí donde el grupo IEEE lanza un estándar básico para todo el mundo que trabaja en proyectos donde las diferentes nuevas tecnologías están presentes.

Entre los estándares tenemos el IEEE 830 – 1998 denominado como: Especificación de requisitos de software (ERS); el cual hace una descripción total de los comportamientos del sistema a desarrollar, estos incluyen:

-          Casos de uso (interacción software – usuario / Registros funcionales).

-          Requisitos no funcionales.

-          Casos de implementación (restricciones de diseño, estándar de calidad).

La particularidad mas grande es que estos funcionan en doble vía o dirección, es decir tanto cliente como equipo de desarrollo participan en su redacción y posibles correcciones durante todas las etapas. Debe ser redactado de manera clara e informal.

Las principales recomendaciones para realizar una buen ERS son:

-          Completo: Todos los requisitos deben ser reflejados y sus referencias definidas.

-          Consistente: Coherente con los requisitos propios y documentos de especificación.

-          Inequívoco: Redacción clara, evitando situaciones de mala interpretación.

-          Correcta: El software debe cumplir con los requisitos de las especificaciones.

-          Trazable: Capacidad para verificar un ítem a través de su ID almacenada y documentada.

-          Priorizable: Organización jerárquica establecida según la relevancia al negocio, clasificándose en esenciales, condicionales y opcionales.

-          Modificable: Fácilmente modificable.

-          Verificable: Debe tener un método finito y sin costo para ser probado.

Donde también se especifican tres tipos de requisitos para ser trabajados, los cuales son:

-          Requisitos de usuario: Necesidad expresada verbalmente por el usuario/cliente.

-          Requisitos del sistema: Componentes del sistema para realizar determinada tarea.

-          Requisitos funcionales: Servicio que proporciona el sistema al finalizarse.

Dejando de lado el esquema del estándar, se nota que la principal necesidad par aplicar este mismo, es la comunicación y disposición de trabajar con el cliente, ya que de aquí se obtendrá toda la información y alcance del proyecto.

El siguiente estándar es el IEEE – std – 1471 - 2010, cabe resaltar que este estándar ya no es aplicable y fue modificado y promovido bajo el siguiente estándar y norma renombrada como: ISO/IEC/IEEE 42010 – 2011 Ingeniería de Sistemas y Software – Descripción y Diseño de Arquitecturas.

El cual define los requisitos en el diseño de sistemas, software y arquitecturas empresariales. Tiene como objetivo estandarizar las prácticas de diseños de arquitecturas para definir términos básicos, presentando un fundamento conceptual para expresar, comunicar y revisar arquitecturas y especificar requisitos para aplicarse en las descripciones de la arquitectura, arquitecturas marco y el lenguaje de descripción de arquitectura. SIEMPRE HAY QUE HACER DIFERENCIA ENTRE ARQUITECTURA Y LA DESCRIPCIÓN DE LA ARQUITECTURA.

Este estándar se integra por diversos fundamentos conceptuales, pero los más aplicados son:

-          Modelo Conceptual – Descripción De La Arquitectura.

-          Modelo Conceptual – Vista De Arquitectura.

-          Modelo Conceptual – Punto De Vista De La Arquitectura.

-          Modelo Conceptual – Alcance U Objetivo.

Y finalmente esta ISO se encuentra definida por 4 casos conforme al estándar.

-          Descripción de la arquitectura: es una herramienta que describe la arquitectura para un sistema de interés. En el estándar un sistema se refiere al creado por el hombre o al sistema natural, incluyendo a los productos y servicios de un software y sistemas de software intensivos.

-          Punto de vista de la arquitectura: un punto de vista formaliza las ideas de que un mismo sistema se puede ver de diferentes maneras. Trazando ideas especificas por separado.

-          Marco de Arquitectura: establece practicas comunes para crear, usar, interpretar y analizar la descripción de la arquitectura con una aplicación particular o una comunidad de Stakeholders.

-          Descripción del lenguaje de arquitectura: Pueden especificar una o más puntos de vista de una arquitectura, pero no pertenecer a alguna necesariamente, permite describir y representar arquitecturas de sistemas.

Como se puede observar este par de elementos funcionan entre sí, como un esqueleto del proyecto, donde se nos es permitido aplicar las diversas practicas y desarrollos de nuestros proyectos, de manera clara y consistente, facilitando la interacción entre los diferentes afectados(interesados) y su correspondiente aplicación a la investigación y gestión.

Para finalizar podemos determinar que los estándares vigentes generan una solución inmediata a problemas de sobre como cliente desea su producto y la fundamentación inicial del mismo al momento del desarrollo.

Bibliografía.

-          http://www.iso-architecture.org/42010/docs/ISO-IEC-IEEE-latest-draft-42010.pdf

-          Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). "What Industry Needs from Architectural Languages: A Survey". IEEE Transactions on Software Engineering. 39 (6). doi:10.1109/TSE.2012.74.

-          Raymond Turner. "The Foundations of Specification". Journal of Logic and Computation, Vol. 15, No. 5 (October 2005), pp. 623–663.

-          IEEE STD 830-1998. "Especificaciones de los requisitos del Software", pág. 3.

Mapa Conceptual IEEE - std - 830 - 1998