Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| 3.3.4. Memogu за описване на проекти
Създадени са различни методи за описание на създаваните проекти, които се различават по степента си на формализираност и по нагледността и разбира- емостта на получените описания. Практиката показва, че все още се предпочи- тат неформалните методи поради съпротивата и на потребителите, и на проек- тантите. Възраженията на потребителите са, че формалните описания са твърде сложни и неразбираеми за тях и те не могат да участват ефективно в обсъжда- 42 нето и проследяването на създаваните проекти. Възраженията на проектантите срещу формализмите са следните: не всички софтуерни специалисти имат необходимата теоретична под- готовка (например в областта на дискретната математика и математическата ло- гика), за да овладеят съответния апарат и да го прилагат за сложните реални системи; някои класове софтуерни системи са сложни за формално специфицира- не поради необходимостта от паралелни обработки, работа в реално време и др.; в софтуерните организации няма достатъчна информация за съществу- ващите техники за специфициране на проекти и за съответните инструментал- ни средства, които ги подпомагат. Използваните техники за описания са: а) Графично описание Този вид описание е най-старият, доколкото блок-схемите са един от най- предпочитаните начини за описание на алгоритми. В последните години се по- вишава приложимостта му поради появата на графични редактори и на специа- лизирани софтуерни средства за графично проектиране. б) Таблично представяне Заимствано е от теорията на вземане на решения и се състои в съставяне на таблици, описващи анализираните условия и съответните реакции на систе- мата за всяка комбинация от осъществени или неосъществени събития. в) Текстови описания Този вид описания са с различна степен на формализираност и най-общо се делят на две: псевдокодове и езици за проектиране на програми (PDL — Program Design Language). Псевдокодът е ограничен и структуриран естествен език, обикновено анг- лийски. Речникът на езика включва глаголи, имена от речника на данните и запа- зени (ключови) думи за описване на логиката на извършваните действия. Син- таксисът на езика допуска комбинации от линейна конструкция, конструкция за описване на условия и конструкция за описване на цикли. По-долу следва схематичен псевдокод за специфициране на модули. Той е създаден на основа- та на описани в литературата псевдокодове и е успешно приложен в реални софтуерни проекти: С ПЕЦИФИКАЦИЯ НА МОДУЛ Module:<имe> Рurposе:<предназначение> Uses: <вход> Returns: <изход> Defines: <собствени данни> Functional details:<описани чрез псевдокод> Псевдокодът е неформален език — ограничен английски. Речник: = глаголи (прилагателните и обстоятелствените пояснения се пропускат по- ради нееднозначното им интерпретиране); = термини от речника на данните; = ключови думи за описване на логиката. 43 Синтаксис: I. Последователни конструкции =. разказвателно описание на английски език; =. оператор за присвояване. II. Конструкции за условен преход: IF THEN ELSE < sequential_construct_S2> III. Конструкции за цикъл WHILE BEGIN END FOR NEXT DO .... UNTIL Различни начини за описване на проекти са подходящи за различните про- екти или за части на един и същи проект. В [7] са описани следните критерии за сравняване на методите за описване на проекти: модулност; простота; леснота на редактиране; възможност за автоматично създаване и обработка (чрез съответни ре- дактори); съпровождаемост; удобство на представяне на данните; възможност за верификация; сложност на прехода „проект—програма" 3.3.5. Организационни аспекти на проектирането Успехът на проектирането зависи както от качеството на междинните продукти, създадени през предишните фази („Технико-икономическо зада- ние" и „Спецификация на изискванията"), така и от организацията на основ- ните дейности. Като колективна дейност, извършвана от екип, проектиране- то трябва да се осъществява целенасочено и систематично, с регламентира- не на основните процедури (за комуникация във и извън екипа, за управля- емо променяне на изискванията, за документиране на процеса и на резулта- тите). Най-сложният проблем е определянето на подходящо ниво на деком- позиране и оттам — на подробност на проекта. Неясните, общи описания могат да породят проблеми при съставянето на програмите. Обратно, стре- межът да се създадат изключително подробни предписания още на този етап може да затрудни програмистите. Препоръката е: „Не казвай на програмис- 44 та, как да прави нещата. Казвай му само, какво трябва да се направи и оста- ви въображението му да те изненада (приятно?!)." 3.3.6. Оценяване качеството на проекти За да се определи кои проекти са добри, трябва да се определят съответни характеристики на качеството, които могат да бъдат: Пълнота — утвърдените изисквания да са отразени в проекта на cod>Tveo- ната система. Проектът да бъде разбираем, ясен, точно и недвусмислено описан и да не зависи от платформата, на която ще се реализира. Проектът да бъде проверяем, т. е. да може да се проследява вграждането на изискванията. Процесът на проектиране и създадените проекти да бъдат документирани. Препоръчва се проектирането да завършва със създаването на документ, наречен „Спецификация на проекта", който може да има следната стандартна структура: Спецификация на проекта I. Цел и обхват на дейностите по проектиране II. Описание на проектите: а) външен проект; б) детайлен проект. III. Съответствие на проектите с утвърдените изисквания IV План за модулно и системно тестване V. Допълнителни условия и ограничения за проектирането VI. Приложения (описание на алгоритми, алтернативни процедури таб- лични данни, извлечения от други документи и т. н.) Изтегляне 2.27 Mb. Сподели с приятели:
|