Metodología de Desarrollo de Sistemasmedios.economiayfinanzas.gob.bo/SP/documentos/... · Las...

Metodología de Desarrollo de Sistemas ALFA

MDS-αMinisterio de Economía y Finanzas Públicas - BoliviaUnidad de Tecnologías de Información - UTIControl de Calidad y Seguridad Informática - CCSI

2009

VERSION 1.0

Metodología de Desarrollo de Sistemas ALFA

MDS-α

Ministerio de Economía y Finanzas Públicas - BoliviaUnidad de Tecnologías de Información - UTIControl de Calidad y Seguridad Informática - CCSI

VERSION 1.0

Copyleft 2009 – UTI – Licencia Abierta

Todo el material escrito en el presente documento se encuentra bajo licencia deDocumentación Libre GNU, por lo tanto es libre de copiar, distribuir, modificar y ajustar estetexto de manera conveniente. La licencia puede ser consultada en la dirección webhttp://www.gnu.org/copyleft/copyleft.es.html y otras referencias pueden encontrarse enhttp://es.wikipedia.org/wiki/Copyleft

http://www.gnu.org/copyleft/copyleft.es.html

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-α

Unidad de Tecnologías de Información 1

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

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

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.

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.

Graf. I-1: Aplicación Lineal

Cap. 1 y 2 Cap. 3 Cap. 4 Cap. 11 Cap. 5

Cap. 6Cap. 7Cap. 8Cap. 9Cap. 10

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.

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.

Cap. 1 y 2 Cap. 3 Cap. 4 Cap. 11 Cap. 5

Cap. 6Cap. 7Cap. 8Cap. 9Cap. 10

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.

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.

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.

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.

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

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

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.

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

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.

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.

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:

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:

Preinversión

Inversión

Operación

Metodología MDS-α


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.

Generación y análisis de la idea de proyecto

Estudio del perfil

Estudio de prefactibilidad

Estudio de factibilidad

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.

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:

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.

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

Metodología MDS-α


La norma ISO/IEC 122074 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

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

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, elcual se intenta solucionar mediante la intervención del proyecto utilizando una relación de tipo causa-efecto.

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

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:

Metodología MDS-α


ALTERNATIVACRITERIOS

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.

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:

ACTIVIDADESTIEMPO

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 paradiferentes tareas o actividades.

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.

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.

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.

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.

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.

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:

Graf. 3-1: Proceso de la Ingeniería de Requerimientos

Necesidades delos usuarios,información deldominio,información desistemasexistentes,estándares deregulación, etc.

Documento deRequerimientos

Especificacionesdel Sistema

RequerimientosAcordados

Análisis deRequerimientos

Documentación deRequerimientos

Validación deRequerimientos

Extracción deRequerimientos

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.

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

Extracción

Análisis

Documentación

Validación

Metodología MDS-α


en la planificación de las actividades sea tomado en cuenta la definición de los requerimientos de

software.

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

Planificación/Extracción

Análisis

DocumentaciónValidación

Inicio

Punto dedecisión

EspecificaciónInformal

RequerimientosAceptados

EspecificaciónPreliminar

EspecificaciónFinal/ Reportede Validación

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.

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.

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.

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

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)

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.

SistemaRV

CLIENTE

VENDEDORBANCO

CONTABILIDAD

ALMACENOrden de Venta

Rechazo

Lista de Productos

Confirmación de laLista de Productos

Registro de TransacciónDepósito

ComisiónPago

Facturación

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

Metodología MDS-α


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.

<<include>>

HacerPedido

Hacer PedidoUrgente

ValidarCliente

<<extend>>(Establecer Prioridad)

Cliente

Verificacióndel Stock

Facturación

Comisión

Vendedor

Departamento deContabilidad

<<include>>

Metodología MDS-α


Creado por: Daniel Abasto Modificado por:Fecha de Creación: 18 de Diciembre de 2008 Fecha de modificación:

Nombre: CU-001/Hacer PedidoActor: Cliente

Descripción:Describe el proceso de pedir la venta de algún producto por parte delcliente

Flujo principal:

Eventos Actor Eventos Sistema1.- Pide datos generales del cliente

2.- Introduce datos personales. 3.- <<include>> Validar Cliente4.- Identifica al cliente por primeravez y lo registra.5.- Muestra su lista de productos ala venta

6.- Selecciona los productos y lacantidad de los mismos.

7.- <<include>> Verifica Stock ypone a la cola el pedidoidentificando al vendedor que loatenderá.8.- Reinicia el Caso de Uso.

Alternativa:

Eventos Actor Eventos Sistema1.- Pide datos generales del cliente

2.- Introduce datos personales. 3.- <<include>> Validar Cliente4.- Identifica a la persona comocliente de la empresa.5.- Muestra su lista de productos ala venta

6.- Selecciona los productos y lacantidad de los mismos.

7.- <<include>> Verifica Stock yprioriza el pedido de acuerdo a lajerarquía del cliente e identifica alvendedor que lo atenderá.8.- Reinicia el Caso de Uso.

Precondición: 1.- El cliente solicita utilización del sistema.Pos condición: 1.- Aceptación del pedido del cliente.

Presunción:1.- Disponibilidad del cliente a introducir por sistema los datos pedidos.2.- Sistema habilitado con disponibilidad de la Base de Datos.

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.

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 8307.

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

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

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.

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 deEspecificación

Detalle de la EspecificaciónRequerimientoRelacionado

Caso de UsoRelacionado

ESP-001 ….. RF-001 CU-001ESP-002 ….. RF-001

RF-003CU-001

ESP-003 ….. RF-004 CU-001CU-002

ESP-004 ….. RF-004 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.

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.

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.

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.

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.

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.

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.

Definición: Según la IEEE-Std 1471-2000, la Arquitectura del Software es laorganización fundamental de un sistema formada por sus componentes, lasrelaciones entre ellos y el contexto en el que se implantarán, y los principiosque orientan su diseño y evolución.

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

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:

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

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.

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.

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

Metodología MDS-α


El siguiente gráfico muestra la Arquitectura de Software del Navegador Mozilla

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.

Spider-Monkey

ExpatNecko

User Interface

Browser Engine Interface

Rendering Engine Interface

User Interface

UI Toolkit (XPFE)

Gecko

Use

r, S

ecur

e, B

row

ser

Pers

ist

GTK +Adapter

SecurityNSS/PSM

GTK+ /X11 Libraries

Networking

JavaScriptInterpreter

XML Parser

Display Backend

Dat

a Pe

rsis

tenc

e

Metodología MDS-α


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.

URL Server Crawler Store ServerServer

Anchor

URL Resolver Indexer Repository

Barrels Lexicon

Searcher

Sorter

Doc Index

Page RangeServer

Links

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

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 Investigador - Organismo ObservacionesAcme Monroe & Garlan (CMU), Wile (USC) Lenguaje de intercambio de ADLsAesop Garlan (CMU) ADL de propósito general, énfasis en estilosArTek Terry, Hayes-Roth, Erman (Teknowledge,

DSSA)Lenguaje específico de dominio - No es ADL

Armani Monroe (CMU) ADL asociado a AcmeC2 SADL Taylor/Medvidovic (UCI) ADL específico de estiloCHAM Berry / Boudol Lenguaje de especificaciónDarwin Magee, Dulay, Eisenbach, Kramer ADL con énfasis en dinámicaJacal Kicillof , Yankelevich (Universidad de

Buenos Aires)ADL - Notación de alto nivel para descripción yprototipado

LILEANNA Tracz (Loral Federal) Lenguaje de conexión de módulosMetaH Binns, Englehart (Honeywell) ADL específico de dominioRapide Luckham (Stanford) ADL & simulaciónSADL Moriconi, Riemenschneider (SRI) ADL con énfasis en mapeo de refinamientoUML Rumbaugh, Jacobson, Booch (Rational) Lenguaje genérico de modelado – No es ADLUniCon Shaw (CMU) ADL de propósito general, énfasis en

conectores y estilosWright Garlan (CMU) ADL de propósito general, énfasis en

comunicaciónxADL Medvidovic, Taylor (UCI, UCLA) ADL basado en XML

Tabla 5-2: Principales Lenguajes de Descripción Arquitectónica/ADLs

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

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.

Graf. 6-2: Diagrama Entidad Relación (E-R)

CI

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 año duración tipoLa Bicicleta de los Huanca 1995 145 AMi Socio 1972 136 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)

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).

Graf. 6-4: Formas Normales

5FN

4FN

BCFN

3FN

2FN

1FN

http://es.wikipedia.org/wiki/Redundancia

http://es.wikipedia.org/wiki/Integridad

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.

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

xml_error

(n:1)

(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

tipo_parametro

(n:1)

(n:1)

servicios Tabla Servicios de la empresa definidos por unacomponente y una operación

grupo_servicios

parametros

(n:1)

(1:n)

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 unerror 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.

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 tablaservicios

resultado char 1 ‘A’ = Estado inicial Estado actual de la auditoría

fecha_hora smalldatetime 4 fecha y hora actual Para registro temporal de laauditoria

tiempo int 2 0 = Cero Duración de la auditoría enminutos

descripcion_error varchar 250 NULL Para el registro detallado delerror

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

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.

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, ….

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.

Metodología MDS-α


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

después (con indentación)

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:

$nombreTemporal = $_FILES['archivo']['nombreTemporal'];

$tamanoArchivo = $_FILES['archivo']['tamano'];

$nombreReal = $_FILES['archivo']['nombre'];

$nombreTemporal = $_FILES['archivo']['nombreTemporal'];

$tamanoArchivo = $_FILES['archivo']['tamano'];

$nombreReal = $_FILES['archivo']['nombre'];

$sitio->configuracion("cabecera" , $cabecera);

$sitio->configuracion("menu" , $menu);

$sitio->configuracion("descripcion" , $descripcion);

$sitio->configuracion("titulo" , $titulo);

Class HolaMundo

{

public metodo()

{

if(condicion)

{

………

}

}

}

llaves en nueva linea

1 Tab

2 Tab

3 Tab

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.

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

Class HolaMundo

{

public metodo()

{

if(condicion)

{

valor1 = 1;

valor2 = 2;

}

}

}

salto de línea

Metodología MDS-α


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).

Class HolaMundo

{

public metodo(parametro1, parametro2)

{

//comentarioA

if(condicionA)

{

valor1 = 1;

valor2 = 2;

}

//comentarioB

if(condicionB)

{

valorB = 1 + valor1 ;

}

}

}

Después de una coma

separar operadores

separación de código

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:

Metodología MDS-α


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.

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

function funcionCalculoEjemplo($entrada, $salida){

$entrada = $entrada + funcionOtroCalculo($entrada);$entrada = $entrada + ($entrada / 2);…………..$salida = $entrada;

}

function funcionEjemplo($codigoBarra){

$codigoBarra = trim(strtoupper($codigoBarra));…………..

}

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

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:

§ 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:

/*********************************************************** ** Esta es una función que calcula la depreciación de los activos ** mediante el método de línea recta ** ************************************************************/

Metodología MDS-α


§ 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

//se busca el caracter delimitador para determinar el parrafowhile(corriente.cadena(posicion) != CARACTER_DELIMITADOR ){

……}

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'";

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.

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.

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:

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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 deAseguramiento de Calidad:

Código:

Proyecto/Sistema:

Administrador delProyecto/Sistema:

Versión del Documento:

Preparado por: Fecha de Preparación:

Nº Control de Versión Revisado por Fecha Descripción

Tabla 11-1: Encabezado del Plan de Aseguramiento de la Calidad

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 Actividad Detalle / Indicación

1 Criterios de

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

participara en el Aseguramiento de

Calidad del Software.

§ Definir responsabilidades a cada

integrante.

Verificar la consistencia entre los

participantes del Control de Calidad y el Plan

Administración del Software.

3 Criterios de Salida Esquema especifico de los participantes del

Control de Calidad.

Estructura del Control de Calidad óptima para

el proyecto.

Tabla 11-2: Tabla guía para la Administración

11.2.4.2 Guía para la Documentación


1 Criterios de

Entrada

Plan de Administración del Proyecto de

Software.

2 Revisión § Revisión y análisis del plan dedocumentación.

§ Buscar discrepancias.§ Discutir discrepancias con el o los

responsables del proyecto.

§ Reportar discrepancias

§ Enviar discrepancias correspondientes a

los respectivos responsables

3 Criterios de Salida Documentación revisada. Documento de acuerdo a estándares y sin

discrepancias.

Tabla 11-3: Tabla guía para la Documentación

Metodología MDS-α


11.2.4.3 Guía para la Adherencia a los Estándares.


1 Criterios de Entrada Documento de Requerimientos y

Especificaciones del Software,

Documento de Arquitectura del

Software, Documento del Diseño del

Sistema, etc.

2 Documentación Monitorear la adherencia de losdocumentos a los estándares.

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

acuerdo a los estándares.

El diseño estará enmarcado en las

diferentes herramientas citadas en la

metodología (MDS-ALFA) de acuerdo a

su tipo (Estructurado, Orientado a

Objetos, etc.)

4 Codificación Monitorear la adherencia de la

codificación a la convención establecida

en la Metodología ALFA.

La Codificación estará enmarcada de

acuerdo a la Convención de Codificación

definida en la Metodología MDS-ALFA.

5 Comentarios/Documentación

Interna

Monitorear la adherencia de los

Comentarios y la Documentación Interna

de acuerdo la convención establecida en

la Metodología ALFA.

Los Comentarios y la Documentación

Interna del Sistema estará enmarcado

bajo las convenciones de codificación

defina en la Metodología MDS-ALFA.

6 Prueba Monitorear la adherencia de las pruebas

de acuerdo a los estándares.

Revisar de acuerdo a los estándares

citado en la Metodología MDS-ALFA.

7 Métricas Revisar la métrica definida Revisar la o las métricas de acuerdo a los

diferentes atributos de calidad

propuestos.

8 Conformidad Monitorear la conformidad que existe en

el sistema.

Revisar documentos de conformidad del

sistema.

9 Criterios de Salida § 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 ysolucionadas.

§ Documentos de acuerdo a losestándares.

Tabla 11-4: Tabla guía para la adherencia a los Estándares

Metodología MDS-α


ANEXOS

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"

8 Lluvia de ideas - Brainstorming, conocido también como tormenta de ideas, es una herramienta de trabajogrupal que facilita el surgimiento de nuevas ideas sobre un tema o problema determinado.

Problema CentralLimitado tratamiento de la informaciónde los funcionarios de la institución.

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.

Metodología MDS-α


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.

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.

Problema CentralLimitado tratamiento de la

información de losfuncionarios de la institución

Objetivo GeneralMejorar el tratamiento de la

información de losfuncionarios de la institución

CAU

SAS

EFEC

TOS

PROBLEMA CENTRALLimitado tratamiento de

la información de losfuncionarios de la

institución

Información inadecuada Demora en elprocesamiento de datos

Capacidad limitada de losequipos de computación

Limitado control delprocesamiento de

información

Computadoras obsoletas Mantenimiento limitado

Falta de fiabilidad de losdatos procesados

Desconfianza en laadministración del

Recurso Humano de lainstitución

Limitada aplicación de lasnormas

Limitada aplicación de losdiferentes procesos y

procedimientos

Metodología MDS-α


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 demantenimiento

Aplicación correcta de lasnormas

Mejor aplicación de losdiferentes procesos y

procedimientos

MED

IOS

FIN

ES

OBJETIVO GENERALMejorar el tratamiento de

la información de losfuncionarios de la

institución

Información adecuada Procesamiento de datosoportuna

Mejorar los equipos decomputación

Mayor control delprocesamiento de

información

Computadoras adecuadas Amplia cobertura demantenimiento

Datos procesados deforma correcta

Confianza en laadministración del

Recurso Humano de lainstitución

Aplicación correcta de lasnormas

Mejor aplicación de losdiferentes procesos y

procedimientos

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

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ÓDIGOPROCESO

PROCESOSCÓDIGO

OPERACIÓNOPERACIONES

CÓDIGOPROCED.

PROCEDIMIENTOS

Form. 04: Formulario de mapeo de procesos, operaciones y procedimientos

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.:

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 OPERACIONESNOMBRE DEL PROCESO: CÓDIGO:OBJETIVO:UNIDAD RESPONSABLE DEL PROCESO:PRODUCTOS DEL PROCESO:

OPERACIONES COMPONENTES DEL PROCESOCÓDIGO OPERACIÓN RESPONSABLES PRODUCTO TIEMPO DÍAS

TOTAL TIEMPO DE EJECUCIÓN DEL PROCESOForm. 05: Formulario de integración de procesos y operaciones


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.

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

PROCEDIMIENTOSNOMBRE DEL PROCEDIMIENTO: CÓDIGO: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 TAREASPUESTO

RESPONSABLEFORMAS

FORMULARIOS

Form. 06: Formulario de procedimientos

Metodología MDS-α



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.

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.

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ónDentro del símbolo se deberá anotar “INICIO” o “FIN”, de acuerdo al principio oconclusión del procedimiento, según corresponda.

Describe de manera telegráfica, las tareas que desempeña el personal involucradas enel procedimiento, en flujos de procesos representa la ejecución de operaciones.

Representa cualquier documento que entre, se genere o utilice en el proceso oprocedimiento.

Representa una tarea que genera un documento.

Indica un punto dentro del flujo en donde se debe tomar una decisión entre dosopciones o alternativas.Preferentemente se indicará la procedencia (SI) hacia la parte de abajo del símbolo y laprocedencia (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.

1Representa la conexión o enlace de una parte del diagrama de flujo con otro parte delmismo, en la misma hoja. Se utiliza para unir actividades cuando el espacio en eldiagrama es limitado y sirve para evitar cruzar las líneas de dirección de flujo.

Va a página óViene depágina

Representa la conexión o enlace de una parte del diagrama de flujo con otro parte delmismo, 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. Enlos casos que no sea posible conectar con líneas rectas, se utilizarán ángulos rectos. Laslí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

Metodología MDS-α


Ejemplo de diagrama de flujo – Procedimiento

Graf. A-2-4: Simbología de diagramas de flujo

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:

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

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.

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.

Graf. A-4-1: Ciclo de vida del proyecto

Problema

Identificación

Desarrollo deAlternativas

Evaluación

AlternativaSeleccionada

FORMULACION

EJECUCION

El Proyecto

OPERACION

FIN PROPOSITO COMPONENTESS

ACTIVIDADES

Metodología MDS-α


La estructura del marco lógico está definida como sigue:

OBJETIVOSINDICADORES

MEDIOSVERIFICABLES

SUPUESTOSENUNCIADO - META

FORMULA DECALCULO

FINPROPOSITOCOMPONENTESACTIVIDADES

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

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:

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: 100*1*DB

Aia =

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.

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).

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.

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

FIN

PROPOSITO

COMPONENTES

ACTIVIDADES

FIN

PROPOSITO

COMPONENTES

ACTIVIDADES

SUPUESTOS

SUPUESTOS

SUPUESTOS

SUPUESTOSmás

entonces

si

más

entonces

si

más

entonces

si

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.

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

OBJETIVOSINDICADORES

MEDIOSVERIFICABLES

SUPUESTOSENUNCIADO - META

FORMULA DECALCULO

FINInformación del RecursoHumano de lainstitución, administradaeficientemente

El porcentaje de registrode información es mayoral 95%

100*B

Ari =

A = Cantidad defuncionarios registrados

B = Total de funcionariosde la institución

Registros actualizados enel área de Escalafón.

La unidad de RRHH creauna culturaadministrativa positiva acerca del procesamientode información personalde la institución.

PROPOSITOTratamiento mejoradode la información de losfuncionarios de lainstitución

El porcentaje deInformación actualizadasupera el 90% en eltiempo

1001

*D

*B

Aia =

A = Cantidad defuncionarios coninformación completa aldía

B = Total de funcionariosde la institución

D = Cantidad de días dedemora

Informes de control depersonal.

Registros dememorándums.

Dotación de credenciales

Generación de planillaspresupuestarias

Los funcionarios de lainstitución dotanoportunamente loscorrespondientes datosde su persona.

Fin

Propósito

Compo-nentes

Activi-dades

Objetivo Central

Metodología MDS-α


COMPONENTES1: Equipos decomputación mejorados

2: Control delprocesamiento deinformaciónperfeccionado

El número de equiposadquiridos superan el50% en la Unidad deRR.HH.

El porcentaje deaplicación de la normaSAP es superior al 80%

100*B

Aea =

A = Cantidad de equiposnuevos

B = Total de equipos enRR.HH.

100*B

Aan =

A = Cantidad deProcesos ejecutados

B = Cantidad total deprocesos definidos en laNorma SAP

Facturas de compra.

Reporte de asignaciónde activos

Manual de procesos yprocedimientos.

Base de Datosconsolidada para RR.HH.

Personal conconocimientos encomputación ycapacitado en la NormaSAP

ACTIVIDADES1: Adquisición deComputadoras

2: Cobertura deMantenimiento

3: Estandarización de lasactividades según norma

4: Automatización deprocesos yprocedimientos

PRESUPUESTOBs. 160.000

Bs. 35.000

Bs. 75.000

Bs. 260.000

Costo Total Bs. 530.000

100*B

Aejecucion =

A = Costo ejecutado enun determinado tiempo

B = Costo Total delproyecto

Informe financiero.

Informes mensuales decapacitación,mantenimiento, etc.

Documentación dedesarrollo de sistemas.

Equipamientocomputacionaldisponible en elmercado.

Norma SAP actualizado.

Disposición de tiemposegún cronograma depersonal en la Unidad deTecnologías deInformación

Matriz A-4-1: Matriz de Marco Lógico

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:

HerramientasActividades

Extracción Análisis Documentación ValidaciónEntrevistas y Cuestionario XSistemas existentes X XGrabaciones de Video y Audio X XBrainstorming (tormenta de ideas) X XArqueología de Documentos X XAprendiz XObservación XRun Use Case WorkShop XPrototipo Bosquejado X X XPrototipo Tangible/Usable X X XFODA XModelo Conceptual X XDiagrama de Pescado X X XGlosario X X X XLista de Requerimientos X X X XChecklist X X

Tabla A-5-1: Herramientas de la Ingeniería de Requerimientos

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

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.

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

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?

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

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.

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.

Pos

itiv

o

Interno

N

egat

ivo

Fortalezas Debilidades

Oportunidades Amenazas

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

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.

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.

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.

Control depersonal

insuficiente

funcionariosentorno

equipos decomputaciónproceso

manual obsoleto

sobrecargalaboral

demasiadosdatos

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.

Metodología MDS-α


La plantilla a utilizar es la siguiente:

REQUERIMIENTOS NO FUNCIONALESCódigo DescripciónRNF-001RNF-002RNF-003RNF-XYZ

Tabla A-5-3: Plantilla para la descripción de Requerimientos No Funcionales

REQUERIMIENTOS FUNCIONALESCódigo DescripciónRF-001RF-002RF-003RF-XYZ

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 RespuestaPregunta - 01Pregunta - 02Pregunta - 03Pregunta - XY

Tabla A-5-5: Plantilla para la lista de verificación de requerimientos

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

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.

Metodología MDS-α


Graf. A-6-1: Arquitectura de Software de un Video Juego

Graf. A-6-2: Arquitectura de Software de un Compilador

AnalizadorSintáctico

AnalizadorSemántico

Optimizador

Generaciónde Código

Parser

Secuencial

AnalizadorSintáctico

Parser AnalizadorSemántico

Representación Interna

Paralelo

Metodología MDS-α


Graf. A-6-3: Arquitectura de Software de una Herramienta CASE

Graf. A-6-4: Arquitectura de un Intérprete implementada en Maquina Virtual

Graf. A-6-5: Arquitectura de un Sistema de Vigilancia

Datos (Estadodel Programa)

Programasiendo

interpretado

Maquina deInterpretación

Simulada

EstadoInterno delInterprete

Sensores

AdquisiciónDatos deVigilancia

PreparaciónProceso de

Entrada

SeguimientoMono

FusiónHorizontal

Vertical

Control deCalidad

Tiempo RealGestión de

Pistas

Distribuciónde Datos de

Vigilancia

Seguridadde la Red

Control deSeguimiento

Monitoreo

Correlación

Grabación

Dispositivos

Repositorio del Proyecto

Editor deDiseño

Generadorde Código

Editor delPrograma

Generadorde Reportes

Análisis yDiseño

Traductordel Diseño

Metodología MDS-α


Graf. A-6-6: Arquitectura de Referencia del Modelo Estándar OSI

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.

Cliente 2Cliente 1 Cliente 3 Cliente 4

Servidor deHipertexto

Servidor deGráficos

Servidor deVideo

Servidor deCatálogos

Red de Banda Ancha

Aplicación

Presentación

Sesión

Transporte

Red

Enlace

Física

Metodología MDS-α


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.

Graf. A-6-9: Estilo Arquitectónico de Pizarra

Filtro Filtro Filtro Filtro

FiltroFiltroFiltro

Filtro

Filtro Filtro

Filtro Filtro Filtro Filtro

Tuberías

b) Batch Secuencial

a) Tuberías y Filtros

Pizarra

Cliente 1 Cliente 2

Cliente 3

Cliente 4Cliente 5

Cliente 6

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.

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

Graf. A-6-11: Estilo de Arquitectura Orientada a Objetos

P

a b c

d e f g h

i j k l m n o

Obj 1Atributos

Métodos

Obj 2Atributos

Métodos

Obj 3Atributos

Métodos

Obj 4Atributos

Métodos

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

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.

Graf. A-6-13: Estilo de Arquitectura Cliente Servidor

Capa

1

Capa

2

Capa

3

Capa

4

Cliente 2Cliente 1 Cliente 3 Cliente 4

Servidor 4Servidor 3Servidor 2Servidor 1

Red de Comunicación

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

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.

Estado delPrograma

Memoria conCódigo a

Interpretar

Simulación de laInterpretación

Estado de laInterpretación

Metodología MDS-α


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.

Graf. A-6-16: Estilo de Arquitectura Modelo Vista Controlador

Control Proceso Sensor 1 Sensor 2

Modelo

Vista Controlador

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.

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/wiki/Modelo_E-R

http://es.wikipedia.org/wiki/Modelo_relacional

http://es.wikipedia.org/wiki/Redundancia

http://es.wikipedia.org/wiki/Integridad

http://es.wikipedia.org/wiki/Tabla_(base_de_datos)

http://es.wikipedia.org/wiki/Fila_(base_de_datos)

http://es.wikipedia.org/wiki/Columna_(base_de_datos)

http://es.wikipedia.org/wiki/Archivo:TablaRelacional2.png

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:

http://es.wikipedia.org/wiki/Tabla_(base_de_datos)

http://es.wikipedia.org/wiki/Registro_(base_de_datos)

http://es.wikipedia.org/wiki/Columna_(base_de_datos)

Metodología MDS-α


§ B depende funcionalmente de A

o que es lo mismo:

§ A determina el valor de 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 tidadcarnetIdennombre Í , entonces nombretidadcarnetIden ®

A2: Dependencia Funcional Incremental

Si Xà Y, entonces X, Zà Y, Z

Por ejemplo:

A B

A B

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.

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.

FUNCIONARIOcod_funcionario nombre puesto salario emails111 Juan Pérez Miranda Jefe de Unidad 12000 [email protected]; [email protected] José Duran Chambi Administrativo 3000 [email protected] Ana María Díaz Cabero Administrativo 3000 [email protected]; [email protected]... ... ... ... ...

No está en Primera Forma Normal – 1FN(X)

Solución 1

FUNCIONARIOcod_funcionario nombres paterno materno puesto salario emails111 Juan Pérez Miranda Jefe de Unidad 12000 [email protected] Juan Pérez Miranda Jefe de Unidad 12000 [email protected] José Duran Chambi Administrativo 3000 [email protected] Ana María Díaz Cabero Administrativo 3000 [email protected] Ana María Díaz Cabero Administrativo 3000 [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

FUNCIONARIOcod_funcionario nombres paterno materno puesto salario111 Juan Pérez Miranda Jefe de Unidad 12000222 José Duran Chambi Administrativo 3000333 Ana María Díaz Cabero Administrativo 3000... ... … … ... ...

Si está en Primera Forma Normal – 1FN y su llave primaria es (cod_funcionario)

Metodología MDS-α


EMAILemail [email protected] [email protected] [email protected] [email protected] [email protected] 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).

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:

FUNCIONARIOcod_funcionario nombres paterno materno puesto111 Juan Pérez Miranda Jefe de Unidad222 José Duran Chambi Administrativo333 Ana María Díaz Cabero Administrativo... ... … … …

Si está en Tercera Forma Normal – 3FN y su llave primaria es (cod_funcionario) con llave foránea

(puesto) a la Tabla PUESTO.

PUESTOpuesto salarioJefe de Unidad 12000Administrativo 3000... ...

Si está en Tercera Forma Normal – 3FN y su llave primaria es (puesto)

EMAILemail [email protected] [email protected] [email protected] [email protected] [email protected] 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.

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.

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

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.

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.

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.

Metodología MDS-α


CONTENIDO

INTRODUCCIÓN ................................................................................................................................................. 1

METODOLOGÍAS ........................................................................................................................................... 1METODOLOGÍA DE DESARROLLO DE SISTEMAS ALFA (MDS-α) ....................................................................... 1ORGANIZACION ............................................................................................................................................ 2APLICACIÓN METODOLÓGICA ....................................................................................................................... 4Aplicación Lineal ........................................................................................................................................... 4Aplicación Cíclica........................................................................................................................................... 5Aplicación Iterativa por Fases ........................................................................................................................ 5Guía Rápida de la Metodología ALFA ............................................................................................................. 6

CAPITULO 1 .....................................................................................................................................................10

1 BASES DE UN PROYECTO DE DESARROLLO DE SISTEMAS ........................................................................... 101.1 GENERALIDADES ................................................................................................................................... 121.1.1 EVOLUCION DE LOS PROYECTOS EN TECNOLOGIAS DE INFORMACION ................................................ 121.1.2 FUNDAMENTOS PARA LA ADOPCION DEL CRITERIO COSTO-EFICIENCIA .............................................. 131.1.3 CRITERIOS DE APROBACION O RECHAZO DE PROYECTOS EN TECNOLOGIAS DE INFORMACION ........... 141.2 CICLO DE PROYECTOS DE DESARROLLO DE SISTEMAS ............................................................................ 141.3 PROYECTOS DE INVERSION .................................................................................................................... 151.3.1 CICLO DE VIDA DE LOS PROYECTOS ..................................................................................................... 151.3.1.1 ESTADO DE PREINVERSION .............................................................................................................. 16Etapa de generación y análisis de la idea de proyecto .................................................................................. 17Etapa de estudio del perfil .......................................................................................................................... 18Etapa de estudio de prefactibilidad ............................................................................................................. 18Etapa de estudio de factibilidad .................................................................................................................. 191.4 TIPOS DE PROYECTOS INFORMATICOS ................................................................................................... 19

CAPITULO 2 .....................................................................................................................................................21

2 PREPARACION DEL PROYECTO DE DESARROLLO DE SISTEMAS .................................................................. 212.1 CARATULA Y TABLA DE CONTENIDOS ..................................................................................................... 222.2 RESUMEN EJECUTIVO ............................................................................................................................ 222.3 PLAN O POLITICA INSTITUCIONAL SOBRE TECNOLOGIAS DE INFORMACION ........................................... 232.4 DEFINICION DEL PROBLEMA .................................................................................................................. 242.5 DIAGNOSTICO DE LA SITUACION ACTUAL............................................................................................... 242.5.1 DESCRIPCION DE LA UNIDAD ORGANIZACIONAL ................................................................................. 242.5.2 ACTUALIDAD TECNOLOGICA ............................................................................................................... 252.5.3 DESCRIPCION DE LOS PROCESOS Y PROCEDIMIENTOS ......................................................................... 252.6 DESCRIPCIÓN GENERAL DE REQUERIMIENTOS ....................................................................................... 252.7 ESTIMACION DE BENEFICIOS ................................................................................................................. 252.8 ESTIMACION DE COSTOS ....................................................................................................................... 252.9 ALTERNATIVAS DE SOLUCION ................................................................................................................ 262.9.1 RESTRICCIONES DE CADA ALTERNATIVA ............................................................................................. 272.9.2 PRODUCTO O SERVICIO ESPERADO DE CADA ALTERNATIVA ................................................................ 272.9.3 ELECCION DE LA ALTERNATIVA ........................................................................................................... 272.10 MATRIZ DEL MARCO LÓGICO ............................................................................................................... 282.11 PLANIFICACION DE ACTIVIDADES ......................................................................................................... 28

Metodología MDS-α


CAPITULO 3 .....................................................................................................................................................29

3 REQUERIMIENTOS DE SOFTWARE............................................................................................................. 293.1 VISIÓN Y ALCANCE DEL PROYECTO ........................................................................................................ 303.1.1 PLANTILLA PARA EL DOCUMENTO DE VISIÓN Y ALCANCES DEL PROYECTO .......................................... 303.1.1.1 REQUERIMIENTOS DE NEGOCIOS ..................................................................................................... 303.1.1.1.1 Antecedentes ............................................................................................................................... 303.1.1.1.2 Oportunidades de Negocio ........................................................................................................... 303.1.1.1.3 Objetivos de Desarrollo del Sistema .............................................................................................. 313.1.1.1.4 Requerimientos del Usuario .......................................................................................................... 313.1.1.1.5 Valor proporcionado al Usuario .................................................................................................... 313.1.1.1.6 Riesgos del Sistema ...................................................................................................................... 313.1.1.2 VISIÓN DE LA SOLUCIÓN .................................................................................................................. 313.1.1.2.1 Declaración de la Visión ................................................................................................................ 323.1.1.2.2 Características Principales ............................................................................................................. 323.1.1.2.3 Dependencias y presunciones ....................................................................................................... 323.1.1.3 ALCANCE Y LIMITACIONES ............................................................................................................... 323.1.1.3.1 Alcance de la Versión Inicial .......................................................................................................... 323.1.1.3.2 Alcance de las versiones subsecuentes.......................................................................................... 323.1.1.3.3 Limitaciones y exclusiones ............................................................................................................ 333.1.1.4 CONTEXTO DEL NEGOCIO ................................................................................................................ 333.1.1.4.1 Características del usuario (Perfil) ................................................................................................. 333.1.1.4.2 Prioridades del Proyecto ............................................................................................................... 333.1.1.5 FACTORES DE ÉXITO DEL PRODUCTO ............................................................................................... 343.2 INGENIERÍA DE REQUERIMIENTOS ......................................................................................................... 343.2.1 Modelo Tradicional en Cascada .......................................................................................................... 353.2.2 Modelo en Espiral............................................................................................................................... 353.3 ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS .......................................................................... 363.3.1 Extracción .......................................................................................................................................... 363.3.2 Análisis ............................................................................................................................................... 373.3.3 Documentación .................................................................................................................................. 383.3.4 Validación .......................................................................................................................................... 383.4 HERRAMIENTAS .................................................................................................................................... 38

CAPITULO 4 .....................................................................................................................................................39

4 ESPECIFICACIONES DE SOFTWARE ............................................................................................................ 394.1 MODELADO DEL NEGOCIO .................................................................................................................... 394.2 DIAGRAMA DE CONTEXTO ..................................................................................................................... 414.3 CASOS DE USO ...................................................................................................................................... 414.3.1 Diagramas de Casos de Uso ................................................................................................................ 424.3.2 Documento de especificación de Casos de Uso ................................................................................... 434.4 DOCUMENTO DE ESPECIFICACIONES DE SOFTWARE .............................................................................. 444.4.1 Formato del Documento de Especificación de Software ...................................................................... 454.4.1.1. Introducción ................................................................................................................................... 454.4.1.1.1 Propósito ...................................................................................................................................... 454.4.1.1.2 Alcance......................................................................................................................................... 454.4.1.1.3 Definiciones, siglas y abreviaciones ............................................................................................... 464.4.1.1.4 Referencias ................................................................................................................................... 464.4.1.1.5 Resumen ..................................................................................................................................... 464.4.1.2 Descripción General ........................................................................................................................ 464.4.1.2.1 Perspectiva del Producto .............................................................................................................. 464.4.1.2.1.1 Interfaces del Sistema ................................................................................................................ 46

Metodología MDS-α


4.4.1.2.1.2 Interfaces del usuario ................................................................................................................ 464.4.1.2.1.3 Interfaces con el hardware......................................................................................................... 464.4.1.2.1.3 Interfaces con otros software .................................................................................................... 464.4.1.2.1.4 Interfaces con otros dispositivos de comunicación ..................................................................... 464.4.1.2.1.5 Operaciones .............................................................................................................................. 464.4.1.2.1.6 Requerimientos de adaptación .................................................................................................. 464.4.1.2.2 Funciones del Producto ................................................................................................................ 474.4.1.2.3 Características del Usuario ............................................................................................................ 474.4.1.2.4 Restricciones ................................................................................................................................ 474.4.1.2.5 Suposiciones y dependencias ........................................................................................................ 474.4.1.3. Especificación de Requerimientos ................................................................................................... 474.4.1.3.1 Características del Sistema............................................................................................................ 484.4.1.3.2 Especificaciones de Rendimiento .................................................................................................. 494.4.1.3.3 Restricciones de diseño ................................................................................................................ 494.4.1.3.4 Atributos del Sistema .................................................................................................................... 494.4.1.3.5 Otros requerimientos ................................................................................................................... 494.4.1.4. Acuerdo o Contrato ........................................................................................................................ 494.5 DIAGRAMA DE FLUJO DE DATOS ............................................................................................................ 50

CAPITULO 5 .....................................................................................................................................................52

5 ARQUITECTURA DEL SOFTWARE ............................................................................................................... 525.1 MODELOS DE ARQUITECTURA DE SOFTWARE ........................................................................................ 535.1.1 Modelos Estructurales ........................................................................................................................ 535.1.2 Modelos Framework .......................................................................................................................... 535.1.3 Modelos Dinámicos ............................................................................................................................ 545.1.4 Modelos de Proceso ........................................................................................................................... 545.1.5 Modelos funcionales .......................................................................................................................... 545.2 ELEMENTOS CLAVE EN LA ARQUITECTURA DE SOFTWARE ..................................................................... 545.2.1 Componentes ..................................................................................................................................... 545.2.2 Conectores ......................................................................................................................................... 555.2.3 Configuraciones / Topologías .............................................................................................................. 555.3 REPRESENTACIÓN ARQUITECTÓNICA ..................................................................................................... 555.4 ROL DEL ARQUITECTO DE SOFTWARE .................................................................................................... 575.5 FASES DE LA CONSTRUCCION DEL SOFTWARE ........................................................................................ 575.5.1 Fase 1: Pre-Diseño .............................................................................................................................. 575.5.2 Fase 2: Análisis del Dominio ................................................................................................................ 575.5.3 Fase 3: Diseño Esquemático................................................................................................................ 585.5.4 Fase 4: Desarrollo del Diseño .............................................................................................................. 585.5.5 Fase 5: Documentos del Proyecto ....................................................................................................... 585.5.6 Fase 6: Contratación o Sub-Contratación ............................................................................................ 585.5.7 Fase 7: Construcción ........................................................................................................................... 585.5.8 Fase 8: Post-Construcción ................................................................................................................... 595.6 ABSTRACCION DE LA ARQUITECTURA .................................................................................................... 595.7 ESTILOS ARQUITECTÓNICOS .................................................................................................................. 615.8 LENGUAJE DE DESCRIPCION ARQUITECTÓNICA ...................................................................................... 62

CAPITULO 6 .....................................................................................................................................................64

6 DISEÑO Y MODELAMIENTO ...................................................................................................................... 646.1 INTERFACE DE USUARIO ........................................................................................................................ 646.2 MODELO CONCEPTUAL ......................................................................................................................... 656.3 MODELO LOGICO .................................................................................................................................. 66

Metodología MDS-α


6.3.1 Normalización .................................................................................................................................... 676.4 MODELO FISICO .................................................................................................................................... 686.4.1 Diccionario de Datos........................................................................................................................... 68

CAPITULO 7 .....................................................................................................................................................71

7 IMPLEMENTACION ................................................................................................................................... 717.1 GENERACION DE CODIGO ...................................................................................................................... 727.1.1 Convenciones de Codificación............................................................................................................. 727.1.1.1 Lineamientos generales ................................................................................................................... 727.1.1.2 Codificación Camel Case .................................................................................................................. 737.1.1.3 Indentación ..................................................................................................................................... 737.1.1.4 Indentar Seteo de Variables ............................................................................................................. 747.1.1.5 Tamaño Máximo de Línea ................................................................................................................ 757.1.1.6 Saltos de Línea................................................................................................................................. 757.1.1.7 Espacios y Líneas en Blanco ............................................................................................................. 757.1.1.8 Nombres de Clases .......................................................................................................................... 767.1.1.9 Interfaces ........................................................................................................................................ 777.1.1.10 Funciones, Procedimientos y Métodos ........................................................................................... 777.1.1.11 Parámetros .................................................................................................................................... 777.1.1.12 Variables ....................................................................................................................................... 787.1.1.13 Nomenclatura de Variables ............................................................................................................ 797.1.1.14 Constantes .................................................................................................................................... 797.1.1.15 Comentarios .................................................................................................................................. 807.1.1.16 Notificación de Errores .................................................................................................................. 817.1.1.17 Nombres de Archivos ..................................................................................................................... 817.1.1.18 ESTILO DE CODIFICACIÓN .............................................................................................................. 827.1.1.18.1 Cadenas de Caracteres ................................................................................................................ 827.1.1.18.2 Concatenación de Caracteres ...................................................................................................... 82

CAPITULO 8 .....................................................................................................................................................83

8 PRUEBAS .................................................................................................................................................. 838.1 PRUEBAS UNITARIAS ............................................................................................................................. 848.2 PRUEBAS DE INTEGRACION ................................................................................................................... 858.3 PRUEBAS DEL SISTEMA .......................................................................................................................... 878.4 PRUEBAS DE IMPLANTACION ................................................................................................................. 888.5 PRUEBAS DE ACEPTACION ..................................................................................................................... 898.6 PRUEBAS DE REGRESION ....................................................................................................................... 90

CAPITULO 9 .....................................................................................................................................................92

9 IMPLANTACIÓN DEL SISTEMA ................................................................................................................... 929.1 DEFINICION DEL PLAN DE IMPLANTACION ............................................................................................. 929.2 CAPACITACION ...................................................................................................................................... 939.3 MANUAL DE INSTALACION .................................................................................................................... 939.4 MANUAL DEL USUARIO ......................................................................................................................... 94

CAPITULO 10 ...................................................................................................................................................95

10 MANTENIMIENTO DEL SISTEMA ............................................................................................................. 95

Metodología MDS-α


CAPITULO 11 ...................................................................................................................................................98

11 PLAN DE ASEGURAMIENTO DE LA CALIDAD ............................................................................................ 9811.1 CALIDAD DEL SOFTWARE ..................................................................................................................... 9811.1.1 Obtención de Software con Calidad .................................................................................................. 9911.1.2 Determinación de Calidad del Software ............................................................................................ 9911.2 PLAN DE LA CALIDAD ..........................................................................................................................10011.2.1 Alcance del Plan de Calidad .............................................................................................................10011.2.2 Objetivos de Calidad ........................................................................................................................101

Esenciales..............................................................................................................................................101Esperados .............................................................................................................................................101Deseados ..............................................................................................................................................101

11.2.3 Procesos del Aseguramiento de Calidad ...........................................................................................10211.2.4 Guías para las actividades del Aseguramiento de Calidad del Software.............................................10211.2.4.1 Guía para la Administración ..........................................................................................................10311.2.4.2 Guía para la Documentación .........................................................................................................10311.2.4.3 Guía para la Adherencia a los Estándares. .....................................................................................104

ANEXO 1 ......................................................................................................................................................... 106

ARBOL CAUSA Y EFECTO .............................................................................................................................106DETERMINACION DEL PROBLEMA ..............................................................................................................106CAUSAS DEL PROBLEMA.............................................................................................................................107EFECTOS DEL PROBLEMA ...........................................................................................................................107CONSTRUCCION DEL ARBOL .......................................................................................................................107EL ARBOL DE OBJETIVOS ............................................................................................................................108

ANEXO 2 ......................................................................................................................................................... 111

PROCESOS Y PROCEDIMIENTOS ..................................................................................................................111MAPEO DE PROCESOS, OPERACIONES Y PROCEDIMIENTOS ........................................................................111LLENADO DEL FORMULARIO N° 4 ...............................................................................................................112INTEGRACIÓN DE PROCESOS Y OPERACIONES ............................................................................................113LLENADO DEL FORMULARIO N° 5 ...............................................................................................................113PROCEDIMIENTOS......................................................................................................................................114LLENADO DEL FORMULARIO N° 6 ...............................................................................................................115DIAGRAMA DE FLUJOS ...............................................................................................................................116Simbología para elaborar un diagrama de flujo:..........................................................................................117Ejemplo de diagrama de flujo – Procedimiento...........................................................................................118

ANEXO 3 ......................................................................................................................................................... 119

BENEFICIOS Y COSTOS ................................................................................................................................119BENEFICIOS ................................................................................................................................................119Ahorro de Horas Hombre ...........................................................................................................................119Aumento de productividad ........................................................................................................................119Ahorro en alquileres de oficinas .................................................................................................................120Ahorro en costos de operación...................................................................................................................120Mejoras en la gestión y en la toma de decisiones .......................................................................................121COSTOS .....................................................................................................................................................121

Metodología MDS-α


ANEXO 4 ......................................................................................................................................................... 122

MATRIZ DE MARCO LOGICO .......................................................................................................................122FIN .............................................................................................................................................................123PROPOSITO ................................................................................................................................................123COMPONENTES .........................................................................................................................................123ACTIVIDADES .............................................................................................................................................124INDICADORES ............................................................................................................................................124PRESUPUESTO ...........................................................................................................................................125MEDIOS DE VERIFICACIÓN .........................................................................................................................125SUPUESTOS................................................................................................................................................125LOGICA DE LA MATRIZ DE MARCO LOGICO .................................................................................................125DETERMINACION DE LOS OBJETIVOS DE LA MATRIZ DE MARCO LOGICO ....................................................126

ANEXO 5 ......................................................................................................................................................... 129

HERRAMIENTAS DE LA INGENIERÍA DE REQUERIMIENTOS ..........................................................................129Entrevistas y Cuestionarios ........................................................................................................................129Sistemas Existentes ....................................................................................................................................130Grabaciones de Video y Audio ....................................................................................................................131Brainstorming (tormenta de ideas) .............................................................................................................131Arqueología de Documentos ......................................................................................................................132Aprendiz ....................................................................................................................................................133Observación ...............................................................................................................................................133Run Use Case WorkShop ............................................................................................................................133Prototipos ..................................................................................................................................................134Análisis FODA .............................................................................................................................................135Modelado Conceptual ................................................................................................................................136Diagrama de Pescado .................................................................................................................................136Glosario .....................................................................................................................................................138Lista de Requerimientos .............................................................................................................................138Checklist ....................................................................................................................................................139

ANEXO 6 ......................................................................................................................................................... 140

ESTILOS ARQUITECTÓNICOS .......................................................................................................................140Estilo de Arquitectura de Tuberías y Filtros .................................................................................................144Estilo de Arquitectura de Pizarra ................................................................................................................145Estilo de Arquitectura de Programa Principal/Subprograma .......................................................................146Estilo de Arquitectura Orientada a Objetos.................................................................................................146Estilo de Arquitectura en Capas ..................................................................................................................147Estilo de Arquitectura Cliente Servidor .......................................................................................................147Estilo de Arquitectura de Máquina Virtual o Intérprete ..............................................................................148Estilo de Arquitectura de Control de Procesos ............................................................................................148Estilo de Arquitectura Modelo Vista Controlador ........................................................................................149

ANEXO 7 ......................................................................................................................................................... 150

NORMALIZACION DE BASES DE DATOS .......................................................................................................150TERMINOLOGÍA RELACIONAL .....................................................................................................................150DEPENDENCIA FUNCIONAL ........................................................................................................................151Axiomas de Armstrong ...............................................................................................................................152FORMAS NORMALES ..................................................................................................................................153

Metodología MDS-α


Primera Forma Normal - 1FN......................................................................................................................153Segunda Forma Normal – 2FN ....................................................................................................................155Tercera Forma Normal – 3FN .....................................................................................................................155Forma Normal de Boyce - Codd - FNBC ......................................................................................................156Cuarta Forma Normal - 4FN........................................................................................................................157Quinta Forma Normal - 5FN .......................................................................................................................157

BIBLIOGRAFÍA ................................................................................................................................................. 158

Metodología de Desarrollo de Sistemasmedios.economiayfinanzas.gob.bo/SP/documentos/... · Las...

Documents

Transcript of Metodología de Desarrollo de Sistemasmedios.economiayfinanzas.gob.bo/SP/documentos/... · Las...