Файл: Основные технологии проектирования информационных систем.pdf

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

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

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

Объект исследования – основные методы проектирования информационных систем.

Предмет исследования – объектно-ориентированный подход проектирования информационной системы.

Цель данной курсовой работы – провести анализ объектно-ориентированного подхода при проектировании информационной системы.

Для достижения поставленной цели, в работе необходимо решить следующие задачи:

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

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

Глава 1. Основные технологии проектирования информационных систем

1.1 Основные понятия и определения

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

В соответствии с Федеральным законом № 149-ФЗ (в редакции от 06.07.2016) «Об информации, информационных технологиях и о защите информации» под термином информация понимается «сведения (сообщения, данные) независимо от формы их представления» [17].

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

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

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

Активное развитие информационных технологий началось в середине прошлого века, когда передовые предприятия и военные ведомства, установили, что необходимость внедрения и развития информационных систем это не столько временная потребность, сколько будущее. Наиболее серьезное значение для развития информационной области оказало совершенствование средств вычислительной техники. Развитие технической базы позволило увеличить скорость решения сложных задач, автоматизировать многие рутинные операции и, создало возможность для создания крупных информационных систем, способных обеспечить одновременную работу множества пользователей. Но потребность в создании таких систем породило необходимость создания специальных средств проектирования и моделирования бизнес-процессов, позволяющих сократить сроки создания информационных систем, при этом минимизируя возникающие ошибки. Стоит отметить, что возникновение ошибок в проектируемых информационных системах возникают постоянно, а потому, чем раньше они будут обнаружены, тем дешевле будет их устранение. Как показывает статистика, устранить ошибку, обнаруженную на стадии проектирования, будет стоить в 2 раза дороже, чем на стадии анализа бизнес-процессов и составления технического задания (ТЗ). Если ошибка будет обнаружена на стадии тестирования, то устранить ее будет стоить в 10 раз дороже, а если ошибка будет обнаружена уже на стадии эксплуатации, то стоить устранения возрастает в 100 раз [3].

Одной из причин ошибок может стать недопонимание, между аналитиком и персоналом заказчика. Полученные требования могут быть некорректно сформулированы, а также измениться, при формализации конкретных бизнес-процессов. Это и послужило основной причиной появления современных методологий проектирования и моделирования информационных систем. Разработка методологий проектирования ИС за всю свою историю прошла множество этапов, было создано несколько десятков методов моделирования сложных ИС, каждый из которых обладал своими достоинствами и недостатками. Несмотря на множество своих различий, они имели схожие подходы к проектированию ИС. В конечном итоге это привело к необходимости выработки единой методологии, которая бы удовлетворяла потребности многих разработчиков ИС. В результате появился унифицированный язык моделирования UML (Unified Modeling Language), ведущие роли в разработке которого сыграли Гради Буч, Айвар Джекобсон и Джеймс Рамбо, работающие в компании Rational Software. Ими же были разработаны основные методы объектного моделирования ИС [2]:

Метод объектного моделирования программного обеспечения сложных информационных систем (метод Буча);
Метод анализа требований к бизнес-приложениям (метод Джекобсона);
Метод анализа обработки данных в сложных информационных системах (метод Рамбо).

Разработанные ими методы и легли в основу первой версии UML 0.9, выпущенной в июне 1996 года. С момента выпуска языка UML, он перерос с простой системы моделирования бизнес-процессов до уровня международного стандарта. Так, версия языка UML 2.4.1 была принята и оформлена в качестве международных стандартов ISO/IEC 19505-1 и ISO/IEC 19505-2.

1.2 Основы моделирования информационных систем

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

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

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

Фактически процесс проектирования ПО и ИС не является однородным и, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса (process model).

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

Перед тем, как непосредственно переходить к рассмотрению моделей проектирования ИС и ПО, необходимо рассмотреть такие понятия, как – фаза и вид деятельности.

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

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

Вид деятельности (activity) – это некоторый тип работ, который выполняется в процессе разработки программного продукта [9]. Разные области знаний требуют не только разные профессиональные знания и навыки, но зачастую могут выполняться только специалистами в данной сфере. Для примера, при разработке программного продукта за управление им отвечает менеджер проекта, его разработкой занимается программист, составляет требования и формализует предметную область аналитик или проектировщик. Стоит иметь в виду, что при реализации небольших проектов, один человек может выполнять все работы по реализации проекта – от проектирования, до конечной разработки и внедрения.

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

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

1.3 Модели жизненного цикла

Перед тем как рассматривать модели процесса разработки ПО или модели его жизненного цикла, ему необходимо дать четкое определение, которое определено в международном стандарте IEEE [14]:

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

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

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

При рассмотрении вопросов, касающихся моделей ЖЦ ПО, необходимо руководствоваться единым стандартом, в качестве которого выступает ГОСТ Р ИСО/МЭК 12207-2010. В нем неопределенны четкие отношения к какой-то конкретной модели ЖЦ, но содержаться общие требования для любых моделей ЖЦ, методов и технологий создания ИС. В рамках данного документа описывается структура процессов ЖЦ, но нет конкретики к выбору способа реализации действий или выполнения задач, которые входят в состав конкретного процесса ЖЦ [18].

Любая модель ЖЦ ПО, в общем случае состоит из: