Социальные сети

Сдал в начале сентября прошлого года

Московский Государственный Технологический Университет «Станкин»

Кафедра «Информационные технологии и вычислительные системы»

ОТЧЁТ

О прохождении производственной практики

Выполнил: Цырульников В.В., гр. И-6-5

Принял: доцент Лакунина О. Н,


Москва, 2009


1. Круг задач, решаемых предприятием

 Приоритетными направлениями деяткельности компании «Б-52 Консалтинг» (www.b-52.ru) являются разработка систем типа «Умный дом», Интернет-проектов и предоставление услуг доступа в Интернет в районе Новопеределкино посредством районных сетей B-52 и BiNet.

 
Для реализации Интернет-проектов используется собcтвенная разработка компании – система управления контентом CMSBuilder (www.cmsbuilder.ru), написанная на языке Perl и ориентированная на платформы Unix. В качестве операционной системы используется FreeBSD.


2. Полный перечень моих должностных обязанностей на предприятии.

 В список моих должностных обязанностей в должности web-программиста в компании «Б-52 Консалтинг» входит:

  1. Реализация и поддержка интернет-проектов на базе CMS (CMS – Content Manager System, Система управления контентом) CMSBuilder по части программной составляющей:
    • разработка новых модулей для CMSBuilder,
    • адаптация существующих модулей под конкретные проекты, при необходимости,
  2. Адаптация готовой вёрстки, разработка client-side приложений (используя JavaScript, jQuery,
    Ajax, Google/Yandex Maps API и др.)
  3. Выбор используемого программного обеспечения при решении нестандартных задач (пример – Интернет-радио с включением Skype).

3. Задачи, решавшиеся с моим участием в период практики, мои обязанности при решении каждой из задач.

 В период прохождения производственной практики были реализованы два проекта:

  1. Система бронирования гостиниц www.headcall.ru

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

    В мои обязанности при разработке данного ресурса входило:

     
    А) Ознакомление с Google Maps API (API – Application Programming Interface) для наглядного отображения гостиниц на карте Google Maps на выбранном пользователем участке

     
    Б) Создание фильтра, позволяющего отображать на карте только те гостиницы, которые удовлетворяют критериям, заданные пользователем. При изменении опций фильтра при помощи Ajax запрос на выборку гостиниц, удовлетворяющих заданным условиям, посылается через RPC на сервер. В ответ с сервера приходит XML-файл с перечнем точек с указанием их географических координат и типа (обычная/рекомендованная гостиница, у каждой своя пиктограмма на карте). Процесс поиска и отображения результатов запроса благодаря применению Ajax осуществляется без перезагрузки страницы. Клиентская часть приложения написана с использованием библиотеки jQuery, что существенно снижает объём кода, трудоёмкость его написания и повышает лёгкость восприятия.

     
    В) Внедрение галереи LightView для удобного просмотра фотографий гостиниц и их номеров.

     
    Г) Разработка модуля бронирования гостиниц для CMSBuilder, рассчитывающего стоимость проживания, сохраняющего заказ на бронирование в базе данных и отсылающего уведомление на E-Mail администратора ресурса.

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

     
    Е) Разработка модуля “Контакты”, предоставляющего пользователю возможность оставить своё сообщение, адресованное администратору, без публикации его на сайте. Сообщение отправляется на e-mail администратора средствами CMSBuilder путём вызова приложения sendmail (что позволяет оставлять сообщения пользователям, у которых не установлены почтовые клиенты, что было бы невозможно в случае использования mailto:[email] в качестве отправного адреса формы контактов)

     
    Ж) Адаптация существующих модулей CMSBuilder под требования вёрстки.

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

  2. Система диспетчеризации

     
    Система ориентирована на применение в коттеджных посёлках и предназначена для автоматизации ведения платежей ЖКХ – централизованный сбор информации с датчиков расхода холодной/горячей воды, газа. электричества, предоставление клиентам доступа по собранной информации – показания датчиков, суммы платежей, отчёты по заданынм периудам, отключение пользователей от тех или иных услуг ЖКХ.

     
    Состав системы:

     
    А) датчики, выполняющие сбор информации по расходу холодной/горячей воды, газа, электроэнергии. Передают информацию по интерфейсу RS-485 на точку, к которой подключены.

     
    Б) точки, представляющие микроконтроллерное устройство на базе AVR 32. Имеют 5 универсальных цифровых портов для подключения датчиков, 2 релейных выхода (по выбору – отключение пользователя от газо-, водо- и электроснабжения) и порт Ethernet для связи с центральным сервером

     
    В) центральный сервер, с ОС FreeBSD, на котором размещена база данных, в которую стекается информация с точек и хранится состояние релейных выходов, отправляемое при изменении на точки. Связан с точками посредством Ethernet сети.

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

     
    В мои обязанности входила разработка web-интерфейса система диспетчеризации, а именно:

     
    А) Изучение системы e-port и использование его в качестве основы для реализации на базе CMSBuilder.

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

     
    В) Разработка модуля вывода информации на сайте:

    • Отчеты. Выборка информации по точкам выбранных клиентов за заданный период. Возможность сортировки выводимой информации по любому из полей (кроме №п/п, даты и клиента). Суммирование результатов.
    • Просмотр информации по каждой точке – IP/MAC адрес точки, состояние, адрес, клиент, состояние точки,а также данные по входам/выходам (состояние входа/выхода, тип ввода, единица измерения (л, кВт/ч,куб/м), коэффициент перерасчёта импульсов в выбранную единицу измерения, суммарное количество импульсов).

    • Справочник – тоже, что и отчёты, но по всем точкам всех клиентов, без возможности поиска.

    Г) Памятка – справочная информация для пользователей.

     
    Д) Права доступа – раздел виден только операторам и администратору, возможность изменения прав доступа


4. Использовавшееся мною в период практики программное и аппаратное обеспечение, особенности работы с ним.

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

 
А) в качестве аппаратного обеспечения, используемый мною сервер1 имел конфигурацию:

 
Процессор – Intel Pentium IV 3.0GHz
Оперативная память – 3Гб
Жёсткий диск: 232Гб (основной), 677Гб (для автоматического сохранения резервных копий)
Операционная система: FreeBSD

 
Сервер 2 (тестовый, для отладки системы диспетчеризации):

 
Процессор – Intel Pentium IV 1.8GHz
Оперативная память – 1Гб
Жесткий диск: 68Гб (основной), 180Гб (для автоматического сохранения резервных копий)
Операционная система: FreeBSD

 
Б) в качестве программного обеспечения:

 

  • в качестве ОС – FreeBSD
  • в качестве Web-сервера – Apache с подключенным модулем mod_rewrite для возможности работы системы ЧПУ CMSBuilder.
    Модуль mod_rewrite является довольно мощным средством, предназначенным для URL-преобразований. Благодаря данному модулю CMS получает возможность полного контроля над запрашиваемыми адресами страниц.
  • в качестве языков разработки – perl, javascript (с применением библиотек ajax, prototype, jquery)
    Ajax (Asynchronous JavaScript and XML) - подход к построению пользовательских интерфейсов веб-приложений, при котором web-страница, не перезагружаясь, сама догружает нужные пользователю данные.
    Prototype – JavaScript Framework, см. Ниже, является по сравнению с jQuery менее эффектимным и более громоздким, одни и теже задачи выполняются значительнее эффективнее с применением jQuery, нежели Prototype.
    jQuery представляет собой JavaScript Framework и содержит функционал для быстрого решения большого круга задач. Благодаря данной библиотеки мы получаем возможность гораздо быстрее и проще решать возникающие задачи, легко добавлять в функционал страницы различные анимационные эффекты. Результирующий код получается компактным и легкочитаемым.
  • В качестве CMS – система управления контентом сайтов CMSBuilder. Рассмотрим данную систему подробнее.

1) Низший уровень системы. Сокеты. Технология “Клиент-сервер”. Режимы работы.

 
В настоящий момент для разработки web-скриптов на серверной стороне наибольшую популярность получили два языка – Perl и PHP, оба которых являются интерпретируемыми языками программирования. Интерпретатор первого языка – perl – оказывается эффективным в циклах за счёт того, что вначале создаётся двоичный исполняемый код (внутренне двоичное представление скрипта), который затем выполняется без участия perl. Т.е. Perl является транслирующим интерпретатором, за что его часто называет компилятором, хотя это и не так. В случае PHP, интерпретация команд происходит в циклах на каждой итерации, давая Perl ощутимое преимущество. Это и стало одной из причиной выбора языка Perl для разработки CMSBuilder.
 
Данная CMS может работать в двух основных режимах, задаваемых в конфигурационном файле – cgi и cgi-server:

  А) В режиме cgi CMS работает как обычное cgi-приложение, запускающееся и загружающееся в память каждый раз при обращении пользователя к странице

  Б) В режиме cgi-server CMS начинает работать как клиент-серверное приложение: основной процесс, включающий все модули CMS, интерпретируется (Один раз за всё время работы!) и загружается в память в качестве демона. При запросе пользователем запускается усечённая версия «лёгкая» CMSBuilder, функция которой – подключиться к серверной части – демону – и передать ей на вход переменные окружения и данные, пришедшие на входной дескриптор (переданные методом POST). После чего считать результат с серверной части и выдать пользователю. Т.е. серверная часть отвечает за сбор, хранение и обработку данных, в то время как клиентская играет роль посредника между Apache и серверной частью. Такой подход позволяет значительно повысить производительность системы в целом, ведь серверная часть загружается только один раз в память, а клиентская при запуске загружает минимальный набор функционала.

  Серверная часть может работать с двумя типами сокетов – как PF_INET (по tcp/ip), так и PF_UNIX (используя файловую систему Unix).

 
2) Панель администрирования. Drag’n’Drop. Контекстное меню. Загрузка файлов. Мультисайт. Возможности панели управления. ЧПУ. Тёги. Импорт/Экспорт Excel.

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

  Интерфейс панели администрирования состоит из трёх визуальный областей – фреймов – границы которых доступны для изменения пользователем. Первая область предназначена для отображения структуры сайта в виде дерева, загрузки файлов, управления CMS, вторая – для быстрого доступа к тем или иным модулям (выбранных пользователем), третья – наибольшая – для просмотра и редактирования выбранного объекта.

  Изменение структуры дерева сайта может производиться мышкой благодаря поддержке технологии Drag’n’Drop – для размещения страницы в другом разделе достаточно захватить соответствующую иконку и перенести её в нужный раздел дерева. Для удобства по умолчанию все ветви дерева, кроме главной, скрыты, и разворачиваются по желанию пользователя с наглядным отображением всех связей.

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

  Имеется удобная возможность загрузки файлов прямо в панели администрирования, с возможностью удаления и просмотра названия/типа файлов с помощь пиктограммок.

  Одним из основных преимуществ системы CMSBuilder является поддержка мультисайта – возможности размещение на базе одной копии CMS нескольких сайтов, со своими шаблонами и наполнением, своими доменными именами, но использующие единую базу данных. Основное применение – создание сайтов-сателлитов, различных по внешнему виду и части наполнения, но содержащие единую базу по товарам.

  Панель управления является одним из разделов панели администирирования и позволяет добавлять новые модули (внося изменения в БД), выбирать модули для отображения в “персональных модулях” (облегчает доступ к данным модулям), производить резервное копирование компонентов системы, конвертировать базу в иные форматы.

  Немаловажной особенностью CMSBuilder является поддержка ЧПУ. Данная концепция предполагает максимально лаконичные и интуитивно понятные адреса, которые показывают естественную для человека логическую структуру данных на сервере, а не её программный интерфейс с модулями и параметрами. Обычный адрес – abc.ru/f=123&gh=55&name=%20%44%40 – для нас не несёт никакой смысловой нагрузки, в то время как при использовании ЧПУ тот же адрес может обрести следующий вид: abc.ru/systems/os/freebsd/, из которого очевидно, что за страница скрывается за данным адресом.

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

  В паре с модулем Интернет-магазина наиболее часто используется модуль импорта-экспорта Excel-файла. Позволяет выгружать информацию о товарах, их характеристиках и ценах из базы данных сайта в Excel-файл, а также выполнять обратную операцию – импортировать информацию из загруженного пользователем excel-файла в базу данных сайта. При разработке данного модуля были использованы perl-модули SpreadSheet::ReadExcel и SpreadSheet::WriteExcel с репозитория cpan.org.

 
3) Объектно-ориентированный подход.

 
CMS CMSBuilder в полной мере соответствует концепции объектно-ориентированного подхода (за исключением инкапсуляции – в perl объекты не являются «вещью в себе», доступ к данным можно получить напрямую, без использования методов объекта). Все методы являются перегружаемыми, что позволяет для реализации тех или иных возможностей (в частности – изменение поведения функций, используемых при выводе блоков панели администрирования) не вторгаться в код ядра, а вносить необходимые поправки строго в разрабатываемом пакете. Взаимодействие с базой данных скрыто от разработчика модуля – вся работа осуществляется путём вызова наследуемых функций.

  Рассмотрим структуру класса в CMSBuilder (в perl классы представлены пакетами):

 
Package packagename;
use strict qw/subs vars/;# исключаем строгую проверку синтаксиса и определения переменных
use utf8;# CMSBuilder заточен на использование кодировки utf-8
our @ISA = qw(plgnSite::Member CMSBuilder::DBI::Array);# наследуем методы перечисленных и переменных классов. В Perl наследование методов осуществляется автоматически, наследование переменных – вручную программистом
sub _cname{‘название элемента в панели администиррования’}
sub _aview{qw/список полей элемента (хранимых в БД) в том порядке, в котором они будут выведены в панели администрирования/}
sub _template_export {qw/только перечисленные здесь методы будут доступны для вызова в шаблонах, применяемых пользователем к данному элементу/}
sub _have_icon {имеет ли элемент свою иконку, отображаемую в панели администрирования}
sub _rcps {qw/перечень методов, разрешённых для вызова со страницы сайта через Ajax. Используются для дозагрузки данных на страницу без перезагрузки онной. RPC – Remote Procedure Call, вызов удалённых процедур/}
sub _props{
#список полей элемента, сохраняемых в БД, например:
name => {type=>’string’,length=>100,name=>’Название’};
submenu =>{type=>’select’,variants=>[{before=>’До’,after=>’После’,no=>’Нет’}]}
# поле с указанным типом string будет представлено в БД полем типа varchar(100), в панели администрирования – элементом <input type=”text”>
# поле с указанным типом select будет представлено в БД полем типа ENUM(“before”,”after”,”no”), в панели администрирования – элементом <select>

# Каждому типу поля (string,select и т.д.) соответствует свой пакет в папке libcore/VType/, в котором определены соответствующие тип поля в БД, тип html-элемента в панели администрировании и правила редактирования/просмотра/добавления значения данного поля.

# В данном примере базовые поля будут унаследованы от модуля Site::Member, в котором также определён метод _props.
}

sub install_code
{
# необязательный метод . Выполняется при установке модуля (нажатие «Обновить» в панели администрирования)
my $mod = shift;

my $mr = modRoot->new(1);
my $to = $mod->cre();
$to->{'name'} = 'п~Sп╩п╟п╡пҐп╟я~O';
$to->{'address'} = 'http://'.$ENV{'SERVER_NAME'}.'/';
$to->{'email'} = 'info@'.join('.',grep {$_} reverse ((reverse split /\./
$to->save();

$mr->elem_paste($to);
# Данный пример наглядно иллюстрирует ООП-подход и служит для создания объекта класса modRoot, далее создаёт в БД запись об объекте текущего класса, снабжает его переменными name,address,email, сохраняет (при этом изменения записываются в БД) и вставляет в недавно созданный объект modRoot, который становится по отношению к нему родительским.
}
sub site_content{
my $o=shift;
for ($o->papaN(1)->get_all){
$_->site_preview;
}
$o->SUPER::site_content
# - берём «предка» нашего элемента и получаем для него информацию из БД –
#первого с корня дерева. get_all последовательно переберёт потомков первого
#уровня вложенности данного элемента и для каждого вызовет метод site_preview
#(предпросмотр контента элемента)
# Т.к. мы переопределили метод site_content, и нам нужен вывод унаследованного метода, вызываем его в $oi->SUPER::site_content
}

Система администрирования CMSBuilder

Система бронирования гостиниц headcall.ru

Web-интерфейс системы диспетчеризации


Техническое задание к программе "Система диспетчеризации"

 Содержание

1. Введение
1.1. Наименование программы
1.2. Назначение и область применения
2. Требования к программе
2.1. Требования к функциональным характеристикам
2.1.1. Описание интерфейса
2.2. Требования к надежности
2.2.1. Требования к обеспечению надежного функционирования программы
2.2.2. Время восстановления после отказа
2.2.3. Отказы из-за некорректных действий оператора
3. Условия эксплуатации
3.1. Климатические условия эксплуатации
3.2. Требования к квалификации и численности персонала
3.3. Требования к составу и параметрам технических средств
3.4. Требования к информационной и программной совместимости
3.4.1. Требования к информационным структурам и методам решения
3.4.2. Требования к исходным кодам и языкам программирования
3.4.3. Требования к программным средствам, используемым программой
3.4.4. Требования к защите информации и программ
3.4.5. Требования к графическому интерфейсу пользователя.
3.5. Специальные требования
4. Требования к программной документации
4.1. Предварительный состав программной документации
5. Технико-экономические показатели
5.1. Экономические преимущества разработки
6. Стадии и этапы разработки
6.1. Стадии разработки
6.2. Этапы разработки
6.3. Содержание работ по этапам
7. Порядок контроля и приемки
7.1. Виды испытаний
7.2. Общие требования к приемке работы


1. Введение

1.1. Наименование программы

Наименование программы: "Система диспетчеризации"

1.2. Назначение и область применения

Сбор, хранение и предоставление данных по диспетчеризации электроэнергии, воды, газа и сигнализация положения газового клапана.

2. Требования к программе

2.1. Требования к функциональным характеристикам

Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
1) Программа должна производить сбор данных показаний счетчиков электроэнергии, воды, газа и сигнализация положения газового клапана, наличие напряжения на вводном кабеле в автоматическом режиме, причем период опросов должен иметь переменный характер, т.е. для каждого конкретного объекта задаваться независимо. Также следует учесть возможность просмотра показаний в режиме реального времени, т.е. любой пользователь должен иметь возможность просмотреть данные на текущий момент времени.
2) Программа должна предусматривать автоматизированное хранение данных.
3) Программа должна предоставлять детализированные отчеты по требованию оператора и в заданный период. Также необходимо предусмотреть полнофункциональный поиск по базе данных исходя из всех имеющихся полей, т.е. поиск по любому из имеющихся ключевых слов (полей). Также следует учитывать параметр положения газового клапана и напряжение на вводном кабеле, и при необходимости извещения о каких-либо неполадках оператора.
4) Программа должна иметь хорошо структурированный справочник по объектам диспетчеризации.
5) Программа должна в полной мере соответствовать технологии «клиент-сервер», т.е. доступ к подсистемам программы, данным, отчетам и другим ресурсам должен предоставляться по требованию клиента, а сбор, хранение и обработка запросов пользователя должны производиться серверной частью.
6) Каждый пользователь программы в меру действующих на него ограничений должен иметь возможность удаленного доступа к отчетам по данным системы диспетчеризации для своего коттеджа через вэб-интерфейс. Предлагается использовать следующие группы: администратор, оператор архива, клиент. Администратор может управлять существующими пользователями, заносить новых пользователей в систему, редактировать настройки системы, просматривать и печатать все имеющиеся отчеты и создавать новые отчеты и печатные формы. Администратор должен иметь доступ к информации о функционировании всех модулей системы.
Оператор архива может просматривать и изменять справочную информацию о пользователе системы, просматривать и печатать отчеты по любому пользователю системы. Оператор архива должен получать сообщения об ошибках возникающих при съеме показаний со счетчиков. Так же должен иметь возможность заносить показания счетчиков и оплат жителей вручную, если такая необходимость возникнет.
Клиент после авторизации в системе должен получить доступ к просмотру информации относящейся непосредственно к его учетной записи. Может проверять правильность занесения показаний своих счетчиков и взаиморасчетов. Может просматривать и печатать отчеты только по своей учетной записи.
7) В программе необходимо предусмотреть возможность для проверки и тестирования любого элемента аппаратной части системы диспетчеризации.
8) Для удобства программа должна быть разделена на несколько модулей:
- настройка системы, установка параметров, управление пользователями,
- программа оператора,
- вэб-интерфейс,
- справочник по всем элементам системы, пользователям и объектам диспетчеризации,
- модуль тестирования и проверки связи между элементами сети диспетчеризации,
- модуль сбора информации,
- модуль хранения информации.
9) Организовать обмен данными между системой диспетчеризации и программой учета платежей ЖКХ. Используемая программа для учета платежей жителей создана на базе платформы «1С Предприятие 7.7».
10) Предусмотреть возможность расположения модулей программы как на одном физическом компьютере, так и на отдельных компьютерах соединенных между собой локальной сетью с обменом информацией по TCP/IP.

2.1.1. Описание интерфейса

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

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

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

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

Информация о клиентах
уникальный идентификационный номер;
имя доступа в систему;
пароль;
Ф.И.О.;
адрес места жительства;
лицевой счет;
контактные данные (номер телефона, электронный почтовый адрес);
показания счетчиков;
выставленные счета;
оплаты по счетам.

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

2.2.1 Требования к обеспечению надежного функционирования программы

Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
а) организацией бесперебойного питания технических средств;
б) использованием лицензионного программного обеспечения;
в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г.
Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления после отказа

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

2.2.3. Отказы из-за некорректных действий оператора

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

3. Условия эксплуатации

3.1. Климатические условия эксплуатации

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

3.2. Требования к квалификации и численности персонала

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

3.3. Требования к составу и параметрам технических средств

3.3.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:
3.3.1.1. процессор Pentium4 - 2.0GHz, не менее;
3.3.1.2. оперативную память объемом, 256 Мбайт, не менее;
3.3.1.3. свободного пространства на жестком диске, 10 Гигабайт, не менее;

3.4. Требования к информационной и программной совместимости

3.4.1. Требования к информационным структурам и методам решения

Для хранения данных использовать бесплатную СУБД, например Firebird.

3.4.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются, разработчик вправе выбирать любые инструменты для разработки программы, если они не противоречат чистоте лицензии ПО оговоренного в пункте 3.4.3.

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

Желательно использование программ и операционных систем со свободной лицензией.

3.4.4. Требования к защите информации и программ

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

3.4.5. Требования к графическому интерфейсу пользователя.

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

3.5. Специальные требования

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

4. Требования к программной документации

4.1. Предварительный состав программной документации

Состав программной документации должен включать в себя:
4.1.1. техническое задание;
4.1.2. программу и методики испытаний;
4.1.3. руководство оператора;

5. Технико-экономические показатели

5.1. Экономические преимущества разработки

Ориентировочная экономическая эффективность не рассчитываются.

6. Стадии и этапы разработки

6.1. Стадии разработки

Разработка должна быть проведена в три стадии:
1. разработка технического задания;
2. рабочее проектирование;
3. внедрение.

6.2. Этапы разработки

На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.
На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
1. разработка программы;
2. разработка программной документации;
3. испытания программы.
На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы

6.3. Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
1. постановка задачи;
2. определение и уточнение требований к техническим средствам;
3. определение требований к программе;
4. определение стадий, этапов и сроков разработки программы и документации на неё;
5. согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.
На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации.
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
1. разработка, согласование и утверждение и методики испытаний;
2. проведение приемо-сдаточных испытаний;
3. корректировка программы и программной документации по результатам испытаний.
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика.

7. Порядок контроля и приемки

7.1. Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки.
Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний.
Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

7.2. Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.






















































































































































































































Вам это будет интересно!

  • Отчет о прочитанном: прививки
  • Краткий отчет
  • Отчет о прибылях и убытках в ресторане 2
  • Q-ZAR 5 - Отчёт
  • Отчёт о культпоходе


  • Последние новости


    Шаг 5. Выбираем фирменное наименование организации

    Если вы собираетесь регистрировать новое юридическое лицо, то перед вами неизбежно встают необходимость выбора его названия и ряд сопутствующих вопросов. Следует ли проверять выбранное наименование организации на уникальность перед подачей документов на регистрацию? Можно ли зарегистрировать компанию с таким же наименованием, как и у другой, уже существующей орган...
    Читать далее »

    Шаг 4. Выбор системы налогообложения

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

    Аренда помещений

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

    Шаг 3. Выбираем место нахождения организации

    МЕСТО НАХОЖДЕНИЯ ОРГАНИЗАЦИИ, ЕЕ ЮРИДИЧЕСКИЙ, ФАКТИЧЕСКИЙ И ПОЧТОВЫЙ АДРЕСА В ГК РФ приведено понятие «место нахождения юридического лица» – так называемый юридический адрес, официально зарегистрированный в ЕГРЮЛ. Однако юридическое лицо может располагаться и по другому адресу – фактическому. В гражданском законодательстве не содержит...
    Читать далее »

    Карточка

    С образцами подписей и оттиска печати ...
    Читать далее »

    Форма

    Документа, подтверждающего наличие лицензии Приложение 26 СЕРТИФИКАТ СООТВЕТСТВИЯ ...
    Читать далее »

    Уведомление

    О регистрации юридического лица в территориальном органе Пенсионного фонда Российской Федерации по месту нахождения На территории Российской Федерации Приложение 22 Свидетельство О регистрации страхователя в территориальном фонде Обязательного медицинского страхования При обязательном мед...
    Читать далее »