МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів
Контакти
Тлумачний словник Авто Автоматизація Архітектура Астрономія Аудит Біологія Будівництво Бухгалтерія Винахідництво Виробництво Військова справа Генетика Географія Геологія Господарство Держава Дім Екологія Економетрика Економіка Електроніка Журналістика та ЗМІ Зв'язок Іноземні мови Інформатика Історія Комп'ютери Креслення Кулінарія Культура Лексикологія Література Логіка Маркетинг Математика Машинобудування Медицина Менеджмент Метали і Зварювання Механіка Мистецтво Музика Населення Освіта Охорона безпеки життя Охорона Праці Педагогіка Політика Право Програмування Промисловість Психологія Радіо Регилия Соціологія Спорт Стандартизація Технології Торгівля Туризм Фізика Фізіологія Філософія Фінанси Хімія Юриспунденкция |
|
|||||||||||||||||||||
Контроль статусу вимогВ автоматизованих засобах управління проектами (наприклад,MS Project), для контролю ступеню виконання тієї чи іншої роботи використовується поняття степені виконання (progress), що виражається у відсотках. Даний спосіб слабо застосовується в розробках програмістів, де, в силу їх слабої формалізованості, важко оцінити роботу у відсотках. При управлінні вимогами рекомендується оперувати не відсотком, а статусом. К Вігерс пропонує наступний шаблон для визначення статусу вимоги:
Вимірювання трудовитрат, необхідних для управління вимогами Як і при розробці вимог, у план проекту повинні бути включені завдання і ресурси для виконання завдань з управління вимогами. Якщо з'ясувати, скільки зусиль витрачається на управління вимогами, можна оцінити – мало їх, як треба або дуже багато - і змінити робочі процеси і майбутні плани відповідним чином.
Управління вимогами, як і всякий інший процес, вимагає ресурсів. Контроль зусиль також дозволяє з’ясувати, чи виконують розробники пропонуємі задачі для управління вимогами. Основні трудовитрати по управлінню вимогами: - Пропозиція зміни вимог та нових вимог; - Оцінка запропонованих змін, включаючи оцінку впливу змін; - Зміна роботи; - Оновлення документації вимог або бази даних; - Повідомлення про зміни вимог зацікавленим групам і окремим особам; - Контроль і звіт про стан вимог; - Збір інформації про трасуємість вимог.
Управління змінами Більшість розробників стикалися з простими на перший погляд змінами, які виявлялися більш складними, ніж вони очікували. Розробники іноді не виконують - або не можуть виконати - реалістичні розрахунки витрат та інших наслідків запропонованого зміни ПЗ. І коли розробник, який хоче бути люб'язним, погоджується додати поліпшення, запитуване користувачем, вимоги змінюються через «чорний хід», а не затверджуються зацікавленими особами, які мають на це право. Tакі неконтрольовані зміни - повсюдний джерело хаосу в проекті, порушення графіка і проблем з якістю, особливо якщо робота ведеться на декількох ділянках або проект виконує стороння організація. Організація, серйозно відноситься до управління · запропоновані зміни вимог ретельно оцінені до їх у введення у справу; · відповідні особи приймають (беруть) бізнес-рішення, будучи добре інформованими про запитані зміни; · схвалені зміни доведені до відома всім учасникам проекту; · зміни вимог, внесені в проект, узгоджені один з іншим. Обов'язок аналітика вимог - включити затверджені зміни в проектну документацію вимог, Принцип все той же: документація вимог повинна точно описувати поставляємий продукт. Якщо не буде оновлено специфікацію вимог щодо ходу розробки продукту, його цінність буде знижуватися, і команді доведеться працювати таким чином, як ніби-то в неї взагалі немає ніякої специфікації. Управління незапланованим ростом об’єму Незапланований ріст об’єму ставить під загрозу: - 80% проектів по розробці систем управління інформацією: - 70% проектів по розробці військових систем ПЗ; - 45% проектів по створенню ПЗ, що виконуються за контрактом. Незапланованою зміною вимог вважається пропозиція нової функціональності і суттєвої модифікації після затвердження базової версії вимог до проекту. Чим довше продовжується робота над проектами, тим більше їх об’єм. Вимоги до системи управління інформацією, як правило, збільшуються на 1% на місяць (Jones, 1996b). Темп приросту може складати до 3,5% у місяць для комерційного ПЗ, при цьому темпи зростання інших типів проектів входять у цей показник. Проблема заключається не в зміні вимог, а в тому, що запізнілі зміни здійснюють суттєвий вплив на вже зроблену роботу. Якщо кожний запит на зміну буде задовільняться – проект, можливо, ніколи не буде закінчений.
Ключова стратегія обмеження росту незапланованих вимог – розробити гарні вимоги, керуючись прийомами і методами в максимальному контакті із Замовником. Інша стратегія – це уміння говорити «Ні». психологія більшості людей побудована таким чином. Що їм важко відмовляти, і в даному випадку може виникнути стан постійного пресингу. К Вігерс пропонує пом’якшити цей підхід, замінивши «Ні» на «Не зараз» (вимога обов’язково буде виконана, але не в поточній версії). Однак, не слід робити висновок з усього вищесказаного, що зміни не потрібні.
2. Процес контролю змін Процес контролю змін дозволяє керівнику проекту приймати Клієнти та інші зацікавлені особи часто ухиляються від нового процесу, проте Якщо запропонована зміна не настільки важлива, щоб зацікавлена в проекті На практиці функції Ради можуть бути делеговані і При прийнятті рішення за запитом необхідно виходити: а) зі ступеня важливості запиту для Замовника, і б) з його вартості для Розробника. Вартість визначається на підставі аналізу впливу зміни. Процес контролю змін
Рис. Шаблон опису процесу контролю змін 1. Введення У вступі описується призначення процесу і визначаються організаційні межі, в яких він застосовується. Якщо цей процес торкається тільки зміни в певних продуктах, їх слід визначити тут. Також вказується, чи існують якісь спеціальні види змін, які не підлягають контролю, наприклад зміни в проміжних або службових продуктах, створених в ході проекту. 2. Ролі та відповідальності Необхідно перелічити членів команди - за ролями, не по іменах, які беруть участь у процесі контролю змін, і описати їх обов'язки. На рис. наведені деякі типові ролі; їх можна адаптувати відповідно до конкретної ситуації. Кожна людина може виконувати кілька ролей. Наприклад, голова ради з управління змінами також може отримувати запити, що подаються на зміни. У невеликих проектах декілька, а можливо, і всі ролі виконуються однією людиною.
Рис. Можливі ролі учасників проекту при управлінні змінами 3. Стан запиту на зміну Запит на зміну проходить через певні стадії протягом життєвого циклу, причому на кожній стадії він має різні статуси. Можна уявити ці зміни стану, використовуючи діаграму переходу станів. Потрібно оновлювати стан запиту, тільки коли задовольняються певні критерії. 4. Вхідний критерій Основним вхідним критерієм для процесу контролю змін є дійсний запит на зміну, отриманий за затвердженими каналах. 5. Завдання Наступний крок - це оцінка запиту на предмет технічної здійсненності, витрат і відповідності бізнес-вимогам проекту і обмеженням ресурсів. Голова ради з управління змінами може призначити співробітника для оцінки впливу зміни, аналізу ризику, аналізу небезпеки та ін.. Аналіз дозволяє переконатися, що ймовірні наслідки зміни ясні. Той, кому доручено оцінка, і члени ради з управління змінами повинні також розглянути комерційні і технічні наслідки відхилення зміни.
6. Перевірка Зміни вимоги, як правило, перевіряють за допомогою експертної оцінки, щоб переконатися, що змінені вимоги, варіанти використання і моделі відповідним чином відображають усі аспекти зміни. Інформація про трасуванню допоможе знайти всі частини системи, які ця зміна зачіпає і які, як наслідок, необхідно перевірити. Доручіть декільком членам команди перевірити зміни за допомогою тестування або експертизи. Після цих процедур той, хто займається перевіркою, що встановлює оновлені продукти, зробивши їх доступними іншим членам команди, і перевизначає базову версію, в якій враховані зміни.
7. Вихідний критерій Всі перераховані далі вихідні критерії повинні бути задоволені, щоб належним чином завершити процес управлінь змінами: - стан запиту: Rejected (Відхилено), Closed (Закрито) або Canceled (Скасовано); - всі зміни записані у відповідних розділах; - ініціатор запиту, голова ради з управління змінами, менеджер проекту та інші значущі учасники проекту оповіщені про деталі зміни і поточний стан запиту на зміну; 8. Звіт про стан управління зміни Необхідно визначите графіки і звіти, які буде використано при узагальненні вмісту бази даних контролю змін. Зазвичай на цих графіках показано кількість запитів на зміну в кожній категорії стану як функція часу. Менеджер проекту використовує ці звіти при контролі станів проекту.
Рада з управління змінами Рада з управління змінами (change control board, CCB) (іноді її називають радою з управління конфігурацією) була визнана кращим практичним рішенням при розробці ПЗ (McConnell, 1996), Це група людей, незалежно від того, скільки їх-одна людина чи декілька, приймаюча рішення про те, які запропоновані зміни вимог і нові функції прийняти для включення в продукт. Рада з управління змінами переглядає і затверджує зміни базових версій будь-якої документації проекту, наприклад специфікації вимог. Деякі ради мають повноваження для прийняття рішень і просто інформують менеджерів про внесення цих змін, тоді як інші можуть тільки давати рекомендації менеджерам для прийняття рішень. У невеликому проекті має сенс делегувати прийняття рішень одному або двом співробітникам. У великих проектах та програмах може бути кілька рівнів рад контролю змін: одні відповідають за прийняття бізнес-рішень, наприклад про зміну вимог, а інші за рішення технічного характеру. Рада з управління змінами більш високого рівня затверджує зміни, що дуже сильно впливають на проект. Наприклад, при розробці великої програми, що об'єднує кілька проектів, слід створити раду, що приймає рішення на рівні програми, і окремі поради для кожного проекту. Останні вирішують проблеми і розглядають зміни, що впливають тільки на конкретний проект. Питання, що стосуються інших проектів, і зміни, в результаті яких можливе перевищення витрат або порушення графіка, передаються до ради рівня програми. Для деяких людей термін «рада з управління змінами» означає неекономічні бюрократичні накладні витрати. Однак це цінна структура, яка допомагає керувати навіть невеликим проектом. Вона не повинна забирати багато часу або бути громіздкою - вона повинна працювати ефективно. Це означає, що Рада з управління змінами розглядає всі запропоновані зміни швидко і приймає своєчасні рішення на підставі аналізу можливого впливу і переваг кожної пропозиції. Ця структура повинна бути не більше і не офіційніше, ніж необхідно для того, щоб упевнитися, що відповідні особи приймають правильні бізнес-рішення по кожній запитуваній зміні.
Склад ради з управління змінами Члени ради з управління змінами повинні представляти всі групи, яким необхідно приймати участь у прийнятті рішень у межах повноважень ради. Учасники представників наступних областей: менеджерів проекту або програми; менеджерів продукту або аналітики вимог; розробників; фахівців з тестування або перевірці якості: маркетологів або представників клієнта; фахівців, відповідальних за інформацію користувача, документацію; фахівців технічної служби або служби підтримки; фахівців з управління конфігурацією. Тільки деякі з них будуть приймати рішення, проте всіх їх слід проінформувати про рішення, що впливають на їх роботу. Статут ради з управління змінами У статуті описуються завдання, область повноважень, членство, виробничі процедури та процес прийняття рішень ради з управління змінами. В уставі має бути вказана регулярність запланованих нарад і умови скликання спеціальних зустрічей. Область повноважень вказує, які рішення рада може приймати, а які слід передати раді вищого рівня або менеджера. Прийняття рішень. Як і всі структури, що приймають рішення, кожна рада з управління змінами повинна визначити відповідні правила та процес прийняття рішення. В описі процесу прийняття рішення слід зазначити таке: - чи використовується голосування, консультативний спосіб чи будь-яке інше правило прийняття рішень; - чи може голова ради з управління змінами відхилити колективне рішення ради; Рада з управління змінами зважує передбачувані переваги і передбачуване вплив прийняття запропонованої зміни. До переваг належать: економія коштів, збільшення доходу, більше задоволення покупців і конкурентні Після того як рада з управління змінами приймає рішення, уповноважений співробітник оновлює стан запиту в базі даних змін. Деякі засоби автоматично генерують повідомлення електронної пошти, щоб інформувати про новий стан ініціатора запиту і всіх, кого зачіпає це зміна Якщо повідомлення електронної пошти не генерується автоматично проінформуйте зацікавлених фахівців особисто для того, щоб вони змогли правильно прийняти цю зміну. Аналіз впливу зміни Аналіз впливу забезпечує точне розуміння підтексту запропонованої зміни, Аналізу результатів змін зачіпає три аспекти. 1. Визначення можливих наслідків зміни. Часто вони викликають значний 2. Визначення всіх файлів, моделей та документів, які, можливо, доведеться змінити, якщо команда включить всі запитані зміни. 3. Визначення задач, необхідних для реалізації зміни, і оцінка зусиль,
24.04.2012 Лекція
1. Поняття та процеси доменної інженерії та доменного аналізу програмного забезпечення. 2. Лінійки та сімейства продуктів. Більшість систем ПЗ можуть бути класифіковані у відповідності з напрямом діяльності і роду задач, які вони підтримують, наприклад, системи бронювання авіаквитків, системи обробки запитів, системи управління запасами і т.д. Крім того можна класифікувати частини програмних систем у відповідності з їх функціональністю, наприклад, системи баз даних, синхронізації пакетів, системи документообігу, GUI бібліотеки. Мається на увазі області організовані навколо класів систем або частин систем як домени. Очевидно, що специфічні (конкретні) системи або компоненти в середині домену мають багато спільних (сумісних) характеристик, так як вони також мають багато спільних вимог. Таким чином організація, що створила ряд систем або компонентів в специфічному (конкретному) домені може скористатися отриманими знаннями при створенні послідуючих систем або компонентів в тому ж домені. Взявши набуті знання домену в формі повторно використовуваних активів (ресурсів) і повторно використовуючи ці активи при розробці нових продуктів, організація буде в змозі поставити нові продукти в більш коротші терміни і за більш нижчою ціною. Доменна інженерія є систематичним підходом для досягнення цієї цілі. Доменна інженерія – діяльність по збору, систематизації і збереження минулого досвіду побудови систем або частин систем в конкретному домені в формі повторно використовуваних ресурсів (активів, засобів), а також по забезпеченню належних засобів (методів) для повторного використання цих ресурсів (тобто, пошук, розповсюдження, адаптація, збірка і т.д.) при створенні нових систем. Доменна інженерія включає в себе три основні компоненти-процеси – Доменний Аналіз (ДА), Доменне Проектування (ДП), Реалізація Домену (РД). Основна мета кожного із цих компонентів: Доменний Аналіз – визначення набору повторно використовуваних вимог для систем в домені. Доменне Проектування – створення спільної (загальної) архітектури для систем в домені. Реалізація Домену – реалізація повторно використовуваних ресурсів, наприклад, повторно-використовувані компоненти, доменно-орієнтовані мови, генератори і повторно використовувана інфраструктура. В той час як звичайні розробки ПЗ концентруються на задоволенні вимог до єдиної системи, Доменна інженерія концентрується на забезпеченні повторно використовуваних рішень для сімейства систем. З іншого боку доменна інженерія націлена на розвиток повторно-використовуваного ПЗ, наприклад, загальної системи, із якої можна створити екземпляри конкретних систем, або компонентів для повторного використання в різних системах. Таким чином Доменна інженерія повинна рахуватися з різноманітною множиною клієнтів (в тому числі потенційних) і контекстів застосувань. В термінології компонент є повторно використовуваною частиною ПЗ яка використовується в побудові більш складного ПЗ. Інші робочі продукти включають повторно-використовувані вимоги, аналіз і моделі проектування, архітектури, шаблони, генератори, доменно-орієнтовані мови. В загалі йде посилання на будь-який повторно використовуваний продукт як повторно використовуваний ресурс. Доменна інженерія розглядає наступні два аспекти: - Інженерію повторно використовуваного ПЗ. Доменна Інженерія використовується для розробки повторно використовуваного ПЗ - Управління знаннями. Доменна інженерія не повинна бути «одноразовою» діяльністю. Замість цього, вона повинна бути безперервним процесом, головною метою якого є підтримка і оновлення знань в домені на основі досвіду, розширення меж, і нові тенденції та ідеї.
ДОМЕННИЙ АНАЛІЗ Доменний аналіз (аналіз предметної області) використовується для визначення домену, збору інформації про домен і вироблення доменної моделі. Метою ДА є: - Вибір і визначення домену. - Збір важливої (необхідної) інформації про домен і інтеграція її в зв’язану (єдину) модель домену. Джерелами доменної інформації є існуючі системи в домені, експерти домену, система довідників, книжок, створення прототипів, експерименти, вже відомі вимоги до майбутньої системи. ДА не тільки включає записи існуючих знань домену. Систематична організація існуючих знань дозволяє і заохочує розширювати їх в творчих цілях. Таким чином ДА є креативною діяльністю. Доменна модель є явним представленням спільних і відмінних властивостей систем в домені і залежностей між відмінними властивостями. В загалі модель домену складається із наступних компонентів: - Визначення домену. «Визначення домену» визначає область домену і характеризує його вміст за допомогою прикладів систем в домені, контр прикладів (тобто, систем за межами домену) і загальні правила включення або виключення (наприклад, «будь-яка система, що має можливість (здатність) Х належить домену»). - Лексикон домену: Доменний лексикон визначає доменний словник. - Концептуальні моделі: Концептуальні моделі описують поняття в домені виражених (відображених) в деяких відповідних формалізмах моделювання (наприклад, діаграми взаємодії і переходу стану або сутність-зв'язок, діаграми потоку даних). - Моделі характеристик (можливостей). Визначають набір повторно використовуваних і конфігуруємих вимог до специфікованих систем домену. ДА зазвичай включає наступні процеси (діяльності): 1) Планування домену, ідентифікація, і обмеження: планування ресурсів для виконання ДА, ідентифікація інтересів домену, визначення границь домену. 2) Моделювання домену: розробка доменної моделі Читайте також:
|
||||||||||||||||||||||
|