38
Для организации единой системы автоматизированного учета на пред-
приятиях, которые имеют территориально удаленные подразделения (цен-
тральный офис, магазин, склад и т. д.), существует дополнительный компо-
нент «Управление распределенными информационными базами». Возможно-
сти, предоставляемые этим компонентом, позволяют организовать работу рас-
пределенной информационной системы с неограниченным количеством авто-
номно работающих информационных баз. Фирма «1С» выпускает типовые
прикладные решения (тиражные) и отраслевые специализированные решения.
Типовые решения характеризуется компактностью и простотой использова-
ния. Они отвечают российским особенностям методологии учета и управле-
ния.
Отраслевые прикладные решения «1С» создаются также силами партне-
ров-разработчиков и предназначены для автоматизации отдельных направле-
ний или областей деятельности предприятий. Все они сертифицированы на
требования «1С:Совместимо».
Наличие единой технологической платформы и общей методологии поз-
воляет создавать такие решения на базе выпускаемых фирмой «1С» тиражных
прикладных решений, добавляя в них только необходимые отличия, учитыва-
ющие специфику отрасли или конкретного предприятия. Это обеспечивает:
высокую скорость создания и внедрения решений за счет макси-
мального использования апробированной функциональности и методологии,
реализованных в типовых конфигурациях;
низкую стоимость отраслевых прикладных решений — затраты на
их создание существенно ниже, чем затраты на разработку программы «с
нуля».
Таким образом, принимая во внимание все вышесказанное нами было
принято решение об использовании в качестве системы разработки плат-
формы «1С:Предприятие 8.3».
Отметим, что выбор платформы разработки повлиял на составление тех-
нического задания. При определении функций разрабатываемой системы
39
учета работы видеосалона нами сразу делался прогноз о возможности реали-
зации этих функций на платформе «1С:Предприятие» и возможного использо-
вания тех или иных прикладных объектов платформы для более полной и
быстрой реализации закладываемых в систему функций. Таким образом, на
этапе составления технического задания у разработчика уже есть представле-
ние, как примерно будет реализована эта функция на платформе разработки,
но без детализации. В дальнейшем при описании подсистем и функций разра-
батываемой системы мы будем описывать их уже с прицелом на возможную
реализацию при помощи тех или иных прикладных объектов платформы.
1С предприятие поддерживает 5 видов СУБД:
файловый вариант самого 1С;
IBM DB2;
MS SQL;
Oracle BD;
PostgreSQL.
Каждая из этих СУБД имеет ограничения при работе с 1С: в СУБД
PostgreSQL сильно уменьшается производительность в режиме интенсивной
работы, система как можно чаще требуется реиндексирование; DB2 чувстви-
тельная к регистру строковых значений при сравнении, а также в ней суще-
ственно снижается производительность от использования подзапросов в усло-
вии соединения; на работу СУБД Oracle DB очень сильное влияние оказы-
вает статистика планов запроса 1C. Наименьшее число ограничений наклады-
вается на использование собственной СУБД, поэтому для реализации системы
будет использоваться именно она.
В качестве языка программирования выбирается встроенный язык 1С
как наиболее понятный и наилучшим образом использующий объекты конфи-
гурации 1С.
1.4.3 Обоснование проектных решений по техническому обеспечению
40
Фирма «1С» проводит сертификацию компьютеров на предмет совме-
стимости с системой программ «1С:Предприятие» версий 8.3.
Компьютеры, прошедшие сертификацию, получают сертификат, удосто-
веряющий их совместимость с системой программ «1С:Предприятие», а также
право на использование логотипа «Совместимо! Система программ 1С:Пред-
приятие».
К сертификации принимаются компьютеры с характеристиками не
хуже:
32-разрядный сервер 1С:Предприятия:
Системные требования:
Процессор Intel Pentium IV/Xeon 2,4 ГГц и выше
Оперативная память 1024 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
64-разрядный сервер 1С:Предприятия:
Системные требования:
Процессор с архитектурой x86-64 (Intel с поддержкой EM64T, AMD
с поддержкой AMD64).
Оперативная память 2048 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
Сервер баз данных:
Системные требования
41
Технические характеристики компьютера и операционная система
должны соответствовать требованием Microsoft SQL Server, PostgreSQL, IBM
DB2, Oracle Database.
Толстый клиент:
Системные требования
Процессор Intel Pentium Celeron 2400 Мгц и выше
Оперативная память 1024 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
Тонкий клиент:
Системные требования
Процессор Intel Pentium Celeron 1800 Мгц и выше
Оперативная память 256 Мб и выше
Жесткий диск 40Гб и выше
Устройство чтения компакт-дисков
USB-порт
SVGA-видеокарта
Компьютеры должны быть укомплектованы мышью, клавиатурой, сете-
выми шнурами.
Компьютер должен предоставляться для сертификации в той програм-
мно-аппаратной конфигурации, в которой он будет поставляться потреби-
телю.
Вместе с компьютером должен поставляться комплект необходимых
драйверов под соответствующие операционные системы.
Конфигурация компьютера должна соответствовать спецификации
(Hardware Compatibility List) для используемых операционных систем.
42
2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл - это период создания и использования информацион-
ной системы, начиная с момента возникновения потребности в информацион-
ной системе и заканчивая моментом полного ее выхода из эксплуатации.
Выделяют следующие этапы жизненного цикла информационной си-
стемы:
1. Анализ требований:
сбор материалов для проектирования, при этом выделяют форму-
лирование требований, с изучения объекта автоматизации, даются предвари-
тельные выводы предпроектного варианта ИС;
анализ материалов и разработка документации, обязательно дается
технико экономическое обоснование с техническим заданием на проектирова-
ние ИС.
2. Проектирование:
2.1 предварительное проектирование;
выбор проектных решений по аспектам разработки ИС;
описание реальных компонент ИС;
оформление и утверждение технического проекта (ТП).
2.2 детальное проектирование:
выбор или разработка математических методов или алгоритмов про-
грамм;
корректировка структур БД;
создание документации на доставку и установку программных про-
дуктов;
выбор комплекса технических средств с документацией на ее уста-
новку.
2.3 разработка техно-рабочего проекта ИС (ТРП).
43
2.4 разработка методологии реализации функций управления с помощью
ИС и описанием регламента действий аппарата управления.
3. Реализация:
получение и установка технических и программных средств;
тестирование и доводка программного комплекса;
разработка инструкций по эксплуатации программно-технических
средств.
4. Внедрение:
ввод технических средств;
ввод программных средств;
обучение и сертификация персонала;
опытная эксплуатация;
сдача и подписание актов приемки-сдачи работ.
5. Эксплуатация и сопровождение ИС:
повседневная эксплуатация;
общее сопровождение всего проекта.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология
(ИТ). Процессы жизненного цикла программных средств» не предлагает кон-
кретную модель жизненного цикла и методы разработки программного обес-
печения. Его регламенты являются общими для любых моделей жизненного
цикла, методологий и технологий разработки. Стандарт ГОСТ Р ИСО/МЭК
12207-99 описывает структуру процессов ЖЦ ПО, но не конкретизирует в де-
талях, как реализовать или выполнить действия и задачи, включенные в эти
процессы. Конкретная модель выбирается из следующих вариантов:
- каскадная модель: предусматривает последовательное выполнение
всех этапов проекта в строго фиксированном порядке. Переход на следующий
этап означает полное завершение работ на предыдущем этапе;
- спиральная модель: на каждом витке спирали выполняется создание
очередной версии продукта, уточняются требования проекта, определяется его
44
качество и планируются работы следующего витка. Особое внимание уделя-
ется начальным этапам разработки - анализу и проектированию, где реализуе-
мость тех или иных технических решений проверяется и обосновывается по-
средством создания прототипов- инкрементной модели.
- инкрементная модель: подразумевает разработку информационной си-
стемы с линейной последовательностью стадий, но в несколько инкрементов
(версий), т. е. с запланированным улучшением продукта [2].
Для сравнения можно использовать таблицу, в которой определены ха-
рактеристики каждой из моделей (таблица 6).
Таблица 6
Характеристики моделей жизненного цикла
Характеристика
проекта
Модель (стратегия)
Каскадная
Инкрементная
Спиральная
Масштаб проекта
Малые и средние
проекты
Средние и круп-
ные проекты
Любые про-
екты
Сроки выполнения
проекта
До года
До нескольких лет. Разработка
одной версии может занимать
срок от нескольких недель до
года
Заключение отдель-
ных договоров на от-
дельные версии
Заключается один
договор. Версия и
есть итоговый ре-
зультат проекта
На отдельную версию или не-
сколько последовательных вер-
сий обычно заключается отдель-
ный договор
Определение основ-
ных требований в
начале проекта
Да
Да
Нет
Изменение требова-
ний по мере развития
проекта
Нет
Незначительное
Да
Разработка итераци-
ями
Нет
Да
Да
Данный проект можно отнести к малым, со сроком разработки до 1 года.
Требования к проекту строго определены заранее и по мере работы изменяться
не будут. Поэтому для данного проекта выбирается каскадная модель жизнен-
ного цикла.
45
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Риск IT-проекта - это кумулятивный эффект вероятностей наступления
неопределенных событий, способных оказать отрицательное или положитель-
ное влияние на цели проекта. Риски подразделяются на известные и неизвест-
ные. Известные риски идентифицируются и подлежат управлению - создаются
планы реагирования на риски и резервы на возможные потери. Неизвестные
риски нельзя определить, и, следовательно, невозможно спланировать дей-
ствия по реагированию на такой риск.
Событие риска - потенциально возможное событие, которое может нане-
сти ущерб или принести выгоды проекту.
Вероятность возникновения риска - вероятность того, что событие риска
наступит. Все риски имеют вероятность больше нуля и меньше 100%. Риск с
вероятностью 0 не может произойти и не считается риском. Риск с вероятно-
стью 100% также не является риском, поскольку это достоверное событие, ко-
торое должно быть предусмотрено планом проекта [7].
На каждом этапе жизненного цикла возможно возникновение рисков. На
ранних этапах преобладают риски, связанные с бизнесом, рамками проекта,
требованиями к конечному продукту и проектированием этого продукта. На
стадии реализации доминируют технологические риски, далее возрастает роль
рисков, связанных с поддержкой и сопровождением системы. На протяжении
всего жизненного цикла проекта возникают новые риски, что требует прове-
дения дополнительных операций анализа и планирования.
Поэтому необходимо разобрать возможные риски на следующих этапах
жизненного цикла:
1) анализ требований,
2) проектирование,
3) реализация,
4) внедрение,
5) эксплуатация и сопровождение.
46
Возможные риски на каждом этапе жизненного цикла приведены в таб-
лице 7.
Таблица 7
Риски разработки и внедрения ИС
Этап жиз-
ненного
цикла
Возможные риски
Пути снижения вероятно-
сти возникновения
Анализ требо-
ваний
Некачественное описание пред-
метной области
Использовать Case-средства
для описания предметной об-
ласти
Незаинтересованность руководи-
телей в проекте
Определить экономическую
эффективность проекта
Неверно указанные функции
Принимать участие в разра-
ботке требований
Проектирова-
ние
Недостаточность данных для ре-
шения поставленных задач
Использовать Case-средства
для моделирования данных
Проектирование решения, несов-
местимого с имеющимися инфор-
мационными системами
Выполнить анализ имею-
щихся программных и техни-
ческих средств
Изменение требований заказчика
На этапе анализа требований
утвердить окончательный ва-
риант требований
Реализация
Риск неверного технического ре-
шения
Анализ возможных техниче-
ских решений для выбора оп-
тимального
Недостаточность технических и
программных средств для реали-
зации поставленных задач
Предусмотреть наращивание
программных и технических
средств
Низкая производительность ис-
полнителя
Разработка календарного
плана разработки с запасом
по срокам
Внедрение
Неготовность персонала к пере-
ходу на новую систему учета
Проработать и согласовать
детальный план перехода на
новую систему учета
Сложность ввода данных в новую
информационную базу
Разработать детальные ин-
струкции для персонала
Проблемы установки платформы
на ПК пользователя
Определить требуемую кон-
фигурацию ПК заранее и при
необходимости провести мо-
дернизацию ПК
Эксплуатация
и сопровож-
дение
Недостаточная квалификация
персонала
Выполнять замеры произво-
дительности с определением
и устранением узких мест
Текучка кадров и сложности с
обучением нового персонала
Разработать подробное руко-
водство пользователя и ин-
струкции для персонала
Риск снижения производительно-
сти информационной системы
Разработать подробное руко-
водство пользователя и ин-
струкции для персонала
47
Дефектом называется ошибка в программном продукте, вследствие ко-
торой продукт ведет себя непредвиденно (неверно). Большинство дефектов
возникают из-за допущенной ошибки в программном коде или логической
ошибки, допущенной во время проектирования. Гораздо меньшее количество
- вследствие ошибок работы инструментальных средств (компилятора, генера-
тора кода).
Дефекты делят на следующие категории
Арифметические ошибки (деление на 0, переполнение)
Логические ошибки (бесконечные циклы, бесконечная рекурсия)
Ошибки работы с ресурсами (null pointer, access violation, переполне-
ние буфера)
Ошибки синхронизации многопоточности (дедлок, race condition)
Поскольку количество дефектов в большинстве программных продук-
том достаточно велико, для учета дефектов применяют специальный класс си-
стем - систему учета запросов (Issue Tracking System). Данная система кроме
учета дефектов ведет еще учет требований продукта, релизов и т.д.
Дефекты программного обеспечения можно классифицировать в соот-
ветствии с их распределением по этапам жизненного цикла и источников их
возникновения:
1) непреднамеренное отклонение от разработчиков рабочих стандартов
или планов реализации;
2) спецификации функциональных и интерфейсных требований без со-
блюдения стандартов разработки;
3) несовершенная организация процесса разработки.
Дефекты могут возникать во время разработки программного обеспече-
ния на различных этапах жизненного цикла. Возможные дефекты на каждом
этапе жизненного цикла приведены в таблице 8.