32
и этапы работ, выполнение которых необходимо и достаточно для создания АС,
соответствующей заданным требованиям. Стадии и этапы создания АС выделяют-
ся как части процесса создания по соображениям рационального планирования и
организации работ, заканчивающихся заданным результатом. Работы по развитию
АС осуществляют по стадиям и этапам, применяемым для создания АС.
Microsoft Solutions Framework (MSF) — методология разработки программ-
ного обеспечения, предложенная корпорацией Microsoft. Модель проектной груп-
пы MSF описывает подход Майкрософт к организации работающего над проектом
персонала и его деятельности в целях максимизации успешности проекта. Данная
модель определяет ролевые кластеры, их области компетенции и зоны ответствен-
ности, а также рекомендации членам проектной группы, позволяющие им успешно
осуществить свою миссию по воплощению проекта в жизнь. В соответствии с мо-
делью MSF проектные группы строятся как небольшие многопрофильные коман-
ды, члены которых распределяют между собой ответственность и дополняют обла-
сти компетенций друг друга. В проектную группу входят такие ролевые кластеры:
управление программой, управление продуктом, разработка, тестирование, управ-
ление релизом, удовлетворение потребителя. Модель процессов включает такие
основные фазы процесса разработки: Выработка концепции, планирование, разра-
ботка, стабилизация, внедрение.
Rational Unified Process (RUP) — методология разработки программного
обеспечения, созданная компанией Rational Software. RUP использует итеративную
модель разработки. В конце каждой итерации проектная команда должна достичь
запланированных на данную итерацию целей, создать или доработать проектные
артефакты и получить промежуточную, но функциональную версию конечного
продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся
требования, обнаруживать и устранять риски на ранних стадиях проекта, а также
эффективно контролировать качество создаваемого продукта. Полный жизненный
цикл разработки продукта состоит из четырех фаз, каждая из которых включает в
себя одну или несколько итераций: начало (формируются видение и границы про-
екта, создается экономическое обоснование), уточнение (документирование требо-
ваний, спроектированная, реализованная и оттестированная исполняемую архи-
тектура), построение (реализация большей части функциональности продукта,
33
внедрение (создается финальная версия продукта и передается от разработчика к
заказчику) [9].
Для выполнения данного проекта выбрана модель жизненного цикла в соот-
ветствии с ГОСТ Р ИСО/МЭК 12207-99 [1]. Данная модель выбрана исходя из того,
что в ней разделены процессы поставки и разработки, поскольку в разрабатывае-
мом проекте предполагается разработка новой конфигурации на имеющейся плат-
форме.
В соответствии с ГОСТ Р ИСО/МЭК 12207-99, работы, которые могут вы-
полняться в жизненном цикле программных средств, распределены по пяти основ-
ным, восьми вспомогательным и четырем организационным процессам. Каждый
процесс жизненного цикла разделен на набор работ; каждая работа разделена на
набор задач.
Основные процессы жизненного цикла состоят из пяти процессов, которые
реализуются под управлением основных сторон, вовлеченных в жизненный цикл
программных средств. Под основной стороной понимают одну из тех организаций,
которые инициируют или выполняют разработку, эксплуатацию или сопровожде-
ние программных продуктов. Основными сторонами являются заказчик, постав-
щик, разработчик, оператор и персонал сопровождения программных продуктов
[8].
Основными процессами являются:
1) Процесс заказа. Определяет работы заказчика, то есть организации, кото-
рая приобретает систему, программный продукт или программную услугу.
2) Процесс поставки. Определяет работы поставщика, то есть организации,
которая поставляет систему, программный продукт или программную услугу за-
казчику.
3) Процесс разработки. Определяет работы разработчика, то есть организа-
ции, которая проектирует и разрабатывает программный продукт.
4) Процесс эксплуатации. Определяет работы оператора, то есть организа-
ции, которая обеспечивает эксплуатационное обслуживание вычислительной си-
стемы в заданных условиях в интересах пользователей.
5) Процесс сопровождения. Определяет работы персонала сопровождения,
то есть организации, которая предоставляет услуги по сопровождению программ-
34
ного продукта, состоящие в контролируемом изменении программного продукта с
целью сохранения его исходного состояния и функциональных возможностей.
Данный процесс охватывает перенос и снятие с эксплуатации программного про-
дукта.
Вспомогательные процессы жизненного цикла
Вспомогательные процессы жизненного цикла состоят из восьми процессов.
Вспомогательный процесс является целенаправленной составной частью другого
процесса, обеспечивающей успешную реализацию и качество выполнения про-
граммного проекта. Вспомогательный процесс, при необходимости, инициируется
и используется другим процессом. Вспомогательными процессами являются:
1) Процесс документирования. Определяет работы по описанию информа-
ции, выдаваемой в процессе жизненного цикла.
2) Процесс управления конфигурацией. Определяет работы по управлению
конфигурацией.
3) Процесс обеспечения качества. Определяет работы по объективному
обеспечению того, чтобы программные продукты и процессы соответствовали тре-
бованиям, установленным для них, и реализовывались в рамках утвержденных
планов. Совместные анализы, аудиторские проверки, верификация и аттестация
могут использоваться в качестве методов обеспечения качества.
4) Процесс верификации. Определяет работы (заказчика, поставщика или не-
зависимой стороны) по верификации программных продуктов по мере реализации
программного проекта.
5) Процесс аттестации. Определяет работы (заказчика, поставщика или неза-
висимой стороны) по аттестации программных продуктов программного проекта.
6) Процесс совместного анализа. Определяет работы по оценке состояния и
результатов какой-либо работы. Данный процесс может использоваться двумя лю-
быми сторонами, когда одна из сторон (проверяющая) проверяет другую сторону
(проверяемую) на совместном совещании.
7) Процесс аудита. Определяет работы по определению соответствия требо-
ваниям, планам и договору. Данный процесс может использоваться двумя сторо-
нами, когда одна из сторон (проверяющая) контролирует программные продукты
или работы другой стороны (проверяемой).
35
8) Процесс решения проблемы. Определяет процесс анализа и устранения
проблем (включая несоответствия), независимо от их характера и источника, кото-
рые были обнаружены во время осуществления разработки, эксплуатации, сопро-
вождения или других процессов.
Организационные процессы жизненного цикла
Организационные процессы жизненного цикла состоят из четырех процес-
сов. Они применяются в какой-либо организации для создания и реализации ос-
новной структуры, охватывающей взаимосвязанные процессы жизненного цикла и
соответствующий персонал, а также для постоянного совершенствования данной
структуры и процессов. Эти процессы, как правило, являются типовыми, независи-
мо от области реализации конкретных проектов и договоров; однако уроки, извле-
ченные из таких проектов и договоров, способствуют совершенствованию органи-
зационных вопросов. Организационными процессами являются:
1) Процесс управления. Определяет основные работы по управлению, вклю-
чая управление проектом, при реализации процессов жизненного цикла.
2) Процесс создания инфраструктуры. Определяет основные работы по со-
зданию основной структуры процесса жизненного цикла.
3) Процесс усовершенствования. Определяет основные работы, которые ор-
ганизация (заказчика, поставщика, разработчика, оператора, персонала сопровож-
дения или администратора другого процесса) выполняет при создании, оценке,
контроле и усовершенствовании выбранных процессов жизненного цикла.
4) Процесс обучения. Определяет работы по соответствующему обучению
персонала [8].
Ключевые положения основных процессов жизненного цикла отражены в
таблице 3.
36
Таблица 3
Основные положения процессов жизненного цикла
Этап
Задачи этапа
Ключе-
вые
участ-
ники
Требования
к входной
информа-
ции
Получаемые
результаты
Процесс
заказа
Определение заказ-
чиком требований к
системе, условий до-
говора, прием заказа
Заказчик
Анализ функ-
ционирова-
ния органи-
зации,
требования
заказчика
Требования к си-
стеме, заявка,
договор с по-
ставщиком
Процесс
поставки
Анализ требований,
реализация продук-
та, опытная эксплуа-
тация, сопровожде-
ние
Постав-
щик
Заявка за-
казчика, тре-
бования к си-
стеме
План управления
проектом, отчеты
о проделанной
работе и испыта-
ниях
Разра-
ботка
Анализ требований,
проектирование,
программирование,
сборка, тестирова-
ние, ввод в действие
и приемка программ
Разра-
ботчик
Требования
заказчика,
план управ-
ления проек-
том
Отчет о проде-
ланной работе,
приемке испыта-
ний, разработан-
ные подсистемы
Эксплуа-
тация
Эксплуатация про-
граммного продукта
и поддержка пользо-
вателей в процессе
эксплуатации
Мене-
джер
Разработан-
ный продукт
Сведенья о воз-
никающих про-
блемах
Сопро-
вожде-
ние
Изменение суще-
ствующего про-
граммного продукта
при сохранении его
целостности
Персо-
нал со-
провож-
дения
Сведенья о
возникающих
проблемах,
требования
по измене-
нию
Снятие про-
граммного про-
дукта с эксплуа-
тации
ГОСТ Р ИСО/МЭК 12207-99 вводит понятие модели жизненного цикла как
структуры, состоящей из процессов, и охватывающей жизнь системы от установ-
ления требований к ней до прекращения ее использования. К настоящему времени
наибольшее распространение получили две основные модели жизненного цикла:
каскадная (водопадная) модель;
спиральная модель.
Каскадная модель демонстрирует классический подход к разработке различ-
ных систем в различных прикладных областях. Каскадная модель предусматривает
последовательную организацию процессов. Причем переход к следующему про-
цессу происходит только после того, как полностью завершены все работы на
37
предыдущем. Каждый процесс завершается выпуском полного комплекта докумен-
тации, достаточной для того, чтобы работа могла быть продолжена другой коман-
дой разработчиков. Главный недостаток каскадной модели заключается в том, что
ошибки и недоработки на любом из этапов проявляются, как правило, на последу-
ющих этапах работ, что приводит к необходимости возврата назад.
В отличие от каскадной, спиральная модель предполагает итерационный
процесс разработки информационной системы. На каждой итерации углубляются и
последовательно конкретизируются детали проекта, собираются метрические дан-
ные, которые используются для оптимизации последующих итераций.
Поэтому для разработки проекта выбирается спиральная модель жизненного
цикла.
Внедрение программного продукта осуществляется на этапе разработки.
Стратегия внедрения предполагает следующие этапы:
1. Разработка конфигурации для автоматизации учета заявок. Данные работы
выполняются разработчиком.
2. Внедрение доработанной версии программного обеспечения в типовые
конфигурации (в данном случае – 1С:Бухгалтерия). Данные работы выполняются
разработчиком.
3. Тестирование на площадке заказчика силами заказчика.
4. Обучение персонала. В соответствии с договором может осуществляться
силами поставщика или разработчика (в данном случае - разработчика).
5. Плавный переход на разработанную систему: перенос необходимой ин-
формации в новые информационные базы, на промежуточном этапе – дублирова-
ние информации в старой и новой базах, на последнем этапе – отказ от старых баз
и полный переход на новый программный продукт.
Данный проект предусматривает автоматизацию отдельных бизнес процес-
сов, объединенных по набору выполняемых функций. При этом существуют участ-
ки, где применение автоматизированных систем дает значительный экономический
эффект, например за счет сокращения персонала, или сокращения времени работы
с документами. В подобной ситуации выбирается автоматизация по участкам.
Стратегия внедрения выбирается из следующих вариантов:
38
1. Параллельная стратегия - подразумевает одновременную работу старой
(ручной) и новой систем, и их выходные документы сравниваются. Если они согла-
суются длительное время, осуществляется переход на новую систему.
2. «Скачок» - предусматривает полный отказ от работающей системы и мо-
ментальный и безусловный переход на новую ИС. Это может стимулировать поль-
зователей системы к быстрому ее освоению, однако возникает большая вероят-
ность остановки технологического процесса получения и обработки информации
при условии, если в новой системе возникнет сбой.
3. «Пилотный проект» - это тактика «скачка», но применяемая к ограничен-
ному числу процессов. Область применения стратегии - небольшой участок дея-
тельности. Такой подход снижает риск и наиболее надежен.
4. «Узкое место» - предполагает, что план внедрения выполняется только для
«узкого места» и для людей, работающих в нем. Точность данных повышается
только для изделий в этом «узком месте»; переподготовка - только для людей, ра-
ботающих в нем; анализ эффекта затрат делается только для него и т.д. [2].
Данный проект предполагает автоматизацию всего набора функций по учету
рабочего времени, поэтому стратегии «Узкое место» и «Пилотный проект» для
данного проекта не подходят. Стратегия «Скачок» слишком рискованная, особенно
для предприятий, работающих в реальном времени и осуществляющих свою дея-
тельность «здесь и сейчас». Поэтому для внедрения проекта выбирается парал-
лельная стратегия.
План по вводу в действие автоматизированной системы следующий:
1. Анализ бизнес-процессов, определение функционала разрабатываемой
автоматизированной системы.
2. Разработка автоматизированной системы. Данные работы выполняются
разработчиком.
3. Внедрение разработанной автоматизированной системы. Данные работы
выполняются разработчиком.
4. Тестирование на площадке заказчика силами заказчика.
5. Обучение персонала. В соответствии с договором может осуществляться
силами поставщика или разработчика (в данном случае - разработчика).
39
6. Плавный переход на разработанную систему: Занесение основных спра-
вочников, на первом этапе – дублирование информации в программе и на бумаж-
ных носителях, при полностью отлаженной работе с системой – полный отказ от
бумажных носителей. Выполняется силами заказчика.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
На различных этапах жизненного цикла проекта возможны следующие рис-
ки:
1. Процесс заказа: возможные риски связаны с некачественной работой
персонала. При определении требований к разрабатываемой системе заказчик мо-
жет некачественно описать предметную область, неточно указать функции подси-
стем, что может привести к необходимости переделки продукта на этапе внедре-
ния. Для уменьшения данного риска необходимо принимать участие в разработке
требований и описании предметной области, а также использоваться Case-средства
для ее описания.
2. Процесс поставки: возможны проблемы безопасности при настройке
серверов под готовый программный продукт. Для уменьшения рисков необходимо
детально разработать требования к безопасности, определить функции и права до-
ступа для каждой группы пользователей, а также определить общие требования к
безопасности серверов.
3. Процесс разработки: возможны риски, связанные с недостаточностью
технических и программных средств для реализации поставленных задач. Также
возможны риски, связанные с недостаточностью данных для решения поставлен-
ных задач. Для уменьшения рисков на данном этапе необходимо полно обследо-
вать доступные технические и программные средства, предоставляемые для реали-
зации поставленных задач и предусмотреть возможность наращивания технических
и программных средств организации.
4. Процессы эксплуатации и сопровождения: возможны риски, связан-
ные с неготовностью персонала к переходу на новую систему учета, сложностью
переноса больших объемов данных в новую информационную базу, нехваткой пер-
сонала для переноса данных или ведения учета параллельно в 2 системах при плав-
ном переходе. Для уменьшения рисков на данных этапах необходимо проработать
40
и согласовать детальный план перехода на новую систему учета с указанием ответ-
ственных лиц, разработать должностные инструкции и регламенты.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Данный проект предназначен для автоматизации учета заявок клиентов. Ин-
формационная система должна использоваться различными пользователями. По-
этому предлагается ряд шагов по защите информации.
Обеспечение информационной безопасности предполагает защиту от не-
санкционированного доступа, обеспечение целостности и доступности информа-
ции [7].
Защита от несанкционированного доступа возможна как извне, так и внутри
организации. В информационной системе хранятся персональные данные, но не
хранится информация, являющаяся коммерческой тайной предприятия. Поэтому
угрозы несанкционированного доступа к данным все же являются опасными. В
информационной системе предусмотрено функции, требующие подключения к се-
ти Интернет: получение заявок от клиентов по электронной почте. Поэтому в целях
безопасности и защиты от несанкционированного доступа предлагается минимизи-
ровать время подключения компьютеров пользователей к сети Интернет, ограни-
чить использование данной сети только для отправки необходимых почтовый со-
общений с использованием почтового клиента.
Для защиты от несанкционированного доступа к информации пользователей
системы необходимо произвести разграничение доступа, организовать парольную
защиту информационной базы. С информационной системой могут работать два
типа пользователей:
- Менеджеры: заносят заявки и информацию по реализации, оформляют до-
говора, ведут перечень продукции поставщиков;
- Руководство: анализирует работу с помощью отчетов.
Таким образом, организационно разграничить доступ можно в соответствии
с таблицей 4.
41
Таблица 4
Разграничение доступа к объектам информационной базы
Группы пользо-
вателей
Работа со спра-
вочниками
Работа с доку-
ментами
Получение от-
четности
Менеджеры
Редактирование
Редактирование
Создание
Руководство
-
-
Создание
Программное разграничение доступа к информационной базе обеспечивает-
ся средствами 1С.
Система 1С предоставляет следующие возможности [6]:
- Настройка прав доступа пользователей (определение ролей) с помощью
профилей и групп доступа.
- Настройка ограничений прав пользователей для элементов данных инфор-
мационной базы (элементов справочников, документов, записей регистров и т.д.).
Для каждой группы пользователей в конфигурации требуется определять от-
дельный интерфейс: главное меню, набор и состав панелей инструментов.
Интерфейс следует проектировать таким образом, чтобы группе пользовате-
лей, с одной стороны, был доступен необходимый набор действий, а с другой, не
предоставлялся доступ к действиям, на которые нет прав. Вызовы наиболее часто
выполняемых пользователем действий в интерфейсе лучше располагать так, чтобы
они были наиболее доступны, и наоборот.
Помимо защиты от несанкционированного доступа необходимо обеспечить
доступность и целостность информации. Для этого необходимо обеспечить следу-
ющее:
- обеспечить регулярное сохранение информационной базы (не менее 1 раза
в день) на внешнем носителе, например – на съемном диске. Это можно делать
стандартными средствами 1С (с помощью сервиса «Выгрузить информационную
базу») или с помощью дополнительных средств (например, Handy Backup - реше-
ние для автоматизации резервного копирования данных 1С, которое упрощает ра-
боту администраторов и подстраховывает пользователей 1С в случае ошибки). Для
этого необходимо разработать соответствующую инструкцию для менеджера кур-
сов.
- обеспечить антивирусную защиту. Поскольку предполагается ограничить
выход в сеть Интернет с используемых ПК, а также не предполагается использова-