🚀 go-pugleaf

Użytkownik "radoslaw tereszczuk" <tereszczuk@it1.pl> napisał w wiadomości 
news:63d79$464463e3

> koncepcja przypadkuw uzycia jest ortogonalna do tego czy dotyczyc maja 
> funkcjonalnosci czy arhitektury czy tez tego i tego na raz
ad opcji ostatniej (mieszanej) - czemu służyć ma mieszanie analizy (CO) z 
projektem (JAK)? Bo chyba nie sprzyja jakości produktu. Jesteś pewien, że 
jest to w _jakimkolwiek_ przypadku pożądane? Jeśli nie strawiamy pastucha 
elektrycznego w miejscu, gdzie kończy się opis funkcjionalności a zaczyna 
projekt rozwiązań, czy można w ogóle mówić o zarządzaniu projektem / 
produktem w tej sytuacji?Konsekwencją mieszania tych dówch typów jest stan, 
gdzie twórca PU narzuca (świadomie lub nie) pewne aspekty projektowe - co 
ogranicza architekta / kodera. Zwracam tu szczególną uwagę na szczególny 
przypadek, iż analityk nie musi być architektem i w ogóle nie bazować na 
aspektach strukturalności, mudularyzacji, i innych istotnych na etapie 
projektowym.


> hoc oczywiscie najczesciej use cases dotycza funkcjoalnosci
reasumując, zagadnienie brzmi, czy nie należałoby tego jawnie wskazać i 
rozgraniczyć, z w.w względów.