Студопедия

КАТЕГОРИИ:


Архитектура-(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)

Проблеми формування системи, функцій та характеристик програмного продукту




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

В требованиях к документации должны быть полно зафиксированы потребности пользователей в таком виде, чтобы разработчик мог построить удовлетворяющее их ПС. Кроме того, требования должны быть достаточно конкретными, чтобы можно было определить, когда они удовлетворены. Если необходимо, документация требований может дополняться одним или несколькими более формальными либо более структурированными методами детализированных спецификаций. Среда пользователей ПС должны включать описание: сколько человек участвует в выполнении данной задачи; сколько времени длится цикл выполнения задачи; сколько вре­мени отводится на выполнение каждого действия; существуют ли уникальные ограничения внешней среды; какие системные плат­формы используются. Альтернативы должны отражать известные конкурирующие варианты ПС, которые существуют или могут возникнуть с аналогичными функциями.

Функции и характеристики программного продукта должны содержать общее описание возможностей продукта, интерфейсов с другими ПС и конфигурациями систем и компонентов, как про­дукт взаимодействует со средой пользователя и между системами, функции должны быть организованы так, чтобы они были понятны заказчику или тому, кто впервые читает данный документ. Атри­буты функций предоставляют в документах дополнительную ин­формацию, которую можно использовать для оценки, отслежива­ния и определения очередности предлагаемых для реализации компонентов разработки, а также для управления ими. Требования к функциям должны отражать основные преимущества, которые но­вая система даст ее заказчикам, покупателям и пользователям.

Функции продукта обеспечивают регистрацию необходимых возможностей для удовлетворения потребностей пользователей. Отчеты об их выполнении помогают пользователю лучше понять состояние проекта и документации. Поскольку концепция изучается широким кругом причастных к проекту лиц и служит основой для достижения соглашений, функции должны описываться на естественном языке пользователя. Каждая основная функция нового программного продукта или возможность, должна предоставляться пользователям, последовательно, подчеркивая те достоинства, кото­рые отличают его от предыдущих или конкурирующих продуктов. Давая каждой функции уникальное имя, можно отследить соответ­ствие каждой функции отдельным требованиям пользователей, Функциональным требованиям, документам и другим компонентам систем.

Базовая версия отражает, в какой версии ПС предполагается впервые реализовать некоторую функцию. Стабильность проекта и Документации определяется аналитиком и командой разработчи­ков, исходя из вероятности того, что может изменить новая функция или понимание функций ПС. Эта информация используется Для того, чтобы помочь при определении приоритетов разработки и выявить те компоненты, для которых следующим действием должно стать дополнительное исследование выделенной функции. Статус изменений функций задается в результате переговоров и рас­смотрения руководством проекта. Информация о статусе отражает процесс определения базового уровня проекта. Атрибут статуса функции может иметь следующие значения:

- предложена - используется для описания обсуждаемых функций, которые еще не рассмотрены и не приняты официальным органом, рабочей группой, состоящей из представителей разработчиков проекта, руководства и пользователей или заказчиков;

- принята - функции, которые официальный орган заказчика признал полезными и достижимыми и допустил к реализации;

- включена - функции, включенные в базовый уровень и документы ПС на данный момент времени.

Реализуются только функции, имеющие статус включенная, для которых определена базовая версия. Приоритеты изменения функций программного продукта задаются представителями мар­кетинга, менеджером продукта или аналитиком базового уровня ПС. Упорядочение функций по их относительной важности для конечного потребителя открывает диалог между заказчиками, аналитиками и членами команды разработчиков. Приоритеты используются для управления масштабом и определения очередности разработки функций:

- критические - основные функции, если их не удастся реализовать, система не будет удовлетворять потребности заказчика, в версии должны быть реализованы все критические функции, в противном случае успех разработки является нереальным;

- важные - функции, необходимые для успешной и эффективной работы системы в большинстве применений, если важные функции не войдут в реализацию ПС, это может повлиять на удов­летворение пользователя или заказчика результатом работы или да­ же на доходы от продаж, но выпуск версии не должен задерживаться из-за нехватки даже важной функции;

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

Стратегический образ системы и ПС - Концепция, позволяю­щая выполнять требуемые задачи, обеспечивает основу для приня­тия решений в течение жизненного цикла ПС. В него не надо включать детали функциональных требований или информа­цию, связанную с планированием проекта. В этом документе следу­ет отразить сбалансированный образ функций, удовлетворяющих различных заинтересованных лиц. Он может быть несколько идеалистичным, но должен быть основан на существующих или предполагаемых рыночных факторах, архитектуре предприятия, стратегическом направлении развития корпорации и ограничениях ресурсов.





Поделиться с друзьями:


Дата добавления: 2015-05-08; Просмотров: 414; Нарушение авторских прав?; Мы поможем в написании вашей работы!


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



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




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