А. А. Платонов, доцент кафедры прикладной математики и вычислительной техники Волгоградского государственного архитектурностроительного университета
 Скачать 3.99 Mb.
|
|
УДК 004.4(075.8) ББК 32.97я73 И266 Р е ц е н з е н т ы: кандидат технических наук М. В. Филиппов, заведующий кафедрой информационных систем и технологий Волгоградского института бизнеса; кандидат технических наук А. А. Платонов, доцент кафедры прикладной математики и вычислительной техники Волгоградского государственного архитектурно-строительного университета Утверждено редакционно-издательским советом университета в качестве учебного пособия Игнатьев, А. В. И266 Методы и средства проектирования информационных систем и техно- логий [Электронный ресурс] : учебное пособие / А. В. Игнатьев ; М-во образо- вания и науки Рос. Федерации, Волгогр. гос. архит.-строит. ун-т. — Электрон- ные текстовые и графические данные (0,9 Мбайт). — Волгоград : ВолгГАСУ, 2014. — Учебное электронное издание сетевого распространения. — Сис- тем. требования: РС 486 DX-33; Microsoft Windows XP; Internet Explorer 6.0; Adobe Reader 6.0. — Официальный сайт Волгоградского государственного архитектурно-строительного университета. Режим доступа: http://www.vgasu.ru/publishing/on-line/ — Загл. с титул. экрана. ISBN 978-5-98276-682-3 Описаны современные методы проектирования информационных систем и техноло- гий. Представлены различные подходы к проектированию информационных систем и дана их характеристика. Для студентов-бакалавров всех форм обучения направления «Информационные сис- темы и технологии». Для удобства работы с изданием рекомендуется пользоваться функцией Bookmarks (Закладки) в боковом меню программы Adobe Reader. УДК 004.4(075.8) ББК 32.97я73 ISBN 978-5-98276-682-3 © Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Волгоградский государственный архитектурно-строительный университет», 2014 3 Оглавление 1. Основные положения проектирования информационных систем и технологий …………..... 4 1.1. Что такое проектирование? ……………………………………………………………….. 4 1.2. Что мы проектируем? …………………………………………………………………….... 5 Контрольные вопросы ………………………………………………………………………….. 7 2. Модели жизненного цикла разработки программного обеспечения информационной системы ……………………………………………………………………………………………… 8 2.1. Понятие и модели жизненного цикла …………………………………………………….. 8 2.2. Каскадная (водопадная) модель …………………………………………………………… 8 2.3. Итеративная и инкременальная модель — эволюционный подход ……………………. 10 2.4. Спиральная модель ………………………………………………………………………… 11 Контрольные вопросы ………………………………………………………………………….. 13 3. Целеориентированное проектирование и его интеграция в жизненный цикл разработки продукта ……………………………………………………………………………………………… 14 3.1. Ошибки проектирования …………………………………………………………………... 14 3.2. Целеориентированное проектирование …………………………………………………... 16 3.2.1. Исследования ……………………………………………………………………… 17 3.2.2. Моделирование ……………………………………………………………………. 18 3.2.3. Выработка требований ……………………………………………………………. 18 3.2.4. Определение инфраструктуры ……………………………………………………. 19 3.2.5. Детализация ………………………………………………………………………... 20 3.2.6. Сопровождение разработки ………………………………………………………. 20 Контрольные вопросы ………………………………………………………………………….. 21 4. Методы сбора требований ……………………………………………………………………….. 22 4.1. Значение качественных исследований …………………………………………………… 22 4.2. Виды качественных исследований ………………………………………………………... 23 4.2.1. Интервьюирование заинтересованных лиц ……………………………………… 23 4.2.2. Интервьюирование экспертов в предметной области …………………………... 24 4.2.3. Интервьюирование покупателей …………………………………………………. 24 4.2.4. Интервьюирование пользователей ……………………………………………….. 25 4.2.5. Анкетирование …………………………………………………………………….. 26 4.2.6. Наблюдение за пользователями ………………………………………………….. 26 4.2.7. Самостоятельное описание требований …………………………………………. 27 4.2.8. Обзор литературы и технической документации ……………………………….. 27 4.2.9. Аудит продукта/прототипа и конкурирующих решений ……………………….. 28 4.2.10. Совместные семинары …………………………………………………………… 28 Контрольные вопросы ………………………………………………………………………….. 28 5. Модели бизнес-процессов ……………………………………………………………………….. 29 5.1. Методики моделирования бизнес-процессов ……………………………………………. 29 5.1.1. Функциональная методика IDEF0 ………………………………………………... 30 5.1.2. Описание бизнес-процессов в Унифицированном языке моделирования …….. 33 5.1.3. ДРАКОН-технология ……………………………………………………………… 34 5.2. Описание бизнес-процесса «Планирование закупок и размещение заказов поставщикам» …………………………………………………………………………………… 38 Контрольные вопросы ………………………………………………………………………….. 50 6. Метод персонажей ……………………………………………………………………………….. 51 6.1. Кто такие персонажи? ……………………………………………………………………… 51 6.2. Разработка персонажей ……………………………………………………………………. 52 Контрольные вопросы ………………………………………………………………………….. 55 Список использованной литературы ………………………………………………………………. 56 Список рекомендуемой литературы ……………………………………………………………….. 56 4 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ 1.1. Что такое проектирование? Обратившись к Новой философской энциклопедии, мы найдем там сле- дующее определение проектирования: Проектирование — один из основных (наряду с инженерной деятельностью) способов создания техники и других изделий и сооружений. Исторически проектирование возникает внутри сферы изготовления (до- мостроения, кораблестроения, изготовления машин, градостроения и т. д.). Это часть работы, связанная с расчетами и изображением на чертежах внеш- него вида, строения и функционирования будущего изделия (дома, корабля, машины). Проектирование становится самостоятельной сферой деятельно- сти, когда происходит разделение труда между архитектором (конструкто- ром, расчетчиком, чертежником) и собственно изготовителем (строителем, машиностроителем). Исходя из предпосылки, что проектирование является самостоятельной сферой деятельности, уточним определение проектирования. Проектирование —деятельность человека или организации по созданию проекта, то есть прототипа, прообраза предполагаемого или возможного объекта, состояния; комплекта документации, предназначенной для создания определен- ного объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект. Проектирование программного обеспечения (ПО) является частным слу- чаем проектирования продуктов и процессов. Проектирование программного обеспечения — процесс создания проекта программного обеспечения, а также дисциплина, изучающая методы проектиро- вания. Целью проектирования является определение внутренних свойств систе- мы и детализации ее внешних (видимых) свойств на основе выданных заказ- чиком требований к ПО (исходные условия задачи). 5 1.2. Что мы проектируем? Вопрос, вынесенный в заглавие раздела, определяет дальнейшее содержа- ние изучаемого курса. Для ответа на него дадим основные определения и рас- смотрим различие между информационной системой предприятия и системой программного обеспечения, разрабатываемого для этой системы. Под системой понимают любой объект, который одновременно рассматривает- ся и как единое целое, и как объединенная в интересах достижения поставленных целей совокупность разнородных элементов. Системы значительно отличаются ме- жду собой как по составу, так и по главным целям. Добавление к понятию «система» слова «информационная» отражает цель ее создания и функционирования. Приведем одно из определений информационной системы, получившее наиболее широкое распространение и приведенное, например, в учебнике [1]. Информационная система — взаимосвязанная совокупность средств, мето- дов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленных целей. Исторически первыми видами информационных систем являются архивы и библиотеки. Им присущи все атрибуты информационной системы. Они обеспечивают в какой-либо предметной области сбор данных, их представ- ление и хранение в определенной форме (книго-, архивохранилища, каталоги и т. д.), в них определяется порядок использования информационных фондов (т. е. определены абоненты, режимы и способы выдачи информации — або- нементы, читальные залы и т. п.). Современное понимание информационной системы предполагает ис- пользование средств вычислительной техники в качестве основных техниче- ских средства переработки информации. Информационная система обеспе- чивает формирование и управление информацией в интересах людей. Часть этой информации генерируется автоматически компьютерными системами. Другая часть вводится людьми вручную, поэтому техническое воплощение информационной системы само по себе ничего не будет значить, если не уч- тена роль человека, для которого предназначена производимая информация и без которого невозможно ее получение и представление. Практика создания и использования автоматизированных информацион- ных систем в различных сферах деятельности позволяет дать более широкое и универсальное определение, которое полнее отражает все аспекты их сущ- ности. Под информационной системой в дальнейшем понимается организованная совокупность программно-технических и других вспомогательных средств, техно- логических процессов и функционально-определенных групп работников, обеспе- чивающих сбор, представление и накопление информационных ресурсов в опре- деленной предметной области, поиск и выдачу сведений, необходимых для удов- летворения информационных потребностей установленного контингента пользователей — абонентов системы. Другими словами, информационные системы — социальные системы, которые включают и используют ПО и другие компоненты в интересах предприятия. 6 Можно выделить следующие компоненты информационной системы: люди; данные/информация; процедуры; ПО; аппаратное обеспечение; линии связи. Системы ПО, разработке и проектированию которых посвящена основ- ная часть изучаемого курса, являются частью (хотя и фундаментальной) на- много большей информационной системы предприятия. Л. Мацяшек [2] приводит диаграмму Венна, демонстрирующую включение системы ПО в информационную систему предприятия, которая, в свою очередь, является компонентом предприятия как целого, а само предприятие является частью бизнес-среды (рис. 1). Рис. 1. Диаграмма Венна, демонстрирующая включение системы ПО в информационную систему предприятия Различие между процессом создания и эксплуатации ПО, с одной сторо- ны, и бизнес-процессом, с другой, определяется и связано с продуктом или сервисом, которые ожидается получить от этих процессов. Результат процесса создания и эксплуатации ПО — ПО. Результат бизнес-процесса — бизнес. Имеются четкие отношения между ПО и бизнесом. ПО — потенциально главный вкладчик в бизнес-успех. ПО — часть бизнеса, но не наоборот. Факти- чески это отношение старшинства было отображено на рис. 1. Предприятие на рис. 1 — это другой термин для обозначения бизнеса. Цель функционирования предприятия состоит в том, чтобы сформировать цепочку создания ценностей, которая обеспечивает реализацию бизнес-назначения, задач и целей. Различие между процессом создания, эксплуатации ПО и бизнес- процессом сродни различию между эффективностью процесса и результа- тивностью. 7 Эффективность (efficiency) означает «делать что-то правильно». Ре- зультативность (effectiveness) означает «делать правильную вещь». В орга- низационных терминах результативность подразумевает достижение бизнес- назначения, задач и целей. Все они — то, что нужно получить как результат процесса стратегического планирования, проводимого на предприятии. Ча- стью стратегического планирования является бизнес-моделирование. Следо- вательно, целью бизнес-процесса является обеспечение результативности. В противоположность этому процесс создания и эксплуатации ПО дол- жен обеспечить эффективность. Следовательно, возможна ситуация, когда процесс создания и эксплуатации ПО даст очень эффективный программный продукт или сервис, который будет нерезультативен для бизнеса. В лучшем случае нерезультативность может означать нейтральный результат с точки зрения бизнеса. В худшем случае это может сделать бизнес уязвимым для конкурентов и даже привести к банкротству. Поэтому ясно, что процесс создания и эксплуатации ПО является харак- терной частью бизнес-процесса, жизненно важной для успеха предприятия. Чтобы обеспечить результативность наряду с эффективностью, процесс создания и эксплуатации ПО должен быть составной частью бизнес-процесса. В конце концов, решение разрабатывать ли программный продукт или сервис в первую очередь будет результатом стратегического планирования и бизнес-моделирования. Процесс программной инженерии устанавливает соответствие ПО и биз- нес-процессов. С одной стороны, разработка ПО все более и более внедряет- ся в среду бизнес-моделирования. С другой стороны, разработка ПО предназначена для поставки про- граммных продуктов и сервисов, увеличивая для предприятия стоимость бизнеса. Это имеет отношение к трем уровням управления, которые бизнес- процессы обслуживают: оперативный, тактический и стратегический. Помещение разработки ПО в среду бизнес-моделирования означает, что процесс создания и эксплуатации ПО получается из более широкой бизнес- модели и старается поддерживать и реализовывать конкретный бизнес- процесс в этой модели. Отсюда следует, что программный продукт/сервис не может быть только информационным сервисом. Он также должен реализо- вывать бизнес-операции или содействовать им. Проект информационной системы должен или явно определить бизнес-процесс, который он обслужи- вает, или, что лучше, быть частью системы управления знаниями. Контрольные вопросы 1. Дайте определение проектирования. 2. Дайте определение проектирования программного обеспечения. 3. Дайте определение системы. 4. Дайте определение информационной системы. 5. Какие компоненты информационной системы можно выделить? 6. В чем различие между процессом создания и эксплуатации ПО и бизнес-процессом? 8 2. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ 2.1. Понятие и модели жизненного цикла В программной инженерии термин «жизненный цикл» (на английском языке lifecycle, обычно пишется единым словом) применяется к искусственным системам ПО и означает изменения, которые происходят в «жизни» программного продукта. Различные стадии между «рождением» изделия и его возможной «смер- тью» известны как стадии жизненного цикла. Наиболее часто говорят о следующих моделях жизненного цикла: каскадная (водопадная) или последовательная; итеративная и инкрементальная-эволюционная (гибридная, смешанная); спиральная (модель Боэма). Легко обнаружить, что в разное время и в разных источниках приводится разный список моделей и их интерпретация. Например, ранее, инкременталь- ная модель понималась как построение системы в виде последовательности сборок (релизов), определенной в соответствии с заранее подготовленным планом и заданными (уже сформулированными) и неизменными требования- ми. Сегодня об инкрементальном подходе чаще всего говорят в контексте по- степенного наращивания функциональности создаваемого продукта. Может показаться, что индустрия пришла, наконец, к общей «правиль- ной» модели. Однако каскадная модель, многократно «убитая» и теорией, и практикой, продолжает встречаться в реальной жизни. Спиральная модель является ярким представителем эволюционного взгляда, одновременно пред- ставляя собой единственную модель, уделяющую явное вниманиеанализу и предупреждению рисков. Рассмотрим и охарактеризуем три модели — каскадную, эволюционную и спиральную. 2.2. Каскадная (водопадная) модель Данная модель предполагает строго последовательное (во времени) и од- нократное выполнение всех фаз проекта с жестким (детальным) предвари- тельным планированием в контексте предопределенных или однажды и це- ликом определенных требований к программной системе. 9 На рис. 2 изображены типичные фазы каскадной модели жизненного цикла и соответствующие активы проекта, являющиеся для одних фаз выхо- дами, а для других — входами. Рис. 2. Каскадная модель жизненного цикла При активном использовании эта модель продемонстрировала свою про- блемность в подавляющем большинстве ИТ-проектов, за исключением, мо- жет быть, отдельных проектов обновления программных систем для крити- чески-важных программно-аппаратных комплексов (например, авионики или медицинского оборудования). Практика показывает, что в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких систем (если можно говорить о «специфике» для подав- ляющего большинства создаваемых систем) в том, что требования характе- ризуются высокой динамикой корректировки и уточнения, невозможно чет- ко и однозначно определить требования до начала работ по реализации (осо- бенно, для новых систем) и быстрой изменчивостью требований в процессе эксплуатации системы. Фредерик Брукс во втором издании своего классического труда «Мифи- ческий человеко-месяц» так описывает главную беду каскадной модели: «Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исхо- дит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы» [3]. В каскадной модели переход от одной фазы проекта к другой предпола- гает полную корректность результата (выхода) предыдущей фазы. Однако, например, неточность какого-либо требования или некорректная его интер- претация приводит к тому, что приходится «откатываться» к ранней фазе проекта, а требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Кроме того, эта модель не способна гарантировать необходимую скорость 10 отклика и внесение соответствующих изменений в ответ на быстро меняю- щиеся потребности пользователей, для которых программная система явля- ется одним из инструментов исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно много для отказа от каскадной модели жизненного цикла. |