23. Життєвий цикл програмного продукту.

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

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

Життєвий цикл - це проекція призначеного для користувача поняття “Час життя” на поняття розробника технологічний цикл (цикл розробки)”. Комбінацією цих термінів пояснюється, мабуть, походження самого терміну “життєвий цикл програмного забезпечення”.

24. Життєвий цикл в об’єктно-орієнтованому проектуванні.

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

полягає в наступному. На кожній фазі проекту будуються працездатні продукти, що розвиваються надалі шляхом збагачення функціональності і інтерфейсу, а не в жорстких рамках попереднього технічного опису в цілому, яке будується в ході спеціального етапу конструювання, що передбачається в традиційних схемах. Як наслідок, традиційні фази розвитку проекту в ході окремої ітерації виявляються незавершеними, вони доповнюються (нарощуються) на наступних ітераціях. Цей принцип багато в чому трансформує поняття життєвого циклу : якщо раніше продукт-виріб вироблявся лише до кінця періоду розробки, то тепер на кожній ітерації з'являються відносно закінчені робочі продукти. Також трансформується поняття документації : замість Технічного опису, що з'являється як підсумок конструювання, розробляється Робочий опис, що доповнюється на кожній ітерації. В таблиці. 1.1 приводиться зіставлення особливостей традиційних і об'єктно-орієнтованих схем життєвого циклу.

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

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

25. Заявка на проект.

Для освітлення вказаних тільки що аспектів перед замовником доцільно розробити

спеціальний документ, що іменується надалі як "Заявка на проект". Залежно від ситуації

назва документу може бути іншою ("Пропозиція розробки", "Заявка на грант" та ін.), але у

будь-якому випадку від менеджера вимагається скласти документ, який:

точно визначає, що ви маєте намір зробити для замовника. Зокрема, повинно бути

чітко виділено, що конкретно ви збираєтеся виробляти для нього;

переконує замовника, що ваша пропозиція розробки задовольнить його потреби

краще, ніж те, що в змозі запропонувати інші компанії;

описує для замовника, як ви маєте намір здійснювати свій задум, включаючи ті деталі,

які доводять, що ви добре розумієте проблеми проекту;

створює у замовника абсолютну впевненість в тому, що ви маєте достатні можливості

для отримання заявлених результатів;

включає повну інформацію, яка потрібна для фінансування проекту, запропонованого

вам.

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

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

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

Таблиця 3.1

Конкурсне замовлення Цільове замовлення

Особливості:

конкретний проект

конкурентний вибір виконавця

Особливості:

завдання може варіюватися

послідовний вибір виконавця

фіксована форма

заявки

вільна форма

заявки

Мета: підвищити

об'єктивність при

виборі виконавця

Мета: розширити круг

відомостей, що оціню-

ються при виборі

виконавця

Мета: точніше встановити відповідність

Проект-Виконавці

Взагалі, отримання конкурсного замовлення завжди призводить або до відмови від

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

виконавцями. У останньому випадку можливо, що одне замовлення розміщують у

невеликого числа виконавців з наступною відмовою від послуг тих з них, у кого результати

(поточні або остаточні) виявляються гірше, ніж у конкурентів. Працюючи із заявкою у

фіксованій формі, менеджер повинен добре собі представляти можливі і найпривабливіші

для замовника відповіді. Не варто зловживати невизначеними відповідями (типу ”Важко

відповісти”). Тим самим вказується на обмеженість круга питань компетентності

претендента.

Особливу увагу слід приділяти позиціям документу, які відбивають кваліфікацію і

потенційні можливості виконавця. Тут завжди є місце свавіллю. Ви можете не вказати,

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

причин: через те, що цей досвід виявився невдалим, що основні працівники команди

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

Яка буде реакція на це з боку потенційного замовника? Відповідь неоднозначна. Він може

просто не помітити, що у вас є досвід, не відбитий в заявці, і це мінус з точки зору оцінки

ваших можливостей. Якщо замовник виявився обізнаним про ваш, приміром, невдалий

досвід і помітив це, то результат оцінки залежить від критеріїв (що більше важливе для

замовника: ваша самооцінка або ваше прагнення приховати небажане). Проте, в більшості

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

Але з іншого боку, не слід перебільшувати свій досвід і компетентність. Навіть якщо

представлену інформацію важко перевірити, можна потрапити в ситуацію, коли

недобросовісні дані зроблять вам ведмедячу послугу (наприклад, вказавши, що колектив

володіє досвідом програмування на деякій мові, ви ризикуєте отримати додаткові витрати на

навчання).__