Читаем ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию полностью

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

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

— реакция на отказные ситуации должна быть согласована с требованиями безопасности;

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

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

<p>7.2.3 Проектирование модифицируемого пользователем ПО</p>

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

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

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

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

<p>7.2.4 Проектные решения уровня ЭКПО</p>

Разработчик должен определить и зарегистрировать проектные решения уровня ЭКПО. Результаты должны быть включены в раздел проектных решений уровня ЭКПО документов проектирования ПО (12.16, 12.17, 12.18).

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

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

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

<p>7.3 Процесс кодирования ПО</p>

В процессе кодирования ПО на основании архитектуры ПО и требований нижнего уровня создают исходный код.

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

<p>7.3.1 Цели процесса кодирования ПО</p>

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

Перейти на страницу:

Похожие книги

1С: Бухгалтерия 8 с нуля
1С: Бухгалтерия 8 с нуля

Книга содержит полное описание приемов и методов работы с программой 1С:Бухгалтерия 8. Рассматривается автоматизация всех основных участков бухгалтерии: учет наличных и безналичных денежных средств, основных средств и НМА, прихода и расхода товарно-материальных ценностей, зарплаты, производства. Описано, как вводить исходные данные, заполнять справочники и каталоги, работать с первичными документами, проводить их по учету, формировать разнообразные отчеты, выводить данные на печать, настраивать программу и использовать ее сервисные функции. Каждый урок содержит подробное описание рассматриваемой темы с детальным разбором и иллюстрированием всех этапов.Для широкого круга пользователей.

Алексей Анатольевич Гладкий

Программирование, программы, базы данных / Программное обеспечение / Бухучет и аудит / Финансы и бизнес / Книги по IT / Словари и Энциклопедии
1С: Управление торговлей 8.2
1С: Управление торговлей 8.2

Современные торговые предприятия предлагают своим клиентам широчайший ассортимент товаров, который исчисляется тысячами и десятками тысяч наименований. Причем многие позиции могут реализовываться на разных условиях: предоплата, отсрочка платежи, скидка, наценка, объем партии, и т.д. Клиенты зачастую делятся на категории – VIP-клиент, обычный клиент, постоянный клиент, мелкооптовый клиент, и т.д. Товарные позиции могут комплектоваться и разукомплектовываться, многие товары подлежат обязательной сертификации и гигиеническим исследованиям, некондиционные позиции необходимо списывать, на складах периодически должна проводиться инвентаризация, каждая компания должна иметь свою маркетинговую политику и т.д., вообщем – современное торговое предприятие представляет живой организм, находящийся в постоянном движении.Очевидно, что вся эта кипучая деятельность требует автоматизации. Для решения этой задачи существуют специальные программные средства, и в этой книге мы познакомим вам с самым популярным продуктом, предназначенным для автоматизации деятельности торгового предприятия – «1С Управление торговлей», которое реализовано на новейшей технологической платформе версии 1С 8.2.

Алексей Анатольевич Гладкий

Финансы / Программирование, программы, базы данных