Файл: Методические рекомендации по написанию магистерской диссертации для направления Прикладная информатика.doc

ВУЗ: Не указан

Категория: Методичка

Дисциплина: Не указана

Добавлен: 06.11.2023

Просмотров: 112

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

2. Структура диссертации

2.2 Структура первой главы

2.3 Структура второй главы

Рисунок 3. Объединение ролей в проектных командах.Руководители проекта должны создавать отношения сотрудничества между участниками проекта, добиваться общего видения проблем и путей их разрешения. Члены команд в свою очередь должны объединять усилия для достижения общих целей, избегать конфликтов, помогать и поддерживать друг друга. Надежная внутренняя среда проекта - залог успеха любого проекта.Рекомендуемая литература по данному разделу: Microsoft Solutions Framework, Модель процессов MSF, вер.3.1 (Отдел MSF, Microsoft ) - White Paper.- 2002. Р. Денис Гиббс. Управление проектами с помощью IBM Rational Unified Process. Практические уроки. Пер.с англ. – М.: КУДИЦ-ПРЕСС. – 2007. – 304 с Алексеева Т.В. Организация взаимоотношений участников ИТ - проекта. // «Бизнес команда и ее лидер», № 6.- М.: ООО «Интерсоциоинформ».- 2008.- 8 стр. Средства коллективной работы над проектом автоматизации После создания команды и распределения ролей между членами команды необходимо определится с средствами коллективной разработки (СКР), которые вы будете использовать. Неправильный выбор может повлечь за собой как огромные потери времени на освоение и настройку СКР, так и необоснованно высокие затраты на приобретение программ, у которых вы не будете использовать все имеющиеся возможности.Для выбора СКР предлагается Вам использовать обзор, представленный в таблице 1 и 2. Вышеприведенный обзор включает всего три средства коллективной разработки, хотя всего таких программ, конечно, гораздо больше. В таблице 1 приведена таблица возможностей некоторых коммерческих СКР, а в таблице 2 - некоммерческих. К сожалению, все имеющиеся средства перечислить невозможно. Достаточно полный список ссылок на сайты производителей СКР можно найти по адресу http://www.cs.colorado.edu/users/andre/configuration_management.html Таблица 1 Коммерческие средства разработки

3. Требования по оформлению диссертации

3.1 Требования и правила оформления текстового материала

3.2 Правила оформления иллюстративного материала

3.3 Правила составления списка литературы

3.4 Правила оформления приложений

3.5 Порядок проверки диссертации



1.4 Анализ существующих разработок и выбор стратегии автоматизации

1.4.1 Анализ существующих разработок для автоматизации задачи

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

Обзор рынка программных средств удобно проводить с помощью Internet. Адреса используемых при обзоре ресурсов следует добавить в список литературы диссертации.

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

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

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

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

  • провести сбор информации по существующим разработкам;

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

  • написать вывод, исходя из анализа.


1.4.2 Обоснование способа приобретения ИС для автоматизации задачи

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

  • анализ бизнеса;

  • анализ стратегии развития бизнеса;

  • определение стратегических свойств ИС;

  • определение функциональности ИС в целом;

  • выбор стратегии автоматизации:

    • хаотичная;

    • по участкам;

    • по направлениям;

    • полная;

  • формирование комплексного проекта;

  • определение архитектуры;

  • формирование бизнес-плана

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


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

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

1.5.1. Обоснование проектных решений по информационному обеспечению

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

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

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

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

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

  • обоснование состава и способов организации файлов с результатной и промежуточной информацией.

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


1.5.2. Обоснование проектных решений по программному обеспечению

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

При обосновании выбора общего ПО целесообразно:

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

  • дать классификацию и обосновать выбор используемой СУБД.

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

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

  • дать классификацию и обосновать выбор методов (например, структурное, модульное проектирование, методом “сверху вниз” или объектно-ориентированное проектирование и т.д.) и средств проектирования специального (функционального) ПО (например, использование библиотеки прикладных программ, или генератора программ, или какого-либо языка программирования);

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

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

План обоснования целесообразно сделать следующим:


  • выделить перечень требуемых элементов программного обеспечения;

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

  • осуществить сравнение возможных альтернатив и сделать обоснованный выбор


1.5.3 Обоснование проектных решений по техническому обеспечению

Вначале данного раздела следует дать определение этого вида обеспечения и его структуру.

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

План обоснования целесообразно сделать следующим:

  • выделить перечень требуемых элементов технического обеспечения;

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

  • осуществить сравнение возможных альтернатив и сделать обоснованный выбор/
    1. 1   2   3   4   5   6   7   8

2.3 Структура второй главы


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

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

2. Проектная часть

    1. Разработка проекта автоматизации

      1. Этапы жизненного цикла проекта автоматизации

      2. Ожидаемые риски на этапах жизненного цикла и их описание

      3. Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации

2.2 Управление проектом автоматизации

2.2.1 Описание системы принятия управленческих решений

2.2.2 Формирование команды проекта автоматизации

      1. Средства коллективной работы над проектом автоматизации

    1. Информационное обеспечение задачи

      1. Информационная модель и её описание

      2. Характеристика нормативно-справочной, входной и оперативной информации

      3. Характеристика результатной информации

    1. Программное обеспечение задачи

      1. Общие положения (дерево функций и сценарий диалога)

      2. Характеристика базы данных

      3. Структурная схема пакета (дерево вызова программных модулей)

      4. Описание программных модулей

    2. Апробация результатов исследования


2. Проектная часть

    1. Разработка проекта автоматизации

2.1.1 Этапы жизненного цикла проекта автоматизации

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