4) Побудова моделі.

Розробка алгоритму - найскладніший і трудомісткий процес, але і найцікавіший в творчому відношенні. Вибір методу розробки залежить від постановки завдання, її моделі. На цьому етапі необхідно провести аналіз правильності алгоритму, що дуже непросто і трудомістко. Найбільш поширена процедура доказу правильності алгоритму - це прогін його на безлічі різних тестів. Проте, це не гарантує того, що не може існувати випадку, в якому програма «Не спрацює». У загальній методиці доказу правильності алгоритму припускають, що алгоритм описаний у вигляді послідовності кроків. Для кожного кроку пропонується якесь обґрунтування його правильності для всіх відповідних вхідних (умовах до даного кроку) і вихідних даних (умовах після цього кроку). Потім пропонується доказ скінченності алгоритму з остаточними початковими вхідними і вихідними даними.

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

• кодування;

• інтеграцію;

• тестування (сертифікацію).

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

Аналіз алгоритму і його складності необхідний для оцінки ресурсів комп'ютерів, на яких він працюватиме, часу обробки конкретних даних, пристосування в роботі в локальних мережах і телекомунікаціях. Хотілося б також мати для даного завдання кількісний критерій для порівняння декількох алгоритмів з метою вибору простішого і ефективнішого серед них.

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

Тестування - це процес виконання програм з метою виявлення (виявлення) помилок. Тестування - процес деструктивний, тому вважається, що тест вдалий, якщо виявлена помилка. Хорошим вважається тест, який має велику вірогідність виявлення ще не виявленої помилки. Вдалим вважається тест, який виявляє ще не виявлену помилку.

2. Основні особливості і проблеми сучасних програмних проектів

Накопичений до теперішнього часу досвід створення систем ПЗ показує, що це складна і трудомістка робота, що вимагає високої кваліфікації фахівців, що беруть участь в ній. Проте до теперішнього часу створення таких систем нерідко виконується на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на мистецтві, практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ПЗ. За даними Інституту програмної інженерії (Software Engineering Institute, SEI) останніми роками до 80% всього експлуатованого ПЗ розроблялося взагалі без використання якої-небудь дисципліни проектування, методом "code and fix" (кодування і виправлення помилок).

Проблеми створення ПЗ виходять з його властивостей. Ще в 1975 р. Фредерік Брукс, проаналізувавши свій унікальний на ті часи досвід керівництва найбільшим проектом розробки операційної системи OS/360, визначив перелік невід'ємних властивостей ПЗ: складність, узгодженість, змінність і незримість.

Характеристики особливостей сучасних великомасштабних проектів ПЗ:

а) Характеристики об'єкту впровадження:

• структурна складність (багаторівнева ієрархічна структура організації) і територіальна розподіленість;

• функціональна складність (багаторівнева ієрархія і велика кількість функцій, що виконуються організацією; складні взаємозв'язки між ними);

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

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

б) Технічні характеристики проектів створення ПЗ:

• різний ступінь уніфікації проектних рішень в рамках одного проекту;

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

• відсутність повних аналогів, що обмежує можливість використання яких-небудь типових проектних рішень і прикладних систем, висока частка знов розроблюваного ПЗ;

• велика кількість і висока вартість успадкованих застосувань (існуючого прикладного ПЗ), що функціонують в різному середовищі (персональні комп'ютери, мінікомп'ютери, мейнфрейми), необхідність інтеграції успадкованих і таких, що знов розробляються застосувань;

• велика кількість локальних об'єктів впровадження, територіально розподілене і неоднорідне середовище функціонування (СУБД, операційні системи, апаратні платформи);

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

в) Організаційні характеристики проектів створення ПЗ:

• різні форми організації і управління проектом: централізована керована розробка тиражованого ПЗ, експериментальні пілотні проекти, ініціативні розробки, проекти за участю як власних розробників, так і сторонніх компаній на контрактній основі;

• велика кількість учасників проекту як з боку замовників (з різнорідними вимогами), так і з боку розробників (більше 100 чоловік), роз'єднаність і різнорідність окремих груп розробників ПЗ рівню кваліфікації, традиціям, що склалися, і досвіду використання тих або інших інструментальних засобів;

• значна тривалість життєвого циклу системи, зокрема значна тимчасова протяжність проекту, обумовлена масштабами організації-замовника, різним ступенем готовності окремих її підрозділів до впровадження ПЗ і нестабільністю фінансування проекту;

• високі вимоги з боку замовника до рівня технологічної зрілості організацій-розробників (наявність сертифікації відповідно до міжнародних і вітчизняних стандартів).

В кінці 60-х років минулого століття в США було відмічено явище під назвою "software crisis" (криза ПЗ). Це виражалося в тому, що великі проекти стали виконуватися з відставанням від графіка або з перевищенням кошторису витрат, розроблений продукт не володів необхідними функціональними можливостями, продуктивність його була низька, якість отримуваного програмного забезпечення не влаштовувала споживачів.

Аналітичні дослідження і огляди, що виконуються протягом ряду останніх років провідними зарубіжними аналітиками, показували не дуже втішні результати. Так, наприклад, результати досліджень, виконаних в 1995 році компанією Standish Group, яка проаналізувала роботу 364 американських корпорацій і підсумки виконання більше 23 тисяч проектів, пов'язаних з розробкою ПЗ, виглядали таким чином:

• тільки 16,2% завершилися в строк, не перевищили запланований бюджет і реалізували всі необхідні функції і можливості;

• 52,7% проектів завершилися із запізненням, витрати перевищили запланований бюджет, необхідні функції не були реалізовані в повному об'ємі;

• 31,1% проектів були анульовані до завершення;

• для двох останніх категорій проектів бюджет середнього проекту виявився перевищеним на 89%, а термін виконання - на 122%.

У 1998 році процентне співвідношення трьох перерахованих категорій проектів лише небагато змінилося в кращу сторону (26%, 46% і 28% відповідно).

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

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

• нечітке і неповне формулювання вимог до ПЗ;

• недостатнє залучення користувачів до роботи над проектом;

• відсутність необхідних ресурсів;

• незадовільне планування і відсутність грамотного управління проектом;

• часта зміна вимог і специфікацій;

• новизна і недосконалість використовуваної технології;

• недостатня підтримка з боку вищого керівництва;

• недостатньо висока кваліфікація розробників, відсутність необхідного досвіду.

Об'єктивна потреба контролювати процес розробки складних систем ПЗ, прогнозувати і гарантувати вартість розробки, терміни і якість результатів привела в кінці 60-х років минулого століття до необхідності переходу від кустарних до індустріальних способів створення ПЗ і появі сукупності інженерних методів і засобів створення ПЗ, об'єднаних загальною назвою "Програмна інженерія" (software engineering). У основі програмної інженерії лежить одна фундаментальна ідея: проектування ПЗ є формальним процесом, який можна вивчати і удосконалювати. Освоєння і правильне застосування методів і засобів створення ПЗ дозволяє підвищити його якість, забезпечити керованість процесу проектування ПЗ і збільшити термін його життя.

В той же час, спроби надмірної формалізації процесу, а також прямого запозичення ідей і методів з інших областей інженерної діяльності (будівництва, виробництва) привели до ряду серйозних проблем. Після двох десятиліть марних очікувань підвищення продуктивності процесів створення ПЗ, що покладаються на нові методи і технології, фахівці в індустрії ПЗ пришли до розуміння, що фундаментальна проблема в цій області - нездатність ефективного управління проектами створення ПЗ. Неможливо досягти задовільних результатів від застосування навіть самих довершених технологій і інструментальних засобів, якщо вони застосовуються безсистемно, розробники не володіють необхідною кваліфікацією для роботи з ними, і сам проект виконується і управляється хаотично, в режимі "гасіння пожежі". Безсистемне застосування технологій створення ПЗ (ТС ПЗ), у свою чергу, породжує розчарування у використовуваних методах і засобах (аналіз думок розробників показує, що серед чинників, що впливають на ефективність створення ПЗ, використовуваним методам і засобам надається набагато менше значення, чим кваліфікації і досвіду розробників). Якщо в таких умовах окремі проекти завершуються успішно, то цей успіх досягається за рахунок героїчних зусиль фанатично настроєного колективу розробників. Постійне підвищення якості створюваного ПЗ і зниження його вартості може бути забезпечено тільки за умови досягнення організацією необхідної технологічної зрілості, створенні ефективної інфраструктури як у сфері розробки ПЗ, так і в управлінні проектами. Відповідно до моделі SEI СММ (Capability Maturity Model), в добре підготовленій (зрілою) організації персонал володіє технологією і інструментарієм оцінки якості процесів створення ПЗ впродовж всього життєвого циклу ПЗ і на рівні всієї організації.

Одна з причин поширеності "хаотичного" процесу створення ПЗ - прагнення заощадити на стадії розробки, не витрачаючи часу і засобів на навчання розробників і впровадження технологічного процесу створення ПЗ. Ці витрати до недавнього часу були досить значними і складали, за різними оцінками (зокрема, Gartner Group), більше $100 тис. і близько трьох років на впровадження розвиненої ТС ПЗ, що охоплює більшість процесів життєвого циклу ПЗ, в численній команді розробників (до 100 чіл.). Причина - в "тяжкості" технологічних процесів.

"Важкий" процес володіє наступними особливостями:

• необхідність документувати кожну дію розробників;

• безліч робочих продуктів (в першу чергу - документів), що створюються в бюрократичній атмосфері;

• відсутність гнучкості;

• детермінована (довгострокове детальне планування і передбаченість всіх видів діяльності, а також розподіл людських ресурсів на тривалий термін, що охоплює велику частину проекту.

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