El software evoluciona con el tiempo.
Los requisitos del usuario y del producto suelen cambiar conforme se
desarrolla el mismo. Las fechas de mercado y la competencia hacen que no
sea posible esperar a poner en el mercado un producto absolutamente
completo, por lo que se aconsejable introducir una versión funcional
limitada de alguna forma para aliviar las presiones competitivas.
En esas u otras situaciones similares los desarrolladores necesitan
modelos de progreso que estén diseñados para acomodarse a una evolución
temporal o progresiva, donde los requisitos centrales son conocidos de
antemano, aunque no estén bien definidos a nivel detalle.
En el modelo cascada y cascada realimentado no se tiene demasiado en cuenta la naturaleza evolutiva del software, se plantea como estático, con requisitos bien conocidos y definidos desde el inicio.
Los evolutivos son modelos iterativos, permiten desarrollar versiones
cada vez más completas y complejas, hasta llegar al objetivo final
deseado; incluso evolucionar más allá, durante la fase de operación.
Los modelos «iterativo incremental» y «espiral» (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.
Etapas en el desarrollo del software.
Involucra fuertemente al usuario o cliente del sistema, por tanto
tiene matices muy subjetivos y es difícil de modelar con certeza o
aplicar una técnica que sea «la más cercana a la adecuada» (de hecho no
existe «la estrictamente adecuada»). Si bien se han ideado varias
metodologías, incluso software de apoyo, para captura, elicitación y
registro de requisitos, no existe una forma infalible o absolutamente
confiable, y deben aplicarse conjuntamente buenos criterios y mucho
sentido común por parte del o los analistas encargados de la tarea; es
fundamental también lograr una fluida y adecuada comunicación y
comprensión con el usuario final o cliente del sistema.
Como se dijo, la habilidad del analista para interactuar con el
cliente es fundamental; lo común es que el cliente tenga un objetivo
general o problema que resolver, no conoce en absoluto el área
(informática), ni su jerga, ni siquiera sabe con precisión qué debería
hacer el producto software (qué y cuantas funciones) ni, mucho menos,
cómo debe operar. En otros casos menos frecuentes, el cliente «piensa»
que sabe precisamente lo que el software tiene que hacer, y generalmente
acierta muy parcialmente, pero su empecinamiento entorpece la tarea de
elicitación. El analista debe tener la capacidad para lidiar con este
tipo de problemas, que incluyen relaciones humanas; tiene que saber
ponerse al nivel del usuario para permitir una adecuada comunicación y
comprensión.
No hay comentarios.:
Publicar un comentario