Требования к программному обеспечению реферат

Обновлено: 04.07.2024

Требования к программному обеспечению

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

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

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

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

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

Каждое из требований нельзя рассматривать отдельно от других, они взаимозависимы.

Требования к программному обеспечению.

Программное обеспечение — совокупность всех программных средств не входящих в состав Системы, но используемых при отладке, функционировании и проверке работоспособности Системы.

Программное обеспечение включает в себя общее программное обеспечение (ОПО Системы) и специальное программное обеспечение (СПО Системы).

6.4.7 Требования к общесистемному программному обеспечению

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

В состав общесистемного ПО должны входить:

— операционная система сервера;

— операционные системы рабочих станций администраторов и пользователей Системы (Windows XP, Vista);

— СКБД (MS SQL 2005).

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

6.4.8 Требования к специальному программному обеспечению

СПО Системы должно предусматривать:

— средства контроля корректности и непротиворечивости данных;

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

— работу одновременно тестовой и рабочей Систем и соответствующих лицензий к ним;

— средства печати документов из Системы.

Функциональные и нефункциональные требования

Требования к программной системе классифицируются как функциональные и нефункциональные.

Функциональные требования. Это перечень функций, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать. Пример функционального требования к библиотечной системе университета, предназначенной для заказа книг и документов из других библиотек:

1. Пользователь должен иметь возможность проводить поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных

2. Система должна предоставлять пользователю подходящее средство просмотра библиотечных документов.

3. Каждый заказ должен быть снабжен уникальным идентификатором (NUM_ID), который копируется в формуляр пользователя для постоянного хранения.

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

4.4. Требования к программному обеспечению

Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.

Все системные требования можно разбить на три большие группы.

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

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

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

Системные требования должным быть выражаться через количественные показатели, которые можно объективно измерить.

Пример системного требования:

Система должна быть простой в эксплуатации для опытного оператора и сводить количество его ошибок к минимуму

Данное требование лучше сформулировать так:

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

В таблице 1Таблица 1 приведены показатели, с помощью которых можно специфицировать системные свойства.

Количественные показатели для системных требований

Таблица 1. Количественные показатели для системных требований

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

Классификация требований к ПО

LABA 2

1.1 Классификация требований

Требования разных уровней, это :

· требованияпользователя для обозначения высокоуровневых обобщенных требований;

· системные требованиядля детализированного описания выполняемых системой функций.

Третий уровень требований используется для более детализированного описания системы – проектная системная спецификация, которая может служить мостом между этапом разработки требований и этапом проектирования системы.

Три перечисленных вида требований можно определить следующим образом.

1 Требования пользователя – описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на нее.

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

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

Требования пользователя

Спецификация требований пользователя представляет собой процесс организации информации о нуждах пользователя и отображения их в документе.

Требование является условием или возможностью, необходимым пользователю, чтобы решить задачу или достичь цели. Поэтому существуют два вида требований: "мандатным требованиям" и "ограничительным требованиям".

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

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

Количественные формулировки, которые точно определяют атрибуты эффективности и точности, должны составлять часть спецификации мандатных требований. Это означает, что мандатное требование должно быть квалифицированным в таких оценках, как: объем; скорость и точность.

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

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

Требование аппаратного интерфейса точно определяет все или часть компьютерной аппаратуры, на которой надо выполнить программное обеспечение. Указание формулировок марки и модели устройства, физических ограничений, например: размера, веса; эффективности, например: скорости, памяти

Требование программного интерфейса точно определяет, должно ли программное обеспечение быть совместимым с другими , например: другими приложениями, компиляторами, операционными системами.

Классификация требований к ПО

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

Системные требования определяют, что должна делать система, не показывая при этом механизма ее реализации (как).

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

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

Первоначальная архитектура системы помогает структурировать спецификацию требований.

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

В спецификацию системных требований входит также спецификация интерфейсов.

Различают три типа специфицируемых интерфейсов.

1. Процедурные интерфейсы, когда существующие подсистемы предлагают набор сервисов, доступных посредством вызываемой интерфейсной процедуры.

2. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой.

3. Специальные представления данных, например в виде упорядоченной последовательности двоичных разрядов.

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

1 Функциональные требования. Это перечень сервисов, функций, которые должна выполнять система (или системный компонент ), причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

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

Требования к программному обеспечению

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

3 Требования предметной области.Характеризуют ту предметную область, для которой разрабатывается система. Эти требования могут быть функциональными и нефункциональными.

Характеристика требований к программному обеспечению (ПО) как набора свойств разрабатываемого ПО, которые желает получить заказчик, оплачивающий разработку. Изучение особенностей процесса формирования и анализа требований к программному обеспечению.

Рубрика	Программирование, компьютеры и кибернетика
Вид	доклад
Язык	русский
Дата добавления	17.09.2017
Размер файла	17,7 K

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Во всех моделях разработки ПО в той или иной форме выполняется выявление и описание требований к ПО.

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

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

Процесс выявления, анализа, документирования называется разработкой требований.

Требования указывают, что должно быть построено, но не говорят, как это сделать.

Существует 3 основных стороны, заинтересованные в создании новой ПС: 1.Заказчик 2.Разработчик 3.Пользователи

Каким-то образом требования к ПС, которые будут удовлетворять потребностям заказчиков и заботам пользователей должны быть переданы разработчикам. Между этими участниками проекта разработки имеется коммуникационный разрыв (не понимание). СТПО является средством (мостом) для преодоления такого разрыва, т.к. они являются общим представление разрабатываемого ПО.

Целью деятельности по работе с требования является создание Спецификаций Требований к ПО (СТПО), которые детально описывают, что должна уметь делать разрабатываемое ПО.

С помощью СТПО заказчик явно описывает, что он ожидает от поставщика, а разработчик явно понимает, какими возможностями должно обладать разрабатываемое ПО.

Процесс формирования и анализа требований проходит через ряд этапов:

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

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

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

o Опрос стейкхолдеров является широко используемой техникой при сборе требований. Эти опросы могут выявлять требования, не попавшие в рамки проекта либо противоречащие ранее собранным. Однако каждый стейкхолдер будет иметь собственные требования, ожидания и видение системы

o Интервью, опросы, анкетирование;

o Мозговой штурм, семинар;

o Анализ нормативной документации;

o Анализ моделей деятельности;

o Анализ конкурентных продуктов;

o Анализ статистики использования предыдущих версий системы

· Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требовании.

· Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.

Сеансы совместного развития требований

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

· Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.

· Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

· Клиенты - это те, кто выполняет основные функции системного проектирования, со специальным акцентом на пользователе системы как ключевом клиенте. Пользовательские требования определят главную цель системы и, как минимум, ответят на следующие вопросы:

· Где система будет использоваться?

· Как система достигнет целей миссии?

· : Какие параметры системы являются критическими для достижения миссии?

· : Как различные компоненты системы должны использоваться?

· : Насколько эффективной должна быть система для выполнения миссии?

· : Как долго система будет использоваться?

· : Каким окружением система должна будет эффективно управлять?

Функционал Функциональные требования объясняют, что должно быть сделано. Они идентифицируют задачи или действия, которые должны быть выполнены.

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

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

Производные требования

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

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

Преимущества

· Обеспечивает контрольный список требований.

· Обеспечивает договор между заказчиками и разработчиками.

· Для большой системы может обеспечить описание высокого уровня.

Недостатки

· Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие документы в целом и получить чёткое понимание системы.

· Такие списки требований перечисляют отдельные требования абстрактно, оторванно друг от друга и от контекста использования

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

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

· Эта абстракция увеличивает вероятность неверного трактования требований; поскольку чем больше число людей будет их читать, тем большее будет число (различных) интерпретаций системы.

· Эта абстракция означает, что чрезвычайно трудно убедиться, что у вас есть все необходимые требования.

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

Типы системных моделей, которые могут создаваться в процессе анализа систем:

· Модель обработки данных. Диаграммы потоков данных показывают последователь-ность обработки данных в системе.

· Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей.

· Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.

· Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.

· Модель "стимул-ответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.

обеспечение программный разработка

Требование описывает одну и только одну вещь.

Требование полностью определено в одном месте и вся необходимая информация присутствует.

Требование не противоречит другим требованиям и полностью соответствует внешней документации.

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

Требование не стало устаревшим с течением времени.

Требование может быть реализовано в пределах проекта.

Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.

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

Подобные документы

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

презентация [3,2 M], добавлен 19.09.2016

Определение требований к программному обеспечению. Ознакомление с процессом проектирования интерфейса пользователя. Рассмотрение результатов обзора существующих информационных систем. Обоснование необходимости разработки программного обеспечения.

дипломная работа [1,1 M], добавлен 05.07.2017

Разработка программного приложения, производящего проверку синтаксиса простой программы: выбор метода создания синтаксического анализатора, описание требований к программному обеспечению, написание алгоритмов решения и тестирование конечного продукта.

курсовая работа [579,7 K], добавлен 03.07.2011

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

курсовая работа [236,7 K], добавлен 09.03.2009

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

курсовая работа [506,3 K], добавлен 17.12.2014

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

дипломная работа [1,9 M], добавлен 24.03.2014

Определение и анализ наиболее эффективной стратегии на примере организации в ритейл сфере. Рассмотрение и характеристика основных видов требований к программному продукту. Ознакомление с принципами взаимосвязи нескольких типов информации для требований.

создание базы данных "электронный каталог книг библиотеки эток"

Требования к программному обеспечению ( реферат , курсовая , диплом , контрольная )

Качество программного обеспечения

Удовлетворение заказчика обычно измеряется соотношением тех, кто удовлетворен и тех, кто не удовлетворен (нейтральных, недовольных). При составлении отчетов по оценке удовлетворенности заказчиков обычно используются различные методы повышения достоверности, устранения предвзятости — например, двойной слепой обзор (интервьюер не знает, кем является заказчик, и заказчик не знает, какую компанию представляет интервьюер).

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

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

Вследствие двух главных аспектов качества (то есть удовлетворение заказчика, как конечное признание качества и строгое соблюдение производителем требований для достижения качества) фактически определение качества имеет два уровня. Первый — это качество, внутренне присущее продукту, практически оно бывает ограничено уровнем надежности продукта, уровнем наличия дефектов. Широкий уровень определения качества включает как качество продукта, так и удовлетворение заказчика.

Двухуровневая концепция качества предполагает формирование замкнутого цикла: желания и потребности заказчиков > требования и спецификации > продукт проектируется, разрабатывается и производится в соответствии с требованиями > отличное качество продукта плюс хорошее распространение (дистрибьюция) и сервис > общее удовлетворение заказчика. Тем не менее, эта концепция не всегда присутствует у многих производителей ПО. Требования к продукту часто генерируются без участия пользователей, и удовлетворение заказчика не всегда является фактором принятия решений в бизнесе. Хотя конечные продукты соответствуют первоначальным требованиям, они могут оказаться не тем, чего хотят потребители. Поэтому, очевидно, что роль заказчиков должна быть точно и подробно изложена в определении качества. Это особенно актуально для программной индустрии, так как ошибки в требованиях составляют одну из главных проблем этой отрасли.

Процесс разработки ПО, не учитывающий качества требований, неизбежно приводит к появлению ПО низкого качества. Еще один взгляд на качество ПО состоит в том, что качество процесса разработки ПО влияет на качество конечного продукта. Процесс разработки ПО сложен по своей природе. Часто он включает несколько фаз, каждая из которых может иметь обратную связь. На каждой стадии производится промежуточный продукт для промежуточного использования — на следующей фазе. На каждой стадии используется промежуточный продукт с предыдущей фазы. Каждый промежуточный продукт имеет атрибуты качества, которые влияют на качество конечного продукта. Если распространить концепцию учета заказчика в определении качества одновременно и на внешнего и на внутреннего потребителя продукта, это определение можно также применить и для качества процесса. Если каждая стадия процесса разработки удовлетворяет требованиям промежуточного пользователя (следующей стадии), конечный продукт, таким образом, разработанный и произведенный, будет удовлетворять специфицированным требованиям. Это утверждение, конечно, значительно упрощает реальность, так как на каждой стадии процесса разработки существует множество факторов, которые влияют на возможность на данной стадии выполнять требования полностью. Тем не менее, если каждый человек, выполняющий работу, думает о потребителях промежуточного продукта и применяет концепцию, обсуждавшуюся выше, это уже реальный путь по улучшению качества конечного продукта.

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

То, что измерено, может быть улучшено. Использование измерений, метрик, моделей при разработке ПО предполагает доступность правильных данных. Фактически плохое качество данных является крупным препятствием для повышения качества.

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

Требование техники

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

Требование инженерного процесса

Это четырехэтапный процесс, который включает в себя:

Технико-экономическое обоснование
Сбор требований
Спецификация требований к программному обеспечению
Проверка требований к программному обеспечению

Давайте посмотрим на процесс вкратце —

Технико-экономическое обоснование

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

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

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

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

Сбор требований

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

Спецификация требований к программному обеспечению

SRS — это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.

SRS определяет, как предполагаемое программное обеспечение будет взаимодействовать с аппаратным обеспечением, внешними интерфейсами, скоростью работы, временем отклика системы, переносимость программного обеспечения на различные платформы, ремонтопригодность, скорость восстановления после сбоя, безопасность, качество, ограничения и т. Д.

Требования, полученные от клиента, написаны на естественном языке. Системный аналитик обязан документировать требования на техническом языке, чтобы они могли быть поняты и полезны для команды разработчиков программного обеспечения.

SRS должен придумать следующие функции:

Требования пользователя выражены на естественном языке.
Технические требования выражены на структурированном языке, который используется внутри организации.
Описание дизайна должно быть написано в псевдокоде.
Формат форм и печать графического интерфейса.
Условные и математические обозначения для DFD и т. Д.

Проверка требований к программному обеспечению

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

Если они могут быть практически реализованы
Если они действительны и согласно функциональности и области программного обеспечения
Если есть какие-то неясности
Если они завершены
Если они могут быть продемонстрированы

Процесс выявления требований

Процесс выявления требований можно изобразить с помощью следующей диаграммы:

Сбор требований — разработчики обсуждают с клиентом и конечными пользователями и знают их ожидания от программного обеспечения.
Организация требований — Разработчики расставляют приоритеты и распределяют требования в порядке важности, срочности и удобства.

Переговоры и обсуждение — если требования неоднозначны или если есть какие-то противоречия в требованиях различных заинтересованных сторон, если они есть, то это обсуждается и обсуждается с заинтересованными сторонами. Требования могут быть затем расставлены по приоритетам и разумно скомпрометированы.

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

Методы выявления требований

Выявление требований — это процесс выяснения требований для предполагаемой системы программного обеспечения путем общения с клиентом, конечными пользователями, пользователями системы и другими лицами, которые заинтересованы в разработке системы программного обеспечения.

Существуют различные способы определения требований

Интервью

Интервью являются сильной средой для сбора требований. Организация может проводить несколько типов интервью, таких как:

Обзоры

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

Анкетирование

Документ с предварительно определенным набором объективных вопросов и соответствующими вариантами передается всем заинтересованным сторонам для ответа, которые собираются и компилируются.

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

Анализ задач

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

Анализ предметной области

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

мозговая атака

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

макетирования

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

наблюдение

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

Требования к программному обеспечению Характеристики

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

Полные спецификации требований к программному обеспечению должны быть:

Очистить
Правильный
последовательный
Последовательный
понятный
модифицируемый
проверяемый
Приоритетное
недвусмысленный
прослеживаемый
Достоверный источник

Требования к программному обеспечению

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

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

Функциональные требования

Требования, относящиеся к функциональному аспекту программного обеспечения, попадают в эту категорию.

Они определяют функции и функциональные возможности внутри и из системы программного обеспечения.

Примеры —

Нефункциональные требования

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

Нефункциональные требования включают в себя —

Безопасность
логирование
Место хранения
конфигурация
Спектакль
Стоимость
Interoperability
гибкость
Аварийное восстановление
доступность

Требования классифицированы логически как

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

Требования к пользовательскому интерфейсу

Пользовательский интерфейс является важной частью любого программного или аппаратного обеспечения или гибридной системы. Программное обеспечение широко распространено, если оно —

прост в эксплуатации
быстрый ответ
эффективно обрабатывать ошибки в работе
обеспечение простого, но последовательного пользовательского интерфейса

Принятие пользователем в основном зависит от того, как пользователь может использовать программное обеспечение. Пользовательский интерфейс является единственным способом восприятия системы пользователями. Хорошо работающая система программного обеспечения также должна быть оснащена привлекательным, понятным, последовательным и отзывчивым пользовательским интерфейсом. В противном случае функциональные возможности программного комплекса не могут быть использованы удобным способом. Говорят, что система хороша, если она предоставляет средства для ее эффективного использования. Требования к пользовательскому интерфейсу кратко упомянуты ниже —

Содержание презентации
Простая навигация
Простой интерфейс
отзывчивый
Согласованные элементы интерфейса
Механизм обратной связи
Настройки по умолчанию
Целенаправленный макет
Стратегическое использование цвета и текстуры.
Предоставить справочную информацию
Ориентированный на пользователя подход
Групповые настройки просмотра.

Программный системный аналитик

Системный аналитик в ИТ-организации — это человек, который анализирует требования к предлагаемой системе и обеспечивает правильное и правильное оформление и документирование требований. Роль аналитика начинается на этапе анализа программного обеспечения SDLC. Аналитик обязан убедиться, что разработанное программное обеспечение соответствует требованиям клиента.

Системные аналитики имеют следующие обязанности:

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

Метрики и показатели программного обеспечения

Меры программного обеспечения можно понимать как процесс количественной оценки и символизации различных атрибутов и аспектов программного обеспечения.

Метрики программного обеспечения обеспечивают измерения для различных аспектов программного процесса и программного продукта.

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

Давайте посмотрим некоторые метрики программного обеспечения:

Размер метрики — LOC (Lines of Code), в основном рассчитывается в тысячах доставленных строк исходного кода и обозначается как KLOC.

Функция Point Count — это мера функциональности, предоставляемой программным обеспечением. Функция Point count определяет размер функционального аспекта программного обеспечения.

Метрики качества — Дефекты, их типы и причины, последствия, интенсивность и их значение определяют качество продукта.

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

Проблемы, которые приходится решать специалистам в процессе создания программного обеспечения, обычно очень сложны. Природа этих проблем не всегда ясна, особенно если разрабатываемая программная система инновационная. В частности, трудно четко описать те действия, которые должна выполнять система. Описание функциональных возможностей и ограничений, накладываемых на программную систему, называется требованиями к этой системе, а сам процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений — разработкой требований (requirements engineering).

Термин требования (к программной системе) может трактоваться по-разному. В некоторых случаях под требованиями понимаются высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы. Другая крайняя ситуация— детализированное математическое формальное описание системных функций

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

На практике часто применяется подход, используемый в различных методологиях разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п.

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользовательские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания выполняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы — проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

Пользовательские требования— описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на нее.

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

Проектная системная спецификация— обобщенное описание структуры программной системы, которое будет основой для более детализированного проектирования системы и се последующей реализации. Эта спецификация дополняет и детализирует спецификацию системных требований.

Различие между пользовательскими и системными требованиями показаны в примере, представленном примере 1. Здесь показано, как пользовательские требования могут быть преобразованы в системные.

Пример. Пользовательские и системные требования

Пользовательские требования

1. ПО должно предоставить средство доступа к внешним файлам, созданным в других программах.

Спецификация системных требований

Пользователь должен иметь возможность определять тип внешних файлов.

Для каждого типа внешнего файла должно иметься соответствующее средство, применимое к этому типу файлов.

Внешний файл каждого типа должен быть представлен соответствующей пиктограммой на дисплее пользователя.

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

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

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

Разработка требований - это первая из основных фаз процесса создания программных систем. Этот фаза состоит из следующих основных работ (рис. 5).

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

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

Формирование и анализ требований. Взаимодействуя с пользователями, обсуждая и анализируя с ними задачи, возлагаемые на систему, разрабатывая модели и прототипы, разработчики формулируют пользовательские требования.

Документирование требований. Сформированные на предыдущем этапе пользовательские требования должны быть документированы. При этом нужно учесть, что основными читателями этого документа будут пользователи, поэтому основными требованиями к нему будут ясность и понятность.

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

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

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

понимание пользователями возможностей системы, решаемых ею задач, может измениться;

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

понимание разработчиками поставленных перед ними задач меняется.

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

К действиям по управлению требованиями относятся:

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

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

включение одобренных изменений при помощи определенной процедуры;

согласование плана проекта с требованиями;

отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

отслеживание статуса требований и действий по изменению на протяжении всего проекта.

В организации (или в проекте) должны быть определены действия по управлению требованиями. Эти действия должны быть документированы и должны выполняться всеми участниками проекта. При разработке процесса нужно определить:

методы и средства управления версиями спецификации и отдельных требований;

процесс разработки, согласования, экспертизы и утверждения базовой версии;

процесс присвоения, контроля и изменения статуса требования;

процесс передачи новых требований и изменений существующих требований заинтересованным лицам;

методы анализа влияния и стоимости внесения изменения.

Кроме этого описание процесса должно содержать определение участников проекта, ответственных за выполнение каждой конкретной задачи.

Минимальной единицей управления в спецификации требований является отдельное требование, поэтому вопрос идентификации требования достаточно важен. Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атрибутов. Атрибутами могут быть: дата создания требования, номер текущей версии требования, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обоснование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование и его состояние.

Таблица 1. Состояния требования

Определение

Требование запрошено авторизированным источником

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

Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода.

Корректное функционирование реализованного требования подтверждено в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается выполненным.

Утвержденное требование удалено из базовой версии. Следует зафиксировать причины и лицо, принявшее это решение.

Требование предложено, но не запланировано для реализации ни в одной из будущих версий. Следует зафиксировать причины и лицо, принявшее это решение.

После разработки, согласования и утверждения спецификация требований становится основным документом в проектировании системы (версии системы). Изменения в этот документ разрешается вносить только через определенный в организации (или проекте) процесс внесения изменений.

Диаграмма состояний для типового процесса внесения изменений в спецификацию приведена на рис. 6.

Требования к программной системе часто классифицируются как функциональные, нефункциональные и требования предметной области.

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

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

Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.

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

Группа функциональных требований

Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).

Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-Functional Requirements)

Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.

Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.

Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.

Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функциисистемы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Читайте также: