Опытная эксплуатация

1.4.6.2 Опытная эксплуатация

Результаты приемки ИС «ШК» в опытную эксплуатацию оформляют «Актом приемки в опытную эксплуатацию», составленным на основании «Протокола испытаний» комиссией, проводившей предварительные испытания системы.

Продолжительность опытной эксплуатации системы определяют по срокам, необходимым для проверки правильности функционирования системы при выполнении каждой автоматизированной функции, функции по представлению информации и готовности персонала к участию в выполнении всех автоматизированных функций и функций по представлению информации ИС «ШК».

Во время опытной эксплуатации системы ведется рабочий журнал, в который заносятся сведения: о продолжительности функционирования системы, о результатах наблюдения за правильностью функционирования системы, об отказах, сбоях, аварийных ситуациях, проводимых корректировках технической документации.

По результатам опытной эксплуатации системы составляют акт о завершении работ по проверке системы в режиме опытной эксплуатации.

1.4.6.3 Приемочные испытания системы

Приемочные испытания системы проводят для определения ее соответствия техническому заданию, требованиям стандарта и определения возможности ввода ИС «ШК» в действие.

Приемочной комиссии заказчик и разработчик предъявляют следующую документацию:

-           техническое задание на систему;

-           проект программы приемочных испытаний;

-           протокол предварительных испытаний;

-           акт приемки системы в опытную эксплуатацию;

-           рабочие журналы опытной эксплуатации системы;

-           акт о завершении работ по проверке системы в режиме опытной эксплуатации;

-           техническая документация на систему.

По результатам приемочных испытаний приемочная комиссия составляет протокол испытаний и акт о вводе системы в действие.

1.4.7 Требования к составу и содержанию работ по подготовке объекта информатизации к вводу системы в действие

Одновременно с разработкой системы должно быть обеспечено проведение следующих мероприятий:

-           определить конкретных лиц, ответственных от СП «ШК» ГОУ ВПО «СибГИУ» за подготовку системы к эксплуатации;

-           обозначить места установки технических средств и обеспечить их сохранность;

-           организовать подготовку персонала для работы с системой.

1.4.8 Требования к документированию

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

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

Комплект документации по системе приведен в приложении 2.

1.4.9 Заключение

В ходе разработки ИС «ШК» было установлено, что в комплекте с ЭШД было поставлено неработоспособное программное обеспечение. Но так как необходимо было в срочном порядке закончить работы по созданию системы, а на выяснение причин и дополнительную поставку ушло бы значительное время вследствие того, что оборудование поставлялось из Нидерландов, было принято решение в срочном порядке пригласить специалистов из информационного шахматного центра российской шахматной федерации, владеющих собственным программным обеспечением для ЭШД, на время проведения соревнований, что повлекло за собой большие расходы.

После разработки ИС «ШК», ее приемки и проведения опытной эксплуатации руководством ГОУ ВПО «СибГИУ» в тесном сотрудничестве с администрацией г. Новокузнецка и администрацией Кемеровской области было принято решение перенести ИС «ШК» в помещение культурного центра «Западносибирского металлургического комбината» («ЗСМК») на время проведения Всемирной шахматной универсиады, которая проходила в г. Новокузнецке с 3 марта по 11 марта 2008 года. Перенесение ИС «ШК» в помещение культурного центра «ЗСМК» не составило больших трудностей, так как все блоки системы легко отсоединяемы и транспортируемы.

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

2. Специальная часть

2.1 Выбор основных методологий разработки программного обеспечения

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

Выбор и адаптация жизненного цикла разработки проекта оказывает влияние на методики разработки продукта, навыки менеджмента проектов и навыки менеджмента персонала. Что касается методов разработки продукта, руководитель проекта должен, прежде всего, иметь представление о стандартах процесса, уметь оценить их применимость по отношению к данному проекту, оценить альтернативные процессы и при необходимости адаптировать процесс жизненного цикла к текущим потребностям. На выбор методов и инструментальных средств также может оказывать влияние выбор жизненного цикла.

Модель жизненного цикла разработки программного обеспечения (ПО) является единственным видом процесса, в котором представлен порядок его осуществления. Модель жизненного цикла разработки ПО (Software Life Cycle Model, SLCM) схематически объясняет, каким образом будут выполняться действия по разработке программного продукта, посредством описания «последовательности» этих действий. Такая последовательность может быть или не быть линейной, поскольку фазы могут следовать друг за другом, повторяться или происходить одновременно. На рисунке 5 представлена простая обобщенная схема процесса.

Жизненный цикл

Процесс

Рисунок 5 – Обобщенная схема процесса

Модель SLCM – это схема (или основа), используемая разработчиком ПО для определения повторяющегося процесса при создании программного продукта. Она определяет точные инструкции, которые разработчик может использовать для создания только высококачественных программных систем. Понятие жизненного цикла ПО относится ко всем программным проектам, причем независимо от их размеров.

Жизненный цикл – это своего рода «карта-путеводитель» для всех участников проекта, которая помогает им понять, не выходят ли они за определенные для них границы. Для управления программным проектом возникает необходимость в некотором роде карты для планирования действий и хронологий их выполнения.

В стандарт были включены описания причин, объясняющих необходимость выполнения стандартизированного процесса. Этот стандарт помогает достичь следующих целей.

·          Улучшение и обеспечение качества:

-            с помощью стандартизированной процедуры можно наилучшим образом гарантировать завершенность результатов, которые необходимо предоставить;

-            определение промежуточных результатов обеспечивает возможность ускорить выполнение оценочных процедур;

-            контекст однородных продуктов облегчает их восприятие, а также работу с процедурами оценки.

·          Возможность проверки затрат на выполнение полного жизненного цикла:

-            упрощает процесс создания стандартов разработки для определенного проекта и его оценка;

-            стандартизированные процедуры повышают степень «прозрачности» операций по определению затрат и позволяют более эффективно распознавать возможные риски, связанные с затратами;

-            одинаковые стандарты уменьшают риск возникновения разногласий между клиентом и разработчиком, а также между главным разработчиком и субподрядчиком;

-            в случае применения стандартизированной процедуры становятся «прозрачными» универсальные подходы к методам решения, а следовательно, их можно использовать повторно;

-            нежелательный ход процесса разработки, возможно, выявить на ранней стадии;

-            уменьшаются затраты на подготовку персонала.

·          Улучшается обмен информацией между различными сторонами, участвующими в процессе разработки; происходит снижение зависимости клиента от подрядчика:

-            использование определенных терминов уменьшает разногласия, возникающие между всеми задействованными в проекте сторонами;

-            пользователь, покупатель и разработчик получают поддержку при формулировании своих требований, а также при описании своих ролей или полученных результатов;

-            промежуточные и окончательные результаты стандартизируются таким образом, что другие задействованные в проекте стороны или персонал других компаний могут в случае необходимости подключиться к процессу разработки, не прилагая при этом больших дополнительных усилий.

«Каркасом» процесса разработки ПО служит модель зрелости функциональных возможностей (Capability Maturity Model, CMM). Она основана на практических действиях, отображает лучшие результаты и определяет потребности индивидов, работающих над усовершенствованием процесса разработки ПО и выполняющих оценочный анализ этого процесса. Модель СММ представляет собой схему, по которой этапы разработки соответствуют пяти уровням развития функциональных возможностей, на основе которых осуществляется непрерывное усовершенствование процесса разработки.

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

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

Определенный. Во всех проектах используется испытанная, адаптированная версия стандартного процесса разработки ПО данной организации.

Управляемый. Собираются детальные показатели процесса разработки ПО и качественные характеристики продукта. Управление процессом разработки программных продуктов осуществляется на количественном уровне.

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

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

Цель определения организационной структуры процесса заключается в разработке и сопровождении стандартного процесса разработки ПО для данной организации.

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

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