КАТЕГОРИИ: Архитектура-(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; Просмотров: 435; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |