Введение. 1 Исторические аспекты развития
 Скачать 158 Kb.
|
|
Введение Современные компании и организации функционируют в условиях большого объема постоянно изменяющейся информации, которую необходимо оперативно анализировать и принимать правильные решения. Бурно развивается вычислительная техника и информационные технологии. Трудно найти сейчас компанию, не занимающуюся развитием информационных технологий. Современные руководители фирм полностью отдают себе отчет в том, что в настоящее время успешность и прибыльность компании полностью зависят в том числе, и от уровня развития IT-технологий, скорости и качества обработки информации, обоснованности и взвешенности принимаемых решений. Требуется постоянная серьезная работа не только IT-специалистов, но и топ-менеджеров по согласованию или точнее – синхронизации всех усилий по стратегическому развитию компании и её информационных систем. Большой ошибкой является позиция руководителей компаний, которые, внедрив однажды информационную систему, перестают ею заниматься. Поэтому процесс проектирования информационных систем в настоящее время становиться обязательным. В данном случае, если этот процесс не впервые осуществляется компанией, то термин проектирование приравнивается к понятию развитие информационной системы. Этим объясняется бурное развитие технологий проектирования информационных систем (ИС) в последние годы. Прежде всего, создание CASEтехнологий, которые во много сокращают сроки проектирования ИС, позволяют организовать одновременную коллективную работу, оперативно вносить изменения и быстро реагировать на изменение обстановки на предприятии. Особое место занимают современные информационные технологии ведения электронной коммерции, работа с заказчиками и поставщиками. И в этом направлении проектирование и развитие информационных систем не возможно без знания основных методологий и программных средств, позволяющих в кратчайшие сроки и без ошибок управлять этими процессами. Компании получают колоссальные конкурентные преимущества. 1.2. Исторические аспекты развития технологий проектирования информационных систем Середина прошлого столетия ознаменовалась началом активного развития информационных технологий. Прежде всего, военные ведомства и передовые предприятия многих стран понимают важность и ценность создания и развития информационных систем. С появлением вычислительной техники обработка больших объемов информации и автоматизация основных производственных процессов и органов управления на всех уровнях становятся наиважнейшей задачей для обеспечения военного превосходства наиболее развитых государств и конкурентных преимуществ коммерческих компаний. Разработчики национальных и крупномасштабных информационных систем стали первыми осознавать необходимость создания специальных средств проектирования и моделирования бизнес-процессов, позволяющими сделать их работу более эффективной и сократить не только сроки создания информационных систем, но минимизировать ошибки. Ошибки и неточности встречаются постоянно, чем раньше они диагностируется и локализуется, тем меньше стоимость переделки. Известно, что стоимость выявление и устранение ошибки на стадии проектирования в два раза обходится дороже, на стадии тестирования информационной системы в десять раз, а на стадии эксплуатации в сто раз, чем на стадии анализа бизнес-процессов и разработки технического задания. При создании сложных информационных систем зачастую очень трудно понять требования персонала заказчика. Они могут быть сформулированы некорректно, а в процессе анализа конкретных бизнес-процессов даже измениться. Поэтому появление методологий современного проектирования и моделирования информационных систем было насущной задачей, над которой работали специалисты разных стран. Появление автоматизированных систем управления в шестидесятых годах прошлого столетия определялось получением начальных знаний и опыта их разработки и внедрения. Анализировались все успехи и неудачи создания первых АСУ, но бесспорным было сокращение времени обработки информации, производственных и управленческих затрат и как следствие персонала. Опыт зарубежных компаний по разработке и внедрению корпоративных информационных систем свидетельствует о появлении программ, в первую очередь связанных с автоматизацией учетных функций бухгалтерий, отдела кадров и складов. И намного позже появляются другие автоматизированные системы управления производством, логистикой, взаимоотношениями с клиентами и поставщиками. На последнем этапе разрабатываются информационные системы управления всей компанией, позволяющие полностью перейти к электронному документообороту и автоматизировать все сферы деятельности фирмы. С появлением персональных компьютеров происходит децентрализация процессов управления, все чаще внедряются модули с распределенными системами обработки информации. На следующем этапе, в семидесятых годах прошлого столетия пришло понимание, что информация – стратегический ресурс любой компании, который необходимо грамотно использовать. В тоже время главными потребителями информации являются руководители. Идеи использования распределенных систем не находят пока применения из-за отсутствия компактной вычислительной техники, которая появится позднее и перевернет весь мир. В компаниях и организациях создаются информационные отделы и службы, вычислительные центры и лаборатории. Восьмидесятые годы характеризуются появлением специализированных методологий проектирования информационных систем и CASE-средств. На их основе разрабатываются первые программные средства, а персональные компьютеры позволяют приступить к созданию децентрализованных информационных систем. Различные персональные компьютеры объединяются в локальную сеть. Этот период характеризуется интеграций информационных систем и появлением различных концепций управления ими на единой методологической основе. Девяностые годы стали триумфом персональных компьютеров. Невысокая стоимость и компактные размеры сделали их чрезвычайно популярными и общедоступными для индивидуализации использования при решении управленческих задач. Разрабатываются корпоративные информационные системы, реализующие принципы распределенной обработки данных. Становится возможным автоматизация всех отделов и служб компаний, а не только бухгалтерии. Появляются системы электронного документооборота, в том числе для предприятий с развитой филиальной сетью в разных городах и регионах. Сокращаются сроки обработки данных, производственных, складских и прочих управленческих отчетов. Появление и развитие методологий моделирования и проектирования информационных систем не было простым процессом. На всех этапах этого пути были талантливые, энергичные, необычайно трудолюбивые люди, которые вкладывали свои знания, силы, опыт, а порой и денежные средства для успешной реализации информационных проектов. Вот некоторые из них: В СССР основателем и теоретиком автоматизированных систем управления был выдающийся ученый академик В.М. Глушков. Под его руководством в 1963-1964 годах в Институте кибернетики Академии наук СССР были начаты работы по созданию автоматизированных систем сбора, учета, обработки данных, оперативно-календарного планирования производства на базе отечественной вычислительной техники. При этом ставилась задача разработки универсальной АСУ, пригодной для внедрения на многих предприятиях страны. Опытная эксплуатация и апробация проходили на самых современных предприятиях государства, таких как Львовский телевизионный завод «Электрон» и Кунцевский радиозавод. Некоторые решения были признаны и за рубежом, так была предложена общая алгоритмическая схема последовательного анализа вариантов, включавшая в себя вычислительные методы динамического программирования (В. С. Михалевича и Н. З. Шора). В.В. Шкурба развил эту схему вместе с методами имитационного моделирования для решения задач упорядочения, в частности в теории расписаний и календарного планировании. В 1970-1980-х годах информационные системы интегрировались в комплексные АСУ, решающие задачи автоматизированного проектирования новых изделий, технологической подготовки производства и автоматизации организационного управления предприятием. Комплексные АСУ были разработаны и внедрены на Ульяновском авиационном заводе и других предприятиях оборонного комплекса под руководством А. А.Морозова, В. И. Скурихина. Комплексные АСУ создавались научно-исследовательскими институтами такими как, Всесоюзного объединения “Союзсистемпром” Минприбора СССР: ЦНИИТУ, г. Минск; ГНИПИ ВТ, г. Казань; НИИУМС, г. Пермь и др. В США Дуглас Т. Росс (SoftTech, Inc) разработал язык АПТ для работы станков с ЧПУ, который в средине 60-х положил начало разработкам графических языков моделирования. А в 1969 году им же предложена методология SADT (IDEF0) для моделирования информационных систем средней сложности, в рамках программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой департаментом Военно-Воздушных Сил США в рамках большого аэрокосмического проекта. К концу двадцатого века было разработано несколько десятков методов моделирования сложных систем. Они все были разные по функциональным возможностям, но во многом имели схожие подходы к анализу и описанию предметной области. Возникла острая необходимость объединения удачных решений в одну методику, которая устраивала большую часть разработчиков информационных систем. В результате этих процессов был разработан язык UML. У многих ведущих компаний, таких как Rational Software, Oracle Corporation, IBM, Microsoft, HewlettPackard, i-Logix, Texas Instruments и Unisys была четкая уверенность в необходимости создания подобного языка программирования. С этой целью был создан консорциум UML Partners, рабочую группу по семантике UML возглавил Крис Кобрин. Ведущую роль в создании унифицированного языка моделирования (UML) сыграли Гради Буч, Айвар Джекобсон и Джеймс Рамбо, работающие в компании Rational Software. Ими разработаны следующие методы объектного моделирования сложных информационных систем: Метод объектного моделирования программного обеспечения сложных информационных систем (метод Буча). Метод анализа требований к бизнесприложениям (метод Джекобсона). Метод анализа обработки данных в сложных информационных системах (метод Рамбо). Предварительная версия 0.8 унифицированного метода программирования была выпущена в октябре 1995 года. Первая версия UML 0.9 вышла в июне 1996 году и получила мощную поддержку Группы OMG, занимающейся разработкой единых стандартов в сфере web-технологий, включающую в себя несколько сотен компаний, работающих в области IT-технологий и производстве компьютерной техники. Это позволило выпустить в первый года сразу несколько версий. Так, в 1997 году появляется сразу две версии UML 1.0 и UML 1.1. В 1998 году разработчиками представляется версия UML 1.2, в 1999 году версия UML 1.3, в 2001 году выходит версия UML 1.4, а в 2003 году версия UML 1.5. Эта версия и принимается в качестве международного стандарта ISO/IEC 19501-2005. Сейчас наиболее популярна версия UML 2.4.1, вышедшая в 2011 году, которая тоже оформлена виде международных стандартов ISO/IEC 19505-1 и 19505- 2. Для нее разработаны инструментальные средства поддержки и визуального программирования, осуществляющих прямую генерацию кода из моделей UML, в основном посредством языков программирования С++ и Java. Среди них программы Rational Rose и Visual Paradigm for UML. В настоящее время методологии и средства моделирования бизнес-процессов, процессно ориентированных методов анализа и проектирования информационных систем широко представлены как в России, так и в большинстве стран мира. 1 Классификация информационных систем Под системой понимают любой объект, который одновременно рассматривается и как единое целое, и как объединенная в интересах достижения поставленных целей совокупность разнородных элементов. Системы значительно различаются между собой как по составу, так и по достигаемым целям. Информационные системы обеспечивают сбор, хранение, обработку, поиск и выдачу информации, необходимой в процессе принятия решений в любой области деятельности. Они помогают анализировать проблемы и создавать новые продукты. Информационная система – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленой цели. Современное понимание информационной системы предполагает использование персонального компьютера в качестве основного технического средства переработки информации. В крупных организациях наряду с персональным компьютером в состав технической базы информационной системы может входить мэйнфрейм или суперЭВМ. Кроме того, техническое воплощение информационной системы само по себе ничего не будет значить, если не учтена роль человека, для которого предназначена производимая информация и без которого невозможно ее получение и представление. В свою очередь информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации 1.2.1. Классификация по архитектуре По степени распределённости отличают: настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере; распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам. Распределённые ИС, в свою очередь, разделяют: на файл-серверные ИС (ИС с архитектурой «файл-сервер«); клиент-серверные ИС (ИС с архитектурой «клиент-сервер«). В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях. В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения. В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные. В двухзвенных (two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД (back-end), и рабочие стан7 ции, на которых находятся клиентские приложения (front-end). Клиентские приложения обращаются к СУБД напрямую. В многозвенных (multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения многозвенности − современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено − веб-сервер с соответствующим серверным программным обеспечением. 1.2.2. Классификация по степени автоматизации По степени автоматизации ИС делятся: на автоматизированные: информационные системы, в которых автоматизация может быть неполной (то есть требуется постоянное вмешательство персонала); автоматические: информационные системы, в которых автоматизация является полной, то есть вмешательство персонала не требуется или требуется только эпизодически. «Ручные ИС» («без компьютера») существовать не могут, поскольку существующие определения предписывают обязательное наличие в составе ИС аппаратно-программных средств. Вследствие этого понятия «автоматизированная информационная система», «компьютерная информационная система» и просто «информационная система» являются синонимами. 1.2.3. Классификация по характеру обработки данных По характеру обработки данных ИС делятся: на информационно-справочные, или информационно-поисковые ИС, в которых нет сложных алгоритмов обработки данных, а целью системы является поиск и выдача информации в удобном виде; ИС обработки данных, или решающие ИС, в которых данные подвергаются обработке по сложным алгоритмам. К таким системам в первую очередь относят автоматизированные системы управления и системы поддержки принятия решений. 1.2.4. Классификация по сфере применения Поскольку ИС создаются для удовлетворения информационных потребностей в рамках конкретной предметной области, то каждой предметной области (сфере применения) соответствует свой тип ИС. Перечислять все эти типы не имеет смысла, так как количество пред8 метных областей велико, но можно указать в качестве примера следующие типы ИС: Экономическая информационная система − информационная система, предназначенная для выполнения функций управления на предприятии. Медицинская информационная система − информационная система, предназначенная для использования в лечебном или лечебнопрофилактическом учреждении. Географическая информационная система − информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных (пространственных данных). 1.2.5. Классификация по охвату задач (масштабности) Персональная ИС предназначена для решения некоторого круга задач одного человека. Групповая ИС ориентирована на коллективное использование информации членами рабочей группы или подразделения. Корпоративная ИС в идеале охватывает все информационные процессы целого предприятия, достигая их полной согласованности, безызбыточности и прозрачности. Такие системы иногда называют системами комплексной автоматизации предприятия. 1.5. Жизненный цикл проекта по созданию ИС Понятие жизненного цикла информационной системы (ЖЦ ИС) Каждый проект, независимо от сложности и объема работ проходит в своем развитии путь от состояния когда «проекта еще нет» до состояния когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы, стадии и этапы. ЖЦ ИС – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации. В определении количества фаз и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее логика и основное содержание процесса разработки ИС почти во всех случаях являются общими. Здесь можно выделить следующие фазы развития ИС: 1) концептуальная фаза. Главным содержанием работ на этой фазе является определение проекта и разработка его концепции, включающая: • формирование идеи, постановку целей; • формирование ключевой команды проекта; • изучение мотивации и требований заказчика и других участников; • сбор исходных данных и анализ существующего состояния (предпроектное обследование объекта автоматизации); • определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов; • сравнительную оценку альтернатив; • представление предложений, их экспертизу и утверждение; 2) разработка технического предложения. Главным содержанием этой фазы является разработка технического предложения и переговоры с заказчиком о заключении контракта. Общее содержание работ этой фазы: • разработка основного содержания и базовой структуры проекта; • разработка и утверждение технического задания; • планирование и декомпозиция базовой структурной модели проекта; • составление сметы и бюджета проекта, определение потребности в ресурсах; • разработка календарных планов и укрупненных графиков работ; • подписание контракта с заказчиком; • ввод в действие средств коммуникации участников проекта и средств контроля за ходом работ; 3) проектирование. На этой фазе определяются подсистемы, их взаимосвя- 59 зи, выбираются наиболее эффективные способы выплнения проекта и использования ресурсов. В основе проектирования ИС лежит моделирование предметной области. Цель моделирования – избежать ошибок, приводящих к экономическим потерям и затратам на последующее перепроектирование системы. Другие работы, характерные для фазы проектирования: • выполнение базовых проектных работ; • разработка частных технических заданий; • выполнение концептуального проектирования; • составление технических спецификаций и инструкций; • представление проектной разработки, экспертиза и утверждение. 4) разработка. На этой фазе производятся координация и оперативный контроль работ по проекту, осуществляется изготовление подсистем, их объединение и тестирование. Основное содержание фазы: • выполнение работ по разработке программного обеспечения; • выполнение подготовки к внедрению системы; • контроль и регулирование основных показателей проекта; 5) ввод системы в эксплуатацию. На этой фазе проводятся испытания, опытная эксплуатация системы в реальных условиях, ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах. Основные виды работ: • комплексные испытания; • подготовка кадров для эксплуатации создаваемой системы; • подготовка рабочей документации, сдача системы заказчику и ввод ее в эксплуатацию; • сопровождение, поддержка, сервисное обслуживание; 6) изъятие из эксплуатации или замена: • оценка результатов проекта и подготовка итоговых документов; • разрешение конфликтных ситуаций и закрытие работ по проекту; 60 • накопление опытных данных для последующих проектов, анализ опыта, состояния, определение направлений развития. На обнаружение ошибок, допущенных на стадии проектирования, расходуется примерно в два раза больше времени, чем на последующих фазах, а их исправление обходится в пять раз дороже. Поэтому на начальных стадиях проекта разработку следует выполнять особенно тщательно. Наиболее частые ошибки, допускаемые на начальных этапах: 1) ошибки в определении интересов заказчика; 2) концентрация на маловажных, сторонних интересах; 3) неправильная интерпретация исходной постановки задачи; 4) неправильное или недостаточное понимание деталей; 5) неполнота функциональных спецификаций (системных требований); 6) ошибки в определении требуемых ресурсов и сроков; 7) редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика). Модели жизненного цикла ИС Моделью жизненного цикла ИС будем называть некторую структуру, определяющую последовательность выполнения процессов, действий и задач, выполняемых на протяжении ЖЦ ИС, а также взаимосвязи между этими процессами, действиями и задачами. К настоящему времени наибольшее распространение получили следующие две модели ЖЦ каскадная (70-85 гг.) и спиральная (86-90 гг.). Каскадная модель ЖЦ Основной характеристикой какскадного способа является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.6.). Рис.  1.6. Каскадная схема разработки ПО Создание системы рассматривается как однократная последовательность стадий и этапов. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Достоинства каскадного подхода: 1) на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; 2) выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Недостатки каскадного подхода выявились в процессе его использования. Дело в том, что реальный процесс создания ПО почти никогда полностью не укладывается в жесткую схему каскадной модели. В процессе создания ПО может возникнуть потребность возврата к предыдущему этапу и уточнения или пересмотра ранее принятых решений. В результате реальный процесс создания ПО часто принимает следующий вид  Основной недостаток каскадного подхода – существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Область применения каскадного подхода (где каскадный подход хорошо зарекомендовал себя): 1) однородные ИС, где каждое приложение представляет собой единое целое; 2) ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные системы. Спиральная модель ЖЦ Поскольку программные проекты отличаются от других, например, строительных проектов, то и управлять ими тоже нужно по-другому. Наглядным подтверждением этого является тот факт, что к концу 1980-х гг. Министерство обороны США начало испытывать серьезные трудности с разработкой ПО в соответствии с жесткой, основанной на директивных документах и предусматривающей один проход модели, как это требовалось стандартом DoD-Std2167A. Проведенная позже в 1999 проверка по выборке ранее утвержденных в Министерстве обороны проектов дала удручающие результаты. Из общего числа входящих в выборку проектов, на реализацию которых было выделено 37 млрд долл., 75% проектов закончились неудачей или выделенные на них средства не были использованы, и только 2% выделенных средств были использованы без значительной модификации проектов. В результате в конце 1987 г. Министерство отступило от стандартов на базе каскадной модели и допустило применение итерационного подхода. Истоки концепции итерационной разработки прослеживаются в относящихся к 1930-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из компании Bell Labs, который предложил ориентированную на повышение качества методику, состоящую из серии коротких циклов шагов по планированию, реализации, изучению и действию (plan-do-study-act, PDSA). С 1940-х годов энергичным поборником PDSA стал известный авторитет в области качества Эдварде Деминг. В более поздних работах PDSA была исследована применительно к разработке ПО. В середине 1980-х годов Барри Боэм предложил свой вариант итерационной модели под названием «спиральная модель» (spiral model). Принципиальные особенности спиральной модели: • отказ от фиксации требований и назначение приоритетов пользовательским требованиям; • разработка последовательности прототипов, начиная с требований наивысшего приоритета; • идентификация и анализ риска на каждой итерации; • использование каскадной модели для реализации окончательного прототипа; • оценка результатов по завершении каждой итерации и планирование следующей итерации. При использовании спиральной модели прикладное ПО создается в несколько итераций (витков спирали) методом прототи-пирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 1.8.), делающая упор на начальные этапы ЖЦ: анализ и проектирование.  На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. 69 В рамках спиральной модели была разработана методология RAD (Rapid Application Development, 1980 – разработка подхода, James Martin в IBM, 1991 – публикация), использующая инструментальные средства быстрой разработки ПО. Методологии и технологии проектирования ИС 1.3.1. Общие требования к методологии и технологии Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования определяется как совокупность трех составляющих: пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4); критериев и правил, используемых для оценки результатов выполнения технологических операций; нотаций (графических и текстовых средств), используемых для описания проектируемой системы.  Рис. 1.4. Представление технологической операции проектирования Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям: технология должна поддерживать полный ЖЦ ПО; технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций; технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам; технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования); технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7. Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие: стандарт проектирования; стандарт оформления проектной документации; стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать: набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.; требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д. Стандарт оформления проектной документации должен устанавливать: комплектность, состав и структуру документации на каждой стадии проектирования; требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; правила использования клавиатуры и мыши; правила оформления текстов помощи; перечень стандартных сообщений; правила обработки реакции пользователя. Методология RAD Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: фаза анализа и планирования требований; фаза проектирования; фаза построения; фаза внедрения. На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС. На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы: определяется необходимость распределения данных; производится анализ использования данных; производится физическое проектирование базы данных; определяются требования к аппаратным ресурсам; определяются способы увеличения производительности; завершается разработка документации проекта. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям. На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой. Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки. Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом: < 1000 функциональных элементов один человек 1000-4000 функциональных элементов одна команда разработчиков > 4000 функциональных элементов 4000 функциональных элементов на одну команду разработчиков В качестве итога перечислим основные принципы методологии RAD: разработка приложений итерациями; необязательность полного завершения работ на каждом из этапов жизненного цикла; обязательное вовлечение пользователей в процесс разработки ИС; необходимое применение CASE-средств, обеспечивающих целостность проекта; применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы; необходимое использование генераторов кода; использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя; тестирование и развитие проекта, осуществляемые одновременно с разработкой; ведение разработки немногочисленной хорошо управляемой командой профессионалов; грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. Заключение Проектирование информационной системы - это один из важнейших этапов ее существования то, с чего, собственно, должна начинаться её жизнь. Таким образом, прежде чем проектировать сеть, нужно понять, какие задачи будет решать сеть, какими будут основные потоки трафика, как физически будут расположены пользователи и ресурсы, нужно ли задание приоритетов видов трафика, как будут решаться вопросы защиты информации внутри сети, как сеть будет подключена к Интернет, как решить задачи управления правами доступа пользователей. Кроме того, в задачу предпроектного исследования входит изучение состояния зданий и сооружений в месте развертывания сети, анализ существующей инфраструктуры. Эта информация жизненно необходима как для постановки задачи проектирования, так и для самого проектирования. Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем. |