Сьогодні процес створення складних програмних програм неможливо уявити без поділу на етапи життєвого циклу. Під життєвим циклом програми розумітимемо сукупність етапів:

• Аналіз предметної галузі та створення ТЗ (взаємодії із замовником)
• Проектування структури програми
• Кодування (набір програмного коду згідно з проектною документацією)
• Тестування та налагодження
• Впровадження програми
• Супровід програми
• Утилізація

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

UML – є графічною мовою для візуалізації, опису параметрів, конструювання та документування різних систем (програм зокрема). Діаграми створюються за допомогою спеціальних CASE засобів, наприклад Rational Rose (http://www-01.ibm.com/software/rational/) та Enterprise Architect (http://www.sparxsystems.com.au/). На основі технології UML будується єдина інформаційна модель. Наведені вище CASE засоби здатні генерувати код різними об'єктно-орієнтованими мовами, а також мають дуже корисною функцієюреверсивного інжинірингу. (Реверсивний інжиніринг дозволяє створити графічну модель з наявного програмного коду та коментарів до нього.)

Розглянемо типи діаграм для візуалізації моделі (це must have, хоча типів набагато більше):

Діаграма варіантів використання (use case diagram)

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

Діаграма класів (class diagram)

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

Діаграма станів (statechart diagram)

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

Діаграма послідовності (sequence diagram)

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

Діаграма кооперації (collaboration diagram)

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

Діаграма компонентів (Component Diagram)

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

Діаграма розгортання (deployment diagram)

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

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

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

Розробка програмного продукту знає багато гідних методологій - інакше кажучи, усталених best practices. Вибір залежить від специфіки проекту, системи бюджетування, суб'єктивних переваг і навіть темпераменту керівника. У статті описані методології, з якими регулярно стикаємося в Едісоні.

1. "Waterfall Model" (каскадна модель або "водоспад")

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

За допомогою каскадної моделі ми створили безліч проектів з нуля, включаючи розробку тільки ТЗ. Проекти, про які написано на Хабрі: середній -, дрібний -.

Коли використати каскадну методологію?

• Тільки тоді, коли вимоги відомі, зрозумілі та зафіксовані. Суперечливих вимог немає.
• Немає проблем із доступністю програмістів потрібної кваліфікації.
• У відносно невеликих проектах.

2. "V-Model"

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

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

Коли використовувати V-модель?

• Якщо потрібно ретельне тестування продукту, то V-модель виправдає закладену у собі ідею: validation and verification.
• Для малих та середніх проектів, де вимоги чітко визначені та фіксовані.
• У разі доступності інженерів необхідної кваліфікації, особливо тестувальників.

3. «Incremental Model» (інкрементна модель)

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

Інкрементні моделі використовуються там, де окремі запити на зміну зрозумілі, можуть бути легко формалізовані та реалізовані. У наших проектах ми застосовували її для створення читалки DefView, а потім і мережі електронних бібліотек Vivaldi.

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

Коли використати інкрементну модель?

• Коли основні вимоги до системи чітко визначені та зрозумілі. У той самий час деякі деталі можуть допрацьовуватися з часом.
• Потрібно раннє виведення товару ринку.
• Є кілька ризикових фіч чи цілей.

4. "RAD Model" (rapid application development model або швидка розробка додатків)

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

Модель швидкої розробки додатків включає такі фази:

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

Коли використовується модель RAD?

Може використовуватися лише за наявності висококваліфікованих та вузькоспеціалізованих архітекторів. Бюджет проекту великий, щоб сплатити цих фахівців разом із вартістю готових інструментів автоматизованого збирання. RAD-модель може бути обрана за впевненого знання цільового бізнесу та необхідності термінового виробництва системи протягом 2-3 місяців.

5. "Agile Model" (гнучка методологія розробки)

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

В основі такого типу – нетривалі щоденні зустрічі – «Scrum» і регулярно повторювані збори (раз на тиждень, раз на два тижні або раз на місяць), які називаються «Sprint». На щоденних нарадах учасники команди обговорюють:

• звіт про виконану роботу з моменту останнього Scrum'a;
• список завдань, які співробітник має виконати до наступних зборів;
• складнощі, що виникли під час роботи.

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

Коли використовувати Agile?

• Коли потреби користувачів постійно змінюються у динамічному бізнесі.
• Зміни на Agile реалізуються за меншу ціну через часті інкременти.
• На відміну від моделі водоспаду, у гнучкій моделі для старту проекту достатньо лише невеликого планування.

6. "Iterative Model" (ітеративна або ітераційна модель)

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

На діаграмі показано ітераційну «розробку» Мона Лізи. Як видно, у першій ітерації є лише малюнок Джоконди, у другій – з'являються кольори, а третя ітерація додає деталей, насиченості та завершує процес. В інкрементної моделі функціонал продукту нарощується по шматочках, продукт складається з частин. На відміну від ітераційної моделі, кожен шматочок є цілісним елементом.

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

Коли оптимально використати ітеративну модель?

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

7. "Spiral Model" (спіральна модель)

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

Спіральна модель передбачає 4 етапи для кожного витка:

1. планування;
2. аналіз ризиків;
3. конструювання;
4. оцінка результату та при задовільній якості перехід до нового витка.

Ця модель не підійде для малих проектів, вона є резонною для складних і дорогих, наприклад, таких, як розробка системи документообігу для банку, коли кожен наступний крок вимагає більшого аналізу для оцінки наслідків, ніж програмування. На проекті з розробки СЕД для ОДУ Сибіру СВ ЄЕС дві наради про зміну кодифікації розділів електронного архіву займають у 10 разів більше часу, ніж об'єднання двох папок програмістом. Державні проекти, в яких ми брали участь, розпочиналися з підготовки експертною спільнотою дорогої концепції, яка аж ніяк не завжди марна, оскільки окупається в масштабах країни.

Підсумуємо

На слайді продемонстровано відмінності двох найпоширеніших методологій.

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

Про технології розробки:
.
.
.
.

Які методології ви використовуєте?