Главная >> Методички

Pages: |

| 2 | 3 | 4 |

«Д.Г. Штенников Разработка информационных систем в образовании Учебное пособие Санкт-Петербург 2012 1 Штенников Д.Г. Приемы работы с приложениями Picasa и Pixlr. Учебное пособие. – СПб: СПбГУ ИТМО, 2012. – 40 с. ...»

-- [ Страница 1 ] --

Министерство образования и науки Российской Федерации

Федеральное агентство по образованию

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ

Д.Г. Штенников

Разработка информационных систем в

образовании

Учебное пособие

Санкт-Петербург

2012

1 Штенников Д.Г. Приемы работы с приложениями Picasa и Pixlr. Учебное пособие. – СПб: СПбГУ ИТМО, 2012. – 40 с.

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

СПбГУ ИТМО стал победителем конкурса инновационных образовательных программ вузов России на 2007-2008 годы и успешно реализовал инновационную образовательную программу «Инновационная система подготовки специалистов нового поколения в области информационных и оптических технологий», что позволило выйти на качественно новый уровень подготовки выпускников и удовлетворять возрастающий спрос на специалистов в информационной, оптической и других высокотехнологичных отраслях науки. Реализация этой программы создала основу формирования программы дальнейшего развития вуза до 2015 года, включая внедрение современной модели образования.

Штенников Д.Г.,

Подготовка модели для генерации программного кода................. Проверка модели независимо от выбора языка генерации кода... Создание компонентов для реализации классов и отображение классов на компоненты

Выбор языка программирования и редактирование свойств генерации программного кода

Выбор класса или компонента и генерация для него программного кода

7. Тестирование, верификация и документирования ИСО.............. Понятие верификации

Типы процессов тестирования и верификации и их место в различных моделях жизненного цикла

Методы тестирования

Тестовое окружение

Тест-планы

Список литературы

1. ПОДГОТОВИТЕЛЬНЫЙ ЭТАП В РАЗРАБОТКЕ

ИНФОРМАЦИОННЫХ СИСТЕМА В ОБРАЗОВАНИИ

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

Таким образом, жизненный цикл информационной системы охватывает все стадии и этапы ее создания, сопровождения и развития:

• предпроектный анализ (включая формирование функциональной и информационной моделей объекта, для которого предназначена информационная система);

• проектирование системы (включая разработку технического задания, эскизного и технического проектов);

• разработку системы (в том числе программирование и тестирование прикладных программ на основании проектных спецификаций подсистем, выделенных на стадии проектирования);

• интеграцию и сборку системы, проведение ее испытаний;

• эксплуатацию системы и ее сопровождение;

• развитие системы.

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

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

Почти треть проектов информационных систем прекращают свое существование, оставшись незавершенными. По данным, публикуемым Standish Group, в 1996 году 84% проектов информационных систем не были завершены в установленные сроки, в 1998 году сократилась до 74%, однако и в 2000-м общий объем "хронической незавершенки" не опустился ниже 50%.

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

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

Основными стандартами, регламентирующими разработку ИСО в РФ являются два:

ГОСТ 34.601- ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207Стандарт ГОСТ 34.601- Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1. Формирование требований к АС 1. Обследование объекта и обоснование необходимости создания 2. Формирование требований пользователя к АС 3. Оформление отчета о выполнении работ и заявки на разработку 2. Разработка концепции АС 1. Изучение объекта 2. Проведение необходимых научно-исследовательских работ 3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей 4. Оформление отчета о проделанной работе 3. Техническое задание 1. Разработка и утверждение технического задания на создание АС 4. Эскизный проект 1. Разработка предварительных проектных решений по системе и ее 2. Разработка документации на АС и ее части 5. Технический проект 1. Разработка проектных решений по системе и ее частям 2. Разработка документации на АС и ее части комплектующих изделий 4. Разработка заданий на проектирование в смежных частях проекта 6. Рабочая документация 1. Разработка рабочей документации на АС и ее части 2. Разработка и адаптация программ 7. Ввод в действие 1. Подготовка объекта автоматизации 2. Подготовка персонала 3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) 4. Строительно-монтажные работы 5. Пусконаладочные работы 6. Проведение предварительных испытаний 7. Проведение опытной эксплуатации 8. Проведение приемочных испытаний 8. Сопровождение АС.

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

Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

Данный стандарт не вполне подходит для проведения разработок в настоящее время Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207) Был прият Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207: «System and software engineering — Software life cycle processes».

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

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

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

Выделяются пять основных групп:

Разработка.

Эксплуатация.

Сопровождение.

Данные процессы описывают поэтапно все шаги, необходимые для создания продукта. В данной статье подробно рассмотрены процессы Заказа и Разработки.

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

Каждый этап подразумевает, что предыдущий завершен.

Подготовка Собрана информация, объясняющая необходимость разработки или модифицирования продукта;

Составлен и утвержден список системных требований;

Определены глобальные требования к программному обеспечению;

Рассмотрены варианты покупки готового программного продукта, покупки и модернизации, создания "с нуля";

Проанализированы технические требования;

Подготовлен, документально оформлен и выполнен план заказа, который содержит:

планируемую загрузку системы;

тип реализуемого договора;

обязанности организаций, участвующих в договоре;

обеспечение подходов к реализации договора;

анализ возможных рискованных ситуаций, а также методы управления такими ситуациями.

Определены и документально оформлены принятые правила и условия (критерии) реализации договора.

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

описание области применения системы;

указания для участников торгов;

список программных продуктов;

сроки и условия реализации заказа;

правила контроля над субподрядчиками;

технические ограничения (например, по условиям эксплуатации).

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

Определены контрольные пункты договора, при выполнении которых анализируется и проверяется деятельность поставщика.

Требования к заказу представлены организации, выбранной для выполнения работ в процессе заказа.

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

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

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

Корректировка договора Подготовлены и обсуждены условия договора с поставщиком. В договоре должны быть оговорены права собственности, использования, лицензирования и гарантии, связанные с используемыми в заказе готовыми программными продуктами.

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

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

Проконтролирована своевременность взаимообмена всей необходимой информацией и решения всех возникающих проблем.

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

Заказчиком проверена готовность поставщика к проведению приемки и проведению приемочных испытаний поставляемого программного продукта или услуги.

Заказчиком принят от поставщика продукт (при выполнении всех условий приемки).

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

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

Разработка Данный процесс описывает все фазы разработки программного продукта (создание, тестирование и приведение к конечному результату, готовому к сдаче заказчику). Выбор метода разработки зависит от конкретной ситуации. Самый частый метод разработки - V-модель.

Подготовка программного средства.

Анализ требований технического задания.

Проектирование архитектуры программного средства.

Детальное проектирование программного средства.

Конструирование программного средства.

Комплексирование программного средства.

Тестирование.

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

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

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

Анализ области применения разрабатываемой системы с точки зрения определения требований к ней.

Оформление требований к программному средству, которые должны описывать:

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

требования к внешним интерфейсам программного объекта квалификационные требования;

требования безопасности, включая требования, относящиеся к методам эксплуатации и сопровождения, воздействию окружающей среды и травмобезопасности персонала;

требования защиты, включая требования, относящиеся к допустимой точности информации;

эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию "человек-машина", персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и обученности персонала;

требования к определению данных и базе данных;

требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и требования к документации пользователя;

требования к эксплуатации объекта пользователем;

требования к обслуживанию пользователя.

Оценка ТЗ с учтом следующих критериев (при этом результаты оценок должны быть документально оформлены):

учт потребностей заказчика;

соответствие потребностям заказчика;

выполнимость проектирования системной архитектуры;

возможность эксплуатации и сопровождения.

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

Оценка системной архитектуры и требований к объектам архитектуры с учтом следующих критериев (при этом результаты оценок должны быть документально оформлены):

соответствие требованиям к системе;

возможность программных объектов архитектуры выполнять установленные для них требования;

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

Детальное проектирование программного средства Трансформирование требований к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта.

Разработка и оформление общего (эскизного) проекта внешних интерфейсов программного объекта и интерфейсов между компонентами объекта.

Разработка и оформление общего проекта базы данных.

Разработка и оформление предварительной версии документации пользователя.

Разработка и оформление предварительных общих требований к тестированию программного объекта и графику сборки программного продукта.

Оценка архитектуры программного объекта и эскизные проекты интерфейсов и базы данных по следующим критериям:

учт требований к программному объекту;

внешняя согласованность с требованиями к программному внутренняя согласованность между компонентами программного соответствие методов проектирования и используемых возможность технического проектирования;

возможность эксплуатации и сопровождения.

Конструирование программного средства Разработка технического проекта для каждого компонента программного объекта.

Разработка технического проекта внешних интерфейсов программного объекта, интерфейсов между компонентами программного объекта и между программными модулями.

Разработка технического проекта базы данных.

Определение требований к испытаниям и программе испытаний программных модулей.

Оценка технического проекта тестирования по следующим критериям:

учт требований к программному объекту;

внешнее соответствие спроектированной архитектуре;

внутренняя согласованность между компонентами программного объекта и программными модулями;

возможность тестирования;

возможность эксплуатации и сопровождения.

Комплексирование программного средства Разработка и документальное оформление следующие продукты:

каждый программный модуль и базу данных;

процедуры испытаний (тестирования) и данные для тестирования каждого программного модуля и базы данных.

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

Сбор программных модулей и компонентов.

Сбор объектов программной в единую систему вместе с объектами технической конфигурации, ручными операциями и, при необходимости, с другими системами.

Тестирование Тестирование в соответствии квалификационным требованиям к программному объекту.

Оценка проекта, запрограммированного программного объекта, тестирование по следующим критериям:

тестовое покрытие требований к программному объекту;

соответствие ожидаемым результатам;

возможность эксплуатации и сопровождения.

Тестирование системы и оценена по следующим критериям:

тестовое покрытие требований к системе;

соответствие ожидаемым результатам;

возможность эксплуатации и сопровождения.

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

адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации и управляет процессом эксплуатации на организационном уровне в соответствии с процессами усовершенствования и обучения.

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

Вспомогательные процессы жизненного цикла Вспомогательные процессы жизненного цикла делятся на:

процесс документирования:

подготовка процесса;

проектирование и разработка;

процесс управления конфигурацией:

подготовка процесса;

определение конфигурации;

контроль конфигурации;

учт состояний конфигурации;

оценка конфигурации;

управление выпуском и поставка.

процесс обеспечения качества:

подготовка процесса;

обеспечение продукта;

обеспечение процесса;

обеспечение систем качества.

процесс верификации:

подготовка процесса;

процесс аттестации:

подготовка процесса;

процесс совместного анализа:

подготовка процесса;

анализы управления проектом;

технические анализы.

процесс аудита:

подготовка процесса;

аудиторская проверка.

процесс решения проблем:

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

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

совместные анализы, аудиторские проверки, верификация и аттестация.

Организационные процессы жизненного цикла Организационные процессы жизненного цикла делятся на:

процесс управления:

подготовка и определение области управления;

процесс создания инфраструктуры:

создание инфраструктуры;

сопровождение инфраструктуры.

процесс усовершенствования:

усовершенствование процесса.

процесс обучения:

разработка учебных материалов;

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

Таким образом, можно сформулировать, что под термином разработка понимаются вполне конкретные вещи. И начать стоит с выбора модели ЖЦ ИСО.

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ ПО включает в себя:

1. Стадии;

2. Результаты выполнения работ на каждой стадии;

3. Ключевые события — точки завершения работ и принятия решений.

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

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

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

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;

2. Проектирование;

3. Реализация;

4. Тестирование;

5. Внедрение;

6. Эксплуатация и сопровождение.

Преимущества:

Полная и согласованная документация на каждом этапе;

Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы.

Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться»

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

Вариантом этой модели является Поэтапная модель с промежуточным контролем. В ней разработка ИСО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

Итерационная модель Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

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

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

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

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Вовторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ вс же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «вс равно вс можно будет переделать и улучшить позже».

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

Спиральная модель Спиральная модель (spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;

необходимость выполнения ещ одной итерации;

степень полноты и точности понимания требований к системе;

целесообразность прекращения проекта.

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

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

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. Перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10.Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определн следующий общий набор контрольных точек:

1. Concept of Operations (COO) — концепция (использования) системы;

2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Кроме вышеприведенных моделей которые нашли наибольшее применение при проектировании ИСО, стоит упомянуть дополнительно:

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

Применительно к разработке ИСО V-Model — вариация каскадной модели, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования — вверх по правой стороне буквы V. Внутри V проводятся горизонтальные линии, показывающие, как результаты каждой из фаз разработки влияют на развитие системы тестирования на каждой из фаз тестирования. Модель базируется на том, что приемо-сдаточные испытания основываются, прежде всего, на требованиях, системное тестирование — на требованиях и архитектуре, комплексное тестирование — на требованиях, архитектуре и интерфейсах, а компонентное тестирование — на требованиях, архитектуре, интерфейсах и алгоритмах.

V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи:

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

Повышение и гарантии качества: V-Model — стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость.

Уменьшение общей стоимости проекта: Ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты.

Повышение качества коммуникации между участниками проекта:

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

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

В модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта.

В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов.

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

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

Недостатки Модель не предусматривает работу с параллельными событиями.

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

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

В модель не входят действия, направленные на анализ рисков.

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

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

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

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

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

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

На каждом представленном уровне существует прямая связь между действиями с левой и правой стороны V модели. Это сделано преднамеренно.

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

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

В каждой разработке, существует зависимость между действиями на левой и правой ветви Объекта Vee. Это сделано специально. Метод проверки, которые будут использоваться в правой ветви Vee должны быть определены одновременно с разработкой требований на левой ветви, в противном случае могут быть созданы требования, которые не могут быть проверены.

Например, «быть дружественным к пользователю» является подходящим требованием, но его проверить невозможно. Вместо этого, требование, которое утверждает что на экране компьютера может быть «не более пяти строк текста, набранным 14 шрифтом текста» определяет один пользовательский критерий требования «быть дружественным к пользователю» в измеримых величинах. План проверок должны быть согласован и зафиксирован чтобы гарантировать, что требования к проверкам и их методы известны и запланированы на этапе принятия решения по разработке, называемого Проверка Предварительного Проекта (Preliminary Design Review (PDR)). Черновые процедуры проверок основанные на требованиях к проверкам, плане проверок, и предложенном проекте объекта должны быть известны на этапе принятия решения по созданию и программированию, обычно называемом Окончательная Оценка Разработки (Critical Design Review (CDR)). Это снижает вероятность того, что проверка, в том виде котором она определена не может, быть выполнена.

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

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

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

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

Но на этих моделях, все не заканчивается, существует и более редкие, например Модель Хаоса.

После предварительного выбора и анализа можно приступать к дальнейшей разработке.

2. РАЗРАБОТКА И АНАЛИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА

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

В зависимости от объема решаемых задач, используемых технических средств, организации функционирования, информационные системы делятся на ряд групп (классов).

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

Основываясь на степени автоматизации информационных процессов в системе управления ОУ, информационные системы делятся на ручные, автоматические и автоматизированные.

Ручные ИСО характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком.

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

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

(Например, ИСО библиотечного обслуживания). Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму.

По характеру использования выходной информации такие принято делить на управляющие и советующие. Результирующая информация управляющих ИСО непосредственно трансформируется в принимаемые человеком решения. Для этих систем характерны задачи расчетного характера и обработка больших объемов данных. (Например, ИСО планирования обучения или составления расписания, кроме того в случае систем, направленных на коммерческое обучение здесь могут добавляться функции, связанные с бухгалтерской работой). Советующие ИСО вырабатывают информацию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных (например, экспертные системы).

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

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

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

ИСО автоматизированного проектирования (САПР) – предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии.

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

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

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

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

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

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

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

сравнение текущих показателей с прошлыми;

составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;

обеспечение доступа к архивной информации и т.д.

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

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

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС. Традиционные архитектурные решения основаны на использовании выделенных файл-серверов или серверов баз данных. Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "хранилища данных" (DataWarehouse) – интегрированной информационной среды, включающей разнородные информационные ресурсы. Для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода.

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

обеспечивать создание ИСО, отвечающих целям и задачам ОУ, а также предъявляемым требованиям по автоматизации деловых процессов;

гарантировать создание ИСО с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;

поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

обеспечивать преемственность разработки, т.е. использование в инфраструктуры ОУ.

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

Проектирование ИСО охватывает три основные области:

проектирование объектов данных, которые будут реализованы в базе проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файлсервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

требуемой пропускной способности системы;

требуемого времени реакции системы на запрос;

безотказной работы системы;

необходимого уровня безопасности;

простоты эксплуатации и поддержки системы.

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

Выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение.

Начальным этапом процесса создания ИСО является моделирование бизнес-процессов, протекающих в ОУ и реализующих ее цели и задачи.

Модель организации, описанная в терминах бизнес-процессов и бизнесфункций, позволяет сформулировать основные требования к ИСО. Это положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИСО затем преобразуется в систему моделей, описывающих концептуальный проект ИСО. Формируются модели архитектуры ИСО, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

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

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

Конечными продуктами этапа проектирования являются:

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

будет ли это архитектура "файл-сервер" или "клиент-сервер";

будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

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

будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, Этап проектирования завершается разработкой технического проекта ИСО.

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

Этап тестирования обычно оказывается распределенным во времени.

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

обнаружение отказов модуля (жестких сбоев);

соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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

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

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

Стандарты разработки ИСО Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла и именно этому стандарту соответствуют ТЗ на Курсовые работы, дипломные проекты и магистерские диссертации по многим специальностям.

ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle.

Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектноориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование (самая новая среди приведенных методологий) сформировалась в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

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

Стадии и этапы создания ИС, выполняемые организациямиучастниками, прописываются в договорах и технических заданиях на выполнение работ:

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

обследование объекта и обоснование необходимости создания ИС;

формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

изучение объекта автоматизации;

проведение необходимых научно-исследовательских работ;

разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

разработка предварительных проектных решений по системе и ее разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

разработка проектных решений по системе и ее частям;

разработка документации на ИС и ее части;

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

Стадия 6. Рабочая документация.

разработка рабочей документации на ИС и ее части;

разработка и адаптация программ.

Стадия 7. Ввод в действие.

подготовка объекта автоматизации;

подготовка персонала;

комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

строительно-монтажные работы;

пусконаладочные работы;

проведение предварительных испытаний ;

проведение опытной эксплуатации ;

проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

На этапе обследования целесообразно выделить две составляющие:

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

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

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

Ориентировочное содержание технико-экономическое обоснование проекта:

ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;

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

сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;

описание выполняемых системой функций;

возможности развития системы;

информационные объекты системы;

интерфейсы и распределение функций между человеком и системой;

требования к программным и информационным компонентам ПО, требования к СУБД;

что не будет реализовано в рамках проекта.

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

инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;

возможности применения новых методов решения задач.

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

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

При изучении каждой функциональной задачи управления определяются:

наименование задачи; сроки и периодичность ее решения;

степень формализуемости задачи;

источники информации, необходимые для решения задачи;

показатели и их количественные характеристики;

порядок корректировки информации;

действующие алгоритмы расчета показателей и возможные методы действующие средства сбора, передачи и обработки информации;

действующие средства связи;

принятая точность решения задачи;

трудоемкость решения задачи;

действующие формы представления исходных данных и результатов их обработки в виде документов;

потребители результатной информации по задаче.

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

количество документов;

место формирования показателей документа;

взаимосвязь документов при их формировании;

маршрут и длительность движения документа;

место использования и хранения данного документа;

внутренние и внешние информационные связи;

объем документа в знаках.

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

На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MuSCoW. Эта аббревиатура расшифровывается так: Must have – необходимые функции; Should have – желательные функции; Could have – возможные функции; Won't have – отсутствующие функции.

Модели деятельности организации создаются в двух видах:

модель "как есть" ("as-is")- отражает существующие в организации бизнес-процессы;

модель "как должно быть" ("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения ИСО.

На этапе анализа необходимо выполнить и ряд тестирующих мероприятий для решения следующих задач:

получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;

разработки плана работ по обеспечению надежности информационной системы и ее тестирования.

Результаты обследования представляют объективную основу для формирования технического задания на информационную систему.

Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

При разработке технического задания необходимо решить следующие задачи:

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

разработать и обосновать требования, предъявляемые к подсистемам;

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

установить общие требования к разрабатываемой системе;

определить перечень задач создания системы и исполнителей;

определить этапы создания системы и сроки их выполнения;

провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

Типовые требования к составу и содержанию технического задания приведены в Таблице.

Состав и содержание технического задания (ГОСТ 34.602- 89) п\п Назначение и цели вид автоматизируемой деятельности п\п п\п п\п созданию системы работ по подготовке изменения в объекте автоматизации объекта автоматизации к вводу системы в действие Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям. Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.

Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

функции ИСО;

функции подсистем, их цели и ожидаемый эффект от внедрения;

состав комплексов задач и отдельных задач;

концепция информационной базы и ее укрупненная структура;

функции системы управления базой данных;

состав вычислительной системы и других технических средств;

функции и параметры основных программных средств.

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

На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.

Состав и содержание технического проекта приведены в таблице.

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

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

Обобщенная схема организационного бизнес- моделирования.

Миссия согласно [ISO-15704] -это 1. Деятельность, осуществляемая ОУ для того, чтобы выполнить функцию, для которой оно было учреждено, - предоставления заказчикам продукта или услуги.

2. Механизм, с помощью которого ОУ реализует свои цели и задачи.

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

Одним из инструментов которые можно ис пользовать при определении миссии это построение матрицы проекций.

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

Описание бизнес-потенциала, функционала и соответствующих матриц отношений представляет собой статическое описание ОУ. При этом процессы, протекающие в ОУ пока в свернутом виде (как функции), идентифицируются, классифицируются и, закрепляются за исполнителями (будущими хозяевами этих процессов).

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

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

При этом создается система справочников, на основании которых получают пакеты необходимых документов и отчетов.

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

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

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

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

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

Стратегическую модель целеполагания (отвечает на вопросы: зачем ОУ занимается именно этим бизнесом, почему предполагает быть конкурентоспособной, какие цели и стратегии для этого необходимо реализовать);

Организационно-функциональную модель (отвечает на вопрос кточто делает в ОУ и кто за что отвечает);

Функционально-технологическую модель (отвечает на вопрос чтокак реализуется в ОУ);

Процессно-ролевую модель (отвечает на вопрос кто-что-как-кому);

Количественную модель (отвечает на вопрос сколько необходимо ресурсов);

Модель структуры данных (отвечает на вопрос в каком виде описываются регламенты ОУ и объекты внешнего окружения).

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

Стандартная практика построения моделей организационнофункциональной структуры ОУ поддерживает два уровня детализации:

1. агрегированную модель;

2. детализированную модель.

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

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

Детализированная модель - модель организационной структуры, детализация учетных регистров которой производится на более глубоких уровнях, чем в агрегированной модели. Степень детализации в модели обусловлена конкретными потребностями ОУ (создание определенных организационных регламентов).

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

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

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

корпоративное управление;

финансы;

персонал;

материальные ресурсы;

заказы;

обучение;

разработка учебных программ;

планирование;

снабжение/закупки;

качество;

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

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

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

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

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

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

Процесс преобразования информации потребляет определенные ресурсы.

Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

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

Функциональная методика IDEF Методологию IDEF0 можно считать этапом развития графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Последняя его редакция была выпущена в декабре года Национальным Институтом по Стандартам и Технологиям США (NIST).

В настоящий момент в 200 г. IDEF0 бы предложен как стандарт в РФ. В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником. Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

верхняя сторона имеет значение "Управление" (Control);

левая сторона имеет значение "Вход" (Input);

правая сторона имеет значение "Выход" (Output);

нижняя сторона имеет значение "Механизм" (Mechanism).

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

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

Pages: |

| 2 | 3 | 4 |

Главная >> Методички

[ СКАЧАТЬ ОРИГИНАЛ ДОКУМЕНТА .pdf ]

Похожие работы:

«Избирательная комиссия Ямало-Ненецкого автономного округа МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ДЛЯ УЧАСТКОВЫХ ИЗБИРАТЕЛЬНЫХ КОМИССИЙ ПО ОФОРМЛЕНИЮ ПЕРВИЧНЫХ ФИНАНСОВЫХ ДОКУМЕНТОВ ПРИ ПРОВЕДЕНИИ МУНИЦИПАЛЬНЫХ ВЫБОРОВ НА ТЕРРИТОРИИ ЯМАЛО-НЕНЕЦКОГО АВТОНОМНОГО ОКРУГА г. Салехард 2013 год Редакционно-издательский совет: А.Н.Гиберт – председатель И.М.Горелик – заместитель председателя А.Б. Хозяинов – ответственный секретарь члены Редакционно-издательского Совета: И.А. Андреева Т.В. Винокурова Л.Н. Зиненко Е.А....»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования ТОМСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСИТЕТ Б.С. МАСЛОВ ГИДРОЛОГИЯ ТОРФЯНЫХ БОЛОТ Учебное пособие Томск 2008 УДК 632.6: [556.16+556.18] (0.75.8) Печатается по решению ББК 40.6 Учебно-методического совета М 31 Томского государственного педагогического университета М 31 Маслов Б.С. Гидрология торфяных болот: Учебное пособие. Томск: Издательство Томского государственного...»

«СОДЕРЖАНИЕ Введение 3 Общие сведения о направлении подготовки. Организационно- 4 1 правовое обеспечение образовательной деятельности Структура подготовки бакалавров. Сведения по основной 4 2 образовательной программе Содержание подготовки бакалавров 6 3 Учебный план 3.1 8 Учебные программы дисциплин и практик, диагностические средства 3.2 8 Программы и требования к выпускным квалификационным испытаниям 9 3.3 Организация учебного процесса Качество подготовки обучающихся Уровень требований при...»

«М.Э. СЕЙФУЛЛАЕВА МЕЖДУНАРОДНЫЙ МЕНЕДЖМЕНТ Допущено Советом УМО по образованию в области менеджмента в качестве учебного пособия по дисциплине специализации Менеджмент организации Второе издание, стереотипное удК 65.0(075.8) ББК 65.290-2я73 С28 рецензенты: а.П. Панкрухин, проф. кафедры менеджмента Российской академии государственной службы при Президенте РФ, д-р экон. наук, В.а. уразов, заместитель Председателя Московской Конфедерации промышленников и предпринимателей, проф. Сейфуллаева М.Э. С28...»

«МЕЖДУНАРОДНЫЙ ИНСТИТУТ ЭКОНОМИКИ И ПРАВА ОСНОВЫ АВТОМАТИЗАЦИИ БУХГАЛТЕРСКОГО УЧЕТА ПРОБЛЕМНО-ТЕМАТИЧЕСКИЙ КОМПЛЕКС Рекомендовано Министерством образования и науки Российской Федерации в качестве учебного пособия для студентов высших учебных заведений МОСКВА 2006 ББК 65.052.21я73 К59 УДК 657:004(075.8) Рецензенты: д-р экон. наук, проф. В.А. Лукинов; кафедра аудита и контроллинга Московского государственного университета дизайна и технологии Научный руководитель проекта и автор образовательной...»

«Департамент образования города Москвы Западное окружное управление образования Государственное бюджетное образовательное учреждение города Москвы Средняя общеобразовательная школа с углубленным изучением отдельных предметов № 1973 Средняя общеобразовательная школа № 875 Комаров Алексей Анатольевич Учебное занятие по направлению Технология. Обслуживающий труд раздела Основы конструирования и моделирования швейных изделий на тему: Разработка эскизов одежды в 7-ом классе Материалы открытого...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Факультет естественных наук Кафедра химии окружающей среды П. А. Попов АДАПТАЦИЯ ГИДРОБИОНТОВ К УСЛОВИЯМ ОБИТАНИЯ В ВОДОЕМАХ СУБАРКТИКИ – НА ПРИМЕРЕ ЭКОЛОГИИ РЫБ В ВОДОЕМАХ СУБАРКТИКИ ЗАПАДНОЙ СИБИРИ Учебное пособие Новосибирск 2012 АННОТАЦИЯ В учебном пособии приведена информация об условиях обитания, структуре ихтиоценозов и особенностях экологии пресноводных рыб в водоемах субарктической зоны Западной Сибири –...»

«Кафедра КИС ХТ Учебная работа Специальность 240802 – Основные процессы химических производств и химическая кибернетика Специализация – Гибкие автоматизированные производственные химико-технологические системы Учебные и методические пособия (библиографический список) Сборники, учебные пособия 1. Перов В.Л., Егоров А.Ф., Хабарин А.Ю. Управление химико-технологическими системами. М., Моск. Хим.-технол. Ин-т им.Д.И.Менделеева, 1981.-52 c. 2. Перов В.Л., Егоров А.Ф., Хабарин А.Ю. Автоматизированное...»

«ИНФОРМАЦИЯ О МЕТОДИЧЕСКИХ И ИНЫХ ДОКУМЕНТАХ, РАЗРАБОТАННЫХ ДЛЯ ОБЕСПЕЧЕНИЯ ОБРАЗОВАТЕЛЬНОГО ПРОЦЕССА Наименование рукописей Авторы (составители) №№ 2008 Метрология, техническое регулирование (стандартизация и сертификация). Л.В. Рогачев, А.С. Яржемский 1 Учебное пособие Материаловедение. Учебное пособие для практических занятий Цориев С.О., Басиев К.Д. 2 Начертательная геометрия. Рабочая тетрадь для всех специальностей Македонова Л.Н. 3 Методы контроля. Курс лекций для спец. МЦ, ТЭА Хоменко...»

«Социально-культурная деятельность в образовательном пространстве: межвузовский сборник научных и учебно-методических статеи, 2007, 5815401471, 9785815401471, Кемеровский ун-т культуры и искусств, 2007 Опубликовано: 28th June 2013 Социально-культурная деятельность в образовательном пространстве: межвузовский сборник научных и учебно-методических статеи СКАЧАТЬ http://bit.ly/1cBNP0p Проблемы современной российской интеллигенции опыт социологического анализа, Владимир Беленький, 2005, History, 187...»

«Учебно-методический центр Инженерно-экономического факультета В.Т. Водянников, Р.Л. Геворков Практикум по экономике сельского хозяйства Учебное пособие Москва 2010 УДК 631.3 ББК 65.9(2) 32:312 В 629 Рецензенты: Сорокин В.С. – кандидат экономических наук, доцент Московской сельскохозяйственной академии им. К.А. Тимирязева Худякова Е.В. – доктор экономических наук, профессор Московского государственного агроинженерного университета им. В.П. Горячкина Водянников В.Т., Геворков Р.Л. В 629 Практикум...»

«История политических и правовых учений: Учебник для вузов, 2004, Владик Сумбатович Нерсесянц, 5891237482, 9785891237483, Норма, 2004 Опубликовано: 5th April 2012 История политических и правовых учений: Учебник для вузов СКАЧАТЬ http://bit.ly/1cAkKT9 Взаимодействие культур и литератур Востока и Запада, Volume 2, Павел Александрович Гринцер, Ирина Дмитриевна Никифорова, 1992, Oriental literature,.. Second Treatise of Government, John Locke, 1952, Liberty, 139 страниц.. История политических и...»

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

«Владимир Ровдо сравнительная политология Учебное пособие в трех частях Часть I теория сравнительной политологии Вильнюс Европейский гуманитарный университет 2007 УДК 32.001(075.8) ББК 66.0я7 р58 Реценз ен ты: Matonite I., PHD in Political Sciense, Associate professor of Kaunas Teсhnical University and Head of Sociology and Political Sciense Department of EHU in Vilnius. Круглашов А. Н., доктор политических наук, профессор, директор магистерской программы “Европейские исследования” ЕГУ в...»

«Банк электронных образовательных ресурсов МБОУ СОШ №5 Начальное общее образование Русский язык РС СD Начальная школа. Русский язык. Тренажер к учебнику Т.Г. Рамзаевой, 1 класс РС СD Начальная школа. Русский язык. Тренажер к учебнику Т.Г. Рамзаевой, 2 класс РС СD Начальная школа. Русский язык. Тренажер к учебнику Т.Г. Рамзаевой, 3 класс РС СD Начальная школа. Русский язык. Тренажер к учебнику Т.Г. Рамзаевой, 4 класс СD-ROM Русский язык. Начальная школа. Семейный наставник....»

«ГОУ ВПО Российско-Армянский (Славянский) университет ГОУ ВПО РОССИЙСКО-АРМЯНСКИЙ (СЛАВЯНСКИЙ) УНИВЕРСИТЕТ Со ст а в л ен в со о т в ет ст в и и с У Т В Е Р Ж Д АЮ : государственными требованиями к м и н и м у м у с о д е р ж а н и я и у ро в н ю Р е к т о р А. Р. Д а рб и н я н подготовки в ып у с к н и к о в по у к а за н н ы м н а п ра в л е н и я м и “_”_ 20 г. П о л о ж ен и е м О б У М К Д Р АУ. Институт: “Экономики и бизнеса” Кафедра: “Управление” Автор: к.э.н., Бабаян Карине...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ УПРАВЛЕНИЕ И ЭКОНОМИКА ФАРМАЦИИ Раздел 2 Организация работы товаропроводящей системы фармацевтического рынка Учебно-методическое пособие для самостоятельной работы Составители: Е.Е. Чупандина И.В. Ручкин Издательско-полиграфический центр Воронежского государственного университета 2011 Утверждено научно-методическим советом фармацевтического...»

«Математические модели принятия решений в экономике Учебное пособие В.В. Розен Л.В. Бессонов 26 сентября 2008 г. Содержание Предисловие 1 1 Вводная лекция 6 Тест для самоконтроля к лекции 1................. 14 I Принятие решений в условиях определённости 16 2 Экстремум функций одной переменной 17 Тест для самоконтроля к лекции 2................. 27 3 Оптимизация при наличии ограничений 31 Тест для самоконтроля к лекции 3................. 43 4...»

«Федеральное агентство по образованию Государственное образовательное учреждение высшего профессионального образования САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ НИЗКОТЕМПЕРАТУРНЫХ И ПИЩЕВЫХ ТЕХНОЛОГИЙ Кафедра экономики и предпринимательской деятельности ПРАВОВЕДЕНИЕ Методические указания и контрольные задания для студентов специальности 060800 и направления 521500 факультета заочного обучения и экстерната Санкт-Петербург 2004 3 УДК 340.1 Правоведение: Метод. указания и контрольные задания...»

«МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ПОДГОТОВКЕ КУРСОВЫХ И ВЫПУСКНЫХ КВАЛИФИКАЦИОННЫХ РАБОТ Для студентов факультета экономики и управления Москва Издательство МИЭП 2012 Авторы-составители: канд. экон. наук, доц. Л.С. Александрова, канд. техн. наук, доц. Е.П. Жарковская, д-р филос. наук, доц. Э.А. Понуждаев, канд. экон. наук, доц. Н.С. Ульянова Ответственный за выпуск проректор по учебной и научно-методической работе, д-р истор. наук, доц. Т.В. Карпенкова Методические рекомендации по подготовке...»

наверх

<< ГЛАВНАЯ | КОНТАКТЫ

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ

ОГЛАВЛЕНИЕ

1. ПОДГОТОВИТЕЛЬНЫЙ ЭТАП В РАЗРАБОТКЕ

ИНФОРМАЦИОННЫХ СИСТЕМА В ОБРАЗОВАНИИ

2. РАЗРАБОТКА И АНАЛИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА (Авторефераты, диссертации, методички, учебные программы, монографии)

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ

ОГЛАВЛЕНИЕ

1. ПОДГОТОВИТЕЛЬНЫЙ ЭТАП В РАЗРАБОТКЕ

ИНФОРМАЦИОННЫХ СИСТЕМА В ОБРАЗОВАНИИ

2. РАЗРАБОТКА И АНАЛИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)