ПОЗНАВАТЕЛЬНОЕ

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

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

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

Описание информационных массивов

1 2 34

3.1. Раздел “Описание информационных массивов” должен состоять из описей:

· Входной оперативной информации;

· Нормативно-справочной информации;

· Выходной информации.

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

· Входных документов;

· Информационных массивов на машинных носителях.

3.3. Описание входных документов должно включать:

· Перечень документов;

· Описание реквизитов, используемых при решении задачи;

· Системы кодирования;

· Формы документов с отметкой перфорируемых реквизитов.

3.4. В перечне входных данных следует приводить:

· Наименование документа;

· Шифр или условное обозначение документа;

· Периодичность поступления документа;

· Дату поступления документа;

· Наименование и шифр задачи, при решении которой образуется документ.

3.5. В описании реквизитов входных документов следует приводить:

· Наименование и шифр документа;

· Наименование реквизитов;

· Шифр и обозначение реквизитов;

· Вид реквизита (цифровой или символьный);

· Длину реквизита в символах (для числовых реквизитов необходимо указать отдельно длину целой и дробной частей);

· Единицу измерения;

· Диапазон измерения.

3.6. Описание информационных массивов на машинных носителях должно включать:

· Перечень информационных массивов;

· Описание реквизитов информационных массивов;

· Макеты записей информационных массивов.

3.7. В перечне информационных массивов на машинных носителях следует указать:

· Наименование массива;

· Шифр и обозначение массива;

· Вид машинного носителя;

· Характера записи (постоянная или переменная длина записи);

· Максимальное количество записей в массиве;

· Параметр упорядочения массива;

· Наименование и шифр задачи, при решении которой образуется массив.

3.8. В описании реквизитов информационных массивов на машинных носителях следует указывать:

· Наименование и шифр массива;

· Наименование реквизита;

· Шифр или условное обозначение реквизита;

· Форму представления реквизита (восьмеричная, десятичная, символьная и т.д.);

· Длину реквизита в знаках.

3.9. Описание нормативно-справочной информации должно включать:

· Описание документов для форматирования массивов нормативно-справочной информации, которое следует выполнять в порядке, указанном в п.3.3;

· Описание массивов нормативно-справочной информации на машинных носителях, которое следует выполнять в порядке, указанном в п.3.6;

· Описание системы кодирования нормативно-справочной информации;

· Периодичность внесения изменений в массивы.

3.10. Выходную информацию следует представлять в виде:

· Информационных массивов на машинных носителях

3.11. Описание выходных документов должно включать:

· Перечень выходных документов;

· Описание реквизитов, которое следует выполнять в порядке, указанном в п.3.5;

· Формы выходных документов.

3.12.В перечне выходных документов следует приводить:

· Наименование документа;

· Шифр или условное обозначение документа;

· Периодичность выдачи;

· Срок выдачи;

· Количество экземпляров.

3.13.Утверждение выходных конструкторских и технологических документов следует проводить в порядке, установленном стандартами ЕСКД и ЕСТД.

3.14.Описание выходных информационных массивов на машинных носителях следует выполнять в порядке, указанном в п.3.6.

Алгоритм решения задачи

4.1.Раздел «Контрольный пример» должен включать:

· Описание схемы решения с указанием последовательности этапов расчёта;

· Расчётные формулы для решения задачи и подготовки обрабатываемой информации;

· Контрольные соотношения для процесса решения и проверки его результата.

4.2.Символы, используемые в блок-схеме алгоритма решения задачи, следует выполнять по ГОСТ 19438-74.

4.3.Блок-схему алгоритма решения задач следует выполнять по ГОСТ 19247-74.

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

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

4.6.При использовании в описании алгоритма решения задачи не стандартизированных терминов следует составить словарь не стандартизированных терминов и помещать его в приложении.

Контрольный пример

5.1.Раздел «Контрольный пример» должен включать:

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

· Текстовую и цифровую распечатку содержания информационных массивов на машинных носителях;

· Выходные документы или текстовые и цифровые распечатки содержания выходных информационных массивов на машинных носителях.

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

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

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

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

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РЕСПУБЛИКИ БЕЛАРУСЬ

Информационные технологии

Процессы жизненного цикла программных средств

Год введения 2003

Процесс разработки

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

Разработчик управляет процессом разработки на проектном уровне в соответствии с процессом управления (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2); адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации (приложение А) и управляет процессом разработки на организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4). Если разработчиком является поставщик разрабатываемого программного продукта, то разработчик должен также выполнять процесс поставки (подраздел 5.2).

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

2) анализ требований к системе;

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

4) анализ требований к программным средствам;

5) проектирование программной архитектуры;

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

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

8) сборка программных средств;

9) квалификационные испытания программных средств;

10) сборка системы;

11) квалификационные испытания системы;

12) ввод в действие программных средств;

13) обеспечение приемки программных средств.

5.3.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

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

5.3.1.2 Разработчик должен:

a) документально оформить выходные результаты в соответствии с процессом документиро-вания (подраздел 6.1);

b) подвергнуть выходные результаты процессу управления конфигурацией (подраздел 6.2) и
выполнять контроль изменений конфигурации в соответствии с данным процессом;

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

d) выполнить вспомогательные процессы (раздел 6) в соответствии с условиями договора.

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

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

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

5.3.2 Анализ требований к системе

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

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

5.3.2.2 Требования к системе должны быть оценены с учетом следующих критериев (при этом результаты оценок должны быть документально оформлены):

a) учет потребностей заказчика;

b) соответствие потребностям заказчика;

c) тестируемость;

d) выполнимость проектирования системной архитектуры;

e) возможность эксплуатации и сопровождения.

5.3.3 Проектирование системной архитектуры

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

5.3.3.2 Системная архитектура и требования к объектам архитектуры должны быть оценены с учетом следующих критериев (при этом результаты оценок должны быть документально оформлены):

a) учет требований к системе;

b) соответствие требованиям к системе;

c) соответствие используемых стандартов и методов проектирования;

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

e) возможности эксплуатации и сопровождения.

5.3.4 Анализ требований к программным средствам

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

5.3.4.1 Разработчик должен установить и документально оформить следующие требования к
программным средствам, включая технические требования к характеристикам качества (рекомен-дации по определению характеристик качества приведены в ИСО/МЭК 9126):

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

b) требования к внешним интерфейсам программного объекта архитектуры;

c) квалификационные требования;

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

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

f) эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию «человек-машина», персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и к обученности персонала;

g) требования к определению данных и базе данных;

h) требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и сопровождения;

i) требования к документации пользователя;

j) требования к эксплуатации объекта пользователем;

k) требования к обслуживанию пользователя.

5.3.4.2 Разработчик должен оценить требования к программным средствам по следующим критериям (при этом результаты оценок должны быть документально оформлены):

a) учет требований к системе и проекту системы;

b) внешняя согласованность с требованиями к системе;

c) внутренняя согласованность требований к объектам между собой;

d) тестируемость требований;

e) выполнимость программного проекта;

f) возможность эксплуатации и сопровождения.

5.3.4.3 Разработчик должен провести совместный(ые) анализ(ы) в соответствии с подразделом 6.6.После успешного проведения анализа(ов) должно быть зафиксировано состояние требований к
программному объекту.

5.3.5 Проектирование программной архитектуры

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

5.3.5.2 Разработчик должен разработать и документально оформить общий (эскизный) проект внешних интерфейсов программного объекта и интерфейсов между компонентами объекта.

5.3.5.3 Разработчик должен разработать и документально оформить общий (эскизный) проект
базы данных.

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

5.3.5.5 Разработчик должен определить и документально оформить предварительные общие требования к испытаниям (тестированию) программного объекта и график сборки программного
продукта.

5.3.5.6 Разработчик должен оценить архитектуру программного объекта и эскизные проекты
интерфейсов и базы данных по следующим критериям (при этом результаты оценок должны быть
документально оформлены):

a) учет требований к программному объекту;

b) внешняя согласованность с требованиями к программному объекту;

c) внутренняя согласованность между компонентами программного объекта;

d) соответствие методов проектирования и используемых стандартов;

e) возможность технического проектирования;

f) возможность эксплуатации и сопровождения.

5.3.5.7 Разработчик должен провести совместный(ые) анализ(ы) в соответствии с подразделом 6.6.

5.3.6 Техническое проектирование программных средств

5.3.6.1 Разработчик должен разработать технический проект для каждого компонента програм-много объекта. Компоненты программного объекта должны быть уточнены на уровне программных модулей, которые можно программировать (кодировать), компилировать и тестировать независимо. Должно быть обеспечено распределение технических требований к компонентам программного объекта между программными модулями. Технический проект должен быть документально оформлен.

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

5.3.6.3 Разработчик должен разработать и документально оформить технический проект базы данных.

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

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

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

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

a) учет требований к программному объекту;

b) внешнее соответствие спроектированной архитектуре;

c) внутренняя согласованность между компонентами программного объекта и программными
модулями;

d) соответствие методов проектирования и используемых стандартов;

e) возможность тестирования;

f) возможность эксплуатации и сопровождения.

5.3.6.8 Разработчик должен провести совместный(ые) анализ(ы) в соответствии с подразделом 6.6.

5.3.7 Программирование и тестирование программных средств

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

5.3.7.1 Разработчик должен разработать и документально оформить следующие продукты:

a) каждый программный модуль и базу данных;

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

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

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

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

5.3.7.5 Разработчик должен оценить запрограммированные элементы программного объекта и результаты их тестирования по следующим критериям (при этом результаты оценок должны быть документально оформлены):

a) учет требований к программному объекту и проекту объекта в целом;

b) внешнее соответствие требованиям и проекту программного объекта;

c) внутреннее соответствие между требованиями к программным модулям;

d) тестовое покрытие всех модулей;

e) соответствие методов программирования и используемых для них стандартов;

f) возможность сборки и тестирования;

g) возможность эксплуатации и сопровождения.

1 2 34