37
• в системе «1С:Предприятие 8.3» достаточно легко выполнять опера-
ции администрирования, решать вопросы обработки транзакций, разграниче-
ния прав пользователей и интеграции с программными продуктами, входя-
щими в состав Microsoft Office, поскольку все эти вопросы платформа берет
на себя. Поэтому для решения задачи достаточно реализации бизнес-логики
приложения, не тратя время на решения технических вопросов [5].
Таким образом, выбор для реализации системы на платформе «1С:Пред-
приятие 8.3» обоснован.
1.4.3 Обоснование проектных решений по техническому обеспечению
Поскольку разрабатываемая система будет реализована в системе
«1С:Предприятие 8.3», необходимо, чтобы техническое обеспечение удовле-
творяло следующим требованиям:
32-разрядный сервер 1С:Предприятия:
Процессор Intel Pentium IV/Xeon 2,4 ГГц и выше
Оперативная память 1024 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
64-разрядный сервер 1С:Предприятия:
Процессор с архитектурой x86-64 (Intel с поддержкой EM64T, AMD с
поддержкой AMD64).
Оперативная память 2048 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
Сервер баз данных:
38
Технические характеристики компьютера и операционная система
должны соответствовать требованием Microsoft SQL Server, PostgreSQL, IBM
DB2, Oracle Database.
Клиентское приложение - это программа, работающая на компьютере
пользователя и обеспечивающая интерактивное взаимодействие системы
1С:Предприятие 8 с пользователем, в отличие от других компонент системы
(программ и рабочих процессов), предназначенных исключительно для про-
граммного взаимодействия с другими частями системы или с другими про-
граммными объектами.
В системе 1С:Предприятие 8 существует 3 клиентских приложения:
1) Толстый клиент, который позволяет реализовывать полные возмож-
ности 1С:Предприятия 8.3 в плане исполнения прикладного кода. Однако он
не поддерживает работу с информационными базами через интернет, требует
предварительной установки на компьютер пользователя и имеет довольно вну-
шительный объем дистрибутива. Требования к толстому клиенту:
Процессор Intel Pentium Celeron 2400 Мгц и выше
Оперативная память 1024 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
2) Тонкий клиент может работать с информационными базами через ин-
тернет. Он также требует предварительной установки на компьютер пользова-
теля, но имеет значительно меньший размер дистрибутива, чем толстый кли-
ент. Системны требования:
Процессор Intel Pentium Celeron 1800 Мгц и выше
Оперативная память 256 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
39
SVGA-видеокарта
Веб-клиент не требует какой-либо предварительной установки на ком-
пьютер. В отличие от толстого и тонкого клиентов, он исполняется не в среде
операционной системы компьютера, а в среде интернет-браузера. Поэтому
пользователю достаточно всего лишь запустить свой браузер, ввести адрес
веб-сервера, на котором опубликована информационная база – и веб-клиент
будет исполняться на компьютере пользователя. Требования к веб-клиенту:
Процессор Intel Pentium Celeron 1800 Мгц и выше
Оперативная память 256 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
SVGA-видеокарта
Компьютеры должны быть укомплектованы мышью, клавиатурой, сете-
выми шнурами.
Компьютер должен предоставляться для сертификации в той програм-
мно-аппаратной конфигурации, в которой он будет поставляться потребителю
[15].
Вместе с компьютером должен поставляться комплект необходимых
драйверов под соответствующие операционные системы.
Конфигурация компьютера должна соответствовать спецификации
(Hardware Compatibility List) для используемых операционных систем.
Разрабатываемая система должна использоваться следующими пользо-
вателями:
- менеджерами по работе с клиентами;
- механиками;
- руководством организации.
Поэтому необходимо разработка приложения клиент-серверной архи-
тектуры, а следовательно – наличие выделенного сервера для базы данных си-
стемы.
40
Существующая техническая архитектура предприятия полностью удо-
влетворяет заявленным требованиям.
41
ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Для создания модели жизненного цикла используются различные стан-
дарты.
Стандарт ГОСТ Р ИСО/МЭК 15288—2005 устанавливает общие основы
для описания жизненного цикла систем, созданных людьми, определяет де-
тально структурированные процессы и соответствующую терминологию. В
стандарте представлены также процессы, которые поддерживают определе-
ние, контроль и совершенствование процессов жизненного цикла внутри ор-
ганизации или в рамках какого-либо проекта. Организации и проекты могут
применять эти процессы при приобретении и поставке систем. Стандарт при-
меним к полному жизненному циклу системы, включая замысел, разработку,
производство, эксплуатацию и снятие с эксплуатации, а также приобретение и
поставку систем, осуществляемых внутри или вне организации. Процессы
жизненного цикла, представленные в стандарте, могут применяться одно-
кратно, многократно и рекурсивно по отношению к системе и ее элементам.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 охватывает жизненный цикл про-
граммных средств от концепции замыслов через определение и объединение
процессов для заказа и поставки программных продуктов и услуг. Стандарт
устанавливает, используя четко определенную терминологию, общую струк-
туру процессов жизненного цикла программных средств, на которую можно
ориентироваться в программной индустрии. Стандарт определяет процессы,
работы и задачи, которые используются: при приобретении системы, содержа-
щей программные средства, или отдельно поставляемого программного про-
дукта; при оказании программной услуги, а также при поставке, разработке,
эксплуатации и сопровождении программных продуктов.
Жизненный цикл процесса создания АСУ согласно ГОСТ 34 включает
следующие стадии: Формирование требований к АС, разработка концепции
42
АС, техническое задание, эскизный проект, технический проект, рабочая до-
кументация, ввод в действие, сопровождение АС. Процесс создания АС пред-
ставляет собой совокупность упорядоченных во времени, взаимосвязанных,
объединённых в стадии и этапы работ, выполнение которых необходимо и до-
статочно для создания АС, соответствующей заданным требованиям. Стадии
и этапы создания АС выделяются как части процесса создания по соображе-
ниям рационального планирования и организации работ, заканчивающихся за-
данным результатом. Работы по развитию АС осуществляют по стадиям и эта-
пам, применяемым для создания АС.
Microsoft Solutions Framework (MSF) — методология разработки про-
граммного обеспечения, предложенная корпорацией Microsoft. Модель про-
ектной группы MSF описывает подход Майкрософт к организации работаю-
щего над проектом персонала и его деятельности в целях максимизации
успешности проекта. Данная модель определяет ролевые кластеры, их области
компетенции и зоны ответственности, а также рекомендации членам проект-
ной группы, позволяющие им успешно осуществить свою миссию по вопло-
щению проекта в жизнь. В соответствии с моделью MSF проектные группы
строятся как небольшие многопрофильные команды, члены которых распре-
деляют между собой ответственность и дополняют области компетенций друг
друга. В проектную группу входят такие ролевые кластеры: управление про-
граммой, управление продуктом, разработка, тестирование, управление рели-
зом, удовлетворение потребителя. Модель процессов включает такие основ-
ные фазы процесса разработки: Выработка концепции, планирование, разра-
ботка, стабилизация, внедрение.
Rational Unified Process (RUP) — методология разработки программного
обеспечения, созданная компанией Rational Software. RUP использует итера-
тивную модель разработки. В конце каждой итерации проектная команда
должна достичь запланированных на данную итерацию целей, создать или до-
работать проектные артефакты и получить промежуточную, но функциональ-
ную версию конечного продукта. Итеративная разработка позволяет быстро
43
реагировать на меняющиеся требования, обнаруживать и устранять риски на
ранних стадиях проекта, а также эффективно контролировать качество созда-
ваемого продукта. Полный жизненный цикл разработки продукта состоит из
четырех фаз, каждая из которых включает в себя одну или несколько итера-
ций: начало (формируются видение и границы проекта, создается экономиче-
ское обоснование), уточнение (документирование требований, спроектиро-
ванная, реализованная и оттестированная исполняемую архитектура), постро-
ение (реализация большей части функциональности продукта, внедрение (со-
здается финальная версия продукта и передается от разработчика к заказчику)
[9].
Для выполнения данного проекта выбрана модель жизненного цикла в
соответствии с ГОСТ Р ИСО/МЭК 12207-99 [1]. Данная модель выбрана ис-
ходя из того, что в ней разделены процессы поставки и разработки, поскольку
в разрабатываемом проекте предполагается разработка новой конфигурации
на имеющейся платформе.
В соответствии с ГОСТ Р ИСО/МЭК 12207-99, работы, которые могут
выполняться в жизненном цикле программных средств, распределены по пяти
основным, восьми вспомогательным и четырем организационным процессам.
Каждый процесс жизненного цикла разделен на набор работ; каждая работа
разделена на набор задач.
Основные процессы жизненного цикла состоят из пяти процессов, кото-
рые реализуются под управлением основных сторон, вовлеченных в жизнен-
ный цикл программных средств. Под основной стороной понимают одну из
тех организаций, которые инициируют или выполняют разработку, эксплуата-
цию или сопровождение программных продуктов. Основными сторонами яв-
ляются заказчик, поставщик, разработчик, оператор и персонал сопровожде-
ния программных продуктов [8].
Основными процессами являются:
44
1) Процесс заказа. Определяет работы заказчика, то есть организации,
которая приобретает систему, программный продукт или программную
услугу.
2) Процесс поставки. Определяет работы поставщика, то есть организа-
ции, которая поставляет систему, программный продукт или программную
услугу заказчику.
3) Процесс разработки. Определяет работы разработчика, то есть орга-
низации, которая проектирует и разрабатывает программный продукт.
4) Процесс эксплуатации. Определяет работы оператора, то есть органи-
зации, которая обеспечивает эксплуатационное обслуживание вычислитель-
ной системы в заданных условиях в интересах пользователей.
5) Процесс сопровождения. Определяет работы персонала сопровожде-
ния, то есть организации, которая предоставляет услуги по сопровождению
программного продукта, состоящие в контролируемом изменении программ-
ного продукта с целью сохранения его исходного состояния и функциональ-
ных возможностей. Данный процесс охватывает перенос и снятие с эксплуа-
тации программного продукта.
Вспомогательные процессы жизненного цикла
Вспомогательные процессы жизненного цикла состоят из восьми про-
цессов. Вспомогательный процесс является целенаправленной составной ча-
стью другого процесса, обеспечивающей успешную реализацию и качество
выполнения программного проекта. Вспомогательный процесс, при необходи-
мости, инициируется и используется другим процессом. Вспомогательными
процессами являются:
1) Процесс документирования. Определяет работы по описанию инфор-
мации, выдаваемой в процессе жизненного цикла.
2) Процесс управления конфигурацией. Определяет работы по управле-
нию конфигурацией.
3) Процесс обеспечения качества. Определяет работы по объективному
обеспечению того, чтобы программные продукты и процессы соответствовали
45
требованиям, установленным для них, и реализовывались в рамках утвержден-
ных планов. Совместные анализы, аудиторские проверки, верификация и ат-
тестация могут использоваться в качестве методов обеспечения качества.
4) Процесс верификации. Определяет работы (заказчика, поставщика
или независимой стороны) по верификации программных продуктов по мере
реализации программного проекта.
5) Процесс аттестации. Определяет работы (заказчика, поставщика или
независимой стороны) по аттестации программных продуктов программного
проекта.
6) Процесс совместного анализа. Определяет работы по оценке состоя-
ния и результатов какой-либо работы. Данный процесс может использоваться
двумя любыми сторонами, когда одна из сторон (проверяющая) проверяет
другую сторону (проверяемую) на совместном совещании.
7) Процесс аудита. Определяет работы по определению соответствия
требованиям, планам и договору. Данный процесс может использоваться
двумя сторонами, когда одна из сторон (проверяющая) контролирует про-
граммные продукты или работы другой стороны (проверяемой).
8) Процесс решения проблемы. Определяет процесс анализа и устране-
ния проблем (включая несоответствия), независимо от их характера и источ-
ника, которые были обнаружены во время осуществления разработки, эксплу-
атации, сопровождения или других процессов.
Организационные процессы жизненного цикла
Организационные процессы жизненного цикла состоят из четырех про-
цессов. Они применяются в какой-либо организации для создания и реализа-
ции основной структуры, охватывающей взаимосвязанные процессы жизнен-
ного цикла и соответствующий персонал, а также для постоянного совершен-
ствования данной структуры и процессов. Эти процессы, как правило, явля-
ются типовыми, независимо от области реализации конкретных проектов и до-
46
говоров; однако уроки, извлеченные из таких проектов и договоров, способ-
ствуют совершенствованию организационных вопросов. Организационными
процессами являются:
1) Процесс управления. Определяет основные работы по управлению,
включая управление проектом, при реализации процессов жизненного цикла.
2) Процесс создания инфраструктуры. Определяет основные работы по
созданию основной структуры процесса жизненного цикла.
3) Процесс усовершенствования. Определяет основные работы, которые
организация (заказчика, поставщика, разработчика, оператора, персонала со-
провождения или администратора другого процесса) выполняет при создании,
оценке, контроле и усовершенствовании выбранных процессов жизненного
цикла.
4) Процесс обучения. Определяет работы по соответствующему обуче-
нию персонала [16].
Ключевые положения основных процессов жизненного цикла отражены
в таблице 6.
Таблица 6
Основные положения процессов жизненного цикла
Этап
Задачи этапа
Ключе-
вые
участ-
ники
Требования
к входной
информа-
ции
Получаемые
результаты
Процесс
заказа
Определение заказ-
чиком требований к
системе, условий до-
говора, прием заказа
Заказчик
Анализ функ-
ционирова-
ния организа-
ции,
требования
заказчика
Требования к си-
стеме, заявка,
договор с постав-
щиком
Процесс
поставки
Анализ требований,
реализация про-
дукта, опытная экс-
плуатация, сопро-
вождение
Постав-
щик
Заявка заказ-
чика, требо-
вания к си-
стеме
План управления
проектом, отчеты
о проделанной
работе и испыта-
ниях
Разра-
ботка
Анализ требований,
проектирование,
программирование,
сборка, тестирова-
ние, ввод в действие
и приемка программ
Разра-
ботчик
Требования
заказчика,
план управ-
ления проек-
том
Отчет о проде-
ланной работе,
приемке испыта-
ний, разработан-
ные подсистемы