«система». Лекция автоматизированные экономические информационные системы

• Название: Лекция автоматизированные экономические информационные системы
• Дата: 11.10.2019
• Размер: 0.87 Mb.
• Имя файла: «система».doc
• Тип: Лекция; #89613
• страница: 14 из 18

Рабочее проектирование – 3 этап. Основные задачи и особенности.

Составление спецификаций

Результаты проектирования отражаются в документе — функциональной спецификации. Этот документ пишется для заказчика, чтобы получить его санкцию на завершение проектирования и начало разработки, и обычно не содержит большого количества технических деталей. Второй документ — техническая спецификация, являющаяся основным документом для разработчиков моделей и групп тестирования, и здесь описаны детали проекта. Если использовались CASE-средства, то техническая спецификация обязательно содержит ряд отчетов из репозитария.

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

• 
  с течением времени в ИС начнется неконтролируемый рост объемов данных;
  
• 
  возникновение потоков запросов с изначально высокой вероятностью конфликта или потоков запросов, которые будут выполняться «вечно» (попытка выполнить поток, обнаружение конфликта и откат всех действий, новая попытка и т.д.) из-за конфликтующих с ними потоков;
  
• 
  смешивание системных и интерфейсных модулей;
  
• 
  дублирование модулей;
  
• 
  ошибки в размещении бизнес-логики;
  
• 
  отсутствие реализации или неполная реализация требуемых заказчиком функций системы.
  

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

Кроме того, отсутствие спецификаций модулей не позволит точно оценить сложность каждого модуля и, как следствие, определить последовательность создания модулей и правильно распределить нагрузку персонала. Обычная ситуация в подобном случае — «кто-то кого-то ждет», при этом процесс создания информационной системы стоит на месте.

Обмен данными с внешними системами

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

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

• 
  одноразовый импорт данных, унаследованных, как правило, из старой системы;
  
• 
  периодический обмен данными между узлами информационной системы (внутренний обмен);
  
• 
  периодический обмен данных с другими информационными системами (внешний обмен).
  

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

При анализе задач загрузки и выгрузки данных проектировщик должен рассмотреть:

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

Следует отметить, что при наследовании данных из старой системы проектировщикам не приходится надеяться на то, что кто-то создаст утилиту, позволяющую достать данные из старой системы, — обычно это становится задачей самих проектировщиков новой системы. Может случиться так, что вам придется работать в жестких условиях, когда не будет возможности выделить время для тестирования новой программы извлечения данных. В этом случае нужно разработать набор тестовых данных. Если в старой системе имеется какое-то средство извлечения данных — используйте его; часто это самый разумный выход.

При загрузке данных из старой системы проектировщики могут столкнуться с большим объемом неочищенных данных — с нарушениями целостности данных, возникшими из-за сбоев системы, «заплаток» разработчиков, иных неприятностей. Если не принять мер по очистке данных, то, вероятно, большинство спроектированных ограничений целостности нужно будет ослабить, чтобы загрузить хоть какую-то часть данных. Цена такой уступки достаточно высока: данные вы приняли, но ослабленные ранее ограничения уже нельзя восстановить, так как они уже нарушены (это отслеживается СУБД автоматически). Отсюда следует вывод: несколько дней, потраченных на очистку данных, стоят так мало по сравнению с наличием в информационной системе данных, не обладающих элементарной целостностью.

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

Реализация

Переход к реализации

Итак, начата реализация модулей. Означает ли это, что работа проектировщиков на этом завершена полностью? На практике это далеко не так. Довольно часто разработчик сталкивается с медленно работающими или не реализуемыми в данной схеме запросами. Подобные ситуации инициируют изменение модели данных, а значит, и информационной модели. Однако изменение информационной модели производится не только по этой причине. Хорошему проектировщику необходим практический опыт работы с аппаратным и программным обеспечением — вот одна из причин участия проектировщиков в составе групп разработчиков. Нередко ведущие сотрудники групп разработчиков одновременно являются проектировщиками. Как можно использовать проектировщиков на этапе разработки? Приведем некоторые примеры:

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

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

На этапе разработки осуществляется тесное взаимодействие проектировщиков, разработчиков и групп тестеров. В случае интенсивной разработки тестер буквально «пристегивается» к разработчику, фактически являясь членом группы разработки.

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

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

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

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

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

Обработка результатов проектирования

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

Желательно, чтобы на этапе проектирования уже была построена матрица «функции-сущности». Это фактически формализованное представление того, что фирма пытается сделать (функции) и какую информацию требуется обработать для достижения результата (сущности). Подобная матрица позволяет проверить следующие моменты:

• 
  имеет ли каждая сущность конструктор — функцию, создающую экземпляры сущности (create);
  
• 
  есть ли ссылки на данную сущность, то есть, используется ли где-либо данная сущность (references);
  
• 
  имеют ли место изменения данной сущности (update);
  
• 
  имеет ли каждая сущность деструктор – функцию, которая удаляет экземпляры сущности (delete).
  

Часто роль деструктора выполняет комплект программ архивирования данных. Нередко в информационных системах информацию просто накапливают. Это допустимо лишь в том случае, если в течение всего периода накопления информации (а фактически в течение всей жизнедеятельности информационной системы) характеристики ее производительности удовлетворяют требованиям заказчика. На практике это чрезвычайно редкое стечение обстоятельств. Связано это в основном с ростом обрабатываемых объемов информации. Следует отметить, что надеяться в этом случае только на мощность СУБД или аппаратного обеспечения нельзя, так как подобные экстенсивные методы повышения производительности дают низкий расчетный прирост скорости. Фактически задача реагирования системы или отдельных ее частей на рост объема обрабатываемых данных является наиболее вероятной задачей тестирования. В таком случае группа тестирования создает модуль генерации (пусть даже абстрактных) данных, выбирается набор запросов, для которых скоростные характеристики критичны, далее производятся замеры, и строится зависимость скорости выполнения от объема данных для каждого из запросов. Такое простое действие позволит избежать серьезных ошибок и в проектировании, и в реализации информационной системы.

Интерфейсы

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

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

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

Тестирование

Проектирование тестирования.

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

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

Когда генерация модуля завершена, выполняют автономный тест, который преследует две основные цели:

• 
  обнаружение отказов модуля (жестких сбоев);
  
• 
  соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
  

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

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

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

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

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

• 
  отказ отдельного компонента информационной системы;
  
• 
  отказ группы компонентов информационной системы;
  
• 
  отказ основных модулей информационной системы;
  
• 
  отказ операционной системы;
  
• 
  «жесткий» сбой (отказ питания, жестких дисков).
  

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

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок — bug tracking. Подобная система обеспечивает следующие функции:

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

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

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