
- •Лекция 1.Надежное программное средство как продукт технологии программирования
- •1.1.Программа как формализованное описание процесса обработки данных. Программное средство.
- •1.2.Неконструктивность понятия правильной программы.
- •1.3.Надежность программного средства.
- •1.4.Технология программирования как технология разработки надежных программных средств.
- •1.5. Технология программирования и информатизация общества.
- •Лекция 2.Источники ошибок в программных средствах
- •2.1.Интеллектуальные возможности человека.
- •2.2.Неправильный перевод как причина ошибок в программных средствах.
- •2.3.Модель перевода.
- •2.4.Основные пути борьбы с ошибками.
- •Лекция 3.Общие принципы разработки программных средств
- •3.1. 3.1. Специфика разработки программных средств.
- •3.2.3.2. Жизненный цикл программного средства.
- •3.3. Понятие качества программного средства.
- •3.4.Обеспечение надежности основной мотив разработки программных средств.
- •3.5. Методы борьбы со сложностью.
- •3.6. Обеспечение точности перевода.
- •3.7.Преодоление барьера между пользователем и разработчиком.
- •3.8.Контроль принимаемых решений.
- •Лекция 4.Внешнее описание программного средства
- •4.1.Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства.
- •4.2.Определение требований к программному средству.
- •4.3.Спецификация качества программного средства.
- •4.4.Функциональная спецификация программного средства.
- •4.5.Методы контроля внешнего описания программного средства.
- •Лекция 5.Методы спецификации семантики функций
- •5.1.Основные подходы к спецификации семантики функций.
- •5.2.Метод таблиц решений.
- •5.3.Операционная семантика.
- •5.4.Денотационная семантика.
- •5.5.Аксиоматическая семантика.
- •5.6.Языки спецификаций.
- •Лекция 6.Архитектура программного средства
- •6.1.Понятие архитектуры программного средства.
- •6.2.Основные классы архитектур программных средств.
- •6.3.Архитектурные функции.
- •6.4.Контроль архитектуры программных средств.
- •Лекция 7.Разработка структуры программы и модульное программирование
- •7.1.Цель модульного программирования.
- •7.2.Основные характеристики программного модуля.
- •7.3.Методы разработки структуры программы.
- •7.4. Контроль структуры программы.
- •Лекция 8.Объектный подход к разработке
- •8.1.Объекты и отношения в программировании. Сущность объектного подхода к разработке программных средств.
- •8.2.Особенности объектного подхода к разработке внешнего описания программного средства.
- •8.3.Особенности объектного подхода на этапе конструирования программного средства.
- •Лекция 9.Разработка программного модуля
- •9.1.Порядок разработки программного модуля.
- •9.2.Структурное программирование.
- •9.3.Пошаговая детализация и понятие о псевдокоде.
- •9.4.Контроль программного модуля.
- •Лекция 10.Доказательство свойств программ
- •10.1.Обоснования программ. Формализация свойств программ.
- •10.2. Свойства простых операторов.
- •10.3.Свойства основных конструкций структурного программирования.
- •10.4.Завершимость выполнения программы.
- •10.5.Пример доказательства свойства программы.
- •Лекция 11.Тестирование и отладка программного средства
- •11.1.Основные понятия.
- •11.2.Принципы и виды отладки программного средства.
- •11.3.Заповеди отладки программного средства.
- •11.4.Автономная отладка программного средства.
- •11.5.Комплексная отладка программного средства.
- •Лекция 12.Обеспечение функциональности и надежности программного средства
- •12.1.Функциональность и надежность как обязательные критерии качества программного средства.
- •12.2.Обеспечение завершенности программного средства.
- •12.3.Обеспечение точности программного средства.
- •12.4.Обеспечение автономности программного средства.
- •12.5.Обеспечение устойчивости программного средства.
- •12.6.Обеспечение защищенности программных средств.
- •12.6.1. Защита от сбоев аппаратуры.
- •12.6.2.Защита от влияния «чужой» программы.
- •12.6.3.Защита от отказов «своей» программы.
- •12.6.4.Защита от ошибок пользователя.
- •12.6.5.Защита от несанкционированного доступа.
- •12.6.6.Защита от защиты.
- •Лекция 13.Обеспечение качества программного средства
- •13.1.Общая характеристика процесса обеспечения качества программного средства.
- •13.2.Обеспечение легкости применения программного средства.
- •13.3.Обеспечение эффективности программного средства.
- •13.4.Обеспечение сопровождаемости программного средства.
- •13.5. Обеспечение мобильности.
- •Лекция 14.Документирование программных средств
- •14.1.Документация, создаваемая и используемая в процессе разработки программных средств.
- •14.2.Пользовательская документация программных средств.
- •14.3.Документация по сопровождению программных средств.
- •Лекция 15.Управление разработкой и аттестация программного средства.
- •15.1.Назначение и процессы управления разработкой программного средства.
- •15.2.Структура управления разработкой программных средств.
- •15.3.Планирование и составление расписаний по разработке пс.
- •Лекция 16.Компьютерная поддержка разработки и сопровождения программных средств
- •16.1.Инструменты разработки программных средств.
- •16.2. Инструментальные среды разработки и сопровождения программных средств и принципы их классификации.
- •16.3.Основные классы инструментальных сред разработки и сопровождения программных средств.
- •16.4. Инструментальные среды программирования.
- •16.5.Понятие компьютерной технологии разработки программных средств и ее рабочие места.
- •16.6.Инструментальные системы технологии программирования.
Лекция 15.Управление разработкой и аттестация программного средства.
Назначение управления разработкой программного средства и его основные процессы. Структура управления разработкой программных средств. Подходы к организации бригад разработчиков. Управление качеством программного средства. Аттестация программного средства и характеристика методов оценки качества программного средства.
15.1.Назначение и процессы управления разработкой программного средства.
Управление разработкой ПС (software management) – это деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков ПС, на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПС, выполнения сроков и бюджета разработки ПС [14.1, 14.2]. Часто эту деятельность называют также управлением программным проектом (software project management). Здесь под программным проектом (software project) понимают всю совокупность работ, связанную с разработкой ПС, а ход выполнения этих работ называют развитием программного проекта (software project progress). К необходимым условиям работы коллектива относятся помещения, аппаратно-программные средства разработки, документация и материально-финансовое обеспечение. Планирование и контроль предполагает разбиение всего процесса разработки ПС на отдельные конкретные работы (задания), подбор и расстановка исполнителей, установление сроков и порядка выполнения этих работ, оценка качества выполнения каждой работы. Финальной частью этой деятельности является организация и проведения аттестации (сертификации) ПС, которой завершается стадия разработки ПС. Влияние правильной расстановки исполнителей на обеспечение надежности ПС уже обсуждалось в лекции 2. Вопросы документации обсуждались в предыдущей лекции. Другие вопросы управления разработки ПС кратко обсудим в настоящей лекции.
Хотя виды деятельности по управлению разработкой ПС могут быть весьма разнообразными в зависимости от специфики разрабатываемого ПС и организации работ по его созданию, можно выделить некоторые общие процессы (виды деятельности) по управлению разработкой ПС:
составление плана-проспекта по разработке ПС;
планирование и составление расписаний по разработке ПС;
управление издержками по разработке ПС;
текущий контроль и документирование деятельности коллектива по разработке ПС.
подбор и оценка персонала коллектива разработчиков ПС.
Составление плана-проспекта по разработке ПС включает формулирование предложений о том, как выполнять разработку ПС. Прежде всего, должно быть зафиксировано, для кого разрабатывается ПС:
для внешнего заказчика,
для других подразделений той же организации,
или является инициативной внутренней разработкой.
В плане-проспекте должны быть установлены общие очертания работ по создания ПС и оценена стоимость разработки, а также предоставляемые для разработки ПС материально-финансовые ресурсы и временные ограничения. Кроме того, он должен включать обоснование, какого рода коллективом должно разрабатываться ПС (специальной организацией, отдельной бригадой и т.п.). И, наконец, должны быть сформулированы необходимые технологические требования (включая, возможно, и выбор подходящей технологии программирования).
Планирование и составление расписаний по разработке ПС – это деятельность, связанная с распределением работ между исполнителями и по времени их выполнения в рамках намеченных сроков и имеющихся ресурсов. Более подробно этот процесс будет рассмотрен в п. 14.3.
Управление издержками по разработке ПС – это деятельность, направленная на обеспечение подходящей стоимости разработки в рамках выделенного бюджета. Она включает оценивание стоимости разработки проекта в целом или отдельных его частей, контроль выполнения бюджета, выбор подходящих вариантов расходования бюджета. Эта деятельность тесно связана с планированием и составлением расписаний в течение всего периода выполнения проекта. Основными источниками издержек являются
затраты на аппаратное оборудование (hardware);
затраты на вербовку и обучение персонала;
затраты на оплату труда разработчиков.
Текущий контроль и документирование деятельности коллектива по разработке ПС – это непрерывный процесс слежения за ходом развития проекта, сравнения действительных состояния и издержек с запланированными, а также документирования различных аспектов развития проекта (см. лекцию 13). Этот процесс помогает вовремя обнаружить затруднения и предсказать возможные проблемы в развитии проекта.
Подбор и оценка персонала коллектива разработчиков ПС – это деятельность, связанная с формированием коллектива разработчиков ПС. Имеющийся в распоряжении штат разработчиков далеко не всегда будет подходящим по квалификации и опыту работы для данного проекта. Поэтому приходится, частично, вербовать подходящий персонал, а, частично, организовывать дополнительное обучение имеющихся разработчиков. В любом случае в формируемом коллективе хотя бы один его член должен иметь опыт разработки программных средств (систем), сопоставимых с ПС, который требуется разработать. Это поможет избежать многих простых ошибок в развитии проекта.