Лекція 3. Організація технологічного процесу розробки ПЗ

Лекція 3. Організація технологічного процесу розробки ПЗ

1. Процес створення програмного забезпечення

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

1.1.Основні стадії типового процесу створення ПП

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

Виділяють 4 основні стадії процесу:

Специфікація: формулювання основних вимог до ПЗ (що повинна робити система). Розробка: створення ПЗ відповідно до специфікацій.

Атестація: перевірка ПЗ на відповідність потребам замовника. Модернізація: розвиток ПЗ відповідно до потреб замовника, що змінилися.

Всі стадії засновані на спеціальних технологіях. Наприклад, розглянуті стисло в попередній лекції модульне, структурне, об'єктно-орієнтоване, компонентне програмування відносяться до стадії Розробки.

Кожна організація може організувати процес створення програмного забезпечення так, як їй це представляється розумним. Цей процес може мати різний ступінь формалізації. Так, створення продукту може йти за принципом "увечері обговорили і домовилися", але цей принцип працює тільки для команд з 2-3 чоловік в достатньо простих проектах. Можлива інша крайність - кожна дія жорстко визначена і прописана в описі процесу. В цьому випадку виникає необхідність тривалого попереднього навчання співробітників роботі в рамках цього, безумовно, складного опису. Подібний підхід, звичайно, породжує і інші накладні витрати. Наприклад, те, що цілком могло б бути вирішене в приватній бесіді, тепер доводиться довго і нудно "проводити" через відповідний формалізм. Мабуть, такий ступінь формалізації може піти на користь для дуже великих, тим більше розподілених, колективів, вирішальних завдання великої складності. Для невеликого або середнього проекту описаний ступінь формалізації принесе більше шкоди, чим користі (хороша аналогія - забивання цвяхів мікроскопом).

21