Песочница

Веб интерфейс для АБС

Для передатчика платежной системы Банка России (собственного приложения) создаю веб сайт.

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

Возможно скоро проект превратится в полноценную АБС

Ссылка на разработку https://businessarchitecture.ru/test-spfs

Клиент-серверное приложение, язык разработки C#, база данных MS SQL

Скачать программу можно по ссылке https://sourceforge.net/projects/peredatchikpsbr/

Тестовая база данных http://developcbs.ru/downloads/ps_bankrussia_test.bak

Скачать дистрибутив http://developcbs.ru/downloads/Setup.msi
E-mail для связи: andrey@businessarchitecture.ru,

Телефон: +7 (930) 946-81-61 (Андрей)

03.08.2020 от Песочница 0

Архивирование лог файлов Сбербанка Бизнес Онлайн-УПШ (СББОЛ-УПШ)

Архивирование лог файлов унифицированного платёжного шлюза https://www.sberbank.ru/ru/legal/bankingservice/upg

@echo off
setlocal enabledelayedexpansion
set now=%DATE: =0% %TIME: =0%

set d=%date:~0,2%
set m=%date:~3,2%
set y=%date:~6,4%

if %d:~0,1%==0 set d=%d:~1%
if %m:~0,1%==0 set m=%m:~1%

set /a feb=y%%4
if %feb%==0 (set feb=29) else (set feb=28)

set /a tok=m-1
if %tok%==0 set tok=12
for /f «tokens=%tok%» %%i in («31 %feb% 31 30 31 30 31 31 30 31 30 31») do (
set /a d-=1
if !d!==0 (
set d=%%i
set m=%tok%
if !m!==12 set /a y-=1
)
)

set d=0%d%
set m=0%m%
set yesterday=%y%_%m:~-2%_%d:~-2%

echo %yesterday%

for /f «tokens=1-7 delims=/-:., » %%a in ( «%now%» ) do (
set now=%%c%%b%%a
)

rem log_ConnectUPSH

«C:\Program Files\7-Zip\7z.exe» a -ssw -mx9 -r0 C:\ARCHIVE\log_ConnectUPSH\connectUPSH_%yesterday% C:\SBBOL_20180216\log_ConnectUPSH\connectUPSH_%yesterday%.txt
del C:\SBBOL_20180216\log_ConnectUPSH\connectUPSH_%yesterday%.txt
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_ConnectUPSH\connectUPSH_%yesterday%.%%i.txt («C:\Program Files\7-Zip\7z.exe» a -ssw -mx7 -r0 C:\ARCHIVE\log_ConnectUPSH\connectUPSH_%yesterday%.%%i C:\SBBOL_20180216\log_ConnectUPSH\connectUPSH_%yesterday%.%%i.txt)
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_ConnectUPSH\connectUPSH_%yesterday%.%%i.txt (del C:\SBBOL_20180216\log_ConnectUPSH\connectUPSH_%yesterday%.%%i.txt)

rem log_DataToReturn

«C:\Program Files\7-Zip\7z.exe» a -ssw -mx9 -r0 C:\ARCHIVE\log_DataToReturn\dataToReturn_%yesterday% C:\SBBOL_20180216\log_DataToReturn\dataToReturn_%yesterday%.txt
del C:\SBBOL_20180216\log_DataToReturn\dataToReturn_%yesterday%.txt
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_DataToReturn\dataToReturn_%yesterday%.%%i.txt («C:\Program Files\7-Zip\7z.exe» a -ssw -mx7 -r0 C:\ARCHIVE\log_dataToReturn\log_DataToReturn_%yesterday%.%%i C:\SBBOL_20180216\log_DataToReturn\dataToReturn_%yesterday%.%%i.txt)
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_DataToReturn\dataToReturn_%yesterday%.%%i.txt (del C:\SBBOL_20180216\log_DataToReturn\dataToReturn_%yesterday%.%%i.txt)

rem log_Exceptions

«C:\Program Files\7-Zip\7z.exe» a -ssw -mx9 -r0 C:\ARCHIVE\log_Exceptions\error_%yesterday% C:\SBBOL_20180216\log_Exceptions\error_%yesterday%.txt
del C:\SBBOL_20180216\log_Exceptions\error_%yesterday%.txt
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_Exceptions\error_%yesterday%.%%i.txt («C:\Program Files\7-Zip\7z.exe» a -ssw -mx7 -r0 C:\ARCHIVE\log_Exceptions\error_%yesterday%.%%i C:\SBBOL_20180216\log_Exceptions\error_%yesterday%.%%i.txt)
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_Exceptions\error_%yesterday%.%%i.txt (del C:\SBBOL_20180216\log_Exceptions\error_%yesterday%.%%i.txt)

rem log_IncomingData

«C:\Program Files\7-Zip\7z.exe» a -ssw -mx9 -r0 C:\ARCHIVE\log_IncomingData\incommingData_%yesterday% C:\SBBOL_20180216\log_IncomingData\incommingData_%yesterday%.txt
del C:\SBBOL_20180216\log_IncomingData\incommingData_%yesterday%.txt
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_IncomingData\incommingData_%yesterday%.%%i.txt («C:\Program Files\7-Zip\7z.exe» a -ssw -mx7 -r0 C:\ARCHIVE\log_IncomingData\incommingData_%yesterday%.%%i C:\SBBOL_20180216\log_IncomingData\incommingData_%yesterday%.%%i.txt)
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_IncomingData\incommingData_%yesterday%.%%i.txt (del C:\SBBOL_20180216\log_IncomingData\incommingData_%yesterday%.%%i.txt)

rem log_SendedToSbbol

«C:\Program Files\7-Zip\7z.exe» a -ssw -mx9 -r0 C:\ARCHIVE\log_SendedToSbbol\SendedToSbbol_%yesterday% C:\SBBOL_20180216\log_SendedToSbbol\SendedToSbbol_%yesterday%.txt
del C:\SBBOL_20180216\log_SendedToSbbol\SendedToSbbol_%yesterday%.txt
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_SendedToSbbol\SendedToSbbol_%yesterday%.%%i.txt («C:\Program Files\7-Zip\7z.exe» a -ssw -mx7 -r0 C:\ARCHIVE\log_SendedToSbbol\SendedToSbbol_%yesterday%.%%i C:\SBBOL_20180216\log_SendedToSbbol\SendedToSbbol_%yesterday%.%%i.txt)
for /L %%i in (0,1,100) do if exist C:\SBBOL_20180216\log_SendedToSbbol\SendedToSbbol_%yesterday%.%%i.txt (del C:\SBBOL_20180216\log_SendedToSbbol\SendedToSbbol_%yesterday%.%%i.txt)

22.07.2020 от Песочница 0

Небольшой модуль авторизации на .Net Framework

Пароль сохраняется в base64, база данных MSSQL

namespace authWF
{
public partial class Form1 : Form
{
public static string BD{ get; set; }
public static string login { get; set; }

public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
login = textBox1.Text;
BD = «Users»;
string password = textBox2.Text;
if (CheckPswd() == password)
{
Form2 form2 = new Form2();
form2.Show();
}

else
{
label3.Visible = true;
}

}

private string CheckPswd()
{
SqlConnection conn = DBUtils.GetDBConnection();
conn.Open();

SqlCommand sqlCmd = new SqlCommand();
sqlCmd.Connection = conn;
sqlCmd.CommandType = CommandType.Text;
sqlCmd.CommandText = $»Select Password FROM {BD} WHERE Login='{login}'»;
string passfrombase = Base64Decode(Convert.ToString(sqlCmd.ExecuteScalar()));
conn.Close();
return passfrombase;

}

public static string Base64Decode(string base64EncodedData)
{
var base64EncodedBytes = System.Convert.FromBase64String(base64EncodedData);
return System.Text.Encoding.UTF8.GetString(base64EncodedBytes);
}

private void Form1_Load(object sender, EventArgs e)
{

}

private void label3_Click(object sender, EventArgs e)
{

}

private void label1_Click(object sender, EventArgs e)
{

}
}
}

Редактирование информации- профиля

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Data.SqlClient;

namespace authWF
{
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{

Users.Name = textBox1.Text;
Users.Surname = textBox2.Text;
Users.Patronymic = textBox3.Text;
Users.Date = textBox11.Text;
Users.Position = textBox4.Text;
Users.Mail = textBox5.Text;
Users.Login = textBox8.Text;
Users.Views = textBox7.Text;
Users.Accesses = textBox6.Text;

if (textBox9.Text != textBox10.Text)
{
textBox9.BackColor = Color.Red;
textBox10.BackColor = Color.Red;
label9.Visible = true;
label13.Visible = true;
label9.Text = «Пароли не равны или не введены»;
label13.Text = «Пароли не равны или не введены»;
}
else
{
label9.Visible = false;
label13.Visible = false;
textBox9.BackColor = Color.White;
textBox10.BackColor = Color.White;
Users.Password = Base64Encode(textBox9.Text);
Users.PasswordRepeat = Base64Encode(textBox10.Text);
// string login = Form1.login;
string BD = Form1.BD;

WriteToBD(BD,Users.Name, Users.Surname, Users.Patronymic, Users.Date, Users.Position, Users.Mail, Users.Login, Users.Views, Users.Accesses, Users.Password);
}
}

private void WriteToBD(string BD, string name, string surname, string patronymic, string date, string position, string mail, string login, string views, string accesses, string password)
{
try
{
SqlConnection conn = DBUtils.GetDBConnection();
conn.Open();

SqlCommand sqlCmd = new SqlCommand();
sqlCmd.Connection = conn;
sqlCmd.CommandType = CommandType.Text;
sqlCmd.CommandText = $»INSERT INTO {BD}(Name,Surname,Patronymic,Date,Login,Password,Mail,Accesses,Views,Position) VALUES (‘{name}’,'{surname}’,'{patronymic}’,'{date}’,'{login}’,'{password}’,'{mail}’,'{accesses}’,'{views}’,'{position}’)»;
sqlCmd.ExecuteNonQuery();
conn.Close();
}
catch { }
finally
{
textBox1.Enabled=false;
textBox2.Enabled = false;
textBox3.Enabled = false;
textBox11.Enabled = false;
textBox4.Enabled = false;
textBox5.Enabled = false;
textBox6.Enabled = false;
textBox7.Enabled = false;
textBox8.Enabled = false;
textBox9.Enabled = false;
textBox10.Enabled = false;

}
}

public static string Base64Encode(string password)
{
var passwordinbase64 = System.Text.Encoding.UTF8.GetBytes(password);
return System.Convert.ToBase64String(passwordinbase64);
}

public void Form2_Load(object sender, EventArgs e)
{

}

private void редактированиеПрофиляToolStripMenuItem_Click(object sender, EventArgs e)
{

}

private void открытыеСчетаКомпанииToolStripMenuItem_Click(object sender, EventArgs e)
{

}

public void редактированиеПрофиляToolStripMenuItem_Click_1(object sender, EventArgs e)
{
SqlConnection conn = DBUtils.GetDBConnection();
conn.Open();

SqlCommand sqlCmd = new SqlCommand();
sqlCmd.Connection = conn;
sqlCmd.CommandType = CommandType.Text;
sqlCmd.CommandText = $»Select * FROM {Form1.BD} WHERE Login='{Form1.login}'»;
var reader = sqlCmd.ExecuteReader();
while (reader.Read())
{
textBox1.Text = reader.GetValue(1).ToString();
textBox2.Text = reader.GetValue(2).ToString();
textBox3.Text = reader.GetValue(3).ToString();
textBox11.Text = reader.GetValue(4).ToString();

textBox4.Text = reader.GetValue(10).ToString();

textBox5.Text = reader.GetValue(7).ToString();
textBox8.Text = reader.GetValue(5).ToString();

textBox6.Text = reader.GetValue(8).ToString();
textBox7.Text = reader.GetValue(9).ToString();

textBox9.Text = reader.GetValue(6).ToString();

}
conn.Close();
}

private void menuStrip1_ItemClicked(object sender, ToolStripItemClickedEventArgs e)
{

}
}
}

21.07.2020 от Песочница 0

Стандартная задача: картотека библиотеки

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

Код программы находится в файлах: Program.cs — весь код, Class1.cs — класс book

Файл для запуска \bin\Debug\netcoreapp3.1\MEPHI_TEST.exe

Код программы https://github.com/aovakur/Mephi_test

Выгрузка данных в файл

05.06.2020 от Песочница 0

Передатчик платежной системы Банка России. Тестирование СПФС

Для небольшой автоматизации тестирования СПФС создал приложение «Передатчик ПС БР»

В версии 1.0.0 создан следующий функционал:
создание платежного поручения в формате УФЭБС ED101 для тестового контура АРМ КБР;
создание платежного поручения в формате УФЭБС ED501 для тестового контура АРМ КБР СПФС;
хранение созданных платежных поручений;
выгрузка платежных поручений в pdf формате;
обработка принятых входящих сообщений;

Клиент-серверное приложение, язык разработки C#, база данных MS SQL,

Скачать программу можно по ссылке https://sourceforge.net/projects/peredatchikpsbr/

Тестовая база данных http://developcbs.ru/downloads/ps_bankrussia_test.bak

Скачать http://developcbs.ru/downloads/Setup.msi

Почта автора: andrey@businessarchitecture.ru

Форма создания платежного поручения в программе выглядит согласно форме 0401060 (Приложение 2 Положения Банка России от 19 июня 2012 года № 383-П «О правилах осуществления перевода денежных средств» (в редакции Указаний Банка России от 15.07.2013 № 3025-У, от 29.04.2014 № 3248-У, от 19.05.2015 № 3641-У, от 06.11.2015 N 3844-У, от 05.07.2017 N 4449-У и от 11.10.2018 N 4930-У)

Форма для отображения сообщений за текущий день/ все дни

Пункты меню для сохранения платежного поручения

Настройка сохранения платежного поручения

Соединение с базой данных

Сформированное ed101

Сформированное Ed501

Сформированные сообщения (ED101,ED501) входят в УФЭБС (унифицированные форматы электронных банковских сообщений), который основан на ISO 20022.

Видео

Система передачи финансовых сообщений Банка России (СПФС) — это альтернативный канал передачи электронных сообщений по финансовым операциям. СПФС гарантирует бесперебойность передачи финансовых сообщений внутри страны.

Подключение кредитных организаций и их клиентов — юридических лиц к СПФС происходит по мере их технической готовности и установления договорных отношений с Банком России. Процедурные аспекты определены отдельным нормативным актом Банка России.  Источник https://cbr.ru/PSystem/fin_msg_transfer_system/

Отправка сформированных сообщений происходит через тестовый/боевой канал ТШ КБР с помощью шлюзовой программы АРМ КБР -Н/ АРМ КБР / АРМ КБР СПФС (где на сообщение накладывается транспортная подпись)

Ссылка на разработку https://businessarchitecture.ru/test-spfs

Клиент-серверное приложение, язык разработки C#, база данных MS SQL

Скачать программу можно по ссылке https://sourceforge.net/projects/peredatchikpsbr/

Тестовая база данных http://developcbs.ru/downloads/ps_bankrussia_test.bak

Скачать дистрибутив http://developcbs.ru/downloads/Setup.msi
E-mail для связи: andrey@businessarchitecture.ru,

Телефон: +7 (930) 946-81-61 (Андрей)

30.03.2020 от Песочница 1

Управление очередями. Начало работы с Apache Kafka

Apache Kafka очень производительный инструмент, который нужен для перенаправления потоков данных из одного места в другое, с обработкой и без. Проект достаточно зрелый, и среди тех, кто его активно использует, много гигантов IT индустрии: LinkedIn, Netflix, Yahoo, Twitter, Pinterest, и другие. Проект стал невероятно популярным во многом благодаря своим неоспоримым преимуществам: легкость настройки, масштабируемость, высокая пропускная способность и надежность.

В отличие от обычных брокеров, которые удаляют сообщения сразу же после успешной доставки, Kafka хранит их столько, сколько скажут. По умолчанию — неделю. Это удобно, потому что, подписываясь на топик в Kafka можно получить и те сообщения, которые публиковались позавчера. Цифры попадаются разные, но Kafka превосходит по производительности многие популярные брокеры вроде ActiveMQ и RabbitMQ. По некоторым источникам зафиксированная пропускная способность Кафки: 100K сообщений в секунду, а у RabbitMQ всего 20К.

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

Apache Zookeeper обеспечивает координацию брокеров в кластере.  Топики с сообщениями можно разбить на разделы (partition) и распределить внутри кластера, а затем еще включить и репликацию. На выходе вырастет пропускная способность, ведь один топик теперь хранится и обслуживается несколькими брокерами, и даже если один из брокеров умрёт, где-то останется реплика его данных, и всё обойдётся без потерь. Хотя некоторые очереди сообщений тоже умеют делать репликацию, я не могу вспомнить ни одной, которая умеет дробить свои очереди на части и распределять по кластеру. Partitions  — единица. То есть наш топик будет храниться в одном монолитном хранилище. Если вдруг топик будет большим — больше, чем позволяет файловая система, и/или хост, который его держит, может и справиться со всеми входящими запросами, то его можно разбить на несколько разделов, которые, скорее всего, окажутся на разных хостах. Если еще включить репликацию, то получится удивительной надежности кластер.

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

  • «Leader» — это узел, ответственный за все чтения и записи для данного раздела. Каждый узел будет лидером для случайно выбранной части разделов.
  • «Replicas» — это список узлов, которые реплицируют журнал для этого раздела независимо от того, являются ли они лидером или даже если они в настоящее время живы

Загрузим дистрибутив kafka с сайта kafka.apache.com.

Распакуем архив в директорию Desktop .

Произведем установку Java 1.8.

Запустим zookeeper-server следующей командой.

bin/zookeeper-server-start.sh config/zookeeper.properties

Запустим kafka-server следующей командой:

bin/kafka-server-start.sh config/server.properties

Запустим топик следующей командой :

kafka-topics —zookeeper localhost:2181 —create —topic MyTopic —partitions 1 —replication-factor 1

Проверим работоспособность топика следующей командой: bin/kafka-topics.sh —zookeeper localhost:2181 —listtest-topic

bin/kafka-console-consumer —bootstrap-server localhost:9092 —topic MyTopic

Запуск потребителя Запустим производителя: bin/kafka-console-producer.sh —broker-list localhost:9092 —topic MyTopic

Запустим кластер с несколькими брокерами. Чтобы избежать столкновения, мы создаем файл server properties для каждого брокера и изменяем свойства конфигурации id  port и logfile (рисунок 10).

Создадим два файла командой:

cp config/server.properties config/server-1.propertiescp config/server.properties config/server-2.properties

Добавим значение:

broker.id=1listeners=PLAINTEXT://:9093log.dirs=/usr/local/var/lib/kafka-logs-1broker.id=2listeners=PLAINTEXT://:9094log.dirs=/usr/local/var/lib/kafka-logs-2

Запустим брокер

bin/kafka-server-start.sh config/server.properties &    bin/kafka-server-start.sh config/server-1.properties &    bin/kafka-server-start.sh config/server-2.properties

Создадим реплицированную тему

bin/kafka-topics.sh —zookeeper localhost:2181 —create —replication-factor 3 —partitions 1 —topic replicated-topicbin/kafka-topics.sh —zookeeper localhost:2181 —describe —topic replicated-topicTopic:replicated-topic  PartitionCount:1    ReplicationFactor:3 Configs:Topic: replicated-topic Partition: 0    Leader: 1   Replicas: 1,2,0 Isr: 1,2,0

Самостоятельно попробуем отправить сообщения с помощью клавиш

20.12.2018 от Песочница 0

Использование Apache Hive для создания Data WareHouse из текстовых файлов

Подготовим среду Hive для использования запросов и управления большими данными, находящихся в распределённых хранилищах.

 

Для создания таблицы в HDFS необходимо в командной строке прописать следующий код hadoop fs -mkdir /user/hive/warehouse/<имя директории>/.

Нам необходимо создать три файла и переместить их в файловое хранилище HDFS.

Создаем первый файл price

hadoop fs -mkdir /user/hive/warehouse/price/

hadoop fs -copyFromLocal /home/cloudera/Desktop/price

 

Создаем второй файл room

hadoop fs -mkdir /user/hive/warehouse/room/

hadoop fs -copyFromLocal /home/cloudera/Desktop/room

 

Создаем третий файл phone_number

hadoop fs -mkdir /user/hive/warehouse/phone_number /

hadoop fs -copyFromLocal /home/cloudera/Desktop/phone_number

 

Проверим работоспособность с помощью HUE и посмотрим файлы в папках.

 

Создадим таблицу price

DROP TABLE IF EXISTS price;

CREATE EXTERNAL TABLE PRICE (

area tinyint,

class tinyint,

price smallint

)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘|’

LOCATION ‘/user/cloudera/price/’;

 

Создадим таблицу room

DROP TABLE IF EXISTS room;

CREATE EXTERNAL TABLE ROOM (

level tinyint,

area tinyint,

class tinyint,

quantity smallint,

quantity_taken_room smallint

)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘|’

LOCATION ‘/user/cloudera/room/’;

 

Создадим таблицу phone_number

drop TABLE IF EXISTS PHONE_NUMBER;

CREATE EXTERNAL TABLE PHONE_NUMBER (

level tinyint,

phone_number int,

admin_name string

)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘|’

LOCATION ‘/user/cloudera/phone_number/’;

 

 

Сформируем простые запросы к базе данных

 

Запрос для вывода двухместных номеров

SELECT *

FROM price

WHERE area=2;

Запрос для вывода телефона, фамилии администратора первого этажа

SELECT phone_number, admin_name

FROM phone_number

WHERE level=1;

Запрос для вывода количества одноместных номеров первого класса по этажам.

SELECT level, quantity

FROM room

WHERE area = 1 and class = 1;

 

Запрос для вывода фамилий администраторов и номера телефонов этажей, на которых есть незанятые одноместные номера.

SELECT DISTINCT phone_number.admin_name, phone_number.phone_number

FROM phone_number INNER JOIN room ON phone_number.level = room.level

WHERE room.area = 1 And room.quantity > room.quantity_taken_room;

 

Запрос для вывода фамилий администраторов и номеров телефонов этажей, на которых есть больше девяти свободных двуместных номеров.

SELECT DISTINCT phone_number.admin_name, phone_number.phone_number

FROM phone_number INNER JOIN room ON phone_number.level = room.level

WHERE room.area = 2 And (room.quantity — room.quantity_taken_room) > 9;

SELECT area, class, Sum(quantity-quantity_taken_room) AS free_room

FROM room

GROUP BY area, class;

SELECT level, class, SUM(quantity) AS some_class_room

FROM room

WHERE class=1

GROUP BY level, class;

Запрос для вывода телефонов этажей, на которых расположены двуместные номера второго класса.

SELECT DISTINCT phone_number.level, phone_number.phone_number

FROM phone_number INNER JOIN room ON phone_number.level = room.level

WHERE area=2 AND class=2

Запрос для вывода телефонов этажей, на которых расположены трехместные номера второго класса или третьего класса.

SELECT DISTINCT phone_number.level, phone_number.phone_number

FROM phone_number INNER JOIN room ON phone_number.level = room.level

WHERE area=3 AND (class=2 OR class=3);

05.12.2018 от Песочница 0

Моделирование бизнес-процессов в business studio

В программе Business studio можно создать модель бизнес процессов в нотации IDF0, декомпозировать бизнес-процессы на более низкий уровень и описать в нотации IDF0, EEPC, BPMN.

IDEF0 — нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

  • использование контекстной диаграммы;
  • поддержка декомпозиции;
  • доминирование;
  • выделение 4 типов стрелок.

Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу. Пример диаграммы A-0 приведен ниже.

Модель бизнес-процессов компании в нотации IDF0 представлена ниже

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

На каждый созданный процесс можно сформировать отчет по описанию процесса и его входам и выходам.

№ Процесс Владелец Исполнители Входы Выходы
Тип Название Объекты Название Объекты
1. А1 Создание компании Вход Пакет документов Пакет документов Договор об аренде помещения Договор об аренде помещения
Список необходимого оборудования Список необходимого оборудования Документы организации Документы организации
Управление Договор об аренде помещения Договор об аренде помещения
Документы для учреждения фирмы Документы для учреждения фирмы
Шаблон устава Шаблон устава
Механизм Администратор_1
Администратор_2
Главный инженер
Директор
Снабженец
Юрист
2. А2 Привлечение клиентов Вход Документы организации Документы организации База данных клиентов База данных клиентов
Управление Шаблон договора Шаблон договора Технические документы Технические документы
Механизм Менеджер 2 Требования Требования
3. А3 Оформление выставки Вход Технические документы Технические документы Партнерский договор Партнерский договор
Требования Требования Список партнеров Список партнеров
Управление База данных клиентов База данных клиентов
Договор с клиентом Договор с клиентом
Свидетельство о регистрации Свидетельство о регистрации
Шаблон Партнерского договора Партнерский договор
Механизм
Администратор_1
Дизайнер
Маркетолог 2
4. А4 Реализация Вход Шаблон договора с контрагентом Шаблон договора с контрагентом Договор с контрагентом Договор с контрагентом
Управление Список партнеров Список партнеров Официальное открытие выставки
Механизм Главный инженер
5. А5 Завершение проекта Вход Официальное открытие выставки Закрытые документы Закрытые документы
Управление Договор с контрагентом Договор с контрагентом Отчет о рекламной компании Отчет о рекламной компании

Входы и выходы процесса

№ Тип Название Объекты
1. Вход Пакет документов Пакет документов
Список необходимого оборудования Список необходимого оборудования
2. Выход Договор об аренде помещения Договор об аренде помещения
Документы организации Документы организации
3. Управление Договор об аренде помещения Договор об аренде помещения
Документы для учреждения фирмы Документы для учреждения фирмы
Шаблон устава Шаблон устава
4. Механизм Администратор_1
Администратор_2
Главный инженер
Директор
Снабженец
Юрист

Описание подпроцессов

№ Процесс Владелец Исполнители Входы Выходы
Тип Название Объекты Название Объекты
1. А1.1 Регистрация фирмы Механизм Директор Свидетельство о регистрации Свидетельство о регистрации
2. А1.2 Закупка инвентаря Вход Список необходимого оборудования Список необходимого оборудования Закупленное оборудование Список необходимого оборудования
Управление Свидетельство о регистрации Свидетельство о регистрации Счета фактуры на оборудование Счета фактуры на оборудование
Механизм Администратор_1
3. А1.3 Поиск помещения Вход Закупленное оборудование Список необходимого оборудования Договор об аренде помещения Договор об аренде помещения
Управление Договор об аренде помещения Договор об аренде помещения
Счета фактуры на оборудование Счета фактуры на оборудование
Механизм Администратор_2

Пример моделей EPC в рамках организации

При моделировании процессов можно использовать операторы условия:»исключающие или», «или», «не».

Организационная структура, выполненная в нотации Business studio

После выполнения моделирования бизнес-процессов можно произвести имитацию бизнес-процесса «as is» с помощью функционально-стоимостного анализа и имитационного моделирования средствами bussiness studio 4.1.

Этапы выполнения имитации:

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

Отчет по результатам имитации «as is»

Временные ресурсы

№ Название Смена Ставка в час Среднее время использования Средняя стоимость использования, руб.
1. Маркетолог 1 Смена 1 200 руб.
2. Маркетолог 2
  Сумма 11333,33

Материальные ресурсы

№ Название Стоимость Среднее потребляемое
количество		 Средняя стоимость потребления,
руб.
1. Word 0 1
2. Акт-передачи 0 1
3. Заключенный договор на размещение 0 1
4. Компьютер 0 1
5. Список необходимого оборудования 0 1
6. Список необходимых мероприятий 0 1
7. Шаблон договора на размещение 0 1
  Сумма 0

Произведенные продукты

№ Название Среднее производимое количество
1. Акт-передачи 1
2. Доставка осуществлена 1
3. Заключенный договор на размещение 1
4. Регистрация на товарный знак 1
5. Список материалов для украшения 1
6. Список необходимого оборудования 1
7. Список необходимых мероприятий 1
8. Счета 1

Средние значения времени и стоимости подпроцессов

№ Процесс Время выполнения Время ожидания Время в очереди Время в ожидании материальных ресурсов Полное время Стоимость,
руб.
1. А6.1 Подготовка рекламной продукции 1д. 00:00:00 2:00:00 9д. 06:42:51 0:00:00 10д. 08:42:51 4800
2. А6.2 Заключение договора на размещение 1д. 00:00:00 2:00:00 7д. 14:30:00 0:00:00 8д. 16:30:00 4800
3. А6.3 Регистрация товарного занака 1:00:00 3д. 00:00:00 17:15:00 0:00:00 3д. 18:15:00 200
4. А6.4 Размещение рекламной продукции 2:00:00 3:00:00 4:00:00 0:00:00 9:00:00 400
5. А6.5 Подготовка списка необходимого оборудования 1:00:00 1д. 00:00:00 0:15:00 0:00:00 1д. 01:15:00 200
6. А6.6 Осуществление доставки оборудования 0:10:00 4:00:00 8:47:30 0:00:00 12:57:30 3000
7. А6.7 Осуществление монтажа оборудования 1:00:00 0:30:00 0:12:30 0:00:00 1:42:30 3500
8. А6.8 Подготовительные работы по отделке помещения 0:40:00 0:10:00 3:45:00 0:00:00 4:35:00 133,33
9. А6.9 Подготовка необходимого материалы для укращения 1:00:00 0:30:00 0:15:00 0:00:00 1:45:00 200
10. А6.10 Провести закупку метериалов 3:00:00 2:00:00 4:00:00 0:00:00 9:00:00 600
11. А6.11 Украсить помещение 1:00:00 0:30:00 11:00:00 0:00:00 12:30:00 200

Средние затраты времени и стоимости экземпляров подпроцессов на выполнение экземпляра процесса

№ Процесс Частота в рамках вышележ. Время выполнения Время ожидания Время в очереди Время в ожидании материальных ресурсов Полное время Стоимость,
руб.
1. А6.1 Подготовка рекламной продукции 1 1д. 00:00:00 2:00:00 9д. 06:42:51 0:00:00 10д. 08:42:51 4800
2. А6.2 Заключение договора на размещение 1 1д. 00:00:00 2:00:00 7д. 14:30:00 0:00:00 8д. 16:30:00 4800
3. А6.3 Регистрация товарного занака 1 1:00:00 3д. 00:00:00 17:15:00 0:00:00 3д. 18:15:00 200
4. А6.4 Размещение рекламной продукции 1 2:00:00 3:00:00 4:00:00 0:00:00 9:00:00 400
5. А6.5 Подготовка списка необходимого оборудования 1 1:00:00 1д. 00:00:00 0:15:00 0:00:00 1д. 01:15:00 200
6. А6.6 Осуществление доставки оборудования 1 0:10:00 4:00:00 8:47:30 0:00:00 12:57:30 3000
7. А6.7 Осуществление монтажа оборудования 1 1:00:00 0:30:00 0:12:30 0:00:00 1:42:30 3500
8. А6.8 Подготовительные работы по отделке помещения 1 0:40:00 0:10:00 3:45:00 0:00:00 4:35:00 133,33
9. А6.9 Подготовка необходимого материалы для укращения 1 1:00:00 0:30:00 0:15:00 0:00:00 1:45:00 200
10. А6.10 Провести закупку метериалов 1 3:00:00 2:00:00 4:00:00 0:00:00 9:00:00 600
11. А6.11 Украсить помещение 1 1:00:00 0:30:00 11:00:00 0:00:00 12:30:00 200
Сумма

Экземпляры процесса

Количество запущенных экземпляров 22
Количество завершенных экземпляров 4
Количество незавершенных экземпляров 18
Среднее количество запусков в день 0,724
Среднее количество завершенных экземпляров в день 0,132

Результат: количество экземпляров равно 22, завершенных равно 4, незавершенных равно 18, среднее количество запусков в день равно 0,724, среднее завершенных экземпляров в день равно 0, 132.

Матрица ответственности

№№ Наименование процесса/процедуры Менеджер 1 Менеджер 2 Владелец БП Зам. директора
БП1 Бизнес-процесс «Реализация» О О В И
Пр1.1 Подготовка рекламной продукции У У И К
Пр1.2 Подготовительные работы по отделке помещения У У И К
Пр1.3 Заключение договора на размещение У У И К
Пр1.4 Регистрация товарного знака У У И К
Пр1.5 Подготовка необходимых материалов для украшения У У И К
Пр1.6 Размещение рекламной продукции У У И К
Пр1.7 Провести закупку материалов У У И К
Пр1.8 Украсить помещение У У И К
Пр1.9 Подготовить список необходимого оборудования У У И К
Пр1.10 Осуществление доставки оборудования У У И К
Пр1.11 Осуществление монтажа оборудования У У И К

Сводная ведомость отчетной информации

Наименование отчета Менеджер 1 Менеджер 2 Владелец БП
Акт передачи ежемесячно
Отчет о доставке ежемесячно еженедельно

 

Взаимодействие с другими процессами

Реализация
Получает информацию Передает информацию
Бизнес – процесс

«Оформление выставки»

 Заключенный партнерский договор Заключенный договор на размещение

Регистрация товарного знака

Акт передачи

Отчет о доставке
Бизнес-процесс

«Завершение проекта»

 Акт передачи и тд Подписанные акты

В процессе to be «Привлечение клиентов» клиентов стало равно 12, что на 4 больше чем в «as is». Количество привлеченных клиентов увеличилось на 4 (по сравнению с показателем до оптимизации бизнес-процесса). Количество сделанных сайтов увеличилось на 4, количество заработанных денег увеличилось на 160 тысяч рублей. В среднем привлеченный клиент оплачивает услуги на 40 тысяч рублей, до оптимизации у нас было 8 клиентов, которые оплатили услуги на 320 тысяч рублей, сейчас этот показатель ровняется 480 тысяч рублей.

01.07.2018 от BPM Песочница 0

Технические задание на разработку портала безопасности
  1. Термины и определения. 3
  2. Общие сведения. 3

2.1        Назначение документа. 3

2.2        Назначение и цели создания (развития) системы.. 5

  1. Характеристика объектов автоматизации.. 6

3.1 Проверка знаний пользователей по основам информационной и ядерной безопасности.. 6

3.2        Публикация дополнительной информации.. 6

4       Требования к порталу. 6

4.1 Нормативная база. 6

4.2 Функциональные требования. 12

4.2.1 Классы пользователей.. 13

4.2.2 Требования к функциональному блоку «Пользователи». 14

4.2.3 Требования к функциональному блоку «Новостей и мероприятий». 14

4.2.4 Требования к функциональному блоку «Курсы безопасности». 15

5       Состав и содержание работ по созданию портала. 16

5.2 Разработка серверной части. 17

5.3 Требования к программному обеспечению.. 18

5.4 Требования к техническому обеспечению.. 18

5.4 Требования к лингвистическому обеспечению.. 19

5.5 Требования к эргономике и технической эстетике. 19

6       Порядок контроля и приемки системы.. 19

6.1. Порядок контроля работ. 19

6.2        Требования к наполнению информацией. 21

6.1.1 Общие требования к информационному наполнению.. 21

6.3        Требования к персоналу. 22

6.3 Требование к хранению информации (данных) 22

6.4        Порядок предоставления дистрибутива. 23

7       Требования к составу и содержанию работ по подготовке. 24

7.1 Наполнение портала. 24

8       Объект автоматизации к вводу системы в действие. 24

9       Требования к документированию.. 24

10     Источники разработки. 24

1.                 Термины и определения

СКЗИ – Средство криптографической защиты информации;

ФСТЭК – Федеральная служба по техническому и экспортному контролю;

ФСБ – Федеральная служба безопасности;

Портал – «Портал корпоративной безопасности»;

ОС – Операционная система;

ИС – Информационная система;

БД – База данных ИС;

2.                 Общие сведения

2.1            Назначение документа

В настоящем документе приводится полный набор требований к разрабатываемому порталу.

Согласно направлению «Информационная безопасность» в программе «Цифровая экономика Российской Федерации 2024» от 28 июля 2017 года необходимо:

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

Портал должен включать в себя следующие объекты (рисунок 1).

Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

  • Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
  • Заказчик согласен со всеми положениями настоящего Технического Задания.
  • Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
  • Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
  • Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
  • Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами.
  • В процессе согласования могут быть разработаны дополнительные требования.

2.2            Назначение и цели создания (развития) системы

В рамках разработки портала будет реализован следующий функционал:

  • Консолидация общедоступных материалов по безопасности (информационной и тд);
  • Мониторинг прохождения сотрудниками компании определенных тестов по безопасности, прочтение определённой новостной информации;
  • Описаны шаги настройки/получения дистрибутивов для шифрования;
  • Продемонстрированы различные металлические пособия по работе в программах для шифрования, дешифрования файлов, по работе с персональными данными и тд.
  • Продемонстрированы методические пособия и нормативные акты стран, в которых присутствует представительство;
  • Автоматизирована проверка пользователей по разделам информационной безопасности (фишинговые письма, документы с потенциальными вирусами и тд).

3.                 Характеристика объектов автоматизации

3.1 Проверка знаний пользователей по основам информационной и ядерной безопасности

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

3.2 Публикация дополнительной информации

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

4                   Требования к порталу

4.1 Нормативная база

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

 

4.2 Функциональные требования

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

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

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

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

Для авторизованных пользователей должен выводиться дополнительный блок с курсами по безопасности.

4.2.1 Классы пользователей

Гость – неавторизованный пользователь, обладает правам:

  • Раздел новости – просмотр
  • Регистрация на портале
  • Раздел мероприятий — просмотр

Авторизованный пользователь обладает правами:

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

Администратор обладает следующими правами:

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

HR специалист обладает следующими правами:

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

4.2.2 Требования к функциональному блоку «Пользователи»

Пользователи портала безопасности должны автоматически синхронизироваться с учетной системой – Active Directory Windows.

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

4.2.3 Требования к функциональному блоку «Новостей и мероприятий»

Функциональней блок «Новости и мероприятия» должен выводить горизонтальным списком последние новости из сферы национальной/ международной безопасности.

Количество выводимых новостей на главной стране должно быть равно 4.

При переходе на раздел «Новости» или «Мероприятия» пользователю выводится страница со всеми новостями или мероприятиями. На главной странице блока должно выводиться наименование статьи, уменьшенная копия картинки, имя автора, количество статей в строке должно быть равно 4.

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

4.2.4 Требования к функциональному блоку «Курсы безопасности»

У авторизованных пользователей портала (т.е после авторизации пользователей) на главной должно дополнительно появиться блок с открытыми для них курсами безопасности. Должно выводится наименование курса, уменьшенная картинка курса, количество человек, прошедших курс и тд. Количество выводимых курсов в ряду должно быть равно 4, по вертикали – неограниченно.

Открытые курсы безопасности для конкретного пользователя/группы пользователей определяет HR специалист.

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

  • Информация о курсе
  • Отзыв о курсе
  • Описание курса
  • Визуальная информация
  • Время прохождения курса
  • Язык курса
  • Содержание

5                   Состав и содержание работ по созданию портала

  • Разработка формы авторизации

Для повышения класса защищённости портала безопасности на основании «Руководящего документа автоматизированные системы. Защита от несанкционированного доступа к информации Классификация автоматизированных систем и требования по защите Информации», утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 30 марта 1992 г, мы осуществим разработку следующего модуля «аутентификация с помощью PAM модуля”.

Pluggable Authentication Modules (PAM, подключаемые модули аутентификации) — это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации в виде единого высокоуровневого API.

В разрабатываемом модуле должны быть предусмотрены следующие подсистемы (для обеспечения класса защищенности 3Б):

А) Подсистема управления доступом:

  • В данной подсистеме должны осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по паролю условно — постоянного действия, длиной не менее шести буквенно – цифровых символов.

 

Б) Подсистема регистрации и учета:

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

 

В) В параметрах регистрации указываются:

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

 

5.2 Разработка серверной части

В качестве разработки нашего портала будет использоваться язык программирования Python или PHP, реляционная база данных Mysql.

5.3 Разработка клиентской части

Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS. Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0). Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и DHTML.

  • Требования к организации гиперссылок. Все ссылки в портале должны быть относительными (за исключением внешних).
  • Требования к иллюстрациям. Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.
  • Требования к объему одной страницы. Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.

5.3 Требования к программному обеспечению

Серверная часть:

  • Операционная система семейства Unix (Linux, FreeBSD и пр.)
  • Веб-сервер Apache 1.3.18 и выше
  • Nginx, модуль mod_accel для Apache
  • Набор библиотек и утилит ffmpeg
  • PHP 4.2.0 и выше (должен быть собран как модуль Apache)
  • СУБД MySQL 4.1.14 и выше (предпочтительно: поддержка формата InnoDB).
  • Модули PHP: Mcrypt, FTP, ffmpeg-php
  • Библиотеки PHP: Smarty, GeoIP
  • Возможность доступа к localhost по FTP протоколу
  • 2 пользователя БД

Желательно, чтобы PHP не был запущен в SafeMode, Python версии 2.6.6

Клиентская часть:

  • Любой из перечисленный ниже браузеров (указана минимальная версия) с включенным
  • Internet Explorer 6
  • Mozilla 1.6 (Firefox 1.0)
  • Opera 9
  • Adobe Flash Player версии 9 и выше. Сайт должен быть работоспособен (информация,
  • расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и

 5.4 Требования к техническому обеспечению

Серверная часть:

  • Компьютер с процессором Xeon 4 ядерный
  • 2 ГГц (рекомендуется от 3 ГГц)
  • Оперативная память 4 Гб
  • Место на жестком диске от 1 Гб

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

Клиентская часть:

  • Компьютер с процессором i3 ГГц (рекомендуется от 1.5ГГц)
  • Оперативная память 256 Мб (рекомендуется от 512 Мб)

 

 

5.4 Требования к лингвистическому обеспечению

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

5.5 Требования к эргономике и технической эстетике

Портал должен быть адаптивный для различных браузеров (Firefox, Chrome, Edge, IE), стандартное поддерживаемое разрешение должно быть 720х1280 пикселей. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

6                   Порядок контроля и приемки системы

6.1. Порядок контроля работ

В следующей таблице будут приведены целевые даты реализации портала.

 

№ Перспектива Цель
Целевая дата
2 Стратегические вопросы Создание портала безопасности 10.05. 2019
3 Технические вопросы Разработка форм аутентификации пользователей 20.01. 2019
Разработка портала (Backend & front) 10.02. 2019
30.02. 2019
Проведение тест кейсов 15.03. 2019
Разработка диаграмм классов, User story и тд 10.01. 2019
10.01. 2019
10.01. 2019
Интеграция пользователей AD 10.03. 2019
4 Обучение и развитие Создание методических материалов 20.04.2019
Разработка тестов для сотрудников АСЕ 10.05.2019
10.05.2019
Поиск международных нормативных актов в сфере информационной и атомной безопасности 1.04.2019
Проверка знаний пользователей 28.05.2018
Создание отчетов проверка знаний 28.05.2018
28.05.2018
28.05.2018
Поиск общедоступных нормативных актов (ГОСТов, приказов ФСТЭК, ФСБ и тд) 1.04.2019
1.04.2019
1.04.2019

 

6.2            Требования к наполнению информацией

6.1.1 Общие требования к информационному наполнению

Публикуемая информация на сайте должна основываться на:

6.1.2 Общие требования к возможности наполнения

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

6.3            Требования к персоналу

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

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

Администратор: уверенный пользователь сети Интернет, знание Microsoft Word.

Пользователи, HR специалист: уверенный пользователь сети Интернет.

6.3 Требование к хранению информации (данных)

Все данные сайта должны храниться в структурированном виде под управлением реляционной СУБД. Исключения составляют файлы, предназначенные для просмотра и скачивания (изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД размещаются ссылки на них. Наполнение различных сайтов, функционирование которых поддерживается одной и той же инсталляцией системы, должно храниться под управлением единой СУБД.

6.4 Порядок предоставления дистрибутива

По окончанию разработки Исполнитель должен предоставить Заказчику исходные коды портала в составе:

  • архив с исходными кодами всех программных модулей и разделов портала (сайта);
  • дамп базы данных с актуальной информацией.
  • Дистрибутив предоставляется на CD-диске в виде файлового архива.

 

  • Порядок переноса сайта на технические средства заказчика

После завершения сдачи-приемки сайта (портала), в рамках гарантийной поддержки Исполнителем производится однократный перенос разработанного портала на сервер Заказчика.  Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и доступ к базе данных.

  • Дополнительные требования

Требования к производительности:

  • Работа любого скрипта не должна превышать 60 секунд.
  • При условии нагрузки на сервер не более 2000 обращений к страницам портала в сутки.

Требования к безопасности

  • Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-код скриптов, Python скриптов. Требуется разграничение доступа.
  • Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp невозможен.
  • На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.

Требования к надежности

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

7                   Требования к составу и содержанию работ по подготовке

7.1 Наполнение портала

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

В процессе разработки методических материалов будет использоваться сайт МАГАТЭ, национальные нормативные акты, международные нормативные акты

8                   Объект автоматизации к вводу системы в действие

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

9                   Требования к документированию

10              Источники разработки

07.11.2017 от Песочница 0

Свежие записи

Рейтинг@Mail.ru