Песочница

Использование спецификации Open GL при построении трехмерного представления

OpenGL (Open Graphics Library) — спецификация, определяющая платформонезависимый (независимый от языка программирования) программный интерфейс для написания приложений, использующих двумерную и трёхмерную компьютерную графику. Включает более 300 функций для рисования сложных трёхмерных сцен из простых примитивов. Используется при создании компьютерных игр, САПР, виртуальной реальности, визуализации в научных исследованиях. На платформе Windows конкурирует с Direct3D.

Для разработки будем использовать пакет SharpGL. WinForms, скаченный из nuget.org (nuget  — менеджер пакетов для .Net. Данный галерея пакетов является центральным репозиторием пакетов, которой используют все авторы и потребители).

Добавим SharpGl к компонентам .Net Framework. Добавим DLL SharpGL  к проекту.

Нарисуем треугольник, с красным, зеленым и синим цветом по углам треугольника. Добавим 6 кнопок с координатами (X, Y, Z) для увеличения или уменьшения координат (рисунок 9).

 

 

Листинг программы

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;

 

namespace openGL_example

{

public partial class Form1 : Form

{

private float axis_rotate_X;

private float axis_rotate_Y;

private float axis_rotate_Z;

public Form1()

{

InitializeComponent();

this.axis_rotate_X = 0;

this.axis_rotate_Y = 0;

this.axis_rotate_Z = 0;

}

 

private void button1_Click(object sender, EventArgs e)

{

this.axis_rotate_X = this.axis_rotate_X + 5f;

}

 

private void button2_Click(object sender, EventArgs e)

{

this.axis_rotate_Y = this.axis_rotate_Y + 5f;

}

 

private void button3_Click(object sender, EventArgs e)

{

this.axis_rotate_Z = this.axis_rotate_Z + 5f;

}

 

private void button4_Click(object sender, EventArgs e)

{

this.axis_rotate_X = this.axis_rotate_X -5f;

}

 

private void button5_Click(object sender, EventArgs e)

{

this.axis_rotate_Y = this.axis_rotate_Y — 5f;

}

 

private void button6_Click(object sender, EventArgs e)

{

this.axis_rotate_Z = this.axis_rotate_Z — 5f;

}

 

private void button7_Click(object sender, EventArgs e)

{

}

 

private void button8_Click(object sender, EventArgs e)

{

}

 

private void openGLControl1_OpenGLDraw(object sender, SharpGL.RenderEventArgs args)

{

SharpGL.OpenGL gl = this.openGLControl1.OpenGL;

gl.Clear(SharpGL.OpenGL.GL_COLOR_BUFFER_BIT | SharpGL.OpenGL.GL_DEPTH_BUFFER_BIT);  // Очистка скрина

gl.LoadIdentity();    // сброс

gl.Translate(0.0f, 0.0f, -6.0f);  // переместить влево

gl.Rotate(axis_rotate_X, 1.0f, 0.0f, 0.0f);

gl.Rotate(axis_rotate_Y, 0.0f, 1.0f, 0.0f);

gl.Rotate(axis_rotate_Z, 0.0f, 0.0f, 1.0f);

gl.Begin(SharpGL.OpenGL.GL_TRIANGLES); // начать рисовать пирамиду

gl.Color(1.0f, 0.0f, 0.0f);   //красный

gl.Vertex(0.0f, 1.0f, 0.0f); // центр пирамиды

gl.Color(0.0f, 1.0f, 0.0f); //Зеленый

gl.Vertex(-1.0f, -1.0f, 1.0f);  // левая сторона пирамиды

gl.Color(0.0f, 0.0f, 1.0f);  // Синий

gl.Vertex(1.0f, -1.0f, 1.0f);  // права сторона пирамиды

gl.Color(1.0f, 0.0f, 0.0f);   //красный

gl.Vertex(0.0f, 1.0f, 0.0f); // центр пирамиды

gl.Color(0.0f, 0.0f, 1.0f); //Зеленый

gl.Vertex(1.0f, -1.0f, 1.0f);  // левая сторона пирамиды

gl.Color(0.0f, 1.0f, 0.0f);  // Синий

gl.Vertex(1.0f, -1.0f, -1.0f);  // права сторона пирамиды

gl.Color(1.0f, 0.0f, 0.0f);   //красный

gl.Vertex(0.0f, 1.0f, 0.0f); // центр пирамиды

gl.Color(0.0f, 1.0f, 0.0f); //Зеленый

gl.Vertex(1.0f, -1.0f, -1.0f);  // левая сторона пирамиды

gl.Color(0.0f, 0.0f, 1.0f);  // Синий

gl.Vertex(-1.0f, -1.0f, -1.0f);  // права сторона пирамиды

gl.Color(1.0f, 0.0f, 0.0f);   //красный

gl.Vertex(0.0f, 1.0f, 0.0f); // центр пирамиды

gl.Color(0.0f, 0.0f, 1.0f); //Зеленый

gl.Vertex(-1.0f, -1.0f, -1.0f);  // левая сторона пирамиды

gl.Color(0.0f, 1.0f, 0.0f);  // Синий

gl.Vertex(-1.0f, -1.0f, 1.0f);  // права сторона пирамиды

gl.End();

gl.LoadIdentity();

}

private void openGLControl1_Load(object sender, EventArgs e)

{

}}

}

Результат работы программы представлен ниже

При нажатии на кнопку соответствующей координате – наш треугольник смешается относительной ей.

Учебный проект. Разработчик: Цирков Г.А.

Метод простой замены на c#

Задача: разработать программу, которая будет заменять символы шифруемого текста на символы того же алфавита со сдвигом вправо на два символа.

Git https://github.com/aovakur/simple_replacement

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

Git https://github.com/aovakur/swap_adjacent

Моделирование бизнес процессов в Aris express

Название Компании: ООО «Баалу»

Миссия: Укрепиться на московском рынке.

Стратегия: Наладить производство самых качественных кожаных курток.

Тактика: Закупить лучшее оборудование, грамотно организовать рекламную кампанию и выйти на большой рынок.  

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

Диаграмма «Цепочка добавленной стоимости» — Value added chain diagram (VAD) — диаграмма, описывающая взаимосвязь бизнес-процессов верхнего уровня(рис. 1).

Бизнес-процессы компании ООО «Баалу» на примере VAD диаграммы

 

Песочница. Оценка ювелирного изделия

 Условия:

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

Заказчик выслал Вам следующее описание бизнес-процесса своей деятельности:

Клиент приносит в ломбард ювелирное изделие. Приемщик производит оценку ювелирного изделия. Оценка зависит от следующих параметров:

— Вес золота;

— Проба золота;

— Состояние изделия.

Приемщик озвучивает клиенту оценочную стоимость и условия залога изделия. В случае согласия Клиента, Приемщик оформляет залоговый билет. Залоговый билет оформляется на срок 10 дней.

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

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

До истечения срока действия залогового билета, Клиент имеет право продлить срок действия кредита на 10 дней. При этом, он должен оплатить процент за прошедшие дни использования кредита.

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

 

 

Задание:

  1. Напишите перечень вопросов, которые Вы зададите клиенту для уточнения бизнес-процесса и требований к программному обеспечению. Приветствуется разделение вопросов в зависимости от типа интервьюируемого (Приемщик или Директор).
  2. Напишите перечень UserStory основываясь на приведенном бизнес-процессе.
  3. Нарисуете с использованием любой нотации (или без таковой) схему бизнес-процесса. Можно использовать любой инструмент или выслать скан, нарисованный от руки.
  4. Нарисуйте с помощью любого программного средства (приветствуется MS Visio) Ваше представление об основной форме приложения. Можно в виде скетча, от руки.
  5. Сделайте проект отчетной формы.
  6. Результаты задания оформите в виде документа MS Word.

Перечень вопросов

Бизнес процесс

  • Оценка изделия будет производиться автоматически в программном обеспечении (с заданием параметра веса, пробы золота, состояния изделия), или приемщик будет производить это сам?

Требования

Директор

  • Программное обеспечение планируется использовать на персональном компьютере под управлением какой операционной системы (MacOS, Windows, Linux)?
  • Какое количество пользователей будут использовать программное обеспечение, какое количество филиалов?
  • Как будет производиться авторизация пользователей в системе? (авторизация операционной системы или выдача логина-пароля)
  • В программном обеспечении необходимо ли настроить поддержку фискального принтера?
  • В программном обеспечении должно быть предусмотрено автоматическое печатание залогового билета с введенными данными клиента (контактные данные клиента + параметры ювелирного изделия и оценочная стоимость, условия залога, дата подписания залога)?
  • Нужны ли какие-нибудь дополнительные модули приложения (например, СМС информирование клиентов).

Приемщик

  • В каком форме должен формироваться отчет? (pdf файл, html, docx)?
  1. User story
  • Как приемщик, я хочу, чтобы система позволяла мне добавлять данные о клиентах.

Критерии приемки:

Как приемщик, я хочу, чтобы позволяла внести данные клиента в приложение

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

Обработка ошибок:

  1. Введенные данные должны проверяться на корректность (если это номер мобильного телефона – длина)
  2. Дата окончания договора должна быть на 10 дней больше даты приемки.
  3. Если приемщик не ввел во всех поля значения, то выводиться диалоговое окно с тем, чтобы заполнить все поля.

Технические заметки:

Количество пользователей, которые должны выводится в основной форме, должно быть не больше 5.

  • Как приемщик, я хочу, чтобы система позволяла мне формировать отчет

Критерии приемки:

Как приемщик, я хочу, чтобы система позволяла создавать ежедневные, ежемесячные и отчет о погашенных кредитах в формате pdf, html, docx.

Обработка ошибок:

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

  1. Бизнес процесс

У нас имеется процесс выдачи микрокредита.

  1. Выдача микрокредита

Бизнес процесс имеет два верхнеуровневых бизнесс-процесса: выдача кредита и формирование отчетности по выданным кредитам.

Модель в нотации IDF0, сформированная в BPwin.

  1. Верхнеуровневые бизнес-процессы

Декомпозиция бизнес процесса «Выдача кредита», смоделированная в нотации IDF3.

  1. Выдача кредита

Бизнес-процесс «Выдача кредита» в нотации EPC Бизнес студио.

  1. Бизнес-процесс «Выдача кредита»

Основная форма приложения

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

5.Основная форма работы приемщика с системой

6.Форма отчетов

5.Отчетная форма

Отчетную форму приемщик может сформировать в разделе «Отчеты». У нас имеется 3 вида отчетных форм: отчет, содержащий информацию о выданных, продленных и погашенных кредитах.

 

  • Ювелирные изделия, которые приняты под залог
Ведомость учета ювелирных вещей, принятых под залог
Дата 05.05.2010
№ залогового билета Ф.И.О Принято залогов Суммы
Оценки Ссуды
1 2342 Иванов Сергей Сидорович 2 2332 1000

 

  • Ювелирные изделия, которые приняты под залог, которые продлены
Ведомость учета ювелирных вещей, принятых под залог, которое продлены
Дата  составления отчета 20.11.2011 Статус залогов Продлены
№ залогового билета Ф.И.О Дата приемки Дата окончания Принято залогов Суммы
Оценки Ссуды
1 2342 Иванов Сергей Сидорович

 

 

 12/12/2010 22/12/2010 2 2332 1000
 Приемщик Кассир

 

 

 

  • Погашенные кредиты
Ведомость учета ювелирных вещей, принятых под залог, которые погашены
Дата  составления отчета 20.11.2011 Статус залога Погашен
№ залогового билета Ф.И.О Дата приемки Дата окончания Принято залогов Суммы
Оценки Ссуды
1 2342 Иванов Сергей Сидорович

 

 

2 2332 0
 Приемщик Кассир

 

 

 

 

Песочница. Концепция Информационной системы (ИС) создаваемой для учета ссуд в микро финансовой организации.

Введение

Во исполнение плана мероприятий по автоматизации деятельности микро финансовой организации и соблюдения 151 Федерального закона «О микрофинансовой деятельности и микрофинансовых организациях» создается концепция информационной системы (ИС). Концепция определяет цели и задачи создания типового программно-технологического обеспечения микрофинансовой организации (МФО), общую функциональную архитектуру и состав информационного обеспечения системы, а также этапы ее создания и последующей эксплуатации. Концепция подготовлена на основе анализа возможности автоматизации процессов сбора, обработки и представления информации, необходимой для владельца и сотрудников-приемщиков МФО.

II. Предпосылки создания системы

Основополагающими документами при создании системы являются: — 151 Федеральный закон «О микрофинансовой деятельности и микрофинансовых организациях — 346.12 статья Налогового кодекса России — Указание Банка России от 11.03.2016 No 3979 У «О формах и сроках представления в Банк России документов, содержащих отчет о микрофинансовой деятельности и отчет о персональном составе руководящих органов микрофинансовой организации»;

III. Цель создания системы

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

Для достижения этой цели необходимо обеспечить: — разработку программно-технического решения; — разработку проектов необходимой рабочей документации, необходимой для обеспечения процессов внедрения и адаптации ИС; — апробацию, адаптацию и опытную эксплуатацию системы; — доработку и уточнение состава рабочей документации и регламентной и организационной документации, необходимой для обеспечения процессов внедрения и адаптации ИС по итогам опытной эксплуатации; — подготовку материалов и методических рекомендаций по адаптации системы по результатам внедрения;

IV. Основные требования, предъявляемые к системе

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

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

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

V. Состав и структура системы

Основными компонентами системы являются: — Хранилище данных — Работа с залоговым билетом — Формирование отчетности — Модули администрирования, обеспечивающие выполнение операций ведения баз данных, управления учетными записями пользователей и разграничения прав доступа к ресурсам системы.

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

VI. Хранилище данных

Хранилище данных должно объединять информацию, необходимую для решения прикладных задач системы: — Ведения учета клиентов — Редактирования статуса клиента (продлен, уплачены проценты, завершен) — Формирования отчетности

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

VII. Работа с залоговым билетом

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

VIII. Формирование отчетности

Средства формирования отчётности предназначены для отображения исходных данных.

Средства представления данных должны обеспечивать: — Формирование и сохранение отчетных форм, полученных в прогнозно-аналитических подсистемах типового решения, в том числе формирование отчетов с использованием параметризированных запросов при использовании толстого клиента; — Экспорт полученных выходных отчетных форм в стандартные офисные приложения, и в виде html-файлов; — Вывод отчетных документов на печать с возможностью предварительного просмотра и редактирования параметров страницы:
— Представление данных в табличном, графическом, анимированном и картографическом виде: — Формирование веб-раздела представления данных в сети Интернет.

IX Программные модули администрирования

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

Основными направлениями создания комплексной системы защиты информации являются: — обеспечение безопасности взаимодействия системы с внешними источниками информации; — защита информации от несанкционированного доступа.

X. Обеспечение создания, функционирования и развития системы

Создание системы осуществляется в 3 этапа: I этап (сентябрь 2017 года) – проектирование и создание ИС; II этап (октябрь 2017 года) – адаптация и внедрение системы; III этап (ноябрь 2017 года) – тиражирование системы в филиалы;

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

На II этапе планируется: — Адаптация и внедрение информационной системы; — Доработка и внедрение модулей системы; — Подготовка методических рекомендаций по работе с системой.

На III этапе планируется: — Тиражирование и адаптация разработанной системы в филиалы компании; — Ввод системы в промышленную эксплуатацию в субъектах.

XI. Ресурсное обеспечение создания и развития системы

В связи с тем, что создание системы носит комплексный характер, направленный на совершенствование информационно-технологической и информационно-коммуникационной инфраструктуры микро финансовых организаций. Финансирование проекта осуществляется заказчиком в полном объеме.

XIV. Ожидаемый социально-экономический эффект создания системы

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

Структура документа:

Глоссарий

Общие положения

2.1 Предмет разработки

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

  1. Требования к графическому дизайну сайта

3.1 Требования к дизайну сайта

3.2 Порядок утверждения дизайн-концепции

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

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

4.2 Требования к представлению сайта

4.3 Требования к системе управления сайтом

4.4 Требования к разделению доступа

  1. Требования к видам обеспечения

5.1 Требования к информационному обеспечению

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

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

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

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

  1. Требования к приемке-сдаче проекта

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

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

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

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

  1. Глоссарий

 

Термин Описание
Сайт Информационная система, предоставляющая пользователям сети

Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц

 

Мобильное приложение Мобильное приложение – это специально разработанное приложение под конкретную мобильную платформу (iOS, Android, Windows Phone).
Нативное мобильное приложение Приложение можно назвать «родным» для операционных систем – Android, IOS, WinPhone . Такие мобильные приложения пишутся на языках программирования, утвержденных разработчиками программного обеспечения под каждую конкретную платформу, а потому органично встраиваются в сами операционные системы. Приложения загружаются через магазины приложений (App Store, Google Play и т.д.) и соответствуют требованиям этих магазинов.
Администратор Лицо, осуществляющее от имени Заказчика информационную поддержку сайта
Дизайн веб-сайта Уникальные для конкретного веб-сайта структура, графическое

оформление и способы представления информации

 

 

  1. Общие положения

2.1 Предмет разработки

 

user case

Рис. Use case

 

Предметом разработки является

  • мобильное приложение с автоматическим наполнением контента;
  • Сайт;

 

Назначение мобильного приложения:

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

 

Назначение сайта

—   Вывод рекламной информации о мобильном приложении;

—   Осуществление администрирование мобильного приложения;

—   Вывод аналитической информации (с возможностью отправить на принтер и на почтовый адрес);

 

Цель создания мобильного приложения:

—   Агрегирование сервисов курортной зоны России в одной месте;

—   Возможность бронирования путешествий «в один клик»;

—   Обмен сообщениями и отзывами между пользователями;

 

Целевая аудитория сайта:

—   Семейные пары (средний возраст которых родителей 30-35 лет) с маленькими детьми, которые планируют провести отдых на курортных зонах России (Сочи, Крым и тд);

—  Молодежь (от 18 до 30 лет), которая планирует отправиться на зимние курортные зоны (Красная поляна, Кавказ и тд.);

—   Активные люди, которые любят путешествовать по России и сами планируют свой отпуск;

 

 

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

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

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

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

 

  1. Требования к графическому дизайну сайта

3.1 Требования к дизайну сайта

При разработке сайта должны быть использованы преимущественно светлые и контрастные цветовые решения (пример дизайнерских решений: https://habrahabr.ru/post/334722/ ).

Оформление должно быть разработано в достаточно консервативном ключе.

На страницах недолжно быть большого объема текста.

 

В дизайне сайта не должны присутствовать:

— мелькающие баннеры;

— много сливающегося текста;

— тёмные и агрессивные цветовые сочетания и графические решения.

 

Снимок

Рис. Пример формы авторизации

 

3.2 Порядок утверждения дизайн-концепции

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

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

 

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

 

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

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

  • Гость – неавторизованный пользователь, обладает правами:
  • Регистрация в мобильном приложении;
  • Авторизация: ввод аутентификационных данных;
  • Авторизованный пользователь обладает правами:
  • Статические разделы – просмотр;
  • Разделы новостей – просмотр;
  • Новости – просмотр;
  • Раздел бронирование билетов – просмотр;
  • Раздел бронирования развлечений – просмотр;
  • Раздел бронирования путевок – просмотр;
  • Раздел бронирования транспорта – просмотр;
  • Видеоролики, фотографии – просмотр, добавление отзыва, редактирование собственного отзыва
  • Обратная связь – создание письма
  • Сообщение в техподдержку – создание заявки
  • Комментарии к разделам и подразделам– просмотр, добавление собственных, редактирование собственных
  • Подписка на рассылки и уведомления
  • Личный кабинет:
  • Информация о пользователе – просмотр, редактирование собственной информации
  • Статистика писем– просмотр собственных писем
  • Список рассылок и уведомлений – просмотр, редактирование, удаление

 

3) Администратор – пользователь, авторизованный в интерфейсе сайта

  • Полный доступ ко всем функциональным возможностям администрирования мобильного приложения:
  • Статические разделы — просмотр, добавление, редактирование, удаление
  • Разделы новостей — просмотр, добавление, редактирование, удаление
  • Новости – просмотр, добавление, редактирование, удаление
  • Статьи – просмотр, добавление, редактирование, удаление
  • Разделы– просмотр, добавление, редактирование, удаление
  • Видеоролики, фотографии – просмотр, добавление, редактирование, удаление
  • Личные данные пользователей – просмотр, редактирование
  • Список рассылок и уведомлений – просмотр, добавление, редактирование, удаление
  • Комментарии к фотографиям, видеороликам, текстам– просмотр, редактирование, удаление
  • Группы пользователей – просмотр, добавление, редактирование, удаление
  • Пользователь — просмотр, добавление, редактирование, удаление, раздача прав
  • Статистика – просмотр

 

4.2 Требования к представлению мобильного приложения

Требования к представлению главной страницы мобильного приложения.

 

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

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

 

Контентная часть главной странице мобильного приложения должна включать:

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

Требования к отображению раздела «проживание».

При переходе пользователя на раздел «проживание» пользователю в верхней части экрана

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

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

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

Требования к отображению раздела «развлечения».

При переходе пользователя на раздел «развлечения» пользователю

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

 

Требования к внутренним страницам раздела «развлечения».

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

 

Требования к разрабатываемому разделу «транспорт»

  • Должны присутствовать разделы-выборы авиа-билеты, жд билеты, вызов такси, аренда автобуса;
  • В разделе авиабилеты должен быть календарь с выбором дата отчета и прилета, пунктом отправления и пунктом назначения, класс
  • В разделе авто должны присутствовать выбор тип авто: эконом, «люкс», «комфорт»

 

Требования к разрабатываемому разделу «питание»

  • Вызов питания на дом
  • Заказ столика в ресторане

 

Требования к внутренним страницам раздела «питание».

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

 

 

Требования к внутренним страницам раздела «личный кабинет».

  • После регистрации пользователя у него создается личный кабинет.
  • У пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.
  • Личный кабинет пользователя находится в боковой части экрана. Там должна быть возможность выбрать фотографию пользователю, выбрать перейти в раздел редактирования личного кабинете. Добавления данных кредитной карты, добавления информации, включения галочки пуш уведовлений.
  • К личному кабинету прикрепляется мониторинг действий (возможно гугл метрика).
  • На основании активности пользователя формируется релевантные предложения

 

 

Требования к странице «оплата».

Оплата путевки, тура, экскурсии, снаряжения и тд.

  • После добавления элемента (путевки и тд) в корзину, пользователю выводится сообщения о том, хочет ли он продолжить покупку чего-нибудь еще и перейти на оплату.
  • После перехода пользователю на вкладку оплаты, если у него не введены данные карты, то ему предлагается вести данные карты (Номер, код, владелец). После введения этих данных пользователь переходит на страницу подтверждения оплаты
  • На странице подтверждения оплаты ему выводится список того, что он выбрал, стоимость заказы, налог на данную услугу, комиссия, если она есть, и итоговая стоимость и кнопка оплатить.
  • После нажатия на кнопку оплатить. Клиенту выводится сообщение, что его заказ принят и обрабатывается. Если у клиента недостаточно денег, то ему выводится сообщение, о том, что у него недостаточно денег и предлагается ему вести другой номер карты или повторить попытку снова.
  • После успешной транзакции на почту клиента приходит чек о совершенной операции.
  • Оплата услуг должна производиться с помощью стороннего сервиса — Payonline.
  • После оплаты пользователю должно вернуться 6% кеш бека со следующей покупки.
  • Передача данных производится внутри приложения с помощь REST или JSON технологии.

Оплата авиа, жд билетов.

  • Оплата билетов происходит с помощью iframe, который выводится после нажатия на кнопку оплатить.
  • В iframe передаются параметры: фамилия, имя, отчество, данные кредитной карты.
  • После оплаты возвращается callback в мобильное приложение.

 

Требования к структуре сайта

  • Сайт создается с целью внесения в ручном режиме информации на сайт.
  • Для выгрузки отчетности

Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах.

 

Авторизация

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

  • Текстовое поле для ввода логина пользователя
  • Кнопка отправки формы.

 

Данные для доступа (авторизации):

  • Логин – адрес электронной почты пользователя
  • Пароль – строка содержащая от 8 символов, состоящая из A-z, 0-9.

 

Ниже формы располагаются ссылка:

  • Забыли пароль

Форма «Забыли пароль» содержит поля:

  • Email адрес пользователя, указанный при регистрации

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

авторизоваться с формой авторизации.

 

Списки рассылок и уведомления

Авторизованные пользователи могут управлять своими списками рассылок, а также

просматривать полученные уведомления.

 

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

Администратор

  • Добавить рассылку
  • Удаление рассылку
  • Редактирование рассылку

 

Авторизованный пользователь

  • Просмотреть список рассылок
  • Подписаться на список рассылок
  • Отписать от списка рассылок
  • Просмотреть уведомления

 

4.4 Требования к разделению доступа

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

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

 

  1. Требования к видам обеспечения

5.1 Требования к информационному обеспечению

Требования к хранению данных

Все данные сайта должны храниться в структурированном виде под управлением реляционной

СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания

(изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД

размещаются ссылки на них.

Наполнение различных сайтов, функционирование которых поддерживается одной и той же

инсталляцией системы, должно храниться под управлением единой СУБД.

 

Требования к языкам программирования

Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS.

Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).

Для реализации интерактивных элементов клиентской части должны использоваться языки

JavaScript и DHTML.

Для реализации динамических страниц должен использоваться язык PHP.

Для разработки мобильного приложения должен быть использован ReactJS

 

Требования к организации гиперссылок

Все ссылки в мобильном приложении должны быть относительными (за исключением внешних).

Требования к иллюстрациям

Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть

выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.

Требования к объему одной страницы

Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.

 

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

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

  • Операционная система семейства 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.

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

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

 

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

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

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

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

обширного тестирования всех модулей

 

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

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

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

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

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

Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

 

  1. Требования к приемке-сдаче проекта

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

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

Наполнение страниц мобильного приложения должно происходить в автоматическом режиме.

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

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

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

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

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

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

составе:

— архив с исходными кодами всех программных модулей и разделов сайта;

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

Дистрибутив предоставляется на CD-диске в виде файлового архива.

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

После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем

производится однократный перенос разработанного программного обеспечения в apple store, google market .

Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и

доступ к базе данных сайта.

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

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

Работа любого скрипта не должна превышать 60 секунд.

При условии нагрузки на сервер не более

500.000 обращений к страницам портала в сутки.

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

Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-

код скриптов. Требуется разграничение доступа.

Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp возможен.

На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.

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

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

хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить

копию сайта

Задачка с Титаником

Сейчас Python является одним из наиболее распространенных языков программирования. Одним из его преимуществ является большое количество пакетов, решающих самые разные задачи. В нашем курсе мы рекомендуем использовать библиотеки Pandas, NumPy и SciPy, которые существенно упрощают чтение, хранение и обработку данных. В дальнейших работах вы также познакомитесь с пакетом Scikit-Learn, в котором реализованы многие алгоритмы машинного обучения.

  • Какое количество мужчин и женщин ехало на корабле? В качестве ответа приведите два числа через пробел.
  • Какой части пассажиров удалось выжить? Посчитайте долю выживших пассажиров. Ответ приведите в процентах (число в интервале от 0 до 100, знак процента не нужен), округлив до двух знаков.
  • Какую долю пассажиры первого класса составляли среди всех пассажиров? Ответ приведите в процентах (число в интервале от 0 до 100, знак процента не нужен), округлив до двух знаков.
  • Какого возраста были пассажиры? Посчитайте среднее и медиану возраста пассажиров. В качестве ответа приведите два числа через пробел.
  • Коррелируют ли число братьев/сестер/супругов с числом родителей/детей? Посчитайте корреляцию Пирсона между признаками SibSp и Parch.


74w
import pandas
In [26]:
data = pandas.read_csv('C:\\Users\\Andrey\\Desktop\\titanic.csv')
print (data)
     PassengerId  Survived  Pclass  \
0              1         0       3   
1              2         1       1   
2              3         1       3   
3              4         1       1   
4              5         0       3   
5              6         0       3   
6              7         0       1   
7              8         0       3   
8              9         1       3   
9             10         1       2   
10            11         1       3   
11            12         1       1   
12            13         0       3   
13            14         0       3   
14            15         0       3   
15            16         1       2   
16            17         0       3   
17            18         1       2   
18            19         0       3   
19            20         1       3   
20            21         0       2   
21            22         1       2   
22            23         1       3   
23            24         1       1   
24            25         0       3   
25            26         1       3   
26            27         0       3   
27            28         0       1   
28            29         1       3   
29            30         0       3   
..           ...       ...     ...   
861          862         0       2   
862          863         1       1   
863          864         0       3   
864          865         0       2   
865          866         1       2   
866          867         1       2   
867          868         0       1   
868          869         0       3   
869          870         1       3   
870          871         0       3   
871          872         1       1   
872          873         0       1   
873          874         0       3   
874          875         1       2   
875          876         1       3   
876          877         0       3   
877          878         0       3   
878          879         0       3   
879          880         1       1   
880          881         1       2   
881          882         0       3   
882          883         0       3   
883          884         0       2   
884          885         0       3   
885          886         0       3   
886          887         0       2   
887          888         1       1   
888          889         0       3   
889          890         1       1   
890          891         0       3   

                                                  Name     Sex   Age  SibSp  \
0                              Braund, Mr. Owen Harris    male  22.0      1   
1    Cumings, Mrs. John Bradley (Florence Briggs Th...  female  38.0      1   
2                               Heikkinen, Miss. Laina  female  26.0      0   
3         Futrelle, Mrs. Jacques Heath (Lily May Peel)  female  35.0      1   
4                             Allen, Mr. William Henry    male  35.0      0   
5                                     Moran, Mr. James    male   NaN      0   
6                              McCarthy, Mr. Timothy J    male  54.0      0   
7                       Palsson, Master. Gosta Leonard    male   2.0      3   
8    Johnson, Mrs. Oscar W (Elisabeth Vilhelmina Berg)  female  27.0      0   
9                  Nasser, Mrs. Nicholas (Adele Achem)  female  14.0      1   
10                     Sandstrom, Miss. Marguerite Rut  female   4.0      1   
11                            Bonnell, Miss. Elizabeth  female  58.0      0   
12                      Saundercock, Mr. William Henry    male  20.0      0   
13                         Andersson, Mr. Anders Johan    male  39.0      1   
14                Vestrom, Miss. Hulda Amanda Adolfina  female  14.0      0   
15                    Hewlett, Mrs. (Mary D Kingcome)   female  55.0      0   
16                                Rice, Master. Eugene    male   2.0      4   
17                        Williams, Mr. Charles Eugene    male   NaN      0   
18   Vander Planke, Mrs. Julius (Emelia Maria Vande...  female  31.0      1   
19                             Masselmani, Mrs. Fatima  female   NaN      0   
20                                Fynney, Mr. Joseph J    male  35.0      0   
21                               Beesley, Mr. Lawrence    male  34.0      0   
22                         McGowan, Miss. Anna "Annie"  female  15.0      0   
23                        Sloper, Mr. William Thompson    male  28.0      0   
24                       Palsson, Miss. Torborg Danira  female   8.0      3   
25   Asplund, Mrs. Carl Oscar (Selma Augusta Emilia...  female  38.0      1   
26                             Emir, Mr. Farred Chehab    male   NaN      0   
27                      Fortune, Mr. Charles Alexander    male  19.0      3   
28                       O'Dwyer, Miss. Ellen "Nellie"  female   NaN      0   
29                                 Todoroff, Mr. Lalio    male   NaN      0   
..                                                 ...     ...   ...    ...   
861                        Giles, Mr. Frederick Edward    male  21.0      1   
862  Swift, Mrs. Frederick Joel (Margaret Welles Ba...  female  48.0      0   
863                  Sage, Miss. Dorothy Edith "Dolly"  female   NaN      8   
864                             Gill, Mr. John William    male  24.0      0   
865                           Bystrom, Mrs. (Karolina)  female  42.0      0   
866                       Duran y More, Miss. Asuncion  female  27.0      1   
867               Roebling, Mr. Washington Augustus II    male  31.0      0   
868                        van Melkebeke, Mr. Philemon    male   NaN      0   
869                    Johnson, Master. Harold Theodor    male   4.0      1   
870                                  Balkic, Mr. Cerin    male  26.0      0   
871   Beckwith, Mrs. Richard Leonard (Sallie Monypeny)  female  47.0      1   
872                           Carlsson, Mr. Frans Olof    male  33.0      0   
873                        Vander Cruyssen, Mr. Victor    male  47.0      0   
874              Abelson, Mrs. Samuel (Hannah Wizosky)  female  28.0      1   
875                   Najib, Miss. Adele Kiamie "Jane"  female  15.0      0   
876                      Gustafsson, Mr. Alfred Ossian    male  20.0      0   
877                               Petroff, Mr. Nedelio    male  19.0      0   
878                                 Laleff, Mr. Kristo    male   NaN      0   
879      Potter, Mrs. Thomas Jr (Lily Alexenia Wilson)  female  56.0      0   
880       Shelley, Mrs. William (Imanita Parrish Hall)  female  25.0      0   
881                                 Markun, Mr. Johann    male  33.0      0   
882                       Dahlberg, Miss. Gerda Ulrika  female  22.0      0   
883                      Banfield, Mr. Frederick James    male  28.0      0   
884                             Sutehall, Mr. Henry Jr    male  25.0      0   
885               Rice, Mrs. William (Margaret Norton)  female  39.0      0   
886                              Montvila, Rev. Juozas    male  27.0      0   
887                       Graham, Miss. Margaret Edith  female  19.0      0   
888           Johnston, Miss. Catherine Helen "Carrie"  female   NaN      1   
889                              Behr, Mr. Karl Howell    male  26.0      0   
890                                Dooley, Mr. Patrick    male  32.0      0   

     Parch            Ticket      Fare        Cabin Embarked  
0        0         A/5 21171    7.2500          NaN        S  
1        0          PC 17599   71.2833          C85        C  
2        0  STON/O2. 3101282    7.9250          NaN        S  
3        0            113803   53.1000         C123        S  
4        0            373450    8.0500          NaN        S  
5        0            330877    8.4583          NaN        Q  
6        0             17463   51.8625          E46        S  
7        1            349909   21.0750          NaN        S  
8        2            347742   11.1333          NaN        S  
9        0            237736   30.0708          NaN        C  
10       1           PP 9549   16.7000           G6        S  
11       0            113783   26.5500         C103        S  
12       0         A/5. 2151    8.0500          NaN        S  
13       5            347082   31.2750          NaN        S  
14       0            350406    7.8542          NaN        S  
15       0            248706   16.0000          NaN        S  
16       1            382652   29.1250          NaN        Q  
17       0            244373   13.0000          NaN        S  
18       0            345763   18.0000          NaN        S  
19       0              2649    7.2250          NaN        C  
20       0            239865   26.0000          NaN        S  
21       0            248698   13.0000          D56        S  
22       0            330923    8.0292          NaN        Q  
23       0            113788   35.5000           A6        S  
24       1            349909   21.0750          NaN        S  
25       5            347077   31.3875          NaN        S  
26       0              2631    7.2250          NaN        C  
27       2             19950  263.0000  C23 C25 C27        S  
28       0            330959    7.8792          NaN        Q  
29       0            349216    7.8958          NaN        S  
..     ...               ...       ...          ...      ...  
861      0             28134   11.5000          NaN        S  
862      0             17466   25.9292          D17        S  
863      2          CA. 2343   69.5500          NaN        S  
864      0            233866   13.0000          NaN        S  
865      0            236852   13.0000          NaN        S  
866      0     SC/PARIS 2149   13.8583          NaN        C  
867      0          PC 17590   50.4958          A24        S  
868      0            345777    9.5000          NaN        S  
869      1            347742   11.1333          NaN        S  
870      0            349248    7.8958          NaN        S  
871      1             11751   52.5542          D35        S  
872      0               695    5.0000  B51 B53 B55        S  
873      0            345765    9.0000          NaN        S  
874      0         P/PP 3381   24.0000          NaN        C  
875      0              2667    7.2250          NaN        C  
876      0              7534    9.8458          NaN        S  
877      0            349212    7.8958          NaN        S  
878      0            349217    7.8958          NaN        S  
879      1             11767   83.1583          C50        C  
880      1            230433   26.0000          NaN        S  
881      0            349257    7.8958          NaN        S  
882      0              7552   10.5167          NaN        S  
883      0  C.A./SOTON 34068   10.5000          NaN        S  
884      0   SOTON/OQ 392076    7.0500          NaN        S  
885      5            382652   29.1250          NaN        Q  
886      0            211536   13.0000          NaN        S  
887      0            112053   30.0000          B42        S  
888      2        W./C. 6607   23.4500          NaN        S  
889      0            111369   30.0000         C148        C  
890      0            370376    7.7500          NaN        Q  

[891 rows x 12 columns]
In [51]:
guy=0
women=0
for index, row in data.iterrows(): 
    row[4]=str(row[4])
    if row[4]== "male":
        guy=guy+1
    else:
        women=women+1
print(guy,',',women)  #мужчины #женщины
577 , 314
In [28]:
servived=0
non_servived=0
doly=0
for index, row in data.iterrows(): 
    row[1]=str(row[1])
    if row[1]== "1":
        servived=servived+1
    else:
        non_servived=non_servived+1
sum=servived+non_servived      
percent=round((servived*100)/sum)
print(percent) #выжившие
38
In [72]:
class1=0
class2=0
class3=0
class4=0
sum=0
doly=0

for index, row in data.iterrows(): 
    row[2]=str(row[2])
    
    if row[2]== "1":
        class1=class1+1 
    if row[2]== "2":
        class2=class2+1
    if row[2]== "3":
        class3=class3+1
    if row[2]== "4":
        class4=class4+1
    
sum=class1+class2+class3+class4
doly= round(class1*(100/sum),2)
print(doly)  #доля первого класса
24.24
In [189]:
survived=0
notsurvived=0
import matplotlib.pyplot as plt
from matplotlib.lines import Line2D 
import pandas
data = pandas.read_csv('C:\\Users\\Andrey\\Desktop\\titanic.csv')
for index, row in data.iterrows(): 
    
    plt.plot(row[5], row[6], 'ro')
    
    row[1]=str(row[1])
    if row[1]== "1":
        survived=survived+1
    else:
        notsurvived=notsurvived+1
    
plt.grid(True)
plt.xlabel(u'Возраст')
plt.ylabel(u'Шлюпка')
plt.title(u'Рассадка пассажиров по шлюпкам')
plt.show()
sum=survived+notsurvived      
percent1=((survived*100)/sum)
percent2=100-percent1
print("Выжило = ",percent1,"%", "Кол-во", survived)
print("Не выжило = ",percent2,"%", "Кол-во",notsurvived)
Выжило =  38.38383838383838 % Кол-во 342
Не выжило =  61.61616161616162 % Кол-во 549
In [22]:
b=data['Age'].mean()  #среднее
m=data['Age'].median()   #медиана
print(round(b,2), m)
29.7 28.0
In [188]:
import pandas
import math
import matplotlib.pyplot as plt
from matplotlib.lines import Line2D 

data = pandas.read_csv('C:\\Users\\Andrey\\Desktop\\titanic.csv')
data.corr()
Out[188]:
PassengerId Survived Pclass Age SibSp Parch Fare
PassengerId 1.000000 -0.005007 -0.035144 0.036847 -0.057527 -0.001652 0.012658
Survived -0.005007 1.000000 -0.338481 -0.077221 -0.035322 0.081629 0.257307
Pclass -0.035144 -0.338481 1.000000 -0.369226 0.083081 0.018443 -0.549500
Age 0.036847 -0.077221 -0.369226 1.000000 -0.308247 -0.189119 0.096067
SibSp -0.057527 -0.035322 0.083081 -0.308247 1.000000 0.414838 0.159651
Parch -0.001652 0.081629 0.018443 -0.189119 0.414838 1.000000 0.216225
Fare 0.012658 0.257307 -0.549500 0.096067 0.159651 0.216225 1.000000

 

Нам необходимо построить классификатор Decision Trees

.

In [2]:
import numpy as np
import pandas as pd
In [6]:
from numpy import *
from sklearn.tree import DecisionTreeClassifier
data = pd.read_csv('C:\\tias\\titanic_1\\titanic.csv', index_col='PassengerId')
main_data_frame = pd.DataFrame(data=data, columns=['Pclass', 'Fare', 'Age', 'Sex', 'Survived'])
main_data_frame = main_data_frame[["Pclass", "Fare", "Age", "Sex", "Survived"]].dropna()   #очищаем от Nano(в)
output = main_data_frame[["Pclass", "Fare", "Age", "Sex"]].replace("female",0).replace("male",1)
clf = DecisionTreeClassifier(random_state=241)
Y = main_data_frame['Survived']
X = output

print(X.columns)
clf.fit(X, Y)
print(clf.feature_importances_)
Index(['Pclass', 'Fare', 'Age', 'Sex'], dtype='object')
[ 0.14000522  0.30343647  0.2560461   0.30051221]

Техническое задание на доработку сайта

1.Общие положения

1.1 Интернет-магазин представляет стильную мужскую одежду культовых брендов.

1.2 Доступ к сайту будет осуществляться при помощи персонального компьютера, смартфона, планшетного компьютера, имеющего браузер Firefox, Safari, Google Chrome или Edge.

2.Терминология

Адаптивный дизайн –  (Adaptive Web Design) — дизайн веб-страниц, обеспечивающий корректное отображение сайта на различных устройствах, подключённых к интернету и динамически подстраивающийся под заданные размеры окна браузера.

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

VPS – (Virtual Dedicated Server) — услуга, в рамках которой пользователю предоставляется так называемый виртуальный выделенный сервер. В плане управления операционной системой она соответствует физическому выделенному серверу. Имеется root-доступ, собственные IP-адреса, порты, правила фильтрования и таблицы маршрутизации.

Google PageSpeed Insights — это бесплатный сервис рекомендаций для веб-сайтов по ускорению отображения страницы в браузере пользователя (https://developers.google.com/speed/pagespeed/insights/).

Поисковая оптимизация (или SEO) — комплекс мер по внутренней и внешней оптимизации для поднятия позиций сайта в результатах выдачи поисковых систем по определённым запросам пользователей.

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

Внутренняя оптимизация сайта —  это оптимизация текста, URL-адресов, редактирование структуры сайта, перелинковка, проверка ответов сервера.

3. Описание функциональных блоков (задач) проекта

3.1. Дизайн

3.1.1 Дизайн сайта должен быть адаптивный и работать корректно во всех браузерах (Firefox, Safari, Edge) и устройствах (персональный компьютер, смартфон, планшетный компьютер). Разрешение экрана устройств имеет размер 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно.

3.1.2 Исправить ошибки верстки страниц в корзине и на странице оформления заказа.

3.2 Личный кабинет

3.2.1 На странице https://name.com/login/ добавить регистрацию и авторизацию посети-телей сайта через социальные сети – VK, Google, Facebook.

3.2.2  В личном кабинете в разделе заказы добавить поле для добавления промо-кода.

3.2.3 Вместо страницы, которая приходит пользователю после запроса на восстановление пароля (вида name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=) сделать страницу (вида name.com/login/forgot/сhange_password=yes&lang=ru&USER_CHECKWORD=), которая будет отображать контент сайта, будет иметь поле  «Email при регистрации», контрольная строка, новый пароль, подтверждение пароля, кнопка отправить данные.

3.2.4 При добавлении товаров в корзину должно выводиться сообщение о том, что товар добавлен в корзину.

3.2.5 Добавить вывод сообщения о том, что пароль не соответствует параметрам без-опасности при регистрации нового пользователя. Пароль пользователя должен проверяться на наличии больших, строчных букв и длинна должна составлять минимум 8 символов.

3.2.6  Исправить ошибку с не отображением товаров в боковом виджете корзины.

3.2.7 Убрать автоматическую подстановку имени из имени почтового адреса клиента в личном кабинете пользователя (http://name.com/account).

3.2.8 На странице восстановления пароля и на странице авторизации пользователя ( https://name.com, https://name.com/login/) при нажатии на поле для ввода информации надпись должна пропадать.

3.3 Меню

3.3.1 Отсортировать пункты подменю по первой букве названия. Выводить букву, а затем пункты подменю.

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

3.3.3 Необходимо убрать открытое подменю с разделами при переходе на соответствующие страницы из главного меню (Новинки, Дизайнеры, Одежда, Обувь, Аксессуары, Скидки). Особенно это касается страницы «Дизайнеры» и «Обувь», так как при переходе из меню на соответствующую страницу появляется подменю с несколькими десятками наименований.

3.3.4 Увеличить интервал между логотипом и меню.

3.4 Контакты

3.4.1 На странице https://name.com/contacts/ сделать так, чтобы карта не перехватывала прокрутку колеса мышки при попадании на него курсора.

3.4.2 Исправить указатель магазина Cornery, который нечетко отображается на странице с картой https://name.com/contacts/.

3.5 Оптимизация сайта

3.5.1 Сайт должен быть оптимизирован до показателя 90 баллов по PageSpeed Insights

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

3.6 Продвижение

3.6.1 Провести SEO оптимизацию.

4. Нефункциональные требования

4.1. Требования к организационному обеспечению

4.1.1 Сайт должен быть настроен на VPS.

4.1.2 Виртуальный выделенный сервер должен иметь PHP версии не ниже 5.3, Apache 1.3 и выше, MySQL 5.0 и выше, Phpmyadmin, акселераторы PHP c минимум 256 Мб кеша.

4.1.3 Должны присутствовать доступы по SSH и FTP.

4.1.4 VPS должен иметь возможность автоматического ежедневного резервного копирование файлов сайта и базы данных сайта.

4.1.5 Сайт должен стабильно работать при объеме трафика 1000 посетителей в день.

Проектирование хранилища данных Сбытовая логистика – Бухгалтерия дебиторов

Имеется предметная область «Сбытовая логистика – Бухгалтерия дебиторов. Предметная область представлена следующим набором сущностей:

Контракт — долгосрочное рамочное соглашение между сторонами; Заказ — краткосрочное соглашение на поставку в рамках контракта, обычно – месячное доп. соглашение; Поставка — товарно — транспортная накладная, документ, отражающий факт поставки по заказу; Фактура — документ, отражающий переход права собственности на поставляемый товар и акцепт Заказчиком дебиторской задолженности. Фактура может выставляться на одну или несколько поставок; Платеж — документ, отражающий факт поступления денег от Заказчика. Платежи могут поступать авансом или по факту поставки в погашение задолженности; Документ выравнивания — документ, отражающий сопоставление данных платежей и фактур, отражает бухгалтерский факт погашения дебиторской задолженности.

1.1 Контракт: Основные характеристики: Период действия (год) Заказчик (Регион, Страна, — «Россия и Белоруссия– СНГ – Дальнее зарубежье»); Продукт – Группа продуктов; Показатели: Объем по договору; Стоимость по договору; Договорная цена позиции Контракта.

1.2 Заказ Содержит уточненный на месяц объем поставки, уточнения по ценам. Наследует характеристики контракта. Кроме того, содержит дополнительные сведения: Период действия заказа (Месяц) Требуемая дата поставки; Показатели: Объем по заказу, Стоимость по заказу; Договорная цена позиции Заказа.

1.3 Поставка Наследует атрибутику заказа, кроме того, содержит следующие признаки: Дата отгрузки (с Предприятия); Дата передачи права собственности (Заказчику). 2 Показатели: Объем поставки; Стоимость поставки.

1.4 Фактура: Наследует атрибутику поставок, кроме того, содержит признаки: Дата фактуры (возникновения дебиторской задолженности); Планируемая дата погашения дебиторской задолженности. Показатели: Объем по фактуре; Стоимость по фактуре.

1.5 Платеж Содержит признаки: Контракт; Заказчик; Дата платежа Показатели: Сумма платежа;

1.6 Документ выравнивания Наследует признаки фактуры и платежа. Кроме того, содержит следующие признаки: Дата выравнивания (погашения дебиторской задолженности) Показатели: Сумма выравнивания.

Схема информационного Хранилища в виде ER – диаграммы.

Будем проектировать хранилище данных в виде ER — диаграммы в программе ERWIN. AllFusion ERwin Data Modeler (ранее ERwin) — CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.

ERWIN позволяет проектировать диаграмму на логическом и физическом уровне (SQL Server). Создадим 6 сущностей (+ я добил дополнительно сущность клиент), в каждой сущности добавим ключи. Зададим связь.

34
CREATE TABLE [Документ_выравнивания]
(
[Документ_выравнивания] varchar(20)  NOT NULL,
[Сумма_выравнивания] money  NULL ,
[Id_Выравнивания]    integer  NOT NULL ,
[Id_Фактуры]         integer  NULL ,
[id_Платежа]         integer  NULL
)
go

ALTER TABLE [Документ_выравнивания]
ADD CONSTRAINT [XPKДокумент_выравнивания] PRIMARY KEY  CLUSTERED ([Id_Выравнивания] ASC)
go

CREATE TABLE [Заказ]
(
[Период_действия]    date  NOT NULL ,
[Требуемая_дата_поставки] date  NOT NULL ,
[Объем_по_заказу]    integer  NOT NULL ,
[Стоимость_по_заказу] money  NOT NULL ,
[Договорная_цена_по_позиции] money  NOT NULL ,
[Id_Заказа]          integer  NOT NULL ,
[id_Контракта]       integer  NOT NULL
)
go

ALTER TABLE [Заказ]
ADD CONSTRAINT [XPKЗаказ] PRIMARY KEY  CLUSTERED ([Id_Заказа] ASC)
go

CREATE TABLE [Клиент]
(
[id_Контракта]       integer  NOT NULL ,
[Id_Заказа]          integer  NOT NULL ,
[Фамилия]            char(18)  NOT NULL ,
[Имя]                char(18)  NOT NULL ,
[Адрес]              char(18)  NOT NULL ,
[Телефон]            char(18)  NOT NULL ,
[id_Платежа]         integer  NOT NULL ,
[Id_Поставки]        integer  NOT NULL ,
[Id_Фактуры]         integer NOT NULL ,
[Id_Выравнивания]    integer  NOT NULL ,
[id]                 integer  NOT NULL
)
go

ALTER TABLE [Клиент]
ADD CONSTRAINT [XPKКлиент] PRIMARY KEY  CLUSTERED ([id] ASC)
go

CREATE TABLE [Контракт]
(
[id_Контракта]       integer  NOT NULL ,
[Период_действия]    date  NOT NULL ,
[Регион]             varchar(20)  NOT NULL ,
[Продукт]            varchar(20)  NOT NULL ,
[Объем_по_договору]  integer  NOT NULL ,
[Стоимость_по_договору] integer  NOT NULL ,
[Договорная_цена_по_позиции_контракта] integer  NOT NULL
)
go

ALTER TABLE [Контракт]
ADD CONSTRAINT [XPKКонтракт] PRIMARY KEY  CLUSTERED ([id_Контракта] ASC)
go

CREATE TABLE [Платеж]
(
[id_Платежа]         integer  NOT NULL ,
[Контракт]           varchar()  NOT NULL ,
[Заказчик]           varchar()  NOT NULL ,
[Дата_платежа]       date  NOT NULL ,
[Сумма_платежа]      money  NOT NULL
)
go

ALTER TABLE [Платеж]
ADD CONSTRAINT [XPKПлатеж] PRIMARY KEY  CLUSTERED ([id_Платежа] ASC)
go

CREATE TABLE [Поставка]
(
[Дата_отгрузки]      date  NOT NULL ,
[Дата_передачи_права_собственности] date  NULL ,
[Объем_поставки]     integer  NOT NULL ,
[Стоимость_поставки] money NOT NULL ,
[Id_Поставки]        integer  NOT NULL ,
[Id_Заказа]          integer  NOT NULL
)
go

ALTER TABLE [Поставка]
ADD CONSTRAINT [XPKПоставка] PRIMARY KEY  CLUSTERED ([Id_Поставки] ASC)
go

CREATE TABLE [Фактура]
(
[Дата_фактуры]       date  NOT NULL ,
[Планируемая_дата_погашения_дебиторской_задолжности] date NOT NULL,
[Стоимость_по_фактуре] money  NOT NULL ,
[Id_Фактуры]         integer  NOT NULL ,
[Id_Поставки]        integer  NOT NULL
)
go

Перенесем спроектированное хранилище в SQL SERVER.

24

cPy4ifxiZ_4

 

23

На гитхабе https://github.com/aovakur/databasedesign