WWW.PROGRAMMA.X-PDF.RU
БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Учебные и рабочие программы
 

Pages:   || 2 |

«Д.А. Демченко, І. В. Стовпченко МЕТОДИЧНІ ВКАЗІВКИ ТА ЗАВДАННЯ до виконання контрольних робіт з дисципліни «Технологія програмування та створення програмних продуктів» для студентів ...»

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

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНА МЕТАЛУРГІЙНА АКАДЕМІЯ УКРАЇНИ

Д.А. Демченко, І. В. Стовпченко

МЕТОДИЧНІ ВКАЗІВКИ ТА ЗАВДАННЯ

до виконання контрольних робіт з дисципліни

«Технологія програмування та створення програмних

продуктів»

для студентів напряму 0804 – “Комп’ютерні науки”

Дніпропетровськ НМетАУ, 2013

Содержание

Содержание

Введение

1. Указания к выполнению контрольной работы №1. Формирование рабочих групп и утверждение тем

2. Указания к выполнению контрольной работы №2. Управление проектом

3. Указания к выполнению контрольной работы №3. Внешнее описание и техническое задание

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

5. Указания к выполнению контрольной работы №5. Конструирование программного средства

6. Указания к выполнению контрольной работы №6. Разработка руководства по применению

7. Указания к выполнению контрольной работы №7. Кодирование, тестирование и отладка..... 23

8. Указания к выполнению контрольной работы №8. Аттестация программного средства......... 26 Приложение А. Пример резюме

Приложение Б. Темы для разработок

Приложение В. Пример технического задания

Приложение Г. Примеры диаграмм UML

Приложение Д. Пример руководства оператора

Приложение Е. Пример журнала отслеживания дефектов WEB-сайта

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

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

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

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

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

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

1. Указания к выполнению контрольной работы №1.

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

1.1.Формирование рабочих групп.

Формирование рабочих групп начинается с подготовки каждым студентом резюме на соискание должности (роли) в рабочей группе. Резюме оформляется на листе А4 рукописным тестом и содержит следующие разделы:

Заголовок формата «Резюме на соискание должности _____». При готовности занимать одну из нескольких должностей все они указываются.

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

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

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

1.2.Утверждение темы разработки Минимальным достаточным набором требований к темам разработок являются следующие:

программное средство должно являться системой автоматизации некоторого реального или правдоподобного бизнес-процесса или части бизнес-процесса, при этом степень правдоподобности оценивает преподаватель;

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

разработка должна быть ориентирована на пользователя-человека, т.е.

программное средство должно иметь графический пользовательский интерфейс;

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

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

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

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

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

2. Указания к выполнению контрольной работы №2. Управление проектом

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

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

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

Структурно деятельность по управлению проектом состоит из следующих процессов:

- управление координацией (Project Integration Management).

- управление целями (Project Scope Management).

- управление временем (Project Time Management).

- управление стоимостью (Project Cost Management).

- управление качеством (Project Quality Management).

- управление человеческими ресурсами (Project Human Resource Management).

- управление коммуникациями (Project Communication Management).

- управление рисками (Project Risk Management).

- управление поставками (Project Procurement Management).

Управление проектом состоит из нескольких фаз: формулирование, планирование, осуществление, завершение.

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

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

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

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

2.2.Порядок работ Порядок выполнения работы следующий

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

a. «задача В может быть начата не ранее завершения задачи А»

b. «Задачи А и В должны начаться одновременно»

c. «Задачи А и В должны закончиться одновременно»

Особые ограничения для отдельных задач:

d. «Задача А может быть начата не ранее чем»

e. «Задача А должна быть закончена не позднее чем»

2. Для каждой задачи необходимо оценить ее трудоемкость в часах.

3. Для каждой задачи нужно указать ее приоритет по отношению к прочим задачам в проекте.

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

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

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

2.3.Пример описания проекта Проект: «Создание автоматизированной системы отслеживания интереса клиентов компании на основании статистики посещений корпоративного сайта»

Подзадача 1: составить техническое задание Подзадача 1.1: Составить внешнее описание (8 ч) Подзадача 1.2: Сформулировать требования к системе (выполнение может быть начато не ранее заверения 1.1) (4 ч) Подзадача 1.3: Сформулировать требования качества (выполнение может быть начато не ранее момента завершения 1.2) (2 ч) Подзадача 1.4: Сформулировать функциональные требования (выполнение может быть начато не ранее момента завершения 1.3) (8 ч) Подзадача 1.4: Составить и утвердить документ технического задания (выполнение может быть закончено не ранее завершения 1.4) (6 ч) Подзадача 2: Разработать архитектуру решения Подзадача 2.1: Установить способ представления и состав данных по статистике посещений (выполнение может быть начато не ранее завершения 1.4) (1 ч) Подзадача 2.2: Разработать реляционную структуру для хранения и обработки протоколов (выполнение может быть начато не ранее завершения 2.1) (16 ч) Подзадача 2.3: Описать способ транспортировки, преобразования и загрузки данных (выполнение может быть начато не ранее завершения 2.1) (4 ч) Подзадача 2.4: Сформулировать логику построения отчетов (выполнение может быть начато не ранее завершения 2.3) (40 ч) Подзадача 3: Реализовать приложение Подзадача 3.1: Реализовать транспортировку протоколов (Может быть начато не ранее завершения 2.3) (8 ч) Подзадача 3.2: Создать реляционную базу данных( 16 ч ) Подзадача 3.3: Реализовать код предварительной обработки и очистки данных (2 ч) Подзадача 3.4: Реализовать код загрузки протоколов (1 ч) Подзадача 3.5: Реализовать код и дизайн отчетов ( 20 ч ) Подзадача 3.5: Создать документацию по применению (16 ч) Подзадача 4: Провести аттестацию (может быть начато не ранее завершения 2) Подзадача 4.1: Тестирование на площадке исполнителя (1 день) Подзадача 5: Развертывание Подзадача 5.1: Развертывание сервера баз данных (1 ч) Подзадача 5.2: Развертывание сервера отчетов (1 ч) Подзадача 5.3: Развертывание сервера интеграции (1 ч) Подзадача 5.4: Развертывание сервера интеграционных пакетов Подзадача 5.5: Развертывание сервера пакетов отчетов Подзадача 5.6: Приемо-сдаточные испытания Подзадача 5.7: Обучение персонала заказчика На основании этой структуры работ строится так называемая диаграмма Гантта (см рисунок), которая отражает состав и порядок работ.

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

По полученной диаграмме необходимо определить критический путь, т.е.

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

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

–  –  –

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

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

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

При этом допустимо оформление части материалов в рукописном виде.

Функциональная спецификация и спецификация качества входят в техническое задание. Оформление технического задания должно быть выполнено в соответствии со стандартом ГОСТ 19.201-78, принятым в 1980г.

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

3.1.Общие положения Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

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

3.1.1. Техническое задание должно содержать следующие разделы:

введение;

основания для разработки;

назначение разработки;

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

требования к программной документации;

технико-экономические показатели;

стадии и этапы разработки;

порядок контроля и приемки;

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

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

3.2.Содержание разделов 3.2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие 3.2.2. В разделе «Основания для разработки» должны быть указаны:

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

организация, утвердившая этот документ, и дата его утверждения;

наименование и (или) условное обозначение темы разработки.

3.2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

3.2.4. Раздел «Требования к программе или программному изделию»

должен содержать следующие подразделы:

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

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

условия эксплуатации;

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

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

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

требования к транспортированию и хранению;

специальные требования.

3.2.5. В подразделе «Требования к функциональным характеристикам»

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

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

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

3.2.7. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

3.2.9. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

3.2.10. В подразделе «Требования к транспортированию и хранению»

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

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

3.2.12.В разделе «Технико-экономические показатели» должны быть указаны:

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

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

3.2.14. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

3.2.15.В приложениях к техническому заданию, при необходимости, приводят:

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

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

другие источники разработки.

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

Электронная форма документа должна быть подготовлена в любом профессиональном редакторе или настольной издательской системе типа MS Word, OpenOffice Writer, IBM Lotus Symphony, LaTeX, Adobe Pagemaker, Adobe InDesign и оформляется с использованием стилей элементов документа. Число стилей, используемых в документе, во многом определяется спецификой задачи, но обычно не превышает семи. Все стили должны иметь названия, отражающие их сущность. Это требование является обязательным.

Внешнее описание и техническое задание распечатываются на листах формата А4 и являются фактическим результатом лабораторной работы.

4. Указания к выполнению контрольной работы №4. Разработка пользовательского интерфейса Проект предполагает создание приложения с пользовательским графическим интерфейсом, и целью данной работы является создание его макета в виде набора экранных форм. В качестве исходной постановки задачи необходимо использовать техническое задание. Инструментарий, допустимый к использованию при выполнении работы: Microsoft Expression Blend, Microsoft Visio, Adobe InDesign.

4.1.Методика разработки интерфейса 4.1.1. Исходя из текста технического задания, нужно определить, будет ли интерфейс относиться к классу SDI (Single Document Interface) или MDI (Multiple Document Interface). Выбор требуется обосновать.

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

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

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

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

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

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

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

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

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

имя, фамилию, отчество;

пол;

год рождения;

серию и номер паспорта;

уникальный налоговый идентификационный номер;

семейное положение;

форма обращения (m-r, m-s);

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

(количество телефонов не ограничено);

несколько адресов электронной почты (число адресов не ограничено);

несколько номеров ICQ (произвольное количество);

несколько идентификаторов Skype (произвольное количество).

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

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

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

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

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

Результатом лабораторной работы должен стать набор дизайнов оконных форм, которые будут реализованы в системе.

Литература

1. С. Жарков. Shareware: профессиональная разработка и продвижение программ

2. Т. Манделл. Разработка пользовательского интерфейса: пер. с англ. – М.

ДМК Пресс, 2001. – 416с.

5. Указания к выполнению контрольной работы №5.

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

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

В нотации для описания конструкции программного средства нужно использовать графический синтаксис UML, а в качестве инструмента для построения диаграмм - Altova UModel, IBM Rational Rose, IBM Rational Software Architect, Visual Paradigm VP Suite, Sybase Power Designer, Microsoft Visio (нежелательно), Sparx Systems Enterprise Architect.

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

5.1.Диаграмма вариантов использования Диаграмма вариантов использования (use case diagram) составляется для всего программного средства целиком и формируется в основном из первого раздела технического задания, а именно требований к функциональным характеристикам. На ней должны присутствовать все определенные в системе роли и все внешние функции, описанные в работе №3. Пример диаграммы использования системы, представляющей собой корпоративную адресую книгу, приведен на рисунке а) приложения Г.

5.2.Диаграмма классов Диаграмма классов (class diagram) строится для всей объектной модели программного средства, но при этом стандартные классы и классы внешних библиотек в виде описаний на диаграммах отражать не нужно. Допустимо использов7ать их как типы свойств, параметров методов и возвращаемых методами значений в собственных классах. Пример диаграммы классов адресной книги приведен на рисунке б) в приложении Г.

5.3.Диаграмма деятельностей Диаграмма деятельностей (activity diagram) строится для одного наиболее сложного с точки зрения логики событий варианта использования. При этом крайне желательно, чтобы описываемый поток событий имел параллельные участки. Пример такой диаграммы на рисунке в) приложения Г.

5.4.Диаграмма последовательностей Диаграмма последовательностей (sequence diagram) строится для любого одного варианта использования, желательно отличного от того, который был рассмотрен в пункте п. 5.3. Для всех объектов необходимо указать классы, присутствующие в модели, описанной в п. 5.2. Пример такой диаграммы представлен на рисунке в) приложения Г.

5.5.Диаграмма состояний Диаграмма состояний (statechart diagram) строится для одного класса объектной модели, при этом класс нужно выбирать таким образом, чтобы были явно видны несколько различных состояний. Состояния можно хорошо идентифицировать по смене поведения объекта класса. Пример диаграммы состояний см. на рисунке г) приложения Г.

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

на рисунке д) приложения Г.

Литература

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006. — с 177-209.

2. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон Язык UML. Руководство пользователя = The Unified Modeling Language user guide. — 2. — М., СПб.: «ДМК Пресс», «Питер», 2004. — 432 с. — ISBN 5-94074-260-2

3. Интернет-ресурс http://www.uml.org/.

4. Интернет-университет информационных технологий http://www.intuit.ru/

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

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

Руководство составляется согласно государственному стандарту 19.5050Руководство оператора. Требования к содержанию и оформлению», текст которого приведен далее.

6.1.ОБЩИЕ ПОЛОЖЕНИЯ 6.1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78. Составление информационной части (аннотации и содержания) является обязательным.

6.1.2. Руководство оператора должно содержать следующие разделы:

назначение программы;

условия выполнения программы;

выполнение программы;

сообщения оператору.

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

6.2.СОДЕРЖАНИЕ РАЗДЕЛОВ 6.2.1. В разделе «Назначение программы» должны быть указаны сведения о назначении программы и информация, достаточная для понимания функций программы и ее эксплуатации.

6.2.2. В разделе «Условия выполнения программы» должны быть указаны условия, необходимые для выполнения программы (минимальный и (или) максимальный состав аппаратурных и программных средств и т.п.).

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

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

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

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

Пример руководства по применению находится в приложении Д.

7. Указания к выполнению контрольной работы №7.

Кодирование, тестирование и отладка Целью данной работы является создание программного кода системы.

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

7.1.Журнал отслеживания дефектов.

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

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

7.1.2. Описание проявления дефекта и способа его воспроизведения, возможно, со снимками экрана (обязательное поле).

7.1.3. «Соответствует дефекту №» - указание на родственный дефект, проявлением или частным случаем которого является (обязательное поле). Если поле не заполнено, дефект считается уникальным.

7.1.4. Оценка важности (приоритета) в виде P1(высокий приоритет) — P5 (низкий приоритет) (обязательное поле). Эта оценка дается экспертным образом исходя из следующих соображений:

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

7.1.5. Ответственный за исправление (обязательное поле). Это поле указывает, кто из разработчиков будет заниматься исправлением дефекта.

7.1.6. Ожидаемое время исправления (EFT) (обязательное поле). Это поле выражает ожидаемые трудозатраты исполнителя на исправление дефекта.

7.1.7. Состояние дефекта (обязательное поле): «зарегистрировано», «подтверждено», «не воспроизводится», «назначено», «отклонено исполнителем», «в работе», «исправлено», «не требует исправления», «исправление невозможно», «исправление заявлено», «исправление подтверждено».

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

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

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

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

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

При этом не должно быть ни одной записи «исправление невозможно» с приоритетом выше P3.

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

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

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

Литература

1. Канер, Фолк, Нгуен, Тестирование программного обеспечения. (Перевод с английского) (2000, издательство ДиаСофт, ISBN 966-7393-87-9)

2. Бахтизин В. В., Глухова Л. А. Стандартизация и сертификация программного обеспечения: Учеб. пособие/ В. В. Бахтизин, Л. А. Глухова — Мн.: БГУИР, 2006. — 200с.:ил.

3. Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование:

Издательский дом «Вильямс» /Серия института качества программного обеспечения — 374с.:ил.

4. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения.

М.:БИНОМ, 2008, 368c. ISBN 978-5-94774-825-3

5. Интернет-ресурс http://www.intuit.ru/department/se/testing/

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

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

название примитива;

способ оценивания;

детальная методика оценивания с обоснованием;

значение оценки.

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

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

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

Литература

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006. — с 177-209.

Приложение А. Пример резюме Днепропетровск, пр. Героев тел. моб. +380684036368 45 кв.298 тел. раб. +380567702922 Демченко Дмитрий Андреевич

–  –  –

Пеший туризм, тяжелая атлетика, классическая и современная Увлечения гитарная музыка, современные интернет-технологии Приложение Б. Темы для разработок.

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

Стоматологическая поликлиника Тестирование знаний учащихся Торговая база Трудоустройство Успеваемость студентов ФИСТ Учет банковских операций с валютными вкладами физических лиц Учет банковских операций с валютными вкладами юридических лиц Учет бегущих строк на телевидении для частных лиц Учет заказов и продаж Учет заявок на производство кондитерских и хлебобулочных изделий Учет курсовых работ Учет материальных ценностей Учет материальных ценностей при реализации металла и металлоизделий Учет поставок и реализации компьютеров Учет поставок и реализация продуктов питания Учет работы поликлиники Учет работы с пластиковыми картами Учет сетевого и компьютерного оборудования Численность населения Таможенная статистика Приложение В. Пример технического задания Техническое задание на разработку программы "Интернет база данных" к Договору №___

8.1. Введение 8.1.1. Наименование программы Наименование программы: "Земная ось" 8.1.2. Назначение и область применения Программа предназначена для применения в туристических агентствах в качестве системы привлечения клиентов и осуществления продаж online.

Система предоставляет WEB-интерфейс по протоколу HTTP. Основными функциями системы являются маркетинговая и сбытовая.

8.2.Основания для разработки Основанием для разработки является договор №1/24 от 10.01.2005 с туристической фирмой «Земная ось» в лице директора Иванова Ивана Ивановича (в дальнейшем – Заказчика), действующего на основании устава фирмы «Земная ось» с одной стороны, и ЧП Петрова П. (в дальнейшем Исполнителя)

–  –  –

забронированного предложения туроператора.

8.3.1.6 Возможность поиска (фильтрации) по базе данных информации по отелям.

8.3.1.7 Для Администраторов базы данных возможность поиска (фильтрации) по базе данных информации по туристам.

8.3.1.8 Для Администраторов базы данных возможность анализа в базе данных динамики изменения цен и рейсов.

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

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

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

использованием лицензионного программного обеспечения;

регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

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

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

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



Pages:   || 2 |

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

«Казанский национальный, исследовательский технический университет им. А.Н. Туполева – КАИ МЕТОДОЛОГИЯ НАУЧНЫХ ИССЛЕДОВАНИЙ Курс лекций Профессор кафедры «Прочность конструкций», д.т.н. И.Ш. Шарафеев Казань 201 Казанский национальный исследовательский технический университет им. А.Н. Туполева – КАИ КНИТУ-КАИ им. А.Н. Туполева Институт авиации, наземного транспорта и энергетики (ИАНТЭ) Кафедра «Прочность конструкций» И.Ш. Шарафеев. Курс лекций по дисциплине М.2.В.ОД.1 «Методология научных...»

«Серия «Первый Президент Республики Казахстан Нурсултан Назарбаев. Хроника деятельности» Первый Президент Республики Казахстан нурсултан назарбаев Хроника деятельности 2004 год АСтАнА 2009 УДК 342 ББК 67.400 П26 Издатель: тОО «Деловой мир Астана»Редакционно-издательская группа: М.Б. Касымбеков (руководитель), доктор политических наук, профессор, Б.Б. темирболат (ответственный редактор), Ж.К. Усембаева, доктор технических наук, профессор, Е.А. Хасенов, т.А. темирханов, М.М. Бейсенова П26 Первый...»

«Федеральное государственное бюджетное образовательное учреждение высшего образования «Саратовский государственный технический университет имени Гагарина Ю.А.» Кафедра «Прикладная математика и системный анализ» РАБОЧАЯ ПРОГРАММА по дисциплине «С.2.1.4 Теория вероятностей и математическая статистика» специальности подготовки (10.05.03) 090303.65 «Информационная безопасность автоматизированных систем» форма обучения – дневная курс – 2 семестр – 3,4 зачетных единиц – 7 часов в неделю – 3,4 всего...»

«Федеральное государственное бюджетное образовательное учреждение высшего образования «Саратовский государственный технический университет имени Гагарина Ю.А.» Кафедра «Экономика инновационной деятельности» РАБОЧАЯ ПРОГРАММА по дисциплине «Б. 3.1.5 Коммерческая деятельность » направления подготовки «100700.62 Торговое дело» Профиль «_«100700.62/02 Логистика в торговой деятельности» (для дисциплин, реализуемых в рамках профиля) форма обучения – заочно сокращенная курс – 1,2 семестр – 2,3 зачетных...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО РЫБОЛОВСТВУ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Камчатский государственный технический университет» (ФГБОУ ВПО «КамчатГТУ») УТВЕРЖДАЮ Проректор по НР Н.Г. Клочкова ^ і, 03» 09 2014 г. « РАБОЧАЯ ПРОГРАММА ДИСЦИПЛИНЫ «ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОМЫШЛЕННОГО РЫБОЛОВСТВА» программы подготовки научно-педагогических кадров в аспирантуре по направлению подготовки 35.06.04 «Технологии, средства механизации и...»

«Федеральное государственное бюджетное образовательное учреждение высшего образования «Саратовский государственный технический университет имени Гагарина Ю.А.» Кафедра «Экология» РАБОЧАЯ ПРОГРАММА по дисциплине «Б.2.2.4 Геохимия окружающей среды» направления подготовки «(05.03.06) 022000.62 Экология и природопользование» Квалификация -бакалавр Профиль «Экология» форма обучения – очная курс – семестр – зачетных единиц – 3 часов в неделю – 3 академических часов – 108, в том числе: лекции – 1...»

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

«Федеральное государственное бюджетное образовательное учреждение высшего образования «Саратовский государственный технический университет имени Гагарина Ю.А.» Кафедра «Архитектура» РАБОЧАЯ ПРОГРАММА по дисциплине «Б.3.1.3.Архитектурное проектирование (1уровень) направления подготовки (07.03.01) 270100.62 Архитектура Профиль «Архитектура» форма обучения – дневная курс – семестр – 1,2 зачетных единиц – 8 часов в неделю – 8 академических часов – 288 в том числе: лекции – практические занятия – 144...»

«Федеральное государственное бюджетное образовательное учреждение высшего образования «Саратовский государственный технический университет имени Гагарина Ю.А.» Кафедра «Массовые коммуникации и лингвистика» РАБОЧАЯ ПРОГРАММА по дисциплине Б.1.2.2.1.2 «Политология» направления подготовки 080200.62 (38.03.02) «Менеджмент» Профиль «Управление человеческими ресурсами» форма обучения – очная курс – 2 семестр – 4 зачетных единиц – 3 всего часов –108 в том числе: лекции – 18 практические занятия –18...»

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

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

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

«Федеральное агентство по рыболовству Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Астраханский государственный технический университет» Разработка и предоставление образовательных услуг в области среднего профессионального, высшего, дополнительного, дополнительного профессионального образования, международного бизнес-образования; воспитательная работа, научно-исследовательская и инновационная деятельность сертифицированы DQS и ГОСТ Р по...»

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

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

«Министерство образования и науки Российской Федерации ФГБОУ ВПО «Уральский государственный лесотехнический университет» Кафедра истории и экономической теории Одобрено: Утверждаю: Кафедрой истории и экономической теории Директор ИАТТС Протокол от 10.10. 2015 г. № 2 Зав. Кафедрой Д.Ю.Пухов _ Е.Е. Баженов Методическая комиссия ИАТТС Протокол от «»_2015 г. «»_2015 г. Председатель комиссии ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ Б.1.Б.4. Экономическая теория Направление (специальность) 190600.62....»

«Федеральное государственное бюджетное образовательное учреждение высшего образования «Саратовский государственный технический университет имени Гагарина Ю.А.» Кафедра «История Отечества и культуры» РАБОЧАЯ ПРОГРАММА по дисциплине C.1.1.9 «Культурология» направления подготовки 14.05.02 «141403.65 Атомные электростанции: проектирование, эксплуатация и инжиниринг» квалификация – специалист форма обучения – очная курс – 5 семестр – 9 зачетных единиц – 6 часов в неделю – 6 всего часов – 216 в том...»

«СОДЕРЖАНИЕ 1. Общая характеристика послевузовского профессионального образования по отрасли технические науки 2. Основная образовательная программа подготовки аспиранта по научной специальности 05.13.11 – Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей 3. Сроки освоения основной образовательной программы подготовки аспиранта по специальности 05.13.11 – Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей 4....»

«ЕСТЕСТВЕННЫЕ И ТЕХНИЧЕСКИЕ НАУКИ Конкурс Российского научного фонда на получение грантов по приоритетным тематическим направлениям исследований Российский научный фонд извещает о проведении открытого публичного конкурса на получение грантов Фонда по приоритетному направлению деятельности Российского научного фонда «Проведение фундаментальных научных исследований и поисковых научных исследований по приоритетным тематическим направлениям исследований». Гранты выделяются на осуществление...»

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







 
2016 www.programma.x-pdf.ru - «Бесплатная электронная библиотека - Учебные, рабочие программы»

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