Refinamiento De Software

• Casos de uso de granularidad muy fina: sin que esto sea lo habitual, se ha seguido este criterio para que los requisitos funcionales de un caso estructurado se “vean” más claros en este caso deorientación a objetos y los desarrolladores que hayan realizado aplicaciones estructuradas tengan más fácil la comprensión de los casos de uso como guía de un desarrollo iterativo e incremental.
 
•Funcionalidades limitadas: para que sea más fácil de seguir, el desarrollo del prototipo de software de una biblioteca se ha recortado de la siguiente manera: El Análisis profundiza en la Gestión demateriales y alumnos, en el préstamo de material. Por ello el caso práctico no se ha modelizado completamente sino que se ha centrado en este subconjunto de funcionalidades según se ha descrito.Arquitectura de productos acorde a Métrica V.3: se ha desarrollado un conjunto de productos, fundamentalmente de modelización, compatible con las propuestas de Métrica aunque no por ello se han planteadotodos los que la metodología propone. El caso práctico se centra en la modelización, y por ello no se ha desarrollado toda la documentación adicional que establecen los procesos de Desarrollo eInterfaz. Es más, no se ha abordado el proceso PSI, y el EVS sólo como punto de partida.
 
Tecnología: como punto de partida se ha establecido un entorno tecnológico bastante común en la actualidadcómo es un SGBD relacional y tecnología Visual Basic.NET, aunque el caso práctico intenta ser más general, para que pueda ser considerado como referencia, por ejemplo, ante plataformas tipo .NET deMicrosoft. El documento se estructura como una colección de productos, identificados en su cabecera según Proceso, Actividad y Tarea que intervienen en su elaboración si bien, en la herramienta CASEempleada como soporte a la modelización – Visual Paradig for UML - se han agrupado los productos en vistas según el siguiente criterio: el Proceso que en Métrica sería responsable de crear el producto,...