Разработка технического задания на создание системы управления процессом разработки программных продуктов "Короб-IT" в ООО "ККМ02"
Анализ и обоснование создания системы управления процессом разработки программных продуктов. Функциональные требования к системе управления процессом разработки программных продуктов "Короб-IT". Обоснование проектных решений по видам обеспечения.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | научная работа |
Язык | русский |
Дата добавления | 09.04.2019 |
Размер файла | 1,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
2
Название
TEXT
NN
3
Комментарий
TEXT
NN
Клиент (заказчик)
Описание: содержит информацию о заказчике проекта, который будет выполнять компания ООО «ККМ02».
Атрибуты таблицы «Клиент», описывающей сущность «Клиент (заказчик)» приведены в Таблице 6.
Таблица 11
Клиент
№ |
Наименование |
Тип |
Ключи |
Ограничение |
|
1 |
ID_Клиента |
INT(10) |
PK, NN, AI, US |
||
2 |
ФИО |
TEXT |
NN |
||
3 |
Организация |
TEXT |
NN |
||
4 |
Телефон |
INT(12) |
NN |
||
5 |
Адрес_организации |
TEXT |
NN |
Приложение Б Описание инфраструктуры компании ООО «ККМ02»
Техническая и информационная оснащенность типовых автоматизированных рабочих мест представлена в таблице 2.
Таблица 12
Характеристика ИТ-инфраструктуры ООО "ККМ02"
Пользователь |
Характеристика АРМа |
|
АРМ Директора, Заместителя директора |
Состав:1. Рабочий стол.2. Компьютер (или Ноутбук)3. Смартфон4. МФУПО:1. Система: Microsoft Windows 82. Microsoft Office 20133. Adobe Reader 9.14. Антивирус «Касперский»5. Справочник «ДубльГИС»6. Система управления7. Сервер системеПриложения (в том числе и мобильные)1. Skype 7.6.2. Viber3. Evernote |
|
АРМ Менеджера |
Состав:1. Рабочий стол.2. Компьютер (или Ноутбук)3. Смартфон4. МФУПО:1. Система: Microsoft Windows 82. Microsoft Office 20133. Adobe Reader 9.14. Антивирус «Касперский»5. Справочник «ДубльГИС»6. Система управленияПриложения (в том числе и мобильные)1. Skype 7.6.2. Viber3. Evernote |
|
АРМ Проектировщика, Программиста |
Состав:1. Рабочий стол.2. Компьютер (или Ноутбук)3. Смартфон4. МФУПО:1. Система: Microsoft Windows 82. Microsoft Office 20133. Adobe Reader 9.14. Антивирус «Касперский»5. Справочник «ДубльГИС»6. Система управления7. Программа RAD Studio XE58. Программа Delphi 7 9. Erwin Data Modeler 9.0.10. SQL ServerПриложения (в том числе и мобильные)1. Skype 7.6.2. Viber3. Evernote |
Приложение В ТЗ на создание системы управления процессом разработки программных продуктов
Утверждаю
Разработчик
_____________ А. А. Соколова
«___» _____________ 2015 г.
Утверждаю
Директор ООО «ККМ02»
_____________ А. В. Куренев
«___» ______________ 2015 г.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
На разработку системы управления процессом разработки программного продукта в ООО «ККМ02» 2015 г.
1 ОБЩИЕ СВЕДЕНИЯ
1.1 Полное наименование системы и ее условное обозначение
Полное наименование системы: Система управления процессом разработки программного продукта «Короб-IT» в ИТ-компании ООО «ККМ02». Краткое наименование системы: СУПРПП «Короб-IT».
1.2 Наименования организации-заказчика и организаций-участников работ
Организация заказчик: ООО «ККМ02» в лице директора компании Куренева Андрей Викторовича (заказчик).
Организация исполнитель: Магнитогорский Государственный Технический Университет им. Г.И. Носова (МГТУ им. Г.И. Носова) в лице студентки ИЭиАС, кафедры прикладной информатики Соколовой Ангелины Андреевны (исполнитель).
1.3 Перечень документов, на основании которых разрабатывается система
Договор на между заказчиком и исполнителем на выполнение заказа по разработке и внедрению системы управления процессом разработки программного продукта «КоробIT» в компании ООО «ККМ02».
1.4 Плановые сроки начала и окончания работы по созданию системы
Плановый срок начала работ по разработке системы управления процессом разработки программного продукта «Короб-IT» в ИТ-компании ООО «ККМ02» - 1 февраля 2016 года.
Плановый срок окончания работ по разработке системы управления процессом разработки программного продукта «Короб-IT» в ИТ-компании ООО «ККМ02» - 1 июля 2016 года.
1.5 Порядок оформления и предъявления заказчику результатов работ по созданию системы
1.5.2 Система передается в виде функционирующего облачного сервиса на базе программных средств Заказчика в сроки, установленные ЧТЗ. Порядок предъявления системы, ее испытаний и окончательной приемки определен в п.6 настоящего ЧТЗ.
1.5.3 Приемка выполненных работ осуществляется заказчиком в лице директора компании на основании акта сдачи системы в эксплуатацию.
1.5.4 Техническая документация должна быть представлена и согласована с заказчиком в стандартном виде в двух экземплярах, на электронном носителе. Совместно с представлением конечного функционирующего программного продукта производится сдача разработанного Исполнителем комплекта документации согласно п.8 настоящего ЧТЗ.
1.6 Источники и порядок финансирования работ
Порядок финансирования определяется Бюджетом ООО «ККМ02» на 2016 год.
1.7 Перечень нормативно-технических документов, использованных при разработке ЧТЗ
При разработке системы управления и создании проектно-эксплуатационной документации Исполнитель должен руководствоваться требованиями следующих нормативных документов:
• ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
• ГОСТ 34.602 -89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;
• ГОСТ 2.105-95. Общие требования к текстовым документам.
1.8 Определения, обозначения и сокращения
Определения, обозначения и сокращения, используемые в тексте Технического задания, представлены в таблице 1.
Таблица 13
Определения, обозначения и сокращения
Термин |
Определение |
|
Бюджет проекта |
План, содержащий детальное описание всех поступлений и расходов, планируемых в течении жизненного цикла проекта. |
|
Заказчик |
Организация, заключившая с Компанией договор на выполнение проекта. |
|
СУПРПП |
Система управления процессом разработки программного продукта. |
|
Менеджер про-екта |
Участник группы разработки проекта, сотрудник компании Исполнителя, который координирует действия всех остальных участников группы разработки |
|
Проект |
Координированное выполнение взаимосвязанных действий для достижения определенных целей в условиях временных и ресурсных ограничений. |
|
Ресурсы |
Люди, материалы, оборудование и другие средства, задействованные в проекте. |
|
Риски проекта |
Потенциальная, численно измеримая возможность неблагоприятных ситуаций и связанных с ними последствий. |
|
Сервер |
Специализированный компьютер и/или специализированное оборудование для выполнения на нём сервисного программного обеспечения, находящееся у владельца разрабатываемой системы |
|
Скрам (Scrum) |
Фреймворк, в рамках которого возможно решать сложные адаптивные проблемы и в то же время продуктивно и креативно разрабатывать продукты наивысшего качества. |
|
ЧТЗ |
Частное техническое задание. |
|
УП |
Управление проектами. В соответствии с определением национальным стандартом ANSI PMBoK -- область деятельности, в ходе которой определяются и достигаются четкие цели проекта при балансировании между объемом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками. |
|
ООО |
Общество с ограниченной ответственностью |
|
ККМ02 |
Контрольно-кассовые машины 02 |
2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.1 Назначение системы
Система управления процессом разработки программного продукта «Короб-IT» предназначена для организации единой среды взаимодействия сотрудников компании «ККМ02» и ее заказчиков по вопросам планирования и разработки программных решений.
Разрабатываемая система позволит предприятию:
• обеспечить удобное взаимодействие сотрудников в единой среде;
• обеспечить контроль выполнения поставленных задач;
• формировать отчетные документы по ходу выполнения задач;
• графически представлять процесс выполнения задач в виде диаграмм и графиков.
• постановку задач каждому сотруднику;
• отслеживать время выполнения задач каждым сотрудником по каждой задаче;
• выполнять ранжирование задач.
Одним из преимуществ разрабатываемой системы заключается в организации принципа работы на основе методологии SCRUM. Данная методология предписывает, что команда является кросс-функциональной, то есть участники обладают навыками, необходимыми для успешного выполнения всех задач проекта, что позволит равномерно распределять нагрузку между сотрудниками. Также данная методология позволяет учесть дополнительные требования заказчика, которые чаще всего появляются уже после старта проекта, а также быстро адаптироваться к изменениям проектных решений за счет демонстраций заказчику результатов выполнения каждой задачи.
2.2 Цели создания системы
Основными целями разработки и внедрения СУПРПП «Короб-IT» в компании ООО «ККМ02» являются:
• увеличить прибыль, засчет более эффективного выполнения бизнес-проектов компании;
• уменьшить количество используемых программных средств для общения между сотрудниками;
• грамотная постановка задач по реализации бизнес-проектов компании;
• уменьшить время выполнения задач по бизнес-проектам, засчет постановки отслеживания конкретного времени выполнения задач.
Для реализации поставленных целей система должна обладать функциональностью для решения следующих задач:
• назначение задач сотрудникам;
• постановка времени на задачу;
• ведение графика выполнения задач;
• отслеживание хода выполнения задач;
• отслеживание статуса выполнения задач;
• проведение диалоговых и приватных конференций между сотрудниками и руководством;
• проведение видео конференций;
• координирование задач с помощью доски задач по методологии Scrum или Kanban;
• обмен документами и прочими рабочими материалами.
3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
3.1 Анализ объекта автоматизации
Объект автоматизации - ИТ-компания автоматизации предприятий торговли, общественного питания и индустрии развлечений ООО «ККМ02».
ООО «ККМ02» - компания "Контрольно-кассовые машины 02", которая существует на рынке автоматизации более 10 лет. Основное направление деятельности - автоматизация предприятий торговли, общественного питания и индустрии развлечений. Компания поставляет надежное оборудование и программное обеспечение для автоматизации бизнес-процессов, оказываем полный спектр услуг - от установки и настройки оборудования, до комплексного внедрения информационных систем управления предприятием. На рисунке 1 представлена организационная структура компании ООО «ККМ02»
Основные цели предприятия
• получение прибыли;
• привлечение новых клиентов;
• постоянное улучшение деятельности компании;
• улучшение условий работы сотрудников;
• постоянное совершенствование предоставляемых услуг. Предмет деятельности предприятия
• автоматизация предприятий в сфере услуг;
• поставка торгового оборудования;
• внедрение и сопровождение собственных программных решений. 3.2 Автоматизируемый бизнес-процесс
Занимаясь автоматизацией предприятий, работающих в сфере торговли и услуг, компания ООО «ККМ02» непрерывно разрабатывает и модернизирует различные программные продукты. Исходя из того, что специфика работы компании заключается в удаленной работе сотрудников, которые выполняют свою работу находясь в различных городах России, им необходим непрерывное общение и контроль выполнения задач, которые ставит им руководство компании.
Рассмотрим паспорт автоматизируемого бизнес-процесса.
Название бизнес-процесса: разработка программного продукта.
Цель бизнес-процесса: получение прибыли путем реализации проектов по разработке программных продуктов сотрудниками компании в установленные сроки.
Владелец бизнес-процесса: директор компании ООО «ККМ02».
Команда бизнес-процесса: менеджер проекта, проектировщик, программисты, тестировщик.
Клиенты бизнес-процесса: заказчик программного продукта.
Основные функции бизнес-процесса: координация действий сотрудников по разработке продукта, реализация продукта: оформление дизайна, настройка функционала, организация базы данных, тестирование работоспособности, обсуждение сотрудниками и руководством плана и процесса разработки и т.д.
Инициирующее событие: заявка от клиента на выполнение проекта.
Завершающее событие: подписание «Акта выполненных работ».
3.3 Процесс управления проектной деятельностью «как есть» («AS IS»)
Модель процесса управления проектной деятельностью «как есть», выполненная в нотации Eepc, представлена на рисунке 2.
Процесс начинается с поступления заявки от клиента на разработку программного решения. Далее директор компании оформляет соответствующие документы для подготовки к разработке. В процессе реализации проекта выполняется ряд основных последовательных действий:
1. Выполняется обследование предметной области.
2. Назначается проектная группа.
3. Распределяются задачи проекта.
4. Выполняются работы по реализации проекта.
5. Выполняется сдача проекта заказчику.
В процессе выполнения всех задач по разработке программного продукта, сотрудники компании постоянно общаются, обсуждают проект, проводят промежуточное тестирование и отчитываются перед руководством о проделанной работе.
Рисунок 6 Организация деятельности компании ООО «ККМ02» AS-IS
Засчет того, что компания работает в режиме удаленной работы, виду проживания каждого из участников в различных городах России и отсутствия единого офиса, сотрудникам и руководству необходимо постоянно заполнять большое количество отчетной документации и связываться с командой, для исключения выполнения лишних работ. Это накладывает ряд обязанностей перед сотрудниками: предоставление ежедневного отчета о проделанной работе и т.п.
В конечном итоге готовый, протестированный, функционирующий программный продукт передается директору, который в свою очередь отчитывается перед заказчиком о проделанной работе. В случае несоответствия выполненной работы с условиями заказчика, проект подлежит исправлению и повторному представлению заказчику. При принятии проекта заказчиком выполняется закрытие проекта.
3.5 Процесс управления проектной деятельностью «как будет» («TO BE»)
Модель процесса управления проектной деятельностью после внедрения системы управления процессом разработки программного продукта «как должно быть», выполненная в нотации Eepc, представлена на рисунке 3.
Значительное отличие от модели «как есть» заключается в сокращении сроков и объемов должностных обязанностей сотрудников компании в процессе разработки. Засчет внедрения единого программного решения для организации управления процесса разработки, у сотрудников отпадает необходимость в формировании отчетов о выполненной работе, так как система сама будет формировать такие отчеты, исходя из заполненных данных.
Работы по анализу предметной области, формированию проектной группы и определению задач проекта не меняются, меняется лишь подход к выполнению этих работ.
После определения задач менеджер проекта заносит в систему все данные о задачах, прикрепляет к ним ответственных сотрудников, назначает время выполнения. В процессе разработки сотрудники могут вести обсуждение в системе как по всему проекту, так и по каждой задаче в отдельности. Также они определяют статус задачи, такие как «Запланировано», «В процессе», «Готово» и тому подобное.
С помощью системы упрощается также вопрос контроля сотрудников руководством о проделанной работе. В системе можно отследить статус задач, время выполнения и возникающие проблемы.
Заканчивается процесс разработки закрытием всех назначенных задач, проверкой программного продукта директором компании исполнителя и заказчиком. В случае несоответствия выполненной работы с условиями заказчика, проект подлежит исправлению и повторному представлению заказчику. При принятии проекта заказчиком выполняется закрытие проекта.
Рисунок 7 Организация деятельности компании ООО «ККМ02» TO-BE
4 ТРЕБОВАНИЯ К СИСТЕМЕ
4.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию системы
Разработка СУПРПП «Короб-IT» для компании ООО «ККМ02» включает в себя:
• определение потребностей заказчика;
• определение состава проектной группы;
• проектирование системы в соответствии с ЧТЗ;
• выбор вспомогательных программных средств для разработки системы;
• разработка шаблонов для реализации проектов в соответствии с классификацией;
• выполнение самого процесса разработки системы.
4.1.1.1 Критерии выбора наиболее подходящего программного решения
При разработке системы управления процессом разработки программных продуктов необходимо определить программные средства, которые будут помогать и способствовать эффективному созданию системы. В состав разрабатываемой системы должны входить следующие подсистемы:
• подсистема хранения данных;
• подсистема расчета;
• подсистема формирования отчетности.
Для выбора программных средств для каждой подсистемы, были выделены общие критерии оценки программных средств.
• стоимость;
• стаж использования программного продукта;
• доступность приобретения;
• степень освоения программного продукта;
• возможность выполнения максимального количества поставленных требований к системе;
• интеграция с другими приложениями;
• платформа MS Windows;
• наличие сетевой версии;
• интеграция с Internet;
• наличие системы на предприятии (необязательно).
4.1.1.2 Требования к разработке корпоративного стандарта управления проектами В Корпоративном стандарте по управлению проектами необходимо:
• привести рекомендации по управлению отдельными проектами;
• дать определение термину управление проектами и связанным с ним понятиям;
• описать жизненный цикл управления проектами и сопутствующие процессы;
• описать процессы управления проектами, инструменты и методы, используемые для управления проектом в целях достижения успешного результата.
Основными целями Корпоративного стандарта по управлению проектами по методологии SCRUM являются:
• стандартизация организационных структур и процессов управления проектами, форм рабочих документов;
• принятие правил закрепления проектных функций за подразделениями и назначения сотрудникам проектных ролей;
• введение единых правил взаимодействия участников проектов, разработка корпоративного стандарта управления проектами;
• разработка комплекса документов, описывающий общую методологию управления проектами в организации, учитывающий все ее особенности.
4.1.2 Требования к численности и квалификации персонала системы
Разрабатываемая система управления процессом разработки программных продуктов предназначена для руководства и сотрудников компании ООО «ККМ02», которые будут использовать систему преимущественно для организации своего рабочего процесса в процессе выполнения проектов.
Основные требования к численности и квалификации персонала системы, следующие:
• внедрение системы управления процессом разработки программных продуктов должно способствовать сохранению или уменьшению численности персонала;
• система разрабатывается для использования ее каждым сотрудником компании;
• использование системы не должно значительно увеличивать должностные обязанности сотрудников, а напротив уменьшать;
• аппаратно-программный комплекс системы не должен требовать круглосуточного обслуживания и присутствия администраторов у консоли управления.
Специфика работы компании подразумевает возможность использования системы в любое время суток при наличии Интернета.
Система реализуется на персональных компьютерах, поэтому требования к организации труда и режима отдыха при работе с ней должны устанавливаться, исходя из требований к организации труда и режима отдыха и специфики выполняемого проекта.
Деятельность персонала по эксплуатации системы должна регулироваться должностными инструкциями.
Исходя из специфики работы компании ООО «ККМ02» определим основные роли при эксплуатации системы:
• Директор компании ООО «ККМ02».
• Менеджер проекта.
• Сотрудники компании ООО «ККМ02».
Основные профили заинтересованных лиц при эксплуатации системы представлен в таблице 2.
Таблица 2
Профили заинтересованных лиц системы
Заинтересованные в проектелица |
Понимание основной ценности проекта |
Отношение |
Основные интересы |
Ограничения |
|
Руководство компании |
Увеличение производительности труда сотрудников, упрощение процесса контроля сотрудников |
Озабоченность возможным увеличением расходов на поддержкусистемы иоплаты труда |
Заинтересованность в эффективном привлечении сотрудников к работе с новой системой |
Не определены |
|
Сотрудники компании (пользователи) |
Эффективная организация рабочего времени, отслеживание поставленных задач и времени на их выполнение, эффективное общение с коллегами в процессе работы |
Озабоченность возможным увеличением обязанностейи контроля со стороны руководства |
Сохранение привычного рабочего процесса и заработной платы |
Необходимость обучения сотрудников работе в новой системе, длительный срок привыкания кновому режиму работы |
|
Клиенты |
Быстрые сроки выполнения заказанных проектов |
Возможность частичного внедрения в процесс реализации заказанного проекта |
Получение заказа в установленные сроки и с выполнением всех условий заказа |
Ограниченные возможности работы в системе |
4.1.4 Требования к надежности
4.1.4.1 Требования к надежному функционированию
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
• при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла,
• при отключении Интернета;
• при ошибках, связанных с работоспособностью сервера;
• при ошибках, связанных с самим приложением: внезапное отключение, замедленное действие системы, подвисания и прочее.
4.1.4.2 Время восстановления после отказа
Система должна нормально функционировать при бесперебойной работе компьютера и Интернета. При возникновении сбоя в работе аппаратного обеспечения, восстановление нормальной работы системы должно производиться после:
• перезагрузки Интернет подключения (5 минут);
• перезагрузки браузера (1 минута);
• перезагрузки страницы (1 минута);
• повторная авторизация (1 минута).
4.1.5 Требования к безопасности
Исходя из того, что пользователи будут работать с системой в стенах собственного дома либо в других помещениях с различных устройств, ответственность за личную безопасность лежит на самом пользователе.
Единственное требование к безопасности заключается в защите от вредоносного проникновения вирусов (любого типа) в устройство пользователя через систему. Для защиты от такого проникновения, руководство компании должно обеспечить сотрудникам антивирусную лицензионную защиту.
4.1.6 Требования к эргономике и технической эстетике
Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм.
Навигационные элементы должны быть выполнены в удобной для пользователя форме.
Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы.
Ввод-вывод данных системы, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме.
Цветовая гамма системы должна быть выполнена в соответствии с корпоративными цветами компании без использования ярких, раздражающих и несочетающихся цветов.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов.
Клавиатурный режим ввода должен используется главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть на русском языке. Должна быть возможность перевода на английский язык.
4.1.7 Требования к транспортабельности для подвижных АС
После внедрения системы, при имеющихся возможностях компании, необходимо разработать мобильную версию системы.
4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
Обслуживание системы первое время выполняется представителем компании разработчика. В дальнейшем, необходимо передать обслуживание системы сотруднику компании Заказчика. Обслуживание системы со стороны Разработчика будет выполняться на уровне сопровождения.
Для эффективной эксплуатации разрабатываемой системы должна быть обеспечена бесперебойная и быстрая работа Интернета. Обеспечение такой работы выполняется самим пользователем, в виду индивидуальных возможностей.
Периодическое техническое обслуживание и тестирование технических средств должны включать в себя обслуживание и тестирование всех используемых средств, включая рабочие станции, серверы, кабельные системы и сетевое оборудование, устройства бесперебойного питания системным администратором компании.
На основании результатов тестирования работы системы должны проводиться анализ причин возникновения обнаруженных ошибок и приниматься меры по их ликвидации. Восстановление работоспособности системы должно проводиться в соответствии с инструкциями разработчика и поставщика технических средств и документами по восстановлению работоспособности технических средств и завершаться проведением их тестирования. При вводе системы в опытную эксплуатацию должен быть разработан план выполнения резервного копирования программного обеспечения и обрабатываемой информации. Во время эксплуатации системы, персонал, ответственный за эксплуатацию системы должен выполнять разработанный план.
Все пользователи системы должны соблюдать правила пользования системы. Квалификация персонала и его подготовка должны соответствовать технической документации.
4.1.9 Требования к защите информации от несанкционированного доступа
Система должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем».
Компоненты подсистемы защиты от НСД должны обеспечивать:
• идентификацию пользователя;
• регистрацию пользователя;
• разграничение прав доступа к тем или иным подсистемам.
Уровень защищённости от несанкционированного доступа средств вычислительной техники, обрабатывающих конфиденциальную информацию, должен соответствовать требованиям к классу защищённости 6 согласно требованиям действующего руководящего документа Гостехкомиссии России «Средства вычислительной техники».
При попытке несанкционированного использования системы или взлома, система должна автоматически выполнять блокировку учетной записи, под которой использовалась система или которую взломали.
4.1.10 Требования по сохранности информации при авариях
Вся информация, находящаяся в системе должна автоматически сохраняться на сервер в БД или в облачное хранилище. При перезапуске системы, независимо от того, каким образом была прекращена работа системы, должен сохранятся весь объем введенной ранее информации.
4.1.11 Требования к защите от влияния внешних воздействий
Защита от влияния внешних воздействий должна обеспечиваться силами пользователя системы, исходя из предпочтений в использовании программных средств.
4.1.12 Требования к патентной чистоте
Установка системы в целом, как и установка отдельных частей системы не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей, кроме программного обеспечения, указанного в разделе
4.3.4. (требования к ПО).
4.2 Требования к функциям (задачам), выполняемым системой
4.2.1 Основные функции системы
Основные функции, которые, по мнению компании Заказчика, должна выполнять разрабатываемая система управления, следующие:
1. Обеспечение удобного взаимодействия сотрудников в единой среде:
a. ведение диалогового общения;
b. общение посредством приватных переписок;
c. проведение видеоконференций;
d. комментирование задач, отчетов, данных.
2. Обеспечение контроля выполнения поставленных задач:
a. формирование отчетов по времени выполнения задач;
b. просмотр статуса задачи через Скрам доску;
c. постановка ответственных на задачи и назначение им времени выполнения.
3. Формирование отчетных документов по ходу выполнения задач:
a. списки подзадач;
b. таблица времени выполнения задач;
c. комментарии к задачам;
d. использование шаблонов документов.
4. Графическое представление процесса выполнения задач в виде диаграмм и графиков:
a. построение графика процесса выполнение задач;
b. использование доски Скрам.
5. Постановка задач каждому сотруднику.
a. привязка к конкретной задаче;
b. постановка времени выполнения задачи;
c. привязка к проекту;
d. предоставление необходимых данных о задаче.
6. Ранжирование задач:
a. Расстановка приоритетов задач;
b. Привязка задачи к конкретному проекту;
c. Отслеживание статуса задачи;
d. Перемещение задачи на доске Скрам по ходу ее выполнения.
4.2.2 Организация входных и выходных данных Входными данными системы - это данные, которые заполняются при начале работы с системой в рамках определенного проекта. Входные данные делятся на группы:
1. Данные о проектах:
a. наименование;
b. заказчик;
c. цель;
d. планируемая дата начала проекта;
e. планируемая дата завершения;
f. менеджер проекта;
g. информация о задачах проекта.
2. Данные о ресурсах:
a. время выполнения каждой задачи;
b. тип;
c. состав;
d. базовый календарь.
3. Данные о фазах проекта:
a. наименование;
b. дата начала;
c. дата завершения.
4. Данные о задачах проекта:
a. наименование;
b. дата начала;
c. дата завершения;
d. подзадачи;
e. исполнитель;
f. прикрепленные документы;
g. возможные статусы задачи.
Выходные данные системы - это отчёты по состоянию проекта, выполнению его плановых показателей. Основные выходные данные системы:
• отчет об затраченном времени на задачу - отчет, в котором можно просмотреть к какое время ответственный сотрудник начал/закончил выполнение задачи. Какое среднее время от тратит на идентичные задачи по разным проектам.
• отчет о доступности ресурса - отчет, о сотрудниках компании, по которому можно отследить загруженность каждого из сотрудников.
• отчет о движении рабочего процесса - отчет в виде графика, который показывает эффективность выполнения поставленных задач.
• сводный отчет по трудозатратам ресурсов - отчет для просмотра диаграммы с общей производительностью ресурсов, трудозатратами, оставшейся доступностью и фактическими трудозатратами, представленными в единицах трудозатрат.
• отчет о состоянии критических задач - отчет для просмотра диаграмм, в которых показаны трудозатраты и оставшиеся трудозатраты для критических и некритических задач. На гистограмме показан процент выполнения по трудозатратам.
• отчет о состоянии задачи - отчет для просмотра трудозатрат и процента выполнения по трудозатратам для задач проекта.
• отчет о состоянии ресурса - отчет для просмотра трудозатрат и значений затрат для каждого ресурса проекта. Процент выполнения по трудозатратам изображается затенением в каждом поле на диаграмме. Затенение становится более темным по мере того, как ресурс приближается к завершению назначенных работ.
4.3 Требования к видам обеспечения
4.3.1 Требования к математическому обеспечению системы.
Требования к математическому обеспечению системы не предъявляются.
4.3.2 Требования к информационному обеспечению системы
Доступ к данным должен быть предоставлен только авторизованным пользователям с учетом их служебных полномочий, а также с учетом категории запрашиваемой информации и настроек приватности.
4.3.3 Требования к лингвистическому обеспечению системы
Все прикладное программное обеспечение системы для организации взаимодействия с пользователем должно использовать русский и английский язык.
4.3.4 Требования к программному обеспечению системы
Программные средства, которые будут помогать и способствовать эффективному созданию системы делятся на следующие подсистемы:
• подсистема хранения данных;
• подсистема расчета;
• подсистема формирования отчетности.
Подсистема хранения данных предназначена для хранения оперативных данных системы, данных запросов для формирования аналитических отчетов, документов системы, сформированных в процессе работы отчетов.
Подсистема расчета должна обеспечивать расчет данных при формировании отчётности (средние значения, суммарные баллы, процентные показатели).
Подсистема формирования отчетности предназначена для создания и формирования отчетов любой конфигурации в соответствии с требованиями и выбранными критериями менеджером, представление отчётности в удобном для просмотра виде, а также в удобном для вывода на печатающие устройства на основе данных системы, проектирования и разработки форм регламентированной отчетности.
Подсистема хранения данных будет реализована с помощью специального сервера DEPO Storage 1304 и облачного пространства в нем. Для построения инфологической модели данных будет использовано программное средство CA ERwin Data Modeler Community Edition 9.0.
Также необходимо наличие установленного браузера в зависимости от предпочтений пользователя из предложенных: Internet Explorer, Opera, Google Chrome, Mozilla Firefox, Safari и другие.
4.3.5 Требования к техническому обеспечению
В состав технических средств должен входить персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:
• процессор Intel Core i7, не менее;
• оперативную память объемом, 16 Гбайт, не менее;
• свободного пространства на жестком диске, 8-15 Гбайт, не менее. Для установки системы основными являются следующие требования:
• 64-разрядная версия Windows Server 2013;
• Корпоративный выпуск Microsoft SharePoint Server 2013;
• Один из браузеров: Internet Explorer, Opera, Google Chrome, Mozilla Firefox, Safari (возможна установка нескольких, в зависимости от предпочтений).
Требования к техническим характеристикам АРМ пользователя и администратора:
Засчет удаленной работы каждого сотрудника, требования к характеристикам АРМ пользователя и администратора определяются самим пользователем. 4.3.6 Требования к метрологическому обеспечению
Требования к метрологическому обеспечению не предъявляются.
4.3.7 Требования к организационному обеспечению
Разрабатываемая система управления процессом разработки программных продуктов предназначена для руководства и сотрудников компании ООО «ККМ02», которые будут использовать систему преимущественно для организации своего рабочего процесса в процессе выполнения проектов.
Для эффективного использования системы необходимо назначить или нанять ответственного сотрудника, менеджера проекта, который будет контролировать всех сотрудников и полностью управлять процессом выполнения проекта.
Разрабатываемая система не предусматривает взаимодействие с другим программным обеспечением, используемым в компании, не считая Интернет браузеры.
4.3.8 Требования к методическому обеспечению
В состав нормативно-правого и методического обеспечения системы должны входить следующие законодательные акты, стандарты и нормативы:
• Американский национальный стандарт по управлению проектами ANSI/PMI 99-001-2008.
• Руководство к Своду знаний по управлению проектами. Четвертое издание (Руководство PMBOK®).
• Исчерпывающее руководство по Скраму «Скрам Гайд»: правила игры. 2014.
В процессе эксплуатации системы список нормативно-правого и методического обеспечения системы может пополняться.
5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ И ВНЕДРЕНИЮ СИСТЕМЫ
Состав и содержание работ по созданию системы согласованы с Заказчиком. Основные работы и формы из отчетности приведены в таблице 3.
Таблица 3
Состав и содержание работ по созданию и внедрению системы
Этап |
Название этапа |
Содержание работ |
Форма отчётности |
|
1 |
2 |
3 |
4 |
|
1 |
Анализ требований к Системе |
Обследование объекта автоматизации и обоснование необходимости создания СистемыФормирование требований пользователей кСистемеРазработка графика сдачи проектной документацииЗакрепление ресурсов |
График сдачи проектной документации |
|
2 |
Анализ бизнеспроцессов и разработка устава |
Разработка устава проекта Описание бизнес-процесса as isОписание бизнес-процесса to beПрезентация заказчику устава проекта, модели бизнес-процесса as is, модели бизнеспроцесса to be |
Устав проекта, модель бизнеспроцесса as is, модель бизнеспроцесса to be |
|
3 |
Техническое задание |
Разработка и утверждение технического задания на создание и внедрение Системы |
ТЗ |
|
4 |
Формирование бюджета проек-та |
Составление сметы расходовРасчет точки безубыточностиРасчет показателей эффективности проектаУтверждение бюджета проектаВнесение коррективов в бюджет |
Смета расходов Бюджет проекта |
|
5 |
Проектирование архитектуры системы |
Проектирование с использованием UML Планирование интеграции с имеющимися приложениямиСоставление подробного плана-графика работФормирование заказа на покупку лицензий |
План-график работ |
|
6 |
Установка ПО |
Установка и настройка системыИнтеграция с основной БД предприятия Настройка сервера |
Отчет о выполненных работах |
|
7 |
Тестирование |
Тестирование интеграцииВыявление недостатков в архитектуре системыУстранение недостатковТестирование интеграции модулейДонастройка компонентов интеграции Повторное тестирование интеграции модулейТестирование СУП по методологии SCRUMВыявление недостатков системыУстранение недостатковПовторное тестирование |
План тестирования, перечень дефектов |
|
8 |
Документация |
Разработка справки |
Комплект Рабо- |
|
Ревизия справкиДоработка справки с учетом замечанийРазработка руководства пользователя Ревизия всей документации для пользователейДоработка документации для пользователей с учетом замечаний |
чей и пользовательской документации |
Должны быть проведены необходимые испытания Системы перед предъявлением её Заказчику, проведены опытная эксплуатация и приёмочные испытания с помощью ответственной группы разработки.
6 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ
6.1 Виды, состав, объем и методы испытаний системы
Испытания и тестирование проводятся разработчиками системы в процессе ее создания, проведении пилотного проекта и опытной эксплуатации:
• с использованием контрольных тестов, позволяющих добиться проверки правильности работоспособности и взаимной совместимости максимального числа функций и операторов программы или модуля при минимальных затратах временных и финансовых ресурсов;
• путем пошагового исполнения программы или модуля (и непрерывного контроля значений переменных) в соответствии с набором тестовых примеров и сравнения полученных в процессе тестирования значений с контрольными значениями тестовых примеров;
6.2 Общие требования к приемке работ по стадиям
Сдача-приёмка работ производится поэтапно, в соответствии с планом-графиком. Сдача-приемка осуществляется руководством компании Заказчика. По результатам приемки подписывается акт о приёме Системы в постоянную эксплуатацию.
Все создаваемые в рамках настоящей работы программные решения передаются Заказчику в виде готовых модулей, представляемых в электронной форме через Интернет. 6.3 Статус приемочной комиссии
Статус приемочной комиссии определяется Заказчиком до проведения испытаний.
7 ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ
При подготовке к вводу в эксплуатацию СУПРПП «Короб-IT» компания Разработчика, совместно с Заказчиком должна обеспечить выполнение следующих работ:
• подготовить пользователей к проведению обучающих мероприятий по работе с системой;
• удостовериться о наличии всех необходимых программных компонентов для проведения обучения;
• организовать пользователям удобные условия проведения обучения;
• подготовить план проведения обучающих мероприятий;
• провести опытную эксплуатацию СУПРПП «Короб-IT».
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие, включая перечень основных мероприятий и их исполнителей, должны быть уточнены на стадии подготовки рабочей документации и по результатам опытной эксплуатации.
8 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
Для системы на различных стадиях создания должны быть выпущены документы, которые приведены в таблице 4.
Таблица 4
Состав и содержание работ по созданию и внедрению системы
Стадия |
Стадия создания |
Наименование документа |
|
1 |
Анализ требований к Системе |
Результат обследования предприятияСтратегическая карта организацииСхема организационной структурыПеречень требований к системеОбзор программных решенийГрафик сдачи проектной документации |
|
2 |
Анализ бизнес-процессов и разработка устава |
Устав проектаМодель бизнес-процесса as isОписание автоматизируемых функцийМодель бизнес-процесса to be |
|
3 |
Техническое задание |
Техническое задание |
|
4 |
Формирование бюджета проекта |
Смета расходов Бюджет проекта |
|
5 |
Проектирование архитектуры системы |
Архитектуры системыПлан-график работЗаказ на покупку лицензий |
|
6 |
Установка ПО |
Отчет о выполненных работах |
|
7 |
Тестирование |
План тестирования, Перечень дефектов |
|
8 |
Документация |
СправкаРуководство пользователяРуководство администратора |
Проверка документации программы осуществляется самим Заказчиком в присутствии Исполнителя проекта.
9 ИСТОЧНИКИ РАЗРАБОТКИ
Источниками разработки являются нормативные документы и информационные материалы, на основании которых разрабатывалось ЧТЗ и которые должны быть использованы при создании системы.
Источники разработки СУПРПП «Короб-IT»:
• ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
• ГОСТ 34.601 -90 Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания АС.
• ГОСТ 34.602 -89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;
• ГОСТ 2.105-95. Общие требования к текстовым документам
• Руководство к своду знаний по управлению проектами (A Guide to the Project Management Body of Knowledge - руководство PMBOK®).
• РД 50-34.698-90 Автоматизированные системы требования к содержанию документов.
• ГОСТ Р ИСО/МЭК 12207-99 Процессы жизненного цикла ПС.
• ISO 15504:1-9:1998 Оценка (аттестация) процессов жизненного цикла программных средств
• ISO 15271:1998. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207. * ISO 16326:1999. (ГОСТ Р-2002). ИТ. Руководство по применению ISO 12207 при административном управлении проектами.
• ISO 9000-3:1997. Стандарты в области административного управления качеством и обеспечения качества. Часть 3. Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.
• ГОСТ 19.402-78 Единая система программной документации. Описание программы.
• ГОСТ 19.404-79 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению.
• ГОСТ 19.301-79 Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению
Размещено на Allbest.ru
Подобные документы
Основные интегрированные информационные системы поддержки принятия решений. Обзор и сравнительный анализ программных продуктов инвестиционного проектирования. Программа управления проектами "MS Project". Примеры программных продуктов в ОАО "Криогенмаш".
курсовая работа [776,0 K], добавлен 03.06.2014Этапы технологического процесса разработки программных продуктов, их жизненный цикл. Общая характеристика языков программирования. Виды ошибок и принципы тестирования программ. Установление прав собственности на продукт посредством лицензий и контрактов.
презентация [1,9 M], добавлен 01.05.2011Обзор программных продуктов для службы экспресс-доставки. Анализ бизнес-процессов в системе, формулировка функциональных и эксплуатационных требований. Декомпозиция системы и построение диаграммы иерархии функций. Построение инфологической модели данных.
курсовая работа [474,8 K], добавлен 20.07.2014Особенности документирования программных средств, стадии разработки продуктов. Классификация обеспечивающего пакета документов. Сущность и основные недостатки Единой системы программной документации. Классификация стандартов, Гост 19.102-77 ЕСПД.
презентация [64,8 K], добавлен 22.03.2014Интегрированная среда разработки Lazarus. Среда программных продуктов Lazarus, объекты программных компонентов. Палитра компонентов Standard, Additional. Разработка справочной системы: структура проекта, интерфейс программы, компоненты приложения.
курсовая работа [695,2 K], добавлен 08.01.2023Приложение для организации и контроля разработки программного обеспечения, сокращающее сроки проектирования программных продуктов и оптимизирующее данный процесс. Технологии создания приложений на платформе .NET. Алгоритм получения и обновления списка.
дипломная работа [861,9 K], добавлен 27.11.2014Обоснование необходимости разработки АОС "Информационная безопасность". Построение модели деятельности "Как есть" (AS-IS) и "Как должно быть" (TO-BE). Анализ программных продуктов. Создание модели предметной области. Разработка информационной системы.
отчет по практике [5,3 M], добавлен 31.05.2015Эффективность и оптимизация программ. Разработка программных продуктов. Обеспечение качества программного продукта. Назначение, область применения, требование к программному продукту. Требования к функциональным характеристикам, надежности, совместимости.
курсовая работа [46,8 K], добавлен 05.04.2009Разработка и обоснование функциональной схемы системы автоматического управления технологическим процессом. Расчет мощности электродвигателей. Выбор и компоновка шкафа электроавтоматики. Моделирование программного обеспечения в Logo Soft Comfort v6.0.
курсовая работа [4,1 M], добавлен 02.04.2013Диагностический анализ системы управления ООО "Система". Оценка функциональной структуры функционирующей АСУ, ее плюсы и минусы. Проектирование подсистемы "Учет разрабатываемых программных продуктов". Расчет затрат на разработку программного продукта.
дипломная работа [5,7 M], добавлен 29.06.2011