Universidad de las Ciencias Informáticas Facultad 7
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Título: Propuesta de procedimiento para comprobar el
cumplimiento de la arquitectura de los sistemas de la Facultad 7
Autores: Osvaldo García Santana Yislenys Suárez Hernández
Tutores: Ing. Diana R. Alfonso Espinosa Ing. Yurién R. Fuentes Guerra
Ciudad de la Habana, Mayo de 2009
“Año del 50 Aniversario del Triunfo de la Revolución”
DECLARACIÓN DE AUTORÍA
Declaramos que somos los únicos autores de este trabajo y autorizamos a la Universidad de las Ciencias Informáticas a hacer uso del mismo en su beneficio. Para que así conste firmamos la presente a los 4 días del mes de Mayo del año 2009.
__________________________ _____________________________
Autor: Osvaldo García Santana Autora: Yislenys Suárez Hernández
____________________________ ___________________________
Tutor: Yurién R. Fuentes Guerra Tutora: Diana R. Alfonso Espinosa
Datos de Contacto
DATOS DE CONTACTO
Ing. Diana R. Alfonso Espinosa
Ingeniera en Ciencias Informáticas, graduada en la Universidad de las Ciencias Informáticas (UCI) en el año 2008. Actualmente pertenece al proyecto Calidad de la Facultad 7 de la UCI, donde se desempeña como Asesora de Calidad del Área Temática de Atención Primaria a la Salud (APS). Es profesora de Práctica Profesional en la propia universidad.
Empresa: UCI Dirección: Carretera a San Antonio Km. 2 1/2 Reparto Torrens, Facultad 7, Ciudad Habana.
e-mail: [email protected], Teléfono: .837-2763.
Ing. Yurién R. Fuentes Guerra
Ingeniero en Ciencias Informáticas, graduado en la Universidad de las Ciencias Informáticas (UCI) en el año 2008. Actualmente es Jefe del Equipo Técnico del proyecto Calidad de la Facultad 7 de la UCI. Es profesor de Ingeniería de Software en la propia universidad.
Empresa: UCI Dirección: Carretera a San Antonio Km. 2 1/2 Reparto Torrens, Facultad 7, Ciudad Habana.
e-mail: [email protected], Teléfono: .835-8287.
"Solamente aquel que contribuye al futuro tiene derecho a juzgar el pasado. "
Nietzsche
Agradecimientos
De Yislenys:
De Osvaldo:
Dedicatoria
De Yislenys:
De Osvaldo:
Resumen
RESUMEN
Esta investigación propone un procedimiento para comprobar el cumplimiento de la arquitectura de software definida por los proyectos productivos de la facultad, a la vez que permite revisar que las mismas estén conforme a lo establecido en el Documento de Arquitectura de la facultad 7 de la Universidad de las Ciencias Informáticas.
De forma general, se explica cómo se comprobará la arquitectura de los proyectos, qué actividades se realizarán en cada una de las fases propuestas y en qué momento deben ser aplicadas, proponiendo además el personal que debe realizarlas.
Se realizó un análisis de las principales bibliografías especializadas en el tema, destacando el documento de arquitectura de la facultad 7, ya que es en dicha facultad donde se comenzará a aplicar el procedimiento. Además se analizó la situación existente actualmente en esta facultad en cuanto a lo establecido en el documento de arquitectura, demostrándose la necesidad de contar con los medios para comprobar la arquitectura por parte del proyecto Calidad.
El procedimiento contribuye a lograr un mejor cumplimiento por parte de los proyectos con lo establecido en el documento de arquitectura de la facultad 7.
Índice
ÍNDICE
INTRODUCCION ... 1
Capítulo1: Fundamentación Teórica ... 5
1.1 Principales conceptos de la calidad de software ... 5
Definiciones de calidad ... 5
1.2 La Arquitectura de Software y conceptos relacionados ... 8
Definición de la Arquitectura de Software ... 8
Descripción de la Arquitectura de Software ... 10
Documento de Arquitectura ... 10
1.3 Patrones de Arquitectura ... 10
1.3.1 Modelo Vista Controlador (MVC). ... 12
1.3.2 Arquitectura Orientada a Servicios (SOA). ... 13
1.3.3 Arquitectura multi-capas. ... 14
1.3.4 Arquitectura basada en componentes. ... 14
1.4 Estándares de comunicación entre los sistemas... 15
1.4.1 ¿Qué es DICOM? ... 16
1.4.2 ¿Qué es HL7? ... 17
1.4.3 ¿Que son los Servicios Web? ... 18
1.5 Lenguajes, tecnologías, metodologías y herramientas de soporte al desarrollo . 18 1.5.1 Herramientas ... 18
1.5.2 Tecnologías Informáticas ... 19
1.5.3 Lenguajes de programación ... 20
1.6 Estándares de codificación ... 21
Conclusiones ... 24
Capítulo 2: Situación actual de la Arquitectura de Software en la Facultad 7. .... 26
2.1 Producción de software en la facultad 7 ..………26
Caracterización de la arquitectura de software en la facultad 7 ... 27
Grupo de Tecnologías y Arquitectura. Funciones. ... 27
2.2 Aplicación de la entrevista para el diagnóstico. ... 28
2.2.1 Muestreo Aleatorio Estratificado ... 29
2.2.2 Distribución de la muestra. ... 32
2.2.3 Análisis de los resultados del diagnóstico ... 32
2.2.3.1 Análisis de las entrevistas realizadas a los Arquitectos ... 33
2.2.3.2 Análisis de las entrevistas realizadas a los Miembros de los Grupos Internos de Calidad ... 35
2.2.3.3 Análisis de las entrevistas realizadas a los Desarrolladores ... 37
2.2.3.4 Preguntas Generales ... 38
Valoración general ... 39
Conclusiones ... 40
Capítulo 3: Descripción del procedimiento propuesto. ... 41
3.1 Objetivos... 41
3.2 Alcance ... 42
3.3 Responsables ... 42
3.4 Referencia ... 42
3.5 Términos y Definiciones ... 42
3.6 Roles del procedimiento ... 43
3.7 Descripción general del procedimiento ... 46
3.8 Fase 1: Planificación del trabajo ... 48
3.8.1 Descripción de las Actividades. ... 49
Índice
3.9 Fase 2 Revisiones DAC ... 51
3.9.1 Descripción general de los Períodos de Revisiones ... 52
3.9.2 Relación de los Períodos de revisión y las fases Elaboración y Construcción de la metodología de desarrollo de RUP... 54
3.9.3 Actividades comunes a los períodos de revisión ... 54
3.9.4 Descripción de cada uno de los períodos de la fase Revisiones DAC. ... 60
3.9.4.1 Período de Revisión de la documentación ... 60
3.9.4.2 Período de comprobación de estándares y patrones ... 66
3.9.4.3 Revisiones de Entorno ... 71
3.10 Fase 3 Análisis de los Resultados ... 74
3.10.1 Revisión de los Resultados parciales de revisiones ... 75
3.10.2 Reunión Final ... 75
3.11 Artefactos utilizados a lo largo de la ejecución del procedimiento. ... 76
3.12 Ventajas del procedimiento……….……….………..……...77
3.13 Riesgos del procedimiento….………..………..………77
Conclusiones ... 79
CONCLUSIONES ... 80
RECOMENDACIONES ... 81
REFERENCIAS BIBLIOGRÁFICAS ... 82
BIBLIOGRAFIA ... 84
ANEXOS ... 87
GLOSARIO DE TÉRMINOS ... 117
Introducción
Introducción
En el mundo de hoy las tecnologías muestran un creciente desarrollo, se incrementan vertiginosamente las producciones de software y la competencia impone productos cada vez con mayor calidad. Para lograrlo, las organizaciones demandan la construcción de grandes y complejos sistemas de software que requieren de la combinación de diferentes componentes de hardware y software. Entre los aspectos fundamentales que hay que tener en cuenta para el diseño de un sistema se encuentra la arquitectura de software.
La arquitectura de software es una práctica joven, con apenas unos pocos años de trabajo constante y en estos momentos, experimenta una nueva ola creativa en sus técnicas. El desarrollo de la misma es una de las etapas fundamentales y, en muchos casos, la más importante en el proceso de desarrollo de software. Es aquí donde los profesionales aportan todos sus conocimientos, creatividad y experiencia para crear la mejor propuesta de solución que se le ofrecerá al cliente. Esta tendrá como premisa el cumplimiento de los requisitos funcionales y no funcionales establecidos para el sistema.
El desarrollo de un proyecto en gran escala no es recomendable que comience, si aún no ha logrado una arquitectura del sistema, incluyendo su justificación, ya que cuanto más tarde se detecten deficiencias arquitectónicas no identificadas con anterioridad, será mayor el esfuerzo empleado para corregirlas.
Dentro de los elementos críticos que debe considerar la arquitectura de software, y en los que está basado el diseño, se encuentran los requerimientos no funcionales del sistema; específicamente los atributos de calidad establecidos para el mismo. Entre estos atributos están: el desempeño, la confiabilidad, seguridad, facilidad de modificación, facilidad de uso, robustez, portabilidad, escalabilidad, reutilización, disponibilidad, entre otros.
Si una arquitectura de software es deficiente en su concepto o diseño, o en el peor de lo casos, no se encuentra definida; existen grandes posibilidades de construir un producto que no alcanzará el total de los requerimientos establecidos. Esto, pudiese ocasionar problemas y hasta el fracaso del software cuando se encuentre en
Introducción
operación. La experiencia demuestra que los proyectos exitosos consideran una arquitectura viable como un logro clave del proceso de desarrollo industrial.
En la actualidad, a pesar de que la arquitectura de software es catalogada como una de las premisas fundamentales para el desarrollo de productos informáticos, que ahorra tiempo y costo en el desarrollo de los mismos, todavía en muchas organizaciones, es un aspecto al cual no se le atribuye la importancia requerida, ni los esfuerzos necesarios, incluso algunos grupos de desarrollos elaboran sus sistemas sin tenerla en cuenta.
En Cuba se realizan grandes esfuerzos por impulsar la industria del software, para ello se hizo necesario definir una estrategia que permita dar un salto de la producción artesanal a la industrial. Como parte de la misma se crean una serie de entidades que con su aporte que deben responder al cumplimiento de dichos objetivos. Una de estas entidades es la Universidad de las Ciencias Informáticas (UCI), enfocada en la producción de software para uso nacional y de exportación, sin embargo a pesar de contar con un elevado número de personal calificado dedicados a la producción de software, no se ve exenta de las deficiencias arquitectónicas que pueden influir directamente sobre la calidad del producto final.
En esta universidad, se trabaja en base a que la arquitectura de software llegue a constituir un elemento prioritario dentro del proceso de desarrollo, que sea válido y aplicable en todos los proyectos de la misma, sin descuidar las características específicas de cada perfil de trabajo de las facultades.
De esta manera y de acuerdo a las líneas de desarrollo existentes en la facultad 7 se elaboró el Documento de Arquitectura que sigue las normas establecidas por la universidad y tiene como objetivo estandarizar algunos elementos relacionados con este tema. En el que se establecieron elementos como: el ambiente de desarrollo para cada una de las plataformas de desarrollo que se utilicen, patrones a utilizar para la estructuración del producto de software y estándares de codificación. Este documento se ha convertido en un instrumento normativo para el proceso de desarrollo de los sistemas de la facultad 7.
En este contexto, y por ser la arquitectura de software uno de los pilares básicos sobre los que se construye y mantiene cualquier aplicación, es necesario realizar un
Introducción
esfuerzo para integrar esta disciplina en el proceso de prueba. Ello permitirá verificar y definir algunos elementos relacionados con el cumplimiento de la arquitectura en los sistemas que se desarrollen, Así como una estandarización coherente en la forma en que son implementados los mecanismos y protocolos de comunicación que se establecerán entre ellos.
La arquitectura de software ser un marco de referencia para satisfacer requerimientos, una base esencial para la estimación de costos y administración del proceso y para el análisis de las dependencias y la consistencia del sistema.
Teniendo en cuenta los aspectos descritos con anterioridad se puede definir que el problema a resolver con esta investigación es la no existencia de un procedimiento que permita comprobar el cumplimiento de la arquitectura definida para los sistemas de la facultad 7.
Por lo que el objeto de estudio es la arquitectura definida para los sistemas de la facultad 7, delimitando así como el campo de acción los aspectos contenidos en el Documento de la Arquitectura de los sistemas de la facultad 7. Por tanto el objetivo general de esta investigación es elaborar un procedimiento que compruebe el cumplimiento de la arquitectura definida para los sistemas de la facultad 7.
Con vista a darle cumplimiento al objetivo planteado se han definido las siguientes tareas investigativas:
Analizar los antecedentes de este tipo de procedimiento en Cuba y el mundo.
Examinar el Documento de Arquitectura definido en la facultad 7.
Profundizar en los aspectos necesarios a tener en cuenta a la hora de elaborar un procedimiento de este tipo.
Confeccionar el procedimiento.
Con el desarrollo de la investigación se espera obtener un procedimiento que será aplicado por el grupo de Calidad de la facultad 7 como parte de su proceso de prueba para comprobar el cumplimiento de cada uno de los aspectos que forman parte de la arquitectura definida para los sistemas desarrollados en la misma.
Introducción
Este trabajo de diploma está estructurado de la siguiente forma:
Capitulo 1: Fundamentación Teórica. En este capítulo se hace alusión a los principales conceptos relacionados con la arquitectura de software profundizando en los aspectos reflejados en el documento de arquitectura de software de la facultad 7.
Capitulo 2: Situación actual de la arquitectura de software en la facultad 7. En este se realiza un análisis a partir de los resultados las entrevistas realizadas a los arquitectos, desarrolladores y a los miembros de los grupos internos de calidad de las distintas Áreas Temáticas de la facultad 7, permitiendo conocer la situación existente en torno al cumplimiento de la arquitectura de software por parte de los proyectos.
Capitulo 3: Descripción del procedimiento propuesto. Se describen las características principales del procedimiento propuesto, las fases y las actividades que se proponen para su ejecución. Así mismo se detallan los roles necesarios para una correcta aplicación del procedimiento.
Capítulo1. Fundamentación Teórica
"La manera más rápida y económica de desarrollar software es hacerlo bien".
Rodrigo Correal (1)
En este capítulo se da un enfoque abarcador acerca de los conceptos de calidad de software y se analizan los fundamentos teóricos de la investigación que permitirán conocer cómo mejorar la calidad de los procesos de desarrollo de software, a partir de la concepción y el cumplimiento de una buena arquitectura. En la realización del capítulo se responden las siguientes interrogantes: ¿Qué es la arquitectura de software?, ¿En que consiste un patrón arquitectónico?, ¿A que se denomina un estándar de comunicación?, entre otras definiciones y conceptos relacionados que definirán las bases sobre las cuales se sustentará la investigación.
1.1 Principales conceptos de la calidad de software
La calidad de software surge como resultado de fracasos que ocurren en el desarrollo de estos, que son provocados por pérdidas de tiempo y recursos para el cliente y el proveedor, así como por malos resultados de trabajo que no garantizan la satisfacción de ninguna de las dos partes. En definitivas, no se cumplen los objetivos propuestos inicialmente y es tratando de buscar una solución viable para el cumplimiento de los requisitos, que surgen métodos y vías alternativas que ofrecieron mejores resultados a esta disyuntiva.
Aunque, no fue hasta la década del 90 que estas acciones tomaron un nombre:
calidad, este término ha sido definido por muchas personalidades y organizaciones que en un fin no han logrado con exactitud conceptualizar exactamente: ¿qué es calidad de software?
Definiciones de calidad
A continuación se toman algunas definiciones de varias personalidades y organizaciones reconocidas sobre la calidad de software:
Capítulo:
Fundamentación Teórica
Capítulo1. Fundamentación Teórica
Deming en 1986 la define como: “Predecible grado de uniformidad, a bajo costo y útil para el mercado”. Lo cual es lógico teniendo en cuenta que es matemático y tratará siempre de cerrar las tolerancias buscando una mayor uniformidad del proceso. (2)
Juran, ingeniero eléctrico, hace varias definiciones de la calidad a lo largo de su carrera, desde “aptitud para el uso o propósito”, hasta 1993 en que aporta ya no una sino dos definiciones de calidad, una que se refiere al producto: “calidad es el conjunto de características de un producto que satisfacen las necesidades de los clientes y en consecuencia hacen satisfactorio el producto” y otra que se refiere a la organización:
“la calidad consiste en no tener deficiencias”. No hay la menor duda que para obtener calidad es preciso tener una organización que trabaje con calidad. (3)
Crosby en 1994 puntualiza que: calidad es “entregar a los clientes y compañeros de trabajo productos y servicios sin defectos y hacerlo a tiempo”. En este caso, considera dos tipos de clientes los internos y externos e involucra en la definición su filosofía de producir con cero defectos. (4)
Conway, consultor de calidad discípulo de Deming, en 1988 plantea que la calidad se alcanza al “desarrollar la fabricación, administración y distribución a bajo costo de producto y servicios que el cliente quiera o necesite”. Este autor en su definición hace referencia a la necesidad de observar la calidad del trabajo y desarrollar un sistema adecuado para obtenerla. (5)
Feigenbaum, presidente de la Academia Internacional de la Calidad en 1996, define la calidad como: “un sistema eficaz para integrar los esfuerzos de mejoras de la gestión de los distintos grupos de la organización para proporcionar productos y servicios a niveles que permitan la satisfacción del cliente”. (6)
Ishikawa, ingeniero químico, pionero e ideólogo indiscutible de los éxitos de la industria japonesa en materia de calidad, en 1988 manifiesta que: “calidad es aquella que cumple los requisitos de los consumidores” e incluye el costo entre estos requisitos. (7)
R. S. Pressman define la calidad como: “Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo
Capítulo1. Fundamentación Teórica
explícitamente documentados y con las características implícitas que se espera en todo software desarrollado profesionalmente”. (8)
Esta última definición sirve para hacer hincapié en tres puntos importantes:
Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
Los estándares definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
Existe un conjunto de requisitos implícitos que a menudo por estar relacionados con otros e inclusive incluidos no se mencionan (por ejemplo: lograr un buen mantenimiento).
La ISO, define la calidad como la ausencia de deficiencia:"Es la totalidad de aspectos y características de un producto o servicio que se refiere a su capacidad para satisfacer las necesidades dadas en la adecuación de sus objetivos".
Por su parte en la norma ISO 9000 se plantea que: “Calidad: es el grado en el que un conjunto de características inherentes cumple con los requisitos”.
En la norma ISO 8402(UNE 66-001-92) se define como: El conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas”. (9)
Muchas personas afirman que la calidad de software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas tales como el incumplimiento, por parte de la aplicación, de los estándares de comunicación para la transferencia de información, impidiéndose la integración con otros sistemas necesarios y/o similares, así como problemas de funcionalidad, de acceso no autorizado, mantenimiento, entre otros que puedan llegar a afectar el correcto funcionamiento del producto final. Todos estos aspectos constituyen elementos importantes de la arquitectura de un sistema software.
Capítulo1. Fundamentación Teórica
Sería oportuno especificar entonces la definición de un conjunto de conceptos de vital importancia para la investigación en cuestión: la arquitectura de software y sus elementos.
1.2 La Arquitectura de Software y conceptos relacionados Definición de la Arquitectura de Software
La arquitectura de software es el conjunto de decisiones significativas sobre la organización de un sistema, la selección de los elementos estructurales y las interfaces de las cuales el sistema está compuesto junto con su comportamiento.
Describe los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente. (10)
La misma se centra tanto en los elementos estructurales significativos del sistema, como subsistema, clases, componentes y nodos, como en las colaboraciones que tienen lugar entre estos elementos a través de las interfaces. (11)
Elementos estructurales
Un elemento estructural es cada una de las partes diferenciadas aunque vinculadas en que puede ser dividida una estructura a efectos de su diseño.
Subsistemas
Una agrupación de elementos, de los que algunos constituyen una especificación del comportamiento ofrecido por otros elementos contenidos. (12)
Los subsistemas constituyen un medio para organizar el modelo de diseño en piezas manejables. (13)
El concepto de subsistemas es muy importante, sobre todo cuando estudiamos sistemas grandes y complejos. Los subsistemas permiten dividir el sistema entero en partes más manejables y fáciles de entender.
Clase
Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. (14)
Capítulo1. Fundamentación Teórica
Componentes
Un componente es el empaquetamiento físico de los elementos de un modelo. (15)
Es una parte física y reemplazable de un sistema que se ajusta a y proporciona la realización de, un conjunto de interfaces. (16)
A modo de resumen se puede decir que un componente no es más que la agrupación de elementos que hace parte de un subsistema.
Nodo
Un elemento físico que existe en tiempo de ejecución y que representa un recurso computacional, que en general tiene al menos una memoria y a menudo capacidad de procesamiento. (17)
Colaboraciones
Una sociedad de clases, interfaces y otros elementos que trabajan juntos para proporcionar algún comportamiento cooperativo que es mayor que la suma de todos sus elementos. La especificación de como un elemento, un caso de uso, o una operación es llevada a cabo por un conjunto de clasificadores y asociaciones desempeñando roles específicos utilizados en una forma específica. (18)
Interfaz
Las interfaces constituyen una forma de separar la especificación de la funcionalidad en términos de operaciones de sus implementaciones en términos de métodos. Esta distinción hace independiente la implementación de la interfaz.
La mayoría de las interfaces se consideran relevantes para la arquitectura debido a que definen las interacciones permitidas entre los subsistemas. (19)
Capítulo1. Fundamentación Teórica
Descripción de la Arquitectura de Software
La arquitectura de software es especificada por el arquitecto en el documento de descripción de la arquitectura. La descripción de arquitectura es la encargada de permitir al arquitecto controlar el desarrollo del sistema desde la perspectiva técnica.
Esta descripción es la vista de los modelos del sistema y de casos de uso, análisis, diseño, implementación y despliegue. Describe las partes del sistema que son importante que comprendan todos los desarrolladores y otros interesados. (20)
Documento de Arquitectura
Documento elaborado con el objetivo de estandarizar algunos elementos relacionados con la arquitectura de software. Por ejemplo, el Ambiente de Desarrollo para cada una de las plataformas de desarrollo que se utilicen, patrones a utilizar para la estructuración del producto de software y estándares de codificación y comunicación.
Modelo
Descripción de las características estáticas, dinámicas o ambas de un tema presentadas en varias vistas. (21)
Una abstracción de un sistema cerrado semánticamente. (22) Procedimiento
Un procedimiento es una serie de pasos, claramente definidos, que permiten trabajar correctamente y ayudan a disminuir la probabilidad de accidentes y fallos. Es un modo de ejecutar determinadas operaciones que suelen realizarse de la misma manera.
Existen varios tipos de procedimientos, los lineales los cuales se ejecutan siempre igual y los ramificados en los cuales la pauta de ejecución está sujeta a criterios. (23)
1.3 Patrones de Arquitectura Patrón
Un patrón es un modelo que se puede seguir para realizar algo y surge de la experiencia de seres humanos de tratar de lograr ciertos objetivos, el cual permite capturar la experiencia existente y probada para promover buenas prácticas.
Capítulo1. Fundamentación Teórica
Los patrones proporcionan el problema-solución, los cuales son aplicados a un contexto en específico. Son utilizados en la solución de problemas recurrentes siendo capaces de identificar y especificar abstracciones de niveles más altos que componentes o clases individuales, proporcionando un vocabulario y entendimiento común.
Patrones de Arquitectura
Los Patrones de arquitectura se caracterizan por organizar la forma en que se comunica y rehúsa la experiencia del diseño en el desarrollo de software permitiendo así el descubrimiento de problemas recurrentes que pueden surgir en determinados contextos.
Se puede decir entonces que, un patrón de arquitectura de software es un esquema genérico probado para solucionar un problema particular recurrente que surge en un cierto contexto. Este esquema se especifica describiendo los componentes, con sus responsabilidades, relaciones y las formas en que colaboran:
Contexto:
Extiende la dicotomía problema-solución.
La descripción del contexto puede ser bastante general o muy específica.
Es muy difícil definir completamente el contexto.
Listar todas las situaciones en que el problema surge.
Problema:
El problema genérico que surge en el contexto especificado.
Esencia: ¿cuál aspecto del problema debemos resolver?
Las fuerzas describen aspectos más específicos del problema con distintos puntos de vista y hasta pueden contradecirse.
- requisitos de la solución - restricciones
- propiedades deseables
Solución:
Forma de balancear las fuerzas para resolver el problema.
Capítulo1. Fundamentación Teórica
- Estructura estática-componentes y relaciones.
- Comportamiento dinámico-forma de organización y colaboración entre los componentes.
La solución no siempre toma en cuenta todas las fuerzas. Hay prioridades si las fuerzas son contradictorias.
Un esquema de soluciones y no algo completamente definido.
1.3.1 Modelo Vista Controlador (MVC).
El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página; el modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio;
y el controlador es el responsable de recibir los eventos de entrada desde la vista.
Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos.
Un modelo puede tener diversas vistas, cada una con su correspondiente controlador.
Un ejemplo clásico es el de la información de una base de datos, que se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, entre otros. Para comprender mejor dicho patrón a continuación se describen las responsabilidades de cada componente:
El modelo es el responsable de:
Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
Definir las reglas de negocio (la funcionalidad del sistema).
Llevar un registro de las vistas y controladores del sistema.
El controlador es responsable de:
Recibir los eventos de entrada.
Contener las reglas de gestión de eventos.
Capítulo1. Fundamentación Teórica
Las vistas son responsables de:
Recibir datos del modelo y mostrárselo al usuario.
Almacenar un registro de su controlador asociado.
Proveer el servicio de "Actualización", para que sea invocado por el controlador o por el modelo.
1.3.2 Arquitectura Orientada a Servicios (SOA).
La Arquitectura Orientada a Servicios (por sus siglas en inglés SOA) supone una estrategia general de organización de los elementos de la tecnología de la información, de forma que una colección de sistemas distribuidos y aplicaciones complejas se pueda transformar en una red de recursos integrados, simplificada y sumamente flexible.
Un proyecto SOA bien ejecutado permite alinear los recursos de la tecnología de la información de forma más directa con los objetivos del equipo de trabajo, ganando así un mayor grado de integración con clientes y proveedores, proporcionando una inteligencia de negocio más precisa y más accesible con la cual se podrán adoptar mejores decisiones, y ayuda a las empresas a optimizar sus procesos internos y sus flujos de información para mejorar la productividad individual. El resultado neto es un aumento muy notable de la agilidad de la organización.
La Arquitectura SOA establece un marco de diseño para la integración de aplicaciones independientes de manera que desde la red pueda accederse a sus funcionalidades, las cuales se ofrecen como servicios. La forma más habitual de implementarla es mediante Servicios Web, una tecnología basada en estándares e independiente de la plataforma, con la que SOA puede descomponer aplicaciones monolíticas en un conjunto de servicios e implementar esta funcionalidad en forma modular.
¿Qué es un servicio exactamente?
Un servicio es una funcionalidad concreta que puede ser descubierta en la red y que describe tanto lo que puede hacer como el modo de interactuar con ella. Desde la perspectiva de la empresa, un servicio realiza una tarea concreta: puede corresponder a un proceso de negocio tan sencillo como introducir o extraer un dato como “Código del Cliente”. Pero también los servicios pueden acoplarse dentro de una aplicación
Capítulo1. Fundamentación Teórica
superior por ejemplo, “introducir datos de un pedido”, un proceso que, desde que comienza hasta que termina, puede involucrar varias aplicaciones de negocio.
1.3.3 Arquitectura multi-capas.
Esta tecnología de punta se basa en el principio esencial de cualquier sistema de información que sería Presentación o Interface, Reglas de Negocios y Datos, que están distribuidas en estaciones de trabajo y servidores, logrando repartir la carga de trabajo y obteniendo una mayor independencia de los procesos entre estas capas.
En general las estaciones de trabajo soportan la presentación visual-gráfica de los datos, constituyendo ésta la capa más cercana al usuario final. La capa intermedia la constituye aquella que maneja todo el procesamiento de las transacciones y reglas de negocios, actuando como intermediario entre las interfaces del usuario y la tercera capa que es la de datos. Esta última capa es el repositorio de los datos, administrado en potentes servidores, siendo hoy día uno de los activos más importantes de la empresa.
De esta manera se obtiene una potente plataforma en la que la representación de los datos se hace de forma agradable y con seguridad mientras la base de datos se administra con velocidad y seguridad mediante un software único asegurando consistencia en los datos y procesos y tolerancia a fallos de hardware y software, se aseguran, asimismo escalabilidad, portabilidad, conectividad e integración de la información. Así mismo es un producto con el que se garantiza soporte, compatibilidad, continuidad y escalabilidad. (24)
La ventaja de la arquitectura multi-capas comparada con una arquitectura de dos niveles es que separa hacia fuera el proceso, eso ocurre para mejorar el balance de la carga en los diversos servidores; es más escalable.
1.3.4 Arquitectura basada en componentes.
En la Arquitectura basada en componentes la interfaz constituye el elemento básico de interoperabilidad. Cada componente debe describir de forma completa las interfaces que ofrece, así como las interfaces que requiere para su operación y su correcto funcionamiento con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz. Características muy relevantes de esta
Capítulo1. Fundamentación Teórica
arquitectura son la modularidad y la reusabilidad. Sin embargo también se requiere robustez ya que los componentes han de operar en entornos mucho más heterogéneos y diversos. El desarrollo de software basado en componentes es la evolución natural de la ingeniería del software para mejorar la calidad, disminuir los tiempos de desarrollo y gestionar la creciente complejidad de los sistemas.
Este tipo de arquitectura permite la reusabilidad de servicios, reduciendo considerablemente los tiempos y costos de desarrollo de aplicaciones al utilizar servicios disponibles ya desarrollados para resolver problemáticas comunes a otras aplicaciones. Aumentando por esta razón la robustez del nuevo sistema, al utilizarse el software ya aprobado.
Por otra parte es capaz de disminuir el grado de complejidad en el proceso de integración, pues se interactúa con elementos que se abstraen de la tecnología y ubicación de los servicios.
Se debe tener en cuenta que este tipo de arquitectura permite la integración de múltiples sistemas, lo que implica una dependencia en la información gestionada por cada uno de ellos. Los sistemas integrados deben convertir al software en una solución cualitativamente superior pero no debe ser una relación de dependencia absoluta. En los casos en que se trata de aplicaciones esencialmente Web, deberán garantizarse alternativas de escritorio, para aquellas que lo requieran, o una estrategia para el trabajo mediante un caché de los datos externos de frecuente utilización. Se debe lograr además que exista entre las aplicaciones integradas un débil acoplamiento de tal forma que de producirse alguna modificación tenga la mínima repercusión en los sistemas dependientes.
1.4 Estándares de comunicación entre los sistemas.
Como se ha hecho referencia anteriormente es necesario para la aplicación de las arquitecturas propuestas que exista una estrategia bien definida para la integración, basada en estándares de comunicación reconocidos que permitan la interoperabilidad entre los sistemas de una forma coherente y satisfactoria. Cada sistema debe ser concebido considerando que los demás sistemas están conectados o no en el momento de realizar la petición.
Capítulo1. Fundamentación Teórica
Un estándar es un documento establecido por consenso, aprobado por un organismo reconocido que provee reglas, guías o características para la realización de actividades. Un estándar de comunicación entonces es un estándar en el cual importa la comunicación de un medio a otro.
Los Estándares de comunicación se utilizan para:
Evitar la necesidad de desarrollar interfaces "hechas a medida".
Permitir que el usuario seleccione los productos más adecuados a sus preferencias y necesidades entre diferentes proveedores.
Dado lo anterior, permitir que los mismos proveedores trabajen integralmente intercambiando información.
Los estándares de comunicación DICOM y HL7, van en línea con la tendencia de la Tecnología Digital, en el ámbito de la integración de sistemas de comunicación y archivos de imágenes, pues son los protocolos por excelencia, sin dejar de destacar los Servicios Web.
1.4.1 ¿Qué es DICOM?
Es la abreviación de "Comunicación e imágenes digitales" (por sus siglas en inglés DICOM), el cual es un estándar de comunicación que norma el intercambio de imágenes médicas en general, y hace posible que equipos y software de distintos fabricantes puedan operar entre sí.
DICOM es el estándar reconocido mundialmente para el intercambio de imágenes médicas, pensado para el manejo, almacenamiento, impresión y transmisión de imágenes médicas. Incluye la definición de un formato de fichero y de un protocolo de comunicación de red. El protocolo de comunicación es un protocolo de aplicación que usa TCP/IP para la comunicación entre sistemas. Los ficheros DICOM pueden intercambiarse entre dos entidades que tengan capacidad de recibir imágenes y datos de pacientes en formato DICOM.
DICOM funciona en un modelo orientado a objetos, los cuales tiene atributos y métodos (llamados servicios). La comunicación entre instancias de objetos se realiza mediante una estructura de cliente-servidor, de forma que uno de los objetos realiza una petición, y el otro objeto presta el servicio. (25)
Capítulo1. Fundamentación Teórica
Ventajas de usar DICOM:
Permite la circulación simultánea de múltiples copias de una imagen, mientras que la imagen original permanece archivada.
Reduce drásticamente los problemas de pérdidas, equivocaciones de archivado, desaparición de placas y carpetas.
Unifica el archivo para todas las imágenes.
Permite la total integración y gestión de archivos de pacientes, cuando se interrelaciona con registros de pacientes existentes.
Permite la consolidación y revisión instantánea de los registros de pacientes producidos por una variedad de tecnología de imagen.
Extiende la flexibilidad de la tecnología de imagen digital (las imágenes pueden ser modificadas, ampliadas y rotadas).
Permite el envío de las imágenes vía telefónica, por cable y satélite para poder ser consultadas desde cualquier lugar del mundo.
Permite un rápido acceso a la información.
1.4.2 ¿Qué es HL7?
El protocolo HL7, permite que las aplicaciones clínicas se comuniquen entre sí, independientemente de su plataforma tecnológica o de su lenguaje de desarrollo. Para tal fin provee modelos de mensajes que se intercambian entre las aplicaciones, en base a la ocurrencia de un evento clínico determinado (por ejemplo, el Ingreso de un paciente).
Ventajas de usar HL7:
Es independiente de la estructura de datos de los sistemas involucrados y es adaptable a lenguajes de desarrollo, sistemas operativos, arquitectura de sistemas (centralizados, distribuidos).
Permite la integración de la información de salud, a través de los servicios y del tiempo.
Permite la conectividad entre sistemas a costos competitivos.
Ofrece flexibilidad, porque puede implementarse usando diversas tecnologías de software. (26)
Capítulo1. Fundamentación Teórica
1.4.3 ¿Que son los Servicios Web?
Los Servicios Web están compuestos por un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.
Ventajas de usar los Servicios Web:
Es un estándar aceptado por los principales fabricantes de software.
Posibilita la integración de aplicaciones entre distintos lenguajes, plataformas y sistemas operativos.
Utiliza la comunicación a través de protocolo http, por lo que puede utilizar Internet.
Comparados con otros protocolos de integración, su desarrollo e implementación son bastante sencillos. (27)
Los Servicios Web utilizan los Protocolos Simple de Acceso a Objetos (por sus siglas en inglés SOAP), como protocolos para invocar llamadas remotas por su simplicidad.
1.5 Lenguajes, tecnologías, metodologías y herramientas de soporte al desarrollo
Para obtener un producto final no solo basta con definir los procesos a automatizar y la manera de hacerlo, si no que también se hace necesario especificar los lenguajes que implementarán la solución, las tecnologías que soportarán dicha solución, las metodologías que guiarán el proceso de desarrollo y las herramientas a utilizar en la obtención del producto resultante.
1.5.1 Herramientas
Las herramientas de desarrollo de software desempeñan un papel fundamental en el desarrollo de sistemas informáticos. Dentro de las mismas se encuentran las siguientes:
Capítulo1. Fundamentación Teórica
Herramientas de Gestión de Proyectos
Herramientas utilizadas para organizar y administrar recursos de manera tal que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo y coste definidos. Estas herramientas son las encargadas de facilitar el trabajo a la hora de realizar la planificación de un proyecto.
Herramientas de Control de Versiones
Herramientas que se utilizan para gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Las mismas facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas.
Estas herramientas deben proporcionar mecanismos de almacenaje de los elementos que deba gestionar, permitir la posibilidad de realizar cambios sobre los elementos almacenados y guardar un registro histórico de las acciones realizadas con cada elemento o conjunto de elementos.
Herramientas de Modelado
Herramientas utilizadas para crear una representación ideal de un objeto real mediante un conjunto de simplificaciones y abstracciones, cuya validez se pretende constatar.
Metodología de Desarrollo
Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software. Las mismas son usadas para estructurar, planear y controlar el proceso de desarrollo en sistemas de información. Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software.
1.5.2 Tecnologías Informáticas
La Tecnología Informática (por sus siglas en inglés IT), según lo definido por la asociación de la Tecnología Informática de América (por sus siglas en inglés ITAA) es
“el estudio, diseño, desarrollo, puesta en práctica, ayuda o gerencia de los sistemas
Capítulo1. Fundamentación Teórica
ocupa del uso de computadoras y del software electrónico de convertir, de almacenar, de proteger, de procesar, de transmitir y de recuperar la información. (28)
Sistema de Gestión de Base de Datos
Los sistemas de gestión de base de datos (SGBD) constituyen un tipo de software muy específico, que se dedica a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. El propósito general de estos sistemas es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante, para un buen manejo de los mismos.
Los SGBD proveen facilidades para la manipulación de grandes volúmenes de datos, las cuales bajan drásticamente los tiempos de desarrollo y aumentan la calidad del sistema desarrollado si son bien explotadas por los desarrolladores.
1.5.3 Lenguajes de programación
Los lenguajes de programación no son más que un conjunto de símbolos y reglas sintácticas y semánticas que definen su estructura y el significado de sus elementos y expresiones. Estos permiten a uno o más programadores especificar de manera precisa sobre qué datos debe operar una computadora, cómo estos datos deben ser almacenados o transmitidos y qué acciones debe tomar bajo una variada gama de circunstancias. Todo esto, a través de un lenguaje que intenta estar relativamente próximo al lenguaje humano o natural, tal como sucede con el lenguaje léxico.
Una característica relevante de los lenguajes de programación es precisamente que más de un programador puedan tener un conjunto común de instrucciones que puedan ser comprendidas entre ellos para realizar la construcción del programa de forma colaborativa.
Lenguajes de Marcas
Un lenguaje de marcado o lenguaje de marcas no es más que una forma de codificar un documento que, junto con el texto, incorpora etiquetas o marcas que contienen información adicional acerca de la estructura del texto o su presentación. El lenguaje de marcas más extendido es el HTML. Los lenguajes de marcado suelen confundirse con lenguajes de programación, sin embargo, estos no son lo mismo, ya que el
Capítulo1. Fundamentación Teórica
lenguaje de marcado no tiene funciones aritméticas o variables, como las poseen los lenguajes de programación.
1.6 Estándares de codificación
Los estándares de codificación, no son más que un término que describe convenciones para escribir código fuente en ciertos lenguajes de programación. Son pautas de programación que no están enfocadas a la lógica del programa sino a su estructura o apariencia física, para facilitar la lectura, comprensión y mantenimiento del código. O sea estilos de codificación a la hora de escribir el código. (29)
Cuando va a comenzar un proyecto de software es necesario que se establezca un estándar de codificación para asegurarse que todos los programadores del proyecto trabajen de forma coordinada.
Una faceta importante en el proceso de desarrollo de software en la que todos los programadores influyen especialmente es en la técnica de codificación. El mejor método para asegurarse de que un equipo de programadores mantenga un código de calidad es establecer un estándar de codificación sobre el que posteriormente se efectuarán revisiones del código de rutinas.
Usar técnicas de codificación sólidas y realizar buenas prácticas de programación con vistas a generar un código de alta calidad es de gran importancia para la calidad del software y para obtener un buen rendimiento. Además, si se aplica de forma continuada un estándar de codificación bien definido, se utilizan técnicas de programación apropiadas, y, posteriormente, se efectúan revisiones del código de rutinas, caben muchas posibilidades de que un proyecto de software se convierta en un sistema de software fácil de comprender y de mantener.
Los aspectos para los que generalmente se establecen estándares son los siguientes:
Identación: La identación en una buena práctica de programación que consiste en comenzar a escribir cada línea de código a diferentes distancias desde el borde izquierdo del área de texto del editor. Esta distancia está determinada por la jerarquía que se forma al introducir sentencias dentro de bloques de estructuras. Esto persigue mayor legibilidad y entendimiento para el programador e igualmente depende del
Capítulo1. Fundamentación Teórica
propio estilo de cada persona y del lenguaje y tipo de programa que se implementa.
(30)
Llaves: Son las encargadas de delimitar el cuerpo de los bloques de código que contienen este tipo de estructuras. Algunos programadores prefieren hacerlo ubicando la llave de apertura inmediatamente detrás de la línea cabecera del bloque, mientras otros apuestan por ubicarlas de forma solitaria en la línea siguiente a la línea cabecera. Para este último estilo existen además diferencias en cuanto al nivel de identación de las mismas. Algunos lo hacen al nivel de la línea cabecera y otros al nivel de las líneas del cuerpo del bloque. De igual forma algunos prefieren usar siempre las llaves mientras otros prefieren aprovechar las ventajas del lenguaje obviándolas en los casos que el cuerpo del bloque contenga solo una sentencia.
Para este trabajo: las llaves de apertura se colocarán solitarias en la línea siguiente e indentadas al nivel de la línea cabecera del bloque. Las llaves de cierre se colocarán solitarias en la línea que sigue a la última línea dentro del bloque e identadas al nivel de la línea cabecera del bloque. En el caso de cuerpos de bloque con una sola sentencia se podrá o no usar las llaves a gusto del programador. Es prudente señalar que este estilo agrega más líneas de código al programa al ubicar las llaves solitarias en una línea, pero a su vez se gana en legibilidad del código. Es por eso que no existe una definición exacta de cual seria una buena práctica de programación en el uso de llaves debido a que cada método tiene ventajas y desventajas. (31)
Comentarios: El uso de comentarios durante la codificación puede parecer innecesario y que atrasa el proceso. Se ha demostrado, sin embargo, que esta práctica es beneficiosa por varias razones: ayuda al programador a entender cada elemento o sección de código. Ayuda a adaptar el código durante su reutilización.
Sirve de guía en los casos en que varios programadores trabajen sobre las mismas secciones del código.
Los comentarios se pueden utilizar para varios fines: se utilizan para explicar el propósito de las funciones. Para explicar las características fundamentales de las clases. Para sintetizar las acciones de los algoritmos complejos. Para aclarar los datos que representan las variables. Para dividir secciones de código en dependencia de los diferentes contextos. Para dejar constancia del autor y algunas condiciones en que se generó el código. A veces, se usan comentarios temporales para recordar cosas que faltan, se deben modificar o analizar en otro momento. (32)
Capítulo1. Fundamentación Teórica
Líneas y espacios en blanco: Para mejorar la legibilidad del código muchas veces se utilizan líneas en blanco para separar segmentos de código que pueden corresponder a clases, funciones, declaraciones, implementaciones, comentarios, bloques o sencillamente secciones criticas que se deseen despejar. Así mismo sucede con los espacios en blanco cuando se utilizan para separar elementos dentro de las sentencias de código. A veces se separan con espacios cada operador de su respectivo operando, paréntesis, identificadores, símbolos y algunos lenguajes exigen que se separen las palabras propias del vocabulario de las adyacentes para ser comprendidas por los compiladores.
El uso de líneas en blanco incrementa la longitud en líneas de código del programa y el uso de espacios en blanco incrementa la longitud de cada línea de código del programa. Esto, sin embargo, mejora la legibilidad del código. Es por esto que se deben establecer los estándares de conjunta aprobación entre los miembros del equipo de programadores. (33)
Variables y Constantes: En programación, las variables son estructuras de datos que, como su nombre indica, pueden cambiar de contenido a lo largo de la ejecución de un programa. Una variable corresponde a un área reservada en la memoria principal del ordenador. Una constante es un dato cuyo valor no puede cambiar durante la ejecución del programa. Recibe un valor en el momento de la compilación y este permanece inalterado durante todo el programa. Estandarizar su apariencia es importante pues ayuda a la legibilidad del código. Cada estándar de codificación tiene su propia manera de declararlas. El nombre empleado para la misma debe de permitir que con solo leerlo se conozca el propósito de la misma.
Clases: Una clase es un contenedor de uno o más datos (variables o propiedades) junto a las operaciones de manipulación de dichos datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje. Además las clases son agrupaciones de objetos que describen su comportamiento. El nombre empleado para la misma debe de permitir que con solo leerlo se conozca el propósito de esta.
Capítulo1. Fundamentación Teórica
Objetos: Se define como la unidad que en tiempo de ejecución realiza las tareas de un programa. También a un nivel más básico se define como la instancia de una clase. Estos objetos interactúan unos con otros, en contraposición a la visión tradicional en la cual un programa es una colección de subrutinas (funciones o procedimientos), o simplemente una lista de instrucciones para el computador. Cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a otros objetos de manera similar a un servicio. En el mundo de la programación orientada a objetos (POO), un objeto es el resultado de la instanciación de una clase. El nombre empleado para la misma debe de permitir que con solo leerlo se conozca su propósito.
Atributos: Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método. El nombre empleado para la misma debe de permitir que con solo leerlo se conozca el propósito para el cual fue empleado.
Funciones o Métodos: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema. El nombre que se defina para la misma debe de permitir que con solo leerlo se conozca para qué fue empleado.
Controles: Los controles no son más que los componentes que se utilizan en el diseño de la interfaz visual. El nombre de cada control que intervenga en el diseño de la interfaz visual estará compuesto por un sufijo seguido de una palabra que exprese su acción, dato que contenga o el contexto en que se ubica. (34)
Conclusiones
En este capítulo se analizaron una serie de conceptos, los cuales al estar estrechamente vinculados permitirán la comprensión de los distintos temas tratados durante la investigación.
A partir del estudio de los mismos y la identificación de sus relaciones e impactos en el desarrollo de software se evidencia la idea de que a pesar de contar con una arquitectura de software completa y flexible, capaz de incorporar nuevas funciones
Capítulo1. Fundamentación Teórica
soportando la reutilización de código, no significa que se haya implementado una arquitectura válida de acuerdo a las características y propósitos del sistema en cuestión.
Es por ello y como consecuencia de la importancia de la arquitectura de software, que en cada fase de desarrollo del producto deben ser elementos verificables: los patrones de arquitectura, los estándares de comunicación, las tecnologías, las herramientas, las metodologías, los lenguajes de programación y los estándares de codificación. Así como las herramientas, procedimientos y técnicas que deben ser utilizadas con tal propósito.
Capítulo2. Situación actual de la AS en la Facultad 7
“… lo que da al hombre el poder no es el mero conocimiento que viene del uso de los sentidos, sino, ese otro conocimiento más profundo que se llama Ciencia.”
José Martí (35)
En el presente capítulo se realiza un análisis de la situación actual de la arquitectura de software en la facultad 7, para el cual se comienza con el estudio de la producción de software en dicha facultad. Se realiza una caracterización a la arquitectura de software en la facultad y se culmina con un análisis de la entrevista estructurada realizada a los arquitectos y a los miembros de los grupos internos de calidad de las áreas temáticas de esta facultad, así como también a una parte de los desarrolladores de los proyectos de la misma.
2.1 Producción de software en la facultad 7
Con el fin de identificar mejor los perfiles existentes y darle seguimiento a los distintos proyectos de la facultad 7, la producción de software en la facultad 7 está dividida en dos polos productivos, el polo de Informática para la salud y el polo de Procesamiento de Imágenes y Señales.
El objetivo principal de estos polos productivos es la elaboración de software vinculados esencialmente con la salud, aunque el perfil de imágenes diseña sistemas para otros sectores. Los mismos están divididos en 6 áreas temáticas que no son más que la unión de varios proyectos afines al polo en el cual se encuentra insertado, además del área temática de calidad, la cual es atendida directamente por la dirección central de calidad en la Universidad y se encuentra relacionada con todos los proyectos de la facultad, pues es la encargada de la revisión del cumplimiento de sus requerimientos.
En la figura 2.1 se muestra la estructura actual de la facultad 7, comenzando por la dirección de la facultad hasta cada uno de los miembros de los proyectos productivos de las distintas áreas temáticas.
Capítulo Situación actual de la Arquitectura de Software
en la Facultad 7
Capítulo2. Situación actual de la AS en la Facultad 7
Figura 2.1 Estructura de Producción de la facultad 7 Caracterización de la arquitectura de software en la facultad 7
La arquitectura de software en la facultad 7 constituye un elemento priorizado debido a la importancia que la misma tiene en el proceso de desarrollo de software. Con el objetivo de aunar esfuerzos y compartir experiencias se han venido realizando algunos cambios y avances, el más significativo es el Grupo de Tecnologías y Arquitectura, quien tiene como tarea principal la toma de decisiones técnicas que contribuyen al continuo y gradual perfeccionamiento del desarrollo de software en la facultad.
Grupo de Tecnologías y Arquitectura. Funciones
El Grupo de Tecnologías y Arquitectura de la facultad cuenta entre sus miembros con el vicedecano de producción, además de los jefes de área temática, los arquitectos y analistas principales de cada área temática. El mismo se reúne con una periodicidad quincenal alternando con el Consejo de Producción de la facultad y es dirigido por el Asesor de Arquitectura y Tecnologías de la facultad. Este grupo tiene la tarea de coordinar y definir todas aquellas decisiones técnicas asociadas al proceso productivo, lográndose una homogenización en las herramientas, tecnologías, metodologías y procedimientos afines, además el mismo debe evitar que se dupliquen esfuerzos por los desarrolladores que estén realizando las mismas tareas contribuyendo a una gestión de la configuración eficiente. (36)
Capítulo2. Situación actual de la AS en la Facultad 7
Entre sus funciones se encuentran:
Plantear la estrategia a seguir en cuanto a tecnologías y lenguajes de programación para el desarrollo de los diferentes sistemas que se encuentren en la facultad (homogeneidad).
Garantizar el cumplimiento del uso de la tecnología y lenguajes, incluyendo las versiones.
Trazar la estrategia para la vinculación docencia-producción en cuanto al uso de las tecnologías y los lenguajes. Velar por su cumplimiento.
Organizar y definir la imagen que se pondrá en los laboratorios docentes y en las aulas de la facultad. Velar por su uso e integridad.
Organizar en conjunto con el Área de Calidad el montaje y uso del servidor de salvas de la facultad.
Plan de Migración.
Con el fin de estandarizar los distintos proyectos de la facultad 7, para que todos trabajen sobre la misma base así como proporcionar un mejor entendimiento y una mayor integración entre los mismos, el Grupo de Tecnologías y Arquitectura, elabora un Documento de Arquitectura, en el cual recogen los objetivos para lo cual fue creado este equipo de trabajo.
El Documento de Arquitectura tendrá un periodo de validez de 6 meses a partir de su aprobación, momento en el cual el Grupo de Tecnologías y Arquitectura deberá incluir un punto en el Consejo Técnico que consistirá en una revisión del Documento por cambios significativos de las herramientas o tecnologías, evolución de las versiones descritas en el mismo así como una evaluación de la aplicación de las mismas en el rendimiento y productividad de los equipos de desarrollo.
2.2 Aplicación de la entrevista para el diagnóstico.
De los instrumentos para la recolección de información, se utiliza específicamente la entrevista, por ser uno de los más básicos y capaz de obtener de manera ordenada la información referente a los aspectos importantes que intervienen en la investigación, sustraídos de las preguntas respondidas.
Capítulo2. Situación actual de la AS en la Facultad 7
La entrevista es una conversación planificada entre el investigador y el entrevistado para obtener información. Su uso constituye un medio para el conocimiento cualitativo de los fenómenos o sobre características personales del entrevistado y puede influir en determinados aspectos de la conducta humana por lo que es importante una buena comunicación.
El investigador debe tener clara las hipótesis de trabajo y las relaciones que se quieren demostrar entre las variables, para poder elaborar el cuestionario de la entrevista y seleccionar el método estadístico más apropiado para procesar los datos obtenidos y lograr los objetivos propuestos.
La entrevista puede ser individual o colectiva, en ambos casos el entrevistador debe realizar una preparación previa sobre el tema a tratar, y elaborar una guía para su desarrollo.
La entrevista puede ser estructurada o no estructurada. La primera se basa en un cuestionamiento fijo, determinado y es aplicado a personas que no son especialistas en el tema; la no estructurada es más abierta que la estructurada, prevé el tema pero no lleva un cuestionario rígido y puede variar de una persona a otra, es más flexible.
Se aplica a especialistas en el tema, es una forma de obtener criterios de expertos.
(37)
La entrevista fue realizada a 39 estudiantes y 19 profesores de la facultad 7. Estuvo conformada por una serie de preguntas debidamente preparadas y ordenadas relacionadas con la arquitectura de software en la facultad. Estuvieron enfocadas para obtener una visión profunda del estado actual de la misma en los proyectos de dicha facultad.
En la misma participaron distintos niveles de los grupos de desarrollo de las seis áreas temáticas de la facultad 7, quienes debían responder las preguntas realizadas, las cuales proporcionan importantes resultados para la realización del posterior análisis de las mismas.
2.2.1 Muestreo Aleatorio Estratificado
Para determinar la cantidad de personas que serán entrevistadas, en los proyectos productivos de la facultad 7 se utilizó el método estadístico Muestreo Aleatorio Estratificado.
Capítulo2. Situación actual de la AS en la Facultad 7
El Muestreo Aleatorio Estratificado consiste en subdividir la población en subpoblaciones de tal forma que la unión de ellos será la población, y la intersección de cualquiera de los dos dará como resultado el conjunto vacío, es decir, no tendrán elementos comunes.
A las subpoblaciones se les llaman estratos, se trata de conformar estos de modo que los elementos dentro de ellas sean homogéneos. El tamaño de la muestra se distribuirá entre los estratos, en función de distintos criterios, pero lo que caracteriza al Muestreo Aleatorio Estratificado es la selección de la muestra de cada estrato.
La población para la muestra es el total de estudiantes que hay en los proyectos de la facultad 7, para ser más preciso dicha población es de 443 personas.
Notación
Se supone que la población consta de n unidades y están distribuidas en L estratos, constituyen una partición de la población; se representará por Nh en el ni de u en el estado h-ésimo, de aquí:
Total de población:
Fracción de muestreo del estrato:
Si el tamaño de la muestra de los estratos se distribuye proporcionalmente al número de unidades en el estrato, es decir si se cumple que:
Capítulo2. Situación actual de la AS en la Facultad 7
Para todo h. En este caso se dice que la distribución de la muestra se ha hecho con asignación proporcional.
Para la determinación del tamaño de muestra de una población con S2 desconocida se puede determinar mediante la expresión:
Donde:
1-α: Nivel de confianza
z1: Percentil de la distribución normal
d: Error absoluto
P: Proporción de la población N: Tamaño de la muestra
Realizando el cálculo del tamaño de muestra para un nivel de confianza 1-α=90%, con un error absoluto d=0.10, se obtiene un percentil de la distribución normal z1=1.64 y se asume como proporción de la población P=0.5, N=443 que es la cantidad total de los integrantes de los proyectos de la facultad 7; se obtiene que:
