Ім'я файлу: Методичні вказівки до командного проекту (1).docx
Розширення: docx
Розмір: 639кб.
Дата: 30.11.2021
скачати

Методичні вказівки

до виконання групового проекту

з курсу

«Проектування інформаційних систем»

Автор:

доцент кафедри АСУ, к.т.н. Дорошенко А.В.

  1. Формулювання вимог до проекту та їх оформлення аналогічно до лабороторної роботи з ПІС №1.

  2. Проведення SWOT-аналізу для задачі, яка реалізується в проекті.

  3. Побудова матриці Захмана для архітектури ІС, що розробляється.

  4. Побудова основних типів UML-діаграм, для системи, що розробляється (Use Case Diagram, Class Diagram, Activity Diagram, Sequence Diagram).

Всі прецеденти мають бути описані за таким взірцем:

Assume that one of the identified use cases is the “List Transactions”. The following text is taken from the Use Case Full Text document:

Name: List Transactions

Description: A list of the transactions of the customer’s account is displayed

Precondition: Customer is logged in.

Post Condition: A list of transactions for a selected account has been displayed to the customer.

Main Success Scenario: The system displays the list of the accounts, associated to the customer. The customer selects an account. The system displays a list of options available for this account. The customer selects the option to list the transactions. The system lists the transactions of the last 30 calendar dates to the customer.

Alternative Scenario: The user may choose to constrain the dates for the listed transactions. Dates should be in the past and in order (begin date before the end date). In this case, the system lists only the transactions between those dates.

Відповідно, для всіх прецедентів необхідно побудувати Activity Diagram.

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

  2. Розробити спроектовану систему відповідно до сформульованих вимог.

2. SWOT-аналіз

Сутність і значення SWOT-аналізу


Кожна організація (підприємство) має на ринку певні переваги і наділена недоліками. SWOT-аналіз (strength, weaknesses, opportunities and threats) - дає змогу виявити ті сильні і слабкі сторони, які потребують найбільшої уваги і зусиль з боку підприємства. Перед початком SWOT-аналізу комплексно зосереджуються на ймовірних загрозах і можливостях, що постають перед виробником. Після цього слід з'ясувати, які загрози є найбільш імовірними і які ризики вони здатні спричинити. Саме вони потребують найбільшої уваги і концентрації зусиль з метою їх усунення.

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

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

Аналіз сильних і слабких сторін, шансів і загроз


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

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

Сильні і слабкі сторони оцінюють стосовно конкурентів та умов зовнішнього середовища. У пошуку сильних і слабких сторін можна використати певну систему критеріїв (табл. 1.34).



Рис. 1.11. Аналіз шансів і загроз, сильних і слабких сторін

Таблиця 1.34. Пошук сильних і слабких сторін

Сфера пошуку
Слабкі сторони (значення)
Сильні сторони (значення)



велике
середнє
мале
велике
середнє
мале



1
2
3
4
5
6
7



Маркетинг-мікс





















Товар





















Ціна





















Дистрибуція





















Просування





















Персонал





















Організація маркетингу на підприємстві





















Клієнти


















Репутація підприємства


















Ринок


















частка


















географічне охоплення




























































Застосуванню SWOT-аналізу повинен передувати аналіз з використанням поширених у розвинутих країнах методів PEST і PRESTCOM. Одержаною з їх допомогою ринковою інформацією послуговуються для з'ясування шансів і загроз підприємству на ринку.

Аналіз PEST (political, economic, social, technological factors) полягає в ідентифікації й оцінюванні політичних, економічних, соціально-культурних, технологічних чинників.

Метод PRESTCOM (regulatory, competitione, organizational market factors) охоплює аналіз регуляційних, конкурентних, організаційних, ринкових чинників. Він дає змогу побачити загальні чинники (як у країні, , так і на міжнародному ринку), які впливають на діяльність підприємства, встановити основні тенденції, на які потрібно звернути увагу при проектуванні стратегії і в поточній діяльності (табл. 1.35).

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

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

Таблиця 1.35. Аналіз PRESTCOM
Чинники
Рівень







внутрідержавний
міжнародний

P
Політичні
Політика уряду, політична

стабільність, податки
Позиції щодо міжнародних підприємств

R
Регуляційні
Внутрішні правові норми
Правові норми регулювання міжнародної торгівлі, діяльності мас-медіа, відносин між країнами

Е
Економічні
Споживчий попит, економічний розвиток, інфраструктура, стабільність валюти
Фінансові структури, розвиток мас-медіа, курси валют

S
Соціальні
Культура, цінності, стиль життя, норми і поведінка, етичні і моральні стандарти
Культура, ставлення до , іноземних фірм

Т
Технологічні
Телекомунікація,

інформаційні

технології
Доступ до спеціальних знань і їх трансфер із закордону

С
Конкурентні
Інтенсивність і різноманітність конкуренції
Пошук кадрів, відмінності в структурі І затрат

O
Організаційні
Сильні і слабкі сторони, планування, структура
Орієнтація фірми, ступінь централізації, зв'язки з філіалами

м
Ринкові
Затрати на сировину, попит, обсяг (потенціал) ринку, фаза циклу життя, застосування і функціональність продукту, демографічна структура
Масштаби

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

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

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

Крім ідентифікації змін, необхідно оцінити їх сферу, динаміку і результати. Отримані при цьому дані можуть бути систематизовані у спеціальній таблиці (табл. 1.36).

Таблиця 1.36. Аналіз середовища підприємства

У чому полягають зміни
У якому темпі вони розвиваються
Коли появляються

перші результати
Які будуть результати

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



















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

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

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

Шаблон SWOT-аналізу


Назва проекту:

Діятельність:

Мета аналіза:
Корисні для досягнення мети
Перешкоди в досягненні мети

Внутрішні фактори
Сильні сторони
Слабкі сторони

Зовнішні фактори
Можливості
Загрози

Висновки:

  1. Побудова матриці Захмана для підприємства-замовника.

Структура Захмана для архітектури підприємств

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

«Каркас для підтримки або укладення інших об'єктів, особливо скелетної підтримки, яку використовують як основи для будь-якої конструкції; Зовнішня робоча платформа; ліси; Фундаментальна структура (в письмових роботах); Набір припущень, концепцій, характеристик і практик, що становлять спосіб представлення реальності. [11]».

З іншого боку, таксономія визначається наступним чином:

«Класифікація організмів у впорядкованій системі, яка відображає природні зв'язку; Наука, закони і принципи класифікації; систематика; Розбиття на впорядковані групи або категорії [12]»

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

Джон Захмана так описав свою роботу:

«Структура [архітектури підприємства] по відношенню до підприємств являє собою просто логічну структуру для класифікації та впорядкування описових уявлень підприємства, істотно важливих для управління підприємством, а також для розробки корпоративних систем». [13]

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

«... рано чи пізно ви виявите, що структура Захмана присутній у всьому, чим ви займаєтеся, а не тільки в ІТ-проектах. Коли ви зрозумієте структуру Захмана, ви станете більш ефективним у всьому. У всьому, не більше і не менше. Це твердження абсолютно серйозно ». [14]

Сам Джон Захмана сказав мені в своєму недавньому інтерв'ю наступне:

«... схема структури використовувалася кілька тисяч років, і я впевнений, буде використовуватися ще кілька тисяч років. Змінюється тільки наше розуміння структури і принципи її використання у проектуванні підприємств та виробництві ». [15]

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

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

У вихідній статті Захмана говорить наступне:

«... кожне архітектурне уявлення відрізняється від інших по суті, а не тільки рівнем деталізації». [16]

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

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

З точки зору власника бізнесу, «дані» - це бізнес-об'єкти. Ці дані можуть включати відомості як про самих об'єктах, наприклад про клієнтів і продукції, так і про відносини між цими об'єктами, наприклад про демографічні групах і складські запаси. У розмові про дані з власником бізнесу слід використовувати саме цю мову.

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

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

«Ми зазнаємо труднощів при обговоренні один з одним архітектури інформаційних систем, оскільки замість єдиної архітектури використовується набір архітектурних уявлень. При такому положенні справ не мають рації обидва учасники обговорення. Архітектури різні. Вони взаємно доповнюють один одного. Існують вагомі причини виділити ресурси на розробку кожного архітектурного уявлення. Якщо будь-які архітектурні уявлення не розроблені, організація стикається з цим ризиком ». [18]



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



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

Таблиця Захмана може допомогти компанії MedAMore в розробці архітектури MAM-EA трьома способами.

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

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

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

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

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

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

Отже, існує п'ять способів використання таблиці Захмана при розробці архітектури MAM-EA. Таблиця Захмана дозволяє:

  • Переконатися в тому, що точка зору кожного зацікавленої особи була розглянута в кожному описовому аспекті.

  • Поліпшити артефакти архітектури MAM-EA шляхом точної підгонки описових аспектів під конкретну аудиторію.

  • Переконатися в тому, що всі бізнес-вимоги Брета зводяться до технічної реалізації.

  • Переконати Брета в тому, що технічні фахівці Ірми не планують реалізовувати непотрібні функції.

  • Переконати Ірму в тому, що співробітники бізнес-підрозділу враховують при плануванні інтереси ІТ-фахівців.

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

https://msdn.microsoft.com/ru-ru/library/ee914379.aspx#_%D0%A1%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0_%D0%97%D0%B0%D1%85%D0%BC%D0%B0%D0%BD%D0%B0_%D0%B4%D0%BB%D1%8F

  1. Побудова основних типів UML-діаграм, для системи, що розробляється (Use Case Diagram, Class Diagram, Activity Diagram, Sequence Diagram).

Для побудови UML-діаграм я б дуже радила Вам використати програмний засіб – Enterprice Architect (https://sparxsystems.com/products/ea/14/index.html). Він має Trial-версію на 30 днів. А також дуже детальну та зрозумілу документацію (https://sparxsystems.com/enterprise_architect_user_guide/14.0/index/index.html, https://sparxsystems.com/resources/user-guides/14.0/guidebooks/enterprise-architecture.pdf, https://sparxsystems.com/resources/user-guides/14.0/guidebooks/business-modeling-techniques.pdf, https://sparxsystems.com/resources/user-guides/14.0/guidebooks/business-analysis-tools.pdf).

Або Ви можете використати StarUML (http://staruml.io/download).

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

Для побудови прототипів я би радила використовувати InVision (https://www.invisionapp.com/), який є безкоштовним, якщо Ви в один момент часу працюєте лише над одним проектом. Дозволяє організувати роботу в команді.

Або Ви можете обрати будь-який інший засіб, наприклад із цих:

  • https://www.cooper.com/prototyping-tools

  • https://spark.ru/startup/primeliber-com/blog/15598/8-instrumentov-dlya-sozdaniya-ux-ui-prototipov-na-kotorie-stoit-obratit-vnimanie

  • https://texterra.ru/blog/obzor-22-instrumentov-dlya-sozdaniya-prototipov.html

Також обов’язковою вимогою є обрати одну із гнучких методологій розробки ПЗ (наприклад Scrum чи Kanban) та працювати за нею протягом роботи над проектом.

Для управління проектом обов’язково має використовуватись система управління проектами (наприклад Trello, Jira) aбо будь-яка із цих.

https://www.capterra.com/task-management-software/

Також для спілкування щодо проекту в межах команди дуже раджу використовувати Slack. (https://slack.com/)
скачати

© Усі права захищені
написати до нас