Як стварыць праектны дакумент праграмнага забеспячэння

Большасць распрацоўшчыкаў праграмнага забеспячэння аддаюць перавагу паспяшацца праз працэс дакументавання патрабаванняў да праектавання або нават увогуле пазбегнуць яго, калі гэта магчыма. Яны аддаюць перавагу перайсці адразу да стварэння кода і прасоўвання да выпуску гатовага прадукту. Аднак стварэнне цэлага праграмнага прадукту або яго набору без дакумента аб распрацоўцы праграмнага забеспячэння можа быць катастрафічным. Дакумент з патрабаваннямі да праграмнага забеспячэння, або дакумент па распрацоўцы праграмнага забеспячэння , – гэта салідны запіс спецыфікацый і розных дэталяў, якія служаць планам для ўсяго праекта.

Дакумент па распрацоўцы праграмнага забеспячэння дакладна вызначае патрабаванні, чаканыя функцыі, жаданыя функцыі і г.д. праграмнага забеспячэння і становіцца арыенцірам, якому можа прытрымлівацца ўся каманда распрацоўшчыкаў праграмнага забеспячэння. І калі праграмнае забеспячэнне ствараецца для вонкавага кліента, то праектны дакумент праграмнага забеспячэння набывае яшчэ большае значэнне, таму што гарантуе, што і кліент, і кампанія па распрацоўцы праграмнага забеспячэння узгадніць вынікі, каб не было блытаніны падчас праекта або падчас выпуску/перадачы. Вось чаму, нават калі напісанне праектнага дакумента праграмнага забеспячэння можа здацца сумнай працай, дакументаванне патрабаванняў да дызайну і стварэнне дакументаў па дызайне праграмнага забеспячэння з’яўляецца абавязковым для кожнага распрацоўшчыка праграмнага забеспячэння.

Давайце хутка паглядзім на тое, што такое праектны дакумент праграмнага забеспячэння і асноўныя элементы, якія павінен утрымліваць кожны такі дакумент.

Што такое праектны дакумент праграмнага забеспячэння?

Дакумент распрацоўкі праграмнага забеспячэння вядомы пад рознымі назвамі, напрыклад, спецыфікацыя распрацоўкі праграмнага забеспячэння, дакументы тэхнічнай спецыфікацыі або дакумент патрабаванняў да праграмнага забеспячэння. Гэта вельмі падрабязны дакумент, які апісвае агульную архітэктуру праграмнага прадукту, які неабходна стварыць. Згодна з IEEE, праектны дакумент праграмнага забеспячэння – гэта «апісанне праграмнага забеспячэння, створанага для палягчэння аналізу, планавання, рэалізацыі і прыняцця рашэнняў». Думайце пра гэта як пра кіраўніцтва або план, які служыць архітэктарам праграмнага забеспячэння (кодэрам і распрацоўшчыкам) і дапамагае ім зразумець, як ім трэба ствараць праграмны прадукт на аснове набору тэхнічных патрабаванняў.

А хто стварае гэты неабходны дакумент? Як правіла, кіраўнікі праектаў і вопытныя распрацоўшчыкі праграмнага забеспячэння ствараюць праектны дакумент праграмнага забеспячэння і гарантуюць, што ўсе зацікаўленыя бакі разумеюць спецыфікацыі праграмнага забеспячэння.

Навошта нам патрэбны праектныя дакументы праграмнага забеспячэння?

Уявіце, што здарылася б, калі б вы адправіліся ў доўгую дарогу без навігацыі або карты? Або архітэктар вырашыў пабудаваць цэлы дом без чарцяжа, які б кіраваў ім і яго камандай? Дакументы па распрацоўцы праграмнага забеспячэння з’яўляюцца важным спосабам уключыць у працэс усіх, хто ўдзельнічае ў прадукце. Кожны павінен зразумець, што магчыма, а што немагчыма, і сістэму, якая будзе распрацавана, даючы ім стабільную кропку адліку, якая апісвае ўсе часткі праграмнага забеспячэння і тое, як яны будуць працаваць.

Для ўнутранай каманды распрацоўшчыкаў гэта выдатны спосаб выразна спланаваць усю сістэмную архітэктуру. Распрацоўшчыкі і менеджэры праектаў могуць прайсці праз усе магчымыя перашкоды або магчымыя прабелы, якія могуць перашкодзіць праекту. Ён аб’ядноўвае інфармацыю аб праекце і дазваляе абмяркоўваць усе істотныя пытанні, якія ўзнікаюць паміж зацікаўленымі бакамі і распрацоўшчыкамі.

Дакумент аб распрацоўцы праграмнага забеспячэння гарантуе, што прадукт створаны ў адпаведнасці з патрэбамі і адпавядае таму, што было ўзгоднена да стварэння праграмнага забеспячэння. Ён таксама служыць кантрольна-прапускным пунктам для кліентаў, каб пацвердзіць, ці выканала распрацоўка праграмнага забеспячэння кампанія, як планавалася.

Што ўплывае на тып праектнага дакумента праграмнага забеспячэння?

Тып дакументацыі, якую створыць каманда распрацоўшчыкаў праграмнага забеспячэння, будзе ў значнай ступені залежаць ад абранай метадалогіі распрацоўкі праграмнага забеспячэння. Правільна. Мы гаворым пра традыцыйную метадалогію Waterfall і больш новую метадалогію Agile . Кожны з іх унікальны з пункту гледжання суправаджальнай дакументацыі.

Метад вадаспаду з’яўляецца лінейным, з рознымі мэтамі для кожнай фазы развіцця. Калі гэты падыход выкарыстоўваецца для распрацоўкі праграмнага забеспячэння , шмат часу траціцца на планаванне прадукту на ранніх стадыях праекта, а падрабязная дакументацыя ствараецца перад пачаткам любой з наступных стадый распрацоўкі. Каманды распрацоўшчыкаў ствараюць падрабязны агляд асноўных задач і могуць планаваць працоўны працэс, забяспечваючы дакладны бюджэт і ацэнку часу. Вядома, як паказала нам апошняе дзесяцігоддзе, метадалогія вадаспаду неэфектыўная для доўгатэрміновага развіцця, паколькі яна не ўлічвае магчымыя змены і непрадбачаныя сітуацыі на хаду.

Гнуткі метад распрацоўкі праграмнага забеспячэння заснаваны на цесным супрацоўніцтве паміж распрацоўшчыкамі і кліентам і забяспечвае як маштабаванасць, так і гібкасць, каб хутчэй рэагаваць на змены. Спрытны метад з’яўляецца вельмі ітэрацыйным, і кожная ітэрацыя, г.зн. вялікая змена спецыфікацый або паляпшэнне/новых патрабаванняў, уключае ў сябе планаванне, аналіз, праектаванне , распрацоўку і тэставанне . Спрытны метад не патрабуе вычарпальнай дакументацыі ў пачатку, таму што праект уносіць шмат змен па меры яго развіцця. Ідэя складаецца ў тым, каб падрыхтаваць дакументацыю з інфармацыяй, якая важная для прасоўвання наперад, калі гэта мае найбольшы сэнс.

Зараз давайце паглядзім, што павінен змяшчаць ідэальны праектны дакумент праграмнага забеспячэння.

Што змяшчаецца ў дакуменце па распрацоўцы праграмнага забеспячэння?

Вось звесткі, якія змяшчае тыповы праектны дакумент праграмнага забеспячэння :

Назва:

Назва дакумента

Уводзіны:

Агляд усяго дакумента і яго мэты

Агляд праекта:

Агульнае апісанне і функцыянальнасць праграмнага забеспячэння

Меркаванні па дызайне:

Пералічыце перашкоды, якія неабходна вырашыць перад стварэннем праграмнага забеспячэння. Яны будуць уключаць такія дэталі, як:

• Любыя магчымыя няправільныя здагадкі або любыя залежнасці
• Агульныя абмежаванні, якія могуць паўплываць на дызайн праграмнага забеспячэння
• Мэты і рэкамендацыі па распрацоўцы праграмнага забеспячэння
• Метадалогія распрацоўкі, якая будзе выкарыстоўвацца

Архітэктурныя стратэгіі:

Стратэгіі, якія будуць выкарыстоўвацца, паўплываюць на сістэму.

Архітэктура сістэмы:

Агляд высокага ўзроўню таго, як функцыянальныя магчымасці і абавязкі сістэмы былі падзелены і размеркаваны на падсістэмы або кампаненты.

Палітыка і тактыка:

Праектуйце палітыку і тактыку, якія не маюць шырокіх архітэктурных наступстваў, г.зн. яны не будуць істотна ўплываць на агульную арганізацыю сістэмы і яе структуры высокага ўзроўню.

Дэталёвы дызайн сістэмы:

Большасць кампанентаў, апісаных у раздзеле “Архітэктура сістэмы”, патрабуюць больш падрабязнага абмеркавання. Іншыя кампаненты і падкампаненты больш нізкага ўзроўню таксама могуць быць апісаны.

Ролі і абавязкі:

Інфармацыя пра ўдзельнікаў, уключаючы ўладальніка прадукту, членаў каманды і зацікаўленых бакоў, з дакладна вызначанымі абавязкамі і запланаванымі мэтамі выпуску для кожнага з членаў каманды.

Здагадкі:

Спіс тэхнічных або дзелавых здагадак, якія можа мець каманда.

Архітэктура і прынцыпы дызайну:

Апісвае кіруючую архітэктуру і прынцыпы праектавання, з якімі вы будзеце распрацоўваць прадукт.

Схематычнае адлюстраванне праграмнага забеспячэння/прадукта:

Дыяграмы, якія дапамогуць зразумець і перадаць структуру і прынцыпы дызайну.

Дакумент зыходнага кода (неабавязкова):

Дакумент зыходнага кода – гэта тэхнічны раздзел, які тлумачыць, як працуе код.

Дакументы з зыходным кодам могуць уключаць такія дэталі, як:

• Фреймворк генерацыі HTML і іншыя фрэймворкі
• Тып прывязкі даных
• Шаблон для афармлення з прыкладамі
• Меры бяспекі
• Іншыя заканамернасці і прынцыпы

Забеспячэнне якасці:

Самыя распаўсюджаныя:

• Тэст стратэгіі
• План выпрабаванняў
• Спецыфікацыі тэставага выпадку
• Кантрольныя спісы тэстаў

Гласарый :

Поўны спіс вызначаных тэрмінаў і паняццяў, якія выкарыстоўваюцца ва ўсім дакуменце.

Віды праектна-праграмнай дакументацыі

Галоўная мэта такой дакументацыі – пераканацца, што ўсе зацікаўленыя бакі маюць агульную мэту і ідуць па вызначаным шляху. Існуюць розныя тыпы праектнай дакументацыі праграмнага забеспячэння , якія служаць гэтай мэты.

Дакументацыя па прадукту – апісвае прадукт, які распрацоўваецца, і дае інструкцыі па выкананні з ім розных задач. Ёсць два тыпу дакументацыі прадукту:

• Сістэмная дакументацыя – адносіцца да дакументаў, якія апісваюць сістэму і яе часткі. Ён уключае ў сябе дакументы з патрабаваннямі, праектныя рашэнні, апісанні архітэктуры, зыходны код праграмы і дапаможнікі.
• Карыстальніцкая дакументацыя – адносіцца да кіраўніцтваў, якія ў асноўным падрыхтаваны для канчатковых карыстальнікаў прадукту і сістэмных адміністратараў. Карыстальніцкая дакументацыя ўключае навучальныя дапаможнікі, кіраўніцтва карыстальніка, кіраўніцтва па ліквідацыі непаладак, кіраўніцтва па ўстаноўцы і даведачныя кіраўніцтва.

Дакументацыя працэсу – уключае ўсе дакументы, звязаныя з працэсам, створаныя падчас распрацоўкі і абслугоўвання праграмнага забеспячэння. Напрыклад, планы праектаў, расклады выпрабаванняў, справаздачы, стандарты, нататкі сустрэч, абмен электроннымі лістамі і г.д. У той час як дакументацыя прадукту апісвае прадукт, які распрацоўваецца, дакументацыя працэсу запісвае працэс распрацоўкі.

Сістэмная дакументацыя – Дае ўсім зацікаўленым бакам агляд сістэмы і асноўных тэхналогій. Сістэмны дакумент звычайна змяшчае патрабаванні да распрацоўкі, праект архітэктуры, зыходны код, дакументы праверкі, праверкі і тэставання, а таксама дапаможнік для карыстальнікаў. Часам ён таксама змяшчае падрабязную інфармацыю аб тым, што павінна рабіць сістэма, варыянты выкарыстання і г.д.

Гэта заўсёды дапамагае дакументаваць

Любая каманда распрацоўшчыкаў праграмнага забеспячэння павінна засяроджвацца на забеспячэнні каштоўнасці для сваіх кліентаў, а высакаякасная дакументацыя гэтак жа неабходная, як і праграмны прадукт, які ствараецца. Добрая дакументацыя па праграмным забеспячэнні павінна выконвацца ў якасці гігіены і павінна быць прадастаўлена, незалежна ад таго, ці з’яўляецца гэта дакумент спецыфікацый для распрацоўшчыкаў і тэсціроўшчыкаў або інструкцыі па праграмным забеспячэнні для канчатковых карыстальнікаў. Вычарпальная дакументацыя па праграмным забеспячэнні з’яўляецца канкрэтнай, кароткай і актуальнай і павінна абмежавацца тым, што непасрэдна дапамагае дасягнуць мэт праекта.