44076

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

Дипломная

Информатика, кибернетика и программирование

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

Русский

2013-11-09

304 KB

26 чел.

СОДЕРЖАНИЕ:

ВВЕДЕНИЕ……………………………………………………………....…....3

1.ОБУЧАЮЩИЕ СРЕДСТВА ДЛЯ ПРОВЕДЕНИЯ ПРОЦЕССОВ АНАЛИЗА И СПЕЦИФИЦИРОВАНИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ. ОБЗОР ЛИТЕРАТУРЫ……………………………………..…5

  1.   Требования в программной инженерии SWEBOK……………………...…5
    1.   Способ представления требований по К. Вигерсу…….……………….......8
    2.   Представление требований по И. Соммервилю…………………………...8
    3.   Анализ требований по С.А. Орлову…………….…………..………..……10

2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ВКР…………………………..………….….12

3. ПОСТАНОВКА ЗАДАЧИ…………………………………………..………..…13

  1.  Анализ предметной области «Программные требования»………………………………………………………………......…13
    1.   Основные шаги процесса определения требований ……………..................18
  2.  ПРОЕКТИРОВАНИЕ ЭЛЕКТРОННОЙ ОБУЧАЮЩЕЙ СИСТЕМЫ………………………………………………………………………...19
    1.  Требования к структуре  и содержанию электронного учебника для обучения разработке требований к программному обеспечению……………………………………………………………………...19

4.1.1 Пользовательские требования……………………………………….19

  1.  Функциональные требования…………………………………………....20
    1.  Нефункциональные требования………………………………………….22
    2.  Архитектурно-контекстная диаграмма…………………………….…….23
    3.  Структура представления материала в электронной обучающей системе «Анализ требований и спецификация»………………………………………..…25
    4.  Проект баз данных ………………………………………………………….27
  2.  РЕАЛИЗАЦИЯ ЭЛЕКТРОННОЙ ОБУЧАЮЩЕЙ СИСТЕМЫ………….28

5.1 Выбор средств реализации………………………………………………..28

5.2 Проект данных……………………………………………………………30

ЗАКЛЮЧЕНИЕ………………………………………………………..…….32

ВВЕДЕНИЕ

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

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

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

-  являться источником информации;

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

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

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

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

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

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

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

  1.  ОБУЧАЮЩИЕ СРЕДСТВА  АНАЛИЗА И СПЕЦИФИЦИРОВАНИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ. ОБЗОР ЛИТЕРАТУРЫ

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

Известна книга Карла Вигерса «Разработка требований к программному обеспечению», его исследования описывают способы выявления, формулировки, разработки,  проверки, утверждения и тестирования требований, направленные на создание эффективного программного обеспечения [2]. В работе Иана Соммервилла «Инженерия программного обеспечения», дана широкая панорама тем инженерии программного обеспечения, охватывающая все этапы и технологии разработки программных систем [1]. В частности, она позволяет ознакомиться с технологией спецификации требований. В документе "Основы программной инженерии" известного руководства Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004, описаны базовые определения, охватывающие основные аспекты и вопросы создания программного обеспечения [4].

  1.  Требования в программной инженерии SWEBOK

В документе SWEBOK1 описывается как одно из десяти областей знаний термин «программные требования» [4]. SWEBOK представляет собой структуру, которая включает базовое определение и описание областей знаний, относящихся к вопросам создания программного обеспечения, и указывает на основные виды деятельности, связанные с разработкой и управлением требованиями.

Области знаний, которые описаны в SWEBOK:  

  •  Программные требования (Software requirements)
  •  Архитектура (Software design)
  •  Конструирование программного обеспечения (Software construction)
  •  Тестирование (Software testing )
  •  Эксплуатация (поддержка) программного обеспечения (Software maintenance)
  •  Конфигурационное управление (Software configuration management)
  •  Управление в программной инженерии (Software engineering management)
  •  Процессы программной инженерии (Software engineering process)
  •  Инструменты и методы (Software engineering tools and methods)
  •  Качество программного обеспечения  (Software quality)

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

Рис.1. Программные требования в SWEBOK

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

1) Основы программных требований (Software Requirements Fundamentals). Эта секция включает определение программных требований как таковых и описывает основные типы требований и их отличия: к продукту и процессу, функциональные и нефункциональные требования и т.п.

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

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

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

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

6) Проверка требований (Requirements Validation). Определение требований напрямую связано с процедурами проверки (verification) и утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято считать, что требования описаны неполностью, то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям.

7) Практические соображения (Practical Considerations). Здесь охвачен весь жизненный цикл программного обеспечения. Управление изменениями и сопровождение, поддержка актуальности требований и их реализации – ключ к успешным процессам программной инженерии.

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

  1.  Способ представления требований по Карлу Вигерсу

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

К. Вигерс не употребляет термин «классификация требований», а говорит о способе представления. Такой способ, по его мнению, является хорошим способом организации представления и группировки требований.

1.3    Представление требований по  Иану Соммервиллю

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

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

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

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

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

На основе этого подхода разработан метод VORD(Viewpoint-Oriented Requirments Definition – определение требований на основе точек зрения) для формирования и анализа требований. Основные этапы метода VORD показаны на рис.2.

Рис.2. Метод VORD.

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

2.Структурирование точек зрения - создание иерархии сгруппированных точек зрения.

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

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

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

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

  1.  Анализ требований по С.А. Орловым.

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

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

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

Шаги, выполняющиеся на этапе анализа, Метод Джексона:

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

2.  Объект-структура. Действия над объектами представляются диаграммами Джексона.

3. Начальное моделирование. Объекты и действия представляются как обрабатывающая модель. Определяются связи между моделью и реальным миром.

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

2.ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ВКР

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

  1.  
    ПОСТАНОВКА ЗАДАЧИ

3.1. Анализ предметной области «Программные требования».

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

Среди этапов и процессов работы с требованиями после их извлечения (Requirements Elicitation) наиболее заметны:

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

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

Определение системы (system definition),

Системные требования (system requirements),

Программные требования (software requirements) [4].

Другие названия этих этапов - формирование и анализ требований, и специфицирование требований [1].

Шаги рабочего процесса определения требований:

Сбор возможных требований;

Определение функциональных требований;

Определение нефункциональных требований.

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

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

Рис.2. Процесс формирования и анализ требований.

Процесс формирования и анализ требований проходит через ряд этапов:

  1.  Анализ предметной области.
  2.  Сбор требований.
  3.  Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
  4.  Разрешение противоречий.
  5.  Назначение приоритетов.
  6.  Проверка требований.

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

Требования к программному обеспечению состоят из трех уровней: бизнес-требования, требования пользователей и функциональные требования [2]. Модель  на рис. 3 схематично показывает организацию требований. Овалы показывают типы информации для требований, а прямоугольники - способ хранения информации (документы, диаграммы, базы данных). Стрелки указывают в какой последовательности происходит процесс работы с требованиями.

Рис.3. Классификация по К.Вигерсу.

Бизнес-требования (Business Requirements) - определяют высокоуровневые цели организации или клиента – заказчика разрабатываемого ПО.

Пользовательские требования (User Requirements) – описывают цели и задачи которые пользователям позволит решить система.

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

Нефункциональные требования включают эксплуатационные характеристики и описание атрибутов качества:

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

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

- Бизнес-правила (Business rules) – включают корпоративную политику, законодательные акты, индустриальные стандарты, учетную практику и алгоритмы вычислений.

Системные требования (System requirements) описывают высокоуровневые требования для ПО, которое содержит много подсистем (IEEE Std 1233-1998).

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

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

К моделям анализа визуального представления относятся диаграммы потоков данных, диаграммы «сущность-связь» (модель данных), диаграммы взаимодействия (модель поведения).

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

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

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

-создаются для моделирования существующего процесса движения информации;

-используются для описания обработки информации.

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

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

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

3.2.  Основные шаги процесса определения требований

Учебник должен отражать основные шаги рабочего процесса определения требований:

 

Рис. 4 Шаги рабочего процесса определения требований.

4. ПРОЕКТИРОВАНИЕ ЭЛЕКТРОННОЙ ОБУЧАЮЩЕЙ СИСТЕМЫ

4.1  Требования к структуре  и содержанию электронного учебника для обучения разработке требований к программному обеспечению

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

Основная цель процесса работы по определению требований состоит в том, чтобы направить процесс разработки на получение качественной программной системы. Для определения адекватности требованиям качества функционирования, наличия технических возможностей программного продукта к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества. Основой регламентирования показателей качества программного продукта ранее являлся международный стандарт ISO 9126:1991 (ГОСТ Р ИСО/МЭК 9126-93) «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». 

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

4.1.1 Пользовательские требования

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

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

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

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

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

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

4.1.2 Функциональные требования

К разрабатываемой и внедряемой  системе (ЭУ) предъявляется ряд требований функциональных требований.

  •  Предоставить возможность пользователям-студентам самостоятельно изучать материалы следующих разделов:

Введение;

Анализ требований:

Программные требования (Software Requirements по SWEBOK);

Анализ требований по Карлу Вигерсу;

Анализ требований  по С.А. Орлову;

Модели требований:

Модели представления данных;

Модели поведения системы;

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

Модели типичные для объектно-ориентированного подхода;

Модели типичные для структурного подхода;

Универсальные модели;

Спецификация требований ПО.

  •  Предоставить возможность пользователям-студентам просматривать примеры построения моделей следующих типов:

Модели поведения системы;

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

Модели представления данных;

Модели типичные для объектно-ориентированного подхода;

Модели типичные для структурного подхода;

Универсальные модели.

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

  1.  Нефункциональные требования

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

Требования к интерфейсу:

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

- титульный экран,

- оглавление,

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

- указание к прочтению дополнительной литературы, 

- систему самопроверки знаний,

- словарь терминов,

- справочную систему по работе с управляющими элементами учебника.

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

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

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

Требования по эргономике и технической эстетике:

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

- Удобочитаемый текст.

- Понятные средства навигации.

Требования к эффективности: 

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

Требования к защите информации от несанкционированного доступа:

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

Требования по сохранности информации:

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

Требование к масштабируемости: система должна иметь способность к расширению.

Требования к ресурсам: По окончании решения поставленной задачи на выходе предполагается получить готовый программный продукт, работающая в операционной системе Windows 2000, XP, 7 и др. Для работы с данной системой от пользователя требуется знание интерфейса любой из перечисленных операционной систем и умение работать в таковой на уровне пользователя.

  1.  Архитектурно-контекстная диаграмма

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

Рис 5. Архитектурно-контекстная диаграмма электронной обучающей системы «Анализ требований и спецификация».

  1.  Структура представления материала в электронной обучающей системе «Анализ требований и спецификация»

Структура электронной обучающей системы:

Рис 6.Основные блоки электронной обучающей системы.

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

Теоретический материал. Данный блок включает в себя:

Рис. 7- Представление теоретической информации в системе.

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

Глоссарий. Предоставляет пояснения основных терминов встречающихся в системе.

Библиотека. Содержит в себе список литературы для работы с требованиями.

Тест. Предоставляет пользователям-студентам самостоятельно пройти тестирование, для закрепления знаний. А пользователям-преподавателям просматривать результаты всех студентов прошедших тест.

4.4. Проект базы данных

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

Materials(id, zagolovok, text,parent_id, pos)- которая содержит информацию о теоретическом материале.

Test(test_id, text)- содержит информацию о  имеющихся тестах.

Questions(questions_id, test_id, text, type,pos)- содержит информацию о вопросах, которые принадлежат определенному тесту.

Answers(answers_id, questions_id)- таблица содержит информацию об ответах, принадлежащую определенному вопросу.

Result(result_id, fam, name, group, ball,data, ocenka,test_id)- таблица содержащая результаты прохождения теста студентами.

  1.  РЕАЛИЗАЦИЯ ЭЛЕКТРОННОЙ ОБУЧАЮЩЕЙ СИСТЕМЫ
    1.  Выбор средств реализации.

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

PHP - это скрипт-язык (scripting language), встраиваемый в HTML, который интерпретируется и выполняется на сервере. На PHP можно: обрабатывать данные из форм, генерировать динамические страницы, получать и посылать куки (cookies). Кроме этого в PHP включена поддержка многих баз данных (databases), что делает написание Web-приложений с использованием БД достаточно простым.

Для возможности запуска электронной обучающей системы «Анализ требований и спецификкация» на локальном сервере нужно установить специальный пакет программ, содержащий в себе Apache(свободный веб-сервер), PHP, MySQL(система управления БД).

Список приложений, которые предоставляют работу на локальном сервере:

- Denwer (набор дистрибутивов Apache, PHP, MySQL, Perl  и программная оболочка)

- TOP Server(набор серверных компонентов)

- XAMPP(достаточно оснащенный функциями сервер).

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

После запуска  файла xampp-win32-1.7.4-VC6-installer.exe в папке installation, приложение установиться на локальный компьютер.

Для разработки самого программного средства был выбран популярный MVC фреймворк3 с открытым исходным кодом, написанный на языке программирования PHP- CodeIgniter.

Схема представления MVC (Model-view-controller «Модель-представление-контроллер») - схема использования нескольких шаблонов проектирования, с помощью которых модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные.

Рис.8 Схема архитектуры MVC.

В шаблоне MVC, как следует из названия, есть три основных компонента: Модель, Представление, и Контроллер.

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

Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.

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

5.2  Проект данных

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

За отображение главной страницы отвечает представление (view) c именем text.php, который отвечает за разделение экрана на блоки: левое меню навигации(leftblock), заголовок программы (shapka), и главный блок отображения информации (contentblock).

Контроллер material.php отвечает за  меню навигации в левом блоке и для того, чтобы вывести основные пункты меню из базы данных взаимодействует с моделью getter.php. Модель getter.php  отвечает за работу с информацией в базе данных, обрабатывая информацию полученную из таблицы  materials она передает её в контроллер в нужном иерархическом порядке, организованном в виде дерева.

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

Рис 6. Общая архитектура электронной обучающей системы «Анализ требований и спецификация».

Контроллер admin.php отвечает за взаимодействие пользователя-преподавателя и электронной обучающей системой. Admin.php содержит функции:

function spisok_st() взаимодействующаяя  с отображением: admin_spisok_st.php  - который отображает пользователю информацию о всех статьях которые можно отредактировать/удалить;

 admin_edit.php - отображает страницу редактирования содержимого статьи; admin_add.php - выводит на экран пользователя страницу для добавления статьи.

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ:

  1.  Иан Соммервил. Инженерия программного обеспечения. 6-е издание М. – СПб. – Киев, 2002. -624 с.
  2.  Вигерс Карл. Разработка требований к программному обеспечению. Пер, с англ. - М.:Издательско-торговый дом "Русская Редакция", 2004. -576с.: ил
  3.  С.Орлов. Технологии разработки программного обеспечения. — СПб.: Питер, 2002. — 464 с.: ил.
  4.  Основы   программной инженерии (по SWEBOK) - http://swebok.sorlik.ru/software_engineering.html.
  5.  Информационные технологии поддержки жизненного цикла продукции МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ http://doc-load.ru/SNiP/Data1/48/48889/index.htm#i695717
  6.  Методологии проектирования информационных систем  http://ami.nstu.ru/~vms/lecture/lecture12/lecture12.htm#name4

1Проект SWEBOK (Software Engineering Body of Knowledge) был инициирован Software Engineering Coordinating Committee, совместным комитетом IEEE и ACM, в 1998 году.

2 Hyper Text Markup Language (HTML) является стандартным языком, предназначенным для создания гипертекстовых документов в среде WEB. HTML-документы могут просматриваться различными типами WEB-броузеров.

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


Предложить пример модели

Спецификация требований

Универсальные модели.

Модели типичные для структурного подхода.

Модели типичные для ООП подхода.

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

Модели представления функций

Модели представления поведения.

Модели требований

Работа с требованиями  по С.А. Орлову.

Работа с требованиями по К.Вигерсу.

Программные требования SWEBOK

Резльтаты тестов

Запрашиваемая информация

Теоретический материал

Электронная обучающая система

Виды анализа требований

Введение

Определение пользовательских требований

Определение функциональных требований

Перечисление возможных требований

Основы требов.

Процесс работы с требов.

Извлечение требований

Анализ требований

Теоретический материал

Спецификация требований

Управление требований

Практические соображения

Программные требования

Определение нефункциональных требований

Специфицирование требований

Запрос на вывод информации

Панель пользователя- студента

Панель пользователя- преподавателя

Данные  пользователя-преподавателя

База данных

Электронный учебник

Задания для самоконтроля

Учебный материал

База знаний

Модели представления  данных системы

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

Пользователь-студент

Запрос на вывод / редактирование информации

Пользователь-преподаватель

Осознание контекста системы

Главная страница

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

О программе

Теоретический материал

Практический материал

Глоссарий

Рекомендуемая литература

Тест

Запрашиваемая информация

Представление

Контроллер

Модель

  1.  Действие

4.   Обновление представления

  1.  Модификация

  1.  Оповещение об изменениях