Разработка информационных систем. Учебное пособие

Сухомлинов А.И.

Возрастное ограничение: 12+ Жанр: Наука Издательство: Проспект Дата размещения: 10.08.2015 ISBN: 9785392189540 Язык: Объем текста: 269 стр. Формат: epub

Оглавление

Предисловие

Глава 1. Архитектура информационных систем

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

Глава 3. Анализ методологий

Для бесплатного чтения доступна только часть главы! Для чтения полной версии необходимо приобрести книгу

Глава 2.
ЖИЗНЕННЫЙ ЦИКЛ И МЕТОДОЛОГИИ РАЗРАБОТКИ СИСТЕМ

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

2.1. Традиционная разработка систем

Разработка систем

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

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

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

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

Область разработки информационных систем

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

Методологии

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

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

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

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

Традиционный жизненный цикл разработки систем

Традиционные информационные системы ранних 1970-х гг. обычно были написаны на языке программирования COBOL и выполнялись на компьютерах мэйнфреймах. Типичная небольшая система того периода могла выводить на печать обобщенные данные о продажах компании для отдела маркетинга. Один из выходных документов, например, мог показывать итоги продаж в разрезе географических районов. Система могла состоять из десяти программ, и трудоемкость ее составления могла составлять двенадцать человеко-месяцев работы по анализу и программированию. Часть этой работы, допустим, восемь человеко-месяцев, могла быть программированием. Такие проекты могут иметь место и сегодня, и они часто решаются подобным образом. Такая система могла разрабатываться в соответствии с традиционным жизненным циклом, который представлен на рис. 2.1. Благодаря своему внешнему виду представленная схема известна как водопадная модель. Как видно из этой модели, основная идея этапа анализа состоит в определении требований и сборе относящихся к делу фактов. После этого может быть сконструирована и запрограммирована система, в частности, программа. Затем эта программа тестируется (испытывается) до применения ее пользователями. Результирующим выходом процесса разработки является программное приложение, готовое для применения, а также относящаяся к нему документация, такая как руководство пользователя системы.

Очень важно осознавать существование выходов для каждого этапа модели «водопад», т.е. выход представляет собой документацию, которая умеренно формальна и в то же самое время естественна для бизнес-пользователей и персонала информационных технологий. Формальность подразумевает не больше чем представление документации в виде подобном учебникам по бизнесу и техническим учебникам. Документация каждого этапа часто представляет собой множество страниц, описывающих существующую или предполагаемую систему. Традиционная документация на систему, по общему мнению, характеризуется сверхмногочисленностью слов и малочисленностью схем. Кроме схем документация часто содержит копии деловых документов, распечаток выходных документов и форматов экранных форм. Документация, связанная с производством полностью новой системы, могла бы составлять несколько больших томов, большинство из которых создаются системным аналитиком.

Рис. 2.1. Упрощенное представление традиционного жизненного цикла

Основные этапы традиционного цикла разработки подробно представлены на рис. 2.2 и объясняются ниже.

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

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

Рис 2.2. Подробное представление традиционного жизненного цикла

Анализ осуществимости выполняется для предложенного компьютерного приложения. Это относительно быстрое исследование. Исследуются различные варианты для новой системы, в частности, их вероятная стоимость и выгоды от применения. Например, бухгалтерский отдел может иметь желание узнать вероятную стоимость и время, требуемое для создания новой системы управления затратами. Обычно существует возможность создать дешевую («сляпанную наспех») версию системы или дорогую («роскошную») версию. Другие варианты могут быть связаны со сравнением версии, реализованной на мэйнфрейме, и противоположной ей, реализованной на локальной сети. Иногда один из вариантов выбора может заключаться не в продолжении выполнения проекта, а, возможно, в продолжении использования старой, уже существующей системы организации. Область определения или масштаб любой работы является ключевым фактором, который должен быть установлен на ранних стадиях проекта, обычно она определяется на этапе анализа осуществимости. Например, включает ли предполагаемая система управления производством завода закупку исходных комплектующих материалов? Основным выходом этапа анализа осуществимости является технико-экономический доклад (обоснование). Он используется как менеджментом, так и пользователями при рассмотрении вариантов и утверждении одного из них, возможно, с рекомендуемой модификацией.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замещение. Под влиянием таких факторов как продолжительно проводимые изменения, программное обеспечение системы становится все более трудоемким в поддержке и все более устаревающим. В конце концов, становится существенным решение вопроса замещения системы. Классическим примером этого являются системы 1960-х гг., написанные на языках программирования 2-го поколения (ассемблеры), которые были замещены системами 3-го поколения (такими как СОBOL) в 1970-х гг. Эти системы, в свою очередь, были замещены пакетами или системами языков 4-го поколения в 1980-х гг. Таким образом, замещение приводит к повторению рассмотренных выше шагов через каждые несколько лет, и системы повторяют жизненный цикл.

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

Рис. 2.3. Распределение трудозатрат в традиционном жизненном цикле

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

Сухомлинов А.И. Разработка информационных систем. Учебное пособие

Сухомлинов А.И. Разработка информационных систем. Учебное пособие

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

Внимание! Авторские права на книгу "Разработка информационных систем. Учебное пособие" (Сухомлинов А.И.) охраняются законодательством!