ГОСТ 34.ххх Стандарты информационной технологии

ГОСТ 34 — Комплекс стандартов на автоматизированные системы.

ГОСТ 19.xxx Единая система программной документации

Единая система программной документации — комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

ГОСТ 2.xxx Единая система конструкторской документации

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

Процесс поставки – основные действия и задачи

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

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

В результате успешного осуществления процесса поставки:

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

Процесс приобретения – основные действия и задачи

Процесс приобретения (acquisition process) состоит из действий и задач заказчика, приобретающего программное средство.

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

В результате успешного осуществления процесса приобретения:

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

Запуск RabbitMQ в Docker Compose

docker-compose.yml

version: '3.9'
services:
   rabbitmq:
      build: ./build
      container_name: rabbitmq
      environment:
       - RABBITMQ_ERLANG_COOKIE=SWQOKODSQALRPCLNMEQG
       - RABBITMQ_DEFAULT_USER=rabbit
       - RABBITMQ_DEFAULT_PASS=rabbit
      ports:
       - "15672:15672"
       - "5672:5672"

Файл располагается в корневом каталоге.

Dockerfile

FROM rabbitmq:3-management
COPY ./conf/enabled_plugins /etc/rabbitmq/enabled_plugins

Файл располагается в ./build

enabled_plugins

[rabbitmq_management, rabbitmq_management_visualiser].

Файл располагается в ./conf/enabled_plugins

Подробнее можно почитать на официальной странице Docker Hub — RabbitMQ.

Выполнить сборку контейнера и запустить можно при помощи команды:

docker-compose up --build -d

Понятие жизненного цикла программного продукта в соответствии с международным стандартом ISO/IEC 12207. Понятие и состав процесса. Классификация процессов

Жизненный цикл (life cycle) — развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения.

Программный продукт (software product) — совокупность компьютерных программ, процедур и, возможно, связанных с ними документации и данных.

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

Состав процесса:

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

Классификация процессов:

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

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

Создание программной документации — важный этап, так как пользователь начинает свое знакомство с программным продуктом именно с документации. Для чего предназначен программный продукт, как установить программный продукт, как начать с ним работать — вот одни из первых вопросов, на которые должна отвечать программная документация (Installation Guide, Getting Started). Составлением программной документации обычно занимаются специальные люди — технические писатели (иногда программную документацию пишут сами программисты или аналитики). Этот этап является самым неприятным и тяжелым в программистской работе. К сожалению, обычно этому либо не учат совсем, либо в лучшем случае не обращают на качество получаемых документов должного внимания. Тем не менее владение этим искусством является одним из важнейших факторов, определяющих качество программиста.

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

Грамотно составленный (точнее, созданный) пакет программной документации избавит вас от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно, просто отослав пользователя к документации. Это касается прежде всего важнейшего документа — Технического задания. Можно напомнить о многомиллионном иске к компании IBM, который предъявило одно крупноеиздательство, не удовлетворенное качеством вычислительной техники и программного обеспечения. IBM суд выиграла только благодаря тому, что предъявила подписанное обеими сторонами Техническое задание. Было это давно, еще в 70-х годах 20 века, однако сути дела это не меняет. На Западе важность программной документации поняли давно, вместе с программным обеспечением поставляется целый пакет документации.

Вообще программную документацию можно разделить по отношению к пользователю на внутреннюю и внешнюю.

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

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:

  • Что должно быть сделано, кроме собственно программы?
  • Что и как должно быть оформлено в виде документации?
  • Что передавать пользователям, а что — службе сопровождения?
  • Как управлять всем этим процессом?
  • Что должно входить в само задание на программирование?

На эти и другие вопросы когда-то отвечали государственные стандарты на программную документацию — комплекс стандартов 19-й серии ГОСТ ЕСПД.

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

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

Проходит ли график функции через точку

Исходный текст программы:

#include <iostream>
using namespace std;

int main()
{
	int x, y;
	cout << "X Y: ";
	cin >> x >> y;
	if (y == 5 * x * x - 7 * x + 2)
		cout << "Grafik funkcii prohodit cherez tochku" << endl;
	else
		cout << "Grafik funkcii NE prohodit cherez tochku" << endl;
	cin.get();
	
	return 0;
}

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

Общие принципы были сформулированы знаменитым математиком Джоном Фон Нейманом: (1) Принцип программного управления, (2) принцип хранимой в памяти программы       

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

  1. Арифметико-логическое устройство (АЛУ) – это выполнение арифметических и логических операций.
  2. Устройство управления (УУ) – организует процесс выполнения программ.
  3. Запоминающее устройство (ЗУ) – память для хранения программ и данных (Оперативная память).
  4. Внешнее устройство (ВУ) – ввод и вывод данных.
Схема работы любого компьютера

Стрелки – это потоки, куда следует информация

Работа компьютера производится следующим образом:

  1. С помощью устройств ввода (УВ) в оперативную память (ОП) вводятся программы и исходные данные.
  2. По сигналу устройства управления (УУ) выбирается очередная команда программы, в которой указано какую операцию нужно выполнить и где взять исходные данные для её управления.
  3. Выбранная команда поступает в устройство управления (УУ), которая её расшифровывает и выдаёт приказ в арифметико-логическое устройство (АЛУ) выполнить операцию.
  4. Результат выполненной операции поступает в оперативную память (ОП), из которой по сигналу устройства управления (УУ) выбирается следующая команда программы.
  5. Цикл обработки программ повторяется до тех пор, пока не будет выполнена последняя команда программы.

Таким образом, работа ПК состоит выполнение процессором заданной последовательности команд программы. Именно программа определяет, какие команды и операции должен выполнить компьютер. В этом состоит программный принцип работы компьютера.