WWW.METODICHKA.X-PDF.RU
БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Методические указания, пособия
 

Pages:   || 2 | 3 | 4 | 5 |   ...   | 6 |

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

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

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

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

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

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

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

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

образовании

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

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

Штенников Д.Г. Приемы работы с приложениями Picasa и Pixlr. Учебное



пособие. – СПб: СПбГУ ИТМО, 2012. – 40 с.

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

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

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

ОГЛАВЛЕНИЕ

1. Подготовительный этап в разработке информационных система в образовании (ИСО)

Жизненный цикл информационных систем

Стандарт ГОСТ 34.601-90

Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)

Модели жизненного цикла ПО

Водопадная (каскадная, последовательная) модель

Итерационная модель

Спиральная модель

V-Model

Dual Vee Model

Разработка и анализ технического задания на ИСО

2.

Основные понятия технологии проектирования информационных систем в образовании (ИСО)

Методология разработки ИСО

Стандарты разработки ИСО

Разработка ИСО

Анализ и моделирование функциональной области внедрения ИСО 52 Полная бизнес-модель ОУ

Инструментальные средства организационного моделирования....... 5 Спецификация функциональных требований к ИС

Процессные потоковые модели

Функционально-ориентированные и объектно-ориентированные методологии описания предметной области

Функциональная методика IDEF0

Функциональная методика потоков данных

Объектно-ориентированная методика

Синтетическая методика

Моделирование бизнес-процессов средствами ERwin

Инструментальная среда ERWin

Построение модели IDEF0

Цель моделирования

Семантические правила блоков и стрелок

Синтаксические правила

Блоки

Стрелки

Стрелки как ограничения.

Параллельное функционирование.

Ветвление и слияние сегментов стрелок

Отношения между блоками диаграммы и другими диаграммами (окружающей средой).

Граничные стрелки.

Стрелки, помещенные в «туннель».

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

Добавление или удаление элементов на диаграмме

ICOM-коды

Туннелирование стрелок

Диаграммы дерева узлов и FEO

Слияние и расщепление моделей

Слияние и расщепление модели

Диаграммы IDEF3

Диаграммы потоков данных

Генерация кода в Visual Basic

Создание отчетов

Генерация словарей

Моделирование UML

Проектирование архитектуры ИСО

3.

IBM Rational Rose

Интерфейс программы IBM Rational Rose

Разработка диаграммы вариантов использования и редактирование свойств ее элементов

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

Добавление и редактирование варианта использования

Добавление ассоциации

Добавление отношения зависимости и редактирование его свойств

Построение сценария диаграммы вариантов использования............ 141 Детальное проектирование ИСО

4.

Разработка диаграммы классов и редактирование их свойств......... 142 Особенности разработки диаграмм классов в среде IBM Rational Rose

Добавление класса на диаграмму классов и редактирование его свойств

Стереотипы классов и их графическое представление





Добавление атрибутов и операций на диаграмму классов. Добавление и редактирование атрибутов классов

Добавление и редактирование операций классов

Добавление отношений на диаграмму классов и редактирование их свойств

Добавление ассоциации на диаграмму классов и редактирование ее свойств

Добавление отношений агрегации и композиции на диаграмму классов и редактирование их свойств

Добавление отношения обобщения на диаграмму классов и редактирование ее свойств

Дальнейшее построение диаграммы классов модели ИСО........... 165 Разработка диаграммы кооперации и редактирование свойств ее элементов

Особенности разработки диаграмм кооперации в среде IBM Rational Rose

Добавление объекта на диаграмму кооперации и редактирование его свойств

Добавление связи и редактирование ее свойств

Добавление сообщения и редактирование его свойств.................. 171 Дальнейшее построение диаграммы кооперации для модели ИСО

Конструирование программного обеспечение ИСО

5.

Разработка диаграммы последовательности и редактирование свойств ее элементов

Особенности разработки диаграммы последовательности в среде IBM Rational Rose

Добавление объекта на диаграмму последовательности и редактирование его свойств

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

Дальнейшее построение диаграммы последовательности модели ИСО

Разработка диаграммы состояний и редактирование свойств ее элементов

Особенности разработки диаграммы состояний в среде IBM Rational Rose

Добавление состояния на диаграмму состояний и редактирование его свойств

Добавление перехода и редактирование его свойств

Дальнейшее построение диаграммы состояний модели ИСО....... 192 Разработка диаграммы деятельности и редактирование свойств ее элементов

Особенности разработки диаграммы деятельности в среде IBM Rational Rose

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

Добавление перехода и редактирование его свойств

Дальнейшее построение диаграммы деятельности модели ИСО.. 199 Разработка диаграммы деятельности для моделирования бизнеспроцессов

Особенности проектов по моделированию бизнес-процессов в среде IBM Rational Rose

Добавление дорожек на диаграмму деятельности

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

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

Разработка диаграммы компонентов и редактирование свойств ее элементов

Особенности разработки диаграммы компонентов в среде IBM Rational Rose

Добавление компонента на диаграмму компонентов и редактирование его свойств

Добавление отношения зависимости и редактирование его свойств

Дальнейшее построение диаграммы компонентов модели ИСО.. 215 Разработка диаграммы развертывания и редактирование свойств ее элементов

Особенности разработки диаграммы развертывания в среде IBM Rational Rose

Добавление узла на диаграмму развертывания и редактирование его свойств

Добавление соединения и редактирование его свойств................. 220 Дальнейшее построение диаграммы развертывания модели ИСО 221 Комплексирование ИСО

6.

Особенности генерации программного кода в среде IBM Rational Rose

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

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

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

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

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

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

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

Тест-планы

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

8.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ 34.601-90

ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207- 99)

Стандарт ГОСТ 34.601-90 Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

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

1. Обследование объекта и обоснование необходимости создания АС

2. Формирование требований пользователя к АС

3. Оформление отчета о выполнении работ и заявки на разработку АС

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

1. Изучение объекта

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

3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

4. Оформление отчета о проделанной работе

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

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

4. Эскизный проект

1. Разработка предварительных проектных решений по системе и ее частям

2. Разработка документации на АС и ее части

5. Технический проект

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

2. Разработка документации на АС и ее части

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

4. Разработка заданий на проектирование в смежных частях проекта

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

1. Разработка рабочей документации на АС и ее части

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

7. Ввод в действие

1. Подготовка объекта автоматизации

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

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

4. Строительно-монтажные работы

5. Пусконаладочные работы

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

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

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

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

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

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

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

Данный стандарт не вполне подходит для проведения разработок в настоящее время Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207) Был прият Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «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-Model

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

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

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

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

Повышение и гарантии качества: V-Model — стандартизованная

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dual Vee Model Двойная 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. РАЗРАБОТКА И АНАЛИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА ИСО

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



Pages:   || 2 | 3 | 4 | 5 |   ...   | 6 |
 
Похожие работы:

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

«1. Общие положения Программа подготовки специалистов среднего звена (ППССЗ) по специальности СПО 13.02.11 Техническая эксплуатация и обслуживание электрического и электромеханического оборудования (по отраслям) реализуется Томским политехническим техникумом по программе базовой подготовки на базе среднего/основного общего образования. ППССЗ представляет собой систему документов, разработанную и утвержденную техникумом с учетом требований регионального рынка труда на основе Федерального...»

«ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ САНКТ-ПЕТЕРБУРГСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ ИНСТИТУТ ХОЛОДА И БИОТЕХНОЛОГИЙ А.Г. Буткарев, Б.Б. Земсков ИНЖЕНЕРНАЯ И КОМПЬЮТЕРНАЯ ГРАФИКА Учебно-методическое пособие Санкт-Петербург УДК 681.3.06 Буткарев А.Г., Земсков Б.Б. Инженерная и компьютерная графика. Учеб.метод. пособие. – СПб.: Университет ИТМО; ИХиБТ, 2015. – 109 с. Даны общие сведения о...»

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

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

«ЛИСТ СОГЛАСОВАНИЯ от 08.06.2015 Рег. номер: 1848-1 (05.06.2015) Дисциплина: Нейронные механизмы психики Учебный план: 37.03.01 Психология/4 года ОДО Вид УМК: Электронное издание Инициатор: Плотникова Марина Васильевна Автор: Плотникова Марина Васильевна Кафедра: Кафедра медико-биологических дисциплин и безопасности жизнедеяте УМК: Институт психологии и педагогики Дата заседания 17.02.2015 УМК: Протокол заседания №6 УМК: Дата Дата Результат Согласующие ФИО Комментарии получения согласования...»

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

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

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

«РОСЖЕЛДОР Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Ростовский государственный университет путей сообщения» (ФГБОУ ВПО РГУПС) Волгоградский техникум железнодорожного транспорта (ВТЖТ – филиал РГУПС) Л.В.Селянина Дисциплина История Учебное пособие для студентов 2 –го курса специальностей 13.02.07 Электроснабжение (по отраслям), 23.02.06 Техническая эксплуатация подвижного состава железных дорог, 27.02.03 Автоматика и телемеханика на...»

«ЛИСТ СОГЛАСОВАНИЯ от 26.05.2015 Рег. номер: 107-1 (17.03.2015) Дисциплина: Психофизиологические механизмы адаптации человека Учебный план: 06.03.01 Биология/4 года ОДО Вид УМК: Электронное издание Инициатор: Кыров Дмитрий Николаевич Автор: Кыров Дмитрий Николаевич Кафедра: Кафедра анатомии и физиологии человека и животных УМК: Институт биологии Дата заседания 24.02.2015 УМК: Протокол заседания УМК: Дата Дата Результат Согласующие ФИО Комментарии получения согласования согласования Зав. кафедрой...»

«Стратегия устойчивого развития Бахчисарайского района на период до 2017 года Содержание 1. Введение............................................................... 4 2. Краткая характеристика района............................................. 4 3. Анализ ситуации в районе................................................. 5 4. Миссия и видение...»

«РОСЖЕЛДОР Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Ростовский государственный университет путей сообщения» (ФГБОУ ВПО РГУПС) Волгоградский техникум железнодорожного транспорта (ВТЖТ – филиал РГУПС) Л.В.Селянина Дисциплина История Учебное пособие для студентов специальностей 13.02.07 Электроснабжение (по отраслям), 23.02.06 Техническая эксплуатация подвижного состава железных дорог, 27.02.03 Автоматика и телемеханика на транспорте...»

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

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

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ УНИВЕРСИТЕТ ИТМО Н.П. Деменчук ПРИКЛАДНАЯ МЕХАНИКА Сопротивление материалов Учебно-методическое пособие Санкт-Петербург УДК 539.3/8(075.8) Деменчук Н.П. Прикладная механика. Сопротивление материалов: Учеб.-метод. пособие. СПб.: Университет ИТМО; ИХиБТ, 2015. 39 с. Приведены рабочая программа, методические указания и контрольные задания по курсу «Прикладная механика», ч. I – «Сопротивление материалов». Предназначено для направлений...»

«СОДЕРЖАНИЕ Введение 1. Общие положения 1.1. Цели и задачи практики 1.2. Места практики и распределение времени 1.3. Методические указания по организации и проведению практики 1.4. Требования к отчету по практике 2. Содержание практики для студентов гражданско-правовой специализации 2.1. Содержание производственной практики в представительных и исполнительных органах государственной власти субъектов РФ и органах местного самоуправления. 2.2. Содержание производственной практики в юридическом...»

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

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

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







 
2016 www.metodichka.x-pdf.ru - «Бесплатная электронная библиотека - Методички, методические указания, пособия»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.