Jeden z mitów w analizie, z jakim się spotykałam, jest taki, że analityk powinien od razu, natychmiast, zrobić rozbudowany dokładny i szczegółowy diagram, w pełni odpowiadający rzeczywistym potrzebom. Taki diagram, jak to wiecie, w książkach o nim piszą – że
[UML] Diagram Przypadków Użycia od strony teoretycznej
Diagram przypadków użycia uznawany jest za najważniejszy diagram w procesie projektowania systemu. Jego “siłą” jest to, że przedstawia funkcjonalności systemu wraz z jego otoczeniem, a na projektowany system patrzy “z zewnątrz”, od strony funkcjonalności dostępnych dla użytkownika. Diagram Przypadków Użycia
Fuck’up Confession – “niepodjęte netto”
Analiza to super sprawa, o tym wie każdy, kto miał z nią styczność i kręcą go takie rzeczy. “Wyciąganie” z ludzi czegoś, czego nie wiedzą że powinni powiedzieć, analizy tony dokumentów, pisanie wielostronicowych opracowań zdobytej wiedzy i spędzanie wielu godzin
“Identyfikacja na podstawie istniejących dokumentów” po ludzku
Niniejszy post rozpoczyna cykl artykułów dotyczących technik pozyskiwania wymagań. Na pierwszy plan bierzemy “identyfikację na podstawie istniejących dokumentów” po ludzku 🙂 Analiza dokumentów Technik zbierania wymagań jest cała masa (o tym napiszę innym razem a tu znajdzie się wtedy link do
O wymaganiach po ludzku cz. 2 – Jakie powinny być idealne wymagania?
Jakie powinny być idealne wymagania? Pytanie idealnie zachęcające do dyskusji, prawda? 🙂 Niby najprostsza i zarazem najpełniejsza odpowiedź zawiera się w jednym zdaniu: Idealne wymagania powinny być tak napisane, by w pełny sposób opisywały oczekiwany system i by w ten
Praktyczne podejście do analizy systemów IT, ale.. kto to robi??
Początkowo ten wpis miał brzmieć inaczej, miał mieć inną formę.. I przyznaje, że jest najdłużej pisanym postem na blogu 😀 Pisałam, kasowałam, poprawiałam, ale nie publikowałam, ciągle było “nie tak”;) Oby tym razem się udało! Zwykle w projekcie jest ktoś,