59
Использование двух процессоров позволяет эффективно распараллеливать
задачи, выполняемые на сервере.;
64 ГБ ОЗУ достаточно для работы с большими объемами данных, которые
используются на данный момент в БД и платформе 1С: Предприятие, а также
для будущего увеличения нагрузки, поскольку на данный момент пиковая
загрузка ОЗУ составляет 12 Гб.;
Использование 8 HDD необходимо для следующего:
Для бесперебойного функционирования серверной ОС организован RAID
массив из 4 жестких дисков по 100 ГБ (этого объема хватает для работы
операционной системы). Платформы 1С и БД расположены отдельно от ОС системы.
Другой массив из 2 HDD по 120 ГБ предназначен для хранения данных в
формате SQL. На данный момент объем занятого пространства в этом массиве
составляет 60 ГБ.
Помимо этого, есть необходимость в хранении файлов данных в формате mdf
(файл БД) и файлов транзакций ldf, в связи с чем и был организован еще один массив
с такими же размерами, как и предыдущий. Мобильное
устройство для приложения, позволяющего отображать список счетов и
подтверждать платеж. Для удовлетворения условиям поставленной задачи была
выбрана платформа Android поскольку является наиболее распространенной.
60
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Моделью жизненного цикла называют структуру, которая содержит комплекс
задач, действий и процессов, осуществляющихся во время разработки, эксплуатации
и работы программного обеспечения на протяжении всего периода от момента
определения требований до окончательного завершения эксплуатации. Выделяют
несколько различных стандартов и моделей, которые в тех или иных рамках
регламентируют жизненный цикл ПО. Большую часть этих стандартов относятся к
программному обеспечению, которое разрабатывается под заказ (например,
автоматизированные системы), следовательно, помимо непосредственного
регулирования жизненного цикла программных продуктов определяют этапы и
процессы разработки.
Областью распространения стандарта ГОСТ 34.601-90 являются
автоматизированные системы и стадии их разработки. В стандарте можно найти
описание содержания работ, проводимых на каждом этапе разработки ИС. Схему
этапов, регламентируемую в данном стандарте можно большей частью отнести к
каскадной модели ЖЦ [1].
Стандарт ГОСТ Р ИСО/МЭК 12207-2010 распространяется на организацию
ЖЦ. Этот стандарт имеет распространение на все программное обеспечение которое
выполняется на заказ. В отличии от ГОСТ 34.601-90 ГОСТ12207-2010 стандарт не
имеет конкретного описания этапов разработки ПО. [2]
Oracle CDM используемый в разработке заказного прикладного программного
обеспечения это методика имеющая высокий уровень детализации, доходящий до
уровня шаблонов проектной документации, которые рассчитаны на использование в
проектах по данной модели разработки ПО. Адаптивность данного метода
ограничена всего тремя моделями жизненного цикла:
"стандартная" (предусматриваются все работы и задачи);
"ускоренная" (Fast Track);
61
"легкая", используется в малых проектах и при наличии возможности
быстро создавать прототипы ПО.
Стандарт RUP предлагает к использованию итеративную модель разработки,
которая включает в себя следующие этапы:
Начало;
Уточнение;
Построение;
Внедрение.
Каждый этап может быть поделен на итерации, результатом которых будет
являться выпуск или релиз, предназначенный к внутренней или внешней
эксплуатации. Цикл разработки — это процесс прохождения работы через основные
этапы RUP. Результатом каждого цикла является компиляция программного кода в
выпуск. При продолжении работы над проектом, полученный релиз снова начинает
процесс прохождения по этим же этапам [3]. Основной сутью рабочего процесса в
рамках данной методологии является разработка и сопровождение моделей, а не
документации на бумажном носителе, следовательно, данный процесс связан с
использованием различных средств моделирования, таких как UML [3].
Методика разработки Microsoft Solution Framework имеет некоторые сходства
с RUP, она так же имеет четыре этапа [4]:
Анализ;
Проектирование;
Разработка;
Стабилизация.
Если сравнивать MSF с RUP, первая больше ориентирована на разработку
корпоративных приложений.
Наиболее поздней из разработанных методик программирования считается
экстремальное программирование XP. Ядром данного подхода к разработке является
командная работа, постоянная и эффективная связь заказчика и исполнителя во
время всего процесса по разработке программного продукта [5].
62
Выделим основные критерии для определения стандарта жизненного цикла
который будет использоваться в данной дипломной работе.
Методика контроля разработки должна быть актуальной и
современной;
Методика должна позволять контролировать риски и вести разработку
использую итерационную модель.
Учитывая указанные выше требования для выполнения проекта дипломной
работы подходят следующие стандарты:
MSF;
RUP;
XP.
Приведем таблицу 2.1 с характеристиками каждого из этих стандартов
Таблица 2.1
Характеристики моделей MSF, RUP, XP
Технологии MSF, RUP и XP
Технология
Оптимальная
команда
Соответствие
стандартам
Допустимые
технологии и
инструменты
Удобство
модификации и
сопровождения
Rational
Unified
Process
10 - 40 чел.
стандарты
Rational
UML и
продукты
Rational
Удобно (RUP)
Microsoft
Solutions
Framework
3 - 20 чел.
адаптируема
любые
Удобно
(MSF+MOF)
63
Методика экстремального программирования не подходит, поскольку не
содержит информации по этапам жизненного цикла ПО, таких как создание
концепта, планирование, разработка, тестирование, внедрение.
RUP представляет собой хорошо сбалансированное решение для среднего по
размеру коллектива. Однако минусом данной методики является то, что она имеет
сильную зависимость от внутрифирменных инструментальных средств.
Согласно анализу характеристик различных методологий, можно прийти к
выводу, что Microsoft Solutions Framework представляет собой самую
сбалансированную технологию, рассчитанную на малые и средние группы
разработчиков. MSF не ограничивает инструменты и содержит только общие
рекомендации. Несмотря на это, описанные рекомендации используются для
организации определенного рабочего процесса, который удовлетворяет потребности
той или иной группы разработчиков [4].
Проект моей дипломной работы будет выполнятся группой из трех человек,
разработка и тестирование будет проходить в интегрированных средах разработки
Android Studio и «1С: Предприятие». Помимо прочего, к преимуществам MSF можно
отнести то, что эта методика представляет собой гибридную модель разработки,
объединяя в себе преимущества итерационной и каскадной модели и позволяет
одномоментно контролировать разработкой и процессом внедрения
инфраструктурной части проекта.
Исходя из вышеописанных достоинств был выбран стандарт MSF
являющийся, по моему мнению, самым гибким и удобным для реализации моего
дипломного проекта.
Microsoft Solutions Framework включает в себя пять различных этапов ЖЦ
информационной системы [4]. Первый этап — это «Стадия выработки концепта».
Целью данной стадии является разработка эффективной коммуникации в группе и
XP
2 - 10 чел.
стандарты
отсутствуют
любые
Сложно
(зависимость от
участников
коллектива)
64
определения общего видения разрабатываемого программного продукта. На данном
этапе необходимо четкое представление того, что необходимо для удовлетворения
запроса заказчика и формирование цели. Заказчиком в случае данного дипломного
проекта выступает предприятие «Текстиль Трейд». Согласно методике, MSF
участникам команды разработчиков необходимо раздать следующие роли:
Менеджмент продукта;
Менеджмент программного обеспечения;
Разработка;
Удовлетворение заказчика;
Тестирование программного продукта;
Управление релизом.
Каждая роль обладает своими обязанностями и зонами ответственности. На
каждом этапе для каждого участника команды определяются задачи. В стадии
выработки концепта обозначены следующие задачи.
Для менеджмента продукта:
Логический дизайн и концептуальный дизайн;
Функции и спецификацию;
Сводные график и план проекта;
Стоимость.
Для менеджмента программного обеспечения:
Концептуальные решения;
Задачи дизайна;
Проектную структуру.
Для роли разработки:
Анализ технологий;
Смета разработки.
Для ответственных за удовлетворение заказчика:
65
Сценарий использования;
Требования пользователей;
Доступность и локализация;
Инструкция для пользователей;
Обучение использованию.
Для управления релизом:
Оценивание дизайна;
Требования к эксплуатации;
План тестового и финального внедрения.
В рамках разработки внедрения данного проекта силами выбранных
специалистов использование шести и более человек для этой задачи не представляет
собой никакой необходимости. Данные задачи были скомбинированы и
распределены между тремя участниками группы разработки.
Разработчику программного обеспечения были назначены следующие
задачи:
Менеджмент ПО;
Разработка;
Удовлетворение требованиям заказчика.
Бухгалтеру было поручено тестирование ПП.
Руководителю были назначены функции:
Менеджмент продукта;
Управление релизом.
Результатом данного этапа станет определение списка подходящих
специалистов, задач для каждого специалиста, временной график и бюджет данного
дипломного проекта.
На следующем этапе жизненного цикла информационной системы идёт
проектирование. Основной целью которого является разработка плана проекта [4].
Этот этап включает в себя проработку дизайнов, архитектуры, рабочих планов,
66
проектных затрат и сроков внедрения.
Процессом проектирования называется продвижение от абстракции к
конкретной технической реализации. Специфика обязанностей каждого человека в
команде содержится в приложении 1 в таблице 1.
Выходной информацией этапа проектирования является:
Спецификация функциональности;
Анализ и характеристика рисков;
Календарный график разработки;
Сконфигурированная среда разработки и тестирования для каждого
языка программирования, который будет использоваться при
выполнении дипломного проекта.
Программисту на данной стадии разработки проекта необходимо сделать
обзор и выбор подходящего языка, на котором будет выполняться решение задачи,
составить календарный график разработки со сроками, продумать архитектуру
программируемой системы. Бухгалтеру необходимо составить сценарии
использования программного продукта.
После этого проект переходит на этап разработки, на котором команда делает
фокус на разработку программного кода и документацию. Частично эта работа
может быть продолжена на этапе стабилизации, при наличии такой надобности на
стадии тестов. Помимо указанного выше, этап разработки включает в себя процесс
организации инфраструктуры. Отдельно надо заметить, что данный этап не
ограничивается написанием программистом программного кода, в процессе
прохождения каждого этапа все члены команды принимают участие в работе.
Таблица 2 в Приложении 1 включает в себя описание зоны ответственности каждого
участника команды проекта во время этапа разработки. Результатом стадии
разработки становится:
Исходный код и скомпилированный исполняемый файл;
Обработка для конфигуратора;
67
Окончательный список функционала разработки;
Тесты;
Документация поддержки.
Следующим этапом становится стадии стабилизации разработки, когда
программное обеспечение проходит тестирование. Фокус делается на
эксплуатационные качества и реалистичность модели использования. Команда
разработки занимается простановкой приоритетов и устранением ошибок,
возникающих в процессе тестирования. В самом начале этого этапа скорость
нахождения ошибок превосходит скорость исправления командой проекта.
Представляется довольно сложным предугадать где и какие ошибку будут
возникать. Существуют показатели, по которым можно определить прогресс в
стабилизации разработки. Это пик конвергенции ошибок, в котором становится
заметно наличие прогресса в работе по устранению ошибок и падение количества
обнаруживаемых ошибок в программе по мере их исправления. Программные
ошибки могут возникать и после прохождения пика нахождения ошибок, поэтому
эти показатели являются скорее тенденцией, чем определенной конкретной точкой
во времени. Таблица 3 в приложении 1 представляет собой задачи для каждого члена
команды на данном этапе.
Выходными данными стабилизационной стадии ИС являются:
Рабочая версия продукта;
Документация к релизу;
Программная документация;
Проектные документы.
На данном этапе в моей дипломной работе, программист корректирует
ошибки в программе, компилируется версия кандидата на выпуск RC и в случае
отсутствия критических ошибок производится выпуск окончательной сборки
продукта. Совместно с подготовкой к релизу дополняется и программная
документация. Руководитель и бухгалтер определяют 2-3 контрагента и проводят
переговоры по тестированию программного продукта.
68
Последний этап, этап внедрения, характеризируется тем, что команда проекта
проводит внедрение разработки, стабилизирует ПО, проводит инструктаж и
получает со стороны заказчика заключение о результатах проекта разработки.
Результатами фазы внедрения могут считаться:
Мобильное приложение;
Программный модуль 1С;
Процедура и процесс эксплуатации разработки;
Отчет о проекте;
Документальная передача и завершение проекта.
После получения положительного заключения о разработке, программист и
бухгалтер внедряют разработанное ПО тем контрагентам, которые выразили
желание использовать программный продукт, разработанный в рамках данной
дипломной работе. Выделяют несколько различных типов стратегии внедрения
программного продукта. Параллельная стратегия, резкий переход со старой системы
на новую и пилотный проект. В нашем случае будем придерживаться наиболее
надежной из этих стратегий, стратегии пилотного проекта. Поскольку она позволяет
проводить анализ работоспособности информационной системы по мере
расширения количества контрагентов, использующих данное ПО.
В начале периода использования разработанного программного продукта,
согласно инструкции, бухгалтеру необходимо будет проверять результат работы ПО
и отзывы от контрагентов для определения проблем и для принятия решения о
доработке программы.
Модель жизненного цикла представляет собой структуру, которая определяет
взаимосвязь процедур и задач, которые выполняются на протяжении ЖЦ. Эта модель
зависит от специфичности работы ИС и условий в которых она применяется.
На данный момент, самыми известными и используемыми моделями
жизненного цикла являются следующие:
Задачная модель;
Системная модель, иначе называемая каскадной;