63477

ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ СИСТЕМ

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-06-20

582.5 KB

2 чел.

Тема: ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ СИСТЕМ

2.1. Модели жизненного цикла информационных систем

Понятие жизненного цикла (ЖЦ) ИС является одним из базовых в программной инженерии. Жизненный цикл ИС определяется как период времени, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим состав процессов жизненного цикла, можно назвать международный стандарт ISO/IEC 12207: «Information Technology- Software Life Cycle Processor» ISOInternational Organization for Standardization – Международная организация по стандартизации, IEC - International Electrotechnical Commision- Международная комиссия по электротехнике. Данный стандарт определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

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

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

каскадная (до 70-х годов);

итерационная (70-80-е годы);

спиральная (80-90-е годы).

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

Преимущества применения каскадного способа заключаются в следующем:

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

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

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

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

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

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

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

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

В середине 80-х гг. была предложена спиральная модель жизненного цикла, представленная на рис. 2.2.

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

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

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

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

Одним из возможных подходов к разработке ИС в рамках спиральной модели жизненного цикла является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Raid Application Development). Подход RAD предусматривает наличие трех составляющих:

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

короткого, но тщательно проработанного производственного графика (до 3 месяцев);

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

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

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

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

2.2. Планирование разработки, определение требований к ИС и анализ информационных потребностей пользователей

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

Планирование разработки ИС состоит в определении трех основных компонентов:

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

Планирование разработки ИС должно быть связано с общей

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

определение бизнес-планов и целей организации с последующим выделением ее потребностей в информационных технологиях;

оценка показателей уже существующих информационных систем с целью выявления их сильных и слабых сторон;

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

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

Определение требований к системе - это проведение обследования деятельности автоматизируемого объекта (организации) для определения диапазона действия и границ ИС, состава ее пользователей и областей применения.

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

  1.  Предварительное выявление требований к будущей системе;
  2.  Определение перечня целевых функций организации;
  3.  Анализ распределения функций по подразделениям и сотрудникам;
  4.  Выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных взаимодействий;
  5.  Анализ существующих средств автоматизации деятельности организации;
  6.  Построение моделей деятельности организации, предусматривающее обработку материалов обследования и построение двух видов моделей:

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

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

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

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

совершенствованием существующих технологий на основе их эффективности;

радикальным изменением технологий и перепроектирование бизнес-процессов (реинжениринг бизнес-процессов).

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

посредством опроса отдельных сотрудников предприятия, особенно специалистов в наиболее важных областях ее деятельности;

с помощью наблюдений за деятельностью предприятия;

посредством изучения документов, особенно тех, которые используют для сбора или представления информации;

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

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

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

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

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

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

технология структурного анализа и проектирования (SAD);

диаграммы потоков данных (DFD);

графики «вход-процесс-выход» (HIPO), дополненные соответствующей документацией.

Для получения гарантий того, что составленный набор требований является полным и непротиворечивым, могут использоваться CASE-инструменты, предназначенные для автоматизированного проектирования и создания программ.

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

2.3. Проектирование базы данных, выбор целевой СУБД и проектирование пользовательского интерфейса

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

Основными целями проектирования базы данных являются:

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

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

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

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

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

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

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

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

Вторая фаза проектирования базы данных называется логическим проектированием. Ее цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная или сетевая модель).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

разработка средств защиты создаваемой системы.

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

они связаны с совершенно разными аспектами системы: что делать и как делать;

они выполняются в разное время, поскольку понять, что надо сделать, следует прежде, чем решить, как это сделать;

они требуют совершенно разных навыков и умений, которыми обычно обладают разные люди.

Выбор целевой системы управления базой данных (СУБД) - это выбор СУБД подходящего типа, предназначенной для поддержки создаваемого приложения базы данных.

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

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

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

Основными этапами процедуры выбора СУБД являются:

определение области компетенции проводимого изучения;

сокращение списка претендентов до двух-трех продуктов;

оценка продуктов;

проведение обоснованного выбора и подготовка отчета.

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

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

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

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

2.4. Реализация проекта ИС

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

В результате выполнения всех этапов проектирования (которые могут включать или не включать создание прототипов) будет подготовлено все, что необходимо для реализации базы данных и прикладных программ. Реализация базы данных осуществляется посредством создания ее описания на языке определения данных (DDL) целевой СУБД. Команды DDL-языка компилируются и используются для создания схем и пустых файлов базы данных.

На этом же этапе определяются и все специфические пользовательские представления.

Прикладные программы реализуются с помощью языков третьего или четвертого поколения. Некоторые элементы этих прикладных программ будут представлять собой транзакции обработки базы данных, записываемые на языке манипулирования данными (DML) целевой СУБД и вызываемые из программ на базовом языке программирования, например, на Visual Basic, Delphi, С, С++, Jaуа, Рascal. Кроме того, на этом этапе создаются другие компоненты проекта приложения, например, экраны меню, формы ввода данных и отчеты. Следует учитывать, что многие существующие СУБД имеют свои собственные инструменты разработки четвертого поколения, позволяющие быстро создавать приложения с помощью непроцедурных языков запросов, разнообразных генераторов отчетов, генераторов форм, генераторов графических изображений и генераторов приложений.

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

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

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

Тестирование - процесс выполнения прикладных программ с целью поиска ошибок.

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

PAGE  10


 

А также другие работы, которые могут Вас заинтересовать

84491. Рухові рефлекси спинного мозку, їх рефлекторні дуги, фізіологічне значення 45.37 KB
  У складі задніх рогів спинного мозку переважають вставні нейрони. Біла речовина спинного мозку представлена волокнами висхідних та низхідних шляхів. Контроль на рівні спинного мозку Рецептори шкіри Вісцерорецептори ангіорецептори.
84492. Провідникова функція спинного мозку. Залежність спінальних рефлексів від діяльності центрів головного мозку. Спінальний шок 43.05 KB
  Біла речовина спинного мозку передні бокові та задні канатики складається з нервових волокон які формують провідні шляхи. Основними висхідними шляхами є: 1. Шлях Голя – розташований в медіальній частині заднього канатика. Шлях Бурдаха – розташований в латеральній частині заднього канатика.
84493. Рухові рефлекси заднього мозку, децеребраційна ригідність 48.79 KB
  Вони носять назву надсегментарних утворень так як впливають на м’язи не прямо а через мотонейрони сегментарних структур – рухові ядра спинного мозку і черепномозкових нервів. Задній мозок отримує і переробляє всю аферентну інформацію що надходить від спинного мозку оскільки всі специфічні висхідні шляхи від спинного мозку входячи в стовбур мозку задній та середній мозок віддають коллатералі гілочки до ретикулярної формації тут продовжується обробка аферентної інформації. В задньому мозку розміщені 4 вестибулярні ядра медіальне...
84494. Рухові рефлекси середнього мозку, їх фізіологічне значення 44.55 KB
  Середній мозок СрМ за участі сітчастої речовини опрацьовує аферентну інформацію яка поступає в спинний та задній мозок. Нова інформація поступає в СрМ від зорових та слухових рецепторів. На основі опрацьовання інформації від усіх цих рецепторів СрМ здійснює контроль за станом зовнішнього та внутрішнього середовища організма. Важливими надсегментарними руховими ядрами СрМ є: 1 червоні ядра – від них інформація від нейронів спинного мозку передається по шляхах що перехрещуються руброспінальні шляхи – елемент ЛНС; 2 ретикулярна формація;...
84495. Мозочок, його функції, симптоми ураження 44.3 KB
  Від вестибулорецепторів через вестибулярні ядра – контроль за збереженням рівноваги при русі. Від всіх рухових ядер стовбуру ретикулярна формація краєві ядра. З руховими ядрами стовбуру ретикулярна формація вестибулярні ядра червоні ядра через які Мз здійснює вплив на мотонейрони і на м’язи. З базальними ядрами.
84496. Таламус, його функції 43.44 KB
  Сенсорні перемикаючі специфічні ядра – вони отримують інформацію від специфічних сенсорних шляхів переробляють її і передають в сенсорні зони КГМ. Неспецифічні – вони отримують інформацію від ретикулярної формації стовбура мозку по шляхах больової чутливості. Вони передають інформацію до всіх зон КГМ здійснюючи на неї неспецифічний активуючий вплив. Асоціативні – отримують інформацію від специфічних сенсорних перемикаючих ядер і від неспецифічних ядер таламуса.
84497. Базальні ядра, їх функції, симптоми ураження 43.36 KB
  Базальні ядра знаходяться в глибині кінцевого мозку. Як єдине ціле з базальними ядрами функціонують чорна субстанція та субталамічне ядро. Ці ядра об’єднані між собою двосторонніми зв’язками отримують інформацію від кори асоціативних та рухових зон та мозочка.
84498. Сенсорні, асоціативні і моторні зони кори головного мозку, їх функції 44.36 KB
  Сенсорні асоціативні моторні зони кори формують нову кору – неокортекс. Сенсорні зони кори відповідають представництву окремих сенсорних систем аналізаторів у різних ділянках кори. Так кіркове представництво зорового аналізатора локалізується у потиличній зоні кори шпорна закрутка слухового – у висковій зоні соматосенсорного – у постцентральній закрутці.
84499. Загальна характеристика системи крові. Склад і функції крові. Поняття про гомеостаз 56.9 KB
  Склад і функції крові. СИСТЕМА КРОВІ ВИКОНАВЧІ ОРГАНИ ТКАНИНИ МЕХАНІЗМИ РЕГУЛЯЦІЇ Кров циркулююча Нервові Гуморальні Кров депонована Органи кровотворення 1. Забезпечення оптимальної кількості складових частин крові як одиниць транспорту в одиниці об’єму крові.