Другата страна
Ще си позволя да доразвия историята, която Гошо разправя с няколко приказки за другата част от работата - а именно тази на разработчика.
Моята роля в проекта е едновременно архитект и разработчик, което ще рече, че след фазата на анализа и изясняването трябва да имам готов модел на приложението, върху който да можем да оценим работата и да планираме процеса, по който да я свършим.
Като цяло най-големият проблем на този етап от проекта е как да държим документите, изграждащи спецификацията (независимо от тяхната форма) актуални, пълни, качествени и снихронизирани един спрямо друг. Което е наистина трудно след като в рамките на 3 срещи за една седмица изкочиха един куп неочаквани новости и промени.
Пред мен стоеше въпроса какъв да бъде формата на синтезираната информация, която събирах от “показанията” на инициатора на проекта. Кратките срокове не позволяват да се разперя в излишна бумащина, така че се спрях на Entity Relationship диаграма + три четири реда за функцията на всяко entity.
Защо не Use Case UML диаграма?
Текстови описания на потребителските случаи бяха “стенографирани” от мениджъра. Този документ е удобен валидатор на модела, но потребителските случаи са прекалено фокусирани върху процеса на употреба и дават малко информация за това какво точно би могло да ги обслужи. Те са по-скоро полезни като допълнение към прототипа на интерфейса, бидейки навигатор на човека, който го преглежда.
А защо не фукнционална спецификация?
Функционалната спецификация на практика е смилане на use case-овете до ясни изисквания към апликацията. Като такава тя е нелошо помагало за изграждането на модела, както и за “замразяване” на проектния обхват. Предвид обстоятелствата обаче предпочетох да я прескоча, и да използвам директно показанията, прототипа и сценариите като база за изграждане на
ER диаграмата
- представете си я като схема на базата данни, ама на една идея по-високо. Целта ти е да опишеш бизнес обектите и релациите между тях. Една идея по-високо от физическата структура на базата, не е задължително да изписваш всичките 40 полета на даден обект, а по-скоро само тези, които са от значение за връзките му с останалите боклуци. Тук таме можеш да си спестиш някоя номенклатурна таблица или N2N връзка, ако това не са от значение за анализа. Ако имаш желание (или по-скоро нужда) създай едно текстово документче за бележки към обектите, заедно с кратко описание на тяхната евентуална употреба. Документът е полезен и за хора, които нямат сериозни познания в областта, но пък трябва да прегледат и да одобрят творчеството ти.
Хубавото на този формат (както и на гошовия прототип) е, че той реално отмята работа от разработката, и не остава остаряла и вече невярна бумага от предишната версия. Веднъж стиснали ръце за обхвата на проекта, тази диаграма се вдига до реална база данни (има си Next > Next > Next уизърд като за мързеливи програмисти). В една по-нататъшна фаза пък Визиото може да reverse engineer-не структурата на базата до диаграма, върху която да се проектира допълнителна фукнционалност.