Описания процессов, поддерживающих поддержание жизненного цикла программного обеспечения «Мэджик Лайф», способов устранения неисправностей, информации о персонале, информации о совершенствовании ПО

1. Процесс разработки программного обеспечения «Мэджик Лайф» включает в себя следующие основные этапы:
- разработка и согласование ТЗ проекта;
- согласование интерфейса оператора;
- согласование структуры ПО;
- разработка исходного кода ПО, компиляция и проведение тестирование программных модулей;
- разработка программной документации;
- проведение комплексного тестирования и устранения замечаний;
- проведение независимого тестирования и устранения замечаний;
- разработка инструкции по изготовлению носителя;
- проведение предварительных испытаний, коррекция КД и ПД по результатам испытаний;
- проведение приемочных испытаний, коррекция КД и ПД по результатам испытаний;
- присвоение литеры О1.

1.1 Для разрабатываемого на предприятии ПО в качестве модели жизненного цикла для большинства проектов выбирается спиральная модель, соответствующая масштабу и сложности проекта.
Спиральная модель схожа с инкрементной моделью, но с в ней уделяется больше внимания оценки и разрешения рисков. Спиральная модель подразделяет реализацию проекта на четыре этапа: планирование проекта, оценка рисков, проектирование и разработка и проведение оценки. Проект каждый раз заново проходит через эти четыре стадии при создании новой версии или фрагмента ПО (что соответствует одному витку спирали в данной модели). Базовый виток спирали, начинающийся на этапе постановки задач, включает в себя определение требований и оценку рисков. Каждый последующий виток строится на основе базового.
Требования программному продукту и к особенностям разработки программного обеспечения определяются на этапе постановки задач. На этапе оценки и разрешения рисков применяется специальный процесс для определения рисков и нахождения разных решений по их разрешению. По окончании данного этапа создается прототип ПО.
Третий этап включает в себя непосредственно разработку ПО и его тестирование по окончании данного этапа. Этап проверки позволяет разработчику и заказчику оценить результат проекта на текущий момент, прежде чем начнется новый виток разработки.

1.2 Каждый этап жизненного цикла ПО подразделяется на различные процессы и операции.

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


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

1.4 Оценка рисков проекта.
Риск – это любое событие, которое может помешать реализации проекта в соответствии с планом или его успешному завершению. Риски можно идентифицировать из разных источников. Некоторые из них могут быть довольно очевидными и будут выявлены до начала проекта. Другие будут идентифицированы в течение жизненного цикла проекта, и риск может быть идентифицирован любым участником проектом. Некоторые риски будут присущи самому проекту, в то время как другие будут результатом внешних воздействий, которые полностью неподконтрольны команде проекта.

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

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

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

1.7.1 Система управления версиями исходного кода.
В процессе разработки ПО в качестве распределенной системы управления версиями исходного кода используется инструмент Git.
Git – это программное обеспечение, свободно распространяемое на условиях универсальной общедоступной лицензии GNU версии 2.
Каждый рабочий каталог в Git – это полноценный репозиторий, содержащий всю историю проекта с возможностью отслеживания версий, не зависящий от доступа к сети или центральному серверу.
Концепция Git возникла на основе опыта, полученного при управлении большим распределенным проектом разработки при работе над Linux, а также особенностей работы с файловыми системами, и острой потребности в создании жизнеспособной системы в кратчайшие сроки. Все это привело к следующим особенностям реализации:
Git позволяет быстро создавать и осуществлять слияние отдельных ветвей проекта и включает в себя специальные инструменты для визуализации и навигации по нелинейной истории разработки. Основным принципом в Git является предположение, что слияние изменения будет производиться чаще, чем его написание, так как оно распределяется для оценки несколькими разработчиками. Ветви в Git занимают очень мало места: они являются лишь ссылками на отдельные коммиты. С помощью родительского коммита может быть построена полная структура ветвей.
Git предоставляет каждому разработчику локальную копию всей истории разработки, и изменения копируются из одного такого репозитория в другой. Такие изменения импортируются в виде дополнительных ветвей разработки, и их слияние может осуществляться так же, как и для ветви, разработанной локально.
Репозитории могут быть опубликованы с помощью HTTP, FTP, rsync или протокола Git через обычный сокет, ssh или HTTP. Git также имеет эмулятор сервера CVS (системы одновременных версий), который позволяет использовать существующие клиенты CVS и плагины IDE для доступа к репозиториям Git. Репозитории подверсий и SVK можно использовать напрямую с помощью git-svn.
История хранится в Git таким образом, что идентификатор конкретной версии («коммит» в терминологии Git) зависит от полной истории разработки, предшествовавшей данному коммиту. После его публикации невозможно изменить старые версии незаметно. Эта структура похожа на дерево хешей, но с наличием дополнительных данных в узлах и листовых вершинах.
ПО разрабатывается несколькими специалистами. Когда разработчик начинает внедрение нового функционала или отладку, он забирает последнюю версию проекта из системы Git. После выполнения задачи новая версия ПО хранится на его локальном хосте. Прежде чем залить новую версию в одну из рабочих ветвей, менеджер версий ПО отправляет измененное ПО на проверку двум другим разработчикам, выбранным произвольно. После одобрения кода ПО отправляется на слияние. Менеджер версий ПО пытается совместить новые изменения с обновленными ветвями проекта. При неудачном слиянии новый код отправляется разработчикам ПО, чтобы они одобрили общее обновление. При успешном слиянии новая ветвь отправляется на тестирование. Тестировщики проверяют обновленное ПО разными методами, и при успешном прохождении тестов ветвь разработки подготавливается к релизу. Автоматическая компиляция версии релиза проекта осуществляется дважды в день. Также ПО проверяется в тестовой среде. Если все тесты и компиляция проходят успешно, версия считается готовой к релизу. В противном случае менеджер версий ПО находит проблему и возвращает ветвь разработчикам для исправления.

1.7.2 В процессе разработки было задействовано 1 - Руководитель отдела IT, 1 - IT-специалист и подрядчик ИП Волков И.Г..

1.7.3 Разработка ПО проводится специалистами компании ООО "МЭДЖИК ЛАЙФ" по адресу 350049, РОССИЯ, КРАСНОДАРСКИЙ КРАЙ, ГОРОД КРАСНОДАР Г.О., КРАСНОДАР Г., ИМ. КОСМОНАВТА ГАГАРИНА УЛ., Д. 232, ПОМЕЩ. 16.

1.7.4 Контактный телефон разработчиков: + 7 (929) 529-99-01, электронная почта: finance@4magic.ru

1.8 Процессы поддержки программного обеспечения «Мэджик Лайф».
Цель процесса поддержки и решения проблем в Программе заключается в обеспечении гарантии качества оказанных услуг по контракту (или договору) и того, что все выявленные запросы идентифицируются, анализируются, контролируются для осуществления их решения.
В процессе поддержки и решения проблем в Программе:
a) проблемы регистрируются, идентифицируются и классифицируются в систему управления запросами (далее -- СУЗ);
b) запросы анализируются и оцениваются для определения приемлемого решения (решений);
c) выполняется решение запросов;
d) запросы отслеживаются вплоть до их закрытия;
e) известно текущее состояние всех зафиксированных запросов;
f) предоставляются регулярные версии Программы (в случае оказания услуг по сопровождению);
g) проводятся регламентные работы.

1.8.1 Режим работы службы поддержки - с 9:00 до 18:00 MSK.

1.8.2 В процессе сопровождения задействовано 1 - Руководитель отдела IT, 1 - IT-специалист.

1.8.3 Фактический почтовый адрес, по которому осуществляется процесс сопровождения - 350049, РОССИЯ, КРАСНОДАРСКИЙ КРАЙ, ГОРОД КРАСНОДАР Г.О., КРАСНОДАР Г., ИМ. КОСМОНАВТА ГАГАРИНА УЛ., Д. 232, ПОМЕЩ. 16.

1.8.4 В процессе модернизации задействовано 1 - Руководитель отдела IT, 1 - IT-специалист. Фактический почтовый адрес, по которому осуществляется процесс модернизации - 350049, РОССИЯ, КРАСНОДАРСКИЙ КРАЙ, ГОРОД КРАСНОДАР Г.О., КРАСНОДАР Г., ИМ. КОСМОНАВТА ГАГАРИНА УЛ., Д. 232, ПОМЕЩ. 16.

1.8.5 В процессе гарантийного обслуживания задействовано 1 - Руководитель отдела IT, 1 - IT-специалист. Фактический почтовый адрес, по которому осуществляется процесс гарантийного обслуживания - 350049, РОССИЯ, КРАСНОДАРСКИЙ КРАЙ, ГОРОД КРАСНОДАР Г.О., КРАСНОДАР Г., ИМ. КОСМОНАВТА ГАГАРИНА УЛ., Д. 232, ПОМЕЩ. 16.

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

1.10. В процессе тестирования и эксплуатации программного обеспечения могут возникнуть сообщения о неисправности. В случае их возникновения необходимо осуществить процедуру передачи информации о характере ошибки в авторизованную сервисную компании ООО «МЭДЖИК ЛАЙФ». Устранение неисправностей и техническое обслуживание может осуществлять только квалифицированный персонал, а именно сотрудники авторизованной сервисной службы компании ООО «МЭДЖИК ЛАЙФ». Для оформления заявки на устранения неисправности необходимо перейти по ссылке на сайт авторизованной сервисной службы и оставить заявку на электронную почту: finance@4magic.ru


Также заявку можно отправить по адресу: 350049, РОССИЯ, КРАСНОДАРСКИЙ КРАЙ, ГОРОД КРАСНОДАР Г.О., КРАСНОДАР Г., ИМ. КОСМОНАВТА ГАГАРИНА УЛ., Д. 232, ПОМЕЩ. 16.