Software Requirements, Software Requirements, Сторінка 3

Розробка та керування вимогами до програмного забезпечення

Опубліковано у Software Requirements

«Концепція системи та варіанти використання (use-cases)»

Доповідачі – співробітники компаній CSoft, Afisha Digital, Egar Technology, Luxoft

  • Цілепокладання як розробка моделі цілей, проблем та рішень
  • Ув'язування моделі цілей з моделями процесів та сутностей
  • Зразок моделі концептуального документа
  • Діаграми UC для узгодження інтересів
  • Відносини include та extend на практиці
  • Особливості UC, типові помилки та проблеми
  • Кордони застосування UC — коли потрібні бізнес-UC
  • Трансформація моделей UC в ході проекту з RUP: бізнес-UC, системні UC та модель класів
  • UC рівня реалізації як найточніші специфікації

Початок о 19:00, тривалість

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

Хто пише ТЗ на систему?

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

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

В ідеалі процес має виглядати так:

  1. Компанія-замовник(КЗ) пише бізнес-вимоги - своє розуміння проблеми, вирішити яку, як вона вважає, можна за допомогою автоматизації/впровадження, розробки інформаційних систем.
  2. Компанія-експерт (КЕ), яка добре знає предметну область замовника і має значні навички та досвід побудови ІВ проводить обстеження, будує бізнес-модель, переузгоджує бізнес-вимоги, пропонує концептуальне рішення — чи робити взагалі систему, якщо так, то якого типу і т.д. . - Тобто. розробляє Концепції автоматизації та техніко-економічні обґрунтування (ТЕО) на кожен варіант.
  3. Компанія-замовник обирає ту чи іншу концепцію автоматизації на підставі ТЕО.
  4. Компанія-експерт виходячи з обраного варіанта концепції розробляє технічне завдання на систему (ТЗ).
  5. Компанія-експерт розробляє приватні технічні завдання підсистеми (ЧТЗ).
  6. Компанія-розробник (КР, можливо - проектувальник, КП) створює ескізний та технічний проекти (ЕП, ТП) на підставі ТЗ, погодить їх з КЕ.
  7. Компанія-розробник створює систему та здає її послідовно (КП?), КЕ та КЗ.

У разі малих проектів як КЕ працює консультант-аналітик.

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

Цілепокладання та дерева рішень як основа планування успішного проекту

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

Поки що вимальовується ось що:

1. Проблема — це різниця між бажаним та існуючим (формулювання не моє, але мені подобається).

2. Бажане можна описати як набір зацікавлених осіб та ієрархії їх потреб, що належать до сфери проекту. Скажімо, з особистісними потребами по Маслоу ми активно працюємо у проекті з особистого психконсалтингу, у проекті з реорганізації бізнесу ми здебільшого працюємо з професійними потребами, у проекті зі створення масового сервісу — і з тими й іншими в рівній мірі, де професійні відповідають ролі людини, що використовує продукт/систему, що створюється, наприклад, «студент», «батько». Причому в моєму розумінні ієрахія потреб відрізняється від Масловської — кожен рівень випливає з вищого, що важить для цього відповідає на запитання «НАВІЩО?», нижчестоящий — «ЯК?».

3. Після того, як дерево потреб описано, на його вузли потрібно проставити мітки пріоритетності — які потреби для проекту є основними, обов'язкові, які — бажані, які — можливі.

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

5. Десь тут або раніше ми проводимо ресурсну оцінку способів реалізації та зіставляємо з наявними у замовника ресурсами.

6. На підставі зіставлення ресурсів вибираємо варіант побудови рішення, фіксуємо таким чином ключові завдання проекту та декомпозуємо їх план проекту.

Ще в менедесь про це стали критерії досягнення цілей.

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

Які питання ставити Замовнику, Експертам предметної галузі, IT-експертам та користувачам?

Знайшов гарне питання на форумі SQL.ru - «Які питання ставити Замовнику, Експертам предметної галузі, IT-експертам та користувачам перед проектуванням системи? Чи є якісь стандарти опису предметної галузі?»

Фактично йдеться про фази «Постановка бізнес-завдання», «Бізнес-моделювання» (Обстеження AS-IS, Проектування TO-BE), «Визначення вимог» та «Аналіз та проектування системи».

Постановку бізнес-завдання треба обговорювати із Замовником або майбутнім Власником системи.

Запитання, які йому варто поставити, це:

  1. Чому взагалі йшлося про створення системи?
  2. У чому Ви бачите її призначення?
  3. Які бізнес-можливості вона має реалізувати?
  4. Які проблеми має вирішити?

Як «Стандарт» на такі питання дивіться шаблон документа «Stakeholder Request», наприклад, з RUP. Бізнес-вимоги може висловити Замовник чи Експерти предметної галузі. Вони зазвичай фіксуються у вигляді списку з 10-30 ключових властивостей продукту - як шаблон див. Vision з RUP.

Бізнес-моделювання треба проводити на основі інформації від, а краще спільно з експертами предметної галузі. Питання по суті зводяться до «Що, чому, коли, як і ким відбувається в предметній галузі і як воно взаємопов'язане?»:

  1. Які основні поняття предметної галузі, їх визначення та взаємозв'язку? Результат можнаоформити у вигляді глосарію та/або концептуально-семантичної моделі предметної області.
  2. З яких правил — міжнародних, федеральних, муніципальних, районних тощо. законів, указів, стандартів, специфікацій, регламентів тощо. - Чи відбувається те, що відбувається в предметній області? Результат оформляєте як структурованого списку або прикріплюєте до елементів концептуальної моделі.
  3. Що реально (які процеси, події, факти) відбувається у якій послідовності, взаємозв'язку? Результат оформляєте у вигляді сценаріїв опису бізнес-процесів (що досить універсально) або діаграм SADT (IDEF0, IDEF3, DFD) / ARIS (eEPC і т.д.) / UML (Business Use-case Diagram (BUC) + Activity Diagram + Sequence Diagram). Це один із найскладніших етапів.
  4. Які властивості має кожне з виділених понять — структурні та поведінкові? Результат описується у вигляді таблиць з атрибутами Концептуальних сутностей або Детальної концептуальної моделі - ER - IDEF1X / UML Class Diagram (BOM).

Існує український стандарт функціонального моделювання P50.1.028-2001, створений на основі IDEF0.

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

  1. На яку систему буде схожа створювана?
  2. З якими системами та як давно ви працюєте?
  3. Яка у вас освіта?
  4. Які ваші очікування від системи - що і як вона повинна робити, які завдання допомагати вирішувати, як маєвиглядати?
  5. Які кроки необхідно зробити для вирішення кожного завдання?
  6. У якому разі ви вважатимете, що система «Хороша»?

Результати анкетування/інтерв'ювання зазвичай представляють у вигляді історій користувача (User Story, Agile) або Користувацьких сценаріїв (Use-case), також можливе їх діаграмне представлення засобами діаграм потоку робіт (IDEF3), ARIS, Activity/State UML Diagram. Докладніше про роботу з Користувачами можуть розповісти фахівці з Проектування взаємодії, інтерфейсів та ергономіки.

Системні вимоги потрібно з'ясовувати у IT-фахівців Замовника, якщо такі є, зі специфіки контексту використання системи, досвіду побудови аналогічних систем (у IT-Експертів-Архітекторів) та Фахівців з окремих аспектів системи, значимих для даного проекту (Юристи, Ергономісти тощо) .д.) та Замовника:

  1. Чи буде система одиничною чи тиражованою?
  2. У яких країнах вона працюватиме?
  3. Наскільки важливою є інформація, що зберігається, обробляється і передається системою?
  4. Які можливі збитки від втрати тієї чи іншої інформації?
  5. Скільки користувачів буде працювати із системою сьогодні, завтра, через рік?

Перероблений результат оформляється у вигляді Системних вимог (Software Requirement Specification, стандарт IEEE-STD-830-1998 або ТЗ ГОСТ 34-602-89 або неформально у вигляді Supplementary Specificaion з RUP).

МСК - Зустріч на тему "Спільнота IT-консультантів, аналітиків та архітекторів"

Цими вихідними пройде зустріч спільно з UML2.ru на тему становлення та розвитку спільноти IT-консультантів та розробників ІС.

Програма: 1. Знайомство, самопрезентація. 2. Визначення зацікавлених осіб (ролей, ЗЛ), які маютьставлення до сфери IT-консалтингу та розробки систем. 3. Визначення їх потреб та інтересів. 4. Визначення існуючих способів та інструментів закриття потреб ЗЛ та реалізації можливостей (+SWOT-аналіз?), опис проблем існуючих рішень та методів. 5. Визначити пріоритети інтересів та виробити варіанти розвитку/зміни ситуації в області. 6. Визначити відповідальних напрями. 7. Визначити цілі в кожному напрямку. 8. Визначити завдання з кожної мети та орієнтовні терміни та потреби в ресурсах. + під час обговорення CASE-ів, прикладів тощо. + якісь нові паралельні теми.

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