1.3 Постановка задачи на разработку информационной системы

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

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

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

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

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

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

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

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

Глава 2. Проектирование и разработка информационной системы

2.1 Методологии проектирования информационных систем

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

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

1.Методология RAD – Rapid Application Development.

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

2.Методология RUP.

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

3.Структурные методологии.

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

4.Гибкие методологии.

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

Главное — удовлетворить заказчика и предоставить ему продукт как можно скорее

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

Наиболее эффективный способ передачи знаний участникам разработки и между ними – личное общение

Работающая программа — лучший показатель прогресса разработки