ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 142
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Содержание
Введение
1. Теоретическая часть. Характеристика этапов разработки программных средств
Спецификация
Разработка алгоритма
Кодирование
Отладка и тестирование
Создание справочной системы
Создание установочного диска
2. Математическая часть
3. Практическая часть
Назначение программы
Язык программирования
Технические требования
Модульная схема
Структура программы
Руководство пользователя
Контрольный пример
Заключение
Список использованных источников
Приложение. Листинг программы
Введение
Программы небольшого и среднего размера (несколько тысяч строк) создаются, как правила в несколько этапов. Сначала необходимо точно определить требования, предъявляемые заказчиком к программному продукту. В дальнейшем проводится анализ предметной области и составляется с помощью экспертов в этой области ее формальная модель. На основе результатов моделирования составляется и утверждается техническое задание, календарный план работ, где указываются все сроки, конкретные исполнители и выполняемые работы. На следующем этапе выбирается методология разработки ПО, технология программирования, система программирования и выполняются работы по созданию программного продукта. Первая версия разработанной программы обязательно должна быть подвергнута тестированию, как со стороны программистов, так и со стороны заказчика на предмет выявления ошибок. После устранения всех обнаруженных ошибок начинается этап внедрения, но на этот этап может потребоваться даже больше времени, чем на разработку программы. Этот этап обычно заканчивается подписанием акта приемки работ по созданию программы. Немаловажным этапом является этап обучения сотрудников организации заказчика приемам работы с внедренной программой. Последним этапом является этап сопровождения программы. На этом этапе создатели программы гарантируют на определенный период бесплатное разрешение вопросов, возникающих при эксплуатации программы, а также информируют заказчика о новых усовершенствованных версиях программы.
В математической части работы будут приведены теоретические основы нечетких множеств и алгоритмы основных операций над ними. Понятие нечеткого множества - понятие математической формализации нечеткой информации с целью ее использования при построении логических моделей сложных систем. В основе этого понятия лежит представление о том, что составляющие данное множество элементы, т.е. обладающие общим свойством, могут обладать этим свойством в различной степени и, следовательно, принадлежат данному множеству с различной степенью.
В последней, практической части работы, будет разработана программа, реализующая несколько операций над нечеткими множествами, приведено ее описание: структура программы, технические условия, инструкция пользователя и результаты контрольных испытаний.
1. Теоретическая часть. Характеристика этапов разработки программных средств
Программа, работающая на компьютере, нередко отождествляется с самим компьютером, т.к. человек, использующий программу, "вводит в компьютер" исходные данные, как правило, при помощи клавиатуры, а компьютер "выдает результат" на экран, на принтер или в файл. На самом деле, преобразование исходных данных в результат выполняет процессор компьютера. Процессор преобразует исходные данные в результат по определенному алгоритму, который, будучи записан на специальном языке, называется программой. Таким образом, чтобы компьютер выполнил некоторую работу, необходимо разработать последовательность команд, обеспечивающую выполнение этой работы, или, как говорят, написать программу.
Этапы разработки программы
Выражение "написать программу" отражает только один из этапов создания компьютерной программы, когда разработчик программы (программист) действительно пишет команды (инструкции) на бумаге или при помощи текстового редактора.
Программирование - это процесс создания (разработки) программы, который может быть представлен последовательностью следующих шагов:
. Спецификация (определение, формулирование требований к программе).
. Разработка алгоритма.
. Кодирование (запись алгоритма на языке программирования).
. Отладка.
. Тестирование.
. Создание справочной системы.
7. Создание установочного диска (CD-ROM). [2]
Спецификация
Спецификация, определение требований к программе - один из важнейших этапов, на котором подробно описывается исходная информация, формулируются требования к результату, поведение программы в особых случаях (например, при вводе неверных данных), разрабатываются диалоговые окна, обеспечивающие взаимодействие пользователя и программы.
Процесс разработки начинается с создания концептуального описания будущего продукта, задающего "по-крупному" его образ, видение (этот документ так и называется "vision statement") в контексте требований рынка. Главным действующим лицом на этом этапе является "менеджер по продукту" (product manager) - специалист-маркетолог, знающий ситуацию на рынке и запросы потенциальных пользователей. Его задача - донести до менеджеров по разработке ПО потребительские свойства будущего продукта, т.е. указать, какие цели и требования пользователей необходимо удовлетворить, какие для этого заложить функциональные возможности (product features) и в каком порядке в соответствии с существующими приоритетами следует их ранжировать.
На основании vision statement менеджеры по разработке составляют функциональную спецификацию. Здесь функциональные особенности будущего продукта прописываются все еще с точки зрения будущего пользователя, правда, с большей степенью подробности, глубины и формализованное. Затрагиваются вопросы архитектуры проекта, определяются основные компоненты и взаимосвязи между ними. Принципиально то, что эта начальная спецификация вовсе не должна фиксировать всю функциональность будущего продукта, как и детали каждой из уже определенных функций. В течение последующих этапов работы эта спецификация подвергнется ревизии по мере того, как разработчики будут больше узнавать о самом продукте, обретающем материальное воплощение и в связи с этим способность "сообщать" о целесообразности наличия (формы) той или иной функции.
На изменение функциональности будут влиять и внешние факторы, в том числе те реальные и потенциальные рыночные продукты, которые так или иначе конкурируют с разрабатываемым ПО. Наконец, функциональность зависит и от таких прозаических факторов, как недостаток ресурсов, отставание от графика или просто изъяны в реализации, которые невозможно или некогда исправить. В этом смысле корпоративная культура компании Microsoft не предполагает каких-либо комплексов: здесь без колебаний "режут по живому", отдавая приоритет своевременности выброса продукта на рынок. Статистические данные по основным продуктам Microsoft показывают, что в среднем около 25% содержащихся в исходной спецификации (разрекламированных, а потому ожидаемых потребителем) функциональных особенностей исчезают ко времени выпуска продукта; если же считать и то, что привнесено, то конечная функциональность будет отличаться от исходной на 30% и более.
На основе функциональной спецификации менеджеры по разработке, постоянно консультируясь с проектировщиками, начинают на модульной основе создавать горизонтальную архитектуру продукта. Главное, что на этой стадии все основные функции ПО разбиваются на несколько групп (обычно три-четыре группы). Соответственно, формируется столько же подпроектов, работа над которыми будет вестись последовательно. Разбиение производится на основе уже имеющейся классификации функций по степени важности. Наиболее важные (1/3 от общего количества, если групп всего 3) попадают в первый подпроект; другие, менее приоритетные, реализуются в рамках второго подпроекта, и наконец, прочие, наименее значимые функции выполняются в последнем подпроекте. Каждый подпроект заканчивается выпуском промежуточной "контрольной" версии продукта (milestone release).
программа язык алгоритм спецификация
Определенная таким образом архитектура проекта отображается на организационную структуру: для реализации отдельных Функций в рамках одного подпроекта назначаются небольшие команды (small feature teams), которые и работают параллельно и максимально автономно. Для них определяется график работы и выделяются необходимые ресурсы, за рамки которых выходить не рекомендуется. Причем большое значение на рассматриваемом этапе придается сознательному принятию этих рамок самими разработчиками, которые имеют возможность детально проанализировать назначенную им задачу. В результате график, планируемый с точностью до дня, часто оказывается чересчур оптимистичным.
Следует обратить внимание на весьма упрощенный подход к разработке архитектуры программного продукта: по сути, само понятие архитектуры низводится до вспомогательного инструментария, подчиненного интересам организационного планирования и управления. Между тем, с точки зрения современных представлений хорошо структурированная архитектура продукта есть необходимое условие его успешной разработки и - что особенно важно! - дальнейшего развития. Именно поэтому виднейшие авторитеты в области Software Engineering, например Гради Буч, рассматривают архитектуру, определяющую логическую и физическую структуры программной системы, как основу надлежащих стратегических и тактических проектных решений в целях построения качественного продукта.