Информационные системы (стр. 2 из 4)

Схема жизненный цикл ИС

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

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

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

Среди моделей ЖЦ можно выделить следующее:

1. Каскадное (до 70г).

2. Интернациональная (70–80 гг.).

3. Спиральная (80–90 гг.).

Принципиальной особенностью каскадного подхода является:

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

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

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

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

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

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

Спиральный метод проектирования

Принципиальной особенностью спирального метода является следующее:

· ИС создается не сразу, как в случае каскадного подхода, а по частям, с использованием метода проектирования.

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

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

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

Подход RAD (Rapid Application Development)

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

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

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

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

Планирование разработки ИС

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

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

1. Определение цели и разработки.

2. Предварительная экономическая оценка проекта.

3. Построение графика выполнения работ.

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

1. Определение бизнес-планов и целей и целей организации с последующим выделением её потребностей в ИТ.

2. Оценка показателей уже существующих ИС с целью выявления их сильных и слабых сторон.

3. Оценка возможностей использования ИТ для достижения конкурентно способного преимущества.

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

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

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

1. Предварительное выявление требований к бедующей системе.

2. Определение перечня целевых функций организации.

3. Анализ распределения функций по подразделениям и сотрудникам.

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

5. Анализ существующих средств автоматизации деятельности организации.

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

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

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

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

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

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

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

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

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

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