Шпаргалка по "Информации"

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

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

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

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

        
 
 
 
 
 
 
 
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Спиральная  модель предполагает итерационный процесс  разработки информационной системы.

    Ее  особенностью является следующее: прикладное ПО создается не сразу, а по частям с использованием метода прототипирования.

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

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

      
 
 
 
 
 
 
 
 

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

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

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

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

    Главная же задача – как можно быстрее  показать пользователям системы  работоспособный продукт, тем самым  активизируя процесс уточнения  и дополнения требований.

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

      Достоинства спиральной модели:

1) наиболее  реально (в виде эволюции) отображает  разработку программного обеспечения;

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

3) включает  шаг системного подхода в итерационную  структуру разработки;

4) использует  моделирование для уменьшения  риска и совершенствования программного изделия.

      Недостатки  спиральной модели:

 1) новизна  (отсутствует достаточная статистика  эффективности модели);

 2) повышенные  требования к заказчику;

 3) трудности  контроля и управления временем  разработки.

 11. Технология проектирования  АИС. Структурный  и объектно-ориентированный  подходы к проектированию  АИС.

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

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

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

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

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

   Основой объектно-ориентированного подхода  является объектная модель. Основными  ее элементами являются:

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

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

2. Инкапсуляция. Это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование останавливает внимание на внешних особенностях объекта, а инкапсуляция (ограничение доступа) не позволяет пользователям различать внутреннее устройство объекта.
3. Модульность. Это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.
4. Иерархия. Это упорядоченная система абстракций, расположение их по уровням.