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

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

1. Понятие жизненного цикла программных средств 2. Нормативно - методическое обеспечение создания программных средств 3. Процессы жизненного цикла 4. Модели жизненного цикла

ЖЦ ПС – это непрерывный процесс, начинающийся с момента принятия решения о необходимости создания ПС и заканчивающийся в момент полного его изъятия из эксплуатации

Малые относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3-5) специалистов нет необходимости в регламентировании их жизненного цикла Большие крупномасштабные комплексы программ для сложных систем управления и обработки информации, оформляемые в виде программных продуктов с гарантированным качеством

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

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

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

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

международные стандарты International Organization of Standardization (ISO) International Electrotechnical Commission (IEC) стандарты Российской Федерации ГОСТ Р стандарты организации - заказчика

CMM/CMMI (Capability Maturity Model Integration for Product and Process Development) – Интегрированная модель оценивания зрелости продуктов и процессов разработки ПО ISO 9001 – Система менеджмента качества ISO 9003 – Руководство по организации применения стандарта ISO 9001 для ПО ISO 9126 – Оценка программного продукта ISO – Процессы жизненного цикла ПО ISO – Оценка и аттестация зрелости процессов жизненного цикла ПО ISO – Процесс измерения ПО и др.

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

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

международный стандарт ISO/IEC его российский аналог ГОСТ Р ИСО / МЭК Основные 2. Вспомогательные 3. Организационные

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

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

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

1. Процесс документирования предусматривает формализованное описание информации, созданной в течении ЖЦ ПС 2. Процесс управление конфигурацией предполагает применение административных и технических процедур на всём протяжении ЖЦ ПС для определения состояния компонентов ПС в системе, управления модификациями ПС, обеспечения полноты, совместимости и корректности компонентов ПС и т. д. 3. Процесс обеспечения качества обеспечивает соответствующие гарантии того, что ПС и процессы его ЖЦ соответствуют заданным требованиям

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

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

Модель ЖЦ ПС включает в себя : стадии результаты выполнения работ на каждой стадии ключевые события ( точки завершения работ и принятия решений )

1. разработка требований 2. проектирование 3. реализация ( кодирование, программирование ) 4. тестирование и отладка 5. ввод в действие ( эксплуатация и сопровождение )

Модели жизненного цикла КаскаднаяИтерационная

Разработка требований ПроектированиеРеализацияТестирование Ввод в действие

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

Разработка требований ПроектированиеРеализацияТестирование Ввод в действие

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

Проектирование Реализация Тестирование Разработка требований Версия 1 Версия 2 Версия 3

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

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

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

Основная цель : подготовить возможность принять обоснованное решение о допустимости дальнейшего продвижения проекта

1. Процессы технико - экономического обоснования создания ПС 2. Моделирование бизнес - процессов 3. Разработка требований к ПС 4. Оценка трудоёмкости создания ПС 5. Структура основных документов, отражающих требования к ПС 6. Планирование жизненного цикла ПС 7. Ресурсы для обеспечения функциональной пригодности ПС 8. Ошибки и риски

Оценка технико - экономических показателей ( ТЭП ) изменение некоторых ТЭП и выделяемых ресурсов прекращение проектирования ПС

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

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

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

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

размер и сложность создаваемого ПС выбор инструментальных средств уровень автоматизаци и технологии доля этих затрат в общих затратах на разработку

Трудоёмкость Размера ПС Срок разработки Повторно используемые компоненты

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

При расчёте трудоёмкость конкретного проекта следует учитывать факторы, влияния которых в конкретном проекте имеют достаточную величину. Все факторы можно разделить на две группы. 1. изменяют трудоёмкость в несколько раз ( до 3-5) 2. в конкретном проекте могут повлиять на изменение трудоёмкости разработки на 10-20%

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

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

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

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

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

" как есть " отражающие существующее на момент обследования положение дел в организации позволяющие понять, каким образом функционирует данная организация позволяет выявить узкие места и сформулировать предложения по улучшению ситуации AS-IS " как должно быть " отражает представление о новых процессах и технологиях работы организации AS-TO-BE

1. Какие процедуры ( функции, работы ) необходимо выполнить для получения заданного конечного результата ? 2. В какой последовательности выполняются эти процедуры ? 3. Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес - процесса ? 4. Кто выполняет процедуры процесса ? 5. Какую входящую информацию использует каждая процедура процесса ? 6. Какую исходящую информацию генерирует процедура процесса ? 7. Какие ресурсы необходимы для выполнения каждой процедуры процесса ? 8. Какие условия регламентируют выполнение процедуры ? 9. Какие параметры характеризуют выполнение процедур и процесса в целом ?

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

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

Осуществимость Нормирование и анализ требований Специфицирование требований Аттестация и утверждение требований Отчет об осуществимости системы Модели системы Пользовательские и системные требования Документация требований

разбиение сложной системы на подсистемы должны содержать в полной и сжатой форме потребности пользователей должны быть достаточно конкретными содержать информацию, какие функции должны осуществляться, а не то, как они реализуются изменения являются неотъемлемой частью ЖЦ ИС

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

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

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

сильное защищённость надёжность эффективность слабое сопровождаемость мобильность

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

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

Модели и методы оценки трудоёмкости используются для : разработки бюджета проекта анализа степени риска и выбора компромиссного решения планирования и управления проектом анализа затрат на улучшение качества ПС

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

анализ статистических данных о ранее выполненных проектах определяется зависимость трудоёмкости проекта от какого - нибудь количественного показателя программного продукта оценка этого показателя для данного проекта Алгоритмическое моделирование опрос нескольких экспертов сравнивание оценок повторение до согласия Экспертные оценки

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

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

1. оценка размера разрабатываемого продукта 2. оценка трудоёмкости в человеко - месяцах или человеко - часах 3. оценка продолжительности проекта в календарных месяцах 4. оценка стоимости проекта

количество строк кода (LOC – Lines of Code) не возможно определить количество строк кода до того, как они будут написаны не учитывается сложность продукта, способности программиста и возможности языка программирования не линейная зависимость к затрачиваемым усилиям функциональные точки (FP – Function Points) трудоёмкость вычисляется на основе функциональности разрабатываемого ПО

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

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

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

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

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

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

11. ожидаемые результаты и возможная эффективность реализации выбранного варианта требований 12. ориентировочный план реализации 13. общие требования к составу и содержанию документации проекта ПС 14. оценка необходимых затрат 15. предварительный состав требований качества 16. предварительные требования к условиям испытаний и приёмки

1. требования проекта системы к комплексу программ 2. требования к унификации интерфейсов БД и комплекса программ 3. требования и обоснование выбора проектных решений с точки зрения пользователя 4. спецификация требований к компонентам системы, интерфейсам между системными компонентами, элементами конфигурации программных компонентов и аппаратуры

5. описание распределения системных требований по компонентам ПС 6. требования к архитектуре ПС 7. требования совместного целостного функционирования компонентов ПС 8. требования для ПС и подсистем

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

Цель : выбор и определение способов создания и совершенствования ПС, удовлетворяющую требованиям ТЗ

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

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

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

Трудности достижения высокого качества ПС отсутствии полной совокупности достоверных требований к значениям характеристик качества на начальных этапах проектирования и разработки итерационный процесс конкретизации требований в течение всего ЖЦ ПС отсутствие чёткого представления о реальных ресурсах, необходимых для их реализации ПС

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

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

Менеджер проекта ПС Менеджер – системный архитектор ПС Разработчики ПС Проектировщики спецификаций на компоненты Разработчики компонентов и программисты Системные интеграторы компонентов и ИС Тестировщики компонентов и ПС Управляющие сопровождением и конфигурацией ПС Документаторы проекта ПС Технологи и специалисты по качеству Технологи и специалисты по технологическому инструментарию Управляющие и контролеры текущего применения системы обеспечения качества Инспекторы по проверке состояния и степени применения системы качества

ЗАКАЗЧИК РАЗРАБОТЧИК функциональные и потребительские характеристики ПС способы реализации характеристик ПС с требуемым качеством

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

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

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

менеджер проекта – специалист, обеспечивающий коммуникацию между заказчиком и проектной командой менеджер - архитектор ПС – управляет коммуникациями и взаимоотношениями в проектной команде

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

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

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

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

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

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

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

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

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

1. подготовка детальных исходных требований и характеристик ПС и внешней среды, для которых должны отсутствовать риски функционирования и применения 2. выделить три класса рисков : функциональной пригодности ПС конструктивных характеристик качества нарушения ограничений ресурсов при реализации процессов ЖЦ ПС 3. в каждом классе выделить несколько наиболее важных рисков и упорядочить их по степени опасности для проекта ПС

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

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

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

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