Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Проверяемость

Недвусмысленность

Назначение приоритетов

Назначьте приоритеты каждому функциональному требованию, характеристике или варианту использования, чтобы определить, что необходимо для каждой версии продукта. Если все положения одинаково

важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки.

Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите

все специальные и запутанные термины в словарь.

Реализованость требований может быть определена через один из четырех возможных методов: осмотр, демонстрация, тест или анализ

Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое требование. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются.

Фаза разработки требований может быть разбита на:

- выявление требований (сбор, понимание, рассмотрение, и выяснение потребностей заинтересованных лиц);

- анализ (проверка целостности, законченности);

- спецификация (документирование требований);

- проверка правильности.

Анализ требований подразумевает их детализацию, гарантирующую, что требования понимают все заинтересованные лица, а также тщательное исследование требований на предмет ошибок, пробелов и других недостатков. Кроме того, анализ включает создание прототипов, анализ осуществимости и согласование приоритетов. Цель анализа — достаточно качественно и подробно описать требования, позволяющие менеджерам реалистично оценить все затраты на проект, а техническому персоналу — начать проектирование, сборку и тестирование.

Зачастую отдельные требования стоит представить несколькими способами, например в текстовой и графической форме. Это позволит выявить их особенности и проблемы, не заметные при представлении одним способом (Davis, 1995). Также это помогает всем заинтересованным лицам выработать согласованное представление об итогах разработки продукта.

Заинтересованными сторонами являются конечные пользователи ПО, его заказчики, разработчики, администраторы систем, в которых оно будет работать, регулирующие органы и пр.

 

1. Огляд стандартних процесів життєвого циклу програмного забезпечення у контексті вимог.

2. Відношення цих процесів до інших процесів розробки та супроводження програмного забезпечення.

3. Процеси вивчення концепції – ідентифікація ідей та потреб замовника, формулювання потенційних підходів, вивчення здійсненності, оформлення ідей та потреб.

4. Загальний зміст декларації ідей та потреб замовника.

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

Традиційно виділяють наступні основні етапи ЖЦ ПЗ:

· Аналіз вимог;

· Проектування;

· Кодування (программирование);

· Тестування і відладка;

· Експлуатація і супроводження.

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

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

Аналіз вимог – це етап ЖЦ ПЗ, під час якого вимоги замовника уточнюються, формалізуються і документуються.

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

Конце́пція, також Концепт (лат. conceptio — розуміння) — система поглядів на ті чи інші явища, процеси; спосіб розуміння (трактування, сприйняття) будь-якого предмету, явища, подій; ідея певної теорії. Тобто, основна точка зору на предмет.

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

Ідея - це форма мислення, досвідчене походження ідей.

Ідея - це специфічна форма мислення, головна функція якої полягає в систематизації, синтезі знань (І. Кант).

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

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

Визначення ідей та потреб

Вхідні дані:

Зовнішні

• Вимоги замовника

• Ідеї від розробника

• Маркетингові джерела інформації

• Вимоги користувача

• Змінені вимоги ПЗ

Підтримка

• Проблем вдосконалення представленої інформації

• Рекомендацій по використанню

Маркетингові дослідження - збір ті аналіз даних про ринок. У ході маркетингових досліджень можуть використовуватись такі джерела маркетингової інформації: друковані видання (періодика, монографії, брошури, огляди ринків, довідники, статистичні збірники), спеціальні дослідження (опитування, спостереження експерименти, імітації), довідки офіційних організацій, експортерів, представників фірм, балансові звіти, каталоги, проекти інших підприємств, виставки, ярмарки, конференції, презентації, узагальнені думки покупців, споживачів, клієнтів, постачальників, посередників, фінансових організацій, неформальні джерела (чутки, просочування інформації").

Визначення ідей та потреб

Висхідні дані:

• Первинне формулювання потреб

Призначення:

• Планування проекту

• Інші процеси вивчення концепції

Визначення ідей та потреб

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

Формулювання потенційних підходів

• Вхідна інформація

Зовнішня:

• Бюджет та ресурси розробки

• Наявні ринкові данні

• Відомості про ресурси

Вивчення концепції:

• Первинне формулювання потреб

Формулювання потенційних підходів

Висхідні дані:

• Обмеження та переваги

• Потенційні підходи

Призначення:

• Інші процеси вивчення концепції

Формулювання потенційних підходів

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

Проведення вивчення здійсненності

Вхідні дані

Вивчення концепції:

• Первинне формулювання потреб

• Обмеження та переваги

• Потенційні підходи

Проведення вивчення здійсненності

Висхідні дані:

• Рекомендації

Призначення:

• Планування проекту

• Інші процеси вивчення концепції

• Призначення системи

Проведення вивчення здійсненності

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

Уточнення та оформлення ідей та потреб

Вхідні дані

Вивчення концепції :

• Первинне формулювання потреб

• Обмеження та переваги

• Потенційні підходи

• рекомендації

Уточнення та оформлення ідей та потреб

Вихідні дані:

• Формулювання (затвердження) потреб

Призначення:

• Планування проекту

• Створення

• Моніторинг та контроль проекту

• Призначення системи

Уточнення та оформлення ідей та потреб

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

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

2.1. Процеси (діяльності) вивчення концепції

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

Аналіз предсталенної інформації повиний бути отриманий, який містить результуючі метрики і описує метрики аналізу.

Перед розподіленням (введенням) Аналізу представленої інформації, наступні види діяльностей повинні бути введені:

1) Проведення огляду

2) Виконання управління конфігурацією

3) Документування розробки

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

Процесами (діяльностей) вивчення концепції є:

1) Визначення ідей та потреб;

2) Формулювання потенційного підходу;

3) Вивчення здійсненності;

4) Уточнення та оформлення ідей та потреб;

Визначення ідей та потреб;

Вхідна інформація:

1) Змінені вимоги до ПЗ

2) Вимоги замовника;

3) Ідеї в межах (в середині) розробки організації (ідеї внутрішнього розвитку);

4) Джерела маркетингової інформації;

5) Вимоги користувачів

6) Проблеми удосконалення представленої інформації;

7) Рекомендації по використанню.

Опис:

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

Вихідна інформація

Затвердження (формулювання) потреб

Група діяльностей:

Планування проекту (Планування переміщення системи, управління плануванням проекту).

5) Група процесів - Вивчення концепції (Формулювання потенційного підходу;Вивчення здійсненності;Уточнення та оформлення ідей та потреб;)

Формулювання потенційних підходів

Вхідна інформація:

1) Бюджет та ресурси розробки

2) Наявні данні про ринок

3) Відомості про ресурси

4) Попередні «Ствердження (заявления) потреб».

Опис:

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

1) Проведення оглядів

2) Виконання управління конфігурацією.

Вихідна інформація

1) Обмеження та переваги – (процес групи) вивчення концепції - Вивчення здійсненності; Уточнення та оформлення ідей та потреб

2) Потенційні підходи - (процес групи) вивчення концепції - Вивчення здійсненності; Уточнення та оформлення ідей та потреб

Вивчення здійсненності

Вхідна інформація

1) Попередні Ствердження потреб;

2) Обмеження і переваги;

3) Потенційні підходи.

Опис

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

Вихідна інформація

Рекомендації.

Уточнення та оформлення ідей та потреб;

Вхідна інформація

1) Попередньо затверджені потреби

2) Обмеження та переваги

3) Потенційні підходи

4) Рекомендації

Опис:

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

Вихідна інформація Затверджені потреби

 

<== предыдущая лекция | следующая лекция ==>
Необходимость | Система отсчета, число степеней свободы, траектория, путь, перемещение
Поделиться с друзьями:


Дата добавления: 2014-01-20; Просмотров: 433; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.082 сек.