АИС управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator

Командная оболочка

Каждому пользователю нужно предоставить способ взаимодействия с системой: передача ей команд и получение от нее ответов. Для этой цели служит специальная программа - командная оболочка (или интерпретатор командной строки). Она должна быть запущена для каждого пользователя, который зарегистрировался в системе. Поскольку в Linux доступно несколько разных интерпретаторов командной строки, в учетной записи указано, какой из них нужно запустить для данного пользователя. Если специально не указывать командную оболочку при создании учетной записи, она будет назначена по умолчанию, вероятнее всего это будет bash.

Интерпретатор командной строки (командный интерпретатор,командная оболочка, оболочка) - это программа, используемая в Linux для организации "диалога" человека и системы. Командный интерпретатор имеет три основных ипостаси:

редактор и анализатор команд в командной строке,

высокоуровневый системно-ориентированный язык программирования,

средство организации взаимодействия команд друг с другом и с системой.

Понятие "администратор"

В Linux есть только один пользователь, полномочия которого в системе принципиально отличаются от полномочий остальных пользователей - это пользователь с идентификатором "0". Обычно учетная запись пользователя с UID=0 называется root (англ., "корень"). Пользователь root - это "администратор" системы Linux, учетная запись для root обязательно присутствует в любой системе Linux, даже если в ней нет никаких других учетных записей. Пользователю с таким UID разрешено выполнять любые действия в системе, а значит, любая ошибка или неправильное действие может повредить систему, уничтожить данные и привести к другим печальным последствиям. Поэтому категорически не рекомендуется регистрироваться в системе под именем root для повседневной работы. Работать в root следует только тогда, когда это действительно необходимо: при настройке и обновлении системы или восстановлении после сбоев.

3.2 Описание протокола SMB

SMB, или иначе CIFS - это протокол, определяющий сетевую файловую систему, ее структуру и порядок использования. NetBIOS предоставляет интерфейс, через который SMB-сообщения передаются в сети, он используется серверами для "анонса" служб в сети, и клиентами для "обзора" этих служб. NetBIOS в качестве транспортного протокола может использовать любой низкоуровневый сетевой протокол, однако наиболее часто используется TCP/IP; когда NetBIOS работает поверх TCP/IP, это называется NBT. WINS предоставляет централизованные службы имен (отображение имен машин в IP-адреса) там, где это необходимо.

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

Управление сессиями. Создание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.

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

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

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

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

открыть и закрыть файл;

создание и удаление директорий;

чтение и запись в файл;

поиск файлов;

посылка на печать и отмена печати на принтере.

Все эти операции могут быть помещены в сообщение SMB и переданы к и от сервера. Название SMB происходит от названия формата данных v разновидности стандартных системных вызовов DOS к различным структурам данных или Server Message Blocks, адаптированная для передачи данных другому компьютеру по сети.

Формат SMB

Richard Shape из команды разработчиков Samba дал определение протоколу SMB как запрос-ответ. На практике это означает, что клиент посылает запрос SMB к серверу и сервер отвечает сообщением на этот запрос. Сервер редко формирует ответы, которые не относятся к клиенту.

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

Формат заголовка SMB

Таблица 3.1 показывает формат заголовка SMB. Команды SMB не обязательно должны заполнять все поля заголовка SMB. Например, когда клиент впервые пытается соединиться с сервером, то значение идентификатора дерева (TID) пусто v он появляется после успешного соединения и нулевое значение TID (0xFFFF) устанавливается в соответствующее поле заголовка. Другие поля могут также устанавливаться в ноль, когда не используются.

Значения полей заголовка SMB перечислены в Таблице 3.1.

Таблица 3.1 Поля заголовка SMB

Формат команды SMB

После того, как заголовок представлен определенным числом байт, происходит выполнение команды SMB. Любая команда, например такая, как открыть файл (ID поля COM: SMBopen ) или получить запрос на печать (SMBsplretq), имеет свой набор параметров и данные. Как и в поле заголовка SMB, здесь также могут быть заполнены не все командные поля, все зависит от команды. Например, команда GetServerAttributes (SMBdskattr) устанавливает поля WCT BCC в 0. Поля командных сегментов показаны в Таблице 3.2.

Таблица 3.2 - Содержание команды SMB

3.3 Описание протокола DNS

Служба Доменных Имен (Domain Name System) предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.

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

Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".

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

Очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко.

Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:

Клиент спрашивает своего сервера.

Если тот является сервером данной зоны, то ответит, на чем все заканчивается.

Сервер спрашивает корневой сервер.

Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".

Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".

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

Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.

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

Следует обратить внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран.

Политика и стратегия назначения имен

Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегистрированы следующие "организационные" зоны:

com - commercial (коммерческие);

edu - educational (образовательные);

gov - goverment (правительственные);

mil - military (военные);

net - network (организации, обеспечивающие работу сети);

org - organization (некоммерческие организации).

3.4 Протокол NFS

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

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

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

2. NFS-клиент посылает RFC-запросы на NFS-сервер через используемый транспортный протокол. Большей частью NFS работает по UDP, но последние реализации могут быть конфигурированы на установление соединений по TCP.

3. NFS-сервер принимает дейтаграммы с запросами NFS-клиента на свой UDP-порт 2049. Хотя, в принципе, NFS-сервер мог бы использовать эфемерный порт, объявляя его на регистраторе портов, в большинстве реализаций NFS зафиксирован стандартный порт 2049.

4. При поступлении запроса от NFS-клиента NFS-сервер транслирует его в запросы к своей местной файловой системе, которая и осуществляет соответствующие действия на диске хоста сервера.

5. Обработка запроса на сервере может занять значительное время, особенно если потребуется выполнить манипуляции в его файловой системе. Чтобы в период выполнения одного запроса не блокировать запросы от других NFS-клиентов, NFS-сервер должен обрабатывать их параллельно. Способ параллельной обработки зависит от возможностей конкретной операционной системы. Поскольку большинство реализаций Unix не поддерживают механизм нитей (multithreading), то обычно используемый искусственный прием состоит в следующем. Запросы от клиента на стороне сервера обрабатывает пользовательский процесс, называемый демоном. NFS (обычное его имя -- nf sd), который может сам себя копировать в некотором числе экземпляров. Эта простейшая программа посылает один не требующий ответа вызов в код встроенного в ядро NFS-сервера.

6. В свою очередь, и NFS-клиент, обслуживающий свой пользовательский процесс, вынужден, выслав RPC-запрос, в течение достаточно длительного времени ждать завершения его обработки на сервере до получения RPC-ответа. Поэтому и на клиентском хосте необходимо так или иначе обеспечить параллельное обслу­живание многих использующих NFS пользовательских процессов, что также ре­шается различными способами в зависимости от операционной системы. В Unix на хосте клиента NFS часто используется тот же прием, что и в случае сервера: создается новая копия пользовательского процесса, называемого здесь демоном блочного ввода-вывода (biod), который посылает один не требующий ответа вызов в код встроенного в ядро NFS-клиента.

Большинство хостов в Unix поддерживают либо NFS-клиента, либо NFS-сервера, либо обоих одновременно. Реализации NFS-клиентов существуют и для персональных компьютеров с операционными системами, например, от Microsoft. Мэйнфреймы, в частности фирмы IBM, часто выполняют роль только NFS-сервера.

В системе NFS на стороне сервера кроме программы, реализующей собственно сам протокол NFS, действуют еще и другие работающие поверх RPC программы, включая непременный для RPC регистратор портов.

Та или иная файловая система NFS-сервера становится доступной с машины NFS-клиента только после того, как будет на ней должным образом смонтирована. Для этого NFS-клиент обращается с соответствующим запросом к демону монтирования (mount daemon) NFS-сервера. Сам протокол монтирования в NFS будет рассмотрен ниже.

Менеджер блокировок (lock manager) и монитор состояний (status monitor) позволяют блокировать фрагменты файлов на сервере. Эти две программы необходимы как отдельные дополнения к протоколу NFS, поскольку для временной блокировки обращений к частям файла при их модификации необходимо, чтобы клиент и сервер могли из одного состояния переходить в другое. (Протоколом NFS не предусмотрено запоминание состояний на стороне сервера).

3.5 Выводы по разделу

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

4. Руководство пользователя

4.1 Руководство пользователя Webmin

Настройка Webmin для работы с серверными приложениями.

Программный комплекс запускается путем ввода в адресную строку https://<ip-сервера>:10000 (https, если с поддержкой SSL). После чего появится окно входа в систему. В открывшемся окне следует заполнить:

Логин (логическое имя) пользователя;

Пароль для входа в систему.

На рисунке 4.1 представлен внешний вид программного комплекса при входе в систему.

Рисунок 4.1 - Вход в систему

Если авторизация прошла успешно, открывается главное окно, содержащие сведения о системе и разделы.

Раздел Система (System) связан с общими настройками операционной системы. Здесь вы можете настраивать файловые системы, пользователей, группы и поведение системы при загрузке. Вы можете управлять сервисами, работающими в системе, и контролировать, запускаются ли они автоматически иконками Bootup и Shutdown. Настройка этих сервисов производится в разделе Servers. Особый интерес представляет утилита "Software Packages". Она позволяет легко просматривать пакеты, установленные на вашей системе, а также предоставляет интерфейсы доступа к репозиторию обновлений дистрибутива и к debfind.net, публичному DEB репозиторию в Internet.

В разделе Сервисы (Servers) размещены модули настройки различных сервисов, которые могут быть запущены на вашей системе. Очень удобны утилиты для настройки BIND и DHCP. Также очень просто пользоваться утилитой для настройки Samba -- файл- и принтсерверов для Windows и других клиентов. Webmin также избавит вас от проблем с настройкой SMTP сервера Sendmail, пользующегося дурной славой из-за сложного конфигурационного файла.

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

Раздел Оборудование (Hardware) предназначен для конфигурирвания физических устройств, в основном принтеров и устройств хранения. Утилита Logical Volume Management (LVM) особенно интересна, поскольку позволяет визуально управлять динамическими томами в вашей Linux системе.

Раздел Кластер (Cluster) содержит утилиты, которые вы можете использовать если вы кластеризуете систему. В данном контексте cluster -- это набор связанных систем, для которых необходимо синхронизировать их настройки. Системы могут синхронизировать пользователей, группы, пакеты и прочее с отслеживанием системных сбоев. Эти утилиты позволяют настраивать мощные отказоустойчивые системы, а также системы, для которых важна синхронизация. Кластеризация - это достаточно сложная тема, которая, возможно, потребует установки пакетов, не входящих в ваш дистрибутив.

Раздел Прочее (Others) содержит разнообразные утилиты, которые могут оказаться вам полезны. "SSH/Telnet Login" и "File Manager" реализованы в виде апплетов и не могут быть запущены, пока у браузера не установлено JRE. Утилита "Perl Modules" будет полезна для обслуживания модулей Perl, и позволяет напрямую подсоединяться к CPAN в интернете. "File Manager" обеспечивает доступ к файловой системе сервера с интерфейсом, похожим на Explorer, и позволяет перемещать и копировать файлы без перемещения их через память вашей рабочей станции (если вы работаете удаленно). "SSH/Telnet Login" - утилита, позволяющая вам получить доступ к консоли удаленной машины через ваш браузер.

На рисунке 4.2 представлен внешний вид программного комплекса после авторизации.

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

Модуль File Manager

Модуль File Manager находится в категории Прочее (Other). Он несколько отличается от большинства других модулей. Вместо предоставления возможности настройки серверов и служб, этот модуль позволяет пользователям просматривать и управлять файлами на сервере при помощи файлового менеджера. Интерфейс похож на старый explorer в Windows: слева - дерево каталогов, а справа - содержимое текущей папки, сверху - кнопки и панель инструментов.

Пользователи и группы

В Webmin, модуль The Users and Groups (Пользователи и группы), который находится в категории System (Система), может быть использован для создания, редактирования и удаления UNIX пользователей и групп в системе..

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

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

Модуль System and Server Status

Этот модуль позволяет отслеживать состояния выбранных серверов и запущенных демонов. С его помощью можно легко определить какие процессы выполняются должным образом или выявить те процессы, работа которых нарушена. Также можно сконфигурировать модуль таким образом, что при проверке состояния сервера происходила отправка сообщения по e-mail или выполнялась какая-либо команда. Эта функция может быть полезна если система управляет серверами, от которых зависят другие люди, такими как web или DNS сервера.

Внешний вид модуля System and Server Status представлен на рисунке 4.4.

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

Установка нового модуля представлена на рисунке 4.5.

4.2 Создание первичного контроллера домена в Webmin

Первичный контроллер домена хранит у себя БД пользователей домена, их пароли, права доступа и прочую информацию. Это позволяет им авторизовавшись один раз посещать все сетевые ресурсы домена без ввода пароля. PDC позволяет применять так называемые logon scripts - текстовые файлы хранящиеся на сервере, в которых содержатся команды, которые будут выполнены на машине клиента при входе в домен. С их помощью можно проводить автоматическое монтирование сетевых дисков, синхронизацию часов, запуск других программ и так далее. На PDC можно настроить перемещаемые профили (roaming profiles). Они используются для хранения windows профиля пользователя (рабочий стол, меню пуск, оформление и пр.) на сервере. Т.е. пользователь, залогинившись с любого компьютера в сети будет работать в своем настроенном рабочем окружении. Конечно такая возможность предполагает наличие быстрого сетевого соединения и наличия достаточного свободного место на диске сервера. Ну и напоследок тот момент что пользователь он на то и пользователь чтобы пользоваться, администрировать он ничего не сможет (пока конечно вы не дадите ему таких прав), следовательно и исправлять будет нечего - это также немаловажный аргумент перехода на PDC.

Настройка первичного контроллера домена процесс трудоёмкий. Применения для этих целей программного комплекса позволит сократить время и облегчит работу администратора, позволив работать не напрямую правив smb. conf, а работая в удобном интерфейсе.

Внешний вид менеджера ресурсов Samba представлен на рисунке 4.6. Модуль включает в себя:

Настройки безопасности;

Настройки сети Unix и Windows;

Параметры вывода на печать;

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

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

Внешний вид правки конфига представлен на рисунке 4.10.

4.3 Руководство пользователя Alterator

На рисунке 4.11 представлен внешний вид конфигуратора Alterator.

Рисунок 4.11 Интерфейс Alterator

4.4 Выводы по четвертому разделу

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

5. Экономическое обоснование проекта

Целью данного раздела является доказательство экономической целесообразности создания автоматизированной информационной системы управления программным обеспечением серверного оборудования на базе программного комплекса Webmin/Alterator.

5.1 Цель и краткое описание программного продукта

Наименование программного продукта: АИС управления серверным программным обеспечением.

Целью является внедрение для Министерства промышленной политики, транспорта и связи Омской области программного комплекса Webmin, позволяющего решить следующие задачи:

производить мониторинг процессов, запускать, останавливать и перезапускать процессы;

осуществлять полноправную навигацию по файловой системе, выполнять любые операции с файлами и каталогами;

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

При разработке системы использовался программный комплекс Webmin, который является открытым программным обеспечением, распространяемый по лицензии GPU.

5.2 Определение затрат труда на разработку программного продукта

Трудоемкость выполнения отдельных видов работ определяется двумя видами оценок:

- минимальные затраты времени на выполнение отдельного вида работ;

- максимальное время выполнения при наименее благоприятных условиях.

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

Ожидаемое значение трудоемкости рассчитывается по формуле:

,

где i - номер этапа.

Стандартное отклонение оценивается по следующей формуле:

,

где i - номер этапа.

Экспертные оценки и расчетные величины трудоемкости, а также стандартные отклонения по всем видам работ приведены в таблице5.1.

Таблица 5.1- Оценка трудоемкости отдельных по всем видам работ

Общая трудоемкость работы составляет 880 человеко-часов или 5 месяцев (по 22 рабочих дня в каждом месяце). Стандартное отклонение составляет менее 5 %, то есть степень достоверности того, что работа будет выполнена в срок, велика.

5.3 Определение численности исполнителей

Период разработки программы - 5 месяцев, с 1 января по 1 июня 2010 года.

Количество рабочих дней в каждом месяце равно 22. Рабочий день равен 8 часам. Отсюда получаем действительный фонд времени за период разработки программы:

ч.

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

Таким образом, получаем:

чел.

Отсюда следует, что разработчиком будет являться один исполнитель - техник.

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

Таблица 5.2 - Распределение трудоемкости по стадиям разработки

5.4 Расчет себестоимости разработки программного продукта

Расчет основной заработной платы

Основная заработная плата рассчитывается, исходя из трудоемкости работ, выполняемых специалистом i-й квалификации при разработке программного продукта () в чел/ч и размера оплаты труда 1 чел/ч.

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

,

где

- основная заработная плата разработчика, руб.;

- оклад техника, руб.;

- общая трудоемкость работ, ч.

Оклад сотрудника отдела информационных систем - 10000 руб./мес.

Трудоемкость техника - 880 ч.

Таким образом, основная заработная плата разработчика, при районном коэффициенте 1,15, применяемом к окладу работников, проживающих в городе Омске и среднем количестве рабочих часов в месяц равном 176 следующая:

руб.

Расчет дополнительной заработной платы

Дополнительная заработная плата в среднем составляет 12% от основной заработной платы.

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

руб.

Расчет отчислений на социальные нужды

Сумма отчислений на социальные нужды составляет 26% от суммы основной и дополнительной заработной платы.

Отчисления на социальные нужды составят:

руб.

Расчет расходов по отладке программного продукта

Расходы по отладке определяются, исходя из планируемых затрат машинного времени, необходимого для разработки и оформления программного продукта (Тм.в), и стоимости одного машино-часа работы ЭВМ, на которой ведется разработка (См.ч.):

Cотл = См.ч. * Тм.в ,

Стоимость одного машино-часа определяется по формуле:

См.ч. = Сэ / Фвт Кз,

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

Ф - годовой плановый фонд времени работы вычислительного комплекса, ч.;

Кз -коэффициент загрузки (не более 0,9-0,95).

Рассчитаем годовой плановый фонд времени:

Фвт = Фном - Фпроф,

где Ф - номинальный фонд времени работы вычислительного комплекса, ч.

Ф = 12*22*8 = 2112 ч.

Фпроф - годовые затраты времени на профилактические работы (принимаются 15 % от Ф),

Фпроф = 0,15*2112=316,8 ч.

Ф = 2112 - 316,8 = 1795,2 ч.

Рассчитаем годовые расходы:

Сэ = Сосн з/п+ Сдоп з/п + Сотч+ Сам + Срем + См + Сэл;

Основная заработная плата сотрудника, проводящего профилактические работы ЭВМ, составляет:

Сосн з/п = руб.

Дополнительная заработная плата сотрудника, проводящего профилактические работы ЭВМ, составляет:

Сдоп з/п = Сосн з/п * 12 % = 10350 * 0,12 = 1242 руб.

Сотч =0,26 * (Сосн з/п + Сдоп з/п) = 0,26 * (10350+1242) = 3013,92 руб.

Затраты на амортизацию определяются как сумма затрат на амортизацию ЭВМ и амортизацию ПО.

Сам = Апо + Аэвм

Затраты на амортизацию ЭВМ:

Cк = 25000 рублей - стоимость компьютера за одно рабочее место;

Максимальный срок полезного использования ЭВМ составляет 3 года.

Аэвм = = руб.

Затраты на амортизацию ПО:

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

Сам = 8333,33+0=8333,33 руб.

Затраты на ремонт и содержание оборудования составят 3% от стоимости ЭВМ:

Срем = Ск * 0,03 = 25000 * 0,03 = 750 руб.

Затраты на расходные материалы составят 1% от стоимости ЭВМ:

См = 0,01 * 25000 = 250 руб.

Расходы на электроэнергию составят:

Cэл = Фном * W * S, где

W = 0,45 кВтч - мощность, которую потребляет компьютер;

S = 2,28 руб. - стоимость 1 кВт/ч энергии.

Cэл = 2112* 0,45*2,28=2166,91 руб.

Тогда годовые расходы составят:

Сэ = 10350+1242+3013,92+8333,33+750+250+2166,91=26106,17 руб.

Отсюда стоимость одного машино-часа работы ЭВМ:

См.ч. = руб./ч.

Машинное время в часах Тмв:

Тмв = 880 ч.;

Стоимость отладки:

Сотл. = 880*16,16=14219,04 руб.

Расчет накладных расходов

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

Снакл = Сосн 0,6 = 57500*1,2=34500 руб.

Себестоимость разработки

Себестоимость разработки программного продукта приведена в таблице 5.3.

Таблица 5.3- Себестоимость разработки программного продукта

Таким образом, себестоимость разработки программного продукта составляет 129 863,04 руб.

5.5 Расчет экономической эффективности внедрения продукта

Исходные данные для расчета годового экономического эффекта представлены в таблице 5. 4.

Таблица 5.4 - Исходные данные для расчета экономического эффекта

Для оценки эффективности проекта будут использоваться следующие показатели:

Прирост производительности труда;

Сравнительная экономия численности работников;

Годовая экономия по фонду заработной платы;

Годовая экономия по сборам на социальные нужды;

Годовой экономический эффект;

Фактический срок окупаемости.

Вычисления по показателям:

Определим прирост производительности труда:

Определим сравнительную экономию численности работников:

чел.

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

Найдем годовую экономию по отчислениям на социальные нужды:

Годовой экономический эффект составит:

Рассчитаем фактический срок окупаемости затрат:

1 год.

5.6 Вывод по разделу

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

В результате расчетов определена трудоемкость разработки программного продукта, которая составила 880 чел/ч., для выполнения данной разработки необходим 1 исполнитель. Сумма затрат на разработку программного продукта составляет 129 863,04 руб.

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

6. Безопасность жизнедеятельности

Заключение

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

Результатом дипломного проектирования является разработанная система управления серверным программным обеспечением на базе программного комплекса Webmin/Alterator включающая в себя создание

первичного контроллера домена на базе программного комплекса Webmin;

почтового сервера на базе конфигуратора Alterator.

Разработанная система, включающая в себя практические разработки, позволяет:

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

повысить оперативность и объективность в работе с серверным программным обеспечением;

автоматизировать рутинные функции управления серверным программным обеспечением;

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

Список использованных источников

1. Стихановская Л.М., Семенова И.И. Методические указания по оформлению текстовых документов при выполнении дипломных, курсовых работ, отчетов и рефератов студентами факультета "информационные системы в управлении" - Омск: Изд-во СИБАДИ, 2010. - 35 с.

2. Осипов В.Г. Итоговая аттестация специалиста АСОИУ. Методические указания для студентов специальности 230102 «Автоматизированные системы обработки информации и управления» / В.Г. Осипов. - Омск: СибАДИ, 2008. - 27с.

3. Фролов А., Фролов Г. Практика применения PERL, PHP, APACHE и MySQL для активных WEB-сайтов. - Москва: Русская редакция, 2002. - 534 с.

4. Ричард Петерсен. LINUX: руководство по операционной системе. - Киев: BHV, 1998. - 1000 с.

5. Андрей Робачевский. Операционная система UNIX. - Спб: BHV-Санкт-Петербург,1997. - 500 с. Бедрина Е.А. Методические указания по выполнению раздела «Безопасность жизнедеятельности» в дипломных проектах выпускников СибАДИ всех специальностей факультета «Информационные системы в управлении» - Омск: СибАДИ, 2007. - 12 с.

6. СанПиН 2.2.2./2.41340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организации работы.

7. СанПиН 2.2.4.548-96. Гигиенические требования к микроклимату производственных помещений.

8. ГОСТ 12.2.032-78 ССБТ. Рабочее место при выполнении работ сидя. Общие эргономические требования.

9. Девисилов В, Ильницкая А., Белов С. Безопасность жизнидеятельности - Высшая школа, 2009 г. - 616 с.

10. Кукин П. П., Лапин В. Л. , Пономарев Н. Л. , Сердюк Н. И. Безопасность жизнедеятельности. Безопасность технологических процессов и производств. Охрана труда - Высшая школа, 2007 г. - 336 с.

11. СанНиП 41-01-03. Отопление, вентиляция и кондиционирование.

12. ГОСТ 12.0.003 -- 74 ССБТ. Опасные и вредные производственные факторы. Классификация.

13. ГОСТ 12.1.038-82 ЭЛЕКТРОБЕЗОПАСНОСТЬ . Предельно допустимые значения напряжений прикосновения и токов.

14. СанПиН 2.2.4.1294-03.Санитарно-гигиенические нормы допустимых уровней ионизации воздуха.

15. СанПиН 2.2.4.1191-03. Электромагнитные поля в производственных условиях.

16. ГОСТ 12.4.154--85. ССБТ. Устройства экранирующие для защиты от электрических полей промышленной частоты. Общие технические требования, основные параметры и размеры.

17. ГОСТ Р 50571.3-94. Требования по обеспечению безопасности. Защита от поражения электрическим током.

18. ГОСТ Р 50571.21-2000 Заземляющие устройства и системы уравнивания электрических потенциалов в электроустановках, содержащих оборудование обработки информации.

19. ГОСТ 12.0.003-74 (1999). ССБТ. Опасные и вредные производственные факторы. Классификации.

20. ГОСТ 12.1.002-84 (1999). ССБТ. Электрические поля промышленной частоты. Допустимые уровни напряженности и требования к проведению контроля на рабочих местах.

21. ГОСТ 12.1.004-91 ССБТ. Пожарная безопасность. Общие требования.

22. ГОСТ 12.2.2006-05. Безопасность аппаратуры электронной сетевой и сходных с ней устройств, предназначенных для бытового и аналогичного общего применения.

23. Колисниченко Д.Н. Linux-сервер своими руками. - Наука и техника, 2008 .- 624 с.

24. Таненбаум Э. Компьютерные сети. - Питер, 2007.- 992 с.

25. Samba - первичный контроллер домена [Электрон. ресурс] http://domaintimes.net/forum/showthread.php?t=3015

26. Документация сообщества к программному комплексу Nagios [Электрон. ресурс] http://wiki.nagios.org/index.php/Main_Page

Приложение А

Листинг файла smb.conf

# This is the main Samba configuration file. You should read the

# smb.conf(5) manual page in order to understand the options listed

# here. Samba has a huge number of configurable options (perhaps too

# many!) most of which are not shown in this example

#

# Any line which starts with a ; (semi-colon) or a # (hash)

# is a comment and is ignored. In this example we will use a #

# for commentry and a ; for parts of the config file that you

# may wish to enable

#

# NOTE: Whenever you modify this file you should run the command "testparm"

# to check that you have not made any basic syntactic errors.

#

#======================= Global Settings =====================================

[global]

# workgroup = Make sure it matches YOUR OWN NT-Domain-Name or Workgroup-Name

workgroup = workgroup

# server string is the equivalent of the NT Description field

server string = Samba Server

# This option is important for security. It allows you to restrict

# connections to machines which are on your local network. The

# following example restricts access to two C class networks and

# the "loopback" interface. For more examples of the syntax see

# the smb.conf man page

; hosts allow = 192.168.1. 192.168.2. 127.

# if you want to automatically load your printer list rather

# than setting them up individually then you'll need this

printcap name = /etc/printcap

load printers = yes

# It should not be necessary to spell out the print system type unless

# yours is non-standard. Currently supported print systems include:

# bsd, sysv, plp, lprng, aix, hpux, qnx

; printing = bsd

# Uncomment this if you want a guest account, you must add this to /etc/passwd

# otherwise the user "nobody" is used

; guest account = pcguest

# this tells Samba to use a separate log file for each machine

# that connects

log file = /var/log/samba/%m.log

# all log information in one file

# log file = /var/log/samba/smbd.log

# Put a capping on the size of the log files (in Kb).

max log size = 50

# Security mode. Most people will want user level security. See

# security_level.txt for details.

# Use password server option only with security = server

; password server = <NT-Server-Name>

# Password Level allows matching of _n_ characters of the password for

# all combinations of upper and lower case.

; password level = 8

; username level = 8

# You may wish to use password encryption. Please read

# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.

# Do not enable this option unless you have read those documents

; encrypt passwords = yes

; smb passwd file = /etc/samba/smbpasswd

# The following are needed to allow password changing from Windows to

# update the Linux system password also.

# NOTE: Use these with 'encrypt passwords' and 'smb passwd file' above.

# NOTE2: You do NOT need these to allow workstations to change only

# the encrypted SMB passwords. They allow the Unix password

# to be kept in sync with the SMB password.

; unix password sync = Yes

; passwd program = /usr/bin/passwd %u

; passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*

# Unix users can map to different SMB User names

; username map = /etc/samba/smbusers

# Using the following line enables you to customise your configuration

# on a per machine basis. The %m gets replaced with the netbios name

# of the machine that is connecting

; include = /etc/samba/smb.conf.%m

# Most people will find that this option gives better performance.

# See speed.txt and the manual pages for details

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

# Configure Samba to use multiple interfaces

# If you have multiple network interfaces then you must list them

# here. See the man page for details.

; interfaces = 192.168.12.2/24 192.168.13.2/24

# Configure remote browse list synchronisation here

# request announcement to, or browse list sync from:

#a specific host or from / to a whole subnet (see below)

; remote browse sync = 192.168.3.25 192.168.5.255

# Cause this host to announce itself to local subnets here

; remote announce = 192.168.1.255 192.168.2.44

# Browser Control Options:

# set local master to no if you don't want Samba to become a master

# browser on your network. Otherwise the normal election rules apply

; local master = no

# OS Level determines the precedence of this server in master browser

# elections. The default value should be reasonable

; os level = 33

# Domain Master specifies Samba to be the Domain Master Browser. This

# allows Samba to collate browse lists between subnets. Don't use this

# if you already have a Windows NT domain controller doing this job

; domain master = yes

# Preferred Master causes Samba to force a local browser election on startup

# and gives it a slightly higher chance of winning the election

; preferred master = yes

# Enable this if you want Samba to be a domain logon server for

# Windows95 workstations.

; domain logons = yes

# if you enable domain logons then you may want a per-machine or

# per user logon script

# run a specific logon batch file per workstation (machine)

; logon script = %m.bat

# run a specific logon batch file per username

; logon script = %U.bat

# Where to store roving profiles (only for Win95 and WinNT)

# %L substitutes for this servers netbios name, %U is username

# You must uncomment the [Profiles] share below

; logon path = \\%L\Profiles\%U

# All NetBIOS names must be resolved to IP Addresses

# 'Name Resolve Order' allows the named resolution mechanism to be specified

# the default order is "host lmhosts wins bcast". "host" means use the unix

# system gethostbyname() function call that will use either /etc/hosts OR

# DNS or NIS depending on the settings of /etc/host.config, /etc/nsswitch.conf

# and the /etc/resolv.conf file. "host" therefore is system configuration

# dependant. This parameter is most often of use to prevent DNS lookups

# in order to resolve NetBIOS names to IP Addresses. Use with care!

# The example below excludes use of name resolution for machines that are NOT

# on the local network segment

# - OR - are not deliberately to be known via lmhosts or via WINS.

; name resolve order = wins lmhosts bcast

# Windows Internet Name Serving Support Section:

# WINS Support - Tells the NMBD component of Samba to enable it's WINS Server

; wins support = yes

# WINS Server - Tells the NMBD components of Samba to be a WINS Client

#Note: Samba can be either a WINS Server, or a WINS Client, but NOT both

; wins server = w.x.y.z

# WINS Proxy - Tells Samba to answer name resolution queries on

# behalf of a non WINS capable client, for this to work there must be

# at least oneWINS Server on the network. The default is NO.

; wins proxy = yes

# DNS Proxy - tells Samba whether or not to try to resolve NetBIOS names

# via DNS nslookups. The built-in default for versions 1.9.17 is yes,

# this has been changed in version 1.9.18 to no.

dns proxy = no

# Case Preservation can be handy - system default is _no_

# NOTE: These can be set on a per share basis

; preserve case = no

; short preserve case = no

# Default case is normally upper case for all DOS files

; default case = lower

# Be very careful with case sensitivity - it can break things!

; case sensitive = no

#============================ Share Definitions ==============================

idmap uid = 16777216-33554431

idmap gid = 16777216-33554431

template shell = /bin/false

username map = /etc/samba/smbusers

winbind use default domain = no

[homes]

comment = Home Directories

browseable = no

writeable = yes

# Un-comment the following and create the netlogon directory for Domain Logons

; [netlogon]

; comment = Network Logon Service

; path = /home/netlogon

; guest ok = yes

; writable = no

; share modes = no

# Un-comment the following to provide a specific roving profile share

# the default is to use the user's home directory

;[Profiles]

; path = /home/profiles

; browseable = no

; guest ok = yes

# NOTE: If you have a BSD-style print system there is no need to

# specifically define each individual printer

[printers]

comment = All Printers

path = /var/spool/samba

browseable = no

# Set public = yes to allow user 'guest account' to print

printable = yes

# This one is useful for people to share files

;[tmp]

; comment = Temporary file space

; path = /tmp

; read only = no

; public = yes

# A publicly accessible directory, but read only, except for people in

# the "staff" group

;[public]

; comment = Public Stuff

; path = /home/samba

; public = yes

; read only = yes

; write list = @staff

# Other examples.

#

# A private printer, usable only by fred. Spool data will be placed in fred's

# home directory. Note that fred must have write access to the spool directory,

# wherever it is.

;[fredsprn]

; comment = Fred's Printer

; valid users = fred

; path = /homes/fred

; printer = freds_printer

; public = no

; writable = no

; printable = yes

# A private directory, usable only by fred. Note that fred requires write

# access to the directory.

;[fredsdir]

; comment = Fred's Service

; path = /usr/somewhere/private

; valid users = fred

; public = no

; writable = yes

; printable = no

# a service which has a different directory for each machine that connects

# this allows you to tailor configurations to incoming machines. You could

# also use the %u option to tailor it by user name.

# The %m gets replaced with the machine name that is connecting.

;[pchome]

; comment = PC Directories

; path = /usr/pc/%m

; public = no

; writable = yes

# A publicly accessible directory, read/write to all users. Note that all files

# created in the directory by users will be owned by the default user, so

# any user with access can delete any other user's files. Obviously this

# directory must be writable by the default user. Another user could of course

# be specified, in which case all files would be owned by that user instead.

;[public]

; path = /usr/somewhere/else/public

; public = yes

; only guest = yes

; writable = yes

; printable = no

# The following two entries demonstrate how to share a directory so that two

# users can place files there that will be owned by the specific users. In this

# setup, the directory should be writable by both users and should have the

# sticky bit set on it to prevent abuse. Obviously this could be extended to

# as many users as required.

;[myshare]

; comment = Mary's and Fred's stuff

; path = /usr/somewhere/shared

; valid users = mary fred

; public = no

; writable = yes

; printable = no

; create mask = 0765

Страницы: 1, 2