An´
alisis de la contextualizaci´
on de los sistemas en el desarrollo de
software
Jonathan L´
opez Ram´ırez
Dirigido por:
Alejandro Paolo Daza
Revisado por:
Oswaldo Romero
Universidad Distrital Francisco Jos´
e de Caldas
Facultad de Ingenier´ıa
Especializaci´
on en Ingenier´ıa de Software
Bogot´
a D.C.
Tabla de Contenido
I
CONTEXTUALIZACI ´
ON DE LA INVESTIGACI ´
ON
3
1. Descripci´on de la Investigaci´on 5
1.1. Planteamiento/Identificaci´on del problema . . . 5
1.1.1. Planteamiento del problema . . . 5
1.1.2. Formulaci´on . . . 5
1.1.3. Sistematizaci´on . . . 6
1.2. Objetivos . . . 7
1.2.1. Objetivo general . . . 7
1.2.2. Objetivos espec´ıficos . . . 7
1.3. Justificaci´on del trabajo/investigaci´on . . . 8
1.4. Hip´otesis . . . 9
1.5. Marco referencial . . . 10
1.5.1. Marco Te´orico y conceptual . . . 10
1.6. Metodolog´ıa de la investigaci´on . . . 19
1.6.1. Tipo de estudio . . . 19
1.6.2. M´etodo de investigaci´on . . . 19
1.6.3. Fuentes y t´ecnicas para la recolecci´on de la informaci´on . . . 19
1.6.4. Tratamiento de la informaci´on . . . 19
1.7. Organizaci´on del trabajo de grado . . . 20
II
DESARROLLO DE LA INVESTIGACI ´
ON
21
2. An´alisis de la contextualizaci´on del sistema para los modelos de proceso 23 2.1. Modelo de proceso en cascada . . . 232.1.1. Rapid Development, McConnell Steve . . . 24
2.1.2. Ingenier´ıa de software, Roger Pressman . . . 24
2.1.3. Ingenier´ıa de software, Ian Sommerville . . . 26
2.1.4. An´alisis final modelo de proceso en cascada . . . 27
2.2. Modelo de proceso en espiral . . . 28
2.2.1. Rapid Development, McConnell Steve . . . 28
2.2.2. Ingenier´ıa de software, Roger Pressman . . . 28
2.2.3. Ingenier´ıa de software, Ian Sommerville . . . 29
2.2.4. An´alisis final modelo de proceso en espiral . . . 31
2.3. Modelo de proceso evolutivo: Prototipos . . . 32
2.3.1. Rapid Development, McConnell Steve . . . 32
2.3.2. Ingenier´ıa de software, Roger Pressman . . . 32
2.3.3. Ingenier´ıa de software, Ian Sommerville . . . 32
3. An´alisis de como se lleva a cabo el desarrollo de software en la industria 35
3.1. Dise˜no de la entrevista . . . 35
3.2. An´alisis de los resultados . . . 39
4. Metodolog´ıas de contextualizaci´on 43 4.1. Metodolog´ıas orientadas por escenarios . . . 43
4.1.1. Elaboraci´on de escenarios . . . 44
4.2. Metodolog´ıas basadas en objetivos . . . 47
4.2.1. Metodolog´ıa KAOS . . . 47
III
CIERRE DE LA INVESTIGACI ´
ON
51
5. RESULTADOS Y DISCUSI ´ON 53 6. CONCLUSIONES 55 6.1. Verificaci´on, contraste y evaluaci´on de los objetivos . . . 556.2. S´ıntesis del modelo propuesto . . . 56
6.3. Aportes originales . . . 56
7. PROSPECTIVA DEL TRABAJO DE GRADO 57 7.1. L´ıneas de investigaci´on futuras . . . 57
7.2. Trabajos de Investigaci´on futuros . . . 57
BIBLIOGRAF´IA 61
IV
ANEXOS
63
´
Indice de Im´
agenes
1.1. Modelo en espiral propuesto por Boehm. Ingenier´ıa de Software Ian Sommerville . . . 11
1.2. Modelo incremental. Ingenier´ıa de Software Ian Sommerville . . . 12
1.3. Ingenier´ıa del software basada en componentes. Ingenier´ıa de Software Ian Sommerville . . . 12
2.1. Modelo de cascada pura. Rapid Development, McConnell Steve . . . 25
2.2. Modelo de cascada con reducci´on de riesgos. Rapid Development, McConnell Steve . . . 25
2.3. Modelo de cascada. Ingenier´ıa de software, Roger Pressman . . . 26
2.4. Modelo de cascada. Ingenier´ıa de software, Ian Sommerville . . . 27
2.5. Modelo de proceso en espiral. Rapid Development, McConnell Steve . . . 29
2.6. Modelo de proceso en espiral. Ingenier´ıa de software, Roger Pressman . . . 30
2.7. Modelo de proceso en espiral. Ingenier´ıa de software, Ian Sommerville . . . 31
2.8. Modelo de proceso evolutivo: Prototipos. Ingenier´ıa de software, Roger Pressman . . . 33
2.9. Modelo de proceso evolutivo: Prototipos. Ingenier´ıa de software, Ian Sommerville . . . 33
3.1. Formulario enviado para la realizaci´on del cuestionario . . . 37
3.2. Resultado pregunta 1: De los siguientes modelos de proceso de desarrollo de software, ¿Cual(es) utiliza con mayor frecuencia? . . . 39
3.3. Resultado pregunta 7: Cuando NO se ha definido el contexto de la aplicaci´on, ¿Que porcentaje de proyectos en los que ha participado ha resultado exitoso? . . . 40
3.4. Resultado pregunta 8: Indique que aspectos considera pueden afectar el contexto donde se desarrollar´ıa e implementar´ıa una aplicaci´on . . . 41
3.5. Resultado pregunta 9: Cuando se ha definido el contexto de la aplicaci´on, ¿Que porcentaje de proyectos en los que ha participado ha resultado exitoso? . . . 41
4.1. S´ıntesis Construcci´on de Escenarios. Proyecto BASAL . . . 46
´
Indice de Tablas
2.1. Tabla comparativa de propuestas para modelo de proceso en cascada . . . 27
2.2. Tabla comparativa de propuestas para modelo de proceso en espiral . . . 31
2.3. Tabla comparativa de propuestas para modelo de proceso por prototipos . . . 34
Parte I
CONTEXTUALIZACI ´
ON DE LA
Cap´ıtulo 1
Descripci´
on de la Investigaci´
on
1.1.
Planteamiento/Identificaci´
on del problema
1.1.1.
Planteamiento del problema
De acuerdo con estad´ısticas relacionadas con el desarrollo de software [Standish group-2015], se ha iden-tificado que menos de la tercera parte de los proyectos (28 %) resulta ser completamente exitoso al final de su ejecuci´on, esto es porque no se cumple con lo solicitado por el usuario final, ya sea en el entregable, los tiempos utilizados y/o los costos asociados.
Lo anterior es el reflejo de m´ultiples factores que inciden en la ejecuci´on de proyectos, ya sea por la falta de planeaci´on, tiempo reducidos, empresas (tanto proveedor como cliente) que quieren maximizar ganancias a costa de productos de baja calidad, o poca experiencia por parte de los encargados del desarrollo. Varios de los m´as frecuentes y relevantes errores en el desarrollo de software, tal como se infiere en el libro [1], est´an relacionados con la poca precisi´on de los requerimientos t´ecnicos y dise˜nos.
Esto en parte se debe al establecimiento del alcance del sistema, la falta de comprensi´on del problema por las partes interesadas, y la volatilidad de los requisitos complican su interpretaci´on y modelamiento. Es por esto que las primeras etapas en el desarrollo de software son complicadas y exigentes.
Otro aspecto a resaltar, es la complejidad en el momento de definir los requerimientos, en forma con-sistente y compacta ya que consiste en la traducci´on de unas ideas vagas de necesidades de software en un conjunto concreto de funciones y restricciones.
As´ı mismo, el ingeniero de desarrollo debe extraer informaci´on dialogando con muchas personas y cada una de ellas se expresar´a de una forma distinta, tendr´a conocimientos inform´aticos y t´ecnicos distintos, y tendr´a unas necesidades y una idea del proyecto muy particulares.
En si el entorno de captura de necesidades es complejo ya que la base es la comunicaci´on entre diferentes personas de distintos perfiles: cliente, usuarios, analistas de requerimientos, arquitectura, dise˜nadores y desa-rrolladores, analistas de pruebas, personas de soporte y operaci´on. La comunicaci´on tiene tanta variabilidad que hay posibilidad de ambig¨uedades y diferencias de interpretaci´on.
1.1.2.
Formulaci´
on
entendi-miento.
1.1.3.
Sistematizaci´
on
En este proceso de an´alisis es importante verificar:
¿Qu´e modelos de proceso de desarrollo de software definen etapas de ingenier´ıa de requerimientos y/o contextualizaci´on del sistema?
¿Qu´e antecede a la ingenier´ıa de requerimientos en el desarrollo de software?
¿Qu´e t´ecnicas existen para contextualizar el sistema en el desarrollo de software?
1.2.
Objetivos
1.2.1.
Objetivo general
Analizar la contextualizaci´on de los sistemas para el desarrollo de software de calidad, a trav´es de modelos de proceso existentes.
1.2.2.
Objetivos espec´ıficos
1. Identificar los modelos de proceso de desarrollo de software a contrastar y su relaci´on con la contextua-lizaci´on del sistema.
2. Identificar que antecede a la definici´on de requerimientos en el desarrollo de software, tanto en los modelos de proceso como en la pr´actica.
1.3.
Justificaci´
on del trabajo/investigaci´
on
A. Justificaci´on te´oricaLa clave del ´exito o fracaso de un proyecto de software depende fuertemente de resolver el problema correcto [2], es decir, encontrar el conjunto de soluciones adecuadas al problema en el universo de discurso. Para lo cual, se debe primero capturar las demandas, necesidades y problemas existentes en el universo de discurso y luego determinar que los requisitos especificados sean los correctos.
En los procesos de dise˜no y desarrollo de un software, los requisitos u objetivos de la aplicaci´on quedan dependiendo de la subjetividad o destreza de los desarrolladores o analistas de requerimientos para interpre-tar los resultados que espera el cliente del producto.
En ese sentido, resulta relevante realizar el an´alisis general de c´omo se est´a abordando actualmente la contextualizaci´on de los sistemas, se realizar´a una comparaci´on de los modelos de proceso de desarrollo de software m´as utilizados, se identificar´a en la industria como se realiza el levantamiento de los requerimientos y si realmente se realizan etapas previas a dicho proceso.
1.4.
Hip´
otesis
1.5.
Marco referencial
1.5.1.
Marco Te´
orico y conceptual
A. Software
Cuando nos referimos a “software” podemos encontrar diferentes definiciones relacionadas con el t´ermino, sin embargo, en general se puede precisar c´omo “El conjunto de los programas de c´omputo, procedimientos, reglas, documentaci´on y datos asociados, que forman parte de las operaciones de un sistema de computaci´on”1.
Como se aprecia en la definici´on estandarizada de IEEE, software no solamente corresponde a programas de computadora, de hecho existen varios expertos en la materia que establecen una definici´on m´as amplia, [3] “Programas de ordenador y documentaci´on asociada. Los productos de software se pueden desarrollar para alg´un cliente en particular o para un mercado general”.
As´ı mismo en la ISO 12207 se define como “Conjunto de programas de computadora, procedimientos y posiblemente documentaci´on y datos asociados”2.
B. Proceso de creaci´on de software
El proceso de creaci´on de software puede llegar a ser muy complejo, dependiendo de sus caracter´ısticas y criticidad del mismo. Dicho proceso de software va generalmente, y esto en b´usqueda de un producto de calidad, acompa˜nado de un modelo de proceso, “Un modelo de proceso del software es un representaci´on abstracta de un proceso del software. Cada modelo del proceso representa un proceso desde una perspectiva particular, y as´ı proporciona solo informaci´on parcial sobre ese proceso” [3] .
“En el contexto de la ingenier´ıa de software, un proceso no es una prescripci´on r´ıgida de c´omo elaborar software de c´omputo. Por el contrario, es un enfoque adaptable que permite que las personas que hacen el trabajo (el equipo de software) busquen y elijan el conjunto apropiado de acciones y tareas para el trabajo. Se busca siempre entregar el software en forma oportuna y con calidad suficiente para satisfacer a quienes patrocinaron su creaci´on y a aquellos que lo usar´an” [4] .
Entre los modelos se pueden citar los siguientes:
Modelo en cascada
Modelos de proceso incremental
Modelos de proceso evolutivo: Prototipos - Espiral
Modelos concurrentes
Modelo basado en componentes
Modelo de m´etodos formales
Desarrollo orientado a aspectos
Proceso Unificado
A continuaci´on se ilustra de manera muy general algunos de los modelos de proceso:
1. Modelo en cascada
A veces denominado ciclo de vida cl´asico, sugiere un enfoque sistem´atico y secuencial para el desarrollo del software, que comienza con la especificaci´on de los requerimientos por parte del cliente y avanza a trav´es de planeaci´on, modelado, construcci´on y despliegue, para concluir con el apoyo del software terminado.
2. Modelo en espiral
Fue originalmente propuesto por Boehm (Boehm, 1988). M´as que representar el proceso del software como una secuencia de actividades con retrospectiva de una actividad a otra, se representa como una espiral. Cada ciclo en la espiral representa una fase del proceso del software. As´ı, el ciclo m´as interno podr´ıa referirse a la viabilidad del sistema, el siguiente ciclo a la definici´on de requerimientos, el si-guiente ciclo al dise˜no del sistema, y as´ı sucesivamente [3] .
Imagen 1.1: Modelo en espiral propuesto por Boehm. Ingenier´ıa de Software Ian Sommerville
3. Modelos de proceso incremental
Imagen 1.2: Modelo incremental. Ingenier´ıa de Software Ian Sommerville
4. Modelo de proceso basado en componentes
En gran parte de los procesos de desarrollo es habitual la re utilizaci´on de software, sin embargo, en lo que respecta el proceso basado en componentes es a menudo indispensable para un proceso r´apido de sistemas.
Este enfoque basado en la reutilizaci´on se compone de una gran base de componentes software reutiliza-bles y de algunos marcos de trabajo de integraci´on para estos. En algunas ocasiones estos componentes son sistemas por s´ı mismos que se pueden utilizar para una funcionalidad espec´ıfica, como para dar formato al texto o efectuar c´alculos num´ericos[3] .
Imagen 1.3: Ingenier´ıa del software basada en componentes. Ingenier´ıa de Software Ian Sommerville
5. Modelos concurrentes
invocar una o m´as de las siguientes acciones de software: hacer prototipos, an´alisis y dise˜no.
Dicha actividad —modelado— puede estar en cualquiera de los estados mencionados en un momento dado. En forma similar, es posible representar de manera an´aloga otras actividades, acciones o tareas (por ejemplo, comunicaci´on o construcci´on). Todas las actividades de ingenier´ıa de software existen de manera concurrente, pero se hallan en diferentes estados [4] .
6. Modelo de m´etodos formales
El modelo de m´etodos formales agrupa actividades que llevan a la especificaci´on matem´atica formal del software de c´omputo. Los m´etodos formales permiten especificar, desarrollar y verificar un sistema basado en computadora por medio del empleo de una notaci´on matem´atica rigurosa.
Cuando durante el desarrollo se usan m´etodos formales, se obtiene un mecanismo para eliminar muchos de los problemas dif´ıciles de vencer con otros paradigmas de la ingenier´ıa de software. Lo ambiguo, incompleto e inconsistente se descubre y corrige con m´as facilidad, no a trav´es de una revisi´on ad hoc sino con la aplicaci´on de an´alisis matem´atico.
7. Desarrollo de software orientado a aspectos
Sin importar el proceso del software que se elija, los constructores de software complejo implementan de manera invariable un conjunto de caracter´ısticas, funciones y contenido de informaci´on localizados. Es-tas caracter´ısticas localizadas del software se modelan como componentes (clases orientadas a objetos) y luego se construyen dentro del contexto de una arquitectura de sistemas. A medida que los siste-mas modernos basados en computadora se hacen m´as sofisticados (y complejos), ciertas preocupaciones —propiedades que requiere el cliente o ´areas de inter´es t´ecnico— se extienden a toda la arquitectura. Algunas de ellas son las propiedades de alto nivel de un sistema (por ejemplo, seguridad y tolerancia a fallas). Otras afectan a funciones (aplicaci´on de las reglas de negocios), mientras que otras m´as son sist´emicas (sincronizaci´on de la tarea o administraci´on de la memoria).
Cuando las preocupaciones afectan m´ultiples funciones, caracter´ısticas e informaci´on del sistema, es frecuente que se les llame preocupaciones globales. Los requerimientos del aspecto definen aquellas preocupaciones globales que tienen alg´un efecto a trav´es de la arquitectura del software. El desarrollo de software orientado a aspectos (DSOA), conocido tambi´en como programaci´on orientada a aspectos (POA), es un paradigma de ingenier´ıa de software relativamente nuevo que proporciona un proceso y enfoque metodol´ogico para definir, especificar, dise˜nar y construir aspectos: “mecanismos m´as all´a de subrutinas y herencia para localizar la expresi´on de una preocupaci´on global” [4] .
8. Proceso Unificado
El proceso unificado es un intento por obtener los mejores rasgos y caracter´ısticas de los modelos tra-dicionales del proceso del software, pero en forma que implemente muchos de los mejores principios del desarrollo ´agil de software. El proceso unificado reconoce la importancia de la comunicaci´on con el cliente y los m´etodos directos para describir su punto de vista respecto de un sistema (el caso de uso). Hace ´enfasis en la importancia de la arquitectura del software y “ayuda a que el arquitecto se centre en las metas correctas, tales como que sea comprensible, permita cambios futuros y la reutilizaci´on”[4] .
C. Modelo de proceso y metodolog´ıa
Cuando nos referimos al desarrollo de software y en particular, al proceso formal definido se considera pertinente enfatizar en la diferencia y principal definici´on para modelo de proceso y metodolog´ıa.
Modelo de proceso: Se refiere a establecer una perspectiva diferente a la planteada en el modelo en cascada que est´a dado por un conjunto de actividades bien definidas y que permiten definir disciplinas y roles. Estos dos conceptos son vitales porque conllevan a una clara definici´on de los recursos y res-ponsabilidades[5].
Metodolog´ıa: Se ocupa de proponer un conjunto de pr´acticas, valores y principios, asociados al proce-so[5].
D. Ciclo de vida del software
Conforme se define en la ISO 12207 el ciclo de vida del software es:
“Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desa-rrollo, la explotaci´on y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definici´on de los requisitos hasta la finalizaci´on de su uso”.
De acuerdo a la definici´on, cualquier sistema de informaci´on va pasando por una serie de fases a lo largo de su vida. Su ciclo de vida comprende una serie de etapas que son un reflejo del proceso que se sigue a la hora de resolver cualquier tipo de problema. De acuerdo al tipo de modelo de proceso implementado se utilizaran algunas o todas las etapas mencionadas.
A continuaci´on se presenta de manera general las caracter´ısticas que comprenden cada etapa:
1. Planificaci´on
Las tareas iniciales que se realizar´an esta fase inicial del proyecto incluyen actividades tales como la determinaci´on del ´ambito del proyecto, la realizaci´on de un estudio de viabilidad, el an´alisis de los riesgos asociados al proyecto, una estimaci´on del coste del proyecto, su planificaci´on temporal y la asignaci´on de recursos a las distintas etapas del proyecto.
2. An´alisis
La etapa de an´alisis en el ciclo de vida del software corresponde al proceso mediante el cual se intenta descubrir qu´e es lo que realmente se necesita y se llega a una comprensi´on adecuada de los requerimientos del sistema.
3. Dise˜no
4. Implementaci´on
Para la fase de implementaci´on es necesario seleccionar las herramientas adecuadas, un entorno de desarrollo que facilite la labor y un lenguaje de programaci´on apropiado para el tipo de sistema a construir. La elecci´on de estas herramientas depender´a en gran parte de las decisiones de dise˜no y del entorno en el que el sistema deber´a funcionar.
5. Pruebas
La etapa de pruebas tiene como objetivo detectar los errores que se hayan podido cometer en las etapas anteriores del proyecto. Adem´as, es hacerlo antes de que el usuario final del sistema los detecte. De hecho, una prueba es un ´exito cuando se detecta un error. La b´usqueda de errores que se realiza en la etapa de pruebas puede adaptar distintas formas, en funci´on del contexto y de la fase del proyecto.
6. Instalaci´on / Despliegue
Una vez concluidas las etapas de desarrollo de un sistema de informaci´on (an´alisis, dise˜no, implementa-ci´on y pruebas), llega el instante de que poner el sistema en funcionamiento, su instalaci´on o despliegue.
7. Uso y mantenimiento
La etapa de mantenimiento consume t´ıpicamente del 40 al 80 por ciento de los recursos de una empresa de desarrollo de software. De hecho, con un 60 % de media, es probablemente la etapa m´as importante del ciclo de vida del software. Dada la naturaleza del software, que ni se rompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes: Correctivo, Adaptativo y perfectivo.
E. Especificaci´on y an´alisis de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema de software es llamado Ingenier´ıa de Requerimientos. La meta es entregar una especificaci´on de requerimientos de softwa-re corsoftwa-recta y completa, apunta a mejorar la forma en que compsoftwa-rendemos y definimos sistemas de softwasoftwa-re complejos.
De acuerdo con el est´andar IEEE 8303, un requerimiento se define como “Condici´on o capacidad que debe
poseer un sistema o componente de un sistema para satisfacer un contrato. Un est´andar, una especificaci´on u otro documento formalmente impuesto”.
Sin embargo, y tal como se ha mencionado en el documento, el proceso de establecimiento de los requeri-mientos de un sistema es complejo y representa una de las primeras etapas por las que debe pasar el proyecto antes de su ejecuci´on, una captura errada de los requisitos puede ser fundamental a la hora de evaluar el proyecto de exitoso o no.
El detalle de los requisitos debe ser correcto, preciso y no ambiguo, es por ello que nace la Ingenier´ıa de Requisitos (IR). La cual se puede definir de la siguiente manera:
“Un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requisitos del sistema” [3], as´ı mismo se puede definir como “el proceso de obtenci´on de requisitos a trav´es de un proceso interactivo y cooperativo de an´alisis del problema, documentando las observaciones en una variedad de formatos de representaci´on y verificando la exactitud de lo comprendido” [6].
F. Especificaci´on de requisitos seg´un el est´andar IEEE 830
A continuaci´on se describe el paso a paso definido en el est´andar para la especificaci´on de requisitos.
Descripci´on General
En esta secci´on se describen todos aquellos factores que afectan al producto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permitir´a definir con detalle los requisitos en la secci´on 3, haciendo que sean m´as f´aciles de entender. Normalmente, esta secci´on consta de las siguientes subsec-ciones: Perspectiva del producto, funciones del producto, caracter´ısticas de los usuarios, restricciones, factores que se asumen y futuros requisitos.
Perspectiva del Producto
Esta subsecci´on debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalmente independiente de otros productos, tambi´en debe especificarse aqu´ı. Si la ERS define un producto que es parte de un sistema mayor, esta subsecci´on relacionar´ıa los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identificaran las interfaces entre el producto mayor y el producto aqu´ı descrito. Se recomienda utilizar diagramas de bloques.
Funciones del Producto
En esta subsecci´on de la ERS se mostrar´a un resumen, a grandes rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad, esta subsecci´on mostrar´ıa que el sistema soportar´ıa el mantenimiento de cuentas, mostrar´ıa el estado de las cuentas y facilitar´ıa la facturaci´on, sin mencionar el enorme detalle que cada una de estas funciones requiere.
Las funciones deber´ıan mostrarse de forma organizada, y pueden utilizarse gr´aficos, siempre y cuando dichos gr´aficos reflejen las relaciones entre funciones y no el dise˜no del sistema.
Caracter´ısticas de los Usuarios
Esta subsecci´on describir´ıa las caracter´ısticas generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia t´ecnica.
Restricciones
Esta subsecci´on describir´a aquellas limitaciones que se imponen sobre los desarrolladores del producto
1. Pol´ıticas de la empresa
2. Limitaciones del hardware
3. Interfaces con otras aplicaciones
4. Operaciones paralelas
5. Funciones de auditor´ıa
6. Funciones de control
7. Lenguaje(s) de programaci´on
8. Protocolos de comunicaci´on
9. Requisitos de habilidad
10. Criticalidad de la aplicaci´on
Suposiciones y Dependencias
Requisitos Futuros
Esta subsecci´on esbozar´a futuras mejoras al sistema, que podr´an analizarse e implementarse en un futuro.
G. Requisitos o requerimientos
En la literatura relacionada con el desarrollo de software se ha evidenciado que los conceptos de requisitos y requerimientos se utilizan de forma similar y casi sin diferenciaci´on, esto puede estar acentuado en nuestro idioma ya que la traducci´on del ingl´es para ambos t´erminos puede llegar a corresponder a un falso cognado, esto se ilustra a continuaci´on:
Requerimiento ingl´es esrequest Requisito en ingl´es esrequeriment
Como se puede apreciar pareciera visualmente que sus traducciones pudiesen estar cambiadas y por ende en varios textos se pudo haber cometido esta imprecisi´on en la traducci´on.
Es por ello que se considera necesario analizar una diferencia conceptual relativa y que permite mayor claridad al mencionar uno u otro:
Requerimiento: son todas las necesidades y deseos pedidos por el cliente y las personas involucradas en el software.
Requisito: todas las funcionalidades, caracter´ısticas y restricciones que deber´ıa tener el software
Esta acepci´on, presenta la oportunidad de recurrir a los requerimientos (en lenguaje del negocio) para modelar la necesidad del cliente y a los requisitos para modelar las caracter´ısticas del software (en lenguaje propio de la ingenier´ıa)[7].
H. Universo de discurso
Un primer paso para realizar el levantamiento de informaci´on es el conocimiento y definici´on acertada, lo que se conoce como ¨Universo de Discurso”del problema, que se define y entiende por:
“Todo el contexto en el cual el software se desarrolla e incluye todas las fuentes de informaci´on y toda la gente relacionada con el software. Es la realidad acotada por el conjunto de objetivos establecidos por quienes demandan una soluci´on de software. Las personas involucradas en el proceso de desarrollo son principalmente: usuarios, clientes, ingenieros de software, expertos del dominio” [8]
En otras palabras, el universo del discurso se refiere a estudiar inicialmente las especificaciones del sistema y el plan del proyecto del software. Realmente se necesita llegar a comprender el software dentro del contexto del sistema.
I. Definici´on del t´ermino “Contexto”
Con el fin de tener claridad y unificar el concepto principal de la investigaci´on, a continuaci´on se presentan varias definiciones para el t´ermino“Contexto”:
Seg´un la RAE, del lat´ın contextus:
2. m. Entorno f´ısico o de situaci´on, pol´ıtico, hist´orico, cultural o de cualquier otra ´ındole, en el que se considera un hecho [9].
Seg´unOxford English Dictionary:
Las circunstancias que conforman la configuraci´on de un evento, declaraci´on o idea, y en t´erminos de los cuales se puede entender completamente [10].
1.6.
Metodolog´ıa de la investigaci´
on
1.6.1.
Tipo de estudio
El tipo de estudio planteado para esta investigaci´on ser´a descriptivo; ya que se pretende analizar los mo-delos de proceso y practicas existentes para la contextualizaci´on de los sistemas y contrastarlo con t´ecnicas que realicen una adecuada captura del universo del discurso.
1.6.2.
M´
etodo de investigaci´
on
La investigaci´on recurre al m´etodo de An´alisis, ya que inicia por la identificaci´on de etapas de contextua-lizaci´on del sistema para cada uno de los modelos de proceso, posteriormente se identifica en la industria que etapa previa se realiza a la obtenci´on de los requerimientos de la soluci´on a realizar y finalmente se verifican t´ecnicas de contextualizaci´on existentes. Con este insumo de informaci´on se podr´a realizar una comparaci´on y desarrollar un an´alisis final.
1.6.3.
Fuentes y t´
ecnicas para la recolecci´
on de la informaci´
on
La fuente de informaci´on principal para la investigaci´on ser´a secundaria, se acudir´a a libros, revistas cient´ıficas y tesis especializadas en Ingenier´ıa de Software, para a su vez recolectar informaci´on de modelos de proceso, metodolog´ıas, etapas de an´alisis, obtenci´on de requerimientos y t´ecnicas de contextualizaci´on de sistemas.
Tambi´en es importante resaltar que se utilizar´a fuentes primarias ya que para validar como se lleva a cabo en la pr´actica el proceso de ingenier´ıa de requerimientos, m´as all´a de la teor´ıa; se utilizaran encuestas y se realizaran entrevistas a personas con experiencia en el desarrollo de software.
1.6.4.
Tratamiento de la informaci´
on
Con la consolidaci´on de la informaci´on de los modelos de proceso a analizar, se espera realizar una tabla con un an´alisis cualitativo.
1.7.
Organizaci´
on del trabajo de grado
Parte II
DESARROLLO DE LA
Cap´ıtulo 2
An´
alisis de la contextualizaci´
on del
sistema para los modelos de proceso
Para el desarrollo de la investigaci´on se inicia por la identificaci´on de las etapas de desarrollo de software que est´an establecidas en tres modelos de proceso diferentes, verificando de esa manera si contemplan etapas o fases de contextualizaci´on del sistema, esto en el marco de la propuesta de tres autores diferentes. En este proceso de verificaci´on de la bibliograf´ıa existente, se identific´o que si bien la definici´on y generalidades de cada modelo de proceso son similares para cada autor, se evidencia que las etapas presentadas no siempre coinciden, y debido a que corresponde a tema neur´algico para la investigaci´on se presentar´a una comparaci´on entre cada una de las propuestas presentadas por autor.
Es importante indicar que debido a que corresponden a la base de otros modelos de proceso y el enfo-que de algunas metodolog´ıas, para la comparaci´on se tuvieron en cuenta los modelos de proceso tradicionales:
Modelo de proceso en cascada
Modelo de proceso en espiral
Modelo de proceso evolutivo: Prototipos
En este proceso de an´alisis no se verificaran las ventajas o desventajas de cada modelo de proceso, de su aplicaci´on o implementaci´on. ´Esta investigaci´on se centrar´a en verificar las etapas, principalmente al inicio del proyecto, previo a la captura de requerimientos.
2.1.
Modelo de proceso en cascada
En ocasiones se denominada “ciclo de vida cl´asico” y presenta un enfoque sistem´atico y secuencial para el desarrollo del software. En este modelo, un proyecto avanza a trav´es de una secuencia ordenada de pasos desde el concepto de software inicial hasta las pruebas y/o mantenimiento del sistema. En el proyecto se realiza una revisi´on al final de cada fase para determinar si est´a listo para avanzar a la siguiente fase, por ejemplo, desde el an´alisis de requisitos hasta el dise˜no arquitect´onico. Si la revisi´on determina que el proyecto no est´a listo para pasar a la siguiente fase, permanece en la fase actual hasta que est´e listo.
2.1.1.
Rapid Development, McConnell Steve
En el libro “Rapid Development”, Steve McConnell, presenta el modelo en cascada tradicional y tres versiones con modificaciones con respecto al modelo original.
Sashimi (cascada con fases superpuestas)
El nombre proviene de un modelo de desarrollo de hardware japon´es (de Fuji-Xerox) y se refiere al estilo japon´es de presentar pescado crudo en rodajas, con las rodajas superpuestas entre s´ı. Esto b´asicamente se refiere a que se podr´an iniciar fases siguientes sin que la anterior este totalmente finalizada.
Cascada con subproyectos
En este tipo del modelo de cascada, se propone que se puede dividir el sistema en subsistemas l´ogicamente independientes en alguna de las fases del modelo original, cada uno de los cuales se puede ejecutar a su propio ritmo, cumpliendo de igual manera con la secuencia de fases restantes.
Cascada con reducci´on de riesgo
Modificando el modelo ligeramente, se puede colocar una espiral de reducci´on de riesgo en la parte supe-rior de la cascada para abordar el riesgo de requisitos, postesupe-riormente podr´a utilizar cualquier otra pr´actica de recopilaci´on de requisitos que se considere adecuada.
Para el modelo en cascada pura, sashimi (cascada con fases superpuestas) y cascada con subproyectos, las fases son las mismas, se describen a continuaci´on y se muestran en la figura 2.1
Concepto de software
An´alisis de requerimientos
Dise˜no arquitect´onico
Dise˜no detallado
Codificaci´on y depuraci´on
Pruebas del sistema
Para el modelo cascada con reducci´on de riesgo se proponen fases diferentes al inicio y final del proyecto, esto debido a que se retira la fase inicial “Concepto de software” y se agrega al finalizar el proyecto la etapa de “Mantenimiento”. Esto se puede apreciar en la figura 2.2
2.1.2.
Ingenier´ıa de software, Roger Pressman
En la propuesta de Roger Pressman solo se identifican cinco etapas, sin embargo, cada una de ellas se divide en tareas o subetapas que las componen:
A continuaci´on se relacionan las etapas establecidas:
Imagen 2.1: Modelo de cascada pura. Rapid Development, McConnell Steve
• recabar los requerimientos
Planeaci´on • Estimaci´on • Programaci´on • Seguimiento
Modelado • An´alisis • Dise˜no
Construcci´on • C´odigo • Pruebas
Despliegue • Entrega • Asistencia
• Retroalimentaci´on
Imagen 2.3: Modelo de cascada. Ingenier´ıa de software, Roger Pressman
2.1.3.
Ingenier´ıa de software, Ian Sommerville
Para Sommerville el modelo en cascada se divide en cinco etapas, las cuales se trasforman en actividades fundamentales de desarrollo:
1. An´alisis y definici´on de requerimientos
2. Dise˜no del sistema y del software
3. Implementaci´on y prueba de unidades
4. Integraci´on y prueba del sistema
Imagen 2.4: Modelo de cascada. Ingenier´ıa de software, Ian Sommerville
2.1.4.
An´
alisis final modelo de proceso en cascada
McConnell Pressman Sommerville
Concepto de Software y An´alisis de requisitos
Comunicaci´on An´alisis y definici´on de requeri-mientos
Dise˜no Arquitect´onico Planeaci´on
Dise˜no detallado Modelado Dise˜no del sistema y del software Codificaci´on y depuraci´on y
Pruebas del sistema
Construcci´on y Despliegue Implementaci´on y prueba de uni-dades e Integraci´on y prueba del sistema
Mantenimiento Funcionamiento y
mantenimien-to
Tabla 2.1: Tabla comparativa de propuestas para modelo de proceso en cascada
En general para el modelo de proceso en cascada se define una etapa de ingenier´ıa de requisitos, en donde los requerimientos se adquieren, analizan, validan y se produce una especificaci´on formal. Esta fase por lo general est´a precedida por otra conocida como “Concepto de software” o “Comunicaci´on con el cliente”, en los casos en que el software forma parte de un sistema h´ıbrido m´as grande, se define el contexto para la fase de Ingenier´ıa de requisitos.
Como se ha mencionado, las variaciones del modelo de cascada adoptan diferentes posiciones previo al proceso de Ingenier´ıa de Requisitos.
2.2.
Modelo de proceso en espiral
Propuesto por Barry Boehm, el modelo espiral es un modelo evolutivo. Tiene el potencial para hacer un desarrollo r´apido de versiones cada vez m´as completas.
El modelo en espiral es orientado al riesgo y divide un proyecto de software en proyectos m´as peque˜nos. Cada uno de los cuales aborda uno o m´as riesgos importantes hasta que se hayan abordado todos los riesgos principales. El concepto de “riesgo”puede referirse a requisitos mal entendidos, arquitectura poco entendida, posibles problemas de rendimiento, problemas en la tecnolog´ıa subyacente, etc. Una vez que se han abordado todos los riesgos principales, el modelo en espiral podr´ıa terminar como lo har´ıa un modelo de ciclo de vida en cascada.
Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez m´as completas del sistema cuya ingenier´ıa se est´a haciendo.
2.2.1.
Rapid Development, McConnell Steve
En la propuesta de McConnell para este modelo de proceso cada iteraci´on incluye los seis pasos que se muestran a continuaci´on:
1. Determinar objetivos, alternativas y restricciones
2. Identificar y resolver riesgos
3. Evaluar alternativas
4. Desarrolle los entregables para esa iteraci´on y verifique que sean correctos
5. Planea la siguiente iteraci´on
6. Comprom´etase con un enfoque para la siguiente iteraci´on
As´ı mismo menciona que una vez se hayan reducido los riesgos a un nivel aceptable, se podr´a utilizar otro modelo de proceso, ya sea evolutivo o en cascada para ejecutar el desarrollo de la iteraci´on.
2.2.2.
Ingenier´ıa de software, Roger Pressman
En la descripci´on de este modelo de proceso, el Autor presenta una versi´on m´as superficial que la propuesta anterior, no obstante, en esencia son muy similares ya que las fases presentan un flujo similar en cada interacci´on del espiral:
Comunicaci´on
Planeaci´on • Estimaci´on • Programaci´on • An´alisis del riesgo
Imagen 2.5: Modelo de proceso en espiral. Rapid Development, McConnell Steve
• An´alisis
• Dise˜no
Construcci´on • C´odigo
• Prueba
Despliegue • Entrega
• Retroalimentaci´on
2.2.3.
Ingenier´ıa de software, Ian Sommerville
Imagen 2.6: Modelo de proceso en espiral. Ingenier´ıa de software, Roger Pressman
fase del proceso del software. As´ı, el ciclo m´as interno podr´ıa referirse a la viabilidad del sistema, el siguiente ciclo a la definici´on de requerimientos, el siguiente ciclo al dise˜no del sistema, y as´ı sucesivamente. Las etapas que describe son:
1. Definici´on de objetivos
2. Evaluaci´on y reducci´on de riesgos
3. Desarrollo y validaci´on
Imagen 2.7: Modelo de proceso en espiral. Ingenier´ıa de software, Ian Sommerville
2.2.4.
An´
alisis final modelo de proceso en espiral
McConnell Pressman Sommerville
Determinar objetivos, alternati-vas y restricciones
Comunicaci´on Definici´on de objetivos
Identificar y resolver riesgos y Evaluar alternativas
Planeaci´on y Modelado Evaluaci´on y reducci´on de ries-gos
Desarrolle los entregables para esa iteraci´on y verifique que sean correctos
Construcci´on y Despliegue Desarrollo y validaci´on
Planea la siguiente iteraci´on y Comprom´etase con un enfoque para la siguiente iteraci´on
Planificaci´on
Tabla 2.2: Tabla comparativa de propuestas para modelo de proceso en espiral
2.3.
Modelo de proceso evolutivo: Prototipos
Es un modelo de ciclo de vida en el que desarrolla el concepto del sistema a medida que avanza en el proyecto. Usualmente se comienza desarrollando los aspectos m´as visibles del sistema. Se presenta esa parte del sistema al cliente y luego contin´ua desarrollando el prototipo en funci´on de los comentarios que reciba. En alg´un momento, el desarrollador y el cliente aceptan que el prototipo es ”lo suficientemente bueno”. En ese momento, completa cualquier trabajo restante en el sistema y libera el prototipo como producto final.
De la misma manera es frecuente que un cliente defina un conjunto de objetivos generales para el softwa-re, pero que no identifique los requerimientos detallados para las funciones y caracter´ısticas. En otros casos, el desarrollador tal vez no est´e seguro de la eficiencia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debe adoptar la interacci´on entre el humano y la m´aquina. En estas situaciones, el paradigma de hacer prototipos tal vez ofrezca el mejor enfoque.
2.3.1.
Rapid Development, McConnell Steve
Para este modelo de proceso el ingeniero McConnell propone cuatro fases principales, dando ´enfasis al “refinar el prototipo hasta que sea aceptable”. Las cuatro etapas son:
Concepto inicial
Dise˜no e implementaci´on inicial del prototipo
Refinar el prototipo hasta que sea aceptable
Completar y liberar prototipo
2.3.2.
Ingenier´ıa de software, Roger Pressman
A diferencia del autor anterior, Roger Pressman presenta un modelo de proceso c´ıclico y evolutivo en todas sus fases y por ende se surte todo el proceso luego de la entrega del prototipo y la retroalimentaci´on del cliente. Las etapas son:
Comunicaci´on
Plan r´apido
Modelado y dise˜no r´apido
Construcci´on del prototipo
Despliegue, entrega y retroalimentaci´on
2.3.3.
Ingenier´ıa de software, Ian Sommerville
El enfoque que presenta Ian Sommerville a este modelo de proceso difiere a las propuestas de los dos autores anteriores ya que si bien presenta el enfoque evolutivo de los prototipos, su propuesta se centra en que los clientes no poseen en un principio un entendimiento definitivo de los requerimientos necesarios y en esa medida el desarrollo del software se va presentando de acuerdo a la evoluci´on de los requerimientos del cliente. En esta propuesta se destacan las siguientes etapas:
Imagen 2.8: Modelo de proceso evolutivo: Prototipos. Ingenier´ıa de software, Roger Pressman
Especificaci´on
Desarrollo
Validaci´on
McConnell Pressman Sommerville Concepto inicial Comunicaci´on Esbozo de la descripci´on Dise˜no e implementaci´on inicial
del prototipo
Plan r´apido y Modelado y dise˜no r´apido
Especificaci´on
Refinar el prototipo hasta que sea aceptable
Construcci´on del prototipo Desarrollo
Completar y liberar prototipo Despliegue, entrega y retroali-mentaci´on
Validaci´on
Tabla 2.3: Tabla comparativa de propuestas para modelo de proceso por prototipos
2.3.4.
An´
alisis final modelo de proceso evolutivo: Prototipos
Cap´ıtulo 3
An´
alisis de como se lleva a cabo el
desarrollo de software en la industria
Para este an´alisis se llevo a cabo un estudio te´orico fundamentado en 4 entrevistas y 30 cuestionarios con personas con experiencia en desarrollo de software.
El objetivo de este cuestionario era contrastar las pr´acticas realizadas en la industria del desarrollo del software, en especial en las etapas de captura de requerimientos y etapas previas (contextualizaci´on), con respecto a lo definido en la bibliograf´ıa especializada.
El ecosistema donde se realiz´o la investigaci´on es Bogot´a (Regi´on Centro), Colombia, la cual correspon-de a la regi´on donde se encuentra concentrada la mayor parte de las empresas de TI (80 %) y empleados realizando actividades de Tele-inform´atica, Software y TI (91 %) del pa´ıs. Espec´ıficamente, de acuerdo con [11] para 2014, Bogot´a contaba con cerca 450 empresas que realizaban actividades de desarrollo de software, alrededor del 62 % del pa´ıs.
Principalmente los cuestionarios fueron enviados a estudiantes y personas que trabajan en el ´area de tecnolog´ıa de la Universidad Distrital Francisco Jos´e de Caldas. As´ı mismo dos (2) encuestas fueron reali-zadas a desarrolladores de la Oficina de Tecnolog´ıas de la Informaci´on y Comunicaciones del Departamento Administrativo de Ciencia, Tecnolog´ıa e Innovaci´on - Colciencias.
3.1.
Dise˜
no de la entrevista
Para el desarrollo de los cuestionarios se utiliz´o la herramienta Formulariosde la suite de Google. Se definieron diez (10) preguntas, las cuales con el fin de facilitar su realizaci´on, en su gran mayor´ıa eran de selecci´on m´ultiple. A continuaci´on se presentan las preguntas definidas y realizadas en cada cuestionario:
1. ¿Cuanto tiempo ha participado en procesos directos de desarrollo de software?
a) Menos de a˜no
b) Entre uno (1) y tres (3) a˜nos
c) M´as de tres (3) a˜nos
2. De los siguientes modelos de proceso de desarrollo de software, ¿Cual(es) utiliza con mayor frecuencia? (Puede seleccionar varias)
b) Espiral
c) Prototipos
d) Proceso Unificado (RUP)
e) Ninguno
f) Otro ¿Cu´al?
3. En la organizaci´on donde labora, ¿que metodolog´ıa de desarrollo de software han implementado?
a) Metodolog´ıas ´agiles
b) Metodolog´ıas tradicionales
c) H´ıbridos
d) Metodolog´ıas propias
e) Ninguna
f) Otro ¿Cu´al?
4. En los procesos de desarrollo de software, ¿ha utilizado procesos formales o bien definidos de captura de requerimientos?
a) Si
b) No
5. ¿Cuando inicia un proyecto, antes de la captura de requerimientos, realiza alguna etapa previa para conocer el contexto donde se implementar´a la aplicaci´on?
a) Si
b) No
6. Si la respuesta a la pregunta anterior fue afirmativa, podr´ıa realizar una breve descripci´on del proceso adelantado para conocer el contexto
a) Respuesta
7. Cuando NO se ha definido el contexto de la aplicaci´on, ¿Que porcentaje de proyectos en los que ha participado ha resultado exitoso?
a) 0 a 30 %
b) 31 a 60 %
c) 61 a 90 %
d) M´as del 90 %
8. ¿Indique que aspectos considera que pueden afectar el contexto donde se desarrollar´ıa y se implementar´ıa una aplicaci´on? (Puede seleccionar varias)
a) Sociales
b) Culturales
c) Usuarios
d) Equipo de desarrollo
e) Pol´ıticos
9. Cuando se ha definido el contexto de la aplicaci´on, ¿Que porcentaje de proyectos en los que ha parti-cipado ha resultado exitoso?
a) 0 a 30 %
b) 31 a 60 %
c) 61 a 90 %
d) M´as del 90 %
10. En su opini´on, ¿Considera importante conocer el contexto en el cu´al se implementar´a el software a desarrollar?
a) Si
b) No
Imagen 3.1: Formulario enviado para la realizaci´on del cuestionario
realiz´o el cuestionario si tiene el conocimiento y el criterio para responder las preguntas. Las siguientes tres (3) preguntas se refieren al entorno y panorama general del desarrollo de software en la organizaci´on donde labora, por ello las preguntas relacionadas con metodolog´ıas de desarrollo, modelos de proceso y t´ecnicas en el proceso de captura de requerimientos, ya que se considera que son actividades pueden influir en la contextualizaci´on del sistema.
La segunda parte consisti´o en preguntas que permiten establecer si se realizan etapas de contextualiza-ci´on del sistema y en caso afirmativo que procesos o actividades se llevan a cabo. As´ı mismo se realizaron preguntas para identificar porcentajes de ´exito en proyectos de software con y sin identificaci´on del contexto.
3.2.
An´
alisis de los resultados
En la primera parte de las preguntas, debido a que eran opcionales, m´as de la mitad de los encuestados no diligenci´o el nombre ni el correo electr´onico. Sin embargo, el dato m´as relevante es que m´as del 88 % cuenta con al menos un a˜no de experiencia en el desarrollo de software y cerca del 60 % posee una experiencia superior a los tres (3) a˜nos, esto permite indicar que la informaci´on obtenida en las encuestas tendr´a la credibilidad e importancia requerida.
En la pregunta enumerada como dos (2) “De los siguientes modelos de proceso de desarrollo de software, ¿Cual(es) utiliza con mayor frecuencia?”, se obtuvo un resultado interesante. Esto debido a que, si bien las metodolog´ıas ´agiles est´an tan “de moda”, casi la mitad de los encuestados (Imagen 3.2) (47,1 %) utiliza con mayor frecuencia el modelo en cascada, el m´as tradicional de los procesos, seguido por el modelo de proceso en espiral con un (41,2 %). Otro dato relevante, es que para la pregunta se dej´o la opci´on de respuesta libre como “Otra” y en ´esta varios encuestados (m´as del 11 %) indicaron “Scrum”, lo que nos permite concluir que los t´erminos “modelo de proceso” y “metodolog´ıa”, son confundidos o en la industria no se tiene claridad de su diferencia conceptual, aspecto mencionado en el literal C. del numeral 1.5.1 Marco te´orico y conceptual, del presente documento.
Imagen 3.2: Resultado pregunta 1: De los siguientes modelos de proceso de desarrollo de software, ¿Cual(es) utiliza con mayor frecuencia?
En los relacionado a la pregunta tres (3), se encontr´o que la mayor´ıa de las organizaciones est´an imple-mentando metodolog´ıas ´agiles en sus procesos de desarrollo. A esta tendencia tambi´en le sigue que el 40 % considera que los procesos se manejan con un h´ıbrido entre varias metodolog´ıas.
Para la pregunta n´umero cuatro (4), resulta preocupante que el 55,9 %, la mayor´ıa, indica no realizar pro-cesos formales o bien definidos de captura de requerimientos, esto cuando se ha identificado que corresponde a una etapa crucial y la base del desarrollo de la aplicaci´on.
Entrevistas y reuniones con el cliente
Lectura y verificaci´on de los documentos de la organizaci´on
Conocer y definir el problema
Tambi´en se mencionaron aspectos como “Verificar normatividad”, “Revisi´on de proceso”,“El kick of”, “Revisi´on del modelo de negocio y del mercado”, entre otras.
La pregunta siete muestra como resultado una tendencia que se ha evidenciado a nivel global con respecto a los proyectos de software, espec´ıficamente a cuantos son exitosos. La mitad de los encuestados respondieron que se han finalizado con ´exito entre el 30 y el 60 %; casi la tercera parte indic´o que solo se alcanza hasta un 30 % de los proyectos y tan solo el 2,9 % indic´o que el ´ındice supera el 90 %. Ver imagen 3.3.
Imagen 3.3: Resultado pregunta 7: Cuando NO se ha definido el contexto de la aplicaci´on, ¿Que porcentaje de proyectos en los que ha participado ha resultado exitoso?
A los encuestados tambi´en se les consult´o sobre los aspectos que consideran relevantes para el contexto donde se implementa y/o desarrolla una aplicaci´on. El principal aspecto indicado fueron los “Usuarios”. Los otros ´ıtems se pueden ver en la imagen 3.4.
Luego de las consultas relacionadas con el contexto, se les volvi´o a preguntar el porcentaje de ´exito de los proyectos de software pero ahora cuando si hayan realizado una etapa de contextualizaci´on. Los resultados son bien interesantes, ya que si bien los rangos establecidos son bastante amplios, los resultados son m´as favorables y podr´ıan indicar que en definitiva contextualizar el sistema si permite tener aplicaciones que si responden a los solicitado por el usuario y a lo definido en las etapas de dise˜no. En la imagen 3.5 se puede apreciar que el porcentaje de proyectos exitosos aumento a m´as del 20 % y no indicaron tener proyectos entre el 0 y 30 % de tasa de ´exito.
Imagen 3.4: Resultado pregunta 8: Indique que aspectos considera pueden afectar el contexto donde se desarrollar´ıa e implementar´ıa una aplicaci´on
Cap´ıtulo 4
Metodolog´ıas de contextualizaci´
on
Con el prop´osito de tener un panorama de que tipo de metodolog´ıas de contextualizaci´on existen, se ha identificado que principalmente este tipo de procesos se llevan a cabo o se encuentran inmersos, al menos en desarrollo de software, en propuestas relacionadas con la Ingenier´ıa de Requisitos.
Adicionalmente se evidenci´o, tal como sucedi´o con los modelos de proceso, que cada propuesta tiene una versi´on particular conforme es presentada por un autor o a lo largo del tiempo surte modificaciones o evolu-ciones. En este documento se presentar´a una descripci´on general de cada una, principales caracter´ısticas y se dar´a a conocer el proceso llevado a cabo para su implementaci´on.
En la industria se presentan principalmente dos tipos de metodolog´ıas, es importante indicar que no se han concebido espec´ıficamente para conocer el contexto del sistema pero sus procesos permiten llegar a dicha conclusi´on o al menos alguna de sus etapas lo contempla:
Metodolog´ıas orientadas por escenarios
Metodolog´ıas basadas en metas u objetivos
4.1.
Metodolog´ıas orientadas por escenarios
Los escenarios forman parte del instrumental que utiliza la “Prospectiva”para explorar las alternativas futuras en cualquier ´ambito del quehacer socio econ´omico, pol´ıtico, tecnol´ogico y ambiental. Una de las defi-niciones formalizadas, aceptada por varios especialistas, define la prospectiva como el proceso de exploraci´on sistem´atica del futuro, bajo la modalidad de “qu´e pasar´ıa si”, mediante varias t´ecnicas cuantitativas y semi cuantitativas entre las que se encuentra la construcci´on de escenarios[12].
De acuerdo con [13] los escenarios son utilizados activamente en cuatro ´ambitos:
Planificaci´on estrat´egica
Interacci´on persona-computadora
Ingenier´ıa de requisitos y an´alisis
Dise˜no orientado a objetos
dominio de la aplicaci´on donde el software se utilizar´a y los clientes/usuarios validar´an si la visi´on de los ingenieros es correcta o no [14].
Los escenarios pueden ser un medio de lograr este objetivo, puesto que proveen un medio atractivo de comunicaci´on entre los stakeholders del Universo de Discurso. Y es en este punto donde los escenarios se vuelven importantes, puesto que pueden mantener mucha informaci´on en una forma que dichos stakeholders podr´ıan reconocer, esto debido a que las situaciones se pueden describir en lenguaje natural.
Como se menciono anteriormente no existe un solo m´etodo de obtenci´on de escenarios, sino varias maneras de construirlos. No obstante, el calificativo de m´etodo de escenarios se asigna ´unicamente a aquellos estudios que se realizan teniendo en cuenta los siguientes tres aspectos fundamentales:
Analizar el fen´omeno en estudio, desde un punto de vista retrospectivo y actual
Analizar la influencia de los grupos sociales que son gestores del desarrollo del fen´omeno as´ı como de los factores de cambio
Presentar los resultados finales en forma de escenarios
As´ı mismo, esta metodolog´ıa posee tres objetivos fundamentales, los cuales deben desarrollarse a cabali-dad; dichos objetivos son[15]:
Descubrir y vincular las variables claves que caracterizan al sistema en estudio mediante un an´alisis explicativo global.
Determinar a partir de las variables clave, los actores fundamentales y los medios de que disponen para concretar sus proyectos.
Describir, en forma de escenarios, la posible evoluci´on del sistema en estudio a partir de la observaci´on y an´alisis de las variables claves y de los comportamientos de los actores, respecto a un juego de hip´otesis.
4.1.1.
Elaboraci´
on de escenarios
La metodolog´ıa de escenarios se desarrolla en dos fases principales: la construcci´on de la base anal´ıtica y la elaboraci´on de los escenarios como tal.
1. Construcci´on de la base anal´ıtica:
a) En esta fase previa se debe realizar una lista en la cual se detallen todas las variables que influyen en el sistema. Esta tarea se puede apoyar en procesos como entrevistas, concepto de expertos, lluvia de ideas, etc.
b) Posteriormente se debe analizar los efectos directos e indirectos existentes entre las variables y jerarquizarlas de acuerdo a sus ´ındices de motricidad y dependencia. Para realizar estas dos pri-meras etapas se pueden realizar los siguientes pasos:
Identificaci´on de variables y delimitaci´on del sistema
B´usqueda de las variables esenciales a trav´es del m´etodo MICMAC (an´alisis de motricidad y dependencia)
• An´alisis de las relaciones directas
• An´alisis de las relaciones indirectas
• Relaciones Potenciales
• Selecci´on de las variables claves
Este an´alisis debe tener en cuenta no solo los datos cuantificables, sino tambi´en los datos cualitativos como factores econ´omicos, sociol´ogicos, pol´ıticos, ecol´ogicos, etc.
c) Finalmente se construye el cuadro de estrategias de los actores, que sintetiza el an´alisis de la situaci´on actual, pone en evidencia los retos del futuro y busca encontrar la posici´on de cada actor con respecto a los proyectos y objetivos de los dem´as. Para esta etapa se utiliza el m´etodo de an´alisis de juego de actor MACTOR.
2. Elaboraci´on de los escenarios:
Con la informaci´on obtenida en la fase previa y la formulaci´on de hip´otesis, se procede a la elaboraci´on de los escenarios. En esta fase se busca identificar los diferentes futuros posibles y jerarquizarlos de acuerdo con su probabilidad de ocurrencia.
Estos futuros se obtienen a partir de un listado de hip´otesis que reflejan las tendencias, rupturas, o hechos portadores de futuro que condicionan el comportamiento del sistema; es decir, deben representar a las variables clave que fueron identificadas en el an´alisis estructural.
La metodolog´ıa para la elaboraci´on de escenarios implica, inicialmente, transformar las variables cla-ves en hip´otesis, Dichas hip´otesis deben estar redactadas en t´erminos que faciliten la medici´on de las respectivas variables en cuanto a su comportamiento presente y su situaci´on futura.
Imagen 4.1: S´ıntesis Construcci´on de Escenarios. Proyecto BASAL
Una vez obtenidos los escenarios, estos se pueden presentar como narraciones textuales, guiones gr´aficos, maquetas de v´ıdeo o prototipos de secuencias de comandos. Adem´as, pueden estar en notaci´on formal, semi-formal o insemi-formal [16].
4.2.
Metodolog´ıas basadas en objetivos
Desde hace algunos a˜nos, se vienen popularizando los enfoques de ingenier´ıa de requisitos orientados a objetivos. La raz´on principal de esto es la insuficiencia de los enfoques de an´alisis de sistemas tradicionales cuando se trata de sistemas de software complejos. En el nivel de requisitos, estos enfoques tratan los requisi-tos como compuesrequisi-tos de procesos y darequisi-tos, y no capturan los fundamenrequisi-tos de los sistemas de software, lo que dificulta la comprensi´on de los requisitos con respecto a algunas preocupaciones de alto nivel en el dominio del problema. La mayor´ıa de las t´ecnicas se centran en el modelado y la especificaci´on del software solo. Por lo tanto, carecen de soporte para el razonamiento sobre el sistema compuesto que comprende el sistema y su entorno. Sin embargo, se sabe que las suposiciones incorrectas sobre el entorno de un sistema de software son responsables de muchos errores en las especificaciones de requisitos. Los requisitos no funcionales tambi´en quedan en general fuera de las especificaciones de requisitos.
La ingenier´ıa de requisitos orientada a objetivos (GORE) intenta resolver estos y otros problemas impor-tantes. Se debe tener en cuenta que el proceso de elaboraci´on de requisitos orientados a objetivos finaliza donde comenzar´ıa la mayor´ıa de las t´ecnicas de especificaci´on tradicionales. En general, GORE se centra en las actividades que preceden a la formulaci´on de los requisitos del sistema de software.
Las metodolog´ıas basadas en objetivos tiene tres usos principales:
Obtiene los requisitos y expectativas de los interesados con los objetivos de la organizaci´on
Establece las responsabilidades de los actores
Permite explicar a los interesados la importancia del software futuro
En la literatura especializada se presentan dos tipos de metodolog´ıas basadas en objetivos: la metodolog´ıa KAOS (Knowledge Acquisition Automated Specification) y el correspondiente a notaci´on I*. En ambos casos, existen tres usos identificables; en primer lugar, representan los objetivos de la organizaci´on, los cuales se subdividen de manera jer´arquica hasta alcanzar el nivel de requisitos y expectativas de los interesados; en segundo lugar, define las responsabilidades de los actores en t´erminos de los diferentes objetivos, requisitos y expectativas; finalmente, justifica, frente a los interesados, la importancia del software futuro. [17]
Conforme se identific´o en el proceso de desarrollo de la presente investigaci´on, la que presenta mayor acogida y literatura relacionada corresponde a la metodolog´ıa KAOS y por ende, es la que se expondr´a a continuaci´on.
4.2.1.
Metodolog´ıa KAOS
La metodolog´ıa KAOS es el resultado de varios proyectos de investigaci´on liderados por el profesor A. Van Lamsweerde de la Universidad de Lovaina, B´elgica y financiados por la Uni´on Europea. Actualmente sigue recibiendo aportes y actualizaciones al modelo propuesto inicialmente.
Lamsweerde [18] propuso el diagrama de objetivos KAOS, con el fin de representar jer´arquicamente los objetivos, de forma tal que se colocaran los de alto nivel de la organizaci´on en la ra´ız y los de bajo nivel (m´as operativos y relacionados con los requisitos y expectativas del software) en la parte inferior. Esto per-mite tener una panorama general de los objetivos de las organizaci´on y a su vez justificar el desarrollo de la aplicaci´on a modelar. Adem´as, en este diagrama se pueden asignar responsabilidades a los diferentes actores de la organizaci´on.
Mejorar el proceso de an´alisis de problemas al proporcionar un enfoque sistem´atico para descubrir y estructurar los requisitos
Aclarar las responsabilidades de todos los actores del proyecto.
Permitir que las partes interesadas se comuniquen de manera f´acil y eficiente sobre los requisitos.
Un an´alisis de requisitos de KAOS se divide en tres fases:
1. Recopilaci´on de informaci´on (por ejemplo, documentos existentes, entrevistas) que se utilizar´a para guiar la construcci´on del modelo de objetivos.
2. Definir objetivos, agentes, operaciones, cooperaci´on, obst´aculos, modelado de dominio, requisitos, ex-pectativas y comportamientos. Para obtener y definir estos objetos se pueden realizar los siguientes pasos:
a) Elaborar la estructura de objetivos, ´esta se logra identificar mediante el prop´osito, las palabras claves, la intenci´on, entre otras. Esta actividad se realiza a trav´es de lectura inicial de la informa-ci´on suministrada por el interesado.
b) Identificar los objetivos involucrados: cuando los objetivos est´an totalmente identificados se puede establecer sobre cual objeto del problema inciden.
c) Identificar agentes y operaciones: los objetivos se refieren a transiciones de estados espec´ıficos, y por cada una de ´estas se identifica la operaci´on que la causa. Los agentes son identificados como los potenciales responsables de la operaci´on.
d) Establecer un glosario de t´erminos del software a desarrollar y del entorno (dominio).
e) Relacionar los objetivos para luego volverlos a requisitos del software aqu´ı se consolida las con-diciones del dominio y as´ı se garantiza el cumplimiento de los objetivos asociados a cada operaci´on.
Durante esta fase es importante resaltar las siguientes definiciones y conceptos que se consideran rele-vantes en el proceso de definici´on de los objetos en el modelado:
Requisito: Objetivo de bajo nivel que debe alcanzar un agente de software.
Expectativa: Objetivo que debe alcanzar un agente que forma parte del entorno(dominio).
Asignaci´on: Objeto asociado a varios agentes.
Responsabilidad: Objeto asociado a solo agente.
Durante la fase de modelado, todos los conceptos relevantes se identifican y se relacionan entre s´ı mediante la notaci´on espec´ıfica de KAOS .
Imagen 4.2: Diagrama b´asico metodolog´ıa KAOS
En la tabla 4.1 se presentan los principales elementos utilizados en el diagrama KAOS.
Luego de plasmar y definir los requisitos del sistema, la metodolog´ıa plantea dos procesos generales de validaci´on de los resultados obtenidos:
Verificar que los requisitos obtenidos en el modelo sean los correctos. Para esto se toma cada objetivo, se le verifican los comportamientos y a su vez los agentes asociados a dichos comportamientos.
Nombre Gr´afica Definici´on
Objetivo Fin que se espera lograr con un proceso o ac-tividad o incluso con la misi´on de una organi-zaci´on
Relaci´on AND Permite subrogar los objetivos mediante la re-laci´on l´ogica AND
Conflicto Es utilizado cuando dos objetivos satisfacen necesidades contradictorias
Expectativa Objetivo a nivel de la soluci´on inform´atica que: (i) no se espera sea incorporado; y (ii) podr´ıa ser deseable si las condiciones del pro-yecto lo permiten
Requisito Objetivo de bajo nivel, alcanzable por un agente de software
Propiedad del dominio Propiedades relevantes del dominio de la apli-caci´on
Agente Componente humano o autom´atico, responsa-ble de un requisito o una expectativa
Relaci´on de responsabilidad Conecta un agente a un requisito que est´a bajo su responsabilidad
Relaci´on de asignaci´on Conecta al agente con una expectativa
Parte III
Cap´ıtulo 5
RESULTADOS Y DISCUSI ´
ON
En la investigaci´on realizada se logr´o evidenciar que en la industria es claro que el contexto tiene una re-levancia importante y corresponde a parte fundamental en el proceso de desarrollo del software. No obstante, en la practica y casi de forma general, no se lleva a cabo de manera rigurosa, con m´etodos o procesos bien definidos, cuando se intenta realizar una aproximaci´on a ese “contexto” es m´as por intuici´on o experiencia del analista.
Lo anterior puede ser el reflejo de que en la bibliograf´ıa especializada no se expone de forma particular o con el ´enfasis requerido la forma de contextualizar un sistema. Si bien existen libros o autores que exponen el desarrollo de software de manera rigurosa, y presentan la etapa de captura de requerimientos que es la que m´as se aproxima, no solo por su cercan´ıa en l´ınea de tiempo sino por su misma concepci´on y objetivo, no siempre se le da ese valor diferencial al reconocimiento del sistema, antes de iniciar la obtenci´on de los requerimientos de la aplicaci´on a desarrollar.
Hablando espec´ıficamente de los modelos de proceso para el desarrollo de software, no se establece como tal una etapa contextualizaci´on, el que m´as se puede aproximar, por su bien conocido paso a paso sistem´atico, es el ciclo de vida por naturaleza del desarrollo o tambi´en conocido como cascada.
En relaci´on a metodolog´ıas para contextualizar, se puede indicar que no existe una sola forma de llevar a cabo el proceso, en esta investigaci´on se puedo establecer que existen no solo diferentes metodolog´ıas, si no diferentes enfoques, y como se puede imaginar, de acuerdo con el sistema a analizar se deber´an tener ciertas consideraciones. En ese sentido no hay una metodolog´ıa ´unica que permita contextualizar todos los sistemas y en esa medida plasmarlo o exponerlo no es algo trivial.
