37
2. Формирование требований пользователей к программному
обеспечению.
3. Выбор стратегии автоматизации.
4. Разработка технического задания.
5. Проектирование системы.
6. Реализация системы.
7. Тестирование системы.
8. Ввод в эксплуатацию.
На этапе анализа процесса была изучена деятельность организации в целом
и проектного отдела в частности, был определен уровень зрелости организации.
На основании полученных данных было дано обоснование необходимости
разработки информационной системы.
Поскольку решение о разработке программного продукта было обосновано,
были изучены бизнес-процессы, связанные с управлением проектами. Изучение
бизнес-процессов осуществлялось на основании документов и опроса
сотрудников организации. В результате было принято решение о необходимости
реорганизации бизнес-процессов.
Теперь перед нами стоит задача выбора стратегии автоматизации.
Существуют следующие варианты стратегии автоматизации: хаотичная
стратегия, стратегия автоматизации по участкам, стратегия автоматизации по
направлениям и стратегия полной автоматизации.
Стратегия полной автоматизации не подходит для рассматриваемой задачи,
поскольку будут автоматизированы не все бизнес-процессы организации, а только
процесс управления проектами.
Хаотичная стратегия автоматизации представляет собой процесс
автоматизации выделенной функции. В результате чего информационная
инфраструктура организации представляет собой совокупность разрозненных
программных продуктов. Такая стратегия применяется на начальном уровне
зрелости организации. Чем выше уровень зрелости организации, тем больше
появляется потребность в единой информационной базе, с поддержкой
оперативного доступа к данным всех сотрудников организации. Поскольку
уровень зрелости рассматриваемой организации не является начальным, такая
38
стратегия автоматизации не является подходящей.
Разница в стратегиях автоматизации по участкам и по направлениям
заключается в том, что в первом случае осуществляется автоматизация
деятельности отдельных структурных подразделений организации, которые
объединяются по функциональному признаку. Автоматизация по направлениям
представляет собой автоматизацию отдельных направлений деятельности
организации.
В рамках рассматриваемой задачи, более подходящей является стратегия
автоматизация по участкам, потому что неавтоматизированным остается только
участок управления проектами организации.
Затем результаты, полученные на предыдущих этапах, фиксируются в
техническом задании. Техническое задание на создание информационной
системы является документом, в перечислены все проектные решения, и который
подписывается заказчиком и исполнителем.
На основании проектных решений совместно аналитиками и
разработчиками составляется эскизный и технический проект информационной
системы. Этот этап должен быть выполнен максимально качественно, поскольку
ошибки, допущенные на этом этапе, повлияют на качество разрабатываемой
системы, а их устранение будет связанно с большими финансовыми и
временными затратами.
В процессе реализации информационной системы осуществляется
кодирование программных модулей и разработка пользовательского интерфейса.
Полученная в результате выполнения этого этапа информационная система
передается для тестирования.
Существует комплекс методов тестирования программных продуктов:
начиная от проверки внешнего соответствия техническому заданию, заканчивая
проверкой функционала. Выявленные на этом этапе ошибки и несоответствия
подлежат устранению в процессе отладки системы.
Отлаженная система передается в опытную эксплуатацию, в ходе которой
осуществляется установка и настройка программного продукта, обучение
пользователей и тестирование пользователями системы.
39
1.3.3. Выбор и обоснование способа приобретения ИС для
автоматизации задачи
Когда решение о необходимости автоматизации бизнес-процесса принято
и обосновано, перед руководителем организации встает вопрос о способе
приобретения программного обеспечения. Способами приобретения
программного обеспечения являются: покупка готовой специализированной
системы, разработка системы своими силами, разработка системы сторонней
организацией, покупка и доработка системы.
Покупка готовой специализированной системы заключается в
приобретении готового программного обеспечения. В результате анализа рынка
программного обеспечения было установлено что ни одна информационная
система не отвечает функциональным требованиям поставленной задачи.
Вариант покупки готовой системы с последующей доработкой требует
больших затрат, потому придется дорабатывать функционал системы
практически полностью. Этот вариант не подходит для рассматриваемой задачи.
Следовательно, остается вариант индивидуальной разработки системы.
Разработка может быть осуществлена как специалистами организации, так и
сторонней организацией. Если в техническом отделе существуют специалисты с
необходимой квалификацией, разработка может осуществляться своими силами.
Такое часто можно наблюдать в организациях, осуществляющих разработку
программного обеспечения или крупных организациях. В организациях малого и
среднего бизнеса с большей вероятностью такие специалисты будут
отсутствовать в штате или в штате будут программисты, осуществляющие
поддержку информационных систем компании.
В рассматриваемой организации специалисты обладают необходимыми
навыками, поэтому разработка системы, автоматизирующей управление
проектами будет осуществляться своими силами.
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному обеспечению
Комплекс проектных решений по информационному обеспечению задачи
будет включать в себя описание входной, условно-постоянной, оперативной и
40
выходной информации. В рассматриваемой задаче входная информация
представлена требованиями заказчика, они не имеют унифицированной формы,
потому что они могут передаваться как в устной, так и в письменной форме.
Поэтому входные документы в процессе управления проектами отсутствуют.
К оперативной информации процесса управления проектами относятся:
перечень задач проекта, сроки выполнения задач проекта, исполнители проекта и
затраты проекта. Оперативная информация может быть представлена как в
текстовой форме, так и в денежной или в форме дат. Эти данные также не имеют
унифицированных форм. Поэтому при проектировании форм для оперативной
информации потребуется оригинальное проектирование.
К выходной информации процесса управления проектами относятся:
1. План работ проекта.
2. Список ресурсов проекта.
3. Календарный план проекта.
4. Бюджет проекта.
Перечисленные документы также не имеют унифицированных форм. Они
представлены в виде списков, а календарный план проекта в виде таблицы.
Поэтому при разработке информационной системы потребуется оригинальное
проектирование форм выходной информации.
Теперь опишем состав условно-постоянной информации:
1. Список сотрудников технического и проектного отделов, который
будет применяться для формирования списка ресурсов проекта.
2. Тип последовательности выполнения задач проекта:
Одновременное начало задач;
Последовательное выполнение задач;
Одновременное окончание задач.
3. Тип длительности выполнения задач: дни, часы.
1.4.2. Обоснование проектных решений по программному
обеспечению
Поскольку ИП «Optimal Decision» осуществляет разработку интернет
ресурсов, разрабатываемая система будет также web-ориентированной, она будет
41
представлять собой web-страницы и программный код для их обработки. Поэтому
для создания системы будут использованы следующие технологии [16]:
HTML5 – для создания и разметки страницы;
PHP7 – для программной обработки данных на web-страницах;
CSS4 – для оформления и верстки объектов на web-странице.
Разработка web-страниц будет осуществляться с помощью CMS-системы
«Wordpress», на которой разрабатываются проекты организации.
Для создания страниц в CMS-системе «Wordpress» необходима установка
web-сервера. Для рассматриваемой задачи в качестве web-сервера был выбран
web-сервер Apache, который входит в пакет Denwer.
Для разработки базы данных будет использована СУБД MySQL, которая
является реляционной базой данных. Использование реляционной базы данных
позволит:
Обеспечить простоту представления данных благодаря тому, что в
реляционной модели данных существует всего одна информационная
конструкция, формализующая табличное представление данных.
С помощью теоретически обоснованных методов нормализации
отношений получение базы данных с заданными характеристиками.
Обеспечить независимость данных заключается в том, что при
необходимости внесения изменений в структуру реляционной базы данных,
требуется внесение минимальных изменений [11].
Разрабатываемая система должна корректно отображаться во всех
браузерах и быть кросс-плаформенной.
На сервере, на котором будет размещена серверная часть системы, в
виртуальной машине будет установлена операционная система Windows Server
2016. На клиентских ПК будет установлена операционная система Windows 10.
1.4.3. Обоснование проектных решений по техническому обеспечению
Рассмотрим критерии выбора технического обеспечения для поставленной
задачи. Поскольку на сервере хранится и обрабатывается вся информация
информационных систем, для этого вида оборудования характерна
преднамеренная избыточность основных компонентов. Основным критерием при
42
выборе платформы сервера является специфика поставленных и количество
автоматизированных рабочих мест, которые объединяются в сеть. После этого
остается только выбрать производителя.
Основным критерием при выборе сервера СУБД является
отказоустойчивость и пропускная способность сетевого интерфейса [21].
Поскольку разрабатываемый программный продукт будет использоваться
ежедневно в рабочее время, а работать с ней будут 10 сотрудников, загруженность
сетевой инфраструктуры будет равна 30%. При этом загруженность сервера баз
данных будет составлять 25%. Поэтому отсутствует необходимость в покупке
высокопроизводительного сервер с сетевым адаптером скоростью в 1Gbps,
достаточно ограничиться интерфейсом в 100Mbps.
В результате анализа критериев выбора серверного оборудования можно
заключиться, что сервер, используемый в организации, обладает необходимой
мощностью для того, чтобы обеспечить оперативное и отказоустойчивое
функционирование проектируемой информационной системы [23]. В качестве
сервера баз данных будет использован сервер, построенный на платформе HP
ProLiant DL365 G5, обладающий характеристиками, перечисленными в таблице 5.
Таблица 5
Характеристика сервера баз данных
Наименование Спецификация
Процессор
Двуядерный Intel® Xeon® X5260 с тактовой
частотой 3,3 Гц.
Количество процессоров 2
Оперативная память 16 Гб (расширяемая до 64Гб)
Жесткий диск Тип «SAS» 4 диска 147 Гб и 2 диска 73 Гб
Количество жестких дисков 6 (расширяемо до 8)
Питание
Дополнительно резервный блок питания 800Вт
с горячей заменой
Приведем обоснование выбора представленной платформы Использование
двух процессоров позволят при использовании SQL-сервера осуществить
эффективное распараллеливание задач, которые будут выполняться на сервере.
Оперативная память объемом 16 Гб будет достаточной для осуществления
обработки больших объемов информации, используемых на данный момент в базе
данных, а также последующего увеличения вычислительной нагрузки, так как на
данный момент пиковый размер занятой оперативной памяти составляет 6 Гб.
43
Использование 6 жестких дисков применяется для обеспечения надежности
функционирования серверной операционной системы. Также был организован
RAID массив из двух жестких дисков каждый по 73 ГБ (такого объема достаточно
для работы ОС). Операционная система установлена на отдельный от файлов базы
данных жесткий диск для обеспечения безопасности и производительности [24].
Для того, чтобы обеспечить надежность хранения данных в формате
Structured Query Language (SQL) был организован массив жестких дисков
большего объема – 147 Гб. Жесткого диска такого объема достаточно для
внедрения нового функционала, на данный момент объем занятого пространства
занимает 53Гб, при условии того что в базе данных информация будет храниться
в течении 5 лет.
Так же отдельно необходимо хранить данный в форматах mdf (файл базы
данных), а также транзакции в виде файлов ldf (файл транзакций), для чего
необходим еще один массив, аналогичный предыдущему по размеру.
Пользовательские ПК, используемые в организации, имеют достаточный
уровень производительности для функционирования разрабатываемой
информационной системы, в связи с чем не подлежат модернизации.
44
2. Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Процессе разработки программного обеспечения выполняется большой
комплекс работ разными специалистами. Поэтому, лицу, ответственному за
выполнение проекта (проектному менеджеру) необходимо осуществлять
постоянный контроль для того чтобы не нарушить сроки выполнения проекта и
не превысить бюджет проекта. Поэтому специалистами в области
информационных технологий были разработаны стандарты, регламентирующие
процесс разработки программного обеспечения.
Важно отметить, что все стандарты разработки программного обеспечения
представляют собой набор рекомендаций относительно процесса разработки. Они
не имеют жестких рамок, потому что разработка программного обеспечения для
разных сфер деятельности может включать в себя разные процессы. Как правило
в каждой организации, занимающейся созданием программного обеспечения,
процесс разработки индивидуальный.
Однако стандарты разработки программного обеспечения не являются
бесполезными, потому что они содержат комплекс рекомендаций относительно
рабочей документации проекта, последовательности выполнения и набора
процессов.
Для разработки программного обеспечения, автоматизирующего процесс
управления проектами, был выбран стандарт ГОСТ Р ИСО/МЭК 16326
«Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207
при управлении проектом» [1]. Отличие этого стандарта от других заключается в
четкой практической направленности. Он предоставляет руководителям проектов
набор инструментов для выбора процессов жизненного цикла для каждого
конкретного проекта разработки программного обеспечения.
Процессы разработки программного обеспечения в этом стандарте названы
активностями, также он содержит перечень правил конструирования процессов
проекта из них. Стандарт содержит следующие виды активностей:
активностей управления проектами;
активности, предшествующие разработке программного продукта;
45
активности по разработке программного обеспечения;
активности, выполняемые при завершении разработки;
общие активности.
Перечисленные активности подходят под любую модель жизненного
цикла. Но для рассматриваемого проекта была выбрана итерационная модель
жизненного цикла [7]. Также эта модель известная как модель с промежуточным
контролем. Поскольку на каждом этапе разработки программного обеспечения
выполняется комплекс работ, перед руководителем проекта стоит задача
постановки цели каждого этапа и оставление перечня конечных результатов. Это
позволит увеличить контроль процесса разработки.
Итерационная модель включает в себя следующие этапы:
1. Анализ;
2. Планирование;
3. Проектирование;
4. Реализация проекта;
5. Тестирование проекта;
6. Эксплуатация проекта.
Взаимосвязь перечисленных этапов представлена на рисунке 13 [14].
Рисунок 13. Итерационная модель жизненного цикла программного обеспечения
46
Эта модель жизненного цикла программного обеспечения была выбрана
потому что в ней предусмотрена возможность устранять выявленные недостатки
проектирования и программирования на более поздних этапах с помощью
частичного возврата на предыдущие этапы. Однако в процессе разработки
необходимо учитывать, что позже будет выявлена ошибка, тем дороже будет
стоить ее исправление. Если стоимость трудозатрат, которые необходимы для
обнаружения и устранения ошибок на этапе реализации принять за единицу, то
стоимость трудозатрат на выявление и устранение ошибок на этапе планирования
будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на этапе
сопровождения обойдется разработчику в 20 раз больше.
Внедрение программного продукта осуществляется на стадии
эксплуатации. Работы на этом этапе формируются в соответствии с одной из
следующих стратегий:
Параллельная стратегия предполагает, что сотрудники предприятия
будут одновременно работать и в старой системе, и в новой. Успех внедрения
системы будет заключаться в согласовании выходных документов обоих систем.
Стратегия скачка предполагает, что старая система снимается с
эксплуатации и пользователи начинают работать с новой системой без
предварительной проверки ее работоспособности.
Стратегия пилотного проекта предполагает, что новая система будет
внедрена на каком-то одном участке работ, что позволит минимизировать риски
и показывает большую надежность.
Стратегия узкого места предполагает, что автоматизация затронет
только один выполняемый процесс и деятельность сотрудников, которые в нем
задействованы.
Из перечисленных стратегий наиболее подходящей является стратегия
узкого места. Она будет использована в проекте потому что деятельность
организации автоматизирована, кроме процесса управления проектами. Только
этот участок нуждается в автоматизации.
На основании вышеизложенного составим перечень работ проекта
разработки системы, автоматизирующей процесс управления проектами [12]:
1. Анализ: