Лекция "Основные понятия руководства проектом. Этапы руководства"
методическая разработка на тему

Государственное бюджетное профессиональное образовательное учреждение

Республики Крым «Феодосийский политехнический техникум»

«Утверждаю»

Заместитель директора

по учебной работе

«____» ______________ 2015 г.

______________ О.Г. Сердюкова

ОТКРЫТОЕ ЗАНЯТИЕ ПО МЕЖДИСЦИПЛИНАРНОМУ КУРСУ

МДК.03.01 ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

по профессиональному модулю ПМ.03 Участие в интеграции программных модулей

для студентов четвертого курса специальности

09.02.03 Программирование в компьютерных системах

Разработала преподаватель

________ С.Н. Джелялова

Рассмотрено на заседании комиссии

Компьютерных дисциплин

Протокол  № ____  от сентября 2015 г.

Председатель  цикловой комиссии

___________  Т.Н. Дворянова

2015г.

План открытого занятия по междисциплинарному курсу

МДК.03.01 Технология разработки программного обеспечения

Дата проведения занятия: « ___ » ________________ 2015г.

Группа: ПКС 12 1/9

Тип занятия: проблемная лекция.

1. Тема занятия: Основные понятия руководства проектом. Этапы руководства.

2. Цели занятия:

2.1. Образовательные:

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

2.2. Развивающие:

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

2.3. Воспитательные:

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

3. Обеспечение занятия:

• рабочая программа по профессиональному модулю УП.03 Участие в интеграции программных модулей;
• календарно-тематический план МДК.03.01 Технология разработки программного обеспечения;
• план проведения занятия;
• мультимедийный проектор;
• слайды презентации по теме металлы.

4.  Литература:

1. Орлов С. А., Цилькер Б. Я. Технологии разработки программного обеспечения: Учебник для вузов. 4..е изд. Стандарт третьего поколения.  СПб.: Питер, 2012. 608 С.: ил.
2. Бахтизин, В. В. Технология разработки программного обеспечения : учеб. пособие / В. В. Бахтизин, Л. А. Глухова. – Минск : БГУИР, 2010. – 267 с. : ил.

Структура занятия

1. Организационный момент:

• приветствие;
• проверка присутствующих.

2. Сообщение темы и цели занятия:

• Тема: Лекция. Основные понятия руководства проектом. Этапы руководства.
• Цель: закрепить основные понятия руководства проектом; научиться выбирать состав команды по реализации проекта и распределять роли в команде; научиться составлять план-график работ на выполнение проекта; ознакомиться с ролью руководителя в команде.

3. Оборудование: Слайды презентации по теме.

4. Актуализация опорных знаний:

• Командная работа над проектом;
• Этапы руководства;
• Проектная документация.

5. Объяснение нового материала:

• Распределение ролей в команде;
• План-график работ.

6. Подведение итогов занятия:

• обобщение изученного материала;
• разбиение на команды для выполнения задания;
• разработанные планы проекта, планы-графики работ;
• ответы на вопросы студентов.

7. Домашнее задание:

• Управление рисками;
• Программное обеспечение для управления проектами.

План – конспект открытого занятия

Тема: Лекция. Основные понятия руководства проектом. Этапы руководства.

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

• Актуализация опорных знаний:

1. Чем обусловлена необходимость командной работы над проектом?
2. Каковы процессы управления проектом?
3. Что такое контрольные метки?
4. Что такое контрольные проектные элементы и когда они выполняются?

• Объяснение нового материала:

План лекции:

1. Создание команды;
2. Роли в группе по разработке ПО;
3. График работ;

1. Создание команды.

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

Люди, которые любят свою работу (целевая ориентация), могут стать прекрасными профессионалами.

Люди с самоориентацией на наилучший результат смогут довести дело до конца.

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

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

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

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

Сплоченность команды

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

 Хорошо сплоченная команда имеет ряд преимуществ:

• Возможность становления стандарта качества группы. Т.к. этот стандарт определяется всей группой единогласно, его легче контролировать, чем чужие стандарты, навязываемые группе извне.
• Члены команды поддерживают тесные рабочие контакты. Работая в группе, люди учатся друг у друга. Скованность и затягивание работы, вызванные незнанием или неосведомленностью, уменьшаются по мере того, как происходит взаимное обучение.
• Члены команды ознакомлены с деятельностью друг друга. Этим достигается возможность продолжения работы даже после ухода одного из сотрудников.
• Возможно внедрение в практику группы безличного программирования. Созданная программа должна быть собственностью всей команды, а не отдельной личности.
• Менеджеры могут развивать сплоченность несколькими путями. Можно организовывать социальные мероприятия для работников и их семей. Можно привить группе чувство самобытности, для чего ее надо назвать, определить сущность команды и сферу ее деятельности. Менеджеры должны проводить мероприятия (например, игры и спорт), прямо направленные на создание команды.
• Однако наилучший способ воспитать дух команды - дать возможность каждому почувствовать, что он несет определенную долю ответственности и что ему доверяют, а также гарантировать доступ к проектной информации для всех членов группы.
• Иногда менеджерам кажется, что они не должны раскрывать определенную информацию. Однако такая линия поведения будет постоянно создавать в группе чувство недоверия. Простой обмен информацией – самый дешевый и эффективный способ дать людям почувствовать себя частью команды.

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

На эффективность общения могут оказать влияние следующие показатели.

1. Размер группы. Чем больше группа, тем труднее обеспечить постоянное общение между ее членами.
2. Различие в социальном положении членов группы приводит к появлению большего количества односторонних связей.
3. Структура группы. Работники, состоящие в группах с неформальной структурой, легче общаются между собой, чем в группах, которые имеют определенную официальную иерархию в отношениях.
4. Состав группы. Если в группе много людей с похожими личностными характеристиками, они могут конфликтовать друг с другом, вследствие чего может значительно снизиться уровень общения в группе. Лучше всего люди общаются в смешанных разнополых группах, чем в однородных по полу.
5. Рабочее окружение. Правильная организация рабочего места – основополагающий фактор в развитии или торможении коммуникационных связей в группе.

2. Роли в группе при разработке ПО

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

Таблица 1 – Факторы выбора сотрудников

Решение о назначении нового сотрудника по проекту основывается на трех видах информации:

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

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

В рамках курса «Технология разработки программного обеспечения» выделены следующие роли в группе по разработке ПО:

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

Рисунок 1 – Структура группы разработчиков

3. График работ

План проекта:

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

Рисунок 2  График работ

Рисунок 3 – Сетевая диаграмма

Таблица 2 – Описание сетевой диаграммы

Рисунок 4 – Временная диаграмма

Рисунок 5 – Диаграмма распределения исполнителей по этапам

Таблица 3 – Распределение исполнителей

• Подведение итогов занятия:

Выделяются будущие руководители команд. Выбранные руководители выбирают себе команду из оставшихся студентов. После выбора  руководитель распределяет роли в команде.

После распределения ролей командам дается одно задание, которое они решают независимо друг от друга.

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

Команда, выполнившая работу наиболее качественно, получает оценки «отлично», вторая команда получает «хорошо».

КРОССВОРД ДЛЯ ГОСТЕЙ

Задания:

1. Диаграмма, отображающая зависимость этапов работ от длительности их выполнения в днях.
2. Аппаратное и программное обеспечение, необходимое для реализации проекта.
3. Веха, отмечающая окончание определенного этапа работ.
4. Последовательность взаимосвязанных событий, которые происходят в течение установленного периода времени и направлены на разработку и реализацию программного обеспечения.
5. Диаграмма, отображающая зависимость этапов работы и длительности их исполнения для выделения кратчайшего пути.
6. Точно сформулированное описание совокупности полезных для пользователя характеристик, ожидаемых им от продукта.
7. Группа людей, деятельность которых направлена на достижение одной цели.
8. Частичная или возможная реализация программного продукта.
9. Член команды, в обязанности которого входит моделирование компонент программного обеспечения, кодирование.
10. Член команды, в обязанности которого входит разработка плана тестирования и составление отчета по результатам.
11. Член команды, отвечающий за разработку и анализ требований.
12. Отметка, означающая завершение очередного этапа работ и завершающая предоставлением соответствующей документации заказчику.
13. Член команды, ответственный успешное прохождение и завершение проекта.

КРОССВОРД ДЛЯ ГОСТЕЙ

Задания:

1. Диаграмма, отображающая зависимость этапов работ от длительности их выполнения в днях.
2. Аппаратное и программное обеспечение, необходимое для реализации проекта.
3. Веха, отмечающая окончание определенного этапа работ.
4. Последовательность взаимосвязанных событий, которые происходят в течение установленного периода времени и направлены на разработку и реализацию программного обеспечения.
5. Диаграмма, отображающая зависимость этапов работы и длительности их исполнения для выделения кратчайшего пути.
6. Точно сформулированное описание совокупности полезных для пользователя характеристик, ожидаемых им от продукта.
7. Группа людей, деятельность которых направлена на достижение одной цели.
8. Частичная или возможная реализация программного продукта.
9. Член команды, в обязанности которого входит моделирование компонент программного обеспечения, кодирование.
10. Член команды, в обязанности которого входит разработка плана тестирования и составление отчета по результатам.
11. Член команды, отвечающий за разработку и анализ требований.
12. Отметка, означающая завершение очередного этапа работ и завершающая предоставлением соответствующей документации заказчику.
13. Член команды, ответственный успешное прохождение и завершение проекта.

Раздаточный материал

для команды по разработке ПО

В рамках курса «Технология разработки программного обеспечения» выделены следующие роли в группе по разработке ПО:

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

План проекта:

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

Рисунок 1  График работ

Временные и сетевые диаграммы

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

Рассмотрим этапы некоего проекта, представленные в таблице 1, из которой, в частности, видно, что этап Т3 зависит от этапа Т1. Это значит, что этап Т1 должен завершиться прежде, чем начнется этап Т3. Например, на этапе Т1 проводится компонентный анализ создаваемого программного продукта, а на этапе Т3 — проектирование системы.

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

Таблица 1 – Этапы проекта

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

Любой этап не может начаться, пока не выполнены все этапы на всех путях, ведущих от начала проекта к данному этапу. Например, этап Т9 не может начаться, пока не будут завершены этапы ТЗ и Т6. Отметим, что в данном случае достижение контрольной отметки М4 говорит о том, что эти этапы завершены.

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

Рисунок 2 – Сетевая диаграмма этапов

Задержка в завершении этапов, не входящих в критический путь, не влияет на продолжительность всего проекта до тех пор, пока суммарная длительность этих этапов (с учтом задержек) на каком-нибудь пути не превысит продолжительности работ на критическом пути. Например, задержка этапа Т8 на срок, меньший 20 дней, никак не влияет на общую продолжительность проекта. На рисунке 3 представлена временная диаграмма, на которой показаны возможные задержки на каждом этапе.

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

Рисунок 3 – Временная диаграмма длительности этапов

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

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

Таблица 2 – Распределение исполнителей по этапам

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

Рисунок 4 – Временная диаграмма распределения работников по этапам

Разработать информационную систему туристического агентства.

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

1.1.        Наименование системы

Полное наименование: Информационная система туристического агентства. Краткое наименование: ИС-Турагент.

1.2.        Основания для проведения работ

Работа выполняется на основании договора №1254 от 01.10.2013 г. между турагентством «Орфей» и ООО «Арсенал».

1.3.        Наименование организаций – Заказчика и Разработчика

Заказчик: Турагентство «Орфей». Адрес фактический: г. Москва, Пр. Мира 110. Телефон / Факс: +7 (495) 123-45-66

Разработчик: ООО «Арсенал». Адрес фактический: г. Москва, Ленинградский пр. 78. Телефон / Факс: +7 (495) 321-55-87

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

Начало работы: 01.10.2013 г.

Окончание работы: 31.12.2013 г.

Календарный план работ приведен в приложении.

1.5.        Источники и порядок финансирования

Финансирование осуществляется в соответствии с договором   №1254 от 01.10.2013 г.

1.6.        Порядок оформления и предъявления заказчику результатов работ

Работы по созданию ИС-Турагент сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.

2.        Назначение и цели создания системы

2.1.        Назначение системы

Основным назначением «ИС-Турагент» является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика. В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах:

1. Ведение базы договоров с туроператорами (закупка товаров).

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

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

ИС-Турагент создается с целью:

• повышения качества выполнения основных бизнес-процессов компании;
• сокращения времени на выполнение основных бизнес-процессов;
• создания единой системы отчетности по показателям деятельности.

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

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

дующие позиции: название страны, город, отель, длительность пребывания, варианты авиаперелета.

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

Основные бизнес-процессы, подлежащие автоматизации приведены в следующей таблице.

4. Требования к системе

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

4.1.1. Требования к структуре   и функционированию системы

4.1.1.1. Перечень подсистем, их назначение и основные характеристики.

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

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

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

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

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.

Для организации доступа пользователей к системе должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

4.1.1.3.Требования к режимам функционирования системы.

Для ИС-Турагент определены следующие режимы функционирования:

• основной режим, в котором подсистемы выполняют все свои основные функции;
• аварийный режим, в котором одна или все подсистемы не выполняют своих функций.

В основном режиме функционирования системы:

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

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

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

В случае перехода системы в предаварийный режим необходимо:

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

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

4.1.1.4.Требования по диагностированию системы.

Требования не предъявляются.

4.1.2. Требования к численности и квалификации персонала системы и режиму его работы

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

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

В состав персонала, необходимого для обеспечения эксплуатации ИС-Турагент в рамках соответствующих подразделений Заказчика, необходимо выделение следующих ответственных лиц:

администратор системы ИС-Турагент - 1 человек.

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

К квалификации персонала, эксплуатирующего Систему ИС-Турагент, предъявляются следующие требования:

• конечный пользователь - знание соответствующей предметной области; знания и навыки работы с Web-приложениями;
• администратор системы - знание методологии проектирования баз данных; знание СУБД; знание языка запросов SQL.

4.1.2.3. Требования к режимам работы персонала

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

4.1.3. Показатели назначения

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

данных с глубиной не менее 10 лет.

Система должна обеспечивать возможность одновременной работы 10 пользователей.

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

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

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

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

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

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

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

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

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

В части диалога с пользователем:

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

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

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

Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба).

Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система "Человек-машина".

Для электропитания технических средств должна быть предусмотрена трехфазная четырех-проводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запиты-вается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.

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

Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

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

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

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

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

4.1.7.2. Требования к антивирусной защите

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

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

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

4.1.8.        Требования по сохранности информации при авариях

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

4.1.9.        Требования к защите от влияния внешних воздействий

Применительно к программно-аппаратному окружению Системы предъявляются следующие требования к защите от влияния внешних воздействий:

• электромагнитное излучение радиодиапазона, возникающее при работе электробытовых приборов, электрических машин и установок, приёмопередающих устройств, эксплуатируемых на месте размещения АПК Системы, не должны приводить к нарушениям работоспособности подсистем.
• Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % - 30 %);
• Система должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
• Система должна иметь возможность функционирования в диапазоне допустимых значений влажности окружающей среды, установленных изготовителем аппаратных средств.
• Система должна иметь возможность функционирования в диапазоне допустимых значений вибраций, установленных изготовителем аппаратных средств.

4.1.10.        Требования по стандартизации и унификации

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».

Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х. Для работы с БД должен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.

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

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

Требования не предъявляются.

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

Требования не предъявляются.

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

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

• ввод и редактирование данных о туроператоре;
• ввод и редактирование данных о турпакетах;
• оформление договоров с туроператорами;
• формирование отчетов.

2. Временной регламент реализации каждой функции, задачи.
3. Требования к качеству реализации функций, задач.
4. Перечень критериев отказа для каждой функции

4.2.2.        Подсистема ведения базы данных клиентов.

Подсистема должна состоять из следующих модулей:

• ввод данных о клиенте;
• редактирование данных о клиентах;
• удаление данных о клиентах.

4.2.3.        Подсистема ведения базы данных турпакетов.

Подсистема должна состоять из следующих модулей:

ввод и редактирование данных о стране;

ввод и редактирование данных о городах;

ввод и редактирование данных об отелях;

ввод и редактирование данных о видах размещения в отелях;

ввод и редактирование данных об авиарейсах.

4.2.4.        Подсистема ведения базы заказов.

Подсистема должна состоять из следующих модулей:

• заполнение и редактирование листа бронирования;
• оформление договора с клиентом;
• оформление заказа;

• сопровождение процесса приема-выдачи документов и процесса оплаты тура.

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

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

Требования не предъявляются.

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

4.3.2.1.        Требования к составу, структуре и способам организации данных в системе.

Модель данных Системы физически должна быть реализована в реляционной СУБД .

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

Требования не предъявляются.

4.3.2.3.        Требования к информационной совместимости со смежными системами

Требования не предъявляются.

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

Основные классификаторы и справочники в системе (клиенты, туроператоры, турпакеты) должны быть едиными.

4.3.2.5.        Требования по применению систем управления базами данрых.

Для реализации хранения данных должна использоваться СУБД MySQL.

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

Процесс сбора, обработки и передачи данных в системе определяется регламентом процессов сбора, преобразования и загрузки данных, разрабатываемом на этапе «Проектирование. Разработка эскизного проекта. Разработка технического проекта».

4.3.2.7.        Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

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

4.3.2.8.        Требования к контролю, хранению, обновлению и восстановлению данных

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

К хранению и восстановлению данных предъявляются следующие требования:

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

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

Требования не предъявляются.

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

При реализации системы должны применяться следующие языки высокого уровня: PHP, SQL и встроенные средства диалогового взаимодействия BI приложения HTML.

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

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

Для описания предметной области (объекта автоматизации) должен использоваться Erwin.

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

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

СУБД должна иметь возможность установки на ОС Windows XP и более поздние версии.

К обеспечению качества ПС предъявляются следующие требования:

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

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

Сервер базы данных должен быть развернут на HP9000 SuperDome №1, минимальная конфигурация которого должна быть: CPU: 16 (32 core); RAM: 128 Gb; HDD: 500 Gb; Network Card: 2 (2 Gbit).

Сервер приложений должен быть развернут на платформе HP Integrity, минимальная конфигурация которого должна быть: CPU: 6 (12 core); RAM: 64 Gb; HDD: 300 Gb; Network Card: 3 (1 Gbit).

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

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

Требования не предъявляются.

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

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

• расписанием Заказчика, которое, в случае необходимости, может изменяться. К организации функционирования Системы и порядку взаимодействия персонала, обеспечивающего эксплуатацию, и пользователей предъявляются следующие требования:
• в случае возникновения со стороны функционального подразделения необходимости изменения функциональности системы, пользователи должны действовать следующим образом <описать, что должны делать пользователи (кому писать, звонить, идти) в случае необходимости доработки системы>;
• подразделение, обеспечивающее эксплуатацию системы, должно заранее (не менее чем за 3 дня) информировать всех пользователей (с указанием точного времени и продолжительности) о переходе её в профилактический режим.

К защите от ошибочных действий персонала предъявляются следующие требования:

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

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

В состав нормативно-правового и методического обеспечения системы

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

• ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
• ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.

4.3.9.        Требования к патентной чистоте

Требования не предъявляются.

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

Работы по созданию системы выполняются в три этапа:

• Проектирование. Разработка эскизного проекта. Разработка технического проекта.
• Разработка рабочей документации. Адаптация программ.
• Ввод в действие.

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

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

6.1. Виды и объем испытаний системы

Система подвергается испытаниям следующих видов:

1. Предварительные испытания.
2. Опытная эксплуатация.
3. Приемочные испытания.

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

Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».

Состав, объем и методы приемочных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Ввод в действие» с учетом результатов проведения предварительных испытаний и опытной эксплуатации.

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

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

7.        Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Требования не предъявляются.

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

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

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

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

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:

1. Договор   №1254 от 01.10.2013 г. между турагентством «Орфей» и ООО «Арсенал».
2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
3. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.
4. ГОСТ 24.701-86 «Надежность автоматизированных систем управления».

--------

Список сотрудников

Список сотрудников