Лекція 2. Поняття процесу проектування програмних продуктів

Чим програмування відрізняється від програмної інженерії? Тим, що перше є деякою абстрактною діяльністю і може відбуватися в багатьох різних контекстах. Поняття процесу розробки ПО. Універсальний процес. Поточний процес. Конкретний процес. Стандартний процес. Вдосконалення процесу.

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

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

Всі ці і інші додаткові види діяльності, що виконуються в процесі промислового програмування і необхідні для успішного виконання замовлень і називатимемо програмною інженерією (software engineering). Виходить, що так ми позначаємо, по-перше, деяку практичну діяльність, а по-друге, спеціальну область знання. Або іншими словами, наукову дисципліну. Адже для полегшення виконання кожного окремого проекту, для можливості використовувати різноманітний позитивний досвід, досягнутий іншими командами і розробниками, цей самий досвід піддається осмисленню, узагальненню і належному оформленню. Так з'являються різні методи і практики (best practices) – тестування, проектування, роботи над вимогами і ін., архітектурних шаблонів і ін. А також стандарти і методології, що стосуються всього процесу в цілому (наприклад, MSF, RUP, CMMI, Scrum). Ось ці-то узагальнення і входять в програмну інженерію як в область знання.

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

Информатика (computer science) – это свод теоретических наук, основанных на математике и посвященных формальным основам вычислимости. Сюда относят математическую логику, теорию грамматик, методы построения компиляторов, математические формальные методы, используемые в верификации и модельном тестировании и т.д. Трудно строго отделить программную инженерию от информатики, но в целом направленность этих дисциплин различна. Программная инженерия нацелена на решение проблем производства, информатика – на разработку формальных, математизированных подходов к программированию.

Системотехніка (system engineering) об'єднує різні інженерні дисципліни по розробці всіляких штучних систем – енергоустановок, телекомунікаційних систем, вбудованих систем реального часу і так далі Дуже часто ПО виявляється частиною таких систем, виконуючи завдання управління відповідного устаткування. Такі системи називаються програмно-апаратними, і беручи участь в їх створенні, програмісти вимушені глибоко розбиратися в особливостях відповідної апаратури.

Бізнес-рєїнжінірінг (business reengineering) – в широкому сенсі позначає модернізацію бізнесу в певній компанії, впровадження нових практик, підтримуваних відповідними, новими інформаційними системами. При цьому акцент може бути як на внутрішньому перевлаштуванні компанії так і на розробці нового клієнтського сервісу (як правило, ці питання взаємозв'язані). Бізнес-рєїнжінірінг часто передує розробці і впровадженню інформаційних систем на підприємстві, оскільки потрібний спочатку навести певний лад в діловодстві, а лише потім закріпити його інформаційною системою.

Зв'язок програмної інженерії (як області практичної діяльності) з інформатикою, системотехнікою і бизнес-реинжинирингом показана на рис. 2.1.

Рис. 2.1. 

Поняття програмного забезпечення

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

Це визначення, дане Харальдом Мілсом, відомим фахівцем в області програмної інженерії з компанії IBM, містить в собі наступне.

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

2. Сучасне ПО призначено, як правило, для одночасної роботи з багатьма користувачами, які можуть бути значно віддалені один від одного у фізичному просторі. Таким чином, обчислювальне середовище (персональні комп'ютери, сервера і так далі), в якому ПО функціонує, виявляється розподіленим.

3. Задачи решаемые современным ПО, часто требуют различных вычислительных ресурсов в силу различной специализации этих задач, из-за большого объема выполняемой работы, а также из соображений безопасности. Например, появляется сервер базы данных, сервер приложений и пр. Таким образом, вычислительная среда, в которой ПО функционирует, оказывается многопроцессорной.

4. ПО розвивається в часі – виправляються помилки, додаються нові функції, випускаються нові версії, міняється його апаратна база.

Властивості. Таким чином, ПО є складною динамічною системою, що включає технічні, психологічні і соціальні аспекти. ПО помітно відрізняється від інших видів систем, що створюються (створених) людиною, – механічних, соціальних, наукових і ін., і має наступні особливості, виділені Фредеріком Бруксом в його знаменитій статті "Срібної кулі немає".

1. Складність програмних об'єктів, яка істотно залежить від їх розмірів. Як правило, більше ПО (більша кількість користувачів, більший об'єм оброблюваних даних, жорсткіші вимоги по швидкодії і ін.) з аналогічною функціональністю – це інше ПО. Класична наука будувала прості моделі складних явищ, і це вдавалося, оскільки складність не була характеристичною межею даних явищ. (Порівняння програмування саме з наукою, а не з театром, кінематографом, спортом і іншими областями людської діяльності, виправдано, оскільки воно виникло, головним чином, з математики, а перші його плоди – програми – призначалися для використання при наукових розрахунках. Крім того, більшість програмістів мають природничонаукову, математичну або технічну освіту. Таким чином, парадигми наукового мислення широко використовуються при програмуванні – явно або неявно.)

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

3. Змінність – ПО легко змінити і, як наслідок, вимоги до нього постійно міняються в процесі розробки. Це створює багато додаткових труднощів при його розробці і еволюції.

4. Нематеріальність²⁾ – ПО неможливо побачити, воно віртуальне. Тому, наприклад, важко скористатися технологіями, заснованими на попередньому створенні креслень, успішно використовуваними в інших промислових областях (наприклад, в будівництві, машинобудуванні). Там на кресленнях в схемному вигляді відтворюються геометричні форми створюваних об'єктів. Коли об'єкт створений, ці форми можна побачити. А на чому ми грунтуємося, коли зображаємо ПО?

Процес розробки ПЗ

Как мы работаем, какова последовательность наших шагов, каковы нормы и правила в поведении и работе, каков регламент отношений между членами команды, как проект взаимодействует с внешним миром и т.д.? Все это вместе мы склонны называть процессом. Его осознание, выстраивание и улучшение - основа любой эффективной групповой деятельности. Поэтому не случайно, что процесс оказался одним из основных понятий программной инженерии.

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

Проте на сьогоднішній день не існує універсального процесу розробки ПО – набору методик, правив і розпоряджень, відповідних для ПО будь-якого вигляду, для будь-яких компаній, для команд будь-якої національності. Кожен поточний процес розробки, здійснюваний деякою командою в рамках певного проекту, має велику кількість особливостей і индивидуальностей. Проте доцільно перед початком проекту спланувати процес роботи, визначивши ролі і обов'язки в команді, робочі продукти (проміжні і фінальні), порядок участі в їх розробці членів команди і так далі Називатимемо цей попередній опис конкретним процесом, відрізняючи його від плану робіт, проектних специфікацій і ін. Наприклад, в системі Microsoft Visual Tem System опиняється шаблон процесу, що створюється або адаптується (у разі використання стандартного) перед початком розробки. У VSTS існують заготовки для конкретних процесів на базі CMMI, Scrum і ін.

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

• інформацію, правила використання, документацію і інсталяційні пакети засобів розробки, використовуваних в проектах компанії (систем версионного контролю, засобів контролю помилок, засобів програмування – різних IDE, СУБД і так далі);

• опис практик розробки – проектного менеджменту, правил роботи із замовником і т.д.;

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

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