Результат зроблений сайт.

6. Індивіуальне завдання з технології програмування

Зміст 

1. Аналіз вимого до програмного продукту

2. Специфікація

3. Архітектура

4. Проектування, реалізація і тестування

5. Розповсюдження та підтримка

6. Гнучка модель розробки

7. Висновок

8. Список використаної літератури

Аналіз вимог до продукту

Найважливіше завдання при створенні програмного продукту - це вироблення вимог, або аналіз вимог до продукту. Замовник найчастіше представляє досить розмиту ідею про те, яким повинен бути кінцевий результат, і не має уявлення про те, як повинна працювати програма. Незакінчені, безглузді, а іноді суперечать один одному вимоги розпізнаються добрими інженерами на цій стадії. Часта демонстрація живого коду може зменшити ризик того, що початкові вимоги були не вірні. Один з методів знаходження проблем такого роду - це аналіз елементів програмного забезпечення.  Коли загальні вимоги отримані від клієнта, їх необхідно уточнити і відобразити в документі. Реалізована функціональність може відрізнятися від визначеної, в результаті високої вартості розробки та / або незрозумілих вимогах до продукту. Якщо розробка проводиться поза фірмою замовника, то даний документ може використовуватися для вирішення питань пов'язаних з функціональністю продукту. 

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

Специфікація

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

Архітектура

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

Проектування, реалізація і тестування

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

Розповсюдження та підтримка

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

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

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

Гнучка модель розробки

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

Термін з'явився у 2001 році, коли був написаний Маніфест гнучкої розробки.

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

Agile акцентує увагу на безпосередньому спілкуванні «віч-на-віч». Більшість agile команд розташовані в одному офісі, його іноді називають bullpen. Як мінімум вона включає і «замовників» (замовники, які визначають продукт, також це можуть бути менеджери продукту, бізнес аналітики або клієнти). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних авторів і менеджерів.

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

Гнучка модель розробки створена організаціями, що займаються розробкою ітераційної. Для цього використовується більш гнучкий, централізований на людях підхід, ніж використовується в традиційних підходах. Гнучкі процеси використовують зворотний зв'язок замість планування як головного контролюючого механізму. Зворотній зв'язок ведеться за допомогою регулярних тестів, а також частих релізів розробки продукту. Цікаво, що дослідження показують потенціал для хорошого поліпшення продуктивності щодо стандартного «Водопадного» методу. Наприклад дослідження, опубліковане в серпні 2006 року, і базоване на опитуваннях більш ніж 700 компаній, свідчить про величезний прибуток при використанні цієї моделі. Дослідження було повторене в серпні 2007 року з базою в 1,700 компаній.