Cita:
Empezado por roman
Yo de esto no sé. Realmente. Según recuerdo de cuando leí algunas cosas de Scott Ambler, una buena herramienta para iniciar una aplicación OOP son las CRC-Cards. El artículo de la wikipedia está muy chafa pero él lo describía mejor e indicaba que eran un medio muy bueno para hablar con los clientes. |
Pues si, las tarjetas CRC son una de las opciones. Aunque hay que hacer la advertencia de que sólo son a modo de orientación o guía; aunque hay ciertos requisitos que dificilmente se pueden capturar en una tarjeta CRC. El problema de las tarjetas CRC está en que se condiciona a hablar en POO. Y hay ciertos clientes al que les cuesta entenderlas... El problema muchas veces está en que no se logra apreciar las clases. Es requisito fundamental contar con las clases para encarar las tarjetas.
Por este motivo se las suele complementar empleando los Casos de Usos, que logran capturar los procesos y luego de estas "historias" uno puede detectar las clases conceptuales y allí ya meterse con CRC.
Tanto CRC como los Casos de Usos son algunas de las técnicas empleadas para la recolección de requisitos... y aún así no todo se logra capturar o que sea fácil de asimilar. Por ello es que se adjuntan también los glosarios, tablas de especificaciones complementarias... incluso es hasta bueno o saludable tratar de entender el contexto analizando las visiones (como una lista de actores-objetivos).
Algo que tiene de bueno el enfoque de casos de uso es que ayuda a ordenar las cosas basándose en el contexto y los procesos. Para ello emplea una guía denominada Casos de Usos EBP (Elementary Business Processes). Es decir se resaltan las actividades y procesos más significativos y que aportan valor y significado al negocio, recolectando los datos que se necesita, quien lo hace, en que momento, y en respuesta a que evento.
De este modo ya el propio caso de uso te aporta y filtra el material para ir detectando las potenciales clases.
Tengo que contarte que las tarjetas CRC ya están quedando en desuso.
Hay otros enfoques que fuerzan a detectar si las cosas las estamos pensando bien... el diseño dirigido por contratos ayuda a determinar que operaciones se necesita para ir de un estado consistente a otro. Cuando uno define las condiciones iniciales y finales ya puede darse una idea de como son las interacciones entre las clases, el estado y asignaciones de cada objeto.
En fin que no se trata de una única cosa... hay un enorme arsenal de herramientas que uno puede tomar. Y luego es que algunos dicen que la Ingeniería de Software es una burla
Ya lo dijo Grady Booch:
Cita:
Las personas son más importantes que cualquier proceso.
Buenas personas con un buen proceso siempre actuarán mejor que buenas personas sin procesos.
|
Saludos,
PD: No hace falta decir que soy defensor de la ingeniería de software supongo