97427

Нормы трудового законодательства, регулирующие режим времени работника

Дипломная

Государство и право, юриспруденция и процессуальное право

Целью выпускной квалификационной работы является исследование норм Трудового законодательства регулирующих режим времени работника. Задачами выпускной квалификационной работы являются: изучить понятие и функции рабочего времени по трудовому законодательству РФ; определить виды рабочего времени; исследовать особенности режима рабочего времени и учета рабочего времени.

Русский

2015-10-18

480.81 KB

1 чел.

Инв. № подп

Подп. и дата

Взам. инв. №

Инв. № дубл.

Подп. и дата

Лист

2

ДП.230401.ПМ.01.МДК.02.03

Лит

№ докум.

Изм.

Подп.

Дата

Инв. № подп

Подп. и дата

Взам. инв. №

Инв. № дубл.

Подп. и дата

Лист

2

ДП.230401.ПМ.01.МДК.02.03

Лит

№ докум.

Изм.

Подп.

Дата

Оглавление

Введение 4

Раздел 1. Отечественные и зарубежные технологии проектирования автоматизированных систем. 9

О видах стандартов 9

Рассматриваемые стандарты 10

Методика Oracle CDM 11

Международный стандарт ISO/IEC 12207: 1995-08-01 14

Стандарты комплекса ГОСТ34 21

Соотнесение процессов ISO12207 и соответствующих компонентов ГОСТ34 и CDM 29

Основные процессы 30

ИТОГИ 32

Обследование объекта и обоснование необходимости создания АИС. 34

Разработка технического задания на АИС. 34

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

Назначение и цели создания АИС 35

Характеристика информационной системы для учета рабочего времени. 36

Требования к ИС 37

Требования к видам обеспечения АИС: 38

Состав и содержание работ по созданию системы 38

Разработка концептуальной схемы базы данных и базы данных АИС. 39

Введение

Цель выпускной квалификационной работы:

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

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

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

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

- исследовать особенности режима рабочего времени и учета рабочего времени.

        Цель АИС:

При построении и эксплуатации АИС учитываются следующие основные категории, отображаемые как системообразующие признаки АИС: цели, задачи, функции системы, структура, технология создания и функционирования АИС, исходные условия функционирования системы, факторы, влияющие на уровень качества и эффективность АИС и др. Определение системообразующих признаков, в данном случае целей АИС, выполняется на основе анализа их содержания и формы проявления. Изучение содержания проводится путем выявления свойств АИС. Один из способов идентификации свойств — классификация. Группировка проводится по основаниям (признакам) деления. В результате деления получаются классы (группы) АИС — носители свойств универсального или специфического характера. С учетом этих свойств можно проводить анализ и синтез соответствующих элементов АИС. Обычно группировка и выбор оснований деления выбираются в соответствии с характером решаемых задач. При решении практических задач целесообразно учитывать наиболее существенные свойства рассматриваемых систем. Определение цели проведем с учетом рассмотренных в первой главе понятий АИС и ее выделенных характеристик. При формулировании цели обычно исходят из условия предвосхищения результата функционирования какой-либо системы. Цель воспринимается как ожидаемый результат функционирования системы, который определяется над системой. Главным результатом функционирования АИС должны быть выдача и предоставление операторам управления информации, которая им нужна в процессе их деятельности для решения экономических задач. Цель АИС — обеспечение специалистов информацией для решения экономических задач. Одна из форм результата — информационная продукция и услуги, предоставляемые потребителям. Кроме того, результатом работы ИС должно быть требуемое качество информационной продукции. Отсюда цель АИС — это также и повышение уровня качества информации, выдаваемой специалистам — пользователям АИС. При решении практических задач следует учитывать, что определение цели может быть выполнено путем анализа, так называемого дерева целей. Оно представляет собой иерархическую систему целей в виде классификации целей относительно управляемой ИС, ее продукции и услуг так, например, на первом уровне иерархии целей АИС могут быть расположены следующие фазы ее жизненного цикла: создание, функционирование. На втором уровне иерархии, в частности стадии «функционирование АИС», можно выделить эффективность технологического процесса обработки информации, качество выходной (результатной) информации и др. На третьем уровне иерархии, например в категории «эффективность технологического процесса», можно выделить качество подготовки документов, качество индексирования документов, качество ввода документов в ЭВМ, качество обработки данных и др. Указанные категории могут быть дифференцированы на подцели.

Задачи создания АИС:

Существует два основных класса задач: основные и универсальные. В соответствии с целью основными универсальными задачами АИС представляются:

  1.  Выполнение процессов преобразования информации и выдача ее в удобном для восприятия виде;
  2.  Экономия ресурсов при выполнении процессов в преобразования информации;
  3.  Развитие социального статуса работников, занятых в контуре функционирования АИС.


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

  1.  Обеспечение необходимого объема производства продукции;
  2.  Обеспечение ритмичности в производстве продукции или услуг предприятия;
  3.  Проведение мероприятий по обеспечению заданного уровня качества продукции;
  4.  Проведение технико-экономического анализа;
  5.  Выполнение материально-технического снабжения предприятия;
  6.  Обеспечение маркетинговой деятельности предприятия;
  7.  Обеспечение организационно-технических мероприятий по развитию предприятия и др.

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

О видах стандартов 

После конференции АПО/ROUG97 (Таруса, июнь 1997), где автор сделал доклад "ISO/IEC 12207, ГОСТ34, Oracle CDM - процессы, результаты, соотнесение", обнаружилось, что:

а) интерес к теме есть и у отдельных людей, и у коллективов;

б) конструктивно говорить на эту тему можно только после выяснения и принятия говорящими более-менее одинакового понимания того, что такое стандарт и какие они бывают.

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

  1.  по предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);
  2.  по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например, ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT Д. Росса), фирменные стандарты (Microsoft ODBC, IBM SNA);
  3.  по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель".

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

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

Рассматриваемые стандарты

Далее будем рассматривать следующие стандарты и методики, касающиеся ЖЦ АС и ПО:

  1.  Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, расчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.
  2.  Стандарты комплекса ГОСТ 34 на создание и развитие АС - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Кроме того, эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости. Насколько это так, а насколько ГОСТ 34 остается работающим с пользой - полезно разобраться.
  3.  Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения (ПО) - казалось бы весьма неконкретный, но вполне новый и отчасти "модный" стандарт.

Методика Oracle CDM

  1.  Возникла как развитие разработанной давно версии Oracle CASE-Method, известной по использованию Oracle CASE (ныне Designer/2000) и книгам Р. Баркера. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения (см. описание CDM) о простом приспособлении CDM к проектам, в которых используется другой инструментальный комплекс.

2) Общая структура.

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

2.2. Этапы:

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

2.3. Процессы:

  1.  RD - Определение производственных требований,
  2.  ES - Исследование существующих систем,
  3.  TA - Определение технической архитектуры,
  4.  DB - Проектирование и построение БД,
  5.  MD - Проектирование и реализация модулей,
  6.  CV - Конвертирование данных,
  7.  DO - Документирование,
  8.  TE - Тестирование,
  9.  TR - Обучение,
  10.  TS - Переход к новой системе,
  11.  PS - Поддержка и сопровождение.

2.4. Процессы состоят из последовательностей задач, задачи разных процессов взаимосвязаны явно указанными ссылками. CDM наиболее сильно связан с методикой "Oracle PJM" по организации управления проектом.

3) Особенности.

3.1. Степень адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track), еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle, "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.

Методика не предусматривает: включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным; дополнительное удаление задачи (и порождаемых ею документов), не предусмотренное одной из трех моделей ЖЦ; изменение последовательности выполнения задач по сравнению с предложенной, тем более - по ходу процесса проектирования.

3.2. Все модели ЖЦ АС и ПП являются по сути каскадными; даже "облегченный подход", несмотря на понятную инерционность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.

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

3.4. Прикладная система рассматривается в основном как программно-техническая система - например, моменты организации выполнения вполне возможных оргструктурных преобразований, реально всегда происходящих при переходе к новой АС (вовсе не имеется в виду BPR!), и соответствующего обеспечения отсутствуют в этой методике. Другой фактической ориентацией методики является ее (исторически понятная) направленность на создание Информационной Системы с Базами Данных в достаточно традиционном понимании.

Международный стандарт ISO/IEC 12207: 1995-08-01

1) Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1"Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важное ЗАМЕЧАНИЕ СТАНДАРТА: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми вовремя ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)

ОПРЕДЕЛЕНИЕ СТАНДАРТА: 

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

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

2) Общая структура.

2.1. Процессы ЖЦ. По сравнению с CDM стандарт ISO состоит из гораздо более крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п. Грубо говоря, один такой процесс сравним со всеми процессами CDM вместе взятыми.

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

2.1.1. Описаны 5 основных процессов ЖЦ ПО:

1. Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО.

2. Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.

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

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

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

2.1.2. Описаны 8 вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО. Вспомогательные процессы это процессы - решения проблем, документирования, управления конфигурацией, гарантирования качества, последний из которых использует результаты остальных процессов группы обеспечения качества, в которую входят: Процесс верификации, Процесс аттестации, Процесс совместной оценки, Процесс аудита.

2.1.3. Описаны 4 организационных процесса: Процесс управления, Процесс создания инфраструктуры, Процесс усовершенствования, Процесс обучения.

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

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

2.2. Каких - либо этапов, фаз, стадий не предусмотрено, что дает описываемую ниже степень адаптивности.

3) Особенности.

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

Примеры:

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

Такой характер позволяет реализовывать любую модель ЖЦ.

ОПРЕДЕЛЕНИЕ СТАНДАРТА: Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.

3.2. Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.

ЗАМЕЧАНИЕ СТАНДАРТА: Добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Контракт понимается в широком смысле: от юридически оформленного контракта до неформального соглашения, соглашение может быть определено и единственной стороной как задача, поставленная самому себе.

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

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

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

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

При этом разработчик должен установить и документировать как требования к программному обеспечению:

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

б) внешние связи (интерфейсы) с единицей программного обеспечения;

в) требования квалификации;

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

д) спецификации защищенности, включая спецификации, связанные с компрометированные точности информации;

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

ж) определение данных и требований базы данных;

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

и) документация пользователя;

к) работа пользователя и требования выполнения;

л) требования сервиса пользователя.

(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ34 по видам обеспечения системы.)

ОПРЕДЕЛЕНИЕ СТАНДАРТА: 

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

Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.

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

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

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

3.6. Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД**), но и не использовать БД вовсе.

Стандарты комплекса ГОСТ34

1) ГОСТ34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в "Особенностях" ГОСТ34. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.

Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). Однако формулировки ГОСТ34 не ориентированы на столь явное и, в известном смысле, симметричное отражение действий обеих сторон, как ISO12207. Поскольку ГОСТ34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается отталкиваясь от этого содержания.

2) Общая структура.

2.1) Из всех существующих и не реализованных групп документов будем основываться только на Группе 0 "Общие положения" и Группе 6 "Создание, функционирование и развитие АС". Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.

2.2) Для общего случая разработки АС стадии и этапы ГОСТ34 приведены в таблице:

Таблица 1. Стадии и этапы разработки АС.

1. ФТ - Формирование требований к АС.

1.1. Обследование объекта и обоснование необходимости создания АС; 
1.2. Формирование требований пользователя к АС; 
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания);

2. РК - Разработка концепции АС.

2.1. Изучение объекта; 
2.2. Проведение необходимых научно-исследовательских работ; 
2.3. Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя 
2.4. Оформление отчета о выполненной работе;

3. ТЗ - Техническое создание АС.

3.1. Разработка и утверждение технического задания на задание.

4. ЭП - Эскизный проект.

4.1. Разработка предварительных проектных решений по системе и ее частям; 
4.2. Разработка документации на АС и ее части.

5. ТП - Технический проект.

5.1. Разработка проектных решений по системе и ее частям; 
5.2. Разработка документации на АС и ее части; 
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку; 
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6. РД - Рабочая документация.

6.1. Разработка рабочей документации на систему и ее части; 
6.2. Разработка или адаптация программ.

7. ВД - Ввод в действие.

7.1. Подготовка объекта автоматизации к вводу АС в действие; 
7.2. Подготовка персонала; 
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); 
7.4. Строительно-монтажные работы; 
7.5. Пуско-наладочные работы; 
7.6. Проведение предварительных испытаний; 
7.7. Проведение опытной эксплуатации; 
7.8. Проведение приемочных испытаний.

8. Сп - Сопровождение АС.

8.1. Выполнение работ в соответствии с гарантийными обязательствами; 
8.2. Послегарантийное обслуживание.

2.3) Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно (то есть по сути - процессов), и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ34 и ISO12207.

3) Особенности.

3.1) Главный мотив: разрешить проблему "вавилонской башни". В 80-х годах сложилось положение, при котором в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная НТД - "нормативно-техническая документация". Это затрудняло интеграцию систем, обеспечение их эффективного совместного функционирования. Действовали следующие комплексы и системы стандартов, устанавливающие требования к различным видам АС:

  1.  единая система стандартов автоматизированных систем управления (24-я система) для АСУ, ОАСУ, АСУП, АСУТП и др. организационно-экономических систем;
  2.  комплекс стандартов системы 23501, распространявшихся на САПР - системы автоматизированного проектирования;
  3.  четвертая группа 14-й системы стандартов, распространяющаяся на АС технологической подготовки производства.

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

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

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

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

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

  1.  определять уровень качества результата;
  2.  выбирать те конкретные методики (с их моделями ЖЦ, набором документов и др.), которые наиболее подходят к условиям разработки и соответствуют используемым Информационным Технологиям;
  3.  работать, таким образом, с минимальными ограничениями эффективных действий проектировщика АС.

Разработчики комплекса стандартов 34 выбрали способ, близкий к первому из указанных выше, то есть пошли по пути, более близкому к схемам конкретных методик, чем к стандартам типа ISO12207. Тем не менее, благодаря общности понятийной базы стандарты остаются применимыми в весьма широком диапазоне случаев.

3.2) Степень адаптивности формально определяется возможностями:

  1.  опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";
  2.  опускать этапы, объединять и опускать большинство документов и их разделов;
  3.  вводить дополнительные документы, разделы документов и работы;
  4.  динамически создавая т. н. ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

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

3.3) Несмотря на сказанное выше, стадии и этапы на практике ориентируют разработчиков на каскадную схему ЖЦ или близкую к ней.

3.4) Введение единой, достаточно качественно определенной терминологии (см. материалы Группы 0 ГОСТ34), наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно полезно. ГОСТ34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.

3.5) Определено несколько важных положений, отражающих особенности АС как объекта стандартизации, например, "в общем случае АС состоит из программно-технических (ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечений". Разделение понятий ПТК, и АС закрепляло принцип, по которому АС есть не "ИС с БД", но:

  1.  "организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;
  2.  "система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций" (по ГОСТ 34.003-90).

Эти определения указывают на то, что АС - это, в первую очередь, персонал, принимающий решения и выполняющий другие управляющие действия, поддержанный организационно-техническими средствами.

Замечание: 

Эти определения и определение системы в ISO12207 вполне совместимы для их совместного использования.

3.6) Гарантирование качества определяется в ТЗ - техническом задании на АС - и производится на любых последующих этапах и с любой степенью независимости экспертизы. В каскадной траектории ЖЦ эти экспертизы располагаются несколько позже, чем в ISO12207. Тем не менее, имеются очень большие потенциальные возможности, которые часто слабо эксплуатируются на практике.

3.7) Степень обязательности: прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.

3.8) Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

Соотнесение процессов ISO12207 и соответствующих компонентов ГОСТ34 и CDM

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

Более того, соотнесение и должно делаться в условных соответствиях, так как:

  1.  ГОСТ34 и CDM в первую очередь ориентированы на действия по созданию и поддержке систем, а ISO12207 - на приобретение и эксплуатацию систем, а разработка является процессом, логически вытекающим из приобретения;
  2.  и главное: ISO12207 изначально предусматривает конкретные применения своих положений после построения профиля для конкретного проекта; таким образом, очень часто некоторый элемент конкретной методики или стандарта может или должен только условно соотноситься с элементами исходных положений ISO12207 и наоборот. Таким образом, конкретное соотнесение элементов должно делаться в процессе адаптации стандартов к проекту и выработки профиля ЖЦ.

Тем не менее, и в этих условиях соотнесение приносит пользу. Оно придает большую ясность выводам и рекомендациям, формулируемым в разделе ИТОГИ.

Основные процессы

В таблице 2 в первом столбце указаны стадии и этапы ГОСТ 34.601-90, как материала, направленного на формирование ЖЦ системы в целом. Во втором столбце указаны процессы ISO12207, в третьем - процессы CDM. В четвертом столбце примечания показывают возможную трактовку соотнесения, возникающую при традиционной (на взгляд автора) трактовке организации ЖЦ АС, близкой к ИС организационно-экономического типа.

Таблица2.  Сравнение технологий и методологии.

ГОСТ 34.601-90; "э.X.Y" - этап Y стадии X

ISO/IEC12207: 1995-08-01

Oracle CDM;

Примечание

э.5.3 ТП, э.7.3 ВД.

1) Процесс приобретения разработчиком

нет

в ГОСТ это приобретение планируется

нет

2) Процесс поставки

нет

CDM содержит процесс CV,

Все этапы ГОСТ34.601 кроме 8. Сп, а именно: 1. ФТ, 2. РК, 3. ТЗ, 4. ЭП, 5. ТП,6. РД, 7. ВД.

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

RD, ES, TA, DB, MD, (DO), TE, (TR), TS.

аналог есть в ГОСТ (э.7.5 ВД и ранее), в ISO аналога нет в явном виде. Процессы DO TR из CDM указаны в скобках, так как они отражены и в других стандартах ГОСТ34 и процессах ISO12207.

нет

4) Процесс эксплуатации

нет

По ISO организация-оператор разрабатывает план и гарантирует соответствие плану

8. Сп., развитие АС - по пункту.1.3 ГОСТ 34.601.

5) Процесс сопровождения

PS

ISO предполагает развитие как элемент сопровождения, вызывающий новый процесс разработки, в CDM в этом смысле полномасштабное развитие не предусмотрено

ИТОГИ

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

Так, CDM предусматривает существенно меньший набор действий по гарантированию качества, развитию системы и ПО, функционированию системы, определению действий пользователя и др. Вместе с тем, CDM явно вводит принципиально важный в реальных проектах смены поколений АС процесс CV - "конвертирование данных", который не выделен в ISO12207 и слишком косвенно отражен в ГОСТ 34.601-90. Кроме того, CDM вводит процесс проектирования базы данных в трактовке, близкой к классической.

2. Однако наличие в практике использования значительного числа конкретных методик, ориентированных к тому же на различные инструменты и терминологические "школы", заново воспроизводит, и, может быть, в еще более острой форме проблему "вавилонской башни", для решения которой создавался ГОСТ34.

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

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

4. По этой причине центральным стандартом, положения которого берутся за начальный "стержневой" набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ГОСТ 34.601-90. Этот "стержень" может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования качества, модель управления проектом.


Раздел 2. Обследование объекта и обоснование необходимости создания АИС.

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

раздел 3. Разработка технического задания на АИС.

Техническое задание составляется в соответствии с ГОСТ 34.60289 «Техническое задание на автоматизирование системы управления».

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

Полное наименование Разработка информационной системы для учета рабочего времени в строительной организации

Условное обозначение: Разработка информационной системы для учета рабочего времени в строительной организации

Разработка ведется на основании договора №1 от 09.11.09 между заказчиком (Виктором Владимировичем директор) и разработчиком (Удаловы Р.Б.).

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

Плановые сроки начала работ 06.03.15, окончания работ 31.05.15.

Финансирование работ по созданию АИС будет осуществляться заказчиком.

Результаты работ по созданию АИС или ее частей оформляются разработчиком в письменном виде и предоставляются в заранее оговоренные сроки.

Назначение и цели создания АИС

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

С помощью этой системы в работе решаются следующие производственные задачи:

- Она создается для развития предприятия и удобного пользования для персонала.

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

Характеристика информационной системы для учета рабочего времени.

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

  1.  продолжительность рабочего времени,
  2.  режим рабочего времени,
  3.  учет рабочего времени.

Учет рабочего времени может быть поденным, недельным и суммированным.

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

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

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

Требования к ИС

Требования:

  1.  Система должна быть простой и понятной пользователю.
  2.  Внедрение АИС должно привести к положительному экономическому эффекту.

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

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

Требования к видам обеспечения АИС:

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

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

  1.  Антивирусная программа Kaspersky Internet Security
  2.  Офисные программы (MS Office)
  3.  Операционная система Windows 7 Professional
  4.  Математическое обеспечение должно включать все ранее разработанные и применяемые на предприятии методики, и алгоритмы расчета основных экономических показателей.
  5.  Программное обеспечение представляет собой совокупность правовых норм, регламентирующих правоотношения при создании и внедрении системы. Правовое обеспечение на этапе разработки должно включать нормативные акты, с правовым регулированием отношений в ходе этого процесса.
  6.  Даная информационная система будет внедрена в течении 3,54 месяцев.

Для работы с ИС необходимо обучить персонал.

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

Проектная стадия:

  1.  Внедрение АИС;
  2.  Сопровождение системы

Исполнителями работ являются:

  1.  Разработчик АИС;
  2.  Специалист по созданию ЛВС (линия высокоскоростной связи);
  3.  Специалист по установке, конфигурированию, сопровождению системы.

Ответственный за выполнение всех работ по всем этапам является разработчик АИС.

раздел 4. Разработка концептуальной схемы базы данных и базы данных АИС.

В данном проекте, для разработки базы данных, будет использоваться программа Microsoft Access.  

Microsoft Access  СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Основные компоненты MS Access:

  1.  построитель таблиц;
  2.  построитель экранных форм;
  3.  построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);
  4.  построитель отчётов, выводимых на печать.

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

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

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

  1.  База данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам.
  2.  База данных должна обеспечивать получение требуемых данных за приемлемое время, т. е. отвечать заданным требованиям производительности.
  3.  База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.
  4.  База данных должна легко расширяться при реорганизации и расширении предметной области.
  5.  База данных должна легко изменяться при изменении программной и аппаратной среды.
  6.  Загруженные в базу данных корректные данные должны оставаться корректными.
  7.  Данные до включения в базу данных должны проверяться на достоверность методом верификации.
  8.  Доступ к данным, размещаемым в базе данных, должны иметь только лица с соответствующими полномочиями.

2.3 Определение таблиц и атрибутов таблиц

Проектирование базы данных начинается с создания таблиц. В базе данных АИС в офисе было создано 9 таблиц: Подразделения, сотрудники, должности, Категории персонала, поставщики, подрядчики, компьютерные материалы, основные заказчики, расход материалов, и копия таблицы сотрудники. Задание атрибутов видно на таблицах 4-13

Таблица 4 Атрибуты таблицы «Подразделения»

Код подразделения

Счётчик

Название подразделения

Текстовый

Численность персонала

Числовой

Таблица 5 Атрибуты таблицы «Сотрудники»

Код сотрудника

Счётчик

Табельный номер сотрудника

Числовой

ФИО сотрудника

Текстовый

Код подразделения

Числовой

Код должности

Числовой

Ид_катег_персонала

Числовой

Стаж по стец-ти

Числовой

Дата рождения

Дата/время

Таблица 6  Атрибуты таблицы «Должности»

Код должности

Счётчик

Должность

Текстовый

Таблица 7 Атрибуты таблицы «Категории персонала»

Ид_катег_персонала

Счётчик

Категория персонала

Текстовый

Таблица 8 Атрибуты таблицы «Поставщики»

Ид_поставщика

Счётчик

Поставщик

Текстовый

Расч_счёт

Текстовый

Банк

Текстовый

Таблица 9 Атрибуты таблицы «Подрядчики»

Ид_подрядчика

Счётчик

Подрядчики

Текстовый

Вид выполняемых работ

Текстовый

Таблица 10 Атрибуты таблицы «Компьютерные материалы»

Ид_нужных_материалов

Счётчик

Нужные материалы

Текстовый

Таблица 11 Атрибуты таблицы «Основные заказчики»

Ид_основные_заказчики

Счётчик

Основные заказчики

Текстовый

Руководитель организации

Текстовый

Телефон

Текстовый

Таблица 12 Атрибуты таблицы «Расход материалов»

Ид_реализация_материалов

Счётчик

Ид_строительных_материалов, изделий и конструкций

Числовой

Дата

Дата/время

Конструкция

Числовой

Ид_поставщика

Числовой

Таблица 13 Атрибуты таблицы «Копия сотрудники»

Код сотрудника

Счётчик

Табельный номер сотрудника

Числовой

ФИО сотрудника

Текстовый

Код подразделения

Числовой

Код должности

Числовой

Ид_катег_персонала

Числовой

Стаж по стец-ти

Числовой

Дата рождения

Дата/время

2.4 Создание схемы данных

После создания таблиц, следующим шагом в разработке базы данных будет создание схемы данных. Чтоб всё работало без нареканий, во время связи таблиц ставим галочку в 3-х полях:

  1.  Обеспечение целостности данных
  2.  Каскадное обновление связанных полей
  3.  Каскадное удаление связанных полей

На примере это видно на рисунке 8.

Рисунок 8 Целостность данных

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

Рис. 9 Схема данных «АИС в строительном офисе»

Заполнение таблиц

После того как была построена схема данных нужно переходить в заполнение таблиц. На рисунках 10-18 можно будет увидеть каким образом были заполнены таблицы.

Запрос – 1.

Запрос – 1 «Перекрестный»

Экономическая часть

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

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

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

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

  1.  Полезный годовой фонд времени;
  2.  Среднегодовая заработная плата разработчика;
  3.  Стоимость одного часа машинного времени;
  4.  Стоимость лицензии инструментального средства реализации ПО.

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

      (4.1)

SРПП затраты на разработку ПО;

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

- стоимость одного часа машинного времени;

n1 и n2 соответственно количество человеко-часов разработки и машинных часов.

Общие издержки на создание ПО включают в себя оплату одного часа работы ЭВМ. И вычисляется по следующей формуле:

       (4.2)

где PЭКСгодовые эксплуатационные расходы, руб.;

PФгодовой фонд времени, час;

PИСПкоэффициент использования машины и времени разработчика.

Коэффициент использования машины принимаем 0,9.

PИСП = 0,9

Эффективный годовой фонд времени рассчитывается по формуле:

   (4.3)

где PР.Д - продолжительность рабочего дня (8 часов);

 NСМколичество смен (1 смена);

PК.Р.Д. количество рабочих дней (253);

 PПТрегламентированные потери рабочего времени (1 час);

    

Продолжительность смены 8 часов, работа идет в одну смену, в году 253 рабочих дня, за рабочий день предусмотрен регламентированный перерыв 1 час. Эффективный фонд времени будет равен:

Рф = 1771 (часов).

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

(4.4)

где ЗПСР.ГОДсреднегодовая заработная плата разработчика, он же занимается обслуживанием. Работу выполняет программист, но работу с системой MS Access может осуществлять сотрудник средней квалификации с заработной платой в размере от 20000 рублей.

АГОДгодовые амортизационные отчисления, руб.;

где  - стоимость ПК (24000руб)

- срок службы ПК (6 лет)

=4000руб

СН.Р.накладные расходы, руб.;

СЭстоимость потребляемой электроэнергии за год, руб.

,  (4.5)

где Ч численность рабочих, 1 человек.

ЗПСР.ГОД =240000 руб.

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

Накладные расходы в условиях предприятия = Ппр. составляют 50% от заработной платы техника-программиста. Сюда включаются затраты на содержание помещения, оборудования, управленческие затраты.

, (4.6)

  

СН.Р. = 120000 руб.

  ,   (4.7)

где МПсумма потребляемой мощности (0,35 кВт);

РФ.годовой фонд рабочего времени, в 2014 году = 1771 час.;

ЦЭстоимость 1 кВт = 4 руб.;

КИСПкоэффициент использования мощности, принимается 0,9.

СЭ = 2331,46 руб.

Исходя из этих данных получаем:

  174000+3500+87000+2331,88=266831,88

РЭКСП = 266831,88 руб.

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

167,41 руб.

Стоимость часа машинного времени.

Затраты, составляющие оплату программиста приведены в нижеследующей таблице:

Табл. 5 Этапы разработки ПО

Этапы разработки ПО

Количество часов

Постановка задачи и исследование предметной области

20

Выбор метода решения

15

Разработка алгоритма для работы программы

42

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

10

Кодирование программы

40

Отладка и тестирование программы

36

ИТОГО:

163

В том числе машинное время

90

Человеко-часов

73

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

,                    (4.8)  

,         (4.9)

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

Отчисления на социальные нужды в размере 30,6%, в том числе:

  1.  Пенсионный фонд 22%
  2.  Фонд медицинского страхования 5,1%
  3.  Фонд социального страхования 2,9%
  4.  Налог на травматизм 0,6%

 

 

ФЗПгод = 227244 руб.

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

   

 . = 128,32 руб.

Вычисляем стоимость разработки программы по формуле (4.1):

26555,13 руб. - себестоимость продукта для предприятия.

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

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

Таблица 6. Исходные данные для расчета экономической эффективности

Наименование показателя

Единицы измерения

Значение

Затраты машинного времени на обработку информации

ч

5

Затраты времени на обработку информации вручную

ч

500

Стоимость компьютера

руб.

21000

Ставка диспетчера/менеджера

руб.

14500

Фактическое время работы компьютера за год

ч

2000

Экономический эффект от внедрения программного продукта рассчитывается по формуле:

Э=S1-S2       (4.10)

где  стоимость базового варианта обработки диспетчером;
S
2 стоимость обработки информации с использованием программного продукта.

Стоимость первого варианта рассчитывается по формуле:

где СД - ставка диспетчера/оператора, руб.;

ТР затраты времени на обработку информации вручную, ч;

ФВ фонд рабочего времени в месяц, ч.

Норма рабочего для всех работающих определяется по календарю, из расчета шестидневной рабочей недели, продолжительностью 40 часов. Следовательно, ФВ в месяц = 176 часов.

 руб.

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

,

где СД ставка оператора, руб;
Ф
В фонд рабочего времени в месяц, ч;
Т
М затраты времени на машинную обработку, ч;
 стоимость одного машинного часа, руб;
 стоимость программного продукта, руб.

При работе с программой 1С предполагается, что ввод данных займет около часа в течение дня. Таким образом, на ввод информации за год будет потрачено 365 часов. Кроме того, несколько часов в месяц потребуется для анализа полученных результатов. Следовательно, принимаем время работы за год равным 400. Все это время компьютер будет занят оператором. В остальное время компьютер занят для других целей.

руб.

Экономический эффект от внедрения данного программного продукта составляет:

Э = 165892,55 - 105612,73 = 60279,82 руб.

Определим срок окупаемости капиталовложений:

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

 года или 5,2 месяца.

Выводы:

  1.  Рассчитаны полные затраты на разработку данного продукта, которые составили 26555,13 рублей.
  2.  Установлено, что при учете только финансовой составляющей продукт окупится через 5,2 месяца.

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

Техника безопасности при работе на ПК.

Организация рабочего места

Приступая к работе на компьютере желательно:

  1.  Осмотреть рабочее место (расположение блоков и их состояние...).
  2.  Подобрать по высоте стул.
  3.  Монитор должен располагаться на уровне глаз и перпендикулярно углу зрения.
  4.  Экран монитора и защитный экран (с обеих сторон) должны быть чистыми.
  5.  Освещение должно соответствовать нормам СанПиН.
  6.  Не рекомендуется располагать монитор около яркого источника света т.к. приходится повышать яркость и контрастность, что влечет за собой: увеличение нагрузки на глаза, излучения, выгорает люминофор экрана, сокращается срок службы монитора.
  7.  На мониторе не должно быть бликов, сильного контраста с внешним освещением.
  8.  Мышь располагается так, чтобы было удобно работать с ней. Провод должен лежать свободно. При работе с мышью по периметру коврика должно оставаться пространство не менее 2-5 сантиметров.
  9.  Клавиатуру следует располагать прямо перед пользователем, работающим на компьютере. По периметру оставляется свободное место 2-5 сантиметров.

Техника безопасности

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

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

  1.  Не входить в помещение, где находится вычислительная техника без разрешения старшего (преподавателя).
  2.  Не включать без разрешения оборудование.
  3.  При несчастном случае, или поломке оборудования позвать старшего (преподавателя). Знать где находится пульт выключения оборудования (выключатель, красная кнопка, рубильник).
  4.  Не трогать провода и разъемы (возможно поражение электрическим током).
  5.  Не допускать порчи оборудования.
  6.  Не работать в верхней одежде.
  7.  Не прыгать, не бегать (не пылить).
  8.  Не шуметь.

Чем опасен для нас компьютер?

Компьютер - высокотехнологичное технически хорошо продуманное устройство, но вместе с тем очень опасное. Иногда опасность реальна, а иногда, он незаметно воздействует на Ваше здоровье и психику.

 

Заключение

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

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

В российском законодательстве выделено два основных типа режимов рабочего времени: нормированный и ненормированный, при этом по общему количеству отработанных суммарных часов они не должны превышать нормы, закрепленные в Трудовом Кодексе РФ.

Исходя из этого, работодатели и юристы чаще сталкиваются с проблемами при учете труда на предприятиях с ненормированным рабочим временем: в случае прерванного рабочего времени, гибкого графика роботы; сменного и вахтенного методов организации труда.

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

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

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

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

В крайних случаях и для устранения формального наличия сверхурочных работ на предприятии с одним сотрудником составляются два трудовых договора по двум ставка. Именно локальные нормативно-правовые акты, такие как Коллективный и Трудовой договора, Правила рабочего распорядка и графика сменности определяет характер «суточного» режима и его правомерность. Федеральные законодательные документы лишь очерчивают границы нормальной положительности рабочего времени (8 часов в день, 40 часов – в неделю, 120 часов в месяц – ст. 91 ТК РФ), но детализация должна осуществляться на каждом предприятии, где в зависимости от потребностей и специфики производства, ресурсной базы выбирается тот или иной график сменности. К тому же трудовое законодательство Российской Федерации, требует более детальной проработки вопроса регулирования рабочего времени, в частности сверхурочных работ.

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

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

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

Список литература

  1.  Алексеев С.С. Теория права. М.: Юридическая литература, 2004.
  2.  Буянова М.О. Трудовое право в вопросах и ответах. - М.: Юристъ, 2003.
  3.  Буянова М.О. Трудовое право в вопросах и ответах. - М.: Юридическая литература, 2003.
  4.  Генкин Б.М. Экономика и социология труда.- М.: НОРМА ИНФРА, 2002.
  5.  Гусов К.Н. Трудовое право Российской Федерации в условиях перехода к рыночной экономике. - М.: Приоритет, 2002.
  6.  Гусов К.Н., Толкунова В.Н. Трудовое право России М.: Юристъ, 2001.
  7.  Гусов К.Н., Толкунова В.Н. Трудовое право России М.: Юристъ, 2001.
  8.  Евстигнеев Н.Д. Практический комментарий. СПб.: Питер, 2003.
  9.  Ершов В.В., Ершова Е.А. Международные трудовые стандарты и российское трудовое право // Трудовое право. 2002. - № 1. с.12-19.
  10.  Зайкин А.Д., Ремизов К.С. Экономико правовое регулирование труда. - М.: Знание, 2002.

  Золотарев Р.Д. Проблемы трудового права. - Новосибирск: Книга, 2000.

  Иванов С.А., Лившиц Р.З., Орловский Ю.П. Трудовое право: Вопросы теории. - М.: Инфра, 2005.

  Иванов С.А., Применение конвенций МОТ в России в переходный период: некоторые проблемы // Государство и право. 1999. - № 8. с. 25-37.

  Киселев И.Я. Международное и сравнительное трудовое право М.:БЕК, 2003.

  Киселев И.Я. Трудовое право России. Историко - правове исследование. - М.: Юридическая литература, 2003.

  Комментарий к Трудовому кодексу Российской Федерации (постатейный, научно - практический)./ Под ред. К.Я. Ананьевой. М.: ТОН ЮРАЙТ, 2002.

  Комментарий к Трудовому кодексу Российской Федерации (постатейный, научно-практический)./ Под ред. К.Я. Ананьевой. Вст.статья В.А. Рыбакова. М.: ТОН-ЮРАЙТ, 2002.

  Комментарий к Трудовому кодексу Российской Федерации (постатейный, научно-практический)./ Под ред. К.Я. Ананьевой. В.А. Рыбакова. М.: ТОН-ЮРАЙТ, 2002.

  Комментарий к Трудовому кодексу российской Федерации / Под ред. Ю П. Орловский. - М.: Юристъ, 2002

  Комментарий к Трудовому кодексу Российской Федерации / Под ред. Ю.П. Орловского. - М.: Норма, 2002.

  Комментарий к Трудовому кодексу Российской Федерации./ Под ред. К.Н. Гусова. М.: Велби, 2003..

  Маврин С.П. Правовые средства управления трудом на предприятии.- Спб.: Нева, 2002.

  Миронов В.И. Законодательство о труде: теория и практика. - М.: Юридическая литература, 2002.

  Миронов В.И. Постатейный комментарий Трудового кодекса РФ. - М.: Юристъ, 2002.

  Миронов В.К. Режим рабочего времени на предприятиях коммерческой сферы. // Трудовое право. - 2003. - № 6. - с 38.

  Организация и нормирование труда / Под ред. Адамчука В.В. М.: Финстатинформ, 2003.

  Организация и регулирование оплаты труда / Под ред. Адамчука В.В. М.: БЕК, 2002.

  Организация, регулирование и учет рабочего времени / Под ред. Адамчука В.В. М.: Финстатинформ 2002.

  Основы организации труда на предприятии / Под ред. Рофе И.А. М., 2004 г.

  Панина А.Б. Проблемы трудового права. - М.: Новый юрист, 2002..

  Панина А.Б. Трудовое право: вопросы и ответы. М.: Новый юрист, 2000. 240 с.

  Панина А.Б. Трудовое право: вопросы и ответы. М.: Новый юрист, 1998. 240 с.

  Российское трудовое право / Отв. Ред. А.Д. Зайкин. М.: НОРМА ИНФРА, 2002.

  Слезенгер Г.Э. Труд в условиях рыночной экономики. М.: Инфра- М.: Инфра, 2003.

  Толкунова В.Н. Трудовое право: Курс лекций.- М.: Экзамен, 2002.

  Трудовое право России / Под ред. С.П. Маврина, Е.Б. Хохлова. - М., 2002.

  Усманов Х.Ю.Трудовые отношения в условиях рынка. Уфа.: Издательство Башкирск. Ун-та 2002.

  Эрделевский А.О. О способах защиты трудовых прав работников // Человек и труд. 2002. - № 1.

  Эренберг Р.Д., Смит Р.С. Современная экономика труда. - М.: МГУ, 2002.


 

А также другие работы, которые могут Вас заинтересовать

71747. Освоение обработки данных с помощью СУБД 380 KB
  Студент должен уметь выполнять следующие виды работ: использовать средства СУБД Microsoft Access для формирования базы данных в режимах Таблицы и Конструктор. использовать средства СУБД Microsoft Access для создания связей между таблицами, входящими в БД.
71748. ТЕКСТОВЫЙ ПРОЦЕССОР WORD 2007 471.5 KB
  Форматирование документов осуществляется в результате следующих действий: установки параметров страницы документа; применения шрифтового оформления символов текста; задания положения абзацев на странице и установки для них отступов и интервалов слева и справа межстрочный и межабзацный интервалы...
71749. Представление информации в табличной форме 258.5 KB
  Цель работы: Научить студентов вставлять в документ таблицы, рисовать таблицы, вводить текст в ячейки таблицы, выравнивать и форматировать текст в ячейках, добавлять и удалять строки и столбцы таблицы, менять параметры ячеек таблицы, вводить формулы в ячейки таблицы.
71750. Создание и редактирование документов 914.05 KB
  Ввод текста в Word осуществляется построчно переход на следующую строку в пределах одного абзаца выполняется автоматически. Ввод текста осуществляется в ту позицию текста в которой находится курсор мерцающая вертикальная черта.
71751. Предикаты раздела WHERE оператора SELECT 55 KB
  Вводит данные в таблицу, заменяя при этом все записи, вызывающие конфликт. Этот оператор аналогичен INSERT за исключением того, что при конфликте нового значения с существующим уникальным ключом новое значение будет записано вместо старого. Первый вариант оператора просто вставит указанные...
71752. Введение в БД MySQL. Типы данных 85 KB
  Цель работы Ознакомление с базой данных MySQL: получение навыков запуска консоли для работы с MySQL корректного формирования и набора команд для работы с БД. Изучить имеющиеся типы данных для столбцов в базе данных MySQL освоить операции создания таблиц.
71753. Изменение таблицы. Выбор данных из таблиц 53 KB
  Оператор ALTER охватывает широкий набор действий, которые изменяют структуру таблицы. Этот оператор используется для добавления, изменения или удаления столбцов существующей таблицы, а также для удаления индексов. Несколько операторов ALTER могут быть объединены в одно предложение...
71754. Создание баз данных 112.5 KB
  Поскольку базы данных и таблицы MySQL хранятся как файлы файловой системы, вы столкнетесь с неприятными различиями - в поведении реализаций для Unix и Win32. Именно, все файловые системы для Win32 нечувствительны к регистру, в то время как файловые системы Unix различают регистр.
71755. ИЗУЧЕНИЕ КОНСТРУКЦИЙ ПОДШИПНИКОВ КАЧЕНИЯ 1.05 MB
  Цель работы: ознакомиться с классификацией и конструкциями основных типов подшипников качения. 1 Классификация подшипников качения Подшипники качения классифицируют по следующим основным признакам: направление действия воспринимаемых нагрузок форме тел качения конструктивным...