Як використовувати System Engineering для створення успішної веб-програми

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

Отже, ви нарешті завершили свій дизайн в Adobe XD, Figma, Sketch або InVision, але все ще боретеся з ідеєю, як реалізувати функціонал. Не хвилюйтесь, ми деякий час думали, що єдиним способом створення веб-додатків є початок з дизайну інтерфейсу користувача / UX разом із ескізами прототипів.

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

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

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

Наприкінці цієї статті ви зможете використовувати деякі з цих методів SE для створення кращих програм.

Ось чотири практичні та відповідні методи SE, які ви можете застосувати.

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

Практичний приклад - Інтернет-платформа навчання

Для того, щоб зробити приклади інтуїтивно зрозумілими та застосовними, ми створимо притворну онлайн-платформу навчання. Платформа, яка дозволяє людям публікувати вміст, таку ж концепцію, як Medium, YouTube, Unsplash тощо.

Примітка: Ідея використання цих методів полягає в тому, щоб описати їх досить, щоб розробники могли легко реалізувати ці функції, а це означає, що нам не потрібно вдаватися в деталі.

Ось кілька приємних порад, про які слід знати на ранніх стадіях програми.

1. Не починайте з детального дизайну

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

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

2. Почніть із проблеми

Спочатку визначте проблему: оточення, хто є зацікавленими сторонами, поведінка та контекст програми (сфера застосування).

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

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

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

Давайте подивимося, якими методами ми можемо описати нашу онлайн-платформу навчання.

1. Контекстна діаграма

Визначте межі

Мета контекстної діаграми - визначити межі програми або її частини та чітко зрозуміти, з якими об’єктами вона взаємодіє.

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

Уточнити складні програми

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

2. Використовуйте схему випадків

Зауважте, ми нічого не згадуємо про компонування, розмір чи розташування елементів. У SE важливо, щоб речі були модульними, це означає, що ми можемо змінювати речі, не впливаючи на додаток - ми не хочемо, щоб речі були виправленими та незмінними.

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

Опишіть взаємодії

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

Розробити варіант використання (дія)

Як показано вище, користувач є виробником вмісту та виконує чотири дії. Дія - це функція, яку потрібно реалізувати. Діаграма випадків використання не описує поведінку програми, за винятком взаємодії між користувачем та програмою або її частинами.

Для того, щоб описати поведінку, ми можемо зробити одну дію та розробити її за допомогою таких діаграм, як дія, автомат стану, діаграми послідовностей тощо.

Наприклад, ми можемо створити діаграму діяльності, щоб описати кроки, необхідні для виконання дії “завантаження вмісту”. Приклад цього є в розділах 3 та 4.

Зосередьтеся на різних сценаріях використання

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

3. Діаграма діяльності

Опишіть поведінку

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

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

Опишіть кроки для досягнення мети

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

Висловлюйте ідеї за допомогою дизайну

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

Загалом, це чудовий інструмент для висловлювання ідей та думок людям, а не просто покладання на словесне спілкування.

4. Діаграма автомата держави

Дайте визначення станів

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

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

Заключні думки

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

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

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

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

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

  • Практичний посібник з модулів ES6
  • Як виконувати HTTP-запити за допомогою API Fetch
  • Порівняння між Angular та React
  • Підвищте свої вміння за допомогою цих важливих методів JavaScript
  • Хаотичний розум веде до хаотичного коду
  • Розробники, які постійно хочуть пізнавати нові речі
  • Вивчіть ці основні веб-концепції
  • Програмуйте швидше, створюючи власні команди bash

Ви можете знайти мене в Medium, де я публікую щотижня. Або ви можете стежити за мною у Twitter, де я публікую відповідні поради та підказки щодо веб-розробки.