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

Практические занятия
3. Научно-технический семинар
4. Лабораторный работы
5. Курсовой проект «Поддержка ЖЗ программного обеспечения (спецификация требований)

обеспечения и его модели. Классификация и специфицирование требований
Тема 2 Методологические и методические основы формирования и многокритериального анализа требований
Тема 3 Качество программного обеспечения и модели его оценивания
Тема 4 Международные и отечественные стандарты качества программного обеспечения
Тема 5 Управление рисками в программном проекте
Тема 6 Формальные методы оценивания качества программного обеспечения. Верификация и валидация требований к программному обеспечению.
Тема 7 Интеллектуальные и информационные технологии формирования и многокритериального анализа требований к программному обеспечению.

и программной инженерии
Основные понятия, определения и стандарты программной инженерии

и программной инженерии

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

потребителей

-

НКУ НКА

ЦУП

Пример сложной технической системы (CTС)

НКА; РБДЗ распределенная база данных (знаний); ТМА типовой модуль автоматизации; ЛСОД локальная система обмена данными; УМОД унифицированный модуль обмена данными; КИС командно-измерительная система; АРМ автоматизированное рабочее место, БНО баллистическое и навигационное обеспечение; ИТО информационно-телеметрическое обеспечение; КДО контрольно-диагностическое обеспечение; КПО командно-программное обеспечение; РСОД распределенная сеть обмена данными.

Техническая структура НКА, КИС, ЦУП НКА

средствами.

НКС.

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

Особенности современных объектов
военно-государственного управления

/40

ОВГУ

Особенности современных ОВГУ

/40

Р

Проблемы построения систем управления и мониторинга ОВГУ

/40

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

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

данных в реальном времени

ERP - система (Enterprise Resource Planning System) Система планирования ресурсов предприятия

MES - система (Manufacturing Execution System) Производственная исполнительная система

SCADA – система Система операторского диспетчерского управления

АСУ предприятия

АСУ подразделений

АСУ ТП подразделений

Обобщенная структура современной интегрированной
АСУ СОТО

/40

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

(пассивные, активные)

Антенна

ЧИП

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

Ридер со встроенным компьютером

стоимость RFID-меток составляет от $1 до $0.15,
что существенно превышает стоимость марок штрих-кодов.
Однако существует устойчивая тенденция к ее снижению

цикла

Логистика сегодня, №4, 2010 )

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

системы:
Рост числа устройств со встроенными процессорами и средствами хранения данных (более 50 млрд. устройств; более 5 млрд. Smart Phone). 
Интеграция, позволяющая достигнуть наибольшего эффекта путем объединения отдельных компонентов в большие системы: Интернет вещей (IoT), World Wide Sensor Net, произвлодственный Интернет, умные среды обитания (Smart Building Environment), оборонные системы будущего (NetworkCentric Systems) и т.д.
Ограничение когнитивных способностей человека, которые эволюционируют медленнее, чем машины ( человек уже не в состоянии справиться с объемом информации, требуемой для принятия решений).
Администрация первого президентского срока Барака Обамы включила киберфизические системы в приоритетный список инноваций, а после его переизбрания линия развития подтвердилась. В 2013 году была утверждена вторая редакция президентского инновационного партнерства USA Presidential Innovation Fellows, где среди девяти приоритетных направлений присутствует и US Multi-agency funding Cyber-Physical Systems initiative (CPS) .

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

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

СЕЛЬСКОЕ ХОЗЯЙСТВО, ГРАДОСТРОИТЕЛЬСТВО, ГЕОДЕЗИЯ, КАРТОГРАФИЯ, МЕДИЦИНА, ТЕЛЕВИДЕНИЕ, СВЯЗЬ, ИНТЕРНЕТ, МЕТЕООБСТАНОВКА, ГЕОЛОГИЯ, СПАСАНИЕ ТЕРПЯЩИХ БЕДСТВИЯ В ВОЗДУХЕ, НА ВОДЕ И НА СУШЕ
МОНИТОРИНГ:
КРИТИЧЕСКИ ВАЖНЫХ ОБЪЕКТОВ И ОПАСНЫХ ГРУЗОВ, ДВИЖЕНИЯ ВСЕХ ВИДОВ ТРАНСПОРТНЫХ СРЕДСТВ, ПРИРОДНЫХ И АНТРОПОГЕННЫХ ЧС, И ДР.

Источник: НИИ КС

Самолечение.
Самосохранение.
Проактивность
Коммуникабельность

Концепция адаптивных и самоорганизующихся компьютерных систем

Hewlett-Packard-Adaptive Infrastructure (Adaptive Enterprise);
IBM-Computing On Demand; Autonomous Computing;
Microsoft-Dynamic Systems;
Sun Microsystems-N1.

Концепция адаптивных и самоорганизующихся компьютерных систем

ИНФРАСТРУКТУРЫ
НА ХОДУ ПОЕЗДА

СИСТЕМЫ КОНТРОЛЯ МЕСТОПОЛОЖЕНИЯ ВАГОНОВ, ЛОКОМОТИВОВ И
ЭКСПЛУАТАЦИОННОГО ПЕРСОНАЛА
С ИХ АВТОМАТИЧЕСКОЙ
ИДЕНТИФИКАЦИЕЙ

СПУТНИКОВЫЕ ТЕХНОЛОГИИ МОНИТОРИНГА ОБЪЕКТОВ И РАДИОЛОКАЦИОННОГО ЗОНДИРОВАНИЯ

ЕДИНОЕ ИНФОРМАЦИОННОЕ ПРОСТРАНСТВО ТРАНСПОРТА
С ОБЕСПЕЧЕНИЕМ ИНФОРМАЦИОННОЙ ЗАЩИТЫ

ИНТЕЛЛЕКТУАЛЬНЫЙ ЖЕЛЕЗНОДОРОЖНЫЙ ТРАНСПОРТ

СИСТЕМЫ УПРАВЛЕНИЯ ДВИЖЕНИЕМ ПОЕЗДОВ НА ОСНОВЕ СПУТНИКОВОЙ НАВИГАЦИИ ЦИФРОВОЙ РАДИОСВЯЗИ (ГЛОНАСС)

ЦЕНТРЫ СИТУАЦИОННОГО КОНТРОЛЯ
И ПРОГНОЗИРОВАНИЯ КРИТИЧЕСКИХ СИТУАЦИЙ

ИНТЕЛЛЕКТУАЛЬНЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ЭКСПЛУАТАЦИОННОЙ РАБОТОЙ

СИСТЕМЫ ЦИФРОВОЙ РАДИОСВЯЗИ СО ВСЕМИ ОБЪЕКТАМИ ТРАНСПОРТНОЙ ИНФРАСТРУКТУРЫ

СИСТЕМЫ
ФИНАНСОВОГО МОНИТОРИНГА И ОПТИМИЗАЦИИ РАСХОДОВ

ИНТЕЛЛЕКТУАЛЬНЫЕ ЛОГИСТИЧЕСКИЕ СИСТЕМЫ

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

Интеллектуальные решения успешно используются в железнодорожных компаниях ряда стран:

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

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

сферы жизни современного общества.
Раньше компьютер был компьютером, а телефон – телефоном, и любой мог отличить одно от другого. Cейчас и компьютер – не только компьютер, и телефон – не только телефон (A.Tanenbaum)
Эра параллельного программирования Последовательные программы имеют очень узкое применение Многоядерные чипы, встроенные бортовые СУ -> требуются технологии разработки параллельного ПО, чтобы оно выполняло нужные функции Multicore processors are bringing parallelism to mainstream of computing
Параллельные программы полны ошибок Параллельные программы непостижимы для человеческого мозга: они очень часто неправильны, содержат ошибки

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

Ю.Г.Карпов

Семинар "Наука и общество"

Замена миллионов дефектных процессоров ⇒ потери ~$500 млн.
4.06.96 ракета Ариан 5 взорвалась через 39 с. Ошибка в бортовой программе при преобразовании 64-битового вещ в 16-бит целое. Ущерб > $600 млн.
Конец 80-х: Therac-25 прибор лучевой терапии. Встроенная программа управления прибором допускала перевод в режимы с огромной дозой облучения. При некоторых (редких) действиях персонала пациенты получали передозировку. Двое умерли, несколько человек стали инвалидами.
23.03.2003. Война в Ираке. Ошибка в программе ⇒ система Patriot определила свой бомбардировщик Tornado как приближающуюся ракету и его сбили. Два пилота погибли. До 24% потерь в живой силе в I Иракской войне – “Friendly Fire”.
Boeing 757, 1995 г (рейс из Майами в Колумбию ). Ошибка в Flight Management System привела к катастрофе. Погибли 159 человек. Фирма-разработчик ПО выплатила $300 млн родственникам жертв
Бортовой компьютер на израильском истребителе в районе Мёртвого моря отказал: деление на 0. Высота над уровнем моря там является отрицательной величиной

Ю.Г.Карпов

Семинар "Наука и общество"

заливе: возможна ли программная ошибка? Don Shafer, Phillip Laplante. The BP Oil Spill: Could Software be a Culprit? IEEE IT Pro September/October 2010, IEEE, 2010. ... Не могла ли одной из причин бедствия стать ошибка в программном обеспечении?

05.07.2010. Apple: ошибка связи iPhone 4 — программная. Компания Apple признала существование в iPhone 4 проблем, касающихся качества связи.

08.12.2010 — Японский зонд «Акацуки» не смог выйти на орбиту Венеры
Космический исследовательский аппарат «Акацуки», запущенный Японией для исследования Венеры, не смог выйти на орбиту планеты, сообщает РИА «Новости» со ссылкой на специалистов Японского аэрокосмического агентства JAXA

06.12.2010. Cпутники ГЛОНАСС и ракету “Протон-М” утопили программисты. Ракета-носитель «Протон-М» со спутниками «Глонасс-М» отклонились от заданного курса из-за допущенных ошибок в математическом обеспечении (основная причина - неправильно написанная формула в документации на заправку кислородом разгонного блока)

область 146.47%

58.99%
32.96%
23.74%
19.41%
9.32%
1.46%
0.59%

Σ 146.47%

методах разработки является тестирование
Эдсгер Дейкстра: “Тестирование не может доказать отсутствия ошибок в программе”

В среднем современные программные системы имеют 10 ошибок на 1000 строк кода, ПО высокого качества 1-3 ошибки на 1000 строк кода

Современное ПО содержит миллионы строк кода Уже сданные работающие программы наполнены ошибками

В ОС Windows 95 ~ 5000 ошибок «Good enough software» недопустимо для критических применений

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

Программист обычно НЕ ЗНАЕТ (и не хочет знать!) как определить требования к результату своей работы? как проверить, что эти требования выполняются?

-> в океан

Важность проблемы валидации

До 80% средств при разработке встроенного ПО тратится на валидацию – проверку соответствия ПО тому, что нужно потребителю ($60 billion annually for US economy – данные 2005 г.)
При оставшихся в системах ошибках:
Огромные материальные потери
Потери жизней
КТО БУДЕТ ОТВЕЧАТЬ? Страховка?
низкая надежность продукта ⇒ падает прибыль
увеличивается время разработки (time-to-market)
иски после аварии ⇒ компания разоряется

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

ЧТО ДЕЛАТЬ?

(Automated system software) по ГОСТ 34.003-90 – это совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС [из п. 2.7 ГОСТ 34.003-90]
Программное обеспечение автоматизированной системы включает в свой состав общее программное обеспечение (ОПО) и специальное программное обеспечение (СПО).
Общее программное обеспечение (ОПО) автоматизированной системы (АС) (Automated system heave-duty software) по ГОСТ 34.003-90 –это часть программного обеспечения АС, представляющая собой совокупность программных средств (ГОСТ 28806-90), разработанных вне связи с созданием данной АС. Примечание - Обычно ОПО АС представляет собой совокупность программ общего назначения, предназначенных для организации вычислительного процесса и решения часто встречающихся задач обработки информации [из п. 6.2 ГОСТ 34.003-90]

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

системы (АС) (Automated system application software) по ГОСТ 34.003-90 – это часть программного обеспечения АС, представляющая собой совокупность программ, разработанных при создании данной АС [из п. 6.3 ГОСТ 34.003-90]
 
Специальное программное обеспечение, как правило, работает «поверх» общего ПО (т.е. под управлением операционной системы) и обычно является клиентской частью, взаимодействующей с серверной частью, установленной на удаленном (или не очень) сервере, по локальной или глобальной компьютерной сети. Если серверная часть СПО представляет собой веб-приложение, то в качестве клиентской части применяется браузер, входящий в состав общего программного обеспечения («тонкий» клиент).

инженерии

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

инженерии

В IEEE Standard Glossary of Software Engineering Terminology (1990) понятие требование к ИС ((ПО) трактуется следующим образом. Требование – это:
1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для пунктов 1 и 2.
В нотации RUP приводит следующее определение: «Требование – это условие или возможность, которой должна соответствовать система».

инженерии

Требования к продукту. В своей основе требования – это то, что формулирует заказчик. Цель, которую он преследует – получить хороший конечный продукт: функциональный и удобный в использовании. Поэтому требования к продукту являются основополагающим классом требований. Более подробно требования к продукту детализируются в следующих ниже классификациях.
Требования к проекту. Вопросы формулирования требований к проекту, т.е. к тому, как Разработчик будет выполнять работы по созданию целевой системы, казалось бы, не лежат в компетенции Заказчика. Без регламентации процесса Заказчиком легко можно было бы обойтись, если бы все проекты всегда выполнялись точно и в срок. Однако, к сожалению, мировая статистика результатов программных проектов говорит об обратном. Заказчик, вступая в договорные отношения с Разработчиком, несёт различные риски, главными из которых является риск получить продукт с опозданием, либо ненадлежащего качества. Основные мероприятия по контролю и снижению риска – регламентация процесса создания программного обеспечения и его аудит.

инженерии

В качестве требований к проекту могут быть внесён регламент отчётов Разработчика, совместных семинаров по оценке промежуточных результатов, определены характеристики компетенций участников рабочей группы, исполняющих проект, их количество, указана методология управления проектом. Ниже сформулирован пример формулировки требования к оффшорному проекту (Заказчик и Разработчик физически находятся в разных государствах) – в этой ситуации Заказчику требуется жёсткий контроль над Разработчиком.
1) Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure - WBS) с точностью до конкретных исполнителей.
2) Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонент разрабатываемого продукта и тестирование продукта в целом.
3) Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase® с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
Следующий уровень – уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
Третий уровень – функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удалён и перемещён с участка на участок.

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

определение системы: «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы». Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [14]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.

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

поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс выделяет следующие основные группы нефункциональных требований:
Внешние интерфейсы (External Interfaces),
Атрибуты качества (Quality Attributes),
Ограничения (Constraints).

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

FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990.
Акроним FURPS обозначает следующие категории требований:
Functionality (Функциональность).
Usability (Применимость).
Reliability (Надёжность).
Performance (Производительность).
Supportability (эксплуатационная пригодность).
Символ «+» расширяет FURPS-модель, добавляя к ней:
ограничения проекта,
требования выполнения,
требования к интерфейсу,
физические требования, часть из которых уже была рассмотрена выше.
Кроме того, в спецификациях RUP выделяются такие категории требований, как
требования, указывающие на необходимость согласованности с некоторыми юридическими и нормативными актами;
требования к лицензированию,
требования к документированию.

области работы с требованиями можно выделить следующие.
1. Разработки IEEE:
IEEE 1362 “Concept of Operations Document”.
IEEE 1233 «Guide for Developing System Requirements Specifications».
IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»
IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.
2. Отечественные ГОСТ:
ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.  ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

и статистика, 2003. - 768 с.
2. ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение, эксплуатация/Дэниел О’Лири;[Пер. с англ. Ю.И.Водопьяновой]. – М.: ООО «Вершина», 2004. – 272 с.
3. Меняев М.Ф. Информационные технологии управления: Учебное пособие: В 3 кн.: Книга 3: Системы управления организацией. – М.: Омега-Л, 2003. – 464 с.
4. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие. – М.: Гелиос АРВ, 2002. – 368 с., ил.
5. Б.Н. Гайфуллин, И.А. Обухов. Автоматизированные системы управления предприятиями стандарта ERP/MRPII. Производственное издание. – М. «Богородский печатник», 2001, 104 с.
6. Петров В. Н. Информационные системы. – СПб.: Питер, 2002. - 688 с.
7. IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
8. Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.
9. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002.

к системам. М.: издательство «Лори», 2002. – 263 с.
11. Мацяшек Лешек. Анализ требований и проектирование систем. Разработка информационных :с Диалектика-Вильямс
12. Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требования. Copyright © Сергей Орлик, 2004-2005. http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf
13. IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004. – http://www.swebok.org
14. ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ. Информационная технология. Процессы жизненного цикла информационных систем. Издание официальное. – М., 1999.
15. Л.Новиков. Введение в Rational Unified Process. http://www.interface.ru/rational/interface/151199/rup/main.htm
16. Белые страницы MSF. http://www.microsoft.com/rus/msdn/msf
17. Analyzing requirements and defining Microsoft .Net solution architectures 2000 г. 491 стр. Microsoft Press.

– СПб.: Вильямс, 2002. – 240 с.
19. Унифицированный процесс разработки программного обеспечения/ А. Якобсон, Г. Буч, Дж. Рамбо – СПб.: Питер , 2002. – 496 с .
20. IEEE 1362 - Concept of Operations Document
21. IEEE 1233 - Guide for Developing System Requirements Specifications.
22. IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»

system software) по ГОСТ 34.003-90 – это совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС [из п. 2.7 ГОСТ 34.003-90]
Программное обеспечение автоматизированной системы включает в свой состав общее программное обеспечение (ОПО) и специальное программное обеспечение (СПО).
Общее программное обеспечение (ОПО) автоматизированной системы (АС) (Automated system heave-duty software) по ГОСТ 34.003-90 –это часть программного обеспечения АС, представляющая собой совокупность программных средств (ГОСТ 28806-90), разработанных вне связи с созданием данной АС.

Ю.Г.Карпов

Семинар "Наука и общество"

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

Ю.Г.Карпов

Семинар "Наука и общество"

(АС) (Automated system application software) по ГОСТ 34.003-90 – это часть программного обеспечения АС, представляющая собой совокупность программ, разработанных при создании данной АС [из п. 6.3 ГОСТ 34.003-90]

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

Ю.Г.Карпов

Семинар "Наука и общество"