Проектирование информационных систем

    Содержание

1. Жизненный цикл программного обеспечения…………………… 3

2. Структурный подход к проектированию программного обеспечения………………………………………………………….. 7

3. Функциональные модели…………………………………………… 10

Список  использованной литературы…………………………………… 13

1. Жизненный цикл программного обеспечения.

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

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

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

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

   Рис. 1.  Каскадная модель ЖЦ

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

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

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

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

   Рис. 2.  Поэтапная модель с промежуточным контролем

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

   И последняя - спиральная модель (рис. 3) ЖЦ была предложена для преодоления  перечисленных проблем. На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.

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

   Рис. 3.  Спиральная модель ЖЦ

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

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

   В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ ПО разделены на три группы

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

2. Структурный подход к проектированию программного обеспечения

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

   Существуют  два основных подхода к декомпозиции систем:

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

   Рассмотрим  наиболее подробно структурный подход проектирования ПО.

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

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

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

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

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

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

• диаграммы «сущность - связь» или ER-диаграммы служат для наглядного представления схем баз данных;
• диаграммы потоков данных (DFD) служат для иерархического описания модели системы;
• метод структурного анализа и проектирования (SADT), служащий для проектирования функциональной модели объекта:
• схемы описания «вход – обработка - выход» служат для описания реализуемых программой функций и циркулирующих внутри нее потоков данных;
• диаграммы Варнье – Орра служат для описания иерархической структуры системы с выделением элементарных составных частей, процессов и указанием потоков данных для каждого процесса.

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

   Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

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

3. Функциональные  модели

   Функциональные  модели, используемые на стадии проектирования ПО предназначены для описания функциональной структуры проектируемой системы.

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

   IDEFO, являющийся наиболее удобным языком моделирования процессов, был предложен более 20 лет назад Дугласом Россом и назывался первоначально SADT - Structured Analysis and Desifi Technique.

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

   Под моделью в IDEFO понимают описание системы (текстовое и графическое), которое  должно дать ответ на некоторые заранее  определенные вопросы.

   В результате моделирования системы  по методологии IDEF0 создается функциональная модель, которая представляет собой:

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

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

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

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

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

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

   Список  использованной литературы

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: учебник. – М.: Финансы и статистика, 2002.
2. Бесплатный Интернет-ресурс – URL: http://www.itstan.ru