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

Разработка концептуальной схемы базы данных и базы данных АИС. На третьем уровне иерархии например в категории эффективность технологического процесса можно выделить качество подготовки документов качество индексирования документов качество ввода документов в ЭВМ качество обработки данных и др. Процессы: RD - Определение производственных требований ES - Исследование существующих систем T - Определение технической...

2015-09-20

122.13 KB

4 чел.


Поделитесь работой в социальных сетях

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


Оглавление

[1] Оглавление

[2] Введение

[3] Раздел 1. Отечественные и зарубежные технологии проектирования автоматизированных систем.

[4] О видах стандартов

[5] Рассматриваемые стандарты

[6] Методика Oracle CDM

[6.1] Международный стандарт ISO/IEC 12207: 1995-08-01

[7] Стандарты комплекса ГОСТ34

[7.1] Соотнесение процессов ISO12207 и соответствующих компонентов ГОСТ34 и CDM

[7.2] Основные процессы

[8] ИТОГИ

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

[10] Разработка технического задания на АИС.

[11] Общие сведения.

[12] Назначение и цели создания АИС

[13] Характеристика информационной системы для учета рабочего времени.

[14] Требования к ИС

[15] Требования к видам обеспечения АИС:

[16] Состав и содержание работ по созданию системы

[17] Разработка концептуальной схемы базы данных и базы данных АИС.


Введение

Цель выпускной квалификационной работы:

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

        Цель АИС:

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

Задачи создания АИС:

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

  •  Выполнение процессов преобразования информации и выдача ее в удобном для восприятия виде;
  •  Экономия ресурсов при выполнении процессов в преобразования информации;
  •  Развитие социального статуса работников, занятых в контуре функционирования АИС.


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

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


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

О видах стандартов 

После конференции АПО/ROUG97 (Таруса, июнь 1997), где автор сделал доклад "ISO/IEC 12207, ГОСТ34, Oracle CDM - процессы, результаты, соотнесение", обнаружилось, что:

а) интерес к теме есть и у отдельных людей, и у коллективов;

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

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

  1.  по предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);
  2.  по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например, ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT Д. Росса), фирменные стандарты (Microsoft ODBC, IBM SNA);
  3.  по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель".

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

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

Рассматриваемые стандарты

Далее будем рассматривать следующие стандарты и методики, касающиеся ЖЦ АС и ПО:

  1.  Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, расчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.
  2.  Стандарты комплекса ГОСТ 34 на создание и развитие АС - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Кроме того, эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости. Насколько это так, а насколько ГОСТ 34 остается работающим с пользой - полезно разобраться.
  3.  Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения (ПО) - казалось бы весьма неконкретный, но вполне новый и отчасти "модный" стандарт.

Методика Oracle CDM

  1.  Возникла как развитие разработанной давно версии Oracle CASE-Method, известной по использованию Oracle CASE (ныне Designer/2000) и книгам Р. Баркера. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения (см. описание CDM) о простом приспособлении CDM к проектам, в которых используется другой инструментальный комплекс.

2) Общая структура.

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

2.2. Этапы:

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

2.3. Процессы:

  •  RD - Определение производственных требований,
  •  ES - Исследование существующих систем,
  •  TA - Определение технической архитектуры,
  •  DB - Проектирование и построение БД,
  •  MD - Проектирование и реализация модулей,
  •  CV - Конвертирование данных,
  •  DO - Документирование,
  •  TE - Тестирование,
  •  TR - Обучение,
  •  TS - Переход к новой системе,
  •  PS - Поддержка и сопровождение.

2.4. Процессы состоят из последовательностей задач, задачи разных процессов взаимосвязаны явно указанными ссылками. CDM наиболее сильно связан с методикой "Oracle PJM" по организации управления проектом.

3) Особенности.

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

Методика не предусматривает: включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным; дополнительное удаление задачи (и порождаемых ею документов), не предусмотренное одной из трех моделей ЖЦ; изменение последовательности выполнения задач по сравнению с предложенной, тем более - по ходу процесса проектирования.

3.2. Все модели ЖЦ АС и ПП являются по сути каскадными; даже "облегченный подход", несмотря на понятную инерционность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.

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

3.4. Прикладная система рассматривается в основном как программно-техническая система - например, моменты организации выполнения вполне возможных оргструктурных преобразований, реально всегда происходящих при переходе к новой АС (вовсе не имеется в виду BPR!), и соответствующего обеспечения отсутствуют в этой методике. Другой фактической ориентацией методики является ее (исторически понятная) направленность на создание Информационной Системы с Базами Данных в достаточно традиционном понимании.

Международный стандарт ISO/IEC 12207: 1995-08-01

1) Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1"Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важное ЗАМЕЧАНИЕ СТАНДАРТА: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)

ОПРЕДЕЛЕНИЕ СТАНДАРТА: система - это объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.

В отличие от Oracle CDM стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.

2) Общая структура.

2.1. Процессы ЖЦ. По сравнению с CDM стандарт ISO состоит из гораздо более крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п. Грубо говоря, один такой процесс сравним со всеми процессами CDM вместе взятыми.

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

2.1.1. Описаны 5 основных процессов ЖЦ ПО:

1. Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО.

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

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

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

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

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

2.1.3. Описаны 4 организационных процесса: Процесс управления, Процесс создания инфраструктуры, Процесс усовершенствования, Процесс обучения.

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

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

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

3) Особенности.

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

Примеры:

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

Такой характер позволяет реализовывать любую модель ЖЦ.

ОПРЕДЕЛЕНИЕ СТАНДАРТА: Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.

3.2. Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.

ЗАМЕЧАНИЕ СТАНДАРТА: Добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Контракт понимается в широком смысле: от юридически оформленного контракта до неформального соглашения, соглашение может быть определено и единственной стороной как задача, поставленная самому себе.

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

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

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

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

При этом разработчик должен установить и документировать как требования к программному обеспечению:

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

б) внешние связи (интерфейсы) с единицей программного обеспечения;

в) требования квалификации;

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

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

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

ж) определение данных и требований базы данных;

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

и) документация пользователя;

к) работа пользователя и требования выполнения;

л) требования сервиса пользователя.

(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ34 по видам обеспечения системы.)

ОПРЕДЕЛЕНИЕ СТАНДАРТА: Требование квалификации - набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.

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

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

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

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

3.6. Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД**), но и не использовать БД вовсе.

Стандарты комплекса ГОСТ34

1) ГОСТ34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в "Особенностях" ГОСТ34. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.

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

2) Общая структура.

2.1) Из всех существующих и не реализованных групп документов будем основываться только на Группе 0 "Общие положения" и Группе 6 "Создание, функционирование и развитие АС". Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.

2.2) Для общего случая разработки АС стадии и этапы ГОСТ34 приведены в таблице:

Таблица 1. Стадии и этапы разработки АС.

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

1.1. Обследование объекта и обоснование необходимости создания АС; 
1.2. Формирование требований пользователя к АС; 
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания);

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

2.1. Изучение объекта; 
2.2. Проведение необходимых научно-исследовательских работ; 
2.3. Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя 
2.4. Оформление отчета о выполненной работе;

3. ТЗ - Техническое создание АС.

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

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

4.1. Разработка предварительных проектных решений по системе и ее частям; 
4.2. Разработка документации на АС и ее части.

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

5.1. Разработка проектных решений по системе и ее частям; 
5.2. Разработка документации на АС и ее части; 
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку; 
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

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

6.1. Разработка рабочей документации на систему и ее части; 
6.2. Разработка или адаптация программ.

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

7.1. Подготовка объекта автоматизации к вводу АС в действие; 
7.2. Подготовка персонала; 
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); 
7.4. Строительно-монтажные работы; 
7.5. Пуско-наладочные работы; 
7.6. Проведение предварительных испытаний; 
7.7. Проведение опытной эксплуатации; 
7.8. Проведение приемочных испытаний.

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

8.1. Выполнение работ в соответствии с гарантийными обязательствами; 
8.2. Послегарантийное обслуживание.

2.3) Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно (то есть по сути - процессов), и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ34 и ISO12207.

3) Особенности.

3.1) Главный мотив: разрешить проблему "вавилонской башни". В 80-х годах сложилось положение, при котором в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная НТД - "нормативно-техническая документация". Это затрудняло интеграцию систем, обеспечение их эффективного совместного функционирования. Действовали следующие комплексы и системы стандартов, устанавливающие требования к различным видам АС:

  •  единая система стандартов автоматизированных систем управления (24-я система) для АСУ, ОАСУ, АСУП, АСУТП и др. организационно-экономических систем;
  •  комплекс стандартов системы 23501, распространявшихся на САПР - системы автоматизированного проектирования;
  •  четвертая группа 14-й системы стандартов, распространяющаяся на АС технологической подготовки производства.

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

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

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

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

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

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

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

3.2) Степень адаптивности формально определяется возможностями:

  1.  опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";
  2.  опускать этапы, объединять и опускать большинство документов и их разделов;
  3.  вводить дополнительные документы, разделы документов и работы;
  4.  динамически создавая т. н. ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

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

3.3) Несмотря на сказанное выше, стадии и этапы на практике ориентируют разработчиков на каскадную схему ЖЦ или близкую к ней.

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

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

  1.  "организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;
  2.  "система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций" (по ГОСТ 34.003-90).

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

Замечание: Эти определения и определение системы в ISO12207 вполне совместимы для их совместного использования.

3.6) Гарантирование качества определяется в ТЗ - техническом задании на АС - и производится на любых последующих этапах и с любой степенью независимости экспертизы. В каскадной траектории ЖЦ эти экспертизы располагаются несколько позже, чем в ISO12207. Тем не менее, имеются очень большие потенциальные возможности, которые часто слабо эксплуатируются на практике.

3.7) Степень обязательности: прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.

3.8) Ключевым документом взаимодействия сторон является ТЗ - техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

Соотнесение процессов ISO12207 и соответствующих компонентов ГОСТ34 и CDM

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

Более того, соотнесение и должно делаться в условных соответствиях, так как:

  •  ГОСТ34 и CDM в первую очередь ориентированы на действия по созданию и поддержке систем, а ISO12207 - на приобретение и эксплуатацию систем, а разработка является процессом, логически вытекающим из приобретения;
  •  и главное: ISO12207 изначально предусматривает конкретные применения своих положений после построения профиля для конкретного проекта; таким образом, очень часто некоторый элемент конкретной методики или стандарта может или должен только условно соотноситься с элементами исходных положений ISO12207 и наоборот. Таким образом, конкретное соотнесение элементов должно делаться в процессе адаптации стандартов к проекту и выработки профиля ЖЦ.

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

Основные процессы

В таблице 2 в первом столбце указаны стадии и этапы ГОСТ 34.601-90, как материала, направленного на формирование ЖЦ системы в целом. Во втором столбце указаны процессы ISO12207, в третьем - процессы CDM. В четвертом столбце примечания показывают возможную трактовку соотнесения, возникающую при традиционной (на взгляд автора) трактовке организации ЖЦ АС, близкой к ИС организационно-экономического типа.

Таблица2.  Сравнение технологий и методологии.

ГОСТ 34.601-90; "э.X.Y" - этап Y стадии X

ISO/IEC12207: 1995-08-01

Oracle CDM;

Примечание

э.5.3 ТП, э.7.3 ВД.

1) Процесс приобретения разработчиком

нет

в ГОСТ это приобретение планируется

нет

2) Процесс поставки

нет

CDM содержит процесс CV,

Все этапы ГОСТ34.601 кроме 8. Сп, а именно: 1. ФТ, 2. РК, 3. ТЗ, 4. ЭП, 5. ТП,6. РД, 7. ВД.

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

RD, ES, TA, DB, MD, (DO), TE, (TR), TS.

аналог есть в ГОСТ (э.7.5 ВД и ранее), в ISO аналога нет в явном виде. Процессы DO TR из CDM указаны в скобках, так как они отражены и в других стандартах ГОСТ34 и процессах ISO12207.

нет

4) Процесс эксплуатации

нет

По ISO организация-оператор разрабатывает план и гарантирует соответствие плану

8. Сп., развитие АС - по пункту.1.3 ГОСТ 34.601.

5) Процесс сопровождения

PS

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

ИТОГИ

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

Так, CDM предусматривает существенно меньший набор действий по гарантированию качества, развитию системы и ПО, функционированию системы, определению действий пользователя и др. Вместе с тем, CDM явно вводит принципиально важный в реальных проектах смены поколений АС процесс CV - "конвертирование данных", который не выделен в ISO12207 и слишком косвенно отражен в ГОСТ 34.601-90. Кроме того, CDM вводит процесс проектирования базы данных в трактовке, близкой к классической.

2. Однако наличие в практике использования значительного числа конкретных методик, ориентированных к тому же на различные инструменты и терминологические "школы", заново воспроизводит, и, может быть, в еще более острой форме проблему "вавилонской башни", для решения которой создавался ГОСТ34.

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

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

4. По этой причине центральным стандартом, положения которого берутся за начальный "стержневой" набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ГОСТ 34.601-90. Этот "стержень" может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования качества, модель управления проектом.


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

 Заказчику не обходимо организовать учет явки работников на работу и ухода с нее. До начала работы каждый работник должен в порядке, установленном заказчиком, отметить свой приход, а по окончании - уход. Учет явок на работу и ухода с нее ведется в табелях использования рабочего времени установленной формы, в годовых табельных карточках и других документах. Учету подлежит фактическое рабочее время, которое состоит из отработанного и неотработанного времени, включаемое в соответствии с законодательством в рабочее время. При приеме на работу руководитель организаций обязан ознакомить с ними работника под роспись. Правила внутреннего трудового распорядка определяют порядок выполнения работниками работы в организации под его руководством и контролем. Работник обязан в порядке, установленном в организации нанимателя, отметить: приход на работу; уход с работы. Если правилами внутреннего трудового распорядка данного предприятия регламентировано, что приход работников на работу и уход с нее регистрируется в журнале установленной формы, это является правомерным.

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

Техническое задание составляется в соответствии с ГОСТ 34.60289 «Техническое задание на автоматизирование системы управления».

Общие сведения.

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

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

Разработка ведется на основании договора №1 от 09.11.09 между заказчиком (Виктором Владимировичем директор) и разработчиком (Удаловы Р.Б.).

Создание информационной системы ведется на основании договора №1 от 02.10.14 между разработчиком и заказчиком.

Плановые сроки начала работ 06.03.15, окончания работ 31.05.15.

Финансирование работ по созданию АИС будет осуществляться заказчиком.

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

Назначение и цели создания АИС

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

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

- Она создается для развития предприятия и удобного пользования для персонала.

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

Характеристика информационной системы для учета рабочего времени.

Рабочее время имеет следующие основные характеристики:

  •  продолжительность рабочего времени,
    •  режим рабочего времени,
    •  учет рабочего времени.

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

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

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

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

Требования к ИС

Требования:

  •  Система должна быть простой и понятной пользователю.
  •  Внедрение АИС должно привести к положительному экономическому эффекту.

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

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

Требования к видам обеспечения АИС:

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

Программное обеспечение должно включать:

  1.  Антивирусная программа Kaspersky Internet Security
    1.  Офисные программы (MS Office)
    2.  Операционная система Windows 7 Professional
  •  Математическое обеспечение должно включать все ранее разработанные и применяемые на предприятии методики, и алгоритмы расчета основных экономических показателей.
  •  Программное обеспечение представляет собой совокупность правовых норм, регламентирующих правоотношения при создании и внедрении системы. Правовое обеспечение на этапе разработки должно включать нормативные акты, с правовым регулированием отношений в ходе этого процесса.
  •  Даная информационная система будет внедрена в течении 3,54 месяцев.

Для работы с ИС необходимо обучить персонал.

Состав и содержание работ по созданию системы

Проектная стадия:

  •  Внедрение АИС;
  •  Сопровождение системы

Исполнителями работ являются:

  •  Разработчик АИС;
  •  Специалист по созданию ЛВС (линия высокоскоростной связи);
  •  Специалист по установке, конфигурированию, сопровождению системы.

Ответственный за выполнение всех работ по всем этапам является разработчик АИС.

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


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

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

Основные компоненты MS Access:

  •  построитель таблиц;
  •  построитель экранных форм;
  •  построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);
  •  построитель отчётов, выводимых на печать.

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

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

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

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

2.3 Определение таблиц и атрибутов таблиц

Проектирование базы данных начинается с создания таблиц. В базе данных АИС в офисе было создано 9 таблиц: Подразделения, сотрудники, должности, Категории персонала, поставщики, подрядчики, компьютерные материалы, основные заказчики, расход материалов, и копия таблицы сотрудники. Задание атрибутов видно на таблицах 4-13

Таблица 4 Атрибуты таблицы «Подразделения»

Код подразделения

Счётчик

Название подразделения

Текстовый

Численность персонала

Числовой

Таблица 5 Атрибуты таблицы «Сотрудники»

Код сотрудника

Счётчик

Табельный номер сотрудника

Числовой

ФИО сотрудника

Текстовый

Код подразделения

Числовой

Код должности

Числовой

Ид_катег_персонала

Числовой

Стаж по стец-ти

Числовой

Дата рождения

Дата/время

Таблица 6  Атрибуты таблицы «Должности»

Код должности

Счётчик

Должность

Текстовый

Таблица 7 Атрибуты таблицы «Категории персонала»

Ид_катег_персонала

Счётчик

Категория персонала

Текстовый

Таблица 8  Атрибуты таблицы «Поставщики»

Ид_поставщика

Счётчик

Поставщик

Текстовый

Расч_счёт

Текстовый

Банк

Текстовый

Таблица 9 Атрибуты таблицы «Подрядчики»

Ид_подрядчика

Счётчик

Подрядчики

Текстовый

Вид выполняемых работ

Текстовый

Таблица 10 Атрибуты таблицы «Компьютерные материалы»

Ид_нужных_материалов

Счётчик

Нужные материалы

Текстовый

Таблица 11 Атрибуты таблицы «Основные заказчики»

Ид_основные_заказчики

Счётчик

Основные заказчики

Текстовый

Руководитель организации

Текстовый

Телефон

Текстовый

Таблица 12 Атрибуты таблицы «Расход материалов»

Ид_реализация_материалов

Счётчик

Ид_строительных_материалов, изделий и конструкций

Числовой

Дата

Дата/время

Конструкция

Числовой

Ид_поставщика

Числовой

Таблица 13 Атрибуты таблицы « Копия сотрудники»

Код сотрудника

Счётчик

Табельный номер сотрудника

Числовой

ФИО сотрудника

Текстовый

Код подразделения

Числовой

Код должности

Числовой

Ид_катег_персонала

Числовой

Стаж по стец-ти

Числовой

Дата рождения

Дата/время

2.4 Создание схемы данных

После создания таблиц, следующим шагом в разработке базы данных будет создание схемы данных. Чтоб всё работало без нареканий, во время связи таблиц ставим галочку в 3-х полях:

  1.  Обеспечение целостности данных
  2.  Каскадное обновление связанных полей
  3.  Каскадное удаление связанных полей

На примере это видно на рисунке 8.

Рисунок 8 Целостность данных

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

Рис. 9 Схема данных «АИС в строительном офисе»

Заполнение таблиц

После того как была построена схема данных нужно переходить в заполнению таблиц. На рисунках 10-18 можно будет увидеть каким образом были заполнены таблицы.



 

Другие похожие работы, которые могут вас заинтересовать.
17261. Педагогические условия формирования социально-педагогического сопровождения практической подготовки специалистов для учреждений дополнительного образования 128.61 KB
  Коренные преобразования в социально-экономической жизни общества определили новые требования к качеству образовательного результата в нашей стране вызвали к жизни процессы диверсификации образования децентрализации системы управления изменили взгляды на ценности и цели парадигму образовательной деятельности. Актуальность данного исследования определяется потребностью практики образования в компетентном осуществлении прикладных исследований создания разработок позволяющих педагогу получить знания о новом образовательном продукте и...
19821. Виды контроля в процессе подготовки спортсменов различной квалификации, на различных этапах подготовки 110.75 KB
  В течение последних 20-25 лет усилиями ведущих специалистов был решен ряд актуальных проблем комплексного контроля и управления в спорте. Вместе с тем ряд важных вопросов комплексного контроля и управления в спорте в силу различных причин не нашел своего решения. Материально-техническое обеспечение системы комплексного контроля и управления в спорте в сборных командах Республики Казахстан по разным видам спорта не соответствует современным требованиям а в некоторых случаях практически отсутствует.
19318. МЕЖПРЕДМЕТНАЯ ИНТЕГРАЦИЯ В ПРАКТИЧЕСКОЙ УЧЕБНОЙ ДЕЯТЕЛЬНОСТИ 581.08 KB
  Начальное образование играет важную роль в общей системе образования так как полученный в начальной школе личностный опыт ребенка достигнутый уровень развития служат базой фундаментом для последующего обучения. Предметная разобщённость становится одной из причин фрагментарности мировоззрения выпускника школы в то время как в современном мире преобладают тенденции к экономической политической и информационной интеграции. Основной целью интеграции в образовании является формирование у младших школьников системности знаний как средства...
5972. Способы практической реализации принципа справедливости в налогообложении 34.21 KB
  Смена форм государственного устройства, как правило, сопровождалось преобразованием налоговой системы. Стремление государств соблюсти принцип справедливости в налогообложении было постоянным в цивилизованных странах. Названный принцип имеет сложное содержание и может рассматриваться как экономический, нравственный и правовой принцип.
18768. Основные направления прикладных исследований в практической социальной психологии 33.92 KB
  Положение детей в России. Содержание и формы социальной защиты детей РФ в настоящее время. Все более ощутимым становится разрушение института семьи; семья не в состоянии проявлять достаточную заботу о своих детях не выполняет родительских обязанностей нередко сама создает условия опасные для жизни и развития детей. В современной психолого-педагогической литературе встречаются различные типологии семей но все они характеризуются следующими признаками: по количеству детей: бездетная или инфертильная семья малодетная многодетная...
19398. Выполнение практической работы по изготовлению кубанской мужской традиционной рубахи 91.31 KB
  Выполнение практической работы по изготовлению кубанской мужской традиционной рубахи. Исполнение рубахи с растительным орнаментом. Актуальность темы настоящего исследования обусловлена возрастающим научным и практическим интересом к историко-культурному наследию Кубани частью которого является история традиционного костюма восточнославянского населения Кубани рубахи в частности. Такой длительный исторический промежуток времени объясняется попыткой проследить процесс этнических взаимовлияний протекающего на Кубани культурогенеза повлиявший...
21376. Использование приемов и средств активизации практической деятельности на уроках физики 629.11 KB
  В период научно-технической революции когда наблюдается быстрый рост научных знаний и их широкое внедрение в производство перед школой стоит задача вооружить своих учащихся системой прочных знаний и умениями самостоятельно пополнять их и развивать свои практические способности. Важнейший фактор успешного формирования прочных знаний по физике – развитие практической деятельности учащихся на уроках которое достигается интеллектуальной и эмоциональной подготовкой школьников к восприятию нового учебного материала. В практике работы школы...
6740. ТЕХНОЛОГИИ В УЧЕБНО-МЕТОДИЧЕСКОЙ И НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ ШКОЛЫ 15.98 KB
  Осуществить эту технологическую цепочку в состоянии лишь педагог владеющий методами научного исследования психолого-педагогической диагностики. Учитель-исследователь должен владеть технологиями проектирования и научного исследования. Технология проектирования педагогического исследования может быть представлена следующей последовательностью действий: Проводим анализ педагогической системы и ее функционирования выявляем проблемы. Определяем тему исследования которая очерчивает круг исследовательской работы.
9815. Формирование самостоятельной работы студентов при работе с электронными учебниками 241.11 KB
  Достоинства и недостатки дистанционного обучения с использованием электронных учебников. Методические приёмы в обучении информатике при использовании электронных учебников. Педагогическая модель формирования познавательного интереса учащихся с использованием электронных учебников. Дидактический эксперимент по проверке эффективности применения электронного учебника для обучения студентов высших учебных заведений...
15606. Основные стороны подготовки спортсмена 26.83 KB
  На сегодняшний день существует несколько видов подготовки спортсмена: техническая, физическая, тактическая, психологическая, теоретическая, итегральная. И у каждого автора свое трактование основ, подвидов, задач, средств методов которые используются в каждом виде подготовки, поэтому эта тема до сих пор актуальна.
© "REFLEADER" http://refleader.ru/
Все права на сайт и размещенные работы
защищены законом об авторском праве.