- •Министерство образования и науки рф
- •Содержание
- •Министерство образования и науки рф
- •1.2. Исследовательская часть.
- •1.2.1. Обзор существующих продуктов на рынке
- •Биллинг АйТи
- •Плата за трафик
- •Абонентская плата
- •1.2.3. Постановка задачи
- •1.3. Конструкторская часть.
- •1.3.1. Концепция баз данных
- •Реляционная структура данных
- •1.3.2. Общая структура системы
- •1.3.3. Схема информационных потоков
- •1.3.4. Структура данных модуля учёта тарифов
- •Структура объектов базы данных Tarif Инфологическая модель базы данных
- •Даталогическая модель базы данных
- •1.3.5. Схемы алгоритмов модуля учёта тарифов
- •1.3.6. Описание работы программного модуля.
- •1.3.5. Заключение
- •Министерство образования и науки рф
- •2.2. Выбор среды и языка программирования.
- •2.2.1. Обзор возможностей, предоставляемых программистам различными технологиями.
- •2.2.2. Преимущества .Net
- •2.2.3. Преимущества c#
- •2.2.4. Создание приложений c# с использованием интегрированной среды разработки Microsoft Visual Studio.Net.
- •2.2.5. MySql-сервер и возможности MySql
- •2.3. Этапы решения задачи на эвм
- •2.3.1. Постановка задачи
- •2.3.2. Составление проекта
- •2.3.3. Алгоритмизация
- •2.3.4. Программирование
- •2.3.5. Препарация
- •2.3.6. Трансляция
- •2.3.7. Отладка
- •2.3.8. Оформление программы
- •2.3.9. Эксплуатация
- •2.3.10. Отчет о работе
- •2.3.11. Модернизация
- •2.4. Необходимость отладки программного продукта
- •2.5. Тестирование
- •Функциональное или аналитическое тестирование
- •Содержательное тестирование
- •2.5.1. Типы тестов
- •Вырожденный тест
- •2.6. Локализация ошибок Способы локализации
- •2.7. Технология отладки программного модуля учета тарифов
- •2.8. Заключение
- •3.1.1. Схема сегментации рынка.
- •3.1.2. Принципы сегментации.
- •3.1.3. Методы сегментации
- •3.1.4. Виды и критерии сегментации.
- •3.1.5. Выбор целевого рынка
- •3.1.6. Выбор целевого сегмента
- •3.1.7. Позиционирование товара
- •3.2.2. Теоретические основы расчёта себестоимости пп
- •3.2.3. Практический расчет себестоимости пп
- •3.2.4. Практическое определение цены программного продукта
- •Факультет: мп и тк
- •Производственная и экологическая безопасность
- •4.1. Введение
- •4.2. Освещенность
- •4.3. Электромагнитное излучение
- •4.4. Электроопасность и пожароопасность
- •4.5. Защита от шума и вибрации
- •4.6. Психофизиологические факторы
- •4.7.Создание оптимального микроклимата и расчет воздухообмена
- •4.8. Выводы
- •Список литературы
- •Текст программы
- •4.3. Завершение работы с программой
- •5.3. Ошибки, вызванные неполным заполнением формы.
- •5.4. Сообщения при корректной записи тарифа
- •Результаты эспериментальной проверки
2.3. Этапы решения задачи на эвм
2.3.1. Постановка задачи
Задача, которую предстоит решить на ЭВМ, выдается в виде специального задания на разработку программы. Задание содержит формулировку задачи, необходимые характеристики разрабатываемой программы, требования к взаимодействию с ней. Выдаче такого задания для крупных задач может предшествовать большая работа научно-исследовательского характера.
Задание на разработку программы по форме и характеру должно быть аналогично техническому заданию (ТЗ) на разработку какого-либо технического продукта (см., например, ГОСТ 19.201-78 Единой системы программной документации).
Техническое задание полезно и в том случае, когда заказчик и исполнитель работают в одной и той же комнате или даже являются одним и тем же лицом. Наличие четкой письменной формулировки будет препятствовать подмене или отходу в процессе разработки программы от сформулированных в ТЗ требований в угоду каким-то другим побочным целям. Кроме того, письменно сформулированное задание делает возможным обсуждение, оценку или согласованную с заказчиками (пользователями) корректировку отдельных требований ТЗ в ходе разработки программы. ТЗ препятствует проникновению в программу таких ошибок и противоречий, которые могут быть обнаружены только после разработки большей части программы или уже на стадии анализа полученных результатов счета. Чем более формализованным по характеру будет техническое задание, тем больше шансов, что разрабатываемая программа будет решать именно ту задачу, которую имел в виду заказчик.
Техническое задание должно содержать также требования или указания, касающиеся принципов проверки и испытаний готовой программы.
2.3.2. Составление проекта
На основании анализа технического задания выбирается основной метод решения задачи, составляет общий проект программы. Выбранный подход к решению задачи должен обеспечивать правильные результаты для тех условий функционирования программы, которые определены ТЗ, гарантировать требуемую скорость работы, предусматривать удобство использования программы и т. п.
В проекте, помимо формулировки выбранного общего метода решения задачи, характеризуются основные части проектируемой программы, их функции, взаимосвязь и последовательность выполнения, а также точно определяются входные данные и выдаваемые результаты, как всей программы, так и основных ее частей. Поскольку каждая разрабатываемая программа, как правило, используется в дальнейшем не только ее автором, но и другими программистами, составляется и проект инструкции для пользователей, в которой фиксируется (и, таким образом, может быть заранее оценен и исправлен) предполагаемый режим общения пользователя (и оператора) с программой.
Для очень простых задач проектирование может производиться мысленно, без фиксации на бумаге. Наоборот, очень сложные задачи могут потребовать нескольких этапов проектирования: предэскизное, эскизное, техническое по аналогии с инженерным проектированием.
Замечание. Этапы 2.3.1. и 2.3.2. для несложных задач мало зависят от ЭВМ и операционной системы, с помощью которых предполагается решать задачу, а также от языка, на котором она будет программироваться; выбор ЭВМ и языка может быть произведен и на следующих этапах разработки.