Требования к системе

Содержание

Требования к системе в целом

123Следующая ⇒

ОБЩИЕ ПОЛОЖЕНИЯ

В разделе «Общие сведения» указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

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

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

Полное наименование системы и ее условное обозначение

Номер договора (контракта)

Наименования организации-заказчика и организаций-участников работ

Перечень документов, на основании которых создается система

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

Источники и порядок финансирования работ

Порядок оформления и предъявления заказчику результатов работ по созданию системы

Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ

Определения, обозначения и сокращения

НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

1) назначение системы;

2) цели создания системы.

Назначение системы

В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать.

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

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

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

ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

В разделе «Характеристики объекта автоматизации» приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

 

Примечание: Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

ТРЕБОВАНИЯ К СИСТЕМЕ

Раздел «Требования к системе» состоит из следующих подразделов:

1) требования к системе в целом;

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

3) требования к видам обеспечения.

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

Требования к системе в целом

В подразделе «Требования к системе в целом» указывают:

– требования к структуре и функционированию системы;

– требования к численности и квалификации персонала системы и режиму его работы;

– показатели назначения;

– требования к надежности;

– требования безопасности;

– требования к эргономике и технической эстетике;

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

– требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

– требования к защите информации от несанкционированного доступа;

– требования по сохранности информации при авариях;

– требования к защите от влияния внешних воздействий;

– требования к патентной чистоте;

– требования по стандартизации и унификации;

– дополнительные требования.


123Следующая ⇒


Дата добавления: 2016-10-06; просмотров: 118 | Нарушение авторских прав


Похожая информация:


Поиск на сайте:


Содержание

Введение

Основы разработки требований к ПО

Требования с точки зрения клиента

Рекомендуемые приемы формулирования требований

Бизнес-аналитик

Этот модуль не является обязательным для завершения учебного курса.

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

Этот модуль не является обязательным для завершения учебного курса.

Игра по правилам

Этот модуль не является обязательным для завершения учебного курса.

Пишем идеальные требования

Этот модуль не является обязательным для завершения учебного курса.

Приложение. Примеры документации требований

Этот модуль не является обязательным для завершения учебного курса.

Обязательная оценка курса

Английское название

GN1410 — Software Requirements

Код курса

Курс читается в бизнес-школе информационных технологий РФЭИ: код GN1410 — “Разработка требований к программному обеспечению”

О курсе

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

Описание

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

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

Мы описываем проверенные на практике способы, приводим примеры и даем общие рекомендации, подчеркивая лучшие мировые практики.

Требования

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

Польза

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

Цели и намерения

Изучив данный курс вы научитесь разрабатывать спецификации требований к ПО, которые помогут вам:

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

Условия завершения и оценка

Электронный недифференцированный зачёт.

Для получения оценки «зачтено» Вам необходимо выполнить все обязательные тестовые задания, вынесенные на зачет.

Результаты обучения

Результат с точки зрения государственного стандарта РФ

Изучив курс, студент будет способен:

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

Используемые образовательные технологии

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

Рекомендованная литература

  1. Карл Вигерс и Джой Битти. Разработка требований к программному обеспечению Издание третье, BHV 2014 г.
  2. Проектная документация. Джесси Рассел, Книга по Требованию, 2013 г.
  3. Документация на программное обеспечение. Д. Рассел, Книга по Требованию, 2014 г.
  4. Прахалад К. К., Кришнан М. С. Пространство бизнес-инноваций. Создание ценности совместно с потребителем, 264 стр., 2012

Общая трудоемкость в ЗЕТ или ETCS

3 ЗЕТ (108 часов)

 

Какие требования бывают

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

Бизнес-требования(business requirements)

Бизнес-требования(business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements)

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

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

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

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

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

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

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

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

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

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

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

Рассмотрим второе требование к библиотечной системе из приведенного выше списка и обратим внимание на выражение "подходящее средство просмотра документов". Библио­течная система может предоставлять документы в широком спектре форматов.

Какие бывают требования?

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

Системные требования (system requirements)

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

Бизнес-правила (business rules)

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

Характеристика продукта (feature)

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

Какими характеристиками должны обладать хорошие требования?

Характеристики качества превосходных требований:

Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработ
чиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

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

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

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

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

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

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

http://www.e-college.ru/xbooks/xbook164/book/index/index.html

Запись опубликована автором admin в рубрике Макетинг и управление. Добавьте в закладки постоянную ссылку.

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

Год выпуска: 2002

Автор: Алистер Коберн

Жанр: Компютерная литература

Издательство: Лори

Серия: 5800

ISBN: 0-201-70225-8, 5-85582-152-8

Формат: DjVu

Качество: Отсканированные страницы

Количество страниц: 288

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

Данная книга эксперта по объектной технологии Алистера Коберна служит новейшим практическим руководством по написанию вариантов использования. Богатый опыт в этой области помогает автору расширить классическое толкование вариантов использования. В книге представлены начальная, промежуточная и расширенная концепция, поэтому она подходит читателям с разным уровнем подготовки. Инструкции подкреплены наглядными примерами и упражнениями.

Требования к системе в целом

Скачать торрент бесплатно

На сайте нет ни одной электронной версии ни одного произведения. На сайте нет torrent-файлов. Сайт — это каталог ссылок, присылаемых и публикуемых пользователями сайта RuTracker. Если вы правообладатель какого-либо представленного материала и не хотите, чтобы ссылка на него размещалась в нашем каталоге, свяжитесь с нами (мыло ниже), и мы незамедлительно удалим ее.

For DMCA requests: mail[at]rutracker.site

Общие требования к программному продукту

⇐ Предыдущая1234Следующая ⇒

Описание требований к программному продукту содержит:

— обозначения и указания;

— функциональные возможности;

— надежность;

— эффективность.

При описании общих требований к программному продукту необходимо указать:

а) целевые рабочие задачи, которые могут быть выполнены данным продуктом;

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

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

1) процессоры, включая сопроцессоры;

2) объем основной памяти;

3) типы периферийных устройств;

4) оборудование ввода и вывода;

5) сетевое оборудование;

6) системные и прочие программные средства;

г) соответствующие интерфейсы или продукты, если в описании продукта имеются ссылки на интерфейсы с другими продуктами;

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

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

ж) необходимое программное обеспечение для сопровождения продукта.

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

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

б) граничные значения. Если использование продукта ограничено конкретными граничными значениями. Они должны быть указаны в описании продукта, например:

1) минимальные или максимальные значения;

2) длины ключей;

3) максимальное число записей в файле;

4) максимальное число критериев поиска;

5) минимальный объем выборки.

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

При описании надежности продукта необходимо привести информацию по процедурам сохранения данных. Например:

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

— описание технологии сбора, передачи, обработки и выдачи информации;

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

— восстановление при ошибках.

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

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

Экспериментальный раздел

Обоснование выбора языка программирования

В обосновании выбора языка программирования аргументируется выбор языка программирования и используемой системы управления баз данных (далее СУБД).

Дается их краткая характеристика.

Описание программы

Описание программы содержит: описание модулей, модульную схему задачи, схему алгоритма.

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

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

Протокол тестирования программного продукта

В протоколе тестирования отражаются:

— тестирование на корректных данных;

— тестирование на некорректных данных;

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

Руководство пользователя

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

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

Требования к программным продуктам

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

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

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

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

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

Руководство пользователя должно содержать:

— руководство по установке и запуску программы;

— руководство по использованию программы;

— сообщения пользователю.

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

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

Таблица 9 — Сообщение пользователю

Сообщение Причина Что делать
     
     

Экономический раздел

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


⇐ Предыдущая1234Следующая ⇒


Дата добавления: 2017-01-28; просмотров: 230 | Нарушение авторских прав


Похожая информация:


Поиск на сайте:


Функциональная спецификация программного средства.

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

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

Функциональная спецификация состоит из трех частей:

· описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;

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

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

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

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

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

 

4.5. Методы контроля внешнего описания программного средства.

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

Техническое задание по ГОСТ 34 — разделы 4-8

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

* статический просмотр,

* смежный контроль,

* пользовательский контроль,

* ручная имитация.

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

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

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

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

 

1234


Дата добавления: 2016-04-06; просмотров: 239;


ПОСМОТРЕТЬ ЕЩЕ:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *