7. Partición
Normalmente los problemas son demasiado grandes y complejos para ser comprendidos como un todo.
Por esta razón, tendemos a particionar (dividir) tales problemas en partes que puedan ser fácilmente
comprendidas, y establecer interfases entre las partes, de forma que se realice la función global.
Durante el análisis de requerimientos, el dominio funcional y el dominio de la información del software
pueden ser particionados.
En esencia la partición descompone un problema en sus partes constituyentes. Conceptualmente,
establecemos una representación jerárquica de la función o información y luego partimos el elemento
superior mediante: 1) incrementando los detalles, moviéndonos verticalmente en la jerarquía, o 2)
descomponiendo funcionalmente el problema, moviéndonos horizontalmente en la jerarquía.
8. Visiones Lógicas y Físicas
La visión lógica de los requerimientos del software presenta las funciones que han de realizarse y la
información que ha de procesarse independientemente de los detalles de implementación.
La visión física de los requerimientos del software presenta una manifestación del mundo real de las
funciones de procesamiento y las estructuras de información. En algunos casos se desarrolla una
representación física como el primer paso del diseño del software. Sin embargo la mayoría de los
sistemas basados en computador, se especifican de forma que se dictan ciertas recomendaciones
físicas.
9. Construcción de Prototipos de Software
En análisis debe ser conducido independientemente del paradigma de ingeniería de software aplicado.
Sin embargo, la forma que ese análisis tomara puede variar. En algunos casos es posible aplicar los
principios de análisis fundamental y derivar a una especificación en papel del software desde el cual
pueda desarrollarse un diseño. En otras situaciones, se va a una recolección de los requerimientos, se
aplican los principios de análisis y se construye un modelo de software, llamado un prototipo, según las
apreciaciones del cliente y del que lo desarrolla. Finalmente, hay circunstancias que requieren la
construcción de un prototipo al comienzo del análisis, puesto que el modelo es el único mediante el que
los requerimientos pueden ser derivados efectivamente.
10. Un escenario para la contruccion de prototipos
Todos los proyectos de ingeniería de software comienzan con una petición del cliente. La petición puede
estar en la forma de una memoria que describe un problema, un informe que define un conjunto de
objetivos comerciales o del producto, una petición de propuesta formal de una agencia o compañía
exterior, o una especificación del sistema que ha asignado una función y comportamiento al software,
como un elemento de un sistema mayor basado en computadora. Suponiendo que existe una petición
para un programa de una de las formas dichas anteriormente, para construir un prototipo del software
se aplican los siguientes pasos:
PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato
para construir un prototipo.
Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es esencial que: 1) el
cliente participe en la evaluación y refinamiento del prototipo, y 2) el cliente sea capaz de tomar
decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de
desarrollo tendrá una fuerte influencia en la eficacia del prototipo.
PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de
los requerimientos.
Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar los dominios
funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación
de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de
requerimientos.
PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto
de especificaciones de diseño abreviadas para el prototipo.
El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de
un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de
datos, en vez de hacia el diseño procedimental detallado.
PASO 4. El software del prototipo se crea, prueba y refina
Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una
forma rápida. Desafortunadamente, tales bloques construidos raramente existen.
Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción
de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible
frecuentemente crear un prototipo en papel que describa la interacción hombre-maquina usando una
serie de hojas de historia.
PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual “conduce la prueba” de
la aplicación y sugiere modificaciones.
Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede
examinar una representación implementada de los requerimientos del programa, sugerir modificaciones
que harán al programa cumplir mejor las necesidades reales.
PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén
formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción.
El paradigma de construcción del prototipo puede ser conducido con uno o dos objetivos en mente: 1) el
propósito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser
traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de
programación, o 2) el propósito de la construcción del prototipo es suministrar un continuo que pueda
conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus meritos y
amos crean problemas. |
