Разработка электронного учебника по дисциплине «Менеджмент» для студентов среднего профессионального образования для всех специальност

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

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

1. Эффективность компьютерной поддержки:

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

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

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

2. Методические свойства:

• отсутствие грамматических и семантических ошибок:
• простота освоения программы и простота работы с ней;

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

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

3. Качество экранного дизайна:

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

4. Экономическая обоснованность:

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

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

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

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

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

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

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

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

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

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

 

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

 

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

Требования  к отказоустойчивости

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

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

3. Работоспособность. Это процентное соотношение времени, в течение которого программное приложение доступно пользователю.

4. Ремонтопригодность. Существует два аспекта понятия ремонтопригодности:

1) восстанавливаемость – легкость устранения дефектов разработки. Программа должна обеспечивать восстанавливаемость двумя способами: легко устанавливать источники дефектов; устранять одни дефекты без порождения других.

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

Системные требования

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

Таблица 1

Минимальные системные требования

№	Наименование	Параметры
1.	Операционная система	Windows 98/2000/ME/XP/Vista
2.	Оперативная память	32 Mb
3.	С памятью на жестком диске	3 Mb
4.	Видеокарта	32 Mb

 

 

2. СПЕЦАЛЬНАЯ  ЧАСТЬ

 

2.1. Проектирование

 

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

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

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

- идентификацию подсистем;

-определение основных  принципов управления подсистемами, взаимодействия подсистем.

Предварительное проектирование включает три типа деятельности:

1. Структурирование системы. Система структурируется на несколько подсистем, где под подсистемой понимается независимый программный компонент. Определяются взаимодействия подсистем.
2. Моделирование управления. Определяется модель связей управления между частями системы.
3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульные соединения.

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

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

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

Задачи проектирования, следующие:

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

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

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

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

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

1. Имя модуля. Указывается имя, с помощью которого можно обратиться к модулю. Для модуля имеющего несколько входов, для каждого из входов составляются отдельные спецификации.
2. Функция. Определяется, что делает модуль, когда он вызван, а также его назначение. Этот элемент спецификации не должен содержать сведения о том, как функция реализуется.
3. Список параметров. Определяется число и порядок параметров, передаваемых модулю.
4. Входные параметры. Подробно описываются все входные параметры (указываются атрибуты, формат, размер, единицы измерения, а также допустимые диапазоны значений всех входных параметров).
5. Выходные параметры.