- •Курс лекций
- •Лекция 1. Технология программирования - основа разработки качественных программных средств
- •1.1. Программа как формализованное описание процесса обработки данных. Понятие «программное средство».
- •Определение требований к программному средству.
- •1.3. Спецификация качества программного средства.
- •Технология программирования как технология разработки качественных программных средств.
- •. Этапы развития технологии программирования.
- •2.1. Специфика разработки программных средств.
- •Виды программных продуктов и специализация программистов
- •Лекция 2. Общие принципы разработки программных средств
- •2.2. Основные этапы решения задач на эвм и их характеристика.
- •Основные этапы решения задач на эвм и их характеристика
- •Постановка задачи.
- •Формализация задачи.
- •Построения алгоритма
- •Составление программы на языке программирования.
- •Отладка и тестирование программы
- •Разработка документации.
- •Сопровождение опытной эксплуатации.
- •2.3. .Источники ошибок в программных средствах
- •2.3.1. Интеллектуальные возможности человека
- •2.3.2. Неправильный перевод как причина ошибок в программных средствах.
- •Модель перевода.
- •Основные пути борьбы с ошибками.
- •Лекция 3. Разработка структуры программы и модульное программирование.
- •3.1. Основные классы архитектур программных средств.
- •Структура программы. Методы разработки структуры программы. Блок - схема программы
- •Модульное программирование. Основные характеристики модуля.
- •Основные характеристики программного модуля.
- •Спецификация программного модуля содержит,
- •Порядок разработки программного модуля.
- •Контроль структуры программы.
- •Лекция 5. Представление основных структур программы в языках высокого уровня
- •Основные языки программирования и их характеристика.
- •Структура данных в языках программирования высокого уровня
- •Типы данных
- •6. Лекция 6. Стандартные типы данных в языках программирования Visual Basic.
- •Простые целые и вещественные типы переменных. И операции с ними
- •Логические типы данных и операции с ними.
- •7. Лекция 7. Представление строковых типов данных, типы данных Date и Variant.
- •Строковые типы данных и функции работы сними.
- •7.1.1. Операции со строковым типом данных.
- •Переменные типа Data и стандартные функции работы с ними.
- •Лекция 8. Структуры ветвления (операторы условного перехода) и повторения ( циклы) и особенности их использования в программах.
- •Операторы ветвления
- •8.2. Структуры повторения (Циклы).
- •Лекция 9. Структурированные типы данных. Массивы и пользовательские типы данных, их использование в программах
- •Типы данных, определяемые пользователем.
- •9.1. Массивы. Статические массивы.
- •9.2. Динамические массивы
- •9.3. Функции, предназначенные для работы с массивами.
- •9.4. Типы данных, определяемые пользователем.
- •Лекция 10. Основные строительные блоки программы, процедуры и функции.
- •Процедуры, назначение, написание, размещение.
- •10.2. Процедуры обработки событий.
- •Процедуры общего назначения.
- •Вызов процедуры.
- •Выход из процедуры до ее завершения.
- •Лекция 11. Функции . Области видимости переменных, функций и процедур
- •Функции. Стандартные функции
- •Функции, создаваемые пользователем
- •Модульная конструкция программы. Модули, формы. Стандартные модули, модули класса.
- •Области видимости переменных, процедур и функций
- •Лекция 12. Хранение информации в файлах.
- •12.1. Файлы с последовательным доступом.
- •12.1. Открытие файла с последовательным доступом.
- •12.3. Чтение данных из файла с последовательным доступом.
- •12.3. Запись информации в файл с последовательным доступом.
- •12.4. Работа с файлами произвольного доступа.
- •12.5. Ввод и вывод информации записями
- •Лекция 13. Операции с файлами.
- •13.1. Операции работы с файлами
- •13.2. Установка атрибутов файлов
- •Стандартные объекты для работы с файлами.
- •13.4. Вывод информации на печать
- •Лекция 14. Методы структурного программирования. Методы доказательства и отладки программ. Вопросы:
- •Методы структурного программирования
- •14.2. Пошаговая детализация и понятие о псевдокоде.
- •Пример пошагового составления программы
- •Доказательство свойств программы.
- •14.3.1. Обоснования программ. Формализация свойств программ.
- •Свойства простых операторов.
- •Свойства основных конструкций структурного программирования.
- •14.4.4. Завершимость выполнения программы.
- •Пример доказательства свойства программы.
- •Лекция 15 Отладка программы
- •15.1. Типы ошибок в программе
- •15.2. Программные средства для обнаружения ошибок.
- •Ошибки в структуре программы.
- •Перехват и устранение ошибок
- •15.5. Инструменты отладки
- •6. Отображение значений переменных и функций.
- •Лекция 16. Обьекто - ориентированное программирование.
- •16.1. Основные понятия объекто – ориентированного программирования.
- •16.2. Стандартные объекты управления, свойства, методы, события
- •16.3. . Пользовательские элементы управления
- •Лекция 17. Применение технологии ole в программировании и завершение проекта.
- •17.1.. Применение технологии ole в программировании на языках высокого уровня
- •Объект управления ole Container
- •Технология ole Automation.
- •17.4. Состав проекта
- •Создание дистрибутива программного средства
- •Документирование программных средств
- •Аттестация программного средства.
Определение требований к программному средству.
Определение требования к ПС являются исходным документом разработки ПС - заданием, выражающем в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел ПС, характеризуют условия его использования. Неправильное понимание потребностей пользователя трансформируются в ошибки внешнего описания. Поэтому разработка ПС начинается с создания документа, достаточно полно характеризующего потребности пользователя и позволяющего разработчику адекватно воспринимать эти потребности.
Определение требований представляет собой смесь фрагментов на естественном языке, различных таблиц и диаграмм. Такая смесь, должна быть понятной пользователю, не знающего специальных программистских обозначений. Обычно в определении требований не содержится формализованных фрагментов, кроме случаев достаточно для этого подготовленных пользователей (например, математически) - формализация этих требований составляет содержание дальнейшей работы коллектива разработчиков.
Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования . Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними.
Известны три способа определения требований к ПС :
-управляемый пользователем,
-контролируемый пользователем,
-независимый от пользователя.
В управляемой пользователем разработке определения требований к ПС определяются заказчиком, представляющим организацию пользователей. Это происходит обычно в тех случаях, когда организация пользователей (заказчик) заключает договор на разработку требуемого ПС с коллективом разработчиков и требования к ПС являются частью этого договора. Роль разработчика ПС в создании этих требований сводится, в основном, в выяснении того, насколько понятны ему эти требования с соответствующей критикой рассматриваемого документа. Это может приводить к созданию нескольких редакций этого документа в процессе заключения указанного договора.
В контролируемой пользователем разработке требования к ПС формулируются разработчиком при участии представителя пользователей. Роль пользователя в этом случае сводится к информированию разработчика о своих потребностях в ПС и контролю за тем, чтобы формулируемые требования действительно выражали его потребности в ПС. В конечном счете разработанные требования, как правило, утверждаются представителем пользователя.
В независимой от пользователя разработке требования к ПС определяются без какого-либо участия пользователя (на полную ответственность разработчика). Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчете на то, что разработанное им ПС найдет спрос на рынке программных средств.
С точки зрения обеспечения надежности ПС наиболее предпочтительным является контролируемая пользователем разработка.
