Файл: R_3.doc

РОЗДІЛ 3

ВИМОГИ ДО СТВОРЕННЯ ПРОГРАМНОГО
ВИРОБУ ТА ЗАСОБИ ЗОВНІШНЬОГО ПРОЕКТУВАННЯ

3.1 Загальна характеристика
основних стадій проектування

Будь-який програмний виріб має системні ознаки, тому процес розробки програмних виробів різних класів потребує спільного аналізу характеристик джерел вхідної інформації, каналів зв’язку, технічних засобів обробки інформації та вимог її користувачів. Доцільність системного підходу до розробки програмного забезпечення та використання досвіду розробки технічних систем не потребує доказів.

Використовуючи системний підхід та керуючись вимогами ДСТУ, процес створення програмного виробу поділяють на такі стадії: розробка технічного завдання, розробка ескізного (зовнішнього) проекту, розробка технічного (внутрішнього) проекту, робоче проектування, випробування програмного виробу.

Початкові стадії визначають якість проекту й успіх розробки програмних виробів у цілому. Для початкових стадій розробки програмних виробів типовими є такі ситуації: виявлення і чітке формулювання проблеми в умовах невизначеності; вибір стратегії дослідження та розробки; точне визначення програмного виробу як системи (межі системи, входи, виходи, набір компонентів); виявлення цілей функціонування програмного виробу; виявлення функцій та складу програмного виробу, що ство-
рюється.

Технічне завдання є результатом досліджень у предметній сфері з погляду задач, що розв’язуються в ній. На цій стадії майбутній комплекс програм ретельно аналізується з урахуванням набору функцій та основних властивостей; обґрунтовується доцільність їх розробки; попередньо оцінюються трудові та вартісні витрати й строки створення; виробляються рекомендації щодо вибору інструментальних засобів і методів, що передбачаються для використання. Обов’язковим у змісті цієї стадії є формування вимог до якості програми відповідно до умов її функціонування та реалізації конкретних функцій.

Програмний виріб являє собою складний комплекс взаємопов’язаних програм, у створенні яких беруть участь багато розробників, тому ефективність розроблюваної системи управління залежить від чітких і узгоджених дій всіх її учасників, які можуть бути досягнуті тільки за допомогою ретельно розробленого технічного завдання (ТЗ).

ТЗ є той документ, яким повинен керуватись колектив розробників програмних виробів. ТЗ розроблюється замовником і узгоджується з розробником, або розроблюється спільно. Усі зміни у ТЗ оформлюються протоколами і є невід’ємною частиною ТЗ.

Технічне завдання містить вимоги до програмного виробу, який розроблятиметься. Основні вимоги до програми повинні мати такі властивості: однозначність інтерпретації, повнота вимог, несуперечливість вимог, здійсненність вимог.

ТЗ містить характеристики програмного виробу, потоків вхідних і керуючих сигналів, а також такі техніко-економічні вимоги:

---

1. Призначення програмного виробу та його основні функції.

2. Перелік техніко-економічних вимог: очікувана економічна ефективність; вартість розробки (грошові та матеріальні ресурси, розподілені по стадіях та строках розробки).

3. Склад і характеристики потоків вхідної інформації — перелік вхідних даних, розподіл каналів зв’язку та засобів перетворення.

4. Основні вимоги до ЕОМ (обсяг пам’яті, системне програмне забезпечення, сумісність із зовнішніми пристроями та інше.)

5. Склад і характеристики вихідної (керуючої) інформації — перелік керуючих сигналів, розподіл каналів зв’язку, припустима середня квадратична помилка, швидкість зміни сигналів, час запізнення повідомлень, формат даних.

6. Необхідний рівень функціональних характеристик — стійкість до зовнішніх впливів, надійність, точність, раціональність структури.

7. Експлуатаційні характеристики — ступінь автоматизації запуску, останову, вводу параметрів та їх змін; вимоги до засобів індикації, контролюючих процес функціонування; можливості зберігання та оперативного відновлення програм у пам’яті ЕОМ.

8. Умови внесення доопрацювань — ступінь автоматизації процесу внесення доопрацювань, перевірка їх ефективності.

9. Склад конструкторської та експлуатаційної документації, вимоги щодо її оформлення.

Слід відзначити, що при використанні модульного принципу програмування, для складних модулів розробляють окремі ТЗ.

Ескізне проектування — процес опису очікуваної поведінки системи з погляду зовнішнього щодо неї спостерігача. Мета цього опису — отримання вичерпаного, детального опису зовнішніх взаємодій користувача з майбутнім продуктом, не торкаючись його внутрішньої будови. Стадія зовнішнього проектування значною мірою залежить від коректності та повноти вимог, що були сформульовані в технічному завданні.

Ескізний проект містить принципові конструктивні рішення — загальну оптимальну структуру програмного виробу, призначення його модулів, організацію взаємозв’язку між ними, обмін даними та динамічний розподіл ресурсів ЕОМ, попередню оцінку необхідного обсягу пам’яті та припустимий діапазон характеристик вхідних і вихідних величин для кожного модуля. Він також містить моделювання роботи основних алгоритмів для апробації основних принципів обробки даних і управління, уточнення основних положень методики випробувань і оцінювання якості функціонування алгоритмів і програм, рішення технологічних і організаційних питань розробки логічного та інформаційного стикування модулів.

Ескізний проект виражається у формі зовнішніх специфікацій. Специфікація — це документ, в якому перераховуються умови, яким повинен відповідати програмний продукт, що розроблятиметься. До складу зовнішніх специфікацій належать: схема зовнішніх функцій; функціональні специфікації; структурне подання даних.

---

На стадії ескізного проектування мають бути розроблені всі принципові методичні та технологічні питання розробки програмного виробу. Ескізний проект затверджується замовником і є керівництвом для розробки технічного проекту.

Технічне проектування — це розробка сукупності проектних рішень щодо алгоритмічної структури програмного виробу та організації інформаційного забезпечення. До документації цієї стадії належать: пакет HIPO — схем або алгоритмічних схем; наочна таблиця змісту програмного виробу; зовнішні специфікації модулів.

Робоче проектування — це реалізація проектних рішень, що вироблені у відповідності із раніше сформульованими вимогами. Ця стадія включає безпосереднє кодування алгоритму (програмування), налагодження окремих компонентів і всього виробу в цілому, оформлення експлуатаційних документів.

На цій стадії використовується праця багатьох розробників, які працюють паралельно і координовано через тісний взаємозв’язок між модулями. Програмування кожного модуля закінчується автономним налагоджуванням, мета якого — локалізація та усунення помилок. Після цього розпочинається комплексне налагоджування програмного виробу.

До складу експлуатаційних документів належать: тексти програми; опис програми; опис застосування; посібник системного програміста; посібник програміста; опис вхідної мови і т. ін.

Випробування програм — це перевірка відповідності програмного виробу його специфікаціям на реальних даних або даних контрольного прикладу, наведеного в технічному завданні.

Досвід розробки пакетів загального призначення показує, котрі алгоритми та програми, значення їх параметрів і констант, взаємозв’язки, їх операторна частина під час створення піддаються неперервним змінам.

Крім того, можуть вводитись нові оператори, блоки і модулі, що реалізують нові додаткові функції, нові структурні зміни, що оптимізують процес управління і є об’єктивно необхідними, оскільки зумовлені набуттям досвіду і більш глибоким пізнанням взаємозв’язків між елементами системи та закономірностей процесу управління.

Певна кількість доопрацювань виконується для усунення неминучих помилок і прорахунків.

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

Отже, процес розробки програмного виробу є багатоетапний і нерозривний; внесення змін в алгоритми і програми на всіх стадіях є об’єктивна закономірність, і це необхідно враховувати під час планування робіт і організації взаємодії між колективами розробників.

---

3.2. Структурні перегляди і зовнішні інспекції

Структурні перегляди

Структурні перегляди є колективним обговорюванням завершеної структурної одиниці програмної системи, що створюється, на різних стадіях її розробки.

Мета структурних переглядів — допомога розробнику в якомога раннім виявленні помилок в його роботі та активне інформування членів колективу про компоненти системи, що є суміжними з їх розробкою, та програмну систему в цілому.

Термін «структурні» підкреслює ту обставину, що цей перегляд стає складовою частиною процесу створення програми і здійснюється наперед продуманим та визначеним у всіх тонкощах способом. Організаційно-структурний перегляд здійснюється у вигляді контрольної сесії, що є складовою переліку основних етапів кожної стадії розробки.

Об’єкти контролю на кожній стадії проектування наведено на рис. 3.1.

Стадія проектування	Що перевіряється	Імовірні недоліки
1. ТЗ	Постановка задачі Критерії ефективності та якості, тобто визначається мета створення програми Специфікація системи (основний зміст ТЗ) (вимоги до ПВ) Умови застосування майбутнього ПВ План чи графік розробки	1’. Нечіткість постановки 2’. Недосяжність 3’. Неповність специфікацій 4’. Недоступність для більшої кількості користувачів 5’. Нереальні плани (строки)
2. Ескізне проектування	Структура вхідних та вихідних даних Схема зовнішніх функцій Функціональні специфікації Обробка виняткових ситуа­цій	1’. Неповні вхідні дані 2’. Ця схема неповно відповідає вимогам (див. ТЗ) 3’. Неповні специфікації 4’. Недостатність проробки
3. Технічне проектування	Схема ієрархії функцій Псевдокод Тести План послідовної розробки модулів План тестування	1’.Наявність горизонтальних зв’язків (тобто порушується деревоподібна структура) 2’. Логічні помилки 3’. Неповність (недостатність набору тестів) 4’. Неупорядкованість модулів за даними 5’. Неповна відповідність вимогам
4. Робоче проектування	1. Взаємодія модулів 2. Текст програми 3. Документація для користувача	1’. Незафіксовані зв’язки, які можуть порушити деревоподібну структуру 2’. Логічні помилки З’. Неповнота, нечіткість, неоднозначність тлумачень
5. Випробу­вання	Остаточна документація Остаточний програмний продукт	1’. Відсутність критерію придатності документації 2’. Невідповідність специфікацій

Рис. 3.1. Об’єкти контролю на кожній стадії проектування

Зауваження до складу учасників структурного перегляду:

1) розробник сам добирає контролерів;

2) адміністратор, як правило не бере участі, бо структурний перегляд не є засобом оцінки кваліфікації розробника;

---

3) бажаний склад учасників: керівник бригади або групи програмістів, що веде розробку, якщо є спеціальна група тестування, то її представник. На стадії ТЗ та ЕП: користувач, ТП та РП: суперпрограміст.

Основні правила структурних переглядів:

1) контролювати роботу кожного, незалежно від посади та досвіду;

2) за кількістю та серйозністю помилок, що знайдені під час сесії не оцінюється рівень кваліфікації розробника;

3) за кількістю та серйозністю помилок, що здійснені після завершення всіх сесій оцінюється рівень кваліфікації розробника;

4) контролери повинні виявляти помилки, а не виправляти їх;

5) слід приділяти увагу основним проблемам, а не дрібним помилкам.

Організація проведення структурних переглядів

Підготовка до перегляду полягає в тому, щоб ознайомити його учасників із матеріалами, що розглядаються. Контролери приходять на сесію, маючи свої зауваження в письмовій формі. Адже розробник дає пояснення тільки тоді, якщо це потрібно. Питання чи проблеми, що пов’язані з документацією, мають пріоритет і розглядаються на початку сесії. Обговорення завершується складанням списку виявлених дефектів. Тривалість контрольної сесії — не більш як 1,5—2 год.

Переваги структурних переглядів:

• можливість раннього виявлення помилок, коли вартість виявлення мінімальна;

• підвищення якості ПВ;

• виникнення у робітников стимулів підвищення своєї кваліфікації; набуття впевненості у своїх силах, отримання задоволення від праці;

• поліпшення психологічної атмосфери в колективі;

• можливість для молодих працівників освоєння нових прийомів, методів, а для досвідчених — можливість удосконалення майстерності;

• можливість контролю з боку керівництва за виконанням проекту, оцінка рівня його завершення.

Зовнішня інспекція

Зовнішню інспекцію здійснює група контролю якості після структурного перегляду на кожній стадії проектування.

Відповідальним за подання матеріалу для зовнішньої інспекції є керівник колективу розробників. А відповідальним за своєчасне проведення та якість зовнішньої інспекції є керівник групи контролю якості.

Під час контролю зовнішньої інспекції повинні бути отримані відповіді на такі питання:

1. чи відповідає склад наданої документації вимогам стандарту ТЗ та прийнятої технології;

2. чи є можливість на основі документації без залучення розробника зрозуміти та оцінити зміст розробки;

3. чи відповідають функції, що реалізовані на даному етапі функціям, що були передбачені в попередній (початковій) точці;

4. чи достатня документація для проведення робіт на наступному етапі чи стадії розробки;

5. чи існують помилки, без усунення яких не можна робити висновок про завершеність стадії розробки;

6. чи існують технічні рішення, що потребують обґрунтування, чи припустимі ці обґрунтування, та чи не треба розглядати альтернативні варіанти, які забезпечують найкращі технічні характеристики за умовою виконання ПВ запланованих функцій;

7. чи погоджена розробка із суміжними розробками з точки зору її можливості випробування та здачі до експлуатації;

8. чи реальний графік проведення робіт наступного етапу з огляду на строки виконання за умови наявних ресурсів.

---