32
Программное обеспечение включает в себя совокупность различных
программ, реализующих функции и задачи Информационной Системы и
обеспечивающих устойчивую и стабильную работу комплексов технических
средств. В состав программного обеспечения входят общесистемные и
специализированные программные приложения, а также инструкции и
методические материалы по применению средств программного обеспечения.
К общесистемному программному обеспечению относятся приложения,
рассчитанные на большое количество пользователей и предназначенные для
организации вычислительных процессов и выполнения часто встречающихся задач.
Они позволяют сильно расширить функциональные возможности компьютеров,
автоматизировать планирование и очередность вычислительных работ, а также
автоматизировать работу ИТ специалистов и программистов. Специальное
программное обеспечение представляет собой совокупность программных
продуктов, разрабатываемых под созданием конкретного функционального
назначения. Оно включает программные приложения, осуществляющие
организацию данных и их обработку их при решении функциональных задач ИС.
При выборе комплекса технических средств для разработки приложений,
самым главным критерием выбора является выбор операционной системы. Каждая
прикладная программа пользуется функциями и средствами, предоставляемыми
операционной системой. Поэтому, выбор используемой операционной системы
очень важен, потому что он определяет набор программных приложений и формат
исполняемых файлов, а также их взаимодействие с операционной системой.
Рассматриваемая нами задача не предъявляет очень больших требований к
надежности, производительности и времени на реакцию системы, что дает нам
широкий выбор между системами общего назначения. При выборе операционной
системы для нашей задачи будем исходить из следующих возможных факторов:
–
операционная система, уже имеющимися в организации;
–
минимальные затраты необходимые на переобучение сотрудников;
–
минимальные затраты на поддержку системы.
Если разбирать первый фактор, то особого маневра у нас нет. ТОО «КТТ»
имеет свой парк компьютеров и периферийных устройств (принтеры, сканеры,
МФУ). На всех машинах установлены операционные системы семейства Windows
33
(Windows 7 – 10). Поэтому клиент разрабатываемой ИС должен быть совместима с
этими ОС. Можно было бы разработать Web клиент, но хотя мы знаем, что на
сервере ТОО «Казцинк» установлена ОС Windows Server 2012 и Web Server IIS, но
остальное серверное программное обеспечение для нас не прозрачно. Приходится
отказаться от мысли использовать Web клиент. Наш выбор останавливается на
использовании Windows клиента.
Второй фактор. Автор ИС ведет разработку с интуитивно понятным
интерфейсом, плюс документация и последующее обучение персонала. Поэтому
этот фактор не должен вызвать никаких проблем.
Третий фактор. Автор является сотрудником одного из цехов ТОО «КТТ» и
сопровождение тоже не должно вызвать вопросов.
Основным принципом выбора СУБД следует считать определение
программной платформы, в наибольшей мере, подходящей предъявляемым нами
требованиям. Эту задачу решить достаточно сложно. Во-первых, к СУБД
предъявляется очень большое число требований, которые с течением времени часто
меняются, во-вторых, СУБД имеют большое число настроек и параметров, что
приводит к затруднению их сравнение. Кроме того, информация о существующих
СУБД часто носит маркетинговый характер, не позволяющий сделать правильное
суждение о них.
СУБД классифицируются по следующим признакам. По модели данных:
–
иерархические;
–
сетевые;
–
реляционные;
–
объектно-ориентированные.
По способу доступа к БД:
–
Файл-серверные;
–
Клиент-серверные.
Наиболее подходящей для нашей задачи моделью данных является
реляционная модель, так как она использует простую структуры данных с удобным
для конечного пользователя представлением в виде таблиц. По способу доступа нам
больше подходит клиент-серверная модель, потому что цеха ТОО «КТТ» находятся
в разных городах и нужно централизованное хранилище данных.
34
Имеется большое разнообразие реляционных клиент-серверных СУБД:
–
MS Sql Server;
–
Oracle;
–
PostgreSql;
–
MySql.
Можно долго описывать преимущества и недостатки одних СУБД над
другими, но и тут у нас нет особого маневра, так как на головном сервере ТОО
«Казцинк» используется сервер баз данных Microsoft Sql Server 2012. Поэтому
сделан выбор в пользу Ms Sql Servr.
В настоящее время на рынке сред разработки лидерами являются Microsoft
Visual Studio Net, C++ Builder, JBuilder, Delphi. Любая из перечисленных сред
разработки позволит разработать современное приложение клиент-серверного типа
с современным пользовательским интерфейсом. Однако, автор ИС является
специалистом по языку программирования Net Framework C#.
[6]
Выбор среды
разработки Visual Studio Net C# позволит нам гораздо быстрее и удобнее, по
сравнению с остальными из выше перечисленных сред разработки, получить
готовую к использованию систему, с интерфейсом, аналогичным ИС такого типа.
Разрабатываемый проект использует такие технологии C# v 6.0 WPF
[7]
, ORM ADO
NET Entity Framework v 6.2.0
[8]
, Linq
[9]
.
1.4.3. Обоснование проектных решений по техническому обеспечению
Обоснование выбора проектных решений по технического обеспечения,
требуемого для решения задачи предполагает выбор типа и мощности как рабочих
станций, так и сервера, и функциональность устройств периферии. При этом следует
учитывать экономическую целесообразность закупки и эксплуатации выбранных
аппаратных средств, возможность их использования для решения других задач
объекта автоматизации.
[6]
Эндрю Троелсен. Язык программирования C# 5.0 и платформа .NET4.5 – Издательский дом «Вильямс»,
2013. – 1312 с.
[7]
Мак-Дональд. Мэтью. WPF: Windows Presentation Fundation в .NET 4.0 с примерами на C# 2010 для
профессионалов – Издательский дом «Вильямс», 2011. – 1024 с.
[8]
John Paul Mueller. Developer Step by step Microsoft ADO.NET Entity Framework –
Programming/Microsoft.NET, 2013. – 417 c.
[9]
Joseph C. Rattz. LINQ язык интегрированных запросов в C# 2008 для профессионалов – Издательский дом
«Вильямс», 2008. – 560 с
35
На выбор типа ЭВМ оказывает влияние огромное количество факторов, но в
случае с дипломным проектом обязательно, прежде всего, пояснить условия, в
которых он разрабатывался, тестировался и внедрялся. Если разработка не
предусматривает реорганизации существующей технологии, необходимо лишь
определить какие требования должны будут применяться к аппаратному
обеспечению при эксплуатации на нем разработанного программного приложения.
При выборе аппаратного обеспечения в качестве основных были выбраны
следующие критерии:
–
надёжность;
–
возможность оперативной настройки;
–
низкие расходы на сопровождение программного обеспечения;
–
наличие уже имеющегося парка.
Для нормального функционирования ИС подходит по современным меркам
ЭВМ не с самой большой производительностью и лазерный принтер для распечатки
документов. Требования к серверу БД так же средние.
Проведя анализ требуемого аппаратного обеспечения (тип ЭВМ, принтеров)
и имеющегося в компании, был сделан вывод что оно полностью обеспечивает
потребности ИС в ресурсах и не требует капиталовложений.
Хотя серверная часть для нас не столько прозрачна, можно сделать вывод по
уже используемому клиент-серверному ПО, что и этот фактор не требует
капиталовложений.
Делаем вывод, что данная ИС будет внедрятся без каких-то реорганизаций в
плане аппаратного обеспечения компании.
36
II ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла проекта - структура, содержащая процессы, задачи
и действия, которые осуществляются в ходе разработки, функционирования и
сопровождения ПО в течение всей жизни приложения, от определения
поставленных требований до полного завершения ее использования. Существует
несколько стандартов и моделей, регулирующий жизненный цикл проекта,
большинство стандартов относятся к ПО на заказ и кроме непосредственно
жизненного цикла регулируют также и процессы разработки.
ГОСТ 34.601-90 распространяется на АИС и устанавливает этапы и стадии их
создания. Кроме того, в стандарте описаны все работ на каждом этапе. Стадии и
этапы работы в наибольшей степени соответствуют каскадной модели жизненного
цикла.
ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла
проекта. Распространяется на все виды ПО на заказ. Стандарт не содержит описания
фаз и стадий этапов.
Custom Development Method (Oracle методика) по разработке прикладных
автоматизированных Информационных Систем под заказ - конкретный материал,
детализирован до уровня заготовок проектных документов, рассчитан на
использование в проектах продуктов и инструментария Oracle. Степень
адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая", "быстрая
разработка", "облегченный подход", рекомендуемый в случае малых проектных
решений.
Rational Unified Process (RUP) - это универсальная методология
распределения задач и сфер ответственности при разработке программного
обеспечения. Предлагает итеративную модель разработки, содержащую четыре
фазы: начало, исследование, построение и внедрение. Каждая фаза разработки
может быть разбита на отдельные этапы, в результате которых выпускаются две
версия для внешнего или внутреннего использования. Цикл разработки
37
прохождение через четыре основные фазы, каждый цикл заканчивается генерацией
новой версии системы. Если после этих этапов работа над проектом не закачивается,
то полученный продукт далее совершенствуется и снова минует те же фазы. Суть
работы RUP - это создание и сопровождение информационных моделей, а не
бумажных копий документов, поэтому этот процесс привязывается к использованию
конкретных средств моделирования, например, UML, а также конкретной
технологии проектирования и разработки приложений (объектно-ориентированный
анализ, объектно-ориентированное программирование).
Microsoft Solution Framework (MSF) сходна модель жизненного цикла с RUP,
так же включает в себя четыре фазы: анализ, проектирование, разработка,
стабилизация. Модель итерационная, использует объектно-ориентированное
моделирование. MSF по сравнении с RUP в больше ориентирована на разработку
бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование является
самым новым из выше рассматриваемых методологий, сформировалось в 1996 году.
Основа методологии командная работа, эффективная и полная коммуникация между
заказчиком и разработчиком в течение всего проекта по разработке
Информационной Системы. Разработка ведется с использованием последовательно
дорабатываемых прототипов.
Модель жизненного цикла XP является итерационно-инкрементной моделью
быстрого создания (и модификации) прототипов продукта, удовлетворяющих
очередному требованию.
Главным критериями для выбора стандарта жизненного цикла будут:
–
актуальность и современность используемых методик контроля
разработки;
–
разработка в итерационном режиме с возможностью контролировать
риски;
–
выполнения самого проекта на неких контрольных точках, отсутствие
дополнительных требований по моделированию процесса разработки и
внедрения.
Стратегии внедрения XP.
38
XP предполагает активную социальную позицию, и она далеко не для всех
очевидна. По поводу внедрения XP существует две противоположные позиции. XP
считается системой приемов, которые приводят к новому качеству, только будучи
взятыми на вооружение все вместе, как единое целое. Между многими приемами XP,
такими как коллективное владение или постоянная интеграция, существуют жесткие
зависимости.
Тем не менее, некоторые рекомендуют внедрять XP постепенно, по одному
приему, сосредотачиваясь на наиболее важной проблеме для команды разработки в
данный момент. Это согласуется с мнением о том, что XP — «всего лишь набор
правил», и команда может изменить эти правила в любое время до тех пор, пока
существует согласованная оценка эффекта изменений
Подводя итог описания стандартов выше итерационными из них являются 4
стандарта: MSF, RUP, COBIT, XP.
[10]
Основные особенности MSF, RUP и XP сведены в таблицу 2.1.1.1
[10]
Ron Jeffries. Microsoft Press, Extreme Programming Adventures in C#, 2004. ISBN 0735619492.
39
Таблица 2.1.1.1
Основные особенности MSF, RUP и XP
Технология
Оптимальная
команда
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство модификации
и сопровождения
Rational Unified
Process
10 - 40 чел.
стандарты Rational
UML и продукты
Rational
Удобно (RUP)
Microsoft Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно (MSF+MOF)
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно (зависимость от
конкретных участников
коллектива)
XP очень хорошо подходит для групп малого размера и для небольших систем
с часто изменяемыми требованиями к ним. Главная проблема XP - сопровождение.
В случае текучести кадров в группе разработчиков большая часть проектной
информации может быть утеряна из-за практически полного отсутствия
документации.
И все-таки выбор падает на XP, потому что принципы XP:
1. Простота
В XP начинается разработка с самого простого решения, которое
удовлетворит текущую потребность в функционале. Члены команды учитывают
только то, что должно быть сделано сейчас, и не закладывают в код функционал,
который понадобится завтра, через месяц или не понадобится никогда.
2. Коммуникация
В XP коммуникация между разработчиками ведется не посредственно
вживую. Команда активно общается между собой и особенно активно с заказчиком.
3. Обратная связь
Обратная связь в XP имеет сразу в три направлениях:
обратная связь от системы во время постоянного тестировании модулей
обратная связь от заказчика, т.к. является членом команду и постоянно
участвует в написании приемочных тестов
обратная связь от команды во время планирования, связанного с временем на
разработку.
4. Смелость
40
Некоторые методики XP до такой степени непривычны, что требует смелости
и постоянного контроля над собой.
Обычно XP имеет набор из 12 правил.
Планирование процесса. Для принимается решение о том, какие свойства
системы в ближайшей итерации будут реализованы вся команда разработчиков
собирается вместе. Трудоемкость реализации каждого функции определяется
самими программистами. Команда состоит из единственного разработчика, вашего
визави, и ИТ менеджера компании, что в XP допускается.
Тесное взаимодействие с заказчиком. Представитель заказчика является
членом XP-команды. В эту группу входят представитель IT службы цеха и
разработчик (смотрите выше).
Общесистемные правила именования. Хорошие системные правила
именования предполагают простоту названия классов и переменных. Это важный
вопрос, так как уменьшает количество ошибок в коде при групповой разработке, но
при наличии единственного разработчика не первостепенный.
Простая архитектура. Любое свойство системы должно быть реализовано
максимально проще. Программист в XP-команде используют девиз: «Ничего
лишнего!».
Рефакторинг - это осуществление оптимизации существующего кода с целью
его упрощения, эта работа разработчиком ведется постоянно.
Парное программирование. Все представители команды должны работать в
парах: один пишет код, другой следит за этим. Участвует разработчик и
представитель IT службы цеха.
40-часовая рабочая неделя. Программист обязан работать не более 8 часов в
день.
Коллективное владение кодом. Каждый член команды в коллективе должен
иметь доступ к коду любой части приложения и иметь право вносить изменения в
любой участок кода. Участвует разработчик и представитель IT службы цеха.
Единые стандарты кодирования. Стандарты в кодировании нужны для
обеспечения других правил: коллективного владения кодом, парного
программирования и рефакторинга.
41
Небольшие релизы. Минимальная итерация – один день, максимальная –
месяц; чем как можно чаще осуществляются релизы, тем больше недостатков
системы будет выявлено.
Непрерывная интеграция. Интеграция новых частей системы должна
происходить как можно чаще, как минимум раз в несколько часов.
Тестирование. В отличие от большинства остальных методологий, в том числе
описанных выше, тестирование в XP – одно из самых важнейших составляющих.
Эти все методики собраны в одно целое не случайно. Их непротиворечивая
совокупность способна ввести процесс разработки в интеллектуальный резонанс,
заметно повысив качество полученного продукта и приблизив время его
окончательного выпуска. Основная сила всего экстремального программирования
— прогнозируемость и сведение к минимуму затраты на разработку; предоставление
заказчику именно того продукта, который он желает получить на момент выпуска; и
конечно же общение и повышение квалификации разработчиков без отрыва от
производства.
Из двух стратегий внедрения, используемых в XP, выбираем стратегию как
единое целое, стратегия «жесткого» внедрения.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В ходе жизненного цикла ИС всегда могут возникнуть какие-то риски,
могущие сорвать разработку. Для их предотвращения всегда проводится оценка
вероятных рисков и разрабатываются способы, позволяющие предотвратить эти
риски полностью или минимизировать их.
Рассмотрим наиболее вероятные риски, могущие возникнуть в процессе
жизненного цикла Информационной Системы в соответствии с выбранным
стандартом.
Планирование процесса - на этапе планирования возможен риск
неправильного планирования, разработка слишком оптимистичных планов проекта,
в которые не успеть уложиться, вследствие чего придется увеличивать время на
разработку, что приведет за собой удорожание проекта в целом. К этапу
планирования нужно отнестись очень ответственно, следить за каждым этапом и
анализировать полученные результаты.