66
1) Временную. Она предполагает, что в целях контроля работы ПО и его
возврата к нормальному уровню работоспособности после сбоев используется
отдельная составляющая производительности ПК;
2) Информационную, которая резервирует отдельные блоки
информационной системы под нужды обеспечения надежности и точности
информации [17];
3) Программную, проявляющуюся в следующих параметрах:
- взаимное недоверие – проектирование отдельных компонентов системы
должно изначально ориентироваться в рамках гипотезы обязательного наличия
ошибок в других компонентах, которые должны быть обнаружены
своевременно;
- оперативная идентификация ошибки и ее фиксирование;
- в рамках различных модулей выполняются одинаковые или схожие
функции, благодаря чему появляется возможность своевременно сопоставить
результаты манипуляций с заданным набором информации;
- контроль данных должен производиться комплексно на основе
одновременного оперирования всеми другими типами избыточности, с
возможностью восстановления информации.
Программное обеспечение должно надежно защищено за счет реализации
методов установления устойчивости к появлению и действию ошибок. Этим
методы направлены на уменьшение потенциальной величины потерь
пользователя при фактическом проявлении ошибки. Для этого применяется:
- обработка аппаратурных нарушений;
- дублирование операций;
- конфигурационные преобразования по динамическому типу;
- ограниченное обслуживание при отдельных функциональных сбоях;
- создание копий данных с возможностью их последующего
восстановления после сбоев;
- блокирование ошибок и программных сбоев.
67
Качество и надежность системы во многом определяется ее
тестированием, в процессе которого программы эксплуатируется заданный
период времени в целях поиска возможных ошибок [10]. Основными этапами
реализации этой процедуры являются:
- автономное тестирование с целью выяснения надежности работы
модулей в отдельности друг от друга;
- проверка и контроль сопряжений между отдельными составляющими
исследуемой системы;
- оценка и контроль за реализацией автоматизируемых функций в процессе
работы самой системы;
- определение степени соответствия ПО пользовательских запросов, что
производится в процессе комплексного тестирования;
- проверка достоверности документации и соответствия ее нормативным
параметрам, а также проверка работы программного обеспечения в рамках
действующих инструкций;
- конфигурационное тестирование с целью выяснения корректности и
работоспособности всех возможных вариантов установки.
Рассмотренные параметры проверки и обеспечения надежности
функционирования программного обеспечения должны быть в обязательном
порядке приняты и оптимизированы.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
На основе анализа функции была построена блок схема:
68
Рисунок 15- Блок схема
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
При разработке автоматизированной системы было создано три основных
справочника:
- физическое лицо;
- должность;
69
- подразделение.
Четыре основных документа:
- регистрация кандидатов;
- прием на работу;
- вакансии;
- увольнение работников.
Основные отчеты:
- плановые собеседования;
- текущие вакансии;
- работники организации.
Программа должна обеспечивать:
1) Корректное ведение базы данных (добавление, удаление,
редактирование записей).
2) По таблице должен поддерживаться поиск информации [15].
Общим требованием системы является создание дружественного
интерфейса, с помощью которого пользователь мог бы легко и быстро занести
информацию в базу данных, по вышеперечисленным требованиям.
2.2.3. Характеристика результатной информации
Печать договора о приеме, отчеты по приказам, личная карточка сотрудника.
2.3 Программное обеспечение задачи
2.3.1Общие положения (дерево функций и сценарий диалога)
В данном проекте для сбора требований была выбрана методика
«Интервьюирование», которая рассматривает следующие этапы:
1) Разрабатываются вопросы
2) Производится выбор опрашиваемых пользователей.
3) Планируются контакты.
4) Проводится интервью.
5) Завершается встреча.
6) Определяются последующие действия.
70
На рисунке 16 представлена диаграмма вариантов использования ИС [5],
представляющая процессы, происходящие в ИС кадрового учета.
Рисунок 16 Диаграмма вариантов использования ИС отдела
кадров
Также определены функциональные, системные требования и требования
к интерфейсу системы:
В процессе формирования необходимых требований принимали участие
следующие лица:
1) Директор организации.
2) Специалист по кадровому учету.
Определение корректных требований представляет собой ответственный
этап программного проекта. Окончательный формат проекта должен
соответствовать требованиям, которые предъявляются к программному
обеспечению. Эти требования были сформулированы командой разработчиков и
представлены в программном продукте.
Специфика требований к программному обеспечению SRS (Software
Requirements Specification) имеет очень большое значение для жизненного цикла
программного продукта. Они представляют собой не просто производный
документ со спецификацией программного проекта, но и основной документ для
аттестационных и приемочных испытаний.
71
Аттестация – это процесс оценки качества работы всех менеджеров
проекта. Именно она определяет степень соответствия программного продукта с
требованиями. Сама спецификация SRS выступает в роли механизма фиксации
системных требований, используемых в качестве критериев при аттестационных
мероприятиях [7].
На основе SRS достигается соглашение между производителями и
заказчиками программного продукта. В спецификации описаны все функции,
которые обязательно должен выполнять разрабатываемый программный
продукт. Помимо этого, аттестация помогает потенциальным пользователям ПО
определить степень соответствия программы их потребностям. Поэтому
разрабатываемое программное обеспечение должно быть максимально
полезным для решения многих задач.
При подготовке спецификации SRS работают разные лица в организации
заказчика. Именно они тщательно изучают требования до того момента, когда
начнется сама работа над проектом. Таким образом, снижается вероятность
повторной разработки проекта, его тестирования и кодирования.
При более тщательном изучении требований, которые представлены в
спецификации SRS могут быть обнаружены противоречия и недостатки на
самых ранних стадиях разработки.
Спецификация SRS является основой при оценке стоимости и создания
графика работ. Описание продукта представляет собой процесс оценки
стоимости проекта. В той среде, где реально работает понятие формального
предложения, SRS используется для утверждения цены или предложения.
Посредством правильно составленных спецификаций SRS на уровне
предприятия можно разрабатывать более продуктивные планы аттестации и
проверки. SRS является частью договора на разработку, поэтому обеспечивает
начальную точку отсчета перед оценкой соответствия техническим условиям.
72
Рисунок 17 Дерево функций
Благодаря спецификации SRS значительно облегчается передача ПО
новым пользователям, а также упрощается процесс установки на ЭВМ.
Заказчики получают возможность быстро и легко переносить программные
продукты в самые разные подразделения организации, а разработчики могут
передавать его другим клиентам. В SRS документе подробно рассматривается
сам продукт, а не ход разработки проекта. По этой причине на ее основании
можно делать расширения для уже завершенного продукта. Спецификация
конкретных требований к реализуемому ПО представлена в приложении 1.
Функции разделяются на вида:
- основные;
73
- служебные.
После завершения процесса определения и спецификации требований
проводится аттестация требований. Она должна продемонстрировать тот факт,
что требования действительно определяют систему, которую желает получить
заказчик. Такая проверка требований очень важна, поскольку ошибки в
спецификации могут привести к полной переделке всей системы и большим
затратам, особенно если они будут обнаружены после введения ПО в
эксплуатацию [8-10].
Для аттестации требований можно использовать метод прототипирования.
В данном случае конечный пользователь и заказчик получает некий прототип
системы.
2.3.2 Характеристика базы данных
В любой автоматизированной информационной системе существуют
рабочие и справочные таблицы, о назначении которых можно судить по их
названию [24].
Свойства представлены в каждой таблице в виде полей.
К основным целям проектирования БД следует относить:
1) представление данных и связей между ними, требующихся для всех
базовых сфер применения этого приложения и любых существующих
пользовательских групп;
2) проектирование модели данных, которая поддерживала бы выполнение
любых транзакций обработки данных, которые требуются пользователю;
3) разработка предварительного варианта проекта, структура которого
позволила бы удовлетворить всем основным требованиям, предъявляемые к
уровню производительности системы, к примеру, требования к определенному
времени реакции системы [16].
74
Рисунок 18 – Окно конфигуратора
В основание проектирования любой БД должны быть заложены
представления пользователей конкретно взятой организации, то есть т.н.
концептуальные требования к системе. Именно конечные пользователи в своей
работе принимают решения, учитывая информацию, получаемую по тогам
доступа к базе. От оперативности и качества данной информации будет также
зависеть эффективность работы всего предприятий в целом. Информация,
помещаемая в базу данных, также предоставляется конечным пользователем.
В ходе рассмотрения требований конечных пользователей следует учесть
несколько важных моментов, а именно:
75
1) БД должна удовлетворять актуальным потребностям организации в
информационном аспекте. Получаемая информация при этом должна полностью
соответствовать поставленным задачам и по структуре, и по своему содержанию
[14,16].
2) В ходе создания БД формируются 2 уровня модели – логический и
физический. Уровень логического типа представляет собой, по сути,
абстрактный взгляд на данные, поскольку на этом уровне данные
представляются также, как они выглядят и в реальном мире, и могут именоваться
тоже аналогичному тому, как бы они именовались в реальном мире. Объекты
модели, представляемые на уровне логического типа называют сущностями.
Логический уровень модели данных может быть также выстроен и на базе другой
модели, к примеру, концептуальной (рисунок 2.4). Стоит также отметить, что
уровень логического типа модели данных универсален, а потому он никак не
связан с какой-либо конкретной реализацией системы управления БД;
3) Реализация модели логического типа начинается с определения
концептуальной модели, которая, в свою очередь, определяет главные сущности,
сохраняемые в форме таблиц БД реляционного типа.
2.3.3 Структурная схема пакета (дерево вызова программных модулей)
Процесс проектирования должен начинаться с того, что модель анализа и
избранная архитектура принимаются как основная информация входного типа.
Далее, в ходе проектирования применимы нефункциональные требования,
предъявляемые к системе, а также те ограничения, которые налагаются на
архитектуру. В итоге модель анализа преобразуется в новую форму, то есть в
модель проектирования, которая в дальнейшем может напрямую
реализовываться в форме кода программного типа. Проектирование ИС
подразумевает решение таких вопросов, как:
а) выбор архитектуры и определение средств последующей физической
реализации, которая была получена в конце модели проектировки;
б) уточнение модели анализа при помощи построения диаграмм