Metodología de Desarrollo de Sistemas

Metodología de Desarrollo de Sistemas ALFA
α
MDS-
VERSION 1.0
Ministerio de Economía y Finanzas Públicas - Bolivia
Unidad de Tecnologías de Información - UTI
Control de Calidad y Seguridad Informática - CCSI
2009
Metodología de Desarrollo de Sistemas ALFA
MDS
-α
VERSION 1.0
Ministerio de Economía y Finanzas Públicas - Bolivia
Unidad de Tecnologías de Información - UTI
Control de Calidad y Seguridad Informática - CCSI
Copyleft 2009 – UTI – Licencia Abierta
Todo el material escrito en el presente documento se encuentra bajo licencia de
Documentación Libre GNU, por lo tanto es libre de copiar, distribuir, modificar y ajustar este
texto de manera conveniente. La licencia puede ser consultada en la dirección web
http://www.gnu.org/copyleft/copyleft.es.html y otras referencias pueden encontrarse en
http://es.wikipedia.org/wiki/Copyleft
El ingeniero de software amateur se encuentra siempre en la búsqueda de
algún método o herramienta mágica cuya aplicación prometa transformar el
desarrollo de software en algo trivial. Lo que distingue a un ingeniero de
software profesional es el convencimiento de que no existe semejante panacea.
[Grady Booch]
Metodología MDS-α
INTRODUCCIÓN
METODOLOGÍAS
Las metodologías para el desarrollo de sistemas ayudan a la construcción de software con un
importante aporte de calidad, señalando los diferentes pasos y actividades a realizar hasta lograr el
producto buscado. Tal producto tiene origen de la necesidad de los usuarios para soportar procesos
importantes de las actividades que estos últimos realizan, como ser: almacenamiento masivo de
información, seguimiento y control de los diferentes procesos automatizados, cálculos periódicos y
precisos, emisión de reportes actuales e históricos, etc.
Por lo general estas metodologías solo contemplan los términos técnicos de la creación de software,
abarcando así las etapas conocidas como análisis, diseño, implementación e implantación, desde
diferentes enfoques.
METODOLOGÍA DE DESARROLLO DE SISTEMAS ALFA (MDS-α)
La Metodología de Desarrollo de Sistemas ALFA o simplemente MDS - α, fue concebida para abarcar
temas adicionales que otras metodologías dejaron de lado, como así también para brindar una
herramienta formal de desarrollo de software en el Ministerio de Economía y Finanzas Públicas de
Bolivia, y que a partir de esta pueda transformarse en un estándar a nivel público.
Su nombre alude a la noción de que todo tiene un inicio, una necesidad que debe ser planteada
desde su esquema base y que antes de comenzar un desarrollo de software a ciegas, se debe
contemplar los pasos de origen del mismo. Es así como está conceptualizada la presente
metodología, desde la necesidad de plantear una determinada problemática con una visión de
gestión de proyectos, hasta la concepción del producto y su debido mantenimiento.
Además, en el Ministerio señalado como así también ocurre en otras entidades públicas, no existe un
criterio metodológico de desarrollo de software por sus respectivas Unidades de Sistemas, y mucho
menos hablar de la documentación de los mismos. Debido a esta última circunstancia, cuántos
sistemas no tendrán el soporte suficiente para un adecuado funcionamiento, cuántos se habrán
discontinuado, cuántos se habrán sobredimensionado, y tantas otras cosas más; provocando como
Unidad de Tecnologías de Información
1
Metodología MDS-α
consecuencia general que se ignore el aspecto tecnológico informático en la mayoría de
organizaciones tanto a nivel público como privado. Por ello nace MDS - α, para ordenar y cimentar el
aspecto técnico del desarrollo de sistemas con tópicos fuertes en la calidad de los mismos.
A diferencia de otras metodologías, se hace énfasis en el tratamiento de proyectos informáticos y su
adecuado planteamiento por parte de las diferentes Unidades o Usuarios solicitantes, este es el
insumo necesario para todo profesional informático y que a partir de esta información se pueda
hacer un buen dimensionamiento del sistema a desarrollar. Así también se puso un enfoque muy
fuerte en la etapa de análisis de los sistemas con temas tales como requerimientos, especificaciones y
arquitectura de software y sus herramientas de aplicación.
Todos los procesos del ciclo de vida de desarrollo de software están contemplados bajo tópicos de
calidad, permitiendo de esta manera sistemas eficientes, íntegros, coherentes, mantenibles, u otras
características.
Las metodologías que sirvieron de base son:
§
METRICA Versión 3
§
Me Rinde
§
MDSI (Metodología de Desarrollo de Sistemas de Información)
§
RUP (Rational Unified Process)
§
RUP Pequeño
ORGANIZACION
El capítulo 1, enfoca que los proyectos del rubro tecnológico son también proyectos de inversión y
que su criterio de evaluación estará relacionado con el de costo – beneficio. Conceptualiza las ideas
generales que se deben tener en cuenta para un planteamiento de un proyecto, en los costos que se
suscitarán y en los beneficios que se esperan de él.
El capítulo 2, se refiere a los diferentes pasos de la formulación del proyecto que debe preparar cada
unidad solicitante; logrando de esta manera consolidar la problemática que envuelve el desarrollo y
ejecución de un proyecto tecnológico. Esta documentación sirve como medio de justificación para
atender las diferentes demandas y su correspondiente necesidad de atención ante las diferentes
autoridades de la entidad; así también introduce al profesional en sistemas en el entorno en que se
Unidad de Tecnologías de Información
2
Metodología MDS-α
desenvolverá y de manera inicial lograr hacer un adecuado dimensionamiento y planificar sus
respectivos tiempos de solución. Este capítulo tiene cuatro anexos que corresponden a: formulación
del problema mediante el método del árbol causa y efecto – Anexo 1, definición de procesos y
procedimientos – Anexo 2, estimación de costos y beneficios – Anexo 3 y la creación de la matriz del
marco lógico – Anexo 4.
El capítulo 3, trata de los requerimientos de software que de acuerdo al capítulo 2 y la ingeniería de
requerimientos aplicada con los usuarios del sistema, se podrá llenar la correspondiente plantilla que
se exige en este capítulo. Adicionalmente está sección cita en el Anexo 5 un número considerable de
herramientas que se pueden utilizar en la cita técnica.
El capítulo 4, está dedicado a las especificaciones de software, las cuales se obtienen a partir del
estudio completo de los requerimientos previstos en el anterior capítulo; su finalidad es la disposición
del modelado de negocios, el diagrama de contexto, los casos de usos, el documento de
especificaciones de software y el diagrama de flujo de datos.
El capítulo 5, brinda el soporte teórico suficiente para diseñar la arquitectura del software que a estas
se tiene claramente especificado, eligiendo para ello un modelo acorde a las necesidades de diseño;
acompaña a este capítulo el Anexo 6, en la cual se cita a los patrones o estilos arquitectónicos más
usados en la actualidad.
El capítulo 6, aborda el tema del diseño y modelamiento del sistema, exigiendo para ello el diseño de
la interface de usuario, el modelo conceptual del sistema que dependiendo de que si el diseño es
estructurado u orientado a objetos el diagrama a utilizar será ó entidad-relación ó el de clases
respectivamente, el modelo lógico en base a las reglas del modelo relacional y el modelo físico de
acuerdo al diccionario de datos de cada relación establecida en el modelo anterior.
El capítulo 7, resalta la planificación que el arquitecto de software ha realizado para empezar la etapa
de implementación, la cual ésta relacionada en la traducción de los esquemas del modelo físico en
una Base de Datos, los aspectos de configuración y los de codificación de los diferentes componentes
del sistema en cuestión. Así también se incluye en esta sección las convenciones de codificación que
se utilizarán para hacer mas legibles y entendibles los códigos fuentes de los diferentes programas.
Unidad de Tecnologías de Información
3
Metodología MDS-α
El capítulo 8, está enfocado al tema de las pruebas del sistema, resaltando que no es una prueba de la
calidad del software; se resalta que debe realizarse una planificación para llevar adelante esta
actividad en base fundamentalmente a la funcionalidad, fiabilidad y rendimiento del sistema.
El capítulo 9, se refiere a los aspectos primordiales en la implantación del sistema, requiriendo para
ello la confección de un adecuado plan de implantación, la capacitación de los diferentes usuarios
como medio de réplica y transmisión conocimientos, la confección del manual de instalación y del
manual de usuario como soportes físicos de colaboración.
El capítulo 10, está dedicado al mantenimiento del sistema, cuya misión más importante es el de
gestionar las diferentes versiones del sistema, para ello se mantiene un catálogo de todos los
registros de peticiones y que de acuerdo a su tipo puede ser catalogado como mantenimiento
correctivo, evolutivo, adaptativo o perfectivo. Todo este proceso debe cumplir con una rigurosa
documentación que demuestre los diferentes hechos suscitados.
Por último el capítulo 11, se refiere al plan de aseguramiento de calidad del software el cual debe ser
diseñado antes de comenzar el desarrollo del producto, para ello debe realizarse una planificación
sistemática de cada requerimiento de calidad que se pretende ver en la aplicación informática a
implementar.
APLICACIÓN METODOLÓGICA
En esta sección definiremos 3 formas elementales de cómo aplicar la presente metodología ante
diferentes proyectos según la naturaleza de cada uno de ellos.
Aplicación Lineal
Se utiliza generalmente para proyectos pequeños en donde cada etapa fue conceptualizada de forma
cabal y en acuerdo con todos los participantes del proyecto.
Cap. 1 y 2
Cap. 10
Cap. 3
Cap. 9
Cap. 4
Cap. 11
Cap. 5
Cap. 8
Cap. 7
Cap. 6
Graf. I-1: Aplicación Lineal
Unidad de Tecnologías de Información
4
Metodología MDS-α
Aplicación Cíclica
Se utiliza generalmente para proyectos de mediana envergadura, donde el desarrollo es por
componentes separados e igualmente bajo un enfoque cabal de cada subsistema.
Cap. 1 y 2
Cap. 3
Cap. 10
Cap. 9
Cap. 4
Cap. 11
Cap. 5
Cap. 8
Cap. 7
Cap. 6
Graf. I-2: Aplicación Cíclica
Aplicación Iterativa por Fases
Su aplicación no es exclusiva para proyectos grandes; este modo se ajusta a la mayoría de los
proyectos y su dinamismo permite regular cada una de las anteriores etapas al efectuar un número
determinado de iteraciones en cada fase.
FASES
Inicio
Elaboración
Construcción
Transición
Cap. 1 y 2
Cap. 3
Cap. 4
Cap. 11
Cap. 5
Cap. 6
Cap. 7
Cap. 8
Cap. 9
Cap. 10
ITERACIONES
Iter. Inicio
Iter. E1
Iter. E2
Iter. C1
Iter. C2
Iter. C3
Iter. T1
Iter. T2
Tabla I-1: Aplicación Iterativa por Fases
Fase de Inicio: Define el alcance del proyecto.
Fase de Elaboración: Abarca el plan del proyecto, especificaciones y arquitectura base.
Fase de Construcción: Se construye el producto.
Fase de Transición: Disposición del producto a los respectivos usuarios.
Unidad de Tecnologías de Información
5
Metodología MDS-α
Iteraciones: Cada fase puede dividirse en iteraciones; cada iteración representa un ciclo de desarrollo
completo; ocasionando como resultado un entregable del producto final.
Guía Rápida de la Metodología ALFA
Para cualquier aplicación metodológica elegida, se describe cada una de las etapas de acuerdo al un
marco de trabajo en un proyecto informático.
Capítulo 1 y 2: Bases de un proyecto de desarrollo de sistemas – Preparación del proyecto de
desarrollo de sistemas.
Propósito: La unidad solicitante es la encargada del desarrollo de esta sección y coordinara su
labor en ciertos aspectos técnicos y la planificación de actividades respecto a los tiempos de
ejecución del proyecto con la Unidad de Tecnologías de Información.
§ Este capítulo trata de ubicar a la unidad solicitante y a los usuarios en general acerca de los
temas que involucra los proyectos de inversión y en particular los proyectos informáticos.
§ Medio de transmisión de la problemática que envuelve al entorno y de inducción al
profesional informático en el tema en cuestión.
§ Justificar la necesidad de implementación de una solución informática a diferentes instancias.
Resultado: La unidad solicitante debe hacer llegar esta documentación para dar inicio formal al
proyecto informático.
§ Documento que refleje la formulación o preparación del proyecto informático.
Capítulo 3: Requerimientos de software.
Propósito: Utilizando el material provisto por la unidad solicitante y aplicando técnicas de
ingeniería de requerimientos el profesional en desarrollo de software deberá captar todos los
requerimientos para el sistema en cuestión; así también abordar y describir el entorno en que se
desenvolverá.
Resultado: Documento de Visión y Alcance del Proyecto.
Unidad de Tecnologías de Información
6
Metodología MDS-α
Capítulo 4: Especificaciones de software.
Propósito: En base a la visión y alcance del proyecto, haciendo énfasis en los requerimientos
brindados en la etapa anterior, el profesional en sistemas deberá refinar estos últimos
conjuntamente con los usuarios y de esa manera contextualizar formalmente el escenario del
software a desarrollar.
Resultado: Se pide la conformación de:
§ El modelado de negocios.
§ El diagrama de contexto.
§ Los casos de uso.
§ El documento de especificaciones de software.
§ Y el diagrama de flujo de datos.
Capítulo 11: Plan de aseguramiento de la calidad.
Propósito: Una vez conocido el entorno de trabajo y el correspondiente análisis realizado en las
etapas anteriores, se puede concentrar en los diferentes atributos de calidad que deberá tener el
software a desarrollar. En esta etapa deben participar los distintos actores involucrados en el
proyecto como ser: los desarrolladores, los usuarios, el arquitecto de software, el personal de
control de calidad, etc.
Resultado: Conformar el documento de Plan de Calidad.
Capítulo 5: Arquitectura de software.
Propósito: Dadas las pautas de calidad y el correspondiente análisis del sistema, se debe
formalizar las estructuras base que cimentarán el soporte del software a desarrollar. En esta
actividad participan principalmente el arquitecto de software y los desarrolladores.
Resultado: Conformar la arquitectura de software del sistema a desarrollar.
Unidad de Tecnologías de Información
7
Metodología MDS-α
Capítulo 6: Diseño y modelamiento.
Propósito: Concretar formalmente el diseño y modelamiento del sistema en base a las
especificaciones y arquitectura de software. Esta etapa es enteramente cumplida por el
profesional en desarrollo de sistemas.
Resultado: Debe consolidarse los siguientes productos:
§ La interface de usuario.
§ El modelo conceptual.
§ El modelo lógico.
§ El modelo físico.
Capítulo 7: Implementación.
Propósito: En base al diseño del sistema, consolidar todos los objetos necesarios en un Gestor de
Base Datos (tablas, vistas, procedimientos almacenados, funciones, disparadores, tareas
programadas, etc), e implementar el código fuente de las diferentes funcionalidades que tendrá
el sistema en cuestión.
Resultado: Código fuente, ejecutables u otros del sistema requerido.
Capítulo 8: Pruebas.
Propósito: Esta actividad se la puede llevar de manera paralela al momento de realizar la
implementación (pruebas de unidad). Su fin es el de detectar errores y anomalías en general que
sean perjudiciales principalmente a la funcionalidad, fiabilidad y rendimiento del sistema.
Resultado: Conformar el Plan de Pruebas.
Capítulo 9: Implantación del sistema.
Propósito: Se trata de colocar el sistema en un ambiente de producción. Esta actividad se la
realiza luego de haber pasado claramente el plan de pruebas.
Unidad de Tecnologías de Información
8
Metodología MDS-α
Resultado: Se exige mínimamente:
§ Un plan de implantación.
§ Capacitación de los diferentes usuarios según sus roles.
§ Disponer de un manual de instalación.
§ Disponer de un manual de usuario.
Capítulo 10: Mantenimiento del sistema.
Propósito: Dar continuidad a la vida y explotación del sistema, posibilitando su adecuación a los
requerimientos iniciales como así también la creación de las nuevas funcionalidades que se
exigen como forma de adaptabilidad al dinamismo del entorno.
Resultado: Disposición de las nuevas versiones del sistema manteniendo para ello un adecuado
catálogo de registros a las diferentes peticiones de cambio.
Unidad de Tecnologías de Información
9
Metodología MDS-α
CAPITULO 1
1 BASES DE UN PROYECTO DE DESARROLLO DE SISTEMAS
El desarrollo de sistemas y de software en general no es una tarea sencilla y mucho menos un
proceso trivial. Para construirlo en forma exitosa es fundamental manejar una amplia variedad de
métodos, técnicas y herramientas; para ello es necesario tener una visión clara e integral de todo el
proceso, en donde la participación del usuario, cliente o beneficiarios es de fundamental importancia.
Las tendencias actuales ponen mayor énfasis que en el proceso de desarrollo de software los
participantes no solamente son los profesionales informáticos, sino también los distintos actores que
cubren el entorno del sistema (usuarios, analistas, programadores, depuradores, gerentes, etc.)
Como estrategia lógica de todo proyecto informático, debe presentarse a la Unidad de Tecnologías de
Información (UTI) la documentación correspondiente a la preparación y evaluación del proyecto a
llevarse a cabo, así mediante esta información se pueda dimensionar más apropiadamente el trabajo a
realizar.
Las herramientas que se utilizarán en los capítulos 2 permitirán a los distintos solicitantes de proyectos
de informática lo siguiente:
§
Presentación correcta de un proyecto de tecnologías de información
§
Presentación de alternativas de solución (si existe más de una)
§
Evaluación de la(s) alternativa(s) de solución mediante el criterio costo - eficiencia
Entonces debe prepararse un documento base, que debe ser presentado a la UTI1, con el propósito de
que esta Unidad tenga el respaldo documentario del proyecto correspondiente, revisar el mismo para su
análisis, aprobación y posibilitar su continuidad según los lineamientos tecnológicos de la entidad.
Además como se puede advertir, la preparación y evaluación indicada en las siguientes secciones, no
solamente puede ser utilizada para plantear soluciones de desarrollo de sistemas, sino su ámbito es más
general, por ejemplo se puede realizar el planteamiento de: fortalecer a diferentes unidades de la
1
UTI - Unidad de Tecnologías de Información de una entidad
Unidad de Tecnologías de Información
10
Metodología MDS-α
institución de equipos de computación, instalación de un centro de cómputo, implantación de una
Intranet, definición de nuevos servicios IP, etc.
Si la UTI es la unidad encargada de desarrollar el proyecto, presentará un dimensionamiento del mismo
de acuerdo al problema central y los requerimientos manifestados en el planteamiento de dicho
proyecto.
En relación a proyectos de tecnologías de información se mencionan algunos problemas en las áreas
estratégica, táctica y operacional.
A nivel estratégico: Uno de los activos más importantes de las organizaciones actuales es la
información y la tecnología que la soporta, por lo tanto la tecnología implementada debe apoyar la
definición estratégica de la organización con respecto a la información, administrando la misma en
función de la generación de conocimiento. Por lo general en las instituciones de nuestro país
(públicas o privadas) se aprecia la falta de definiciones estratégicas con respecto al tratamiento de la
información.
A nivel táctico: Existe un marcado descuido en el área informática respecto a temas de calidad, por
ejemplo cuando existen licitaciones la principal variable de elección es el precio, o cuando se debe
entregar un sistema su variable de peso es el tiempo, en cuestiones de aceptabilidad de una
aplicación informática su variable más preciada es una interfaz bonita, etc. Quedan de lado temas
tales como la reusabilidad del código, su mantenibilidad y peor aún cuando se define a priori la
solución informática a implementar sin siquiera haber hecho un levantamiento de requerimientos
adecuado. También es usual que no existan respaldos de la información que es estratégica para la
organización, así también se le da más importancia a la tecnología que a la propia gestión del
proyecto.
A nivel operacional: El principal problema es la inexistencia de documentación de los diferentes
sistemas informáticos (este es un problema muy generalizado en las distintas instituciones de nuestro
país). Esta situación es comparable a construir un edificio sin haber hecho previamente los planos.
Posiblemente las diferentes circunstancias del desarrollo del sistema condujo a este hecho, pero una
unidad seria en tecnologías de información debe empezar por realizar este proceso con los diferentes
sistemas que están a su cargo. Otra falencia a nivel operacional es la inexistencia de programas
fuentes, es decir que no se dispone del código madre o que el mismo no es entendible. Así también
Unidad de Tecnologías de Información
11
Metodología MDS-α
los diferentes servicios no están correctamente instalados y consecuentemente aplicaciones en
ejecución con demoras y pérdida de datos, etc.
Planificar, organizar, dirigir y controlar un proyecto de software tiene que ver con:
§
Extraer, describir, modelar y analizar requerimientos
§
Diseñar la arquitectura del software
§
Diseñar las componentes de la arquitectura del software
§
Controlar la calidad de los productos
§
Asegurar la calidad de productos y procesos
§
Integrar entre sí los elementos que componen el software y el sistema
§
Realizar actividades de soporte al proceso, tales como administrar la configuración,
desarrollar documentación del usuario, resolver problemas, etc.
pero, su planteamiento es primero, y en este aspecto abarcaremos la preparación o formulación del
proyecto informático desde su etapa base.
1.1 GENERALIDADES
1.1.1 EVOLUCION DE LOS PROYECTOS EN TECNOLOGIAS DE INFORMACION
Los proyectos en tecnologías de información fueron evolucionando paralelamente con las distintas
organizaciones a medida que se presentaron los diferentes cambios tecnológicos. Las organizaciones
evolucionaron desde estructuras mecanicistas a flexibles para hacer frente a un entorno muy
cambiante y orientado al cliente. También la informática fue acompañando estas transformaciones;
su evolución, desde sistemas fuertemente centralizados basados en mainframe, pasando
posteriormente a sistemas interactivos (terminales de usuarios), para luego tratar con la computación
personal, mismo que hace hincapié en las redes de computadoras (surgen los sistemas gerenciales,
estratégicos, etc.). Finalmente se ha llegado al punto actual con Internet, aplicaciones multimedia,
video-conferencia, realidad virtual, etc. Similarmente ocurre en el tema de las inversiones de los
diferentes proyectos en tecnologías de información:
§
Primeramente, sólo tenía importancia la evaluación costo – beneficio.
§
Se evaluaba además, si se facilitaba la obtención de los objetivos de la organización y si es
que las tecnologías de información (TI) mejoraban la calidad de tales inversiones.
Unidad de Tecnologías de Información
12
Metodología MDS-α
§
Posteriormente cobra importancia el cómo las TI2 pueden mejorar las tomas de decisiones y
aumentar la participación de mercado.
§
Finalmente, ahora se da mayor importancia a cómo las TI pueden aumentar la capacidad de la
información (Datawarehouse, Internet, Gestión del Conocimiento, etc.) e innovación.
1.1.2 FUNDAMENTOS PARA LA ADOPCION DEL CRITERIO COSTO-EFICIENCIA
Como se indico anteriormente, el criterio de inversión a lo largo de los años fue evolucionando en
distintos aspectos. En tiempos pasados, se consideraba como criterio de inversión importante la
posibilidad de aumento de capacidad de la información. Dicho aumento está referido a la generación
de conocimiento y a un grado mayor de satisfacción por el lado del cliente. Es decir, la idea es
conocer la tecnología y explotarla de tal manera que permita ofrecer mejores servicios con la
información disponible.
Criterios anteriores se evaluaban mediante el costo – beneficio. Sin embargo, existen beneficios que
son muy difíciles de cuantificar, medir y valorar, junto a ello, se presentan beneficios intangibles tales
como mejoras en la calidad de la información, efecto modernizador, redes sociales que se pueden
establecer por Internet, aprendizaje en contacto con la tecnología, etc. Se espera que conociendo las
TI y haciendo uso de ella se hagan innovaciones importantes, lo cual agrega mayor dificultad, ya que
los beneficios se obtendrían después de tener contacto con las TI. En el nombrado criterio, el análisis
se centraba sólo en los aspectos tecnológicos, lo que implica una pérdida de vista de la administración
de la información, por tanto; no se apreciaba una adecuada definición de qué información es
relevante para la organización y qué medidas se tomaban para asegurarla o respaldarla. Hay que
considerar que esto es muy importante, porque existen empresas que perdieron sus bases de datos y
como consecuencia han quebrado en un periodo de tiempo bastante corto. Las instituciones públicas
no quiebran, pero puede afectarse seriamente en su funcionamiento.
Considerando que la evaluación encuentra su sentido en el apoyo veraz para la toma de decisiones;
en esta metodología se propone el criterio de costo-eficiencia. La idea es conceptualizar factores
estratégicos que tengan que ver con la decisión de qué información se debe almacenar (para su
posterior y adecuado tratamiento).
2
TI - Tecnologías de Información
Unidad de Tecnologías de Información
13
Metodología MDS-α
El enfoque costo-eficiencia plantea que la conveniencia de la ejecución de un proyecto se determina
por la observación conjunta de dos factores:
§
El costo: involucra la implementación de la solución tecnológica informática, adquisición y
puesta en marcha del sistema hardware / software y los costos de operación asociados.
§
La eficiencia: se entiende como la relación entre bienes y servicios finales (resultados) y los
insumos requeridos para ello (esfuerzo). Así se trata de medir en qué grado el gasto de
recursos se justifica por los resultados, minimizando costos u optimizando insumos.
Estos dos elementos evaluados en forma conjunta configuran el análisis costo–eficiencia. Es
importante que éstos sean un reflejo de la estrategia que está tomando la institución con respecto a
la información.
1.1.3 CRITERIOS DE APROBACION O RECHAZO DE PROYECTOS EN TECNOLOGIAS DE INFORMACION
Un importante elemento para aprobar o rechazar un proyecto, es la evaluación costo-eficiencia. Sin
embargo, esto no es suficiente; para que un proyecto sea aprobado tiene que estar bien justificado,
ya sea con beneficios cualitativos o cuantitativos. En este sentido, será muy importante la coherencia
del proyecto con un plan informático o con líneas estratégicas planteadas en la institución, es decir
que los sistemas a implementar deben coadyuvar con los objetivos de la institución. Debe verificarse
que el cálculo de ponderadores responda a la estrategia, es así que si una unidad organizacional de la
entidad ha planteado que privilegiará la seguridad, no podría presentar el ponderador
correspondiente con un bajo porcentaje. En general, se apreciará fuertemente la coherencia que
presenta el proyecto en sí mismo.
1.2 CICLO DE PROYECTOS DE DESARROLLO DE SISTEMAS
En un proyecto informático se distinguen claramente las siguientes etapas:
§
Diseño Lógico: Los resultados típicos esperados son las respuestas a las preguntas: ¿qué
sistemas administrativos se apoyarán?, ¿qué sistemas computacionales se desarrollarán?,
¿qué flujos de información son relevantes?, ¿qué procesamiento se requiere?, ¿qué tipo de
datos se manejarán?, etc.
Unidad de Tecnologías de Información
14
Metodología MDS-α
§
Diseño Físico: Se definen los aspectos computacionales del sistema: ¿qué tipo de archivos se
necesitan?, ¿qué tipo de acceso a los diferentes archivos?, ¿qué programas?, ¿qué lenguaje o
aplicaciones?, ¿qué configuración de hardware / software?, etc.
§
Implementación: Consiste en la elaboración de los programas computacionales
anteriormente diseñados.
§
Implantación: Se realizan pruebas, alimentación de datos, marcha blanca y puesta en
producción definitiva.
§
Operación y Mantención: En esta etapa, se tiene que considerar los costos de operación y
mantención. Los costos de operación se refieren a aquellos que permiten el funcionamiento
diario del sistema y los de mantención los que permiten la actualización, la ampliación de
nuevos requerimientos, así también la reparación del mismo.
Es importante destacar, que el término mantención de sistemas informáticos, se refiere a
adecuaciones que requieran los sistemas de propiedad institucional para mantener su vigencia y
utilidad. Esta diferencia se debe a que el software tiene características distintas como producto de
ingeniería, ya que el software está sujeto a un mayor cambio en los requerimientos, así como en el
ambiente con el cual interactúa el sistema. Existen distintas alternativas de desarrollo de estas
etapas: secuencial en cascada, desarrollo incremental, desarrollo en espiral, etc. Estas alternativas se
destacan más adelante, en la presente metodología.
1.3 PROYECTOS DE INVERSION
De una u otra forma, un proyecto de desarrollo de sistemas es un proyecto de inversión. Dentro de
una institución puede o no existir un departamento de sistemas, y el llevar adelante un proyecto
informático involucra en alguna medida algún tipo de inversión, por ejemplo el recurso humano que
desarrollara el software, los usuarios que manipulan el mismo, el software base, lenguajes de
programación, bases de datos, equipamiento tecnológico, etc.
Veamos ahora las características generales de un proyecto de inversión.
1.3.1 CICLO DE VIDA DE LOS PROYECTOS
Entendemos como proyecto al diseño y ejecución de cambios en la asignación actual de recursos que
sigue un objetivo y que generan costos y beneficios, cualitativos y cuantitativos.
Unidad de Tecnologías de Información
15
Metodología MDS-α
El proceso de transformación de las ideas de inversión, pasando por el diseño y llegando hasta su
puesta en marcha, se puede dividir en los siguientes estados:
Preinversión
Inversión
Operación
Graf. 1-1: Ciclo de vida de un proyecto
En el estado de preinversión, se estima la factibilidad técnica y económica. En el estado de inversión,
se diseña y se materializa físicamente la inversión requerida por el proyecto de acuerdo a lo
especificado en la etapa anterior. En el estado de operación, se pone en marcha el proyecto y se
concretan los beneficios netos que fueron estimados previamente.
1.3.1.1 ESTADO DE PREINVERSION
En este estado se estudia la factibilidad técnico - económica mediante aproximaciones sucesivas por
etapas, siendo estas las de idea, perfil, prefactibilidad y factibilidad. La pre-evaluación de un proyecto,
en cualquiera de las etapas mencionadas tiene como objetivos:
§
Abordar en forma explícita el problema de la asignación de recursos escasos en forma óptima.
§
Recomendar al quién toma decisiones (a través de distintas metodologías), sobre la
conveniencia relativa de que una acción o un proyecto determinado se realice por sobre otras
iniciativas. (Estado de Preinversión)
§
Identificar, medir y valorizar, cuantitativa y cualitativamente, los beneficios y costos para la(s)
persona(s) o institución(es).
La selección de los mejores proyectos de inversión, aquellos que tienen mayor conveniencia relativa
(evaluación) y hacia los cuales generalmente se destinan los recursos disponibles, constituye un
proceso que sigue las siguientes etapas secuenciales:
Unidad de Tecnologías de Información
16
Metodología MDS-α
Generación y análisis de la idea de proyecto
Estudio del perfil
Estudio de prefactibilidad
Estudio de factibilidad
Graf. 1-2: Etapas de Preinversión
Cada una de ellas busca reproducir el ciclo de vida del proyecto, de manera que a medida que se
avanza en las etapas, los estudios van tomando mayor profundidad y se va reduciendo la
incertidumbre respecto a los costos y beneficios netos esperados del mismo.
La secuencia por etapas tiene por justificación evitar los elevados costos de los estudios y poder
desechar en las primeras etapas los proyectos que no son adecuados.
Los resultados esperados de cada etapa de preinversión, pasando desde la idea hasta su factibilidad,
se especifican a continuación:
Etapa de generación y análisis de la idea de proyecto
Es crucial contar con un buen diagnóstico, de modo que la generación de una idea de proyecto de
inversión surja como consecuencia clara de necesidades insatisfechas, de objetivos y/o políticas
generales de la organización, de un plan de desarrollo, etc.
Se debe establecer su magnitud, a quienes afecta y la confiabilidad de la información utilizada. Así
como también las alternativas disponibles.
Unidad de Tecnologías de Información
17
Metodología MDS-α
Del análisis surgirá la especificación precisa del bien que se desea construir o el servicio que se
pretende dar. Y servirá para adoptar la decisión de abandonar, postergar o profundizar la idea de
proyecto.
Etapa de estudio del perfil
Se estudian los antecedentes que permitan formar un juicio respecto de la conveniencia y factibilidad
técnico-económica de llevar a cabo la idea de proyecto.
El énfasis está en identificar los beneficios y costos pertinentes respecto de la situación base
(situación actual optimizada), sin incurrir en mayores costos en recursos financieros y humanos para
medirlos y valorarlos, debe incluir un análisis preliminar de los aspectos técnicos, otros diferentes
estudios y los de evaluación. Se utilizan estimaciones gruesas de los beneficios y costos,
generalmente basadas en información existente, es decir, sin incurrir en costos significativos por
concepto de levantamiento de información.
Como conclusión de esta etapa, están las decisiones alternativas de abandonar, postergar o
profundizar el proyecto pasando a la etapa de prefactibilidad.
Etapa de estudio de prefactibilidad
Se examinan a mayor detalle las alternativas viables desde el punto de vista técnico y económico que
fueron determinadas en la etapa anterior, descartando las menos atractivas. El énfasis de esta etapa
es medir los beneficios y costos identificados en la etapa de perfil. Existe un esfuerzo de inversión en
información para disminuir la incertidumbre.
Es necesario estudiar con especial atención los aspectos del entorno, la tecnología, el tamaño y la
localización del proyecto, las condiciones institucionales y legales relevantes para el proyecto.
El estudio de entorno debe identificar los beneficios en un marco de referencia general. El análisis
tecnológico incluye equipos, materias primas y procesos, que permiten determinar los costos del
proyecto. Sobre el tamaño y localización del proyecto se debe considerar la identificación y
localización de las unidades organizacionales de consumo del producto, de abastecimiento de
insumos, canales de distribución, competencia, proyecciones de crecimiento, así como el impacto en
el medio ambiente.
Unidad de Tecnologías de Información
18
Metodología MDS-α
El análisis de los aspectos administrativos permite determinar algunas componentes de costo fijo y la
organización de los recursos humanos, físicos y financieros. El análisis de los aspectos legales permite
conocer las restricciones de ese tipo que limitan al proyecto. Ejemplo: pago de impuestos, permisos
requeridos, accesibilidad de la información, puesta en ejecución, etc.
Todo lo anterior permite tener una estimación de los montos de inversión, costos de operación y de
los ingresos que generaría el proyecto durante su vida útil, esto es lo que se utiliza para la evaluación
económica y para determinar las alternativas más rentables. Conviene sensibilizar los resultados de la
evaluación en las variables más importantes.
Como resultado de la etapa se debe decidir realizar el proyecto o postergar, abandonar o profundizar
pasando a la etapa de factibilidad.
Etapa de estudio de factibilidad
La factibilidad se enfoca en el análisis detallado y preciso de la alternativa que se ha considerado más
viable en la etapa anterior. El énfasis está en medir y valorar en la forma más precisa posible sus
beneficios y costos.
Dada la cantidad de recursos destinados a esta etapa, sólo llegarán a ella los proyectos para los que
no hay duda de su rentabilidad positiva. Por ello, toma más importancia los flujos financieros y la
programación de tareas y actividades. Una vez definido y caracterizado el proyecto, debe optimizarse
en tamaño, localización, momento de inversión, etc.
Se debe coordinar la organización, puesta en marcha y operación del proyecto. Determinar el
calendario de desembolsos para la inversión, disponibilidad de equipos y sus plazos, anteproyecto de
ingeniería, selección y entrenamiento del personal, operación y mantenimiento, así también las
fuentes, condiciones y plazos de financiamiento. Esta etapa es la conclusión del proceso de
aproximaciones sucesivas en la formulación y preparación de un proyecto y constituye la base de la
decisión respecto a su ejecución.
1.4 TIPOS DE PROYECTOS INFORMATICOS
Las tipologías relevantes para proyectos informáticos son:
Unidad de Tecnologías de Información
19
Metodología MDS-α
§
Proyectos de desarrollo de aplicaciones: elaboración y puesta en marcha de programas o
sistemas computacionales.
§
Proyectos de equipamiento: adquisición por primera vez de equipos, incluyendo tanto
hardware como software básico utilitario3.
§
Proyectos de mejoramiento, ampliación o reposición: aumento de capacidad y calidad de
servicios de hardware y/o mejoramiento de software.
3
Sistemas operativos, procesadores de texto, planillas de cálculo, navegadores, antivirus, etc.
Unidad de Tecnologías de Información
20
Metodología MDS-α
CAPITULO 2
2 PREPARACION DEL PROYECTO DE DESARROLLO DE SISTEMAS
Una definición imprecisa de requerimientos de desarrollo de sistemas informáticos es lo que ha
caracterizado a la mayoría de las instituciones del estado, sencillamente se ha desplazado el concepto
para que el profesional informático investigue la naturaleza de los diferentes procesos a automatizar.
Es sorprendente, pero a veces ocurre que solo se dispone del título del sistema que se desea
desarrollar. Por esta razón se plantea este capítulo, ya que cada sistema debe mostrar su contexto
inicial para poder realizar un adecuado dimensionamiento del mismo. Además, los usuarios son los
que conocen los diferentes procesos y procedimientos a implementar.
La siguiente tabla visualiza los distintos puntos que deben ser tomados en cuenta para la formulación
de un proyecto informático de acuerdo a su dimensión.
Secciones
Proy. Pequeño
Proy. Mediano
Proy. Grande
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
Tabla 2.1: Puntos necesarios para la formulación de proyectos informáticos
Unidad de Tecnologías de Información
21
Metodología MDS-α
La norma ISO/IEC 12207 4 enfatiza los diferentes procesos del ciclo de vida del software, y en la
mayoría de tales procesos son los usuarios quienes tienen una marcada y elevada participación.
La unidad solicitante debe preparar el proyecto y luego enviarlo a la UTI, bajo los marcos de
referencia que se indican más adelante. La redacción de la propuesta debe ser clara, concisa y
principalmente debe tener coherencia, de modo tal que facilite el trabajo de la persona responsable
de su evaluación. Existe la creencia equivocada de que una propuesta correctamente elaborada tiene
que ser voluminosa, pero no es cierto. Generalmente, una propuesta debería oscilar (sin incluir
anexos) entre las ocho y diez páginas si se trata de pequeños proyectos. En el caso más extenso, lo
recomendable es que el documento abarque las treinta o cuarenta páginas. Al final, se puede anexar
toda la información respaldatoria que sustente el plan (técnicas, estadísticas, gráficas, etc.).
2.1 CARATULA Y TABLA DE CONTENIDOS
La carátula del documento debe expresar la información básica y relevante sobre el proyecto, a la par
de lucir un aspecto sobrio y profesional; en este se incluye:
§
Nombre de la Unidad Organizacional / Entidad
§
Nombre del proyecto (debe permitir identificar la naturaleza del proyecto)
§
Mes y año de elaboración de la propuesta
§
Persona de contacto (nombre del funcionario, teléfono, fax, correo electrónico, dirección)
Además de enviar una copia física de la propuesta, es recomendable anexar al documento una copia
en un medio magnético (disquete, CD u otro) y enviar una copia adicional por correo electrónico. Esto
permitirá compartir con mayor facilidad el documento entre los funcionarios responsables de la
evaluación de la propuesta.
Si la extensión del documento es superior a cinco páginas, se deberá incluir una tabla de contenidos
que permita ubicar más fácilmente las diferentes secciones.
2.2 RESUMEN EJECUTIVO
El resumen ejecutivo es indudablemente una de las principales secciones de una propuesta de
proyecto. Es el punto de partida que despierta el interés de la persona responsable de su evaluación.
4
ISO/IEC 12207 Information Technology / Software Life Cycle Proccess
Unidad de Tecnologías de Información
22
Metodología MDS-α
Por tanto, es fundamental poner especial cuidado en su redacción y consistencia. Como su nombre lo
dice, un resumen ejecutivo es una síntesis de la información más relevante del proyecto. Se
recomienda que su extensión no exceda las dos páginas y su contenido debe contemplar los
siguientes puntos:
§
Identificación del problema a resolver
§
Objetivo del proyecto
§
Requerimientos base
§
Breve justificación de la solución escogida
§
Costos de inversión y operación de la solución
Sugerencia: El resumen ejecutivo debe ser redactado al final, una vez terminada la elaboración de la
propuesta. Generalmente, esta es la única parte de la propuesta que leen los evaluadores para
decidir si continúan revisándola o la dejan de lado. Por ello es importante poner especial cuidado en
su redacción.
2.3 PLAN O POLITICA INSTITUCIONAL SOBRE TECNOLOGIAS DE INFORMACION
La política institucional debe contener estrategias encaminadas a una buena gestión, tanto de la
información como de la tecnología que la soporta.
En particular, definir los casos que corresponda:
§
Dependiendo del área, deseablemente la información debe cumplir con los siguientes
atributos en distintos grados de importancia:
o
Confidencialidad: nivel de protección de la información que se necesita
o
Integridad: precisión y suficiencia de la información
o
Disponibilidad: qué usuarios dispondrán de la información
o
Confiabilidad: la información obtenida debe ser apropiada para la gestión y operación de
la institución
o
Información Externa: acceso a información requerida por otras unidades organizacionales
o instituciones externas.
§
Clasificación de la información respecto a su relevancia. La relevancia se define en función de
lo que significa la pérdida de información; de manera que se considera estratégica aquella
Unidad de Tecnologías de Información
23
Metodología MDS-α
información cuya pérdida afecta a la misión de la institución y no estratégica a aquella cuya
pérdida no afecta a la misión.
§
Procesos claves dentro de la institución, ya que las mejoras a estos procesos colaborarán
grandemente la gestión estratégica y del plan tecnológico.
§
Estrategia de capacitación.
§
Estrategia de desarrollo de software de aplicaciones: desarrollo local, desarrollo externo,
desarrollo mixto, u otras modalidades.
§
Estrategia de recursos humanos: Unidad Solicitante, Unidad de Tecnologías de Información y
sus respectivos alcances.
2.4 DEFINICION DEL PROBLEMA
Se debe especificar claramente qué problema se intenta solucionar o qué objetivo se pretende
alcanzar mediante el proyecto, esto debe abordarse en términos generales. Este punto constituye el
motivo por el que se origina el proyecto, para ello se utilizará la metodología del árbol causa – efecto5
(Ver Anexo 1).
2.5 DIAGNOSTICO DE LA SITUACION ACTUAL
2.5.1 DESCRIPCION DE LA UNIDAD ORGANIZACIONAL
Realizar una descripción acerca del área o unidad organizacional en la cual se involucre el proyecto.
Esta sección explica claramente la situación actual de la unidad o departamento conteniendo los
siguientes puntos:
§
Organigrama de la unidad o departamento, la cual indique la actual situación de la unidad
solicitante donde se ejecutara el proyecto.
§
Funciones y responsabilidades de la unidad o departamento
§
Exposición de los objetivos actuales, tanto de corto como de largo plazo que se ha planteado
la unidad o departamento. Para ello, se debe realizar una enumeración y una breve
descripción de los mismos.
5
La metodología del árbol causa - efecto es una técnica que se emplea para identificar el problema central, el
cual se intenta solucionar mediante la intervención del proyecto utilizando una relación de tipo causa-efecto.
Unidad de Tecnologías de Información
24
Metodología MDS-α
§
Definir la interacción de la unidad o departamento con su entorno mediante un esquema
simple de interrelación. Mencionar las relaciones que guardan nexo con el tema que se desea
estudiar y que puede ser importante acotarlas.
2.5.2 ACTUALIDAD TECNOLOGICA
Realizar una breve descripción de la actualidad tecnológica de la unidad o departamento, mencionar
el hardware disponible, el software base utilizado y los sistemas informáticos que automatizan ciertos
procesos de la citada unidad. Citar su utilidad en cada uno de los casos.
2.5.3 DESCRIPCION DE LOS PROCESOS Y PROCEDIMIENTOS
Identificar y describir los procesos que tienen relación con el tema en estudio, dando un nombre
simple al proceso y una breve descripción de cómo operan los mismos. Para ello puede guiarse
mediante la aplicación de formatos del Anexo 2.
2.6 DESCRIPCIÓN GENERAL DE REQUERIMIENTOS
En esta sección deben describirse los requerimientos principales de la unidad solicitante, los cuales se
espera que estén incluidos en la solución informática. Es recomendable que los requerimientos
citados tengan relación con los procesos estratégicos de la solución.
Los datos descritos en este apartado permitirán realizar un dimensionamiento inicial de lo que se
pretende automatizar, posibilitando el punto de partida al trabajo del profesional en sistemas
informáticos.
2.7 ESTIMACION DE BENEFICIOS
Identificar los diferentes beneficios que pueden obtenerse tras la ejecución del proyecto, su
exposición debe ser en forma cualitativa. Luego de la identificación de tales beneficios, tratar de
hacer su medición y valoración, para ello tomar en cuenta los puntos señalados en el Anexo 3
2.8 ESTIMACION DE COSTOS
La estimación de costos (en inversión, operación, mantención, etc.) tiene su fundamento
principalmente en la experiencia de la institución. Debe explicarse de forma precisa los valores o
cifras correspondientes a cada uno de los puntos o actividades que deberán realizarse para la
Unidad de Tecnologías de Información
25
Metodología MDS-α
ejecución del proyecto, por ejemplo pueden describirse el software, hardware y servicios
profesionales que se usarán.
Se hace notar que la estimación de costos debe afinarse después de realizar el dimensionamiento del
proyecto. En lo que respecta al tema, se debe inmiscuir la participación de personal calificado en el
tema, para nuestro caso en lo que se refiere a proyectos tecnológicos que sean viabilizados mediante
la Unidad de Tecnologías de Información, algunos datos brindados pueden ser: tiempo de desarrollo,
tiempo de implantación, tiempo de capacitación, perfiles del personal, términos de referencia, nivel
salarial, costos de adquisición de partes y equipos, costos de mantenimiento (en informática se
entiende por costos de mantenimiento los destinados a las adecuaciones que requieren los sistemas
para mantener su vigencia y utilidad) u otros.
2.9 ALTERNATIVAS DE SOLUCION
De acuerdo al problema central, la presentación de alternativas de solución está relacionada en
forma directa con las capacidades técnicas para su ejecución que podrían contribuir al cambio de la
situación actual a la situación futura deseada.
Estas alternativas deben ser evaluadas a través de diversos criterios que dependen de los objetivos
del proyecto, estos criterios pueden ser:
§
Financiero
§
Económico
§
Socioeconómico
§
Ambiental
§
Viabilidad política
§
Legal
§
Cultural
§
etc.
Para la evaluación puede utilizarse el siguiente cuadro:
Unidad de Tecnologías de Información
26
Metodología MDS-α
ALTERNATIVA
CRITERIOS
Financiero
Económico
Socioecon.
Ambiental
Viab. Política
Legal
Alternativa 1
Alternativa 2
Alternativa 3
Alternativa 4
Tabla 2-1: Cuadro comparativo de criterios para cada alternativa
2.9.1 RESTRICCIONES DE CADA ALTERNATIVA
Mencionar las restricciones de precio, mantención, operación, tecnología, u otros que presenta en
cada una de las alternativas.
2.9.2 PRODUCTO O SERVICIO ESPERADO DE CADA ALTERNATIVA
Especificar si se espera el mismo servicio o producto por cada alternativa de solución y realizar una
descripción general. Por ejemplo, se puede mencionar que el producto de la alternativa seleccionada
cumplirá con ciertos requerimientos específicos y en cambio no solucionará otro requerimiento
menos importante.
2.9.3 ELECCION DE LA ALTERNATIVA
Tomar la decisión sobre una alternativa (o combinación de ellas) que se juzgue como la más
apropiada para el proyecto. La decisión a adoptarse puede considerar:
§
Los intereses de los beneficiarios del proyecto
§
Recursos financieros disponibles
§
Los resultados de los estudios financieros, económicos, socioeconómicos, etc. indicados en la
evaluación.
§
Los intereses y mandatos de las entidades ejecutoras potenciales y demás involucrados
directa o indirectamente.
El análisis de alternativas es un medio para obtener preciada información para el respaldo en la toma
de decisiones.
Unidad de Tecnologías de Información
27
Metodología MDS-α
2.10 MATRIZ DEL MARCO LÓGICO
Una vez identificado claramente el proyecto, debe diseñarse la matriz del marco lógico; si el proyecto
se cataloga como mediano o de gran envergadura entonces su carácter es obligatorio (Ver Anexo 4).
2.11 PLANIFICACION DE ACTIVIDADES
La planificación de actividades puede representarse mediante un Diagrama Gantt6 el cual establece el
orden de las actividades a realizar, detallando cuales tareas pueden ser elaboradas en forma paralela
y cuales son necesarias previamente para realizar otras. Esta descripción se hace simbolizando cada
tarea mediante una barra, cuyo largo dependerá del tiempo de ejecución de cada tarea.
Para la planificación puede utilizarse el cuadro siguiente:
ACTIVIDADES
TIEMPO
T1
T2
T3
T4
T5
T6
T7
…….…
Tm
A1
A2
A3
…..
An
Tabla 2-2: Diagrama Gantt
6
Diagrama Gantt: Herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para
diferentes tareas o actividades.
Unidad de Tecnologías de Información
28
Metodología MDS-α
CAPITULO 3
3 REQUERIMIENTOS DE SOFTWARE
Se sabe que la parte más compleja en la construcción de un software es saber precisamente qué
construir; es así que debe definirse correctamente los diferentes requerimientos técnicos, incluyendo
todas las interfaces con personas, máquinas u otros sistemas antes de empezar con el proyecto.
Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o
porque el cliente quiere que ese requerimiento sea parte del producto final. Así que si no se tienen
los requerimientos correctos, no se puede diseñar o construir el producto correcto y,
consecuentemente, el producto no permitirá a los usuarios finales realizar su trabajo. Y esto está
confirmado por estudios que demuestran que más del 60% de los errores de diseño se originan
durante las etapas de requerimientos y análisis.
Los requerimientos se pueden dividir en requerimientos funcionales y no-funcionales.
§
Requerimientos Funcionales: definen qué hace el sistema (describen todas las entradas y
salidas), es decir, las funciones del sistema.
§
Requerimientos No-funcionales: definen los atributos que le indican al sistema cómo realizar
su trabajo (eficiencia, hardware, software, interface, usabilidad, etc.); es el cómo, cuándo,
cuánto y qué del sistema.
Un escenario comúnmente marcado es que el analista de sistemas se posiciona ante un dominio o
entorno que desconoce y un cliente que no tiene claramente estructurado los diferentes procesos del
negocio (incluyendo metas y objetivos) por lo que el analista se enfrenta ante objetivos ambiguos y
no operacionales, y como resultado de esta acción se dificulta enormemente la definición de las
distintas variables que se deben involucran en los distintos procesos a ser automatizados.
Esta sección debe involucrar necesariamente el trabajo tanto del usuario como del ingeniero de
software para definir claramente los distintos requerimientos que involucran el sistema a ser
desarrollado.
Unidad de Tecnologías de Información
29
Metodología MDS-α
3.1 VISIÓN Y ALCANCE DEL PROYECTO
Un proyecto de desarrollo de Software que carezca de una dirección claramente establecida y
correctamente comunicada a todos los participantes, es una invitación al fracaso.
Una definición concisa de la Visión y Alcance del Proyecto es crítica obtenerla al inicio del mismo.
La visión del proyecto alinea a todos los participantes en una dirección común y clara. La visión
describe al proyecto y que productos se podrán ultimadamente obtener en un “mundo perfecto”.
El alcance del proyecto describe qué se perseguirá como producto real y que cosas no se incluirán. El
alcance especifica la frontera entre lo que está o no comprendido, define las limitaciones del
proyecto.
Para esta sección se debe tener como producto un documento que exprese la visión y alcance del
proyecto según la siguiente plantilla:
3.1.1 PLANTILLA PARA EL DOCUMENTO DE VISIÓN Y ALCANCES DEL PROYECTO
3.1.1.1 REQUERIMIENTOS DE NEGOCIOS
Identificar los beneficios principales que el nuevo sistema proveerá a los usuarios y a la entidad en
general.
3.1.1.1.1 Antecedentes
Puntualizar las razones de ser del nuevo sistema. Realizar una descripción general de la historia o
situación que derivo en la decisión de construir el producto.
3.1.1.1.2 Oportunidades de Negocio
Describir las oportunidades existentes o el problema de negocios que será resuelto en la entidad.
Señalar el entorno en el cual el producto va a competir o va a ser utilizado. Identificar los problemas
que en la actualidad no pueden ser resueltos por falta del producto, y describir cómo el producto se
alinea con las tendencias de la institución según sus políticas y estrategias.
Unidad de Tecnologías de Información
30
Metodología MDS-α
3.1.1.1.3 Objetivos de Desarrollo del Sistema
Describir los más importantes beneficios institucionales que proveerá el producto, preferentemente
de una manera cuantificable y susceptible de medición. Estos objetivos pueden relacionarse a
estimaciones de ingresos o ahorro en costos.
3.1.1.1.4 Requerimientos del Usuario
Describir las necesidades de los usuarios tipo, incluyendo necesidades que no están siendo
satisfechas por productos que ya están disponibles en la entidad. Presentar problemas que los
usuarios encuentran en la actualidad y que el nuevo sistema va (o no va) a solucionar. Presentar estos
requerimientos en una lista numerada, de tal manera que un usuario especifico y los requerimientos
funcionales puedan ser rastreados de retorno a la misma.
3.1.1.1.5 Valor proporcionado al Usuario
Definir el valor que el usuario recibirá del producto e indicar como el producto desembocará en una
mejora de la satisfacción del citado usuario. Expresar esto en términos de:
§
Mejora en productividad.
§
Reducción de trabajo repetitivo.
§
Simplificación de procesos institucionales.
§
Ahorro en costos.
§
Automatización de tareas manuales.
3.1.1.1.6 Riesgos del Sistema
Resumir los principales riesgos de negocio asociados con el desarrollo (o no desarrollo) del producto,
como ser: problemas con tiempos de cumplimiento, aceptación del usuario, problemas de
implementación o posibles impactos negativos en el negocio.
3.1.1.2 VISIÓN DE LA SOLUCIÓN
Esta sección del documento establece una visión a largo-plazo del sistema que va a encarar los
objetivos de negocio.
Unidad de Tecnologías de Información
31
Metodología MDS-α
3.1.1.2.1 Declaración de la Visión
Escribir una declaración concisa de la visión que resuma los objetivos e intenciones a largo-plazo del
nuevo producto. La declaración de la visión debe reflejar una vista balanceada que satisfaga las
necesidades de los diferentes usuarios.
3.1.1.2.2 Características Principales
Incluir una lista numerada de las características o funciones principales, o de las capacidades que el
nuevo sistema proveerá al cliente. Enfatizar aquellas que distingan al producto de otros anteriores o
competidores.
3.1.1.2.3 Dependencias y presunciones
Registrar cualquier presunción realizada al momento de la concepción del proyecto y de la
elaboración de éste documento. También, mencionar las dependencias principales, como ser
tecnologías a ser utilizadas, proveedores, o cualquier relación de negocios.
3.1.1.3 ALCANCE Y LIMITACIONES
El alcance del proyecto define los conceptos y rangos de la solución propuesta, y las limitaciones
identifican ciertas capacidades o funciones que el sistema no va a incluir. Clarificar el alcance y
limitaciones ayudan a establecer expectativas reales del usuario o interesados.
3.1.1.3.1 Alcance de la Versión Inicial
Resumir las funciones principales de la versión inicial del sistema. Describir las características de
calidad que van a permitir al producto proporcionar los beneficios esperados a las diferentes
comunidades del o los usuarios.
3.1.1.3.2 Alcance de las versiones subsecuentes
Si se divisa una evolución por etapas del producto, indicar que características funcionales van a ser
pospuestas y los tiempos planificados para las subsecuentes versiones.
Unidad de Tecnologías de Información
32
Metodología MDS-α
3.1.1.3.3 Limitaciones y exclusiones
Definir la frontera entre lo que se incluye y no se incluye en el producto, para así no crear falsas
expectativas en el usuario y evitar la adición innecesaria de características no especificas.
3.1.1.4 CONTEXTO DEL NEGOCIO
3.1.1.4.1 Características del usuario (Perfil)
Elaborar un resumen de las características esenciales de las diferentes categorías de los usuarios para
este producto, para ello especificar la siguiente información para cada categoría de usuarios:
§
Beneficios principales que la categoría de usuario va a recibir del producto.
§
Actitudes esperadas del producto.
§
Características funcionales claves de su interés.
§
Cualquier restricción del usuario que deberá ser acomodada.
3.1.1.4.2 Prioridades del Proyecto
Una vez que las prioridades del proyecto se establezcan claramente, los interesados en el proyecto y
otros participantes pueden enfocar sus esfuerzos en un conjunto de objetivos comunes. Una manera
de enfocar este proceso es considerar 5 dimensiones del proyecto software:
§
características funcionales
§
calidad
§
cronograma
§
costo
§
personal
En cualquier proyecto cada una de estas dimensiones pueden ser clasificadas como:
§
Un conductor (driver) : Un objetivo de alta prioridad
§
Una restricción (constraint) : Un factor limitante para el proyecto
§
Un nivel de libertad: Un factor que el gerente del proyecto puede balancear en contra de
otra dimensión para la consecución del “conductor” entre las “restricciones” conocidas.
Todos los factores no pueden ser conductores, tampoco restricciones.
Unidad de Tecnologías de Información
33
Metodología MDS-α
3.1.1.5 FACTORES DE ÉXITO DEL PRODUCTO
Determinar cómo el éxito del producto va a ser medido y describir los factores que tengan mayor
impacto en obtener el éxito del proyecto.
3.2 INGENIERÍA DE REQUERIMIENTOS
La Ingeniería de Requerimientos es un conjunto de actividades que mediante el uso de ciertas
técnicas y herramientas se analiza un problema determinado, obteniendo como conclusión del
proceso las especificaciones de la solución. Involucra actividades en la definición, documentación y
mantenimiento de los requerimientos del producto buscado, el uso del término "ingeniería" implica
la utilización de técnicas sistemáticas y repetibles para asegurar que los requerimientos del sistema
estén completos y, sean consistentes y relevantes.
Las actividades que se incluyen en el proceso de Ingeniería de Requerimientos, incluyen la extracción
de requerimientos, el análisis, la documentación y la validación. No existe un proceso único que sea
válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso
de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de
experiencia y habilidad de las personas involucradas en el entorno.
El proceso de Ingeniería de Requerimientos puede verse de la siguiente forma:
Extracción de
Requerimientos
Necesidades de
los usuarios,
información del
dominio,
información de
sistemas
existentes,
estándares de
regulación, etc.
Análisis de
Requerimientos
Documentación de
Requerimientos
Validación de
Requerimientos
Documento de
Requerimientos
Especificaciones
del Sistema
Requerimientos
Acordados
Graf. 3-1: Proceso de la Ingeniería de Requerimientos
Unidad de Tecnologías de Información
34
Metodología MDS-α
A continuación se citan dos modelos base, de los cuales pueden adecuarse otros según las
necesidades del momento y del caso de estudio en particular.
3.2.1 Modelo Tradicional en Cascada
Este modelo de proceso de Ingeniería de Requerimientos sugiere que los resultados de una tarea
llevan a la siguiente, y así sucesivamente. Es decir, la extracción lleva al análisis, el análisis
desencadena la documentación, y la documentación inicia la validación.
Extracción
Análisis
Documentación
Validación
Graf. 3-2: Modelo Tradicional en Cascada en la Ingeniería de Requerimientos
Este modelo es bastante sencillo y el inconveniente que se manifiesta en el mismo es que no se
diferencian las fases. Por lo general, los requerimientos son de carácter dinámico en el tiempo y por
ello debe existir el carácter retro-alimentador en este modelo.
3.2.2 Modelo en Espiral
El modelo en espiral toma en cuenta la retroalimentación entre etapas y la repetición de las tareas.
El diagrama siguiente sugiere que las distintas actividades de la ingeniería de requerimientos se van
repitiendo hasta tomar una decisión final que consiste en la aceptación del Documento de
Especificación de Requerimientos generado como consecuencia del proceso. En otras palabras, si en
el diseño preliminar todavía se encuentran problemas entonces recorremos el ciclo nuevamente
(extracción, análisis, documentación, validación) hasta resolver los mismos (las veces que sea
necesario) hasta elaborar un documento aceptable.
Por lo general existen presiones a cumplir con ciertos plazos para la entrega del producto, pero se
debe tomar en cuenta muy claramente que esta etapa de la definición de requerimientos nos
ahorrará muchos dolores de cabeza cuando ya se esté codificando el sistema pedido. Se aconseja que
Unidad de Tecnologías de Información
35
Metodología MDS-α
en la planificación de las actividades sea tomado en cuenta la definición de los requerimientos de
software.
Especificación
Informal
Planificación/Extracció
n
Análisis
Punto de
decisión
Especificación
Final/ Reporte
de Validación
Requerimientos
Aceptados
Inicio
Validación
Documentación
Especificación
Preliminar
Graf. 3-3: Modelo en Espiral de la Ingeniería de Requerimientos
3.3 ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS
Como ya se indico, las actividades más destacadas de la Ingeniería de Requerimientos son:
§
Extracción
§
Análisis
§
Documentación
§
Validación
3.3.1 Extracción
Esta fase representa el inicio de cada ciclo, y como su nombre lo indica el Analista debe extraer junto
al usuario los distintos aspectos que colaboraran en la solución del problema (servicios que prestará
el sistema, modos de presentación, tipos de cálculo, restricciones, modelos utilizados, etc.). Esto
suele ser una tarea difícil y muchas veces los usuarios no tienen una idea clara de sus necesidades
Unidad de Tecnologías de Información
36
Metodología MDS-α
reales; diversas personas dentro de la institución tienen necesidades encontradas, pueden existir
limitaciones técnicas o tecnológicas para cumplir con algunos requerimientos, etc. Pero, en definitiva
extraer los requerimientos del sistema no sólo implica preguntar a las personas qué quieren; es un
proceso delicado que involucra comprender el entorno de la aplicación, es decir, obtener un
conocimiento del área general de aplicación del sistema; comprender el problema en sí, lo que
implica que se debe extender y especializar el conocimiento sobre el dominio general para que se
aplique al usuario en particular; comprender el negocio; por tanto, se debe entender en profundidad
cómo es que este sistema interactuará y afectará a las partes del negocio que estarán involucradas y
cómo puede contribuir a lograr las metas de la entidad; finalmente, comprender las necesidades y
restricciones de los usuarios del sistema; en particular, se deben entender los procesos de trabajo
que se supone que el sistema apoyará y el rol de cualquier otro sistema que actualmente se involucre
en dichos procesos.
Entonces, es importante que la extracción sea efectiva, ya que la aceptación del sistema dependerá
de cuán bien éste satisfaga las necesidades del usuario y de cuán bien asista a la automatización del
trabajo.
3.3.2 Análisis
En base a la extracción se comienza esta fase, la cual se presenta en un alto grado de complejidad en
un proyecto donde el dominio es desconocido, en donde se apunta a descubrir problemas con los
requerimientos del sistema identificados hasta el momento.
Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de
requerimientos; aquí se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas
con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van
fijando reuniones con el cliente para discutir tales requerimientos.
Debemos destacar que no es posible convertir el análisis en un proceso estructurado y sistemático, lo
que convierte a esta etapa en "subjetiva" porque depende en gran medida del juicio y de la
experiencia del analista.
Unidad de Tecnologías de Información
37
Metodología MDS-α
3.3.3 Documentación
En esta fase se documentan los requerimientos acordados con el usuario a un nivel apropiado de
detalle. Y en la práctica, esta etapa se va realizando conjuntamente con el análisis, pero podríamos
decir que la Documentación es el "pasar en limpio" el análisis realizado previamente aplicando
técnicas y/o estándares de documentación.
3.3.4 Validación
La validación es la etapa final de la Ingeniería de Requerimientos y su objetivo es justamente validar
los requerimientos, para ello se verifican todos los requerimientos que aparecen en el documento
especificado para asegurarse que representan una descripción aceptable del sistema que se debe
implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.
La validación representa un punto de control del propio analista como así también de la interacción
con el usuario. Es inevitable que durante la validación se descubran algunos problemas, y esto se
debe corregir antes de aprobarse el documento final de requerimientos.
En definitiva, la validación significa asegurarse de que el documento de requerimientos represente
una descripción clara del sistema, y es una verificación final de que los requerimientos cubren
realmente las necesidades de los usuarios.
Esta etapa puede confundirse con la de análisis, pero la diferencia es clara: mientras que en el análisis
se trabaja sobre el boceto del documento de requerimientos, en la validación se utiliza el documento
final, lo que equivale a decir, sobre los requerimientos "depurados".
3.4 HERRAMIENTAS
Para llevar a cabo cada una de las actividades del proceso de Ingeniería de Requerimientos, se
pueden usar distintas técnicas y herramientas. Las herramientas que fueron seleccionadas son las
consideradas más pertinentes para el escenario planteado en ésta sección. Para tal labor se describe
los elementos necesarios en el Anexo 5.
Unidad de Tecnologías de Información
38
Metodología MDS-α
CAPITULO 4
4 ESPECIFICACIONES DE SOFTWARE
La Especificación de Software define claramente los alcances reales de los servicios que un Sistema
Informático debe proveer; determina los límites y restricciones en las distintas operaciones del
sistema a construir. Para ello en la actualidad la Ingeniería de Requerimientos nos permite capturar y
formalizar los requerimientos, dando lugar a las especificaciones del software.
Se sabe mediante varios estudios experimentales que la Ingeniería de Requerimientos es crítica y vital
respecto al éxito o fracaso de numerosos proyectos informáticos y su mala gestión tiene una gran
incidencia en relación con el desbordamiento de los costes y el incumplimiento a los plazos de
desarrollo. En esta área de la informática, se vienen desarrollando una gran cantidad de métodos,
técnicas, herramientas y estándares, que en muchas ocasiones no son conocidos por los mismos
profesionales del sector.
Una vez que ya han sido recopilados, clasificados, consensuados y redactados los diferentes
requerimientos, corresponde seguidamente especificar tales requerimientos con la finalidad en
primera instancia de conformar un Documento de Especificaciones de Requerimientos
(especificaciones de software) y luego formalizar los mismos mediante diferentes herramientas.
Debe existir en la Especificación de Requerimientos la habilidad de comunicarse con la audiencia
involucrada de forma balanceada para que tal proceso sea definido de forma específica y sin
ambigüedad alguna.
4.1 MODELADO DEL NEGOCIO
El método de Modelado de Negocios posibilita un mejor entendimiento de la organización donde se
va a implantar el sistema informático. Los motivos para ejecutar esta actividad son los siguientes:
§
Asegurar que el producto sea algo útil y no un obstáculo.
§
Ajustar el modelamiento de la mejor forma posible.
§
Poseer un marco referencia común entre el equipo del proyecto y los usuarios.
Unidad de Tecnologías de Información
39
Metodología MDS-α
Los objetivos específicos del modelado de negocio son:
§
Entender el problema e identificar potenciales mejoras.
§
Entender la estructura y la dinámica del problema a resolver.
Tomando en cuenta la “Visión y Alcance del Proyecto” definido en el tema anterior y para lograr los
objetivos descritos deben definirse los diferentes procesos, roles y responsabilidades.
Un proceso de negocio es un grupo de tareas relacionadas lógicamente que se llevan a cabo en una
determinada secuencia y que emplean los recursos de la una determinada organización para brindar
resultados en apoyo a sus objetivos.
En UML, se dispone del “Diagrama de Actividades” para definir los diferentes procesos de negocios
que contemplara el sistema. Esta herramienta permite ver de forma clara todas las actividades y su
flujo lógico, incluyendo paralelismo de actividades de un determinado proceso (y no solamente flujo
secuencial); y como suena su nombre esta herramienta es para flujo de actividades y no para flujo de
datos.
Ejemplo: Para el proceso de vender productos se tiene el siguiente diagrama
Diag. 4-1: Modelamiento del Negocio con Diagrama de Actividades
Unidad de Tecnologías de Información
40
Metodología MDS-α
4.2 DIAGRAMA DE CONTEXTO
En la sección de “Visión y Alcances del Proyecto” se determinaron las fronteras entre lo que vamos a
desarrollar y el resto del universo. El Diagrama de Contexto, ilustra de forma grafica estas fronteras
mediante la representación de las conexiones entre el sistema que se pretende desarrollar o
problema que se intenta solucionar, y el mundo exterior.
El Diagrama de Contexto identifica las entidades externas que tienen un vínculo con el sistema y que
se interrelacionan a éste último de alguna manera (llamados también terminadores), así como los
flujos de datos entre cada entidad externa y el sistema.
Ejemplo: Diagrama de Contexto para un Sistema de Registro de Ventas (Sistema RV)
Lista de Productos
Orden de Venta
ALMACEN
CLIENTE
Rechazo
Confirmación de la
Lista de Productos
Facturación
Pago
Depósito
Sistema
RV
Comisión
Registro de Transacción
VENDEDOR
BANCO
CONTABILIDAD
Diag. 4-2: Diagrama de Contexto del Sistema RV
4.3 CASOS DE USO
Los casos de uso son una herramienta de análisis que ayudan a describir qué es lo que el sistema
debe hacer. Desde el punto de vista del usuario describen qué hace el sistema.
Los casos de uso se escriben con el fin de expresar lo que debe hacer el sistema a desarrollar, sin
tener en cuenta cómo debe hacerlo.
Unidad de Tecnologías de Información
41
Metodología MDS-α
Un Caso de Uso es una secuencia de transacciones en un sistema cuyo resultado proporciona un
determinado valor a un actor individual del sistema.
Los casos de uso representan los requisitos funcionales del sistema.
En el modelado de casos de uso se tienen en cuenta dos conceptos básicos:
§
Actores: Los actores pueden representar a personas, software o hardware; el término actor
identifica el rol genérico del usuario del sistema. El nombre de dicho actor deberá reflejar el
papel que tendrá con nuestro sistema. La identificación de los actores nos permite:
o
Definir los límites del sistema (qué forma parte del sistema y qué no).
o
Desarrollar un sistema orientado al usuario que contemple todas las funcionalidades
esperadas por los diferentes actores.
§
Casos de Uso: Muestran las funcionalidades que ofrecerá el sistema y los comportamientos
posibles inherentes a las diferentes situaciones contempladas para cada una de estas.
4.3.1 Diagramas de Casos de Uso
Es una gráfica en donde se muestra la relación de los casos de uso con actores o con otros casos de
uso; dicha relación está dada por una línea o flecha entre los casos de uso y/o actores relacionados.
Las relaciones pueden ser de cuatro tipos posibles:
§
Comunicación: relación entre un actor y un caso de uso, se representa mediante una línea o
flecha indicando el orden de tal relación.
§
Uso: “include”, “includes”, “uses”; cuando un caso de uso utiliza a otro.
§
Extensión: “extend”, “extends”; cuando un caso de uso especializa a otro extendiendo su
funcionalidad.
§
Generalización: se trata del concepto de herencia, habitual en los diagramas de clases, pero
aplicado entre casos de uso, e incluso entre actores; se representa por una flecha con un
triángulo vacío en la punta señalando el sentido de la relación.
Ejemplo: Una parte del Sistema RV se muestra en el siguiente Diagrama de Casos de Uso
Unidad de Tecnologías de Información
42
Metodología MDS-α
Validar
Cliente
<<include>>
Hacer
Pedido
<<extend>>
(Establecer Prioridad)
<<include>>
Hacer Pedido
Urgente
Verificación
del Stock
Cliente
Facturación
Departamento de
Contabilidad
Comisión
Vendedor
Diag. 4-3: Diagrama de Casos de Uso
4.3.2 Documento de especificación de Casos de Uso
Lo importante de los casos de uso aparte de su diagramación es su especificación en un documento.
En este último se describe o explica principalmente la forma de actuar entre el usuario y el sistema.
Continuando con el ejemplo de la venta de productos, se muestra en el siguiente formulario el
correspondiente caso de uso de “Hacer Pedido”. De esta manera se deben completar todos los casos
de uso que contempla el sistema analizado y de igual forma conformar el Documento de Casos de
Uso.
Unidad de Tecnologías de Información
43
Metodología MDS-α
Creado por:
Fecha de Creación:
Daniel Abasto
18 de Diciembre de 2008
Nombre:
Actor:
CU-001/Hacer Pedido
Cliente
Describe el proceso de pedir la venta de algún producto por parte del
cliente
Eventos Actor
Eventos Sistema
1.- Pide datos generales del cliente
2.- Introduce datos personales.
3.- <<include>> Validar Cliente
4.- Identifica al cliente por primera
vez y lo registra.
5.- Muestra su lista de productos a
la venta
6.- Selecciona los productos y la
7.- <<include>> Verifica Stock y
cantidad de los mismos.
pone a la cola el pedido
identificando al vendedor que lo
atenderá.
8.- Reinicia el Caso de Uso.
Eventos Actor
Eventos Sistema
1.- Pide datos generales del cliente
2.- Introduce datos personales.
3.- <<include>> Validar Cliente
4.- Identifica a la persona como
cliente de la empresa.
5.- Muestra su lista de productos a
la venta
6.- Selecciona los productos y la
7.- <<include>> Verifica Stock y
cantidad de los mismos.
prioriza el pedido de acuerdo a la
jerarquía del cliente e identifica al
vendedor que lo atenderá.
8.- Reinicia el Caso de Uso.
1.- El cliente solicita utilización del sistema.
1.- Aceptación del pedido del cliente.
1.- Disponibilidad del cliente a introducir por sistema los datos pedidos.
2.- Sistema habilitado con disponibilidad de la Base de Datos.
Descripción:
Flujo principal:
Alternativa:
Precondición:
Pos condición:
Presunción:
Modificado por:
Fecha de modificación:
Form. 4-1: Formulario de Casos de Uso
4.4 DOCUMENTO DE ESPECIFICACIONES DE SOFTWARE
El análisis y desarrollo de requerimientos tiene como producto final un acuerdo documentado entre
el usuario/cliente y el grupo de desarrollo de sistemas acerca del producto a ser construido.
El documento es conocido como: Especificación de Requerimientos del Software, Especificación
Funcional / Especificación del Sistema / Especificaciones de Software.
Unidad de Tecnologías de Información
44
Metodología MDS-α
El Documento de Especificaciones de Software (DES) establece con precisión las funciones,
características y capacidad del software como así también sus restricciones. Este documento es la
base para toda subsecuentes etapas del desarrollo del sistema, es decir su planificación, diseño, y
codificación, así como para las pruebas del software y documentación del usuario.
El Documento de Especificaciones de Software debe ser preparado en forma conjunta (analistas,
desarrolladores, usuarios) y debe comprender la totalidad de los requerimientos citados por el
usuario. Tanto los desarrolladores como los propios usuarios no deben realizar presunción alguna y; si
cualquier requerimiento funcional o no funcional no está claramente establecido en el citado
Documento, entonces no es parte del acuerdo o convenio y por lo tanto nadie debe esperar que
aparezca en el producto final.
Según el estándar IEEE 830 un buen Documento de Especificaciones de Software debe ser: correcto,
completo, claro, sin ambigüedades, consistente, verificable, modificable, trazable, etc.
Posiblemente el Documento de Especificaciones de Software vaya evolucionando a medida que se
vaya desarrollando el sistema pedido, por ello los requerimientos deben ser especificados de la
manera más correcta posible de acuerdo a los conocimientos del entorno en su momento y esto debe
marcar una señal para mencionar que la especificación no está completa.
4.4.1 Formato del Documento de Especificación de Software
Este formato está de acuerdo a los lineamientos del estándar IEEE std 830 7.
4.4.1.1. Introducción
4.4.1.1.1 Propósito
Establece el propósito del Documento de Especificaciones, así también su audiencia.
4.4.1.1.2 Alcance
a) Identificar el nombre del Sistema a ser Desarrollado.
b) Explicar lo que hará y no hará el Software a desarrollar.
c) Explicar en que se usará el producto (beneficios, objetivos, metas).
7
IEEE std 830: Estándar de Especificaciones de Software
Unidad de Tecnologías de Información
45
Metodología MDS-α
4.4.1.1.3 Definiciones, siglas y abreviaciones
Definir todos los términos, acrónimos, y abreviaciones requeridos para interpretar de buena
manera el documento.
4.4.1.1.4 Referencias
Proveer una lista completa de todos los documentos utilizados e identificar sus fuentes
(registros, manuales, procedimientos, reglamentos, formularios, etc.).
4.4.1.1.5 Resumen
Describir brevemente lo que contiene el resto del documento como así también su
organización.
4.4.1.2 Descripción General
Se deben describir los factores generales que afectan al producto y sus requerimientos. Tomar en
cuenta que esta sección no establece requerimientos específicos, sino los antecedentes a ellos.
4.4.1.2.1 Perspectiva del Producto
Colocar la perspectiva al producto con otros relacionados, y si el producto es independiente,
debe ser especificado de la siguiente manera:
4.4.1.2.1.1 Interfaces del Sistema
4.4.1.2.1.2 Interfaces del usuario
4.4.1.2.1.3 Interfaces con el hardware
4.4.1.2.1.3 Interfaces con otros software
4.4.1.2.1.4 Interfaces con otros dispositivos de comunicación
4.4.1.2.1.5 Operaciones
4.4.1.2.1.6 Requerimientos de adaptación
Unidad de Tecnologías de Información
46
Metodología MDS-α
4.4.1.2.2 Funciones del Producto
Se debe incluir un resumen de todas las funciones principales que realizara el sistema a
desarrollar, sin incluir detalles.
4.4.1.2.3 Características del Usuario
Incluir las características generales de cada tipo de usuario (enriquecer si se puede su nivel de
educación, experiencia y nivel de aptitud técnica).
4.4.1.2.4 Restricciones
Describir de forma general aquellos aspectos que limitarán las distintas opciones del
desarrollador.
4.4.1.2.5 Suposiciones y dependencias
Listar cada uno de los factores que afectan los requerimientos establecidos en este
documento. Estos factores no deben ser tomados como restricciones de diseño para el
desarrollo del software.
4.4.1.3. Especificación de Requerimientos
Esta sección debe contener todos los requerimientos de software hasta un nivel de detalle suficiente
como para permitir a las personas que participan en el desarrollo del producto un diseño adecuado
del sistema, el cuál satisfaga esos requerimientos. En base a esta especificación los especialistas en
pruebas podrán comprobar que el sistema satisfaga los citados requerimientos.
Cada especificación establecida debe ser percibida externamente por un usuario, operador u otro
sistema externo.
Estos requerimientos específicos deben incluir mínimamente una descripción de cada entrada
(estimulo) al sistema, toda salida (respuesta) del sistema, y toda función realizada por el sistema en
respuesta a la entrada o en soporte a una salida.
Unidad de Tecnologías de Información
47
Metodología MDS-α
4.4.1.3.1 Características del Sistema
Esta sección debe contener la descripción detallada de todos los requerimientos específicos
que el analista y los respectivos usuarios han determinado como funciones del sistema. Para
ello se plantea el llenado de la siguiente forma:
Código de
Especificación
ESP-001
ESP-002
…..
…..
ESP-003
…..
ESP-004
…..
…..
…..
Detalle de la Especificación
Requerimiento
Relacionado
RF-001
RF-001
RF-003
RF-004
RF-004
…..
Caso de Uso
Relacionado
CU-001
CU-001
CU-001
CU-002
CU-002
…..
Form. 4-2: Formulario de Especificación de Requerimientos
Ejemplo de Especificación
RF: El sistema deberá desplegar mensajes de estado en rangos de tiempo regulares no
mayores de 60 segundos.
Luego de analizar el requerimiento (RF) y en concordancia con la participación del usuario se
llega a la siguiente especificación (ESP).
ESP: El gestor de tareas deberá desplegar mensajes de estado en una posición determinada en
la interface de usuario.
§
El mensaje tiene que ser actualizado cada 60 (+/- 10) segundos después de iniciado el
proceso de una tarea.
§
Si la tarea progresa de forma normal, el gestor de tareas deberá mostrar el porcentaje
de avance de la misma.
§
El gestor de tareas debe desplegar el mensaje “Tarea Concluida” cuando la misma
concluya.
§
El gestor de tareas deberá desplegar un mensaje de error si la tarea no puede
continuar o persistió un error.
Unidad de Tecnologías de Información
48
Metodología MDS-α
4.4.1.3.2 Especificaciones de Rendimiento
Mostrar este tipo de especificaciones en cifras numéricas, ya sea de tipo estática o dinámica.
Es decir el tipo de rendimiento que tendrá el producto. Por Ejemplo: Número de terminales
soportadas, usuarios simultáneos, cantidad de información, peso de la base de datos, tiempos
de acceso, etc.).
4.4.1.3.3 Restricciones de diseño
Especificar restricciones de diseño que pueden ser impuestas por otros estándares,
limitaciones de hardware, normas de seguridad, normas de calidad, etc.
4.4.1.3.4 Atributos del Sistema
Atributos del sistema que son especificados para poder ser objetivamente evaluados. Por
ejemplo: la accesibilidad, su inferencia lógica, diseño amigable, etc.
4.4.1.3.5 Otros requerimientos
Otros requerimientos que sean contemplados como importantes antes de firmar el acuerdo o
contrato
4.4.1.4. Acuerdo o Contrato
Se debe redactar un acuerdo o contrato entre las partes involucradas mediante sus respectivas
unidades organizacionales. Una de estas partes puede ser la Unidad de Tecnologías de Información
quien dotara al proyecto del cuerpo de técnicos para el desarrollo del producto pedido.
En el citado documento se hace notar claramente el alcance real que tendrá el sistema, la
participación que tendrán los distintos usuarios y desarrolladores en general, como así también los
respectivos tiempos para el citado proceso.
Finalmente firman al pie del documento los titulares de las unidades organizacionales involucradas o
las personas responsables, para dejar constancia de la aceptación de los términos del acuerdo o
contrato.
Unidad de Tecnologías de Información
49
Metodología MDS-α
4.5 DIAGRAMA DE FLUJO DE DATOS
Los Diagramas de Flujo de Datos o DFD representan de forma gráfica las funciones que el sistema
debe realizar. Dan respuesta a las preguntas ¿Qué transformaciones realizará el sistema? ¿Qué
entradas se transforman en qué salidas?, etc.
Diag. 4-4: Diagrama de Flujo de Datos
Los elementos fundamentales de los diagramas de flujo de datos son:
§
Los procesos se representan por medio de círculos o burbujas. Representan las funciones
individuales que el sistema debe resolver. Las funciones transforman entradas en salidas.
§
Los flujos se muestran por medio de flechas, representan las conexiones entre los procesos
mostrando la información que se necesita como entrada o la que se genera como salida.
Unidad de Tecnologías de Información
50
Metodología MDS-α
§
Los almacenes que se representan por medio de dos líneas. Muestran colecciones de datos
que el sistema debe recordar en el tiempo. Cuando el sistema este concluido, los almacenes
serán archivos o bases de datos.
§
Las entidades externas, típicamente son individuos, grupos de personas, organizaciones
externas, otros sistemas, etc.
Los diagramas derivados de los procesos principales se clasifican en niveles, los cuales son:
§
Nivel 0: Diagrama de contexto.
§
Nivel 1: Diagrama de nivel superior.
§
Nivel 2: Diagrama de detalle o expansión.
Se sugiere no pasar más allá del Nivel 2.
Unidad de Tecnologías de Información
51
Metodología MDS-α
CAPITULO 5
5 ARQUITECTURA DEL SOFTWARE
La arquitectura del software representa la estructura del programa que cohesiona las funcionalidades
más críticas y relevantes (las más necesarias para el sistema), sirviendo de soporte al resto de
funcionalidades finales (necesarias para el usuario). Su especificación es ampliamente aceptada y
representa el problema central de diseño de un sistema de software.
Uno de los principios de las metodologías modernas de desarrollo de software es priorizar la
definición, el diseño, la implementación y la evaluación de la arquitectura del software.
En la construcción de un edificio, se comienza primero por los cimientos, los pilares y las vigas, y los
distintos pisos hasta obtener el esqueleto de soporte principal, después se construyen las paredes,
puertas y ventanas, instalaciones eléctricas, etc. Basta el sentido común para darse cuenta que no
debe empezarse a colocar las paredes sin antes tener los pilares. En resumen, primero se crea el
esqueleto o estructura del edificio y luego se ensamblan las distintas partes. La primera es el soporte
para las segundas y apoyan la mayoría de las funcionalidades básicas del inmueble. ¿Qué pasaría si
existiese un error?, por ejemplo si se olvidase la construcción de una columna o pilar, seguramente el
edificio no podrá tener la certificación de ser habitable; por el contrario si nos olvidásemos de
colocar la bañera, estaríamos restándole solamente una funcionalidad que más luego de acuerdo a
las necesidades pueden de alguna forma corregirse y reubicarse. En este ejemplo se nota claramente,
que el primer error es de mayor efecto e impacto que el segundo.
La estrategia definida anteriormente es aplicada en una diversidad de disciplinas sociales y técnicas,
una de ellas es la creación de software. A diferencia de la construcción de un edificio, el software no
se rige en leyes físicas, ni por procedimientos conocidos, sino que es inherentemente específico; por
ello el diseño de un software es una tarea generalmente única y creativa.
La arquitectura del software debe definirse a partir de un conjunto de requisitos críticos funcionales,
de rendimiento o de calidad. Considerando cómo el software debe dar solución a tales objetivos, la
arquitectura constituye la estructura principal que refleja la solución al problema central.
Unidad de Tecnologías de Información
52
Metodología MDS-α
El equipo de desarrollo debe diseñar, construir y estabilizar primeramente la arquitectura del
software, antes de diseñar e implementar el conjunto de componentes elementales que se integran
en tal arquitectura y que aportan las funcionalidades finales de los usuarios.
La esencia del principio de priorizar la arquitectura es la de dedicar los mínimos esfuerzos a garantizar
la corrección de las partes más importantes, costosas e indefinidas del sistema.
La Arquitectura del Software es un nivel de diseño que va más allá de los algoritmos y las estructuras
de datos. El diseño y la especificación de la estructura del sistema emergen como un nuevo problema.
Los elementos estructurales incluyen: la organización y el control global, los protocolos de
comunicación, la distribución física, la composición de elementos de diseño, la escalabilidad y el
rendimiento, y la elección a las distintas alternativas de diseño.
Definición: Según la IEEE-Std 1471-2000, la Arquitectura del Software es la
organización fundamental de un sistema formada por sus componentes, las
relaciones entre ellos y el contexto en el que se implantarán, y los principios
que orientan su diseño y evolución.
Ante la variedad de definiciones existentes de Arquitectura de Software, se ha tratado de
proporcionar una sistematización de las versiones manipuladas, explicando las mismas en función de
sus clases de modelos, entre ellos:
5.1 MODELOS DE ARQUITECTURA DE SOFTWARE
5.1.1 Modelos Estructurales
Sostienen que la Arquitectura de Software está compuesta por componentes, conexiones entre estos
y aspectos tales como: la configuración, el estilo, las restricciones, la semántica, el análisis, las
propiedades, las racionalizaciones, los requerimientos, las necesidades de los participantes, etc.
5.1.2 Modelos Framework
Son similares a los modelos estructurales, pero enfatiza principalmente en el diseño de una
estructura coherente del sistema completo, a cambio de concentrarse en su composición. Los
modelos de framework a menudo se refieren a dominios o clases de problemas específicos.
Unidad de Tecnologías de Información
53
Metodología MDS-α
5.1.3 Modelos Dinámicos
Puede referirse a los cambios en la configuración del sistema, o a la dinámica involucrada durante el
proceso de la computación (valores de los datos de acuerdo a la dinamicidad).
5.1.4 Modelos de Proceso
Se concentran en la construcción de la arquitectura, y en los pasos o procesos involucrados en esa
construcción. En esta perspectiva, la arquitectura es el resultado de seguir una conducta (script) de
proceso. Esta vista se ejemplifica con el actual trabajo sobre programación de procesos para derivar
arquitecturas.
5.1.5 Modelos funcionales
Se considera a la arquitectura como un conjunto de componentes funcionales, organizados en capas y
que proporcionan servicios hacia arriba. Esta visión es pensada como un framework particular.
Ninguna de estas vistas o modelos excluye a las otras, ni representa un conflicto fundamental sobre lo
que es o debe ser la Arquitectura de Software; por el contrario, representan los diferentes matices en
que pueden aplicarse. En ese sentido se puede decir que la Arquitectura de Software es un nivel
elevado de abstracción de la vista estructural, una combinación de estilos arquitectónicos y que
básicamente involucra los componentes, conexiones, configuración y restricciones.
5.2 ELEMENTOS CLAVE EN LA ARQUITECTURA DE SOFTWARE
Los componentes clave en la Arquitectura de Software son:
§
Componentes
§
Conectores
§
Configuraciones
5.2.1 Componentes
Los ”componentes” son unidades de cómputo (procesamiento) o de almacenamiento de datos. Son
también la ubicación del procesamiento y del estado (clientes, servidores, bases de datos, filtros,
capas, etc). Un componente puede ser simple o compuesto; un componente compuesto representa a
Unidad de Tecnologías de Información
54
Metodología MDS-α
un sistema y, una arquitectura de software con componentes compuestos representa un sistema de
sistemas.
5.2.2 Conectores
Un “conector” es un elemento arquitectónico que modela:
§
Interacciones entre componentes
§
Reglas que gobiernan esas interacciones
Interacciones Simples representan:
§
Llamadas a procedimientos
§
Accesos a variables compartidas
Interacciones complejas y semánticamente ricas representan:
§
Protocolos cliente-servidor
§
Protocolos de acceso a base de datos
5.2.3 Configuraciones / Topologías
Una ”configuración arquitectónica” o ”topología” es una gráfica conectada de componentes y
conectores que describen una estructura arquitectónica. Poseen:
§
Conectividad apropiada
§
Propiedades concurrentes y distribuidas
§
Adherencia a heurísticas de diseño y reglas de estilo
Los componentes compuestos son configuraciones.
5.3 REPRESENTACIÓN ARQUITECTÓNICA
Convencionalmente, para la presente metodología usaremos los siguientes gráficos para representar
los elementos de la arquitectura de software:
Unidad de Tecnologías de Información
55
Metodología MDS-α
Elementos
Representación
Componentes
Conectores
Configuraciones
Tabla 5-1: Representación de los elementos arquitectónicos
Nota: Los conectores pueden ser representados mediante flechas (à) que indiquen la dirección de la
conexión; y si en un conector la conexión es de ambos lados, entonces simplemente se puede dibujar
una línea de enlace sin flechas (o con flechas dependiendo el diseño).
Como se menciono anteriormente, los componentes compuestos representan configuraciones, que a
su vez representan sistemas y en todo modelo arquitectónico de software se debe hacer notar esta
disposición.
Graf. 5-1: Componente compuesto/Configuración/Sistema
Unidad de Tecnologías de Información
56
Metodología MDS-α
5.4 ROL DEL ARQUITECTO DE SOFTWARE
El Worldwide Institute of Software Architects (WWISA) es el Instituto Mundial de Arquitectos de
Software el cuál señala los roles que debe tener un Arquitecto de Software, a ello se citan:
§
Detalla las fases que definen el proceso de construcción del software.
§
Enfatiza “construcción de software” en contraposición a “desarrollo de software” puesto que
teóricamente no hay final para un “desarrollo”.
§
Si se compara el rol de un “Arquitecto” que construye edificios, el “Arquitecto de Software”
construye sistemas (software), no los desarrolla, es el mentor.
5.5 FASES DE LA CONSTRUCCION DEL SOFTWARE
Las fases se derivan de los procesos que se realizan en la construcción de edificaciones, parte de la
analogía Construcción de Edificios Vs Construcción de Software, que es más fácil de entender para los
usuarios. Estas fases se aplican a todos los proyectos de construcción de software.
5.5.1 Fase 1: Pre-Diseño
§
El arquitecto escucha para comprender el alcance del proyecto, los requerimientos y
expectativas del cliente.
§
El arquitecto estudia el contexto del proyecto.
§
Identifica las posibles soluciones
§
Comienza los pasos y surgimiento de una dirección de diseño.
§
Se establecen objetivos generales con relación a presupuestos y tiempos.
5.5.2 Fase 2: Análisis del Dominio
§
El arquitecto emprende la tarea de comprender y documentar completamente las áreas
(dominios) para las cuales el sistema deberá ser construido.
§
Se detalla el comportamiento deseado.
§
El arquitecto evalúa el ambiente de negocios y tecnológico del cliente.
§
Los términos y conceptos del dominio son definidos con precisión.
Unidad de Tecnologías de Información
57
Metodología MDS-α
5.5.3 Fase 3: Diseño Esquemático
§
Se prepara el diseño a nivel arquitectura mostrando las características del dominio y la
estructura tecnológica.
§
Se diseña el estilo de la interfaz de usuario.
§
Se construye prototipos si son necesarios.
§
Se realiza una valoración de los riesgos y de una posible migración.
5.5.4 Fase 4: Desarrollo del Diseño
§
El arquitecto continúa expandiendo el detalle y refinando el diseño.
§
Todos los diagramas de diseño del dominio y tecnología son finalizados (elementos necesarios
para que el cliente valide el cumplimiento a sus requerimientos).
5.5.5 Fase 5: Documentos del Proyecto
§
El arquitecto se enfoca en los requerimientos de aquellos que construirán el sistema.
§
Se documenta el proceso de construcción, los roles en el equipo de trabajo y las secuencias
de construcción.
§
Se escribe la guía de construcción, la guía de estilo de la interfaz de usuario y la guía de
pruebas.
§
El arquitecto especifica las herramientas y métodos a utilizar.
5.5.6 Fase 6: Contratación o Sub-Contratación
§
El arquitecto ayuda a identificar a los posibles constructores del sistema.
§
Para proyectos a ser subcontratados, se invita y evalúa a posibles contratistas/consultores.
§
El arquitecto de software colabora con los detalles del contrato y los costos.
§
Las secuencias de actividades son acordadas y los contratos firmados.
5.5.7 Fase 7: Construcción
§
El arquitecto supervisa la construcción asegurando que la visión del cliente es entendida y
ejecutada.
§
El arquitecto conduce las revisiones del diseño y analiza problemas y solicitudes de cambio.
Unidad de Tecnologías de Información
58
Metodología MDS-α
§
El arquitecto de software diseña los cambios aceptados, valora el impacto en el diseño y el
costo general; también establece la secuencia de los cambios.
§
Participa en las pruebas y revisiones de aceptación.
5.5.8 Fase 8: Post-Construcción
§
El arquitecto ayuda al cliente en la implantación y migración al nuevo sistema.
§
Puede estar involucrado en la capacitación de operadores y usuarios.
§
Asiste en temas relacionados a la garantía y procesos de mantenimiento.
5.6 ABSTRACCION DE LA ARQUITECTURA
Arquitectura
Diseño
Implementación
Graf. 5-2: Abstracción Vista Dimensional Lineal
Base de Datos
Aplicación
Interfaces
Infraestructura
Arquitectura
Diseño
Implementación
Graf. 5-3: Abstracción Vista Dimensional Plana
Unidad de Tecnologías de Información
59
Metodología MDS-α
El siguiente gráfico muestra la Arquitectura de Software del Navegador Mozilla
User Interface
User Interface
Browser Engine Interface
Gecko
Rendering Engine Interface
Necko
Security
NSS/PSM
SpiderMonkey
JavaScript
Interpreter
Expat
XML Parser
Data Persistence
User, Secure, Browser
Persist
UI Toolkit (XPFE)
GTK +
Adapter
GTK+ /X11 Libraries
Display Backend
Networking
Graf. 5-4: Arquitectura de Software del Navegador Mozilla
Diseñar la Arquitectura del Software de un sistema en particular permite:
§
Comunicación entre las personas participantes. Tales personas necesitan abstraer, diseñar,
codificar y comunicarse en términos de grandes bloques.
§
Estandarización a nivel estructural para eludir los desarrollos excesivamente personalizados,
evitando:
o Erosión: Violación a la arquitectura
o Drift: Ignorar la arquitectura
§
Documentación inicial de las decisiones de diseño, misma que deben expresar sistemas de
larga vida.
§
Definición de las restricciones de implementación.
§
Predicción de las cualidades más sobresalientes del sistema.
§
Administración de la evolución del sistema.
§
U otros.
Unidad de Tecnologías de Información
60
Metodología MDS-α
Store Server
Server
Crawler
URL Server
Anchor
URL Resolver
Links
Doc Index
Indexer
Repository
Barrels
Lexicon
Sorter
Page Range
Server
Searcher
Graf. 5-4: Arquitectura de Software del Buscador Google
5.7 ESTILOS ARQUITECTÓNICOS
Un estilo es una forma de organización arquitectónica, el cual define una estructura base conjugando
los componentes, conectores, configuraciones y restricciones; así,
arquitecturas compuestas o
complejas pueden resultar de la composición de estilos básicos.
Los estilos se utilizan para sintetizar estructuras de soluciones definiendo patrones a las distintas
arquitecturas y en la cual se encapsulan configuraciones concretas.
Un tópico importante de la Arquitectura de Software es que se trata de un razonamiento de alto nivel
y calidad operacional, concentrándose en los requerimientos no funcionales que son esenciales para
el éxito de todo proyecto informático. Estos requerimientos de no funcionales están dados por
atributos de calidad (performance, disponibilidad, seguridad, modificabilidad, usabilidad, portabilidad
u otros.) y los estilos arquitectónicos contribuyen eficientemente a tales requerimientos.
Unidad de Tecnologías de Información
61
Metodología MDS-α
En el Anexo 6 se plantea una lista de estilos arquitectónicos y sus correspondientes modelos de
arquitectura de software.
Una clasificación convencional de los estilos arquitectónicos está dada por:
§
Estilos de Flujo de Datos
o Tuberías y filtros
o Secuencial y en lote
§
Estilos Centrados en Datos
o Arquitecturas de Pizarra o Repositorio
o Base de Datos
o Sistemas de Hipertexto
§
§
Estilos de Llamada y Retorno
o
Programa principal y subrutina
o
Model-View-Controller (MVC)
o
Arquitecturas en Capas
o
Arquitecturas Orientadas a Objetos
o
Cliente Servidor
o
Arquitecturas Basadas en Componentes
Estilos de Máquinas Virtuales
o Intérpretes
o Sistemas basados en Reglas
§
Estilos Peer-to-Peer
o Arquitecturas Basadas en Eventos
o Arquitecturas Orientadas a Servicios
o Arquitecturas Basadas en Recursos
§
Estilos Heterogéneos
o Sistemas de Control de Procesos
o Arquitecturas Basadas en Atributos
5.8 LENGUAJE DE DESCRIPCION ARQUITECTÓNICA
Los lenguajes de descripción arquitectónica o ADLs se utilizan para el modelado, la descripción y la
prueba de las arquitecturas, representan los componentes, conectores, configuraciones y
Unidad de Tecnologías de Información
62
Metodología MDS-α
restricciones. Se trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas
de extracción académica. Los ADLs permiten modelar una arquitectura mucho antes que se lleve a
cabo la programación de las aplicaciones que la componen, analizar su adecuación, determinar sus
puntos críticos y eventualmente simular su comportamiento.
Entre los ADLs más conocidos destacan ACME, ARMANI, JACAL Y xADL.
ADL
Acme
Aesop
ArTek
Armani
C2 SADL
CHAM
Darwin
Jacal
LILEANNA
MetaH
Rapide
SADL
UML
UniCon
Wright
xADL
Investigador - Organismo
Monroe & Garlan (CMU), Wile (USC)
Garlan (CMU)
Terry, Hayes-Roth, Erman (Teknowledge,
DSSA)
Monroe (CMU)
Taylor/Medvidovic (UCI)
Berry / Boudol
Magee, Dulay, Eisenbach, Kramer
Kicillof , Yankelevich (Universidad de
Buenos Aires)
Tracz (Loral Federal)
Binns, Englehart (Honeywell)
Luckham (Stanford)
Moriconi, Riemenschneider (SRI)
Rumbaugh, Jacobson, Booch (Rational)
Shaw (CMU)
Observaciones
Lenguaje de intercambio de ADLs
ADL de propósito general, énfasis en estilos
Lenguaje específico de dominio - No es ADL
ADL asociado a Acme
ADL específico de estilo
Lenguaje de especificación
ADL con énfasis en dinámica
ADL - Notación de alto nivel para descripción y
prototipado
Lenguaje de conexión de módulos
ADL específico de dominio
ADL & simulación
ADL con énfasis en mapeo de refinamiento
Lenguaje genérico de modelado – No es ADL
ADL de propósito general, énfasis en
conectores y estilos
Garlan (CMU)
ADL de propósito general, énfasis en
comunicación
Medvidovic, Taylor (UCI, UCLA)
ADL basado en XML
Tabla 5-2: Principales Lenguajes de Descripción Arquitectónica/ADLs
Unidad de Tecnologías de Información
63
Metodología MDS-α
CAPITULO 6
6 DISEÑO Y MODELAMIENTO
El Análisis y Diseño consiste en transformar los requerimientos y especificaciones del usuario
definidos previamente a una especificación formal o informal que describa como implementar un
determinado software.
Esencialmente el Análisis consiste en obtener una visión acerca de lo hace o debe hacer el sistema de
software a desarrollar, en ese sentido su ámbito de resolución está en base a los requisitos
funcionales del sistema. Por otro lado, el Diseño es un refinamiento que toma en cuenta los requisitos
no funcionales, por tanto se centra en como el sistema cumple sus objetivos.
Así, luego de realizar todo el análisis correspondiente de los capítulos de Requerimientos de
Software, Especificaciones del Software y Arquitectura del Software procedemos a diseño y
modelamiento de nuestro sistema.
6.1 INTERFACE DE USUARIO
Graf. 6-1: Diseño o Modelo Navegacional de la Interfaz de Usuario del Caso de Uso de Alquilar Película
Unidad de Tecnologías de Información
64
Metodología MDS-α
Para el caso de la Interface de Usuario utilizaremos el Diseño o Modelo Navegacional, el cual consiste
en mostrar mediante una especificación informal la secuencia de sucesos principales que debe ocurrir
en el funcionamiento del sistema cuando este ya esté desarrollado.
De forma convencional para la presente metodología se determina que las herramientas a utilizar en
los diferentes modelos serán:
Modelo Conceptual
§
Diagrama Entidad Relación (diseño estructurado)
§
Diagrama de Clases (diseño orientado a objetos)
Modelo Lógico
§
Modelo Relacional
Modelo Físico
§
Diccionario de Datos
Tabla 6-1: Convención de Modelos
6.2 MODELO CONCEPTUAL
El Analista/Desarrollador debe concentrarse en la observación de los hechos relevantes que ocurren
en la realidad, mismos que fueron ya expresados en los requerimientos, las especificaciones y la
arquitectura del software, con la finalidad de concebir conceptualmente el sistema y que pueda
automatizar las necesidades de información de la misma.
Para el caso de un Diseño Estructurado se debe utilizar el Modelo Entidad Relación.
CI
Graf. 6-2: Diagrama Entidad Relación (E-R)
Unidad de Tecnologías de Información
65
Metodología MDS-α
Para el caso de un Diseño Orientado a Objetos se debe utilizar el Diagrama de Clases.
Graf. 6-3: Diagrama de Clases
6.3 MODELO LOGICO
Es la representación lógica de la estructura que compondrá la base de datos del sistema. El Modelo
Relacional es el Modelo Lógico en el que se basan la mayoría de los SGBD (Sistema de Gestión de Base
de Datos) comerciales de uso en la actualidad.
De acuerdo al tipo de diseño conceptual elegido, se debe mapear tal modelo para su representación
en el Modelo Relacional. El modelo relacional proporciona una manera simple de representar los
datos, así se trata una tabla bidimensional llamada Relación.
título
La Bicicleta de los Huanca
Mi Socio
año
1995
1972
duración
145
136
tipo
A
B
Tabla 6-2: Tabla Relacional (o simplemente Relación)
Para la comodidad del trabajo bajo este modelo, se utilizan los esquemas:
Películas (título, año, duración, tipo)
Unidad de Tecnologías de Información
66
Metodología MDS-α
y una Tupla estaría dada por:
(Mi Socio, 1972, 136, B)
En un Modelo Relacional, un diseño consiste en uno o más esquemas y a tal conjunto se le conoce
como “Esquema Relacional de la Base de Datos” o simplemente “Esquema de la Base de Datos”.
6.3.1 Normalización
Después de mapear el modelo conceptual al modelo relacional (modelo lógico) se debe aplicar el
proceso de normalización en el esquema de base de datos resultante, la cual consiste en la aplicación
de una serie de reglas para verificar si dicho esquema pertenece o no a una cierta forma normal.
Se aplica la normalización principalmente para:
§
Evitar la redundancia de los datos.
§
Evitar problemas de actualización de los datos en las diferentes tablas de la Base de Datos.
§
Proteger la integridad de los datos.
La normalización es el proceso mediante el cual un esquema de relación que no es satisfactorio se
lleva a un nuevo esquema equivalente pero de mejor calidad en cuanto al diseño, llevando del estado
inicial del esquema hasta una forma normal sin modificar la dependencia de los datos.
Existen varias Formas Normales, unas más restrictivas que otras (Ver Anexo 7).
1FN
2FN
3FN
BCFN
4FN
5FN
Graf. 6-4: Formas Normales
Unidad de Tecnologías de Información
67
Metodología MDS-α
6.4 MODELO FISICO
A partir del Modelo Lógico se describen las estructuras físicas de almacenamiento de los datos, por
ejemplo: definiciones, accesos, índices, tipos de campo, tamaño del campo, restricciones, etc.
Convencionalmente adoptaremos esta descripción detallada de la Base de Datos, aplicando el
desarrollo de la especificación conocida como Diccionario de Datos.
En un modelamiento puro, orientado a objetos; el Modelo Físico estaría dado por:
Graf. 6-5: Modelo Físico Orientado a Objetos
6.4.1 Diccionario de Datos
El Diccionario de Datos es la descripción de información acerca de todos los datos y objetos que
forman la Base de Datos; en él se contiene las características lógicas de los sitios donde se almacenan
los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización.
En una Base de Datos Relacional, el Diccionario de Datos proporciona información acerca de:
§
La estructura lógica y física de la Base de Datos.
§
Las definiciones de todos los objetos de la Base de Datos: tablas, vistas, índices, disparadores,
procedimientos, funciones, etcétera.
Unidad de Tecnologías de Información
68
Metodología MDS-α
§
Los valores por defecto de las columnas de las tablas.
§
Información acerca de las restricciones de integridad.
§
Auditoría de información, como los accesos a los objetos.
§
U otros.
Diccionario de Objetos de la Base de Datos
Se debe describir todos los objetos que conforman la Base de Datos.
Tomando de ejemplo el diagrama anterior (Graf. 6-5) se puede expresar tales datos de la siguiente
manera:
Objeto
Tipo
Definición
Relación
Cardinalidad
auditoria
Tabla
Bitácora de auditoria
servicios
(n:1)
xml_error
(1:n)
grupo_servicios
Tabla
Grupo de servicios de la empresa disponibles
servicios
(1:n)
parametros
Tabla
Parámetros de los servicios de la empresa
servicios
(n:1)
tipo_parametro
(n:1)
Servicios de la empresa definidos por una
componente y una operación
grupo_servicios
(n:1)
parametros
(1:n)
servicios
Tabla
tipo_parametro
Tabla
Tipo de datos de los parámetros de la empresa
(fecha, numero, texto)
parametros
(1:n)
xml_error
Tabla
Xml recibido por el sintetizador que genero un
error al invocar un servicio de la empresa
auditoria
(n:1)
Form. 6-1: Formulario de Objetos de la Base de Datos
donde los valores para Tipo pueden ser:
§ Tabla
§ Vista
§ Procedimiento Almacenado
§ Disparador
§ Función
§ U otros.
Diccionario de Datos de los Objetos de la Base de Datos
Se pretende realizar una descripción detallada de los diferentes elementos que conforman cada uno
de los objetos de la Base de Datos.
Unidad de Tecnologías de Información
69
Metodología MDS-α
Tipo y Nombre del Objeto:
Tabla auditoria
Columna o Variable
Tipo de Dato
Tamaño
Valor por Defecto
Descripción
auditoria_id
int
2
Identificación de auditoria
servicios_id
smallint
1
Es llave foránea a la tabla
servicios
resultado
char
1
‘A’ = Estado inicial
Estado actual de la auditoría
fecha_hora
smalldatetime
4
fecha y hora actual
Para registro temporal de la
auditoria
tiempo
int
2
0 = Cero
Duración de la auditoría en
minutos
descripcion_error
varchar
250
NULL
Para el registro detallado del
error
dispositivo_movil
varchar
20
NULL
Para el registro del tipo de móvil
usuario
int
2
usuario actual
Registro del usuario
Form. 6-2: Formulario de Datos de los Objetos de la Base de Datos
Unidad de Tecnologías de Información
70
Metodología MDS-α
CAPITULO 7
7 IMPLEMENTACION
El objetivo principal del análisis y diseño consiste en transformar los elementos de los mismos en
elementos de implementación, estos pueden ser: códigos fuentes, ejecutables, binarios, etc.
La implementación debe también estar sujeta a las pruebas de unidad, las cuales se limitan a los
componentes de software implementados. Entonces de la implementación se obtiene un sistema
ejecutable estable, constituido por los resultados producidos por los analistas/desarrollares.
Los objetivos específicos de la implementación están dadas por:
§
El arquitecto de software debe planificar las distintas actividades de implementación.
§
Cada desarrollador decide en qué orden implementar los diferentes elementos del
subsistema.
§
Integrar el sistema siguiendo el plan dado por el arquitecto de software.
§
Notificar los errores de diseño, si estos se encuentran.
§
Planificar que subsistemas deben ser implementados y en qué orden deben ser integrados,
formando el Plan de Integración.
§
Probar los subsistemas individualmente.
La estructura de todos los elementos implementados forma el Modelo de Implementación. La
integración debe realizarse de forma incremental, es decir, en cada momento debe añadirse un
elemento a la vez. De esta manera es menos dificultoso localizar los fallos, probando cada
componente más a fondo en el tiempo. En fases tempranas del proceso se pueden implementar
prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el
principio, probar tecnologías o diseñar la interfaz de usuario. Los prototipos pueden ser exploratorios
(desechables) o evolutivos. Estos últimos por lo general llegan a transformarse en el sistema final.
Una vez preparado el Modelo Físico se debe preparar el ambiente correspondiente en un Sistema
Gestor de Base de Datos para alojar cada uno de los objetos descritos en la etapa anterior y de esa
manera dar inicio formalmente a la etapa de implementación.
Unidad de Tecnologías de Información
71
Metodología MDS-α
7.1 GENERACION DE CODIGO
En la presente metodología se ha invertido esfuerzos para desarrollar una convención de codificación
con los estándares más conocidos en este rubro. Así la aplicación de ésta permitirá una buena
legibilidad y compresión de todo código fuente que está basado en dicha convención.
7.1.1 Convenciones de Codificación
En cualquier proyecto de desarrollo de sistemas se hace necesario seguir unas guías comunes para
asegurar una correcta comprensión del código fuente así como su posterior mantenimiento por
personas que no han participado del desarrollo inicial. La disparidad de estilos trae consigo un efecto
negativo en la salud del proyecto; al inicio aparentan ser productivas, ingeniosas, eficaces, pero a
largo plazo cuando llega el momento de corregir errores que ocurren en entornos o condiciones no
previstas, o cuando se deben realizar ampliaciones del sistema, o cuando se necesita incorporar un
nuevo programador; es donde se pueden ver los efectos negativos de las malas prácticas.
La convención de nombres es un conjunto de normas y reglas para la escritura de nombres, código
fuente, identificadores, comentarios u otros elementos dentro de la programación de sistemas, que
facilitan y hacen más comprensible no solamente su lectura sino también su comprensión.
7.1.1.1 Lineamientos generales
§
Salvo necesidades especiales se convendrá que la codificación de los nombres sean escritas
en español, exceptuando aquellas que tienen origen externo pero que son incluidas en
nuestros programadas por los beneficios que estos describan (librerías, componentes,
frameworks, etc.)
§
En los nombres de identificadores queda prohibido el uso de:
o Determinantes:
ü Artículos: el, la, los, las, uno, unos, unas, ….
ü Determinantes demostrativos: este, ese, aquel, ….
ü Determinantes posesivos: mi, tu, su, cuyo, cuyos, cuyas, ….
ü Cardinales: uno, dos, tres, ….
ü Ordinales: segundo, tercero, cuarto, ….
ü Multiplicativos: triple, cuádruple, quíntuple, ….
Unidad de Tecnologías de Información
72
Metodología MDS-α
o Pronombres:
ü Personales: yo, tu, el , ….
ü Recíprocos: os, nos, se, ….
ü Reflexivos: me, te, se, ….
ü Interrogativos/Exclamativos: que, como, cual, cuanto, ….
Las únicas excepciones a estas reglas son el ordinal “Primer” y el multiplicativo “Doble”
§
Evitar el uso de preposiciones, exceptuando situaciones de marcada necesidad: a, ante, bajo,
con, de, desde, en, hacia, hasta, para, ….
§
En todo momento se utilizaran nombres que sean claros, concretos, expresivos y no
ambiguos. Por ejemplo: fechaTransaccion vs fecha, estadoCorrespondencia vs estado, etc.
7.1.1.2 Codificación Camel Case
CamelCase es un estándar en varios lenguajes de programación. Es la práctica de escribir frases o
palabras compuestas eliminando los espacios y poniendo en mayúscula la primera letra de cada
palabra. El nombre se deduce al parecido de estas mayúsculas, a las jorobas de los camellos.
Existen dos tipos de CamelCase:
UpperCamelCase: la primera letra de todas se escribe en mayúscula al igual que las primeras
letras de las restantes palabras. Por ejemplo:
NombreClase
lowerCamelCase: la primera letra de la primer palabra se escribe en minúscula y las primeras
letras de las restantes palabras están escritas en mayúsculas. Por ejemplo:
nombreObjeto
7.1.1.3 Indentación
Para la indentación existen varios estilos tales como: Allman, K&R, BSD KN, Whitesmiths, etc. Por
convención se utilizará el estilo Allman, el cual dice que debemos usar los sangrados (tabulación)
para indentar el código, nunca espacios y colocar las llaves de control en la línea subsiguiente.
Unidad de Tecnologías de Información
73
Metodología MDS-α
Class HolaMundo
{
1 Tab
2 Tab
3 Tab
public metodo()
{
if(condicion)
{
………
llaves en nueva linea
}
}
}
Vista 7-1: Identación
7.1.1.4 Indentar Seteo de Variables
Esto no es un estándar, pero puede tomarse como una buena recomendación. Por ejemplo en PHP se
tiene:
antes
$nombreTemporal = $_FILES['archivo']['nombreTemporal'];
$tamanoArchivo = $_FILES['archivo']['tamano'];
$nombreReal = $_FILES['archivo']['nombre'];
después (con indentación)
$nombreTemporal
$tamanoArchivo
= $_FILES['archivo']['nombreTemporal'];
= $_FILES['archivo']['tamano'];
$nombreReal
= $_FILES['archivo']['nombre'];
Sin duda se lee mejor de la segunda manera, queda más claro y se distinguen mejor las variables.
También podemos hacer lo mismo con los parámetros de funciones cuando las líneas se repiten:
$sitio->configuracion("cabecera"
$sitio->configuracion("menu"
, $cabecera);
, $menu);
$sitio->configuracion("descripcion"
$sitio->configuracion("titulo"
, $descripcion);
, $titulo);
Unidad de Tecnologías de Información
74
Metodología MDS-α
7.1.1.5 Tamaño Máximo de Línea
Evitar que la longitud de la línea no supere los 80 caracteres (esto no es restrictivo). Cuando se supera
esta longitud se debe cortar bajo los siguientes principios:
§
Salto de línea después de la coma
§
Salto de línea después de un operador
§
Alinear la nueva línea con el principio de la expresión en el mismo nivel que la línea anterior
7.1.1.6 Saltos de Línea
Añadir un salto de línea después del cierre de los paréntesis de los parámetros, así también después
de un punto y coma o cuando termine una sentencia.
Class HolaMundo
{
public metodo()
{
if(condicion)
salto de línea
{
valor1 = 1;
valor2 = 2;
}
}
}
Vista 7-2: Salto de Línea
7.1.1.7 Espacios y Líneas en Blanco
§
Usar espacios en blanco para mejorar la legibilidad del código
§
Usar espacios en blanco en ambos lados del operador de símbolos, después de comas y
después de las declaraciones
§
Usar líneas en blanco para separar trozos de código
§
Usar líneas en blanco antes de cada método dentro de la clase
Unidad de Tecnologías de Información
75
Metodología MDS-α
Class HolaMundo
{
Después de una coma
public metodo(parametro1, parametro2)
{
//comentarioA
if(condicionA)
{
valor1 = 1;
valor2 = 2;
}
separación de código
//comentarioB
if(condicionB)
{
valorB = 1 + valor1 ;
}
}
}
separar operadores
Vista 7-3: Espacios y Líneas en Blanco
7.1.1.8 Nombres de Clases
Para el nombre de clases tomar en cuenta:
§
Las clases representan “cosas” y no “acciones”, por tal motivo evitar los verbos.
§
El nombre debe definirse en “singular”, salvo que la clase represente multiplicidad de cosas.
§
Los nombres de las clases deben ser “sustantivos”. Por ejemplo Automovil, Persona, Pais,
Armamento, Empresa
§
Cada clase debe tener un bloque de documentación según la norma del lenguaje
(phpDocumentor para PHP, javaDoc para Java, etc.).
En la definición del nombre de clases se aplicara el estilo CamelCase. Solo deberían contener
caracteres alfanuméricos incluyendo el carácter underscore (_). Tal nombre debe ser significativo y
brindar una idea de lo que representa. La primera letra siempre debe ir en mayúscula
(UpperCamelCase).
Unidad de Tecnologías de Información
76
Metodología MDS-α
Por ejemplo:
definición incorrecta: clase_ejemplo, nombreClase
definición correcta: NombreClase, Nombre_Clase
7.1.1.9 Interfaces
Las interfaces seguirán las mismas reglas de las clases con la única exigencia que deben añadirse en la
terminación la palabra Interface.
Por ejemplo:
BaseDatosInterface
7.1.1.10 Funciones, Procedimientos y Métodos
Las funciones y métodos deben estar en lowerCamelCase, utilizando en caso necesario el caracter
underscore (_) para separar palabras brindando el sentido completo y humano de su funcionamiento.
Un buen nombre para una rutina es aquel que describe todo lo que hace la rutina; bajo ningún caso
utilizar verbos genéricos. Por ejemplo: procesarActivo, gestionarFuncionario, etc. El nombre debe
consistir en un verbo seguido del objeto al que afecta.
Por ejemplo:
imprimirFichaActivo
modificarDatosFuncionario
calcularPromedioPonderado
7.1.1.11 Parámetros
Los parámetros de rutinas deben estar ordenados de la siguiente manera:
§
Primero los parámetros de entrada o solo lectura.
§
Después los parámetros de transporte o de lectura/escritura
§
Finalmente, los parámetros exclusivamente de salida
No se deben utilizar los parámetros como variables comunes (auxiliares, contadores, temporales,
generales, etc.). Por ejemplo el siguiente fragmento de código es inapropiado:
Unidad de Tecnologías de Información
77
Metodología MDS-α
function funcionCalculoEjemplo($entrada, $salida)
{
$entrada = $entrada + funcionOtroCalculo($entrada);
$entrada = $entrada + ($entrada / 2);
…………..
$salida = $entrada;
}
La única situación en la que se permite la modificación de los parámetros de entrada es para
normalizar su valor como preparación a su uso.
function funcionEjemplo($codigoBarra)
{
$codigoBarra = trim(strtoupper($codigoBarra));
…………..
}
7.1.1.12 Variables
Cualquier tipo de variables deben estar escritas en lowerCamelCase y cuando una variable representa
una instancia de una clase debe tener el mismo nombre de la clase con el prefijo obj haciendo alusión
a la creación del objeto correspondiente, también en lowerCamelCase; y de forma similar a los
anteriores utilizar el carácter underscore (_) cuando sea necesario para separar las palabras.
Asimismo se recomienda utilizar en el nombre de las variables un sentido completo y humano que
refleje el funcionamiento del mismo.
Por Ejemplo:
obj_persona
contador
ejeX
controlador
Unidad de Tecnologías de Información
78
Metodología MDS-α
7.1.1.13 Nomenclatura de Variables
Es recomendable para asegurar la legibilidad del programa y de su entorno usar nombres con prefijos
que señalen su clasificación, por ejemplo:
Clasificación
Prefijo
Ejemplo
Global
glb_
glb_contador
Puntero
ptr_
ptr_pilaPeso
Arreglo
arr_
arr_tiempoRecorrido
Instancia de una Clase / Objeto
obj_
obj_funcionario
Formulario
frm_
frm_datosCorrespondencia
Texto
txt_
txt_nombreFuncionario
Select / Combo
cmb_
cmb_profesion
Checkbox
chk_
chk_listaProducto
Radio
rad_
rad_color
Submit
sbm_
sbm_aceptar
Button
btn_
btn_reportePlanilla
Tabla 7-1: Convención para los objetos de la programación
Para el tratamiento de codificación en la web es conveniente la siguiente convención:
Clasificación
Prefijo
Ejemplo
Password
psw_
psw_firmaDigital
File
fil_
fil_archivoPrecio
Reset
rst_
rst_limpiar
Hidden
hdn_
hdn_estadoModelo
Método Get
mgt_
mgt_txt_nombreFuncionario
Método Post
mpo_
mpo_cmb_profesion
Método Put
mpu_
mpu_chk_listaProducto
Tabla 7-2: Convención para los objetos/métodos de la web
7.1.1.14 Constantes
Las constantes deben ir en mayúscula, inclusive las constantes de clase. Utilizar el caracter
underscore (_) cuando sea necesario para separar las palabras. Por ejemplo:
PATH_MODELO
NOMBRE_SISTEMA
Unidad de Tecnologías de Información
79
Metodología MDS-α
7.1.1.15 Comentarios
§
Los comentarios deben tener el mismo nivel de indentación que el código que comentan.
§
Los comentarios deben ser fáciles y sencillos de generar y modificar. Por ejemplo lo expuesto
a continuación es opuesto a lo estipulado a esta convención:
/**********************************************************
*
*
*
Esta es una función que calcula la depreciación de los activos *
*
mediante el método de línea recta
*
*
*
***********************************************************/
§
Los comentarios no deben repetir el código ni formularlo de otra manera, sino que deben
explicar la intensión del mismo.
§
En cada módulo, clase, método, función, procedimiento o rutina importante se debe
mantener un bloque de comentarios que describa según su necesidad lo siguiente:
o Su razón, entorno o cometido
o Los parámetros que acepta, valores o rangos válidos. Precondiciones
o El resultado que devuelve. Postcondiciones
o Excepciones que se provocan
o Efectos secundarios que se provocan, incluyendo cambios en variables globales
§
Aquellos métodos o funciones que devuelven valores nulos deben explicar las circunstancias
de los mismos (inexistente, sin dato, no aplicable, etc.)
§
Las funciones que traten con porcentajes, permiles u otros, deben explicar sus rangos de
acción. Por ejemplo: [0-1] , [0-100], [0-1000], …
§
Las funciones matemáticas, físicas u otras que expresen magnitudes deben describir
claramente las respectivas unidades de medición
§
En caso de desactivar temporalmente fragmentos de código, se debe comentar la razón que
expone esta decisión (nuevo requerimiento, afinación, etc.) y cuando se prevé su activación.
§
En situaciones que se expresen condiciones particulares con cierta especialidad se
recomienda realizar cometarios para ayudar su comprensión; esto generalmente ocurre en
los bucles.
Por ejemplo:
Unidad de Tecnologías de Información
80
Metodología MDS-α
//se busca el caracter delimitador para determinar el parrafo
while(corriente.cadena(posicion) != CARACTER_DELIMITADOR )
{
……
}
§
Se debe aplicar la norma de documentación interna que acompaña al lenguaje de
programación utilizado en la creación de un sistema en particular. Por ejemplo
phpDocumentor si se utiliza PHP, JavaDoc si se usa Java, etc.
7.1.1.16 Notificación de Errores
§
Cualquier comunicación de error al usuario debe ser sutil, educado y que además exprese la
posible solución. No echar la culpa al usuario.
§
En lo posible se debe gestionar un control preventivo de datos para evitar una notificación de
errores a posteriori.
§
Delimitar claramente una tabla de errores estándar y su posterior tratamiento a estas
excepciones y notificarlas de forma clara y concisa, permitiendo al usuario la identificación de
errores típicos.
7.1.1.17 Nombres de Archivos
Los nombres de archivos deben estar en lowerCamelCase utilizando el carácter underscore (_) cuando
sea necesario para separar las palabras. Los nombres de los archivos deben ser significativos o
humanizados y que representen el objetivo del archivo.
Por ejemplo:
formulario/controlador/formularioServicio.php
libreria/plantilla/datosBasicos.php
Unidad de Tecnologías de Información
81
Metodología MDS-α
7.1.1.18 ESTILO DE CODIFICACIÓN
7.1.1.18.1 Cadenas de Caracteres
En lenguajes script como el PHP, las cadenas deben utilizar el caracter de comilla simple (') cuando no
se requiera sustitución interna de variables; y cuando exista sustitución debe utilizarse la doble
comilla.
Por ejemplo:
$nombre
= 'Daniel Abasto';
$miNombre = "Mi nombre es $nombre";
7.1.1.18.2 Concatenación de Caracteres
En lenguajes script como el PHP, la concatenación debe realizarse usando el operador punto (.) sin
dejar espacios entre los operandos.
Por ejemplo:
$sql = "select count(*) from ".$tabla;
Cuando ocupen varias líneas se debe indentar la concatenación al nivel del operador igual.
Por ejemplo:
$sql = "select count(*) from ".$tabla.
"where campo = 'A'";
Unidad de Tecnologías de Información
82
Metodología MDS-α
CAPITULO 8
8 PRUEBAS
El principal objetivo de las pruebas consiste en evaluar la calidad del producto que se está
desarrollando a través de las diferentes etapas de desarrollo; así mediante la aplicación de pruebas
concretas se podrán validar las distintas suposiciones hechas en el diseño y que los requerimientos se
estén cumpliendo satisfactoriamente; esto significa decir que se verifica que el producto funcione
como se diseño y que los requerimientos son satisfechos cabalmente como los pretende el usuario
final.
En las pruebas se debe encontrar, documentar y solucionar los diferentes defectos en la calidad del
sistema. Las pruebas deben realizarse en todo el ciclo de vida del desarrollo del sistema para de esa
manera ir refinándolo en todo momento y no esperar hasta el final del mismo.
Sus objetivos específicos están dados por:
§
Encontrar y documentar defectos en la calidad del software.
§
Notificar la calidad observada del software.
§
Proveer un medio de validación para las suposiciones hechas en el diseño y especificaciones
de los requerimientos por medio de demostraciones concretas.
§
Validar que los requerimientos fueron implementados apropiadamente.
§
Validar las funciones del producto de software según lo diseñado.
Para llevar adelante el proceso de las pruebas deberá planificarse que es lo que hay que probar, para
ello se debe diseñar como se va a llevar a cabo la prueba, implementar todo lo necesario para
concretar esta actividad, ejecutarlas en los niveles necesarios y obtener los resultados, de forma tal
que la información obtenida sirva para ir refinando el producto a desarrollar.
El fin de la prueba no consiste en asegurar la calidad, pero si evaluarla, y proporcionar una
realimentación a su debido tiempo, de forma que los aspectos de calidad puedan resolverse y
evolucionar de manera efectiva en tiempo y costo.
Unidad de Tecnologías de Información
83
Metodología MDS-α
Los principales aspectos a ser evaluados en un producto software son:
§
La funcionalidad (¿hace lo que debe?).
§
La fiabilidad (¿resistente a fallos?).
§
El rendimiento (¿lleva a cabo su trabajo de manera efectiva?).
Las pruebas pueden hacerse a diferentes niveles dependiendo del objetivo de los mismos, entre estos
tenemos:
§
Pruebas de Unidad: se prueban las unidades mínimas por separado, y normalmente se hace
durante la implementación misma.
§
Pruebas de Integración: evaluaciones de varias unidades juntas.
§
Pruebas de Sistema: sobre la aplicación o sistema completo.
§
Pruebas de Implantación: dirigida al inicio y aceptación de operaciones mediante el sistema.
§
Pruebas de Aceptación: realizado sobre el sistema global por los diferentes usuarios o
terceras personas.
§
Pruebas de Regresión: realizada después de haber incluido un proceso de modificación o
actualización para no incluir errores o procesos defectuosos.
8.1 PRUEBAS UNITARIAS
Las pruebas unitarias se realizan principalmente para verificar la funcionalidad y estructura de cada
componente individualmente una vez que ha sido codificado. Constituyen la prueba inicial de un
sistema y las demás pruebas deben apoyarse sobre ellas.
Existen dos enfoques principales para el diseño de casos de prueba:
§
Enfoque Estructural o de Caja Blanca: Se verifica la estructura interna con independencia de la
funcionalidad del componente. Esto equivale a decir que, no se comprueba la corrección de
los resultados si éstos se producen. Ejemplos de este tipo de pruebas pueden ser:
o
Ejecutar todas las instrucciones del programa.
o Localizar código no usado
o Comprobar los caminos lógicos del programa
o U otros.
Unidad de Tecnologías de Información
84
Metodología MDS-α
§
Enfoque Funcional o de Caja Negra. Se comprueba el correcto funcionamiento de los
componentes del sistema de información, analizando las entradas y salidas y verificando que
el resultado es el esperado. Se consideran exclusivamente las entradas y salidas del sistema
sin preocuparse por la estructura interna del mismo.
El enfoque general que suele tomarse para una prueba unitaria está orientado al de caja blanca,
aunque puede existir complementación con caja negra. El hecho de tomar los casos de caja blanca se
debe, a que el tamaño del componente es apropiado para examinar la lógica del desarrollo.
Para llevar adelante las pruebas unitarias se deben seguir los siguientes pasos:
§
Registrar los resultados de todos los casos de prueba asociados a cada verificación establecida
en el plan de pruebas. Los casos de prueba deben contemplar tanto las condiciones válidas y
esperadas como las inválidas e inesperadas.
§
Corregir los errores o defectos encontrados y repetir las pruebas que se detectaron. Si se
considera necesario, debido a su implicación o importancia, se repetirán otros casos de
prueba ya realizados con anterioridad.
La prueba unitaria se da por finalizada cuando se hayan realizado todas las verificaciones establecidas
y no se encuentre ningún defecto, o bien se determine su suspensión.
8.2 PRUEBAS DE INTEGRACION
Las pruebas de integración se realizan para verificar el correcto ensamblaje entre los distintos
componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan
correctamente mediante sus respectivas interfaces, tanto internas como externas, cubren la
funcionalidad establecida y se ajustan a los requisitos no funcionales.
En las pruebas de integración se examinan las interfaces de los distintos componentes o subsistemas
para asegurar que son llamados cuando son necesarios y que los datos o mensajes que se transmiten
son los requeridos.
Los tipos fundamentales de integración son los siguientes:
Unidad de Tecnologías de Información
85
Metodología MDS-α
Integración Incremental
Se combina el siguiente componente que se debe probar con el conjunto de componentes que ya
están probados y se esa manera se va incrementando progresivamente el número de componentes a
probar.
Así se distinguen las siguientes estrategias de integración:
§
De Arriba Abajo (Top-Down): El primer componente que se desarrolla y prueba es el primero de la
jerarquía (A). Los componentes de nivel más bajo se sustituyen por componentes auxiliares para
simular a los componentes invocados. Una de las ventajas de aplicar esta estrategia es que las
interfaces entre los distintos componentes se prueban en una fase temprana y con frecuencia.
§
De Abajo Arriba (Bottom-Up): En este caso se crean primero los componentes de más bajo nivel
(E, F) y se crean componentes conductores para simular a los componentes que los llaman. A
continuación se desarrollan los componentes de más alto nivel (B, C, D) y se prueban. Por último
dichos componentes se combinan con el que los llama (A). Los componentes auxiliares son
necesarios en raras ocasiones. Este tipo de enfoque permite un desarrollo más en paralelo que el
enfoque de arriba abajo, pero presenta mayores dificultades a la hora de planificar y de gestionar.
§
Estrategias Combinadas: A menudo es útil aplicar las estrategias anteriores de forma conjunta. De
este modo, se desarrollan partes del sistema con un enfoque "Top-Down", mientras que los
componentes más críticos en el nivel más bajo se desarrollan siguiendo un enfoque "Bottom-Up".
En este caso se recomienda una planificación cuidadosa y coordinada, de manera tal que el éxito
de la prueba sea la esperada.
Graf. 8-1: Organización de la estrategia de integración incremental
Unidad de Tecnologías de Información
86
Metodología MDS-α
Integración No Incremental
Se prueba cada componente por separado y posteriormente se integran todos de una vez realizando
las pruebas pertinentes. Este tipo de integración se denomina también “Big-Bang” (gran explosión).
8.3 PRUEBAS DEL SISTEMA
Las pruebas del sistema consisten en ejercitar profundamente el sistema, comprobando la
integración del sistema de información globalmente, verificando el funcionamiento correcto de las
interfaces entre los distintos subsistemas y con el resto de los sistemas externo con los que se
comunica. Así las pruebas del sistema son pruebas de integración completas, y permiten probar el
sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las
especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su comportamiento
en el entorno de producción.
Una vez que se han probado los componentes individuales y se han integrado, se prueba el sistema
de forma global. En esta etapa pueden distinguirse los siguientes tipos de pruebas, cada uno con un
objetivo claramente diferenciados:
§
Pruebas Funcionales: Dirigidas a asegurar que el sistema de información realiza
correctamente todas las funciones que se han detallado en las especificaciones dadas por el
usuario del sistema.
§
Pruebas de Comunicaciones: Determinan que las interfaces entre los componentes del
sistema funcionan adecuadamente, tanto a través de dispositivos remotos, como locales.
Asimismo, se han de probar las interfaces hombre/máquina.
§
Pruebas de Rendimiento: Consisten en determinar que los tiempos de respuesta están dentro
de los intervalos establecidos en las especificaciones del sistema.
§
Pruebas de Volumen: Consisten en examinar el funcionamiento del sistema cuando está
trabajando con grandes volúmenes de datos, simulando las cargas de trabajo esperadas.
§
Pruebas de Sobrecarga: Consisten en comprobar el funcionamiento del sistema en el umbral
límite de los recursos, sometiéndole a cargas masivas. El objetivo es establecer los puntos
extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos.
Unidad de Tecnologías de Información
87
Metodología MDS-α
§
Pruebas de Disponibilidad de Datos: Consisten en demostrar que el sistema puede
recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de
los datos.
§
Pruebas de Facilidad de Uso: Consisten en comprobar la adaptabilidad del sistema a las
necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de
trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y
obtener los resultados.
§
Pruebas de Operación. Consisten en comprobar la correcta implementación de los
procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y
rearranque del sistema, etc.
§
Pruebas de Entorno: Consisten en verificar las interacciones del sistema con otros sistemas
dentro del mismo entorno.
§
Pruebas de Seguridad: Consisten en verificar los mecanismos de control de acceso al sistema
para evitar alteraciones indebidas en los datos.
8.4 PRUEBAS DE IMPLANTACION
Las pruebas de implantación consisten en comprobar el funcionamiento correcto del sistema
integrado (hardware y software) en el entorno de operación, y permitir al usuario operador realizar la
aceptación del sistema una vez instalado en su entorno real, en base al cumplimiento de los
requisitos no funcionales dados por estos últimos.
Una vez que hayan sido realizadas las pruebas del sistema en el entorno de desarrollo, se llevan a
cabo las verificaciones necesarias para asegurar que el sistema funcionará correctamente en el
entorno de operación. Debe comprobarse que responde satisfactoriamente a los requisitos de
rendimiento, seguridad, operación y coexistencia con el resto de los sistemas de la instalación para
conseguir la aceptación del usuario de operación.
Las pruebas de seguridad van dirigidas a verificar que los mecanismos de protección incorporados al
sistema cumplen su objetivo; las pruebas de rendimiento a asegurar que el sistema responde
satisfactoriamente en los márgenes establecidos en cuanto tiempos de respuesta, de ejecución y de
utilización de recursos, así como los volúmenes de espacio en disco y capacidad; por último con las
pruebas de operación se comprueba que la planificación y control de trabajos del sistema se realiza
Unidad de Tecnologías de Información
88
Metodología MDS-α
de acuerdo a los procedimientos establecidos, considerando la gestión y control de las
comunicaciones y asegurando la disponibilidad de los distintos recursos.
Asimismo, también se llevan a cabo las pruebas de gestión de copias de seguridad y recuperación,
con el objetivo de verificar que el sistema no ve comprometido su funcionamiento al existir un
control y seguimiento de los procedimientos de salvaguarda y de recuperación de la información, en
caso de caídas en los servicios o en algunos de sus componentes. Para comprobar estos últimos, se
provoca el fallo del sistema, verificando si la recuperación se lleva a cabo de forma apropiada. En el
caso de realizarse de forma automática, se evalúa la inicialización, los mecanismos de recuperación
del estado del sistema, los datos y todos aquellos recursos que se vean implicados.
Las verificaciones de las pruebas de implantación y las pruebas del sistema tienen muchos puntos en
común al compartir algunas de las fuentes para su diseño como pueden ser los casos para probar el
rendimiento (pruebas de sobrecarga o de Stress).
El responsable de implantación junto al equipo de desarrollo determina las verificaciones necesarias
para realizar las pruebas así como los criterios de aceptación del sistema. Estas pruebas las realiza el
equipo de operación, integrado por los técnicos de sistemas y de operación que han recibido
previamente la formación necesaria para llevarlas a cabo.
8.5 PRUEBAS DE ACEPTACION
Las pruebas de aceptación consisten en validar que un sistema cumple con el funcionamiento
esperado y permitir la aceptación por parte del usuario de dicho sistema, principalmente desde el
punto de vista de su funcionalidad y rendimiento.
Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de
desarrollo, aunque la ejecución y aprobación final corresponden al usuario. Estas pruebas van
dirigidas a comprobar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en
el catálogo de requisitos y especificaciones con los diferentes criterios de aceptación.
El responsable de usuarios debe revisar los criterios de aceptación que se especificaron previamente
en el plan de pruebas del sistema y, posteriormente, dirigir las pruebas de aceptación final.
Unidad de Tecnologías de Información
89
Metodología MDS-α
La validación del sistema se consigue mediante la realización de pruebas de caja negra que
demuestran la conformidad de los requisitos y que se recogen en el plan de pruebas, el cual define las
verificaciones a realizar y los casos de prueba asociados. Dicho plan está diseñado para asegurar que
se satisfacen todos los requisitos funcionales especificados por el usuario sin dejar de lado los
requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos
y procesos, así como a los distintos recursos del sistema.
La formalidad de estas pruebas dependerá en mayor o menor medida de cada organización, y vendrá
dada por la criticidad del sistema, el número de usuarios implicados en las mismas y el tiempo del que
se disponga para llevarlas cabo, entre otros.
8.6 PRUEBAS DE REGRESION
Las pruebas de regresión se realizan con el fin de eliminar el efecto onda, es decir, comprobar que los
cambios sobre un componente de un sistema de información, no introducen un comportamiento no
deseado o errores adicionales en otros componentes no modificados.
Las pruebas de regresión se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto
para corregir un error como para realizar una mejora. No es suficiente probar sólo los componentes
modificados o añadidos, o las funciones que en ellos se realizan, sino que también es necesario
controlar que las modificaciones no produzcan efectos negativos sobre el mismo u otros
componentes.
Normalmente, este tipo de pruebas implica la repetición de las pruebas que ya se han realizado
previamente, con el fin de asegurar que no se introducen errores que puedan comprometer el
funcionamiento de otros componentes que no han sido modificados y confirmar que el sistema
funciona correctamente una vez realizados los cambios.
Las pruebas de regresión pueden incluir:
§
La repetición de los casos de pruebas que se han realizado anteriormente y están
directamente relacionados con la parte del sistema que fue modificado.
§
La revisión de los procedimientos manuales preparados antes del cambio, para asegurar que
permanecen correctamente.
Unidad de Tecnologías de Información
90
Metodología MDS-α
§
La obtención impresa del diccionario de datos de forma que se compruebe que los elementos
de datos que han sufrido algún cambio son correctos.
El responsable de realizar las pruebas de regresión será el equipo de desarrollo junto al técnico de
mantenimiento, quien a su vez, será responsable de especificar el plan de pruebas de regresión y de
evaluar los resultados de dichas pruebas.
Unidad de Tecnologías de Información
91
Metodología MDS-α
CAPITULO 9
9 IMPLANTACIÓN DEL SISTEMA
En esta fase se deben realizar las actividades necesarias para poner a disposición de los usuarios el
sistema de información desarrollado y en función a sus características se define un plan de
implantación señalando a todas las personas participantes en el proceso.
Antes de pasar a un ambiente de producción se debe preparar la infraestructura necesaria para
configurar el entorno, instalar cada uno de los componentes, activar los distintos procedimientos,
migración o carga inicial de datos.
Para establecer el plan de implantación se debe tomar en cuenta:
§
El cumplimiento de los diferentes requerimientos de implantación.
§
La estrategia de transición del antiguo sistema al nuevo.
9.1 DEFINICION DEL PLAN DE IMPLANTACION
Previamente se revisa la estrategia de implantación del sistema, analizando las posibles dependencias
con otros sistemas, que puedan condicionar en alguna medida el plan de implantación. Seguidamente
se constituye el equipo de implantación, determinando el recurso humano correspondiente para la
instalación, implantación y preparación del mantenimiento, para ello debe señalarse cada uno de los
perfiles y los niveles de responsabilidad.
La estrategia de implantación deberá tomar en cuenta información como ser: la envergadura del
proyecto, el número de sistemas involucrados en la implantación, la cobertura geográfica, la
capacitación de los usuarios, etc.; para luego en el plan de implantación calcular adecuadamente el
esfuerzo y los recursos necesarios.
Esta fase requerirá trabajos con los usuarios operadores, la instalación de las diferentes herramientas
informáticas, la publicación y ejercicio del servicio, un plan de mantenimiento, resguardo de los
códigos fuente y bases de datos, capacitación de los usuarios, etc.
Unidad de Tecnologías de Información
92
Metodología MDS-α
9.2 CAPACITACION
En función al plan de implantación se debe revisar y efectivizar las diferentes actividades de
capacitación y formación de los usuarios finales, para ello:
§
Asegurar que se cuenta con los recursos humanos, técnicos y materiales necesarios para
realizar la actividad correspondiente.
§
Establecer el plan de capacitación del sistema de información con la única finalidad de
garantizar el éxito de la implantación.
§
Determinar en función a los distintos esquemas de formación asociados a los distintos
perfiles, los contenidos que tienen los cursos, quienes los van a recibir, su prioridad y
sobretodo los tiempos que se impartirán los mismos.
§
También posibilitar la realización del seguimiento operacional a los distintos usuarios
beneficiados con la capacitación con la finalidad de informar las posibles desviaciones para
tomar las medidas oportunas.
9.3 MANUAL DE INSTALACION
Conformar un documento que señale la infraestructura base que se necesita para lograr la instalación
y puesta en producción del software desarrollado, para ello tomar en cuenta que tal infraestructura
debe cumplir los requisitos descritos en el plan de implantación.
Algunos temas puntuales que se deben tener en este documento son:
§
Requisitos de implantación (instalación e infraestructura).
§
Procedimientos de seguridad y control de accesos (mantenimiento de la integridad y
confiabilidad de los datos, control de acceso al sistema, copias de seguridad y recuperación
de datos, etc.).
§
Operación y administración del sistema (estándares, recuperación y reanudación de trabajos,
planificación de trabajos, etc.).
§
Y si el sistema trae consigo un proceso de migración o carga de datos se debe señalar
puntualmente cada uno de los pasos que estas actividades involucra.
§
Señalar el equipo responsable de la instalación, pruebas de implantación y aceptación del
sistema.
Unidad de Tecnologías de Información
93
Metodología MDS-α
Y en lo que respecta al trabajo con las Bases de Datos se debe señalar también su respectivo plan,
señalando básicamente:
§
La creación de la Base de Datos a partir del Modelo Lógico.
§
Establecimiento de los procedimientos de explotación, uso y actualización de las Bases de
Datos.
§
Establecimiento de los procedimientos de las copias de seguridad de los datos y su
restauración indicando la temporalidad de los mismos.
§
Señalizar el procedimiento de los tipos de usuarios de las bases de datos, sus respectivos
permisos según los distintos perfiles de los usuarios del sistema.
Y por último, señalar los procedimientos de operación y administración del sistema incluyendo el
arranque y cierre, recuperación y reanudación del sistema según una frecuencia establecida.
9.4 MANUAL DEL USUARIO
Desarrollar un documento se pueda ser utilizado como una guía, para mostrar y a la vez enseñar al
usuario acerca de las distintas funcionalidades que tiene el sistema. Tal documento debe responder a
los diferentes requerimientos y especificaciones hechas por el usuario.
Un manual de usuario debe estar redactado de manera simple y concisa, que pueda ser entendible
por cualquier tipo de persona (usuarios, técnicos, operadores, etc.) y mínimamente debe incluir:
§
Un prefacio, con información sobre cómo usar el propio manual.
§
Un índice.
§
Una guía detallada que describa la funcionalidad del sistema.
§
Una sección de resolución de problemas típicos.
§
Información de contacto.
§
Un Glosario.
Unidad de Tecnologías de Información
94
Metodología MDS-α
CAPITULO 10
10 MANTENIMIENTO DEL SISTEMA
El objetivo de este proceso es la obtención de una nueva versión de un sistema de información en
particular, y se lo realiza a partir de las peticiones de mantenimiento que los usuarios realizan con
motivo de un problema detectado en el sistema, o por la necesidad de una mejora del mismo.
En este proceso se realiza el registro de las peticiones de mantenimiento con el fin de llevar el control
de las mismas y de proporcionar, si fuera necesario, datos estadísticos de peticiones recibidas o
atendidas en un determinado periodo, sistemas que se han visto afectados por los cambios, en qué
medida y el tiempo empleado en la resolución de dichos cambios. Es recomendable, por lo tanto,
llevar un catálogo de peticiones de mantenimiento sobre los sistemas de información, en el que se
registren una serie de datos que nos permitan disponer de la información antes mencionada.
En el momento en el que se registra la petición, se procede a diagnosticar de qué tipo de
mantenimiento se trata. Atendiendo a los fines, podemos establecer los siguientes tipos de
mantenimiento:
§
Correctivo: son aquellos cambios precisos para corregir errores del producto software.
§
Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto
software para cubrir la expansión o cambio en las necesidades del usuario.
§
Adaptativo: son las modificaciones que afectan al entorno en que el sistema opera, por
ejemplo: cambios de configuración del hardware, software de base, gestores de base de
datos, comunicaciones, etc.
§
Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en
cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y
optimización del rendimiento y eficiencia.
Una vez registrada la petición e identificado el tipo de mantenimiento y su origen, se determina a los
responsabilidad de atender la petición. En el supuesto de que la petición sea remitida, se registra en
el catálogo de peticiones de mantenimiento y continúa el proceso.
La petición puede ser denegada; en este caso, se notifica al usuario y acaba el proceso.
Unidad de Tecnologías de Información
95
Metodología MDS-α
Posteriormente, según el tipo de mantenimiento, se verifica y reproduce el problema, o se estudia la
viabilidad del cambio propuesto por el usuario; en ambos casos se estudia el alcance de la
modificación.
Hay que analizar las alternativas de solución identificando, según el tipo de mantenimiento de que se
trate, cuál es la más adecuada. El plazo y urgencia de la solución a la petición se establece de acuerdo
con el estudio anterior.
La definición de la solución incluye el estudio del impacto de la solución propuesta para la petición en
los sistemas de información afectados. Mediante el análisis de dicho estudio, la persona encargada
del Proceso de Mantenimiento valora el esfuerzo y coste necesario para la implementación de la
modificación.
Las tareas de los procesos de desarrollo que va a ser necesario realizar son determinadas en función
de los componentes del sistema actual afectados por la modificación. Estas tareas pertenecen a
actividades de los procesos generales de Análisis, Diseño, Construcción e Implantación.
Por último, y antes de la aceptación del usuario, es preciso establecer un plan de pruebas de
regresión que asegure la integridad del sistema de información afectado.
La mejor forma de mantener el coste de mantenimiento bajo control es una gestión del Proceso de
Mantenimiento efectiva y comprometida. Por lo tanto, es necesario registrar de forma disciplinada
los cambios realizados en los sistemas de información y en su documentación. Esto repercutirá
directamente en la mayor calidad de los sistemas resultantes.
Lo dicho anteriormente puede esquematizarse como sigue:
§
Registro de la Petición para mantener una estandarización de las diferentes solicitudes
(catálogo de mantenimiento) mejorando de esta manera el flujo de trabajo de las personas
involucradas.
§
Asignación de la Petición para realizar su estudio de viabilidad según las soluciones
identificadas para luego brindar una respuesta (aceptación o rechazo). Si se acepta la petición
se identifica al responsable de atender este asunto.
§
Análisis de la Petición llevando a cabo el diagnóstico y análisis del cambio para dar respuesta
a las peticiones de mantenimiento que han sido aceptadas en la actividad anterior. Se analiza
el alcance de la petición en lo referente a los sistemas de información afectados, valorando
Unidad de Tecnologías de Información
96
Metodología MDS-α
hasta qué punto pueden ser modificados en función del ciclo de vida estimado para los
mismos.
§
Verificación y Estudio de la Petición que una vez examinada su correspondiente estudio se
registra su información de mantenimiento y se determina el tipo de tratamiento.
§
Estudio de la Propuesta de Solución que de acuerdo a su alcance se establece una prioridad
de atención, concretando los requisitos solicitados y analizando a detalle su implicancia en el
sistema de información. También se debe analizar el impacto que tendrá tal solución.
§
Implementación de la Modificación identificando los elementos afectados y estableciendo un
plan de acción.
§
Plan de Pruebas de Regresión para eliminar el conocido efecto “onda” , evitando de esta
manera la intrusión de comportamiento no deseado, errores o implicancias no deseadas en
los distintos componentes del sistema.
§
Seguimiento de los Cambios de acuerdo a los puntos de control definidos en el plan de
acción.
§
Realización de las Pruebas de Regresión definidas en el correspondiente plan, y asegurar de
esta manera que el sistema implicado en el cambio no esté comprometido con su normal y
correcto funcionamiento.
§
Aprobación y Cierre de la Petición de acuerdo a los resultados obtenidos de las pruebas de
regresión, y se cierra el catálogo de mantenimiento actualizando la petición tratada.
§
Actualización de Documentación del Sistema crear una nueva versión de la documentación
del sistema tratado indicando la persona quien la realizo, el tiempo, el tipo de ajuste, etc. Así
se modificarán por ejemplo: los documentos de requerimientos y especificaciones de
software, de arquitectura de software, de diseño y modelamiento, etc.
Unidad de Tecnologías de Información
97
Metodología MDS-α
CAPITULO 11
11 PLAN DE ASEGURAMIENTO DE LA CALIDAD
Las metodologías, normas, estándares y demás herramientas de construcción de software, tienen un
único fin, producir software de gran calidad.
La calidad de software se refleja en la “relación que debe existir entre los requisitos funcionales y los
de rendimiento, expresamente establecidos con los estándares de desarrollo, convenientemente
documentados y, principalmente con los requerimientos no funcionales incrustados implícita o
explícitamente en el software” (ISO 8402-94, ISO 9000:2000)
Así podemos decir que:
§
Los requerimientos de software son la base de las medidas de calidad.
§
La falta de concordancia con los requisitos se transforma en una falta de calidad.
§
Los estándares, normas y metodologías guían el buen desarrollo de sistemas con calidad.
§
Si no se sigue ninguna metodología siempre habrá falta de calidad.
§
Existen requisitos no funcionales que generalmente están implícitos (por ejemplo el deseo de
un buen mantenimiento y escalabilidad) que también pueden implicar una falta de calidad.
El aseguramiento de calidad de software es el conjunto de actividades planificadas y sistemáticas,
necesarias para satisfacer los requerimientos dados de calidad por parte del cliente y de los
desarrollares.
El aseguramiento de calidad de software se diseña para cada aplicación antes de comenzar a
desarrollarla y no después.
11.1 CALIDAD DEL SOFTWARE
La calidad de software es el conjunto de atributos que lo caracterizan y que determinan su utilidad y
existencia; la calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,
portabilidad, usabilidad, seguridad, integridad, etc. La calidad del software es medible y varía de un
sistema a otro.
Unidad de Tecnologías de Información
98
Metodología MDS-α
La calidad del software puede medirse después de haber elaborado el producto. Pero, esto puede
resultar muy costoso si se detectan problemas derivados de imperfecciones en el análisis, diseño,
codificación, etc., por lo que es necesario tomar en cuenta que la obtención de la calidad como su
control debe realizarse durante todas las etapas del ciclo de vida del software
11.1.1 Obtención de Software con Calidad
La obtención de software con calidad implica la utilización de metodologías, normas, procedimientos
estándares en cada etapa del desarrollo del software (análisis, diseño, programación, prueba,
mantenimiento) permitiendo uniformar una filosofía de trabajo, con la intensión marcada de lograr
una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad,
tanto para la labor de desarrollo como para el control de la calidad del software.
11.1.2 Determinación de Calidad del Software
Existen tres grupos bien definidos que determinan la calidad del software:
Operaciones del Producto
Referidas a las características operativas de software.
§
Corrección (¿Resuelve lo pedido?): Es el grado en que una aplicación satisface sus
especificaciones y consigue los objetivos encomendados por el cliente.
§
Fiabilidad (¿Lo hace de forma fiable todo el tiempo?): Es el grado que se espera se lleve a
cabo las operaciones especificadas de una aplicación informática.
§
Eficiencia (¿Qué recursos hardware y software se necesita?): La cantidad de recursos
hardware y software que necesita una aplicación para realizar las operaciones con los
tiempos de respuesta adecuados.
§
Integridad (¿Se puede controlar su uso?): Es el grado con que puede controlarse el acceso
al software o a los datos (por lo general a personal no autorizado).
§
Facilidad de uso (¿Es fácil y cómodo de manejar?): Se trata del esfuerzo requerido para
aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir los
resultados buscados.
Unidad de Tecnologías de Información
99
Metodología MDS-α
Revisión del Producto
Referida a la capacidad para soportar cambios o modificaciones.
§
Facilidad de mantenimiento (¿Se pueden identificar las fallas y ajustar procesos?): Se
refiere al esfuerzo requerido para localizar y reparar los errores, y ajustar procesos sin
mayores dificultades.
§
Flexibilidad (¿Se puede incluir nuevas opciones?): se refiere al esfuerzo requerido para
modificar una aplicación en funcionamiento o producción.
§
Facilidad de prueba (¿Se pueden probar todas las opciones?): Es el esfuerzo requerido
para probar una aplicación de forma que cumpla con las especificaciones de requisitos.
Transición del Producto:
Hace alusión a la adaptabilidad a nuevos entornos.
§
Portabilidad (¿Podrá usarse en otras máquinas?): Es el esfuerzo requerido para transferir
la aplicación a otro hardware o sistema operativo.
§
Reusabilidad (¿Se Podrá utilizar alguna parte del software en otra aplicación?): se refiere
al grado en que las partes de una aplicación pueden utilizarse en otros sistemas.
§
Interoperabilidad (¿Se podrá comunicar con otros sistemas informáticos?): Indica el
esfuerzo que se necesita para comunicar una determina aplicación con otros sistemas
informáticos.
11.2 PLAN DE LA CALIDAD
11.2.1 Alcance del Plan de Calidad
Se identifican los componentes, aspectos o características del sistema que deberán ser evaluados
para asegurar que los objetivos de calidad se han alcanzado.
·
Componente-1
·
Componente-2
·
Componente-3
·
Característica-1
·
Característica-2
Unidad de Tecnologías de Información
100
Metodología MDS-α
11.2.2 Objetivos de Calidad
Incluir los objetivos para ajustarlos al proyecto. Agrupar por prioridades de acuerdo a los
lineamientos del proyecto.
Esenciales
§ Funcionalidad à Corrección
§ Funcionalidad à Robustez
Esperados
§ Funcionalidad à Exactitud
§ Funcionalidad à Compatibilidad
§ Funcionalidad à Corrección medible
§ Usabilidad à Comprensibilidad y Legibilidad
§ Usabilidad à Apoyo para tareas
§ Usabilidad à Eficiencia
§ Usabilidad à Seguridad
§ Usabilidad à Consistencia y Familiaridad
§ Usabilidad à Satisfacción Subjetiva
Deseados
§ Confiabilidad à Consistencia en carga
§ Confiabilidad à Consistencia bajo concurrencia
§ Confiabilidad à Disponibilidad bajo carga
§ Confiabilidad à Longevidad
§ Eficiencia
§ Escalabilidad
§ Escalabilidad à Desempeño bajo carga
§ Escalabilidad à Grandes volúmenes de datos
§ Operabilidad
§ Capacidad de mantenimiento à Comprensibilidad
§ Capacidad de mantenimiento à Capacidad de evolución
§ Capacidad de mantenimiento à Capacidad de prueba
Unidad de Tecnologías de Información
101
Metodología MDS-α
11.2.3 Procesos del Aseguramiento de Calidad
Para lograr una buena adherencia con los estándares se debe medir cuantitativamente, donde sea
posible, los aspectos de calidad (complejidad, confiabilidad, mantenimiento, seguridad, defectos,
número de problemas) utilizando métricas bien establecidas. Para ello, se deben realizar chequeos,
reconocimientos, controles o verificaciones de:
§
Administración
§
Documentación
§
Estándares, prácticas, convenciones y métricas
§
Revisiones e intervenciones
§
Actividades de testeo
§
Reporte de errores y acciones correctivas
§
Herramientas, técnicas y métodos
§
Control del código
§
Control de medios
§
Colección de registros, mantenimiento y retención
§
Entrenamiento
§
Administración del riesgo
La forma en que se llevarán a cabo estas actividades se define en el Proceso de Aseguramiento de
Calidad, el cual estará presente e irá evolucionado en las sucesivas fases del proceso de desarrollo del
software.
11.2.4 Guías para las actividades del Aseguramiento de Calidad del Software
Nombre del Proceso de
Aseguramiento de Calidad:
Código:
Proyecto/Sistema:
Administrador del
Proyecto/Sistema:
Preparado por:
Nº Control de Versión
Versión del Documento:
Fecha de Preparación:
Revisado por
Fecha
Descripción
Tabla 11-1: Encabezado del Plan de Aseguramiento de la Calidad
Unidad de Tecnologías de Información
102
Metodología MDS-α
Las siguientes tres guías muestran la pauta general del proceso que se debe seguir respecto a las
actividades del Aseguramiento de Calidad.
11.2.4.1 Guía para la Administración
Nº
Propósito
1
Criterios de
Actividad
Detalle / Indicación
§
Entrada
Plan de Administración del Proyecto de
Software.
§
Personal que participara en el Control de
Calidad.
2
Revisión
§
§
Identificar tareas de cada integrante que
Verificar
participara en el Aseguramiento de
participantes del Control de Calidad y el Plan
Calidad del Software.
Administración del Software.
Definir
responsabilidades
a
la
consistencia
entre
los
cada
integrante.
3
Criterios de Salida
Esquema especifico de los participantes del
Estructura del Control de Calidad óptima para
Control de Calidad.
el proyecto.
Tabla 11-2: Tabla guía para la Administración
11.2.4.2 Guía para la Documentación
Nº
Propósito
1
Criterios de
Plan de Administración del Proyecto de
Entrada
Software.
2
3
Revisión
Criterios de Salida
Actividad
Revisión y análisis del plan de
documentación.
§
Buscar discrepancias.
§ Discutir discrepancias con el o los
responsables del proyecto.
Documentación revisada.
§
Detalle / Indicación
§
Reportar discrepancias
§
Enviar discrepancias correspondientes a
los respectivos responsables
Documento de acuerdo a estándares y sin
discrepancias.
Tabla 11-3: Tabla guía para la Documentación
Unidad de Tecnologías de Información
103
Metodología MDS-α
11.2.4.3 Guía para la Adherencia a los Estándares.
Nº
Propósito
1
Criterios de Entrada
Actividad
Detalle / Indicación
Documento
de
Requerimientos
Especificaciones
del
Documento
Arquitectura
de
y
Software,
del
Software, Documento del Diseño del
Sistema, etc.
2
Documentación
Monitorear la adherencia
documentos a los estándares.
de
los
La documentación debe reflejar los
diferentes puntos citados en la presente
metodología (MDS-ALFA)
3
Diseño
Monitorear la adherencia del diseño de
El diseño estará enmarcado en las
acuerdo a los estándares.
diferentes herramientas citadas en la
metodología (MDS-ALFA) de acuerdo a
su tipo (Estructurado, Orientado a
Objetos, etc.)
4
5
6
7
Codificación
Monitorear
la
la
La Codificación estará enmarcada de
codificación a la convención establecida
acuerdo a la Convención de Codificación
en la Metodología ALFA.
definida en la Metodología MDS-ALFA.
Monitorear
los
Los Comentarios y la Documentación
Interna
Comentarios y la Documentación Interna
Interna del Sistema estará enmarcado
de acuerdo la convención establecida en
bajo las convenciones de codificación
la Metodología ALFA.
defina en la Metodología MDS-ALFA.
Monitorear la adherencia de las pruebas
Revisar de acuerdo a los estándares
de acuerdo a los estándares.
citado en la Metodología MDS-ALFA.
Revisar la métrica definida
Revisar la o las métricas de acuerdo a los
Métricas
adherencia
de
Comentarios/Documentación
Prueba
la
adherencia
de
diferentes
atributos
de
calidad
propuestos.
8
9
Conformidad
Criterios de Salida
Monitorear la conformidad que existe en
Revisar documentos de conformidad del
el sistema.
sistema.
§
Proceso
de
Documentación
revisado
§
§
§
§
§
§
Proceso de Diseño revisado
Proceso de Codificación revisado
Proceso de Comentarios y
Documentación Interna revisados
Proceso de Pruebas revisado
Métricas definidas revisadas
Conformidad revisado
§
§
Discrepancias
reportadas
y
solucionadas.
Documentos de acuerdo a los
estándares.
Tabla 11-4: Tabla guía para la adherencia a los Estándares
Unidad de Tecnologías de Información
104
Metodología MDS-α
ANEXOS
Unidad de Tecnologías de Información
105
Metodología MDS-α
ANEXO 1
ARBOL CAUSA Y EFECTO
También conocido como árbol de problemas; es una herramienta de planificación que sirve de mucho
en el planteamiento de proyectos, esta técnica se utiliza para identificar una situación negativa
dentro de un determinado entorno aplicando para ello la relación causa y efecto.
La identificación correcta del problema tiene de inicio un elevado porcentaje de solución del mismo, y
en consecuencia un correcto encaminamiento a los diferentes objetivos.
DETERMINACION DEL PROBLEMA
Se deben seguir los siguientes pasos:
§
Según una determinada situación, identificar los posibles problemas
§
Mediante esta lluvia de ideas8, el grupo debe identificar el problema central
El problema central que se pretende solucionar con la aplicación del proyecto, debe expresar
necesidades insatisfechas y/o oportunidades no aprovechadas. El problema no debe expresar la falta
de una solución, ya que no se contaría con alternativas para su análisis. Por ejemplo:
Problema Incorrecto: "Falta de sistema informático en la Unidad de Recursos Humanos”
(Pues, el sistema informático puede ser una alternativa de solución.)
Problema Correcto: "Limitado tratamiento de la información de los funcionarios de la
institución"
Problema Central
Limitado tratamiento de la información
de los funcionarios de la institución.
8
Lluvia de ideas - Brainstorming, conocido también como tormenta de ideas, es una herramienta de trabajo
grupal que facilita el surgimiento de nuevas ideas sobre un tema o problema determinado.
Unidad de Tecnologías de Información
106
Metodología MDS-α
Así también es importante usar verbos adecuados en la definición de problema y tener mucho
cuidado en términos como carencia, falta, etc.
CAUSAS DEL PROBLEMA
Definido el problema central, seguidamente deben identificarse las causas directas e indirectas que
generan el mismo, suprimiendo aquellas que están fuera del alcance del proyecto, por ejemplo
aquellos sucesos externos que pueden estar presentes. Cada causa directa debe estar relacionada
con sus correspondientes causas indirectas.
EFECTOS DEL PROBLEMA
Los efectos son sucesos que se derivan del problema y permanecerán en caso de no ejecutarse el
proyecto. Similarmente, deben identificarse los efectos directos e indirectos según su relación con el
problema citado hasta ubicar el efecto final.
CONSTRUCCION DEL ARBOL
Identificado las causas y los efectos se organiza el árbol de la forma siguiente:
§
El problema principal ocupa el nodo central del árbol (es el tronco)
§
Por debajo del nodo central se identifican las causas directas que originan dicho problema, los
encadenamientos posteriores hacen una relación de las causas directas con sus
correspondientes causas indirectas (son las raíces)
§
Por encima del problema central, ubicamos a los efectos que derivan del problema,
relacionados hacia un orden superior hasta ubicar el efecto final (son las hojas).
Siguiendo el caso ejemplo, vemos en el gráfico Graf. A-1-1 la estructura del árbol para el problema
mencionado, en donde puede notarse que el gran efecto es la Desconfianza en la Administración del
Recurso Humano de la Institución.
Unidad de Tecnologías de Información
107
Metodología MDS-α
EFECTOS
Desconfianza en la
administración del
Recurso Humano de la
institución
Falta de fiabilidad de los
datos procesados
Información inadecuada
Demora en el
procesamiento de datos
Limitado tratamiento de
la información de los
funcionarios de la
institución
PROBLEMA CENTRAL
CAUSAS
Capacidad limitada de los
equipos de computación
Computadoras obsoletas
Mantenimiento limitado
Limitado control del
procesamiento de
información
Limitada aplicación de las
normas
Limitada aplicación de los
diferentes procesos y
procedimientos
Graf. A-1-1: Árbol Causa Efecto (Árbol de Problemas)
EL ARBOL DE OBJETIVOS
El árbol de objetivos conocido también como árbol de medios y fines se construye de una manera
opuesta y positiva al árbol de problemas. A partir del árbol de causa y efecto puede obtenerse los
objetivos del proyecto.
Problema Central
Limitado tratamiento de la
información de los
funcionarios de la institución
Objetivo General
Mejorar el tratamiento de la
información de los
funcionarios de la institución
Los objetivos específicos se construyen de similar forma, son lo opuesto de las causas directas. En la
grafica Graf. A-1-2 se puede observar el árbol de medios y fines relacionado con el problema de
ejemplo.
Unidad de Tecnologías de Información
108
Metodología MDS-α
Confianza en la
administración del
Recurso Humano de la
institución
FINES
Datos procesados de
forma correcta
Información adecuada
Procesamiento de datos
oportuna
Mejorar el tratamiento de
la información de los
funcionarios de la
institución
OBJETIVO GENERAL
Mejorar los equipos de
computación
MEDIOS
Mayor control del
procesamiento de
información
Computadoras adecuadas
Amplia cobertura de
mantenimiento
Aplicación correcta de las
normas
Mejor aplicación de los
diferentes procesos y
procedimientos
Graf. A-1-2: Árbol de Objetivos
Lo opuesto a las causas indirectas son los medios fundamentales, a partir de ellos se encontrarán las
acciones respondiendo a la pregunta ¿Cómo?; para el caso de Computadoras adecuadas, la pregunta
sería cómo las obtendremos; una opción comprar computadoras, otra es actualizar las partes, otra
alquilarlas, etc. Y así sucesivamente para cada medio se halla sus acciones correspondientes, para
luego agruparlas y formar las alternativas del proyecto
Computadoras adecuadas
Amplia cobertura de
mantenimiento
Aplicación correcta de las
normas
Mejor aplicación de los
diferentes procesos y
procedimientos
Unidad de Tecnologías de Información
109
Metodología MDS-α
Alternativa de Proyecto 1
§
Comprar computadoras
§
Realizar programas de mantenimiento
§
Estandarización de actividades
§
Automatizar procesos y procedimientos con personal interno
Alternativa de proyecto 2
§
Actualizar partes de computadoras
§
Realizar programas de mantenimiento
§
Estandarización de actividades
§
Automatizar procesos y procedimientos con personal externo
y así pueden plantearse otras alternativas al proyecto citado.
Mediante el árbol de medios y fines se tiene identificado las siguientes partes del proyecto:
OBJETIVO GENERAL DEL PROYECTO
Mejorar el tratamiento de la información de los funcionarios de la institución.
OBJETIVOS ESPECÍFICOS DEL PROYECTO
§
Mejorar los equipos de computación
§
Poseer un mayor control del procesamiento de información.
PRODUCTOS DEL PROYECTO
Al ejecutarse el proyecto con el respaldo de la correspondiente inversión, entregará:
§
Computadoras adecuadas
§
Amplia cobertura de mantenimiento
§
Aplicación correcta de las normas
§
Mejor aplicación de los diferentes procesos y procedimientos
Unidad de Tecnologías de Información
110
Metodología MDS-α
ANEXO 2
PROCESOS Y PROCEDIMIENTOS
Proceso es un conjunto de pasos o actividades enlazadas entré sí que, partiendo de uno o más inputs
(entradas o insumos) los transforma, generando outputs (salidas, productos, resultados).
Normalmente un proceso puede estar conformado por dos o más operaciones. Sin embargo,
dependiendo de las funciones que cumplen las áreas o unidades organizacionales y de los objetivos o
resultados que persiguen, pueden existir procesos que se desagreguen directamente en
procedimientos.
Las operaciones son un conjunto de procedimientos interrelacionados, que transforman insumos en
bienes o servicios requeridos por los usuarios internos o externos.
Los procedimientos son un conjunto de tareas secuenciales o paralelas, que son realizadas para lograr
una operación, proceso o parte de ellos
MAPEO DE PROCESOS, OPERACIONES Y PROCEDIMIENTOS
MAPEO DE PROCESOS, OPERACIONES Y PROCEDIMIENTOS
CÓDIGO
PROCESO
PROCESOS
CÓDIGO
OPERACIÓN
OPERACIONES
CÓDIGO
PROCED.
PROCEDIMIENTOS
Form. 04: Formulario de mapeo de procesos, operaciones y procedimientos
Unidad de Tecnologías de Información
111
Metodología MDS-α
LLENADO DEL FORMULARIO N° 4
El Formulario N° 4 correspondiente al Mapeo de Procesos, Operaciones y Procedimientos, sirve para
definir de manera clara y concreta cuales serán los procesos, operaciones y procedimientos que
deberán llevarse adelante para la obtención de diferentes productos.
Código Proceso: Se debe asignar el código correspondiente al proceso, el cual consta de dos campos,
tal como se observa en la figura de Ej.:
Graf. A-2-1: Código de Proceso
Procesos: Colocar el nombre de cada uno de los procesos correspondientes. Para definir los procesos
se debe realizar unos análisis de las competencias, objetivos y productos que se pretenden lograr.
Código Operación: Se debe asignar el código correspondiente a cada operación, la cual consta de tres
campos, dos del código del proceso que debe ser encadenado y uno correspondiente a la numeración
de la operación, tal como se observa en la figura de Ej.:
Graf. A-2-2: Código de Operación
Operaciones: Colocar el nombre de cada uno de las operaciones (subprocesos) necesarias para lograr
el proceso correspondiente.
Código Procedimiento: Se debe asignar el código correspondiente a cada procedimiento, el cual
consta de cuatro campos, tres del código de la operación que debe ser encadenado y uno
correspondiente a la numeración del procedimiento, tal como se observa en la figura de Ej.:
Unidad de Tecnologías de Información
112
Metodología MDS-α
Graf. A-2-3: Código de Procedimiento
Procedimientos: Colocar el nombre de cada uno de los procedimientos correspondientes a las
operaciones o procesos.
INTEGRACIÓN DE PROCESOS Y OPERACIONES
INTEGRACIÓN DE PROCESOS Y OPERACIONES
NOMBRE DEL PROCESO:
OBJETIVO:
UNIDAD RESPONSABLE DEL PROCESO:
PRODUCTOS DEL PROCESO:
OPERACIONES COMPONENTES DEL PROCESO
CÓDIGO
OPERACIÓN
RESPONSABLES
PRODUCTO
CÓDIGO:
TIEMPO DÍAS
TOTAL TIEMPO DE EJECUCIÓN DEL PROCESO
Form. 05: Formulario de integración de procesos y operaciones
LLENADO DEL FORMULARIO N° 5
El Formulario N° 5 correspondiente a la integración de procesos y operaciones, debe ser llenado una
vez que se cuente con el Mapeo de Procesos.
Nombre del Proceso: En este apartado se registrará el nombre del Proceso, de acuerdo con el Mapeo
de Procesos previamente realizado. Se define mediante un verbo de acción en infinitivo que denota la
cualidad de imperativo (terminaciones ar, er, ir). Por ejemplo:
Nómina no es un proceso
Elaborar la nómina sí es un proceso
Código del Proceso: Colocar el código asignado al proceso en el Mapeo de Procesos.
Unidad de Tecnologías de Información
113
Metodología MDS-α
Objetivo del Proceso: Se debe indicar que se persigue con el proceso a fin de que el personal de la
entidad sepa para que se desarrolla y pueda involucrase y contribuir a la mejora continua del mismo.
El objetivo definido debe ser alcanzable, es decir realista, redactarse en forma breve y concisa e
iniciar con un verbo en infinitivo (terminaciones ar, er, ir) y en lo posible, evitar utilizar gerundios,
adjetivos calificativos.
Unidad Responsable del Proceso: Se debe mencionar el área o unidad organizacional responsable de
la ejecución, control, evaluación y mejoramiento del proceso.
Productos que genera el Proceso: Se debe incluir todos los bienes o servicios que genera el proceso
como consecuencia del valor agregado a los insumos.
Código y Nombre de las operaciones que componen el proceso: Se deben registrar los códigos y
nombres de todas las operaciones que componen el proceso, de acuerdo al mapeo realizado.
Unidades Responsables de las operaciones: Se debe mencionar el área o unidad organizacional
responsable de la ejecución de las operaciones.
Productos que genera la Operación: Se debe incluir todos los bienes o servicios intermedios que
genera la Operación.
Tiempo: Mencionar el tiempo aproximado requerido para cumplir las operaciones en días, cuya
sumatoria brindará el tiempo total del proceso.
PROCEDIMIENTOS
PROCEDIMIENTOS
NOMBRE DEL PROCEDIMIENTO:
OPERACIÓN A LA QUE CORRESPONDE EL PROCEDIMIENTO:
OBJETIVO DEL PROCEDIMIENTO:
INSUMOS REQUERIDOS PARA EL PROCEDIMIENTO:
PRODUCTOS OBTENIDOS DEL PROCEDIMIENTO:
TIEMPO DE EJECUCIÓN DEL PROCEDIMIENTO:
N°
DESCRIPCIÓN DE TAREAS
CÓDIGO:
PUESTO
RESPONSABLE
FORMAS
FORMULARIOS
Form. 06: Formulario de procedimientos
Unidad de Tecnologías de Información
114
Metodología MDS-α
LLENADO DEL FORMULARIO N° 6
Nombre del Procedimiento: En este apartado se registrará el nombre del Procedimiento, de acuerdo
con el Mapeo de Procesos previamente realizado.
Código: En este punto, debe colocarse el código correspondiente al procedimiento que se describe,
de acuerdo a lo establecido en el mapeo de procesos.
Operación a la que corresponde el procedimiento: Se debe incluir el nombre de la operación a la que
pertenece o contribuye de manera directa el procedimiento respectivo.
Objetivo del Procedimiento: Se debe indicar que se persigue con el procedimiento a fin de que el
personal involucrado sepa para que se desarrolla y pueda involucrarse y contribuir a la mejora
continua del mismo, considerando las características señaladas en el instructivo del formulario N° 5.
Insumos requeridos para el Procedimiento: Se deben señalar cuáles son los productos intermedios o
finales, requeridos para realizar el procedimiento. (Ej. Normas, POA ejecutado, etc. No se refiere a
materiales de escritorio o similares).
Productos obtenidos por el procedimiento: Se deben detallar cuáles son los productos (bienes o
servicios) que se pretender lograr con el procedimiento.
Tiempo de ejecución del Procedimiento: Se debe establecer el tiempo total de ejecución aproximado
del procedimiento en horas o días.
Descripción de las tareas que componen el Procedimiento: Es la narración objetiva de cada una de la
tareas que integran el procedimiento, en secuencia cronológica y organizada expresada de manera
clara, que permite al personal comprenderlas, seguirlas y aplicarlas.
Para la redacción de las actividades considere los siguientes lineamientos:
§
Utilizar verbos conjugados en el tiempo presente de tercera persona en singular, por ejemplo,
prepara, envía, analiza, desarrolla, por citar algunos.
§
Redactar cada oración o frase en orden lógico, esto es, primero el verbo y luego el
complemento.
Unidad de Tecnologías de Información
115
Metodología MDS-α
§
De preferencia utilizar oraciones o frases cortas, usando palabras sencillas y evitando
tecnicismos.
§
Evitar en lo posible incluir actividades que no agregan valor como recibir, enviar, registrar, por
citar algunas.
§
En la medida de lo posible no utilizar abreviaturas.
§
Una buena descripción de actividades responderá las siguientes preguntas: ¿Quién?, ¿Cómo?,
¿Cuándo?, ¿Con qué?, ¿Dónde?
Puestos responsables de las tareas: Se debe mencionar los puestos responsables de la ejecución de
cada una de las tareas que componen el Procedimiento.
Registros, formularios u otros impresos a utilizarse: Se deben mencionar todos los formularios o
formas impresas que se utilizarán en las tareas que se describen.
DIAGRAMA DE FLUJOS
El diagrama se elabora en base a la secuencia de las actividades; la toma de decisiones deberá ser
acorde con la descripción de tareas. En la primera columna de la izquierda se da inició al
procedimiento. El trazo inicia de arriba hacia abajo y de izquierda hacia la derecha; posteriormente el
flujo puede retroceder dependiendo del procedimiento.
Para la elaboración de los diagramas de flujo se deben seguir los siguientes lineamientos:
§
En un inicio comenzar con el trazo de columnas con líneas delgadas, en los encabezados de
éstas anote las unidades o puestos en orden de participación de izquierda a derecha, donde
el primer participante inicia la acción.
§
Estandarice las dimensiones de sus hojas dejando espacio suficiente en cada columna,
dependiendo del número de unidades o puestos que intervienen.
§
Trace las líneas del flujo del procedimiento, utilizando las puntas de las flechas para indicar la
dirección del flujo en cada sección del rayado.
§
Si el flujo retrocede muestre como lo hace, utilizando las flechas o conectores de actividad, no
repita el nombre del puesto o unidad participante en otra columna.
§
Dibuje los símbolos de un mismo tamaño.
§
Numere cada actividad del flujo, utilice números grandes y claros.
Unidad de Tecnologías de Información
116
Metodología MDS-α
§
Describa en lenguaje telegráfico cada tarea (el detalle de la actividad quedará establecida en
la descripción de tareas del procedimiento, por lo que no debe hacer una transcripción en los
símbolos del diagrama).
§
Incluya gráficamente en cada actividad los formatos que elabora, recibe y/o proporciona a
otras unidades o puestos, o los que archiva, señalando el número de tantos y cuál es su
distribución.
§
No mezcle al mismo lado del símbolo varias líneas de entrada y salida, emplee solo una línea
de unión entre dos símbolos. Solo el símbolo de decisión puede tener hasta tres líneas de
salida.
Simbología para elaborar un diagrama de flujo:
Símbolo
Descripción
Dentro del símbolo se deberá anotar “INICIO” o “FIN”, de acuerdo al principio o
conclusión del procedimiento, según corresponda.
Describe de manera telegráfica, las tareas que desempeña el personal involucradas en
el procedimiento, en flujos de procesos representa la ejecución de operaciones.
Representa cualquier documento que entre, se genere o utilice en el proceso o
procedimiento.
Representa una tarea que genera un documento.
Indica un punto dentro del flujo en donde se debe tomar una decisión entre dos
opciones o alternativas.
Preferentemente se indicará la procedencia (SI) hacia la parte de abajo del símbolo y la
procedencia (NO) hacia un lado. No contarán con número consecutivo de las etapas.
Representa el archivo de algún tipo de documentación en un punto del flujo.
1
Va a página ó
Viene de
página
Representa la conexión o enlace de una parte del diagrama de flujo con otro parte del
mismo, en la misma hoja. Se utiliza para unir actividades cuando el espacio en el
diagrama es limitado y sirve para evitar cruzar las líneas de dirección de flujo.
Representa la conexión o enlace de una parte del diagrama de flujo con otro parte del
mismo, en otra hoja.
Indican la dirección del flujo de tareas y sirven para unir los símbolos de descripción,
decisión, documentos, etcétera., Se utilizarán sólo líneas horizontales y verticales. En
los casos que no sea posible conectar con líneas rectas, se utilizarán ángulos rectos. Las
líneas no deberán cruzarse, si esto no es posible, se debe utilizar un pequeño “puente”:
Tabla A-2-1: Tabla de símbolos de diagramas de flujo de procedimientos
Unidad de Tecnologías de Información
117
Metodología MDS-α
Ejemplo de diagrama de flujo – Procedimiento
Graf. A-2-4: Simbología de diagramas de flujo
Unidad de Tecnologías de Información
118
Metodología MDS-α
ANEXO 3
BENEFICIOS Y COSTOS
En proyectos de informática se puede estimar los costos de sin muchas dificultades, pero no así los
beneficios. Generalmente en estos proyectos tanto los costos como los beneficios son de tipo
intangibles; y por consiguiente su descripción es de forma cualitativa.
BENEFICIOS
Tomar en cuenta que un beneficio cualesquiera debe ser contabilizado una sola vez dependiendo su
tipología. Y según el proyecto, pueden identificarse algunos de los beneficios siguientes:
Ahorro de Horas Hombre
En una situación en que no se ejecute el proyecto, se puede pensar en la contratación de personal
adicional que posibilite alcanzar los mismos objetivos que la alternativa del proyecto informático, a
esto se le conoce como situación base optimizada. En consecuencia el beneficio citado se tiene por no
tener que contratar personal adicional con respecto a la situación optimizada.
Por ejemplo, si la institución debiera contratar en una situación optimizada dos personas más durante
el lapso de una gestión versus ejecución del proyecto durante 8 meses, se tendría aproximadamente
un ahorro en costos de horas hombre de 4 meses por cada persona.
Este beneficio se da bajo el supuesto de que las horas hombre liberadas tengan un uso alternativo
productivo.
Aumento de productividad
El aumento de la productividad puede provenir de tres tipos:
Ahorro del tiempo de desplazamiento: Con la aplicación del nuevo sistema, se pretende disminuir o
eliminar el tiempo que las personas consumen en desplazarse para intercambiar información o para
ejecutar alguna acción, mismos que pueden ser operados desde su escritorio. Por ejemplo:
Unidad de Tecnologías de Información
119
Metodología MDS-α
§
Entregar información en algún medio magnético
§
Compartir información digital por red
§
Información procesada según formatos predefinidos
Mejora del actual sistema: Mejoramiento de las características básicas del sistema actual. Por
ejemplo:
§
Extender la robustez del sistema
§
Procesar más rápidamente la información, así también su acceso
§
Disminución de tiempos de espera en la impresión de los reportes
Automatización: La implementación e implantación de un sistema informático pretende automatizar
aquellos procesos manuales relevantes para una determinada unidad organizacional. Algunos
procesos típicos pueden ser:
§ Accesibilidad y ordenamiento de archivos
§
Generación automática de boletas de pago
§
Procesamiento de penalizaciones en el control de personal
§
Búsqueda e identificación de información
Ahorro en alquileres de oficinas
Suponiendo el caso de que la institución posea oficinas en alquiler y este ya no sea necesario tras la
ejecución del proyecto, se tendría un ahorro por el pago del mencionado alquiler. Esto puede ocurrir
por ejemplo cuando se digitaliza información a medios magnéticos que antes estaban contenidos en
gabinetes, archivos y carpetas físicas.
Para el caso en que la oficina sea de propiedad de la institución, el ahorro proviene del uso
alternativo que se le puede dar a dicha oficina.
Ahorro en costos de operación
Respecto a una situación base, pueden mencionarse por ejemplo: una disminución o eliminación de
los costos de mantención; ahorro de pagos por servicios a empresas externas, pues con la realización
del proyecto estos servicios podrán desarrollarse internamente, etc. Se debe mencionar el detalle de
Unidad de Tecnologías de Información
120
Metodología MDS-α
cada uno de los costos de operación describiendo el ahorro respectivo en cada circunstancia o
situación.
Mejoras en la gestión y en la toma de decisiones
Señalar los diferentes beneficios que están inmersos en la gestión y en la toma de decisiones como
ser: la versatilidad, fiabilidad y productividad de los operarios del sistema, información clara,
detallada y oportuna, reducción de tareas administrativas, planificación y facilitación en la toma de
decisiones, u otros. Generalmente estos beneficios son difíciles cuantificar, por lo que en ocasiones
son considerados como intangibles.
COSTOS
En general pueden presentarse los siguientes puntos:
§
Compra de hardware
§
Compra de software
§
Adaptación del software existente
§
Desarrollo de software
§
Capacitación
§
Instalación e implantación del servicio
§
Salarios ( si se requiera personal adicional)
§
Servicios externos
§
Comunicaciones (alquiler de líneas de comunicación)
§
Materiales de uso y consumo corriente (diskettes, hojas de impresión, tonners de impresoras,
scanner, CD’s, etc.)
§
Mantenimiento y reparaciones
§
Consumo de energía
§
u otros.
Unidad de Tecnologías de Información
121
Metodología MDS-α
ANEXO 4
MATRIZ DE MARCO LOGICO
La matriz de marco lógico es una herramienta analítica para la planificación y gestión de proyectos
orientada por objetivos. Permite estructurar los principales elementos de un proyecto, relacionando
los recursos disponibles, las actividades planeadas y los resultados esperados.
La matriz lógica refleja el ciclo de vida de un proyecto, es el sistema más utilizado para la
conceptualización, diseño, ejecución, seguimiento, evaluación y comunicación de la información más
relevante del proyecto en forma resumida. Ver el siguiente gráfico.
FORMULACION
Problema
Desarrollo de
Alternativas
Identificación
Evaluación
Alternativa
Seleccionada
EJECUCION
OPERACION
FIN
PROPOSITO
El Proyecto
COMPONENTES
S
ACTIVIDADES
Graf. A-4-1: Ciclo de vida del proyecto
Unidad de Tecnologías de Información
122
Metodología MDS-α
La estructura del marco lógico está definida como sigue:
OBJETIVOS
INDICADORES
FORMULA DE
ENUNCIADO - META
CALCULO
MEDIOS
VERIFICABLES
SUPUESTOS
FIN
PROPOSITO
COMPONENTES
ACTIVIDADES
Form. A-4-1: Formulario matriz de marco lógico
FIN
El fin es el impacto al cual contribuirá el proyecto una vez haya finalizado la fase de operación. Por
convención, el objetivo expresado en el Fin, debe redactarse como resultado logrado o producido;
debe reflejar logros, éxitos y metas cumplidas. Por ejemplo:
Fin correcto: Información del Recurso Humano de la institución, administrada
eficientemente
Fin incorrecto: Administrar eficientemente la información del Recurso Humano de
la institución.
Si el proyecto forma parte de un programa, en general la descripción del fin de los proyectos
comienza con ‘’Contribuir a…….’’
PROPOSITO
El propósito es el punto principal de referencia que debe definirse con precisión, de manera clara y
realista. Asegura el resultado de la solución del problema, es por tanto, el objetivo central del
proyecto. El propósito es una hipótesis sobre el beneficio que se desea lograr.
Todo proyecto debe tener un solo propósito, y el mismo debe expresarse como un resultado logrado.
Generalmente el propósito da el nombre al proyecto
COMPONENTES
Son los resultados específicos que se producen durante la ejecución del proyecto, sean estos
tangibles o intangibles. Son necesarios para alcanzar el propósito y son los productos que financia el
Unidad de Tecnologías de Información
123
Metodología MDS-α
proyecto. Por lo tanto, es razonable plantear que si todos los componentes son producidos de la
manera planeada, entonces se logrará el propósito buscado. Análogamente al fin y al propósito,
deben redactarse de forma clara y como resultados o productos finales (objetivo logrado).
Algunos ejemplos de componentes pueden ser: servicios, capacitación, obras, estudios,
equipamiento, sistemas informáticos instalados, etc.
ACTIVIDADES
Las actividades son las principales tareas que deben cumplirse para el logro de cada uno de los
componentes del proyecto. Corresponde a un listado de actividades en orden cronológico para cada
componente.
No es necesario que las actividades se detallen o desagreguen demasiado. Es suficiente que sean
identificados en el nivel de “macro actividades”, indicando a qué componente pertenecen.
INDICADORES
Dato o información que sirve para conocer, valorar e intensificar las características de un hecho o
para determinar su evolución futura. Los indicadores son una herramienta que entrega información
cuantitativa o cualitativa respecto del nivel de logro alcanzado por un programa o un proyecto. Es una
expresión que establece una relación entre dos o más variables, la que comparada con períodos
permite evaluar el desempeño.
Las dimensiones que son factibles y relevantes de medir a través de un indicador son su eficacia,
eficiencia, calidad y economía.
Enunciado - Meta: Es la expresión conceptual (escrita) de lo que se desea medir a través de un
indicador.
Fórmula de Cálculo: Es la expresión matemática que permite cuantificar el nivel o magnitud que
alcanza el indicador en un cierto período de tiempo, considerando variables que se relacionan
adecuadamente para este efecto.
Siguiendo con el ejemplo de la presente metodología se señala el indicador para el PROPOSITO, que
señala la oportunidad de la información en el tiempo:
Unidad de Tecnologías de Información
124
Metodología MDS-α
Indicador: Porcentaje de Información actualizada
Enunciado – Meta: El Porcentaje de Información actualizada supera el 90% en el tiempo
Fórmula de Cálculo: ia =
A 1
* *100
B D
donde:
A = Cantidad de funcionarios con información completa al día.
B = Total de funcionarios de la institución.
D = Cantidad de días de demora.
PRESUPUESTO
A nivel de las actividades y en la sección que corresponde a los indicadores se plantea el presupuesto
global del proyecto por actividades que se desarrollen en el mismo.
MEDIOS DE VERIFICACIÓN
Son la base para el seguimiento y la evaluación del proyecto e indican las fuentes de información y su
frecuencia para la actualización de los indicadores para de esa forma confrontarlos respecto de su
línea base. Incluyen material publicado, inspección visual, encuestas, registros de información,
reportes estadísticos, informes, etc.
SUPUESTOS
Son los factores externos cuya ocurrencia es necesaria para asegurar el cumplimiento de objetivos del
proyecto. Esos supuestos pueden ser de tipo financiero, social, político, ambiental, institucional,
climatológico, etc.
LOGICA DE LA MATRIZ DE MARCO LOGICO
Lógica Vertical: Muestra las relaciones causa efecto entre los distintos niveles de los objetivos.
Unidad de Tecnologías de Información
125
Metodología MDS-α
Para cumplir el Fin, es necesario que se cumpla el Propósito; para cumplir el Propósito, es necesario
que se produzcan los Componentes (resultados o productos). Para cumplir con los Componentes, es
necesario realizar las Actividades (para realizar las Actividades es necesario contar con los Insumos).
FIN
PROPOSITO
COMPONENTES
ACTIVIDADES
Graf. A-4-2: Lógica Vertical
Lógica Horizontal: Es condición necesaria y suficiente contar con las actividades más los supuestos de
ese nivel para obtener los componentes, similarmente los componentes más los supuestos de su nivel
es necesario y suficiente para obtener el propósito y por último, el propósito más los supuestos de su
correspondiente nivel son necesarios y suficientes para obtener el fin.
FIN
SUPUESTOS
entonces
si
más
PROPOSITO
SUPUESTOS
entonces
si
COMPONENTES
más
SUPUESTOS
entonces
si
ACTIVIDADES
más
SUPUESTOS
Graf. A-4-3: Lógica Horizontal
DETERMINACION DE LOS OBJETIVOS DE LA MATRIZ DE MARCO LOGICO
Partiendo del árbol de objetivos (Anexo 1), el fin o fines terminales debe corresponder con su similar
en la matriz de marco lógico. El objetivo central corresponde con el propósito del proyecto. Los
medios de primer orden son los componentes y los medios de segundo orden son las actividades que
Unidad de Tecnologías de Información
126
Metodología MDS-α
se llevarán adelante. Cada uno de los enunciados que representan a los objetivos, deben adecuarse
según lo manifestado en los correspondientes acápites de las secciones de la Matriz de Marco Lógico.
Fin
Propósito
Objetivo Central
Componentes
Actividades
Graf. A-4-4: Relación entre el árbol de objetivos y la matriz de marco lógico
Siguiendo con el ejemplo del Anexo 1, se tiene la siguiente matriz:
Proyecto: Mejoramiento al tratamiento de información de los funcionarios en el Ministerio Hacienda
OBJETIVOS
FIN
Información del Recurso
Humano de la
institución, administrada
eficientemente
INDICADORES
FORMULA DE
ENUNCIADO - META
CALCULO
El porcentaje de registro
de información es mayor
al 95%
ri =
A
*100
B
A = Cantidad de
funcionarios registrados
MEDIOS
VERIFICABLES
Registros actualizados en
el área de Escalafón.
La unidad de RRHH crea
una cultura
administrativa positiva a
cerca del procesamiento
de información personal
de la institución.
Informes de control de
personal.
Los funcionarios de la
institución dotan
oportunamente los
correspondientes datos
de su persona.
B = Total de funcionarios
de la institución
PROPOSITO
Tratamiento mejorado
de la información de los
funcionarios de la
institución
El porcentaje de
Información actualizada
supera el 90% en el
tiempo
ia =
A
*
1
*100
B D
A = Cantidad de
funcionarios con
información completa al
día
B = Total de funcionarios
de la institución
SUPUESTOS
Registros de
memorándums.
Dotación de credenciales
Generación de planillas
presupuestarias
D = Cantidad de días de
demora
Unidad de Tecnologías de Información
127
Metodología MDS-α
COMPONENTES
1: Equipos de
computación mejorados
El número de equipos
adquiridos superan el
50% en la Unidad de
RR.HH.
ea =
A
*100
B
A = Cantidad de equipos
nuevos
Facturas de compra.
Reporte de asignación
de activos
Personal con
conocimientos en
computación y
capacitado en la Norma
SAP
B = Total de equipos en
RR.HH.
2: Control del
procesamiento de
información
perfeccionado
El porcentaje de
aplicación de la norma
SAP es superior al 80%
an =
A
*100
B
A = Cantidad de
Procesos ejecutados
Manual de procesos y
procedimientos.
Base de Datos
consolidada para RR.HH.
B = Cantidad total de
procesos definidos en la
Norma SAP
ACTIVIDADES
1: Adquisición de
Computadoras
PRESUPUESTO
Bs. 160.000
ejecucion =
A
2: Cobertura de
Mantenimiento
Bs. 35.000
*100
B
A = Costo ejecutado en
un determinado tiempo
3: Estandarización de las
actividades según norma
Bs. 75.000
B = Costo Total del
proyecto
4: Automatización de
procesos y
procedimientos
Bs. 260.000
Informe financiero.
Informes mensuales de
capacitación,
mantenimiento, etc.
Documentación de
desarrollo de sistemas.
Equipamiento
computacional
disponible en el
mercado.
Norma SAP actualizado.
Disposición de tiempo
según cronograma de
personal en la Unidad de
Tecnologías de
Información
Costo Total Bs. 530.000
Matriz A-4-1: Matriz de Marco Lógico
Unidad de Tecnologías de Información
128
Metodología MDS-α
ANEXO 5
HERRAMIENTAS DE LA INGENIERÍA DE REQUERIMIENTOS
El analista de requerimientos puede utilizar una variedad de herramientas. Algunas de esas
herramientas y las más utilizadas se citan en el cuadro siguiente:
Herramientas
Extracción
Actividades
Análisis
Documentación
Entrevistas y Cuestionario
X
Sistemas existentes
X
X
Grabaciones de Video y Audio
X
X
Brainstorming (tormenta de ideas)
X
X
Arqueología de Documentos
X
X
Aprendiz
X
Observación
X
Run Use Case WorkShop
X
Prototipo Bosquejado
X
Prototipo Tangible/Usable
X
X
Validación
X
X
FODA
X
Modelo Conceptual
X
X
X
Diagrama de Pescado
X
X
X
Glosario
X
X
X
X
Lista de Requerimientos
X
X
X
X
Checklist
X
Tabla A-5-1: Herramientas de la Ingeniería de Requerimientos
X
Entrevistas y Cuestionarios
En las entrevistas se debe previamente coordinar tanto la fecha y hora, y debe realizarse una
planificación acorde y colocarla en agenda; para ello debe confeccionarse un punteo del objetivo de
la entrevista. Por ejemplo, en la primera entrevista debe establecerse un plan de comunicación, en el
cual se pueden intercambiar datos tales como teléfonos, direcciones de correo electrónico, horas de
contacto, etc.
Para las entrevistas posteriores conviene llevar un cuestionario ya preparado. En términos generales,
un cuestionario consiste en un conjunto de preguntas pre-diseñadas y presentadas a una persona
Unidad de Tecnologías de Información
129
Metodología MDS-α
para su respuesta. La forma de las preguntas puede influir en las respuestas recibidas, por lo que se
sugiere preparar las mismas con anticipación y con el debido cuidado.
Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas.
Las preguntas abiertas permiten a los encuestados responder en su propia terminología.
Generalmente estas son más reveladoras, ya que los interrogados no están limitados en sus
respuestas. Son especialmente útiles en la etapa exploratoria de la investigación del proyecto, cuando
el analista busca penetrar en el pensamiento del encuestado.
Algunas preguntas abiertas pueden ser:
§
¿Por qué razón se quiere resolver este problema?
§
¿Cómo es la resolución del problema actualmente?
§
¿Cuál es el valor de una solución exitosa?
§
¿Quién utilizará el sistema que se va a desarrollar?
§
¿Cómo debería llevarse adelante el desarrollo del sistema?
Por su parte, las preguntas cerradas predeterminan las posibles respuestas y la persona interrogada
elige entre las opciones dispuestas.
Luego, estas preguntas pueden utilizarse por ejemplo para establecer criterios de priorización de los
casos de uso con el usuario, también se la puede utilizar cuando tenemos que negociar algún
requerimiento.
Sistemas Existentes
Esta técnica consiste en analizar distintos sistemas ya existentes que estén relacionados con el
sistema a desarrollar. Tal análisis se puede efectuar de las interfaces de usuario, observando el tipo
de información que se introduce y cómo la misma es tratada. Esto es útil para descubrir información
importante a tener en cuenta, información que tal vez el usuario no haya tomado en cuenta. Por su
parte es útil analizar las salidas que dichos sistemas producen (listados, consultas, etc.), porque
pueden surgir nuevas ideas sobre la base de estas. Luego de este análisis se puede realizar una
tormenta de ideas y así obtener requerimientos sumamente interesantes.
Unidad de Tecnologías de Información
130
Metodología MDS-α
Es recomendable realizar a priori y sin necesidad de que intervenga el usuario analizar o investigar
por ejemplo en Internet algunos productos similares, este mecanismo puede ocasionar que se
establezcan contactos con profesionales que desarrollan sistemas de características comparables.
Otra ventaja que presenta esta técnica es que cuenta con la experiencia de los sistemas que ya están
en producción, y que pasaron por una curva de aprendizaje del dominio del problema. Es así que
cuando se analizan estos sistemas, debe tomarse en cuenta por ejemplo, el por qué manejan cierta
información y para qué sirve, lo que resultará de suma utilidad para el usuario final. También es
recomendable que luego de haber analizado el sistema, se lo muestre al usuario, ya que por su
experiencia pueden surgir importantes ideas nuevas.
Grabaciones de Video y Audio
Las grabaciones sirven básicamente como registro y apoyo de las entrevistas, y para analizar algún
proceso en particular.
Esta actividad permite centrar la atención en la entrevista en sí en vez de distraerse tomando notas
de todo lo que se dice. Cuando se está grabando la conversación, basta con puntear en una libreta los
temas tratados para después tener una guía básica de los mismos y luego saber en qué lugar de la
grabación se deben realizar ciertas búsquedas. Además, posibilita analizar los temas con más
detenimiento y con una visión más global, pues ya se ha conversado sobre todos los puntos
necesarios y se han visto los procesos específicos/ad hoc.
Una gran ventaja de esta técnica es que permite ver y analizar el proceso la cantidad de veces que sea
necesario.
Es conveniente comenzar las grabaciones con preguntas poco importantes que sirvan para prepara al
usuario y a la vez relajar el ambiente.
Brainstorming (tormenta de ideas)
Este modelo se usa para generar ideas. Su intensión es la producción de la máxima cantidad de
requerimientos para el sistema.
Se sugiere no detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio
consiste en generar en una primera instancia muchas ideas. Luego, se eliminarán tales ideas en base a
Unidad de Tecnologías de Información
131
Metodología MDS-α
distintos criterios, por ejemplo: caro, impracticable, imposible, no confiable, fuera de las expectativas,
etc.
Las reglas básicas a seguir son:
§
Los participantes deben pertenecer a diferentes disciplinas y, preferentemente, deben poseer
mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas
creativas.
§
Conviene suspender el juicio crítico y se debe permitir la evolución de cada uno de los
aportes, porque si no puede crearse un ambiente hostil que no alienta a la generación de
ideas.
§
Por más ilógicas que parezcan algunas ideas, no se las debe descartar, porque luego de
maduradas probablemente se tornen en un requerimiento sumamente útil.
§
A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias
ideas para generar una nueva.
§
No debe existir censura al escribir las ideas.
Arqueología de Documentos
Esta herramienta posibilita determinar requerimientos sobre la base de la inspección de
documentación utilizada en la institución; por ejemplo: boletas, facturas, recibos, formularios,
reportes, etc. En el caso de las facturas podemos encontrar información que no se pensaba manejar y
que en definitiva resulta de suma utilidad, como un número propio de la institución que se usa para
saber el orden que tiene la factura en una determinada carpeta y que permite encontrar las copias
del documento con mayor rapidez.
En definitiva, se debe recolectar cualquier documento que sea utilizado para registrar o enviar
información. Y, en el análisis de cada documento, se puede realizar algunas preguntas, como:
§
¿Cuál es el propósito del documento?
§
¿Quién lo usa? ¿Por qué? ¿Para qué?
§
¿Qué tareas que realizan con este documento?
§
¿Qué relaciones existentes entre los distintos documentos?
§
¿Cuál es el proceso que realiza la conexión con estos documentos?
§
¿Cuál es el documento que genera más problemas a los usuarios?
Unidad de Tecnologías de Información
132
Metodología MDS-α
Aprendiz
Esta herramienta se basa en la idea del maestro y el aprendiz, y es una buena forma de observar el
trabajo real. El aprendiz es representado por el analista y el usuario cumple el rol de maestro.
El aprendiz se sienta con el maestro a aprender por medio de la observación, realizando
intervenciones interrogativas como ¿por qué hizo eso? y ¿qué significa eso?, y también realizando
algún trabajo bajo la supervisión del maestro.
Esta técnica puede ser combinada para confeccionar el modelo conceptual. A medida que el trabajo
es observado y explicado, el analista puede realizar bosquejos para cada una de las tareas realizadas
en distintos flujos de datos.
La aplicación de esta herramienta libera muchas veces al usuario el explicar cómo realiza su trabajo.
Una de las posibles objeciones que se le pueden hacer a esta herramienta es que su implementación
requiere de mucho tiempo.
Observación
Observar el cómo se hacen las cosas es una buena manera de entender lo que estas requieren. Esto
significa que de alguna manera debe conectarse íntimamente con la cultura organizacional de la
institución, palpar y vivir su realidad. El análisis permitirá buscar estructuras y patrones a los distintos
procesos y de la problemática en general, para luego posibilitar las diferentes abstracciones de la
realidad.
Run Use Case WorkShop
Son Talleres de Trabajo basados en los Casos de Uso. En esta actividad participan los usuarios y el
equipo de requerimientos. La primer parte del WorkShop consiste en generar los escenarios
correspondientes con información proporcionada por los diferentes usuarios del sistema.
Por medio de los casos de uso y de las cosas esenciales extraídos de los usuarios se debe resolver
conjuntamente los diferentes sucesos que se van presentando; así por ejemplo se pueden identificar
los distintos tipos de usuarios, e identificar los diferentes pasos que se realizan en un caso de uso
particular. Luego se dilucida con la contraparte si los pasos registrados son o no los correctos, si están
Unidad de Tecnologías de Información
133
Metodología MDS-α
bien o si deben ser ajustados (cambiar, mejorar, adecuar). Como resultado de este proceso
obtenemos un excelente bosquejo del caso de uso.
Una vez finalizada la etapa anterior, el equipo de requerimientos retorna a la oficina a especificar y
deducir los requerimientos, a partir del conocimiento previamente adquirido.
Prototipos
Durante la actividad de extracción, puede ocurrir que algunos requerimientos no estén claros o que
no se esté seguro de haber entendido correctamente los diferentes requerimientos obtenidos hasta
el momento, lo cual puede conducir a un desarrollo ineficiente del sistema final. Entonces, para
validar los requerimientos hallados, se construyen prototipos.
Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final,
permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado en
base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y
efectiva.
Los prototipos se pueden clasificar en:
§
Prototipo Evolutivo: Cuando un usuario no puede articular sus requerimientos, entonces los
mismos se pueden determinar mediante un proceso de ensayo y error. De esta manera se
van realizando evoluciones sobre la base de un prototipo hasta determinar claramente los
requerimientos.
§
Prototipo Bosquejado: Para este prototipo nos apoyamos, por un lado, en el rol del analista
de requerimientos, simulando las respuestas del sistema y realizando bosquejos de las
interfaces de usuario; y, por otro, el usuario, que es quien realiza las entradas (utilizando el
prototipo) y mediante el diálogo, manejamos la interactividad entre el usuario y el sistema.
Una de las ventajas más importantes es el poco esfuerzo que realizamos para aplicar los
cambios.
§
Prototipo Tangible/Usable: Los términos tangible y usable se refieren a desarrollar una
aplicación (software) que el usuario pueda utilizar, es decir, con la cual pueda interactuar
como si fuera la aplicación final.
Unidad de Tecnologías de Información
134
Metodología MDS-α
Cualquiera sea la herramienta de software, que elijamos utilizar para desarrollar el prototipo,
debemos recordar los siguientes puntos:
§
Debe demandar poco esfuerzo para realizar los cambios.
§
Debe ser flexible en el manejo de interfaces de usuario.
§
Debe consumir poco tiempo para generar un nuevo prototipo.
Cabe remarcar y dejar muy en claro al usuario que se trata de un prototipo y que no es el producto
final; para explicar esta diferencia se pude recurrir a la analogía con las maquetas de los arquitectos.
Las desventajas más importantes de los prototipos pueden ser:
§
Costo de entrenamiento y capacitación en la herramienta
§
Costo de confeccionar el prototipo.
§
Problemas de calendario.
§
Incompletitud (puede confundir a los usuarios, haciéndolos pensar que el producto final
quedará como el prototipo, es decir incompleto).
Análisis FODA
Con este análisis se intentan identificar las principales fortalezas, oportunidades, debilidades y
amenazas con las que se enfrenta una institución.
Fortalezas
Debilidades
Oportunidades
Amenazas
Negativo
Positivo
Interno
Externo
Diag. A-5-1: Diagrama FODA
Por un lado, las oportunidades y las amenazas, se refieren a los factores externos que pueden afectar
el futuro del negocio. Y por otro lado, se encuentran las fortalezas y debilidades que son factores
Unidad de Tecnologías de Información
135
Metodología MDS-α
internos. Las fortalezas señalan ciertas estrategias cuya aplicación podría conducir al éxito del
negocio, mientras que las debilidades señalan aquello que la institución debe corregir.
Esta herramienta se usa para analizar la situación de una entidad e identificar la forma en que se
puede ayudar a disminuir las debilidades y amenazas; y a la vez cómo se pueden crear y aprovechar
las oportunidades y, cómo hacer aún más fuertes las fortalezas. También es útil para analizar el
impacto de la solución planteada.
Modelado Conceptual
Un modelo conceptual es una representación de conceptos del dominio del problema. Permite
mostrar conceptos, atributos y asociaciones entre conceptos. La creación del modelo posibilita
comprender la terminología del dominio y comunica cuáles son los términos importantes y las
relaciones existentes entre ellos.
Para representar un concepto podemos basarnos en el Modelo Entidad Relación, o si hablamos del
entorno orientado a objetos en el Diagrama de Clases, utilizando las entidades y las clases como
forma de representar el concepto respectivamente.
Esta herramienta es utilizada para capturar el vocabulario del sistema que se está desarrollando.
Mediante ella podemos incluir abstracciones que forman parte del dominio.
El modelo conceptual muestra los conceptos que se manejan en el negocio y como se relacionan
entre sí. Es una buena forma de obtener la idea general de cómo funciona el negocio (relaciones
entre los diferentes elementos), y a la vez capturar su vocabulario y conceptos.
Si se utiliza el modelamiento conceptual en las el proceso de ingeniería de requerimientos, debe
entenderse que este representa todavía una visión parcial hasta consensuar con el usuario el modelo
final (esto generalmente corresponde a la etapa de especificación).
Diagrama de Pescado
Permite identificar, explorar y exhibir gráficamente, con detalles crecientes, todas las posibles causas
relacionadas con un problema o condición a fin de descubrir su raíz u origen y poder concentrarse en
el contenido del problema, no en la historia del mismo.
Unidad de Tecnologías de Información
136
Metodología MDS-α
En la figura que se presenta como ejemplo del diagrama de pescado, se analizan las posibles causas
por las cuales el proceso de control de personal en la Unidad de Recursos Humanos es insuficiente.
entorno
funcionarios
sobrecarga
laboral
demasiados
datos
Control de
personal
insuficiente
manual
proceso
obsoleto
equipos de
computación
Graf. A-5-1: Diagrama de Pescado
Como vemos en este diagrama, se distinguen 4 categorías básicas: funcionarios, entorno, proceso,
equipos de computación. En dicha figura vemos causas relacionadas a las distintas categorías. Por
ejemplo, se analiza una posible causa relacionada con la sobrecarga laboral de los funcionarios, y otra
que es el estado obsoleto de los equipos de computación en la Unidad de Recursos Humanos de la
institución.
Con esta se puede analizar el impacto de la solución planteada para un requerimiento dado. Por
ejemplo, cómo afecta el trabajo diario del funcionario de la Unidad de Recursos Humanos.
También en el caso de que la solución planteada interactúe con otros sistemas existentes
(modificando, consultando o intercambiando información), el diagrama de pescado nos permite
analizar los posibles problemas que pueden surgir.
Esta herramienta la podemos utilizar conjuntamente con una tormenta de ideas (brainstorming), y de
esta manera ordenar las posibles soluciones a un problema. Es decir, por un lado se generan ideas y
por el otro utilizamos esta herramienta para organizarlas.
Unidad de Tecnologías de Información
137
Metodología MDS-α
Glosario
El glosario es una simple lista de términos en donde se incluyen su significado y explicación de
palabras que no son de uso común, mejorando así la comunicación con el usuario y con grupo en
general.
El glosario es dinámico en cuanto a su actualización, mientras transcurre el proceso de Ingeniería de
Requerimientos, perfeccionándolo en cada nuevo ciclo.
Para conformar el glosario pueden utilizarse dos columnas; en la primera se identifica el nombre del
término y, en la segunda, se detalla su descripción.
Termino
Descripción
Tabla A-5-2: Plantilla para la definición del Glosario
Es recomendable ordenar alfabéticamente esta tabla por Términos, para así facilitar las consultas.
Lista de Requerimientos
La lista de requerimientos es un documento en donde se describen los requerimientos del sistema (o
sea que debe hacer el sistema). Solamente se incluyen los requerimientos del producto. Ayuda
bastante que el usuario sepa cabalmente los requerimientos del sistema; en esta lista va expresado
toda la demanda que tiene propiamente el usuario.
Los requerimientos pueden ser clasificados en dos grandes categorías, los no-funcionales y los
funcionales.
Los no-funcionales señalan las características de cómo el sistema debe realizar su trabajo; por
ejemplo: eficiencia, hardware necesario, software, etc.
Por otro lado, los requerimientos funcionales definen qué hace el sistema; describen básicamente
todas las entradas y salidas, las relaciones respectivas, mismas que el sistema debe manejar.
Resumiendo, los requerimientos funcionales describen las funciones del sistema.
Unidad de Tecnologías de Información
138
Metodología MDS-α
La plantilla a utilizar es la siguiente:
Código
RNF-001
RNF-002
RNF-003
RNF-XYZ
REQUERIMIENTOS NO FUNCIONALES
Descripción
Tabla A-5-3: Plantilla para la descripción de Requerimientos No Funcionales
Código
RF-001
RF-002
RF-003
RF-XYZ
REQUERIMIENTOS FUNCIONALES
Descripción
Tabla A-5-4: Plantilla para la descripción de Requerimientos Funcionales
Checklist
El Checklist o lista de verificación es una herramienta fácil de usar y proporciona una gran utilidad. En
general, es una lista de preguntas que el analista debe utilizar para evaluar cada requerimiento. Se
deben verificar y marcar los puntos de evaluación mientras se lee la lista de requerimientos. Cuando
emergen problemas potenciales, los mismos deben ser anotados y descritos cabalmente.
Las checklist brindan un recordatorio de lo que se debe buscar y reducen las chances de pasar por
alto alguna verificación importante.
Para esta sección se puede utilizar la plantilla genérica descrita a continuación, en donde la misma se
utiliza según la cantidad de requerimientos descritos en la lista de requerimientos (funcionales y no
funcionales)
COD-REQ.: REQUERIMIENTO
Preguntas de Verificación
Pregunta - 01
Pregunta - 02
Pregunta - 03
Pregunta - XY
Respuesta
Tabla A-5-5: Plantilla para la lista de verificación de requerimientos
Unidad de Tecnologías de Información
139
Metodología MDS-α
ANEXO 6
ESTILOS ARQUITECTÓNICOS
Un aspecto fundamental de la disciplina de Arquitectura de Software son los estilos. Un estilo es un
concepto descriptivo que define una forma de articulación u organización arquitectónica. Es una
forma recurrente de estructurar o documentar un sistema.
El conjunto de los estilos cataloga las formas básicas de estructuras de software, mientras que las
formas complejas se articulan mediante composición de los estilos fundamentales. Tiene propiedades
que los hace interesantes y útiles por ser soluciones abstractas para alcanzar ciertos requerimientos
de calidad (requerimientos no funcionales).
Diferentes partes del sistema pueden tener diferentes estilos arquitectónicos. La descripción de un
estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un lenguaje
de descripción arquitectónica o en lenguajes formales de especificación.
Una clasificación convencional de estilos arquitectónicos está dada por:
§
Estilos de Flujo de Datos
o Tuberías y filtros
o Secuencial y en lote
§
Estilos Centrados en Datos
o Arquitecturas de Pizarra o Repositorio
o Base de Datos
o Sistemas de Hipertexto
§
Estilos de Llamada y Retorno
o
Programa principal y subrutina
o
Model-View-Controller (MVC)
o
Arquitecturas en Capas
o
Arquitecturas Orientadas a Objetos
o
Cliente Servidor
o
Arquitecturas Basadas en Componentes
Unidad de Tecnologías de Información
140
Metodología MDS-α
§
Estilos de Máquinas Virtuales
o Intérpretes
o Sistemas basados en Reglas
§
Estilos Peer-to-Peer
o Arquitecturas Basadas en Eventos
o Arquitecturas Orientadas a Servicios
o Arquitecturas Basadas en Recursos
§
Estilos Heterogéneos
o Sistemas de Control de Procesos
o Arquitecturas Basadas en Atributos
Con el uso de estilos arquitectónicos se pueden cortar diseños complejos en diseños más simples,
evitando malas prácticas y representando las estructuras de los sistemas de forma más limpia y
concisa, por ejemplo:
§
Mala Práctica
o Aplicaciones clientes que consultan si sucedió algo
o Listener de HTTP, Archivo, Colas
§
Buena Práctica
o Estilo basado en Eventos
A continuación se brinda una lista de ejemplos de Arquitectura de Software de sistemas conocidos y
un pequeño catálogo de algunos estilos arquitectónicos.
Unidad de Tecnologías de Información
141
Metodología MDS-α
Graf. A-6-1: Arquitectura de Software de un Video Juego
Secuencial
Paralelo
Analizador
Sintáctico
Analizador
Sintáctico
Parser
Parser
Analizador
Semántico
Analizador
Semántico
Representación Interna
Optimizador
Generación
de Código
Graf. A-6-2: Arquitectura de Software de un Compilador
Unidad de Tecnologías de Información
142
Metodología MDS-α
Editor de
Diseño
Traductor
del Diseño
Generador
de Código
Editor del
Programa
Repositorio del Proyecto
Análisis y
Diseño
Generador
de Reportes
Graf. A-6-3: Arquitectura de Software de una Herramienta CASE
Datos (Estado
del Programa)
Programa
siendo
interpretado
Maquina de
Interpretación
Simulada
Estado
Interno del
Interprete
Graf. A-6-4: Arquitectura de un Intérprete implementada en Maquina Virtual
Sensores
Adquisición
Datos de
Vigilancia
Control de
Seguimiento
Preparación
Proceso de
Entrada
Control de
Calidad
Tiempo Real
Seguridad
de la Red
Seguimiento
Mono
Distribución
de Datos de
Vigilancia
Fusión
Horizontal
Vertical
Gestión de
Pistas
Monitoreo
Correlación
Grabación
Dispositivos
Graf. A-6-5: Arquitectura de un Sistema de Vigilancia
Unidad de Tecnologías de Información
143
Metodología MDS-α
Aplicación
Presentación
Sesión
Transporte
Red
Enlace
Física
Graf. A-6-6: Arquitectura de Referencia del Modelo Estándar OSI
Cliente 1
Cliente 2
Cliente 3
Cliente 4
Red de Banda Ancha
Servidor de
Catálogos
Servidor de
Video
Servidor de
Gráficos
Servidor de
Hipertexto
Graf. A-6-7: Arquitectura de Software de una Biblioteca de Videos y Pinturas
Estilo de Arquitectura de Tuberías y Filtros
Basada en el patrón “pipe and filter” (tuberías y filtros). En este estilo los componentes se denominan
filtros y las conexiones tuberías. Cada filtro trabaja de manera independiente, esperan un conjunto de
datos en un determinado formato y procesa como resultado otros datos de salida, también en un
formato específico.
Si el flujo degenera en una única línea de transformación, la arquitectura se denomina secuencial en
batch o en lote.
Unidad de Tecnologías de Información
144
Metodología MDS-α
Tuberías
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
a) Tuberías y Filtros
Filtro
Filtro
Filtro
Filtro
b) Batch Secuencial
Graf. A-6-8: Estilo de Arquitectura de Tuberías y Filtros / Batch Secuencial
Estilo de Arquitectura de Pizarra
En la parte central de este tipo de arquitectura se destaca un almacén de datos, el cual es accedido y
actualizado de manera frecuente por los otros componentes (adicionan, actualizan, modifican y
borran tales almacenes). El cliente accede a un repositorio central, este repositorio puede ser:
§
Repositorio Pasivo: el software cliente accede a los datos independientemente de cualquier
cambio en los datos o a las acciones de otros clientes.
§
Repositorio Activo (Pizarra): el repositorio envía información a los clientes cuando los datos
de su interés cambian, así de esta manera se considera como un ente activo.
Cliente 1
Cliente 2
Pizarra
Cliente 6
Cliente 5
Cliente 3
Cliente 4
Graf. A-6-9: Estilo Arquitectónico de Pizarra
Unidad de Tecnologías de Información
145
Metodología MDS-α
Estilo de Arquitectura de Programa Principal/Subprograma
Posibilita estructurar software con relativa facilidad de modificación y escalamiento. Se trata de
descomponer las funciones en jerarquías de control, donde el programa principal invoca a los
programas subordinados y estos a su vez a los otros.
P
a
d
i
e
j
c
b
g
f
k
l
h
m
n
o
Graf. A-6-10: Estilo de Arquitectura de Programa Principal/Subprograma
Estilo de Arquitectura Orientada a Objetos
Los componentes del sistema encapsulan datos y operaciones que deben utilizarse para manipular
tales datos. La comunicación y coordinación de entre componentes se realiza mediante envío de
mensajes. Su arquitectura es de un sistema de llamada y retorno, donde se enfatiza el
empaquetamiento entre datos y operaciones que permiten manipular y acceder dichos datos.
Las representaciones de los datos y las operaciones están encapsuladas en un tipo abstracto de datos
u objeto, los componentes son los objetos; las invocaciones de los métodos son los conectores
Obj 1
Obj 2
Obj 3
Atributos
Atributos
Atributos
Métodos
Métodos
Métodos
Obj 4
Atributos
Métodos
Graf. A-6-11: Estilo de Arquitectura Orientada a Objetos
Unidad de Tecnologías de Información
146
Metodología MDS-α
Estilo de Arquitectura en Capas
Este estilo permite definir un conjunto de niveles o capas; por lo general cada capa solo puede
comunicarse con su vecina y aunque esta solución puede ser menos eficiente en algunos casos,
facilita la portabilidad de los diseños. Dependiendo el lugar que ocupe una capa; cada capa provee
servicios a la capa superior y éste servido por la capa inferior. Los componentes son cada una de las
Capa 4
Capa 3
Capa 2
Capa 1
capas y los conectores son los protocolos de interacción entre las capas.
Graf. A-6-12: Estilo de Arquitectura en Capas
Estilo de Arquitectura Cliente Servidor
Se refiere a un esquema de sistema distribuido, el cual muestra cómo los datos y el procesamiento se
distribuyen a través de un rango de componentes; tales componentes se identifican en ser la red,
clientes o servidores, estos últimos tienen inmerso un estado stand-alone para la ejecución de un
servicio específico ante la petición de un determinado cliente.
Cliente 1
Cliente 2
Cliente 3
Cliente 4
Red de Comunicación
Servidor 1
Servidor 2
Servidor 3
Servidor 4
Graf. A-6-13: Estilo de Arquitectura Cliente Servidor
Unidad de Tecnologías de Información
147
Metodología MDS-α
Estilo de Arquitectura de Máquina Virtual o Intérprete
Este tipo de solución de software resuelve varios problemas de hardware y está básicamente
reducida a la aplicación de lenguajes de programación, está formado por cuatro componentes
elementales:
§
Un motor de simulación o interpretación
§
Una memoria que contienes el código a interpretar
§
Una representación del estado de la representación
§
Una representación del estado del programa que se está simulando
Estado del
Programa
Memoria con
Código a
Interpretar
Simulación de la
Interpretación
Estado de la
Interpretación
Graf. A-6-14: Estilo de Arquitectura de Máquina Virtual o Intérprete
Estilo de Arquitectura de Control de Procesos
Cualquier sistema diseñado bajo este estilo se compone de tres elementos básicos:
§
Control: Implementa el algoritmo de control presentando las interfaces de activación y
desactivación, establece los rangos de funcionamiento.
§
Proceso: Oculta los dispositivos que ocultan la salida cuyos parámetros deben ser medidos y
controlados; ofrece una interfaz al Control de manera que pueda modificar el proceso cuando
resulte conveniente
§
Sensores: Miden los parámetros que deben ser controlados (se los conoce como variables
controladas o variables medibles) y comunican esos valores al Control.
Este estilo permite las incorporaciones sencillas de más o diferentes sensores, mejoras en el
algoritmo de control, cambios en los diferentes tipos dispositivos de hardware, etc.
Unidad de Tecnologías de Información
148
Metodología MDS-α
Control
Proceso
Sensor 1
Sensor 2
Graf. A-6-15: Estilo de Arquitectura de Control de Procesos
Estilo de Arquitectura Modelo Vista Controlador
Este patrón de arquitectura separa los datos de una aplicación, la interfaz de usuario y lógica de
control en básicamente tres componentes:
§
Modelo: encargada de la implementación de las funcionalidades y datos del sistema
§
Vista: Gestiona la forma de mostrar los datos al usuario
§
Controlador: responde a acciones del usuario (eventos) e invoca cambios en el modelo y
probablemente en la vista.
Modelo
Vista
Controlador
Graf. A-6-16: Estilo de Arquitectura Modelo Vista Controlador
Unidad de Tecnologías de Información
149
Metodología MDS-α
ANEXO 7
NORMALIZACION DE BASES DE DATOS
El proceso de Normalización de Bases de Datos consiste en aplicar una serie de reglas a las relaciones
obtenidas tras el paso de mapeo del Modelo Entidad Relación al Modelo Relacional.
Las Bases de Datos relacionales se estandarizan o normalizan con el objeto de:
§
Evitar la redundancia de los datos.
§
Evitar problemas de actualización de los datos en las tablas.
§
Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea
considerada como una relación tiene que cumplir con algunas restricciones:
§
Cada columna debe tener un nombre único.
§
No puede haber dos filas iguales. No se permiten los registros duplicados.
§
Todos los datos en una columna deben ser del mismo tipo o dominio.
TERMINOLOGÍA RELACIONAL
Graf. A-7-1: Terminología del Modelo Relacional
Para una mejor manipulación es preferible tratar esta terminología a nivel de esquemas, es decir:
Trabajo (Código, Nombre, Posición, Salario)
donde Código es la Clave Primaria.
Unidad de Tecnologías de Información
150
Metodología MDS-α
Así también se respeta la siguiente terminología:
§
Relación = tabla o archivo
§
Tupla = registro, fila o renglón
§
Atributo = columna o campo
§
Clave = llave o código de identificación
§
Clave Candidata = superclave mínima
§
Clave Primaria = clave candidata elegida
§
Clave Ajena = clave externa o clave foránea
§
Clave Alternativa = clave secundaria
§
Dependencia Multivaluada = dependencia multivalor
§
RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de
Bases de Datos Relacionales.
§
1FN = Primera Forma Normal.
§
2FN = Segunda Forma Normal.
§
3FN = Tercera Forma Normal.
§
FNBC = Forma Normal de Boyce Codd.
§
4FN = Cuarta Forma Normal.
§
5FN = Quinta forma Normal.
Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo relacional, que constituyen la
fuente teórica del Modelo de Base de Datos Relacional.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo
puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto
cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la
analogía matemática, dado que algunos RDBMS permiten filas duplicadas, entre otras cosas.
Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto
cartesiano entre los dominios.
DEPENDENCIA FUNCIONAL
La dependencia funcional muestra asociaciones lógicas de los datos; significa que los valores para A y
B en tal asociación; el valor de B será deducido o mantendrá su valor a partir de A, así decimos que:
Unidad de Tecnologías de Información
151
Metodología MDS-α
§
B depende funcionalmente de A
o que es lo mismo:
§
A determina el valor de B
A
B
A
B
Graf. A-7-2: Representación de la Dependencia Funcional
Por ejemplo si conocemos el valor de fechaNacimiento podemos conocer el valor de edad, y la
dependencia funcional salta a la luz de la manera siguiente:
fechaNacimiento à edad
Axiomas de Armstrong
A1: Dependencia Funcional Reflexivo
Si Y está incluido en X, entonces X à Y
Por ejemplo:
Si el nombre está incluido en el carnetIdentidad, entonces del carnetIdentidad podemos
determinar el nombre
Si nombre Í carnetIdentidad , entonces carnetIdentidad ® nombre
A2: Dependencia Funcional Incremental
Si X à Y, entonces X, Z à Y, Z
Por ejemplo:
Unidad de Tecnologías de Información
152
Metodología MDS-α
Si carnetIdentidad à nombre, entonces carnetIdentidad, direccion à nombre, direccion
Si con el carnetIdentidad se determina el nombre de una persona, entonces con el
carnetIdentidad mas la direccion se determina el nombre o direccion de la persona.
A3: Dependencia Funcional Transitiva
Si X à Y à Z , entonces X à Z
Por ejemplo:
Si fechaNacimiento à edad à licenciaConducir,
entonces fechaNacimiento à licenciaConducir
Se tiene que fechaNacimiento determina edad, y edad determina licenciaConducir, entonces
fechaNacimiento determina licenciaConducir. Para este ejemplo la restricción de aplicación es
que para tener Licencia de Conducir se debe adquirir la Mayoría de Edad.
FORMAS NORMALES
Las Formas Normales son aplicadas a las tablas de una determinada Base de Datos. Mencionar que
una Base de Datos está en la forma normal FN implica decir que todas las tablas que la componen
están en la forma normal FN.
Para cubrir las necesidades generales en la mayoría de las Bases de Datos, se requiere que la misma
este normalizada con las primeras tres formas.
Primera Forma Normal - 1FN
Una tabla o esquema está en Primera Forma Normal (1FN) si:
§
Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son
indivisibles, mínimos e inseparables.
§
La tabla contiene una clave primaria.
§
La tabla no contiene atributos nulos.
§
La tabla no posee ciclos o grupos repetitivos.
Unidad de Tecnologías de Información
153
Metodología MDS-α
Una columna no puede tener múltiples valores, los datos son atómicos, cada uno de los registros
debe tener el mismo número de atributos que es lo mismo decir que cada registro debe contener el
mismo tipo y número de campos. Esta forma normal elimina los valores repetidos dentro de una Base
de Datos.
Por ejemplo:
Se tiene en el Ministerio de Economía y Finanzas Públicas diferentes puestos de trabajo regulados por
el Estado, lo que significa que las condiciones salariales están determinadas por el puesto. Para ello se
ha creado el siguiente esquema relacional:
FUNCIONARIO(cod_funcionario, nombre, puesto, salario, emails) con cod_funcionario como clave
primaria.
FUNCIONARIO
cod_funcionario
111
222
333
...
nombre
Juan Pérez Miranda
José Duran Chambi
Ana María Díaz Cabero
...
puesto
Jefe de Unidad
Administrativo
Administrativo
...
salario
12000
3000
3000
...
emails
[email protected]; [email protected]
[email protected]
[email protected]; [email protected]
...
No está en Primera Forma Normal – 1FN(X)
Solución 1
FUNCIONARIO
cod_funcionario
111
111
222
333
333
...
nombres
Juan
Juan
José
Ana María
Ana María
...
paterno
Pérez
Pérez
Duran
Díaz
Díaz
…
materno
Miranda
Miranda
Chambi
Cabero
Cabero
…
puesto
Jefe de Unidad
Jefe de Unidad
Administrativo
Administrativo
Administrativo
...
salario
12000
12000
3000
3000
3000
...
emails
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
...
Si está en Primera Forma Normal – 1FN y su llave primaria es (cod_funcionario, nombres, paterno,
materno, puesto, salario, emails)
Solución 2
FUNCIONARIO
cod_funcionario
111
222
333
...
nombres
Juan
José
Ana María
...
paterno
Pérez
Duran
Díaz
…
materno
Miranda
Chambi
Cabero
…
puesto
Jefe de Unidad
Administrativo
Administrativo
...
salario
12000
3000
3000
...
Si está en Primera Forma Normal – 1FN y su llave primaria es (cod_funcionario)
Unidad de Tecnologías de Información
154
Metodología MDS-α
EMAIL
email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
...
cod_funcionario
111
111
222
333
333
...
Si está en Primera Forma Normal – 1FN y su llave primaria es (email) con llave foránea
(cod_funcionario) a la Tabla FUNCIONARIO.
Segunda Forma Normal – 2FN
Una tabla o esquema está en Segunda Forma Normal (2FN) si:
§
Está en Primera Forma Normal (1FN).
§
Los atributos que no forman parte de ninguna clave dependen de forma completa de la clave
principal, es decir que no existen dependencias parciales.
Continuando con el ejemplo anterior, a partir de la última solución analizamos:
§
Ambas tablas (FUNCIONARIO y EMAIL) están en Primera Forma Normal (1FN).
§
Para un valor particular de llave principal (tanto en la tabla FUNCIONARIO como EMAIL)se
puede determinar el valor de los restantes atributos, es decir cada atributo depende de
forma completa de la llave primaria.
Por tanto, la segunda solución también se encuentra en Segunda Forma Normal (2FN).
NOTA: cuando la llave primaria de una tabla es simple, se tiene prácticamente garantizado que se
encuentra en 2FN. Y si tuviéramos una llave compuesta, y parte de ella determina el valor de algún
atributo, entonces si nos encontraríamos en problemas, para tal caso debe estudiarse la composición
de la llave primaria y la posibilidad de crear una tabla que muestre esa dependencia en una relacion.
Tercera Forma Normal – 3FN
Una tabla o esquema esta en Tercera Forma Normal (3FN) si:
§
Está en Segunda Forma Normal (2FN).
§
No existe ninguna dependencia funcional transitiva entre los atributos que no son clave (o
parte de ella).
Unidad de Tecnologías de Información
155
Metodología MDS-α
Siguiendo el ejemplo dado, y partiendo de la última solución tenemos:
§
Se encuentra en 2FN.
§
Existe dependencia funcional transitiva entre:
(cod_funcionario à puesto) y (puesto à sueldo)
Por tanto no se cumple con la Tercera Forma Normal (3FN). Y para transformarla adecuadamente
hacemos:
FUNCIONARIO
cod_funcionario
111
222
333
...
nombres
Juan
José
Ana María
...
paterno
Pérez
Duran
Díaz
…
materno
Miranda
Chambi
Cabero
…
puesto
Jefe de Unidad
Administrativo
Administrativo
…
Si está en Tercera Forma Normal – 3FN y su llave primaria es (cod_funcionario) con llave foránea
(puesto) a la Tabla PUESTO.
PUESTO
puesto
Jefe de Unidad
Administrativo
...
salario
12000
3000
...
Si está en Tercera Forma Normal – 3FN y su llave primaria es (puesto)
EMAIL
email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
...
cod_funcionario
111
111
222
333
333
...
Si está en Tercera Forma Normal – 3FN y su llave primaria es (email) con llave foránea
(cod_funcionario) a la Tabla FUNCIONARIO.
Forma Normal de Boyce - Codd - FNBC
La tabla o esquema esta en Forma Normal de Boyce – Codd (BCNF) si:
§
Está en 3FN.
§
Existen múltiples llaves candidatas.
§
Atributos compartidos entre las llaves compuestas.
Unidad de Tecnologías de Información
156
Metodología MDS-α
§
Cada atributo que determina completamente a otro, es clave candidata (este es un requisito
más fuerte que la 3FN, donde los atributos no clave tienen que mutuamente independientes).
Cuarta Forma Normal - 4FN
Una tabla o esquema se encuentra en Cuarta Forma Normal (4FN) si:
§
Para cada una de sus dependencias múltiples no funcionales XààY, con X una super-clave
que: X es una clave candidata ó un conjunto de claves primarias (este concepto se apoya
sobre dependencias multivaluadas).
Quinta Forma Normal - 5FN
Una tabla o esquema se encuentra en Quinta Forma Normal (5FN) si:
§
La tabla o esquema esta en 4FN.
§
No existen relaciones de dependencias no triviales que no siguen los criterios de las claves.
Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación de
dependencia se encuentra definida por las claves candidatas.
Unidad de Tecnologías de Información
157
Metodología MDS-α
BIBLIOGRAFÍA
[1] Alvarez Amalia y Scafarelli Leonardo (2006). ORT Software Factory- Aseguramiento de la calidad.
Uruguay. Universidad ORT.
[2] Andía Valencia Walter. El árbol causa y efecto – Una metodología para los proyectos de inversión
privada. Perú. Lima.
[3] Arquitectura de software: arte y oficio. España. Valencia. Actualidad TIC. Universidad Politécnica
de Valencia. Instituto Tecnológico de Informática.
[4] Arquitectura de software (2002). España. Escuela Superior de Ingeniería Informática de Albacete.
[5] Bastarrica María Cecilia. Atributos de calidad y arquitectura de software. Chile. Universidad de
Chile. Departamento de Ciencias de la Computación.
[6] Billy Reynoso Carlos (2004). Introducción a la Arquitectura de Software. Argentina. Buenos Aires.
Universidad de Buenos Aires.
[7] Camacho H., Cámara L., Cascante R. y Sainz H. El enfoque del marco lógico – 10 casos prácticos.
España. Madrid. CIDEAL – ADC.
[8] Cristiá Maximiliano (2006). Catálogo incompleto de estilos arquitectónicos. Argentina. Santa Fe.
Universidad Nacional de Rosario. Facultad de ciencias exactas, Ingeniería y Agrimensura.
[9] Cuesta Carlos. Arquitectura de Software. España. Universidad Rey Juan Carlos.
[10] Cueva Lovelle Juan Manuel (1999). Calidad del software. España. Universidad de Oviedo.
[11] Davyt Dávila Nicolás (2001). Ingeniería de Requerimientos. Uruguay. Universidad ORT, Facultad
de Ingeniería.
[12] Domínguez Kenyer, Perez María y Mendoza Luis (). Gestión de proyectos de desarrollo de
software libre con un enfoque de calidad. Venezuela. Caracas. Universidad Simón Bolivar
Unidad de Tecnologías de Información
158
Metodología MDS-α
[13] Elaboración de Procesos y Procedimientos (2007). España. Madrid. Universidad Politécnica de
Madrid.
[14] Fábrica de Software: Documento de proceso de la gerencia de aseguramiento de la calidad.
Chile. Universidad Católica de Chile, Escuela de Ingeniería, Departamento de Ciencias de la
Computación.
[15] Febles Estrada Ailyn y Pérez Isabel (2005). Métricas para la Configuración de Software. Cuba. La
Habana. Facultad de Ingeniería Industrial. Instituto Superior Politécnico José Antonio Echeverría
CUJAE.
[16] Fosch Alonso Ignasi y Arellano Roig Javier (2006). Guía de estilo de codificación. España.
Universidad Oberta de Catalunya.
[17] Giuliano A., Scarpa C., Bustamante D., Leiva D., García G., Macchi G., Vannini K., Cabot M.,
Ferrara M., Maldonado P., Villagra S., Piacentino S., Nucci V y Herrero V. Proyectos informáticos
– Técnicas y Herramientas (2000). Argentina. Buenos Aires. Universidad de Buenos Aires.
Facultad de Ingeniería.
[18] Gómez A (2004). Metodología de desarrollo de aplicaciones web. Venezuela. Caracas. Micorp.
[19] Gonzales Sigfrido, Gutiérrez Eduardo y Vasquez Hugo. Metodología de proyectos informáticos.
Chile. Ministerio de Planificación y Cooperación.
[20] Hernández Gonzáles Anaisa (2004): Informática – Identificación de Procesos de Negocio. Cuba,
La Habana. Instituto Superior Politécnico José Antonio Echeverría CUJAE. Facultad de Ingeniería
Industrial.
[21] Hristov Alexander (2007). Manual de estilo de programación. Bulgaria.
[22] IEEE 730 1998. Plan de aseguramiento de la calidad del software.
[23] IEEE-STD-828-1998: Plan de gestión de la configuración de software.
[24] IEEE-STD-830-1998: Especificaciones de los requisitos de software.
[25] Ishikawa Kaoru (1989). Diagrama causa y efecto.
Unidad de Tecnologías de Información
159
Metodología MDS-α
[26] ISO 9000-3: 1997. Administración y aseguramiento de la calidad del software.
[27] ISO 9001: 2000. Sistemas de gestión de calidad.
[28] ISO/IEC 12207. Procesos del ciclo de vida del software.
[29] ISO/IEC 9126. Evaluación del software.
[30] Kruchten Philippe (2003). The rational unified process an introduction. Estados Unidos. Addison
Wesley.
[31] León Carlos (2007). Evaluación de Inversiones. Perú. Chiclayo. Universidad Católica Santo Toribio
de Mogrovejo.
[32] Manual de procesos y procedimientos (2008). Bolivia. La Paz. Ministerio de Economía y Finanzas
Públicas.
[33] Marrero Carlos y Santos Kiberley (2007). Metodología de la red nacional de integración y
desarrollo de software libre – MeRinde. Venezuela. Caracas. Centro Nacional de Tecnologías de
Información.
[34] Matriz de indicadores – Metodología de marco lógico (2007). México. Consejo Nacional de
Evaluación de la Política de Desarrollo Social – CONEVAL.
[35] Mendez Anderson. Aseguramiento de la calidad mediante ingeniería de software. República
Dominicana: Politécnico de Azua.
[36] Metodología de desarrollo de sistemas de información MDSI versión 1 (2005). Perú. Lima.
Presidencia del Consejo de Ministros. Oficina Nacional de Gobierno Electrónico e Informática.
[37] Metodología de planificación, desarrollo y mantenimiento de sistemas de información –
METRICA Versión 3.0. España. Ministerio de Administraciones Públicas. Consejo Superior de
Informática y para el impulso de la Administración Electónica.
[38] Metodología para la elaboración de matriz de marco lógico. Chile. Dirección de Presupuesto.
Unidad de Tecnologías de Información
160
Metodología MDS-α
[39] Metodología para la preparación y evaluación de proyectos de educación. Chile. Santiago.
Ministerio de Planificación.
[40] Pollice Gary (2003). Using the RUP for small projects: Expanding upon extreme programming. A
Rational Software White Paper.
[41] Pulido Pavón Jose Antonio (2007). Arquitectura de software para sistemas de tiempo real
particionados. España. Madrid. Tesis Doctoral. Universidad Politécnica de Madrid.
[42] Rational Unified Process for System Engineering (2002). Rational the Software Development
Company
[43] Sanín Ángel Héctor. Marco lógico, instrumento de formulación, gestión y evaluación de
proyectos. BID – CEPAL.
[44] Serrano Juan Manuel (2008). Arquitecturas software y estilos arquitectónicos. España.
Universidad Rey Juan Carlos.
[45] Sommerville Ian (2000). Ingeniería de software – Diseño arquitectónico. Sexta edición.
[46] Thomas Fielding Roy (2000). Estilos arquitectónicos y el diseño de arquitecturas de software
basadas en red. Estados Unidos. Tesis Doctoral. University California – Irvine.
[47] Vásquez Gustavo. Testing de Performance. Uruguay. Montevideo. Universidad de la República.
Facultad de Ingeniería.
[48] Velásquez Huerta Robert Aldo. Control y evaluación de proyectos informáticos. Perú.
Universidad Inca Garcilaso de la Vega. Facultad de Educación.
[49] Vilalta Marzo Josep (2007). Modelo de Casos de uso. España. Barcelona.
Unidad de Tecnologías de Información
161
Metodología MDS-α
CONTENIDO
INTRODUCCIÓN ................................................................................................................................................. 1
METODOLOGÍAS ........................................................................................................................................... 1
METODOLOGÍA DE DESARROLLO DE SISTEMAS ALFA (MDS-α) ....................................................................... 1
ORGANIZACION ............................................................................................................................................ 2
APLICACIÓN METODOLÓGICA ....................................................................................................................... 4
Aplicación Lineal ........................................................................................................................................... 4
Aplicación Cíclica........................................................................................................................................... 5
Aplicación Iterativa por Fases ........................................................................................................................ 5
Guía Rápida de la Metodología ALFA ............................................................................................................. 6
CAPITULO 1 .....................................................................................................................................................10
1 BASES DE UN PROYECTO DE DESARROLLO DE SISTEMAS........................................................................... 10
1.1 GENERALIDADES ................................................................................................................................... 12
1.1.1 EVOLUCION DE LOS PROYECTOS EN TECNOLOGIAS DE INFORMACION ................................................ 12
1.1.2 FUNDAMENTOS PARA LA ADOPCION DEL CRITERIO COSTO-EFICIENCIA .............................................. 13
1.1.3 CRITERIOS DE APROBACION O RECHAZO DE PROYECTOS EN TECNOLOGIAS DE INFORMACION ........... 14
1.2 CICLO DE PROYECTOS DE DESARROLLO DE SISTEMAS ............................................................................ 14
1.3 PROYECTOS DE INVERSION .................................................................................................................... 15
1.3.1 CICLO DE VIDA DE LOS PROYECTOS ..................................................................................................... 15
1.3.1.1 ESTADO DE PREINVERSION .............................................................................................................. 16
Etapa de generación y análisis de la idea de proyecto.................................................................................. 17
Etapa de estudio del perfil .......................................................................................................................... 18
Etapa de estudio de prefactibilidad ............................................................................................................. 18
Etapa de estudio de factibilidad .................................................................................................................. 19
1.4 TIPOS DE PROYECTOS INFORMATICOS ................................................................................................... 19
CAPITULO 2 .....................................................................................................................................................21
2 PREPARACION DEL PROYECTO DE DESARROLLO DE SISTEMAS .................................................................. 21
2.1 CARATULA Y TABLA DE CONTENIDOS..................................................................................................... 22
2.2 RESUMEN EJECUTIVO ............................................................................................................................ 22
2.3 PLAN O POLITICA INSTITUCIONAL SOBRE TECNOLOGIAS DE INFORMACION ........................................... 23
2.4 DEFINICION DEL PROBLEMA .................................................................................................................. 24
2.5 DIAGNOSTICO DE LA SITUACION ACTUAL............................................................................................... 24
2.5.1 DESCRIPCION DE LA UNIDAD ORGANIZACIONAL ................................................................................. 24
2.5.2 ACTUALIDAD TECNOLOGICA ............................................................................................................... 25
2.5.3 DESCRIPCION DE LOS PROCESOS Y PROCEDIMIENTOS......................................................................... 25
2.6 DESCRIPCIÓN GENERAL DE REQUERIMIENTOS ....................................................................................... 25
2.7 ESTIMACION DE BENEFICIOS ................................................................................................................. 25
2.8 ESTIMACION DE COSTOS ....................................................................................................................... 25
2.9 ALTERNATIVAS DE SOLUCION ................................................................................................................ 26
2.9.1 RESTRICCIONES DE CADA ALTERNATIVA ............................................................................................. 27
2.9.2 PRODUCTO O SERVICIO ESPERADO DE CADA ALTERNATIVA ................................................................ 27
2.9.3 ELECCION DE LA ALTERNATIVA ........................................................................................................... 27
2.10 MATRIZ DEL MARCO LÓGICO ............................................................................................................... 28
2.11 PLANIFICACION DE ACTIVIDADES ......................................................................................................... 28
Unidad de Tecnologías de Información
162
Metodología MDS-α
CAPITULO 3 .....................................................................................................................................................29
3 REQUERIMIENTOS DE SOFTWARE............................................................................................................. 29
3.1 VISIÓN Y ALCANCE DEL PROYECTO ........................................................................................................ 30
3.1.1 PLANTILLA PARA EL DOCUMENTO DE VISIÓN Y ALCANCES DEL PROYECTO .......................................... 30
3.1.1.1 REQUERIMIENTOS DE NEGOCIOS ..................................................................................................... 30
3.1.1.1.1 Antecedentes ............................................................................................................................... 30
3.1.1.1.2 Oportunidades de Negocio ........................................................................................................... 30
3.1.1.1.3 Objetivos de Desarrollo del Sistema .............................................................................................. 31
3.1.1.1.4 Requerimientos del Usuario.......................................................................................................... 31
3.1.1.1.5 Valor proporcionado al Usuario .................................................................................................... 31
3.1.1.1.6 Riesgos del Sistema ...................................................................................................................... 31
3.1.1.2 VISIÓN DE LA SOLUCIÓN .................................................................................................................. 31
3.1.1.2.1 Declaración de la Visión ................................................................................................................ 32
3.1.1.2.2 Características Principales............................................................................................................. 32
3.1.1.2.3 Dependencias y presunciones ....................................................................................................... 32
3.1.1.3 ALCANCE Y LIMITACIONES ............................................................................................................... 32
3.1.1.3.1 Alcance de la Versión Inicial .......................................................................................................... 32
3.1.1.3.2 Alcance de las versiones subsecuentes.......................................................................................... 32
3.1.1.3.3 Limitaciones y exclusiones ............................................................................................................ 33
3.1.1.4 CONTEXTO DEL NEGOCIO ................................................................................................................ 33
3.1.1.4.1 Características del usuario (Perfil) ................................................................................................. 33
3.1.1.4.2 Prioridades del Proyecto ............................................................................................................... 33
3.1.1.5 FACTORES DE ÉXITO DEL PRODUCTO ............................................................................................... 34
3.2 INGENIERÍA DE REQUERIMIENTOS ......................................................................................................... 34
3.2.1 Modelo Tradicional en Cascada .......................................................................................................... 35
3.2.2 Modelo en Espiral............................................................................................................................... 35
3.3 ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS .......................................................................... 36
3.3.1 Extracción .......................................................................................................................................... 36
3.3.2 Análisis............................................................................................................................................... 37
3.3.3 Documentación .................................................................................................................................. 38
3.3.4 Validación .......................................................................................................................................... 38
3.4 HERRAMIENTAS .................................................................................................................................... 38
CAPITULO 4 .....................................................................................................................................................39
4 ESPECIFICACIONES DE SOFTWARE ............................................................................................................ 39
4.1 MODELADO DEL NEGOCIO .................................................................................................................... 39
4.2 DIAGRAMA DE CONTEXTO..................................................................................................................... 41
4.3 CASOS DE USO ...................................................................................................................................... 41
4.3.1 Diagramas de Casos de Uso ................................................................................................................ 42
4.3.2 Documento de especificación de Casos de Uso ................................................................................... 43
4.4 DOCUMENTO DE ESPECIFICACIONES DE SOFTWARE .............................................................................. 44
4.4.1 Formato del Documento de Especificación de Software ...................................................................... 45
4.4.1.1. Introducción ................................................................................................................................... 45
4.4.1.1.1 Propósito...................................................................................................................................... 45
4.4.1.1.2 Alcance......................................................................................................................................... 45
4.4.1.1.3 Definiciones, siglas y abreviaciones ............................................................................................... 46
4.4.1.1.4 Referencias................................................................................................................................... 46
4.4.1.1.5 Resumen ..................................................................................................................................... 46
4.4.1.2 Descripción General ........................................................................................................................ 46
4.4.1.2.1 Perspectiva del Producto .............................................................................................................. 46
4.4.1.2.1.1 Interfaces del Sistema................................................................................................................ 46
Unidad de Tecnologías de Información
163
Metodología MDS-α
4.4.1.2.1.2 Interfaces del usuario ................................................................................................................ 46
4.4.1.2.1.3 Interfaces con el hardware......................................................................................................... 46
4.4.1.2.1.3 Interfaces con otros software .................................................................................................... 46
4.4.1.2.1.4 Interfaces con otros dispositivos de comunicación ..................................................................... 46
4.4.1.2.1.5 Operaciones .............................................................................................................................. 46
4.4.1.2.1.6 Requerimientos de adaptación .................................................................................................. 46
4.4.1.2.2 Funciones del Producto ................................................................................................................ 47
4.4.1.2.3 Características del Usuario............................................................................................................ 47
4.4.1.2.4 Restricciones ................................................................................................................................ 47
4.4.1.2.5 Suposiciones y dependencias ........................................................................................................ 47
4.4.1.3. Especificación de Requerimientos ................................................................................................... 47
4.4.1.3.1 Características del Sistema............................................................................................................ 48
4.4.1.3.2 Especificaciones de Rendimiento .................................................................................................. 49
4.4.1.3.3 Restricciones de diseño ................................................................................................................ 49
4.4.1.3.4 Atributos del Sistema.................................................................................................................... 49
4.4.1.3.5 Otros requerimientos ................................................................................................................... 49
4.4.1.4. Acuerdo o Contrato ........................................................................................................................ 49
4.5 DIAGRAMA DE FLUJO DE DATOS............................................................................................................ 50
CAPITULO 5 .....................................................................................................................................................52
5 ARQUITECTURA DEL SOFTWARE ............................................................................................................... 52
5.1 MODELOS DE ARQUITECTURA DE SOFTWARE ........................................................................................ 53
5.1.1 Modelos Estructurales ........................................................................................................................ 53
5.1.2 Modelos Framework .......................................................................................................................... 53
5.1.3 Modelos Dinámicos ............................................................................................................................ 54
5.1.4 Modelos de Proceso ........................................................................................................................... 54
5.1.5 Modelos funcionales .......................................................................................................................... 54
5.2 ELEMENTOS CLAVE EN LA ARQUITECTURA DE SOFTWARE ..................................................................... 54
5.2.1 Componentes..................................................................................................................................... 54
5.2.2 Conectores ......................................................................................................................................... 55
5.2.3 Configuraciones / Topologías.............................................................................................................. 55
5.3 REPRESENTACIÓN ARQUITECTÓNICA..................................................................................................... 55
5.4 ROL DEL ARQUITECTO DE SOFTWARE .................................................................................................... 57
5.5 FASES DE LA CONSTRUCCION DEL SOFTWARE........................................................................................ 57
5.5.1 Fase 1: Pre-Diseño .............................................................................................................................. 57
5.5.2 Fase 2: Análisis del Dominio................................................................................................................ 57
5.5.3 Fase 3: Diseño Esquemático................................................................................................................ 58
5.5.4 Fase 4: Desarrollo del Diseño .............................................................................................................. 58
5.5.5 Fase 5: Documentos del Proyecto ....................................................................................................... 58
5.5.6 Fase 6: Contratación o Sub-Contratación ............................................................................................ 58
5.5.7 Fase 7: Construcción........................................................................................................................... 58
5.5.8 Fase 8: Post-Construcción................................................................................................................... 59
5.6 ABSTRACCION DE LA ARQUITECTURA .................................................................................................... 59
5.7 ESTILOS ARQUITECTÓNICOS .................................................................................................................. 61
5.8 LENGUAJE DE DESCRIPCION ARQUITECTÓNICA ...................................................................................... 62
CAPITULO 6 .....................................................................................................................................................64
6 DISEÑO Y MODELAMIENTO ...................................................................................................................... 64
6.1 INTERFACE DE USUARIO ........................................................................................................................ 64
6.2 MODELO CONCEPTUAL ......................................................................................................................... 65
6.3 MODELO LOGICO .................................................................................................................................. 66
Unidad de Tecnologías de Información
164
Metodología MDS-α
6.3.1 Normalización .................................................................................................................................... 67
6.4 MODELO FISICO .................................................................................................................................... 68
6.4.1 Diccionario de Datos........................................................................................................................... 68
CAPITULO 7 .....................................................................................................................................................71
7 IMPLEMENTACION ................................................................................................................................... 71
7.1 GENERACION DE CODIGO ...................................................................................................................... 72
7.1.1 Convenciones de Codificación............................................................................................................. 72
7.1.1.1 Lineamientos generales ................................................................................................................... 72
7.1.1.2 Codificación Camel Case .................................................................................................................. 73
7.1.1.3 Indentación ..................................................................................................................................... 73
7.1.1.4 Indentar Seteo de Variables............................................................................................................. 74
7.1.1.5 Tamaño Máximo de Línea................................................................................................................ 75
7.1.1.6 Saltos de Línea................................................................................................................................. 75
7.1.1.7 Espacios y Líneas en Blanco ............................................................................................................. 75
7.1.1.8 Nombres de Clases .......................................................................................................................... 76
7.1.1.9 Interfaces ........................................................................................................................................ 77
7.1.1.10 Funciones, Procedimientos y Métodos........................................................................................... 77
7.1.1.11 Parámetros.................................................................................................................................... 77
7.1.1.12 Variables ....................................................................................................................................... 78
7.1.1.13 Nomenclatura de Variables............................................................................................................ 79
7.1.1.14 Constantes .................................................................................................................................... 79
7.1.1.15 Comentarios .................................................................................................................................. 80
7.1.1.16 Notificación de Errores .................................................................................................................. 81
7.1.1.17 Nombres de Archivos..................................................................................................................... 81
7.1.1.18 ESTILO DE CODIFICACIÓN .............................................................................................................. 82
7.1.1.18.1 Cadenas de Caracteres................................................................................................................ 82
7.1.1.18.2 Concatenación de Caracteres...................................................................................................... 82
CAPITULO 8 .....................................................................................................................................................83
8 PRUEBAS .................................................................................................................................................. 83
8.1 PRUEBAS UNITARIAS ............................................................................................................................. 84
8.2 PRUEBAS DE INTEGRACION ................................................................................................................... 85
8.3 PRUEBAS DEL SISTEMA .......................................................................................................................... 87
8.4 PRUEBAS DE IMPLANTACION................................................................................................................. 88
8.5 PRUEBAS DE ACEPTACION ..................................................................................................................... 89
8.6 PRUEBAS DE REGRESION ....................................................................................................................... 90
CAPITULO 9 .....................................................................................................................................................92
9 IMPLANTACIÓN DEL SISTEMA................................................................................................................... 92
9.1 DEFINICION DEL PLAN DE IMPLANTACION ............................................................................................. 92
9.2 CAPACITACION ...................................................................................................................................... 93
9.3 MANUAL DE INSTALACION .................................................................................................................... 93
9.4 MANUAL DEL USUARIO ......................................................................................................................... 94
CAPITULO 10 ...................................................................................................................................................95
10 MANTENIMIENTO DEL SISTEMA ............................................................................................................. 95
Unidad de Tecnologías de Información
165
Metodología MDS-α
CAPITULO 11 ...................................................................................................................................................98
11 PLAN DE ASEGURAMIENTO DE LA CALIDAD ............................................................................................ 98
11.1 CALIDAD DEL SOFTWARE ..................................................................................................................... 98
11.1.1 Obtención de Software con Calidad .................................................................................................. 99
11.1.2 Determinación de Calidad del Software ............................................................................................ 99
11.2 PLAN DE LA CALIDAD ..........................................................................................................................100
11.2.1 Alcance del Plan de Calidad .............................................................................................................100
11.2.2 Objetivos de Calidad ........................................................................................................................101
Esenciales..............................................................................................................................................101
Esperados .............................................................................................................................................101
Deseados ..............................................................................................................................................101
11.2.3 Procesos del Aseguramiento de Calidad...........................................................................................102
11.2.4 Guías para las actividades del Aseguramiento de Calidad del Software.............................................102
11.2.4.1 Guía para la Administración ..........................................................................................................103
11.2.4.2 Guía para la Documentación .........................................................................................................103
11.2.4.3 Guía para la Adherencia a los Estándares. .....................................................................................104
ANEXO 1......................................................................................................................................................... 106
ARBOL CAUSA Y EFECTO.............................................................................................................................106
DETERMINACION DEL PROBLEMA ..............................................................................................................106
CAUSAS DEL PROBLEMA.............................................................................................................................107
EFECTOS DEL PROBLEMA ...........................................................................................................................107
CONSTRUCCION DEL ARBOL .......................................................................................................................107
EL ARBOL DE OBJETIVOS ............................................................................................................................108
ANEXO 2......................................................................................................................................................... 111
PROCESOS Y PROCEDIMIENTOS..................................................................................................................111
MAPEO DE PROCESOS, OPERACIONES Y PROCEDIMIENTOS ........................................................................111
LLENADO DEL FORMULARIO N° 4 ...............................................................................................................112
INTEGRACIÓN DE PROCESOS Y OPERACIONES ............................................................................................113
LLENADO DEL FORMULARIO N° 5 ...............................................................................................................113
PROCEDIMIENTOS......................................................................................................................................114
LLENADO DEL FORMULARIO N° 6 ...............................................................................................................115
DIAGRAMA DE FLUJOS ...............................................................................................................................116
Simbología para elaborar un diagrama de flujo:..........................................................................................117
Ejemplo de diagrama de flujo – Procedimiento...........................................................................................118
ANEXO 3......................................................................................................................................................... 119
BENEFICIOS Y COSTOS ................................................................................................................................119
BENEFICIOS................................................................................................................................................119
Ahorro de Horas Hombre ...........................................................................................................................119
Aumento de productividad ........................................................................................................................119
Ahorro en alquileres de oficinas .................................................................................................................120
Ahorro en costos de operación...................................................................................................................120
Mejoras en la gestión y en la toma de decisiones .......................................................................................121
COSTOS .....................................................................................................................................................121
Unidad de Tecnologías de Información
166
Metodología MDS-α
ANEXO 4......................................................................................................................................................... 122
MATRIZ DE MARCO LOGICO .......................................................................................................................122
FIN .............................................................................................................................................................123
PROPOSITO ................................................................................................................................................123
COMPONENTES .........................................................................................................................................123
ACTIVIDADES .............................................................................................................................................124
INDICADORES ............................................................................................................................................124
PRESUPUESTO ...........................................................................................................................................125
MEDIOS DE VERIFICACIÓN .........................................................................................................................125
SUPUESTOS................................................................................................................................................125
LOGICA DE LA MATRIZ DE MARCO LOGICO .................................................................................................125
DETERMINACION DE LOS OBJETIVOS DE LA MATRIZ DE MARCO LOGICO ....................................................126
ANEXO 5......................................................................................................................................................... 129
HERRAMIENTAS DE LA INGENIERÍA DE REQUERIMIENTOS ..........................................................................129
Entrevistas y Cuestionarios ........................................................................................................................129
Sistemas Existentes....................................................................................................................................130
Grabaciones de Video y Audio....................................................................................................................131
Brainstorming (tormenta de ideas) .............................................................................................................131
Arqueología de Documentos ......................................................................................................................132
Aprendiz ....................................................................................................................................................133
Observación...............................................................................................................................................133
Run Use Case WorkShop ............................................................................................................................133
Prototipos..................................................................................................................................................134
Análisis FODA.............................................................................................................................................135
Modelado Conceptual................................................................................................................................136
Diagrama de Pescado.................................................................................................................................136
Glosario .....................................................................................................................................................138
Lista de Requerimientos.............................................................................................................................138
Checklist ....................................................................................................................................................139
ANEXO 6......................................................................................................................................................... 140
ESTILOS ARQUITECTÓNICOS .......................................................................................................................140
Estilo de Arquitectura de Tuberías y Filtros.................................................................................................144
Estilo de Arquitectura de Pizarra ................................................................................................................145
Estilo de Arquitectura de Programa Principal/Subprograma .......................................................................146
Estilo de Arquitectura Orientada a Objetos.................................................................................................146
Estilo de Arquitectura en Capas..................................................................................................................147
Estilo de Arquitectura Cliente Servidor .......................................................................................................147
Estilo de Arquitectura de Máquina Virtual o Intérprete ..............................................................................148
Estilo de Arquitectura de Control de Procesos ............................................................................................148
Estilo de Arquitectura Modelo Vista Controlador........................................................................................149
ANEXO 7......................................................................................................................................................... 150
NORMALIZACION DE BASES DE DATOS .......................................................................................................150
TERMINOLOGÍA RELACIONAL .....................................................................................................................150
DEPENDENCIA FUNCIONAL ........................................................................................................................151
Axiomas de Armstrong ...............................................................................................................................152
FORMAS NORMALES ..................................................................................................................................153
Unidad de Tecnologías de Información
167
Metodología MDS-α
Primera Forma Normal - 1FN......................................................................................................................153
Segunda Forma Normal – 2FN ....................................................................................................................155
Tercera Forma Normal – 3FN .....................................................................................................................155
Forma Normal de Boyce - Codd - FNBC ......................................................................................................156
Cuarta Forma Normal - 4FN........................................................................................................................157
Quinta Forma Normal - 5FN .......................................................................................................................157
BIBLIOGRAFÍA................................................................................................................................................. 158
Unidad de Tecnologías de Información
168