Лекция 1 Информационные системы и их классификации
Скачать 1.11 Mb.
|
| Использование SilverRun Методология Планирование и разработка комплексных информационных систем невозможны без тщательно обдуманного методологического подхода. Какие этапы необходимо пройти, какие методы и модели использовать, как организовать контроль за продвижением проекта и качеством выполнения работ - эти вопросы решаются методологиями программной инженерии. Методологий существует много, и главное в них - единая дисциплина работы на всех этапах жизненного цикла системы. Если учитываются все критические задачи и контролируется их решение, качество создаваемых систем значительно возрастает. При этом, в общем случае, не важно, какие конкретно методы были выбраны для решения этих задач. Для различных классов систем используются свои методы разработки. Они определяются как типом создаваемой системы, так и средствами реализации. Вероятно, самыми распространенными по объемам разработок являются информационные системы бизнес-класса. Практически в каждой организации имеются специалисты, разрабатывающие или сопровождающие информационные системы. Спецификация этих систем в большинстве случаев состоит из двух основных компонентов: функционального и информационного. По способу сочетания этих компонентов подходы к представлению информационных систем можно разбить на два основных типа - структурный и объектно-ориентированный. Разумеется, объектно-ориентированные методы также являются структурными в прямом понимании этого слова. Но исторически в программной инженерии этот термин закрепился за рядом дисциплин: структурное программирование, структурный дизайн, структурный анализ. В структурных технологиях функциональная и информационная модели строятся отдельно, чаще всего в виде диаграмм потоков данных и диаграмм "сущность-связь". Объектно-ориентированные технологии рассматривают информацию неотъемлемо от процедур ее обработки. Модели объектно-ориентированных технологий описывают структуру, поведение и реализацию систем в терминах классов объектов. Объектно-ориентированные технологии доминируют в области создания операционных систем, средств разработки и исполнения приложений, систем реального времени. Концепция объекта помогает бороться с быстро растущей сложностью систем. Кроме того, взаимодействующие электронные устройства, как и элементы программ, естественно представляются объектами. В области создания бизнес-систем лидируют структурные технологии, так как они максимально приспособлены для взаимодействия с заказчиками и пользователями, не являющимися специалистами в области информационных технологий. А анализ опыта разработок информационных систем показал, что активное привлечение пользователей на этапах выявления требований и постановки задачи является критическим фактором успеха крупных проектов. При разработке систем бизнес-класса основные усилия затрачиваются именно на понимание и спецификацию требований пользователя, а для реализации используются покупные средства разработки приложений (чаще всего языки четвертого поколения) и системы управления базами данных (чаще всего реляционные). В терминах вышесказанного, место системы SILVERRUN в технологиях программной инженерии можно определить следующим образом: это CASE-система верхнего уровня, предназначенная для инструментальной поддержки структурных методологий создания информационных систем бизнес-класса. Таким образом, эта система может быть использована специалистами, занимающимися анализом и моделированием деятельности предприятий, разработчиками информационных систем, администраторами баз данных. Средства управления проектом Для контроля выполнения всех предусмотренных выбранной методологией действий используются специальные средства. В них расписываются все шаги проектной деятельности, и для каждого шага назначаются ответственные за его выполнение специалисты. Обычно средства управления проектом дают возможность прогнозировать сроки и стоимость выполнения проекта с учетом сложности задачи, количества и квалификации персонала. В системе регистрируются план-графики работ и выполнение заданий. На основании полученных в процессе работы данных система может пересчитать прогноз стоимости и длительности проекта. Также обычно имеется возможность учитывать результаты предыдущих проектов, подстраивая таким образом планирование под темпы работы конкретного коллектива. Использование средств управления проектом позволяет значительно усилить контроль проектной деятельности и гарантировать выполнение всех предусмотренных методологией действий. CASE-система верхнего уровня Как уже упоминалось, самой критической фазой жизненного цикла информационной системы является анализ требований, включающий спецификацию правил работы и разработку архитектуры систем. Программист может не знать правила растаможивания товаров или проведения финансовых операций. Но он должен создать систему, обеспечивающую корректное выполнение этих действий. Это возможно только при наличии их детальных спецификаций. А если на этапе проектирования был сделан неправильный выбор архитектуры системы, может значительно снизиться эффективность ее использования. Подобные ошибки невозможно компенсировать даже высоким качеством реализации. Правильно решить такие задачи можно, только работая совместно с пользователями. Не случайно тесное взаимодействие с пользователем и полная спецификация требований стоят на первом месте в списке факторов, определяющих успех или крах проекта. CASE-системы верхнего уровня предназначены для автоматизированной поддержки создания спецификаций, с одной стороны, понятных пользователю, с другой стороны, содержащих технические детали для разработчиков. Эти системы позволяют постепенно переходить от формирования бизнес-требований к генерации реализующих эти требования приложений. Ниже будет показано, как это осуществляется в системе SILVERRUN. Средства поддержки проектирования систем При разработке архитектуры системы "клиент-сервер" бывает необходимо проверить работоспособность принятого решения. Для этой цели предназначены специализированные средства, например эмуляторы систем распределенной обработки. С помощью таких средств можно оценить требуемую пропускную способность каналов связи и мощность рабочих станций. При больших масштабах, характерных для распределенных систем, потери, возникающие вследствие построения неработоспособной архитектуры, могут быть очень велики. Поэтому затрата времени и средств на предварительный анализ выбранной архитектуры чаще всего бывает оправдана. Средства управления разработкой приложений Коллективная разработка больших информационных систем значительно упрощается при использовании автоматизированных систем ее поддержки. Трекеры ошибок и системы контроля версий позволяют синхронизировать работу удаленных групп разработчиков и создавать многоверсионные системы. Языки разработки приложений четвертого поколения Для массового создания информационных систем критична эффективность и относительная простота средств разработки приложений. Этим требованиям удовлетворяют языки четвертого поколения (4GL). Высокая скорость разработки, возможность повторного использования и хорошая переносимость созданных на этих языках приложений сделали языки четвертого поколения наиболее используемыми средствами разработки систем бизнес-класса. SILVERRUN имеет возможность передать информацию в репозитории (или словари данных) наиболее распространенных средств создания приложений. При этом экономятся значительные трудозатраты разработчиков. Например, генератор приложений SILVERRUN для PowerBuilder может генерировать из модели данных до 75% кода приложения. Лекция 9. Методологии и технологии проектирования ИС Общие требования к методологии и технологии Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования определяется как совокупность трех составляющих: · пошаговой процедуры, определяющей последовательность технологических операций проектирования; · критериев и правил, используемых для оценки результатов выполнения технологических операций; · нотаций (графических и текстовых средств), используемых для описания проектируемой системы. Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям: · технология должна поддерживать полный ЖЦ ПО; · технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; · технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций; · технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; · технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам; · технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; · технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования); · технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие: · стандарт проектирования; · стандарт оформления проектной документации; · стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать: · набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; · правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.; · требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; · механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д. Стандарт оформления проектной документации должен устанавливать: · комплектность, состав и структуру документации на каждой стадии проектирования; · требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.), · правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; · требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; · требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: · правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; · правила использования клавиатуры и мыши; · правила оформления текстов помощи; · перечень стандартных сообщений; · правила обработки реакции пользователя. Методология RAD Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента: · небольшую команду программистов (от 2 до 10 человек); · короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); · повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: · фаза анализа и планирования требований; · фаза проектирования; · фаза построения; · фаза внедрения. На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС. На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть: · общая информационная модель системы; · функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; · точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами; · построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы: · определяется необходимость распределения данных; · производится анализ использования данных; · производится физическое проектирование базы данных; · определяются требования к аппаратным ресурсам; · определяются способы увеличения производительности; · завершается разработка документации проекта. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям. На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой. Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки. Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:
|
Похожие:
 | Методические указания предназначены для студентов экономических и других специальностей, изучающих дисциплины «Информационные системы»,... | | Рекомендовано методической комиссией филологического факультета для студентов спо ннгу им. Н. И. Лобачевского, обучающихся по направлению... |
| Хирургический метод лечения имеет большое значение в клинической медицине. Одну четверть заболеваний составляют хирургические болезни.... | | Дисциплина «Информационные системы в управлении международными проектами» является обязательной дисциплиной вариативной части дисциплин... |
 | Григорьев М. В. Информационные системы в экономике. Учебно-методический комплекс. Рабочая программа для студентов направления 02.... | | Григорьев М. В. Информационные системы в нефтегазовом комплексе. Учебно-методический комплекс. Рабочая программа для студентов направления... |
| Содержание отчета о преддипломной практике для специальности 230201 «Информационные системы и технологии» 12 | | Содержание отчета о преддипломной практике для специальности 230201 «Информационные системы и технологии» |
| Омской области «Омский промышленно-экономический колледж» по специальности 18. 02. 09 Переработка нефти и газа (базовая подготовка)... | | Омской области «Омский промышленно-экономический колледж» по специальности 18. 02. 01 Аналитический контроль качества химических... |