Внедрение

Анализ

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

• функции — информация о событиях и процессах, которые происходят в бизнесе;
• сущности — информация, необходимая для организации базы данных.

Двумя классическими результатами анализа являются:

• иерархия функций, которая разбивает процесс обработки на компоненты («что делается и из чего это состоит»);
• модель “сущность-связь” (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

Информация, полученная в результате предпроектного обследования анализируется с помощью методов структурного и /или объектного анализа и используется для построения моделей деятельности организации.

Модель деятельности организации предполагает

Эти результаты являются необходимыми, но не достаточными. К достаточным результатам следует отнести диаграммы потоков данных и диаграммы жизненных циклов сущностей,которые описывают динамику системы. В настоящее время существует способ формализации проекта – Unified Modelling Language (UML), позволяющий формально описать различные стороны жизнедеятельности разрабатываемого проекта. Существует достаточно большое количество ПО, реализующего UML, например Rational Rose.

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

Ниже мы рассмотрим три наиболее часто применяемые методологии структурного анализа:

• диаграммы “сущность-связь” (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;
• диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы;
• диаграммы переходов состояний (State Transition Diagrams, STD), которые отражают поведение системы, зависящее от времени; диаграммы жизненных циклов сущностей относятся именно к этому классу диаграмм

27/01/2011

После построения модели, содержащей требования к будущей системе, на её основе осуществляется разработка Технического задания на создание системы, включающего в себя:

· Требования к автоматизированным рабочим местам, их составу и структуре, а также способам и схемам информационного взаимодействия между ними;

· Разработка требований к техническим средствам;

· Разработка требований к программным средствам

· Разработку топологии, состава и структуры локальной вычислительной сети;

· Требования к этапам и срокам выполнения работ

Проектирование

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

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

31/01/2012

Задачами проектирования являются:

· Рассмотрение результатов анализа и проверки их полноты;

· Семинары с заказчиком;

· Определение критических участков проекта и оценка ограничений проекта;

· Определение архитектуры системы;

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

· Проектирование хранилища данных, модель базы данных, бета-версия базы данных;

· Проектирование процессов и кода; окончательный выбор средств разработки, определение интерфейсов программ, отображение функций системы на её модули и определение спецификаций модулей;

· Определение требований к процессу тестирования;

· Определение требований безопасности системы

На этапе проектирования формируется модель данных. Проектировщики в качестве исходной информации получают результаты анализа. Конечным продуктом этапа проектирования являются:

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

Структурное проектирование

Базовыми строительными блоками АСУП при использовании структурного подхода являются модули. Все виды модулей в любом языке программирования имеют ряд общих свойств, из которых существенны при структурном проектировании перечисленные ниже:

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

2) Модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту.

3) Модуль может принимать и/или передавать данные как параметры в вызывающей последовательности или связывать данные через фиксированные ячейки или общие области.

При структурном проектировании выполняется два вида работ:

· Проектирование архитектуры АСУП, включающее разработку структуры и интерфейсов её компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;

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

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

Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы (в том числе циклические, условные и параллельные). Межмодульные связи по данным и управлению также моделируются специальными узлами, привязанными к потокам, стрелками указываются направления потоков и связей. Фундаментальные элементы структурных карт Константайна стандартизованы IBM, ISO и ANSI.

Техника структурных карт Джексона восходит к методологии структурного программирования Джексона и заключается в продуцировании диаграмм и схем для графического иллюстрирования внутримодульных (а иногда и межмодульных) связей и документирования проекта архитектуры АСУП.

При этом структурные карты Джексона позволяют осуществлять проектирование нижнего уровня АСУП и на этом этапе близки к традиционным блок-схемам моделирующим последовательное, параллельное условное и итерационное исполнение их узлов.

14/02/2012

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

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

Таким образом, одним из способов оценки качества и модели реализации является анализ сцепления модулей. Сцепление – это мера взаимозависимости модулей. В хорошем проекте сцепления должны быть минимизированы, т.е. модули должны быть слабозависимыми. Слабое сцепление между модулями служит признаком хорошо спроектированной системы.

Объектно-ориентированное проектирование

Объектно – ориентированные методы используют описания классов и объектов, то есть выразительные средства объектно-ориентированного программирования.

Основой для объектно-ориентированного проектирования служат результаты объектно-ориентированного анализа. Результат любого из методов структурного анализа также может быть использован в качестве входных данных для объектно-ориентированного проектирования

Реализация (программирование/адаптация)

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

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

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

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

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

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

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

ХХХХХХХХХХ

Следует отметить исключительную важность обмена информацией между проектировщиками, разработчиками, тестировщиками: ошибки должны быть классифицированы согласно приоритетам; для каждого класса ошибок должна быть определена четкая структура действий: «что делать», «как срочно», «кто ответственен за результат»; каждая проблема должна отслеживаться проектировщиком/разработчиком/тестировщиком, отвечающим за её устранение.

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

Тестирование и отладка

Корректность АСУП является её самым важным свойством и составляет главный предмет заботы разработчиков. В идеальном случае под корректностью АСУП понимается отсутствие в ней ошибок. Однако для большинства сложных программных продуктов достигнуть этого невозможно – “в каждой программе содержится по крайней мере одна ошибка. Поэтому под корректным обычно подразумевают программный продукт, работающий в соответствии с предъявленными к нему требованиями, другими словами, продукт, для которого пока ещё не найдены такие условия, в которых он окажется неработоспособным

Установление корректности является главной целью рассматриваемого этапа жизненного цикла. Следует отметить, что этап тестирования и отладки – один из наиболее трудоемких, утомительных и непредсказуемых этапов разработки АСУП. В среднем при разработке традиционными методами этот этап занимает от 1/3 до ½ полного времени разработки. С другой стороны, тестирование и отладка представляют собой серьёзную проблему: в некоторых случаях тестирование и отладка программы требуют в несколько раз больше времени, чем непосредственно программирование.

Тестирование представляет собой набор процедур и действий, предназначенных для демонстрации корректнойработы АСУП в заданных режимах и внешних условиях. Цель тестирования – выявить наличие ошибок или убедительно продемонстрировать их отсутствие, что возможно лишь в отдельных тривиальных случаях, важно различать тестирование и сопутствующее понятие “отладка”. Отладка – это набор процедур и действий, начинающихся с выявления самого факта наличия ошибки и заканчивающихся установлением точного места, характера этой ошибки и способов её устранения.

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

31/01/2013

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

Полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Самым распространенным критерием тестирования является критерий, требующий по крайней мере однократной проверки каждой из ветвей программ (критерий С1). Так например, тестирование при приёмке программного обеспечения для ВВС США производится на основании этого критерия. По ряду независимых оценок использование критерия С1 обеспечивает обнаружение от 67 до 90% ошибок.

Существуют и другие подходы к тестированию, например тестирование с ориентацией на слабые места (части программы, где вероятность появления ошибок относительно высока).

При установлении наличия ошибок на этапе тестирования возникает необходимость в следующем этапе – отладке. Отладка представляет собой процесс устранения ошибок.

Внедрение системы – процесс постепенный. Ввод в эксплуатацию проходит как минимум три стадии:

· Первоначальная загрузка информации;

· Накопление информации;

· Выход на проектную мощность (то есть переход к этапу эксплуатации)

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

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

Выход системы на проектную мощность –это доводка мелких ошибок и редких серьезных ошибок.