Технологии программирования (Software Engineering)
Программирование (реализация)
Выбор языка программирования
Сравнительная пригодность языка программирования для данной задачи. Обзор языков, ориентированных на различные предметные области, будет сделан в разд. 4.5.2.
Избранная методология. Часто говорят, что язык поддерживает ту или иную методологию. Обычно это означает, что применение этого языка совместно с указанной методологией в совокупности дадут значительно больший эффект. Обзор языков, поддерживающих методологии, сделан в гл. 2.
Степень важности для разработчика многочисленных характеристик и свойств, которые могут быть присущи или не присущи избираемому языку программирования. Подробно характеристики будут рассмотрены в разд. 4.1.1.3.
Степень знакомства программистов с языком программирования. Результаты исследований говорят о том, что производительность программиста, работавшего на некотором языке более трех лет, возрастает на треть по сравнению с программистом такого же уровня, но без опыта работы на данном языке [Boehm 1981]. Исследование специалистов компании IBM показало даже более существенные результаты. Программисты с длительным опытом программирования на некотором языке имеют производительность в три раза большую, чем программисты с минимальным опытом программирования [Walston, Felix 1977].
Защитное программирование
Защитное программирование (defensive programming) - это такой стиль написания программ, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом [Тассел 1985].
Стиль программирования
очевидная логика;
естественные выражения;
использование соглашений, принятых в языке разработки;
осмысленные имена;
аккуратное форматирование;
развернутые комментарии;
отсутствие хитрых трюков и необычных конструкций.
Завершение эксплуатации
Процесс завершения эксплуатации программного продукта несложен, но требует тщательной организационной подготовки. Обычно процесс начинается с того, что пользователи заранее оповещаются о прекращении сопровождения программного продукта. С этого момента пользователи могут продолжать использовать продукт до тех пор, пока не наступит его моральное устаревание. Очень часто невозможность решить хотя бы одну из четырех задач сопровождения приводит к тому, что от продукта приходится отказаться.
Эксплуатация и сопровождение
Под сопровождением будем понимать все действия по повышению надежности программного продукта после завершения отладки и разработку усовершенствованных версий. Пожалуй, основным принципом сопровождения является закон Биледи (Laszlo Belady): используемый программный продукт подвергается непрерывным изменениям для поддержания его экономической выгоды [Гласе, Нуазо 1983].
Ввод программы в действие
Ввод программы в действие существенно зависит от того, была ли это разработка для конкретного заказчика или она является продуктом, рассчитанным на широкого пользователя. Существует три основных способа доставки программы до пользователя.
Тестирование и отладка
Отладка программных продуктов
Отладка программы - процесс творческий и плохоформализуемый. Тем не менее, основной идее отладки (базирующейся на анализе данных) можно придать вид следующего алгоритма:
Следует начать с изучения уже доступных исходных и результирующих данных.
Сформулировать некоторую гипотезу, которая объясняет получение таких результирующих данных.
Подготовить новые исходные данные и провести эксперимент, который позволит доказать или опровергнуть гипотезу.
Тестирование программных продуктов
Существуют две основные стратегии тестирования.
Тестирование программы как черного ящика, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.
Тестирование программы как прозрачного (белого) ящика подразумевает знание исходного кода программы и полный доступ к нему.
Существуют также разновидности тестирования.
Детерминированное тестирование, при котором контролируется каждая комбинация исходных эталонных данных и соответствующая ей комбинация результатов функционирования программ. На практике полное детерминированное тестирование обычно нереализуемо.
Стохастическое тестирование, при котором исходные тестовые данные берутся случайным образом, как правило, с использованием статистического распределения.
Ручное тестирование, которое проводится без исполнения тестируемой программы на компьютере.
Введение в тестирование и отладку
Тестирование - процесс выполнения программ с целью обнаружения факта наличия ошибок. Это классическое определение тестирования, принадлежащее Гленфорду Майерсу. Обратим внимание, в определении указан лишь один способ проведения тестирования. Существуют и методы ручного тестирования (например, инспекции и сквозные просмотры программ).
Анализ требований и проектирование
Подходы к ведению анализа и проектирования
Процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов.
Подходы, ориентированные на данные. Для таких подходов первичны входные и выходные данные, а функциональные (процедурные) компоненты вторичны.
Информационно-ориентированные подходы. Эта группа близка к предыдущей, но отличается тем, что работа ведется с неиерархическими структурами данных.
Методы анализа и построения спецификаций
основные методы ведения структурного анализа и рассмотрим подробно некоторые из них.
Диаграммы потоков данных.
Диаграммы потоков управления.
Таблицы решений.
Сети Петри.
Диаграммы зависимости.
Диаграммы декомпозиции.
Диаграммы функционального моделирования.
Проектирование модулей
Перечислим основные методы проектирования модулей для структурной методологии и рассмотрим подробно некоторые из них.
Диаграммы "сущность-связь".
Структурные карты.
Диаграммы деятельности.
Диаграммы Варнье-Орра.
Диаграммы переходов состояний.
Блок-схемы.
Схемы экранов.
Псевдокод.
Проектирование архитектуры
Проектирование архитектуры (проектирование "в большом") для структурной методологии включает следующие основные методы:
метод нисходящего проектирования;
метод восходящего проектирования;
метод расширения ядра.
Отступление "об архитектуре"
Архитектура программного продукта - это его строение как оно видно (или должно быть видно) извне его, т. е. представление программного продукта как системы, состоящей из некоторой совокупности взаимодействующих подсистем [Жоголев 1996]. В качестве таких подсистем обычно выступают отдельные программы.
Отступление "о спецификациях"
Спецификация - достаточно точное и достаточно полное описание задачи, которое человеку, участвующему в решении, написать, понять и прочесть легче, чем программу решения этой задачи на доступном ему языке программирования. Более коротко спецификацию можно определить как подробное описание некоторой работы, подлежащей выполнению.
Введение в анализ требований и проектирование
Анализ и проектирование - два достаточно близких и тесно связанных процесса. Они выполняют общую задачу, результатом которой должно стать четкое представление о системе, на основе которого будет создан программный код. Поэтому мы будем их рассматривать совместно, проводя разделение по методологиям - анализ и проектирование на основе структурной методологии и на основе объектно-ориентированной методологии.
Возникновение и исследование идеи
Постановка задачи
Основные даты
Завершение проектирования "руководства" - апрель 1998 г.
Первый вариант полного "руководства" - август 1998 г.
Список основных документов
Спецификация OpenMP.
Зависимости
Выяснить возможность подключения инженеров-разработчиков для получения информации о деталях реализации и рецензирования документации.
Выяснить право использовать фрагменты оригинальной спецификации OpenMP (это позволит сэкономить время, необходимое для разработки оригинальной части документации).
Описание технического процесса
Исследовать возможность импортирования спецификаций OpenMP непосредственно из документа.
Определить с помощью инженеров, реализующих поддержку OpenMP, какие особенности спецификации OpenMP войдут в состав текущей версии компилятора.
Разработать проект "руководства" и определить способ его распространения (совместно с группой маркетинга).
Проанализировать детали реализации, подготовить и включить в "руководство" соответствующие примеры программ.
Включить информацию о "руководстве пользователя" в документ "Новости компании Компилятор++"
Сравнительный анализ
Многие разработчики компиляторов (например, компании SGI, Sun, IBM) уже включили поддержку OpenMP. Описание OpenMP они включают как отдельные главы в руководство пользователя по компиляторам с языков С, C++, Pascal и FORTRAN. С нашей точки зрения, лучшим решением будет иметь единый документ для всех компиляторов.
Пользователи документа
Пользователь - опытный программист на языках С, C++, Pascal и FORTRAN, понимающий преимущества распараллеливания программ на многопроцессорных ЭВМ.
Описание особенностей поставки
Документ "Руководство пользователя по OpenMP" будет доступен как на сервере компании в сети Интернет, так и в бумажной копии.
Поскольку в данной реализации проекта "Волхов" не будут включены все особенности спецификации OpenMP, необходимо четко указать, какие из них будут реализованы, а какие нет.
Полная спецификация по OpenMP доступна в Интернете (http://www.openrap.org/).
Введение
Дата подготовки документа: 19 августа 1998 версия 1.3.
Название проекта: Руководство пользователя по OpenMP.
Краткий обзор
Стандарт OpenMP представляет собой набор директив, добавление которых в код, написанный для последовательного исполнения, позволяет компилятору разделить программу на подзадачи для параллельного вычисления. Появление OpenMP стало первой стандартизацией параллельного исполнения программ. Предлагается разработка документации "Руководство пользователя по OpenMP".
Одностраничный документ
Разработка руководства пользователя по OpenMP.
Современные подходы к управлению проектом
Продолжающиеся непрерывные неудачи в крупных программных проектах заставили министерство обороны США сформировать подразделение, которое получило название Сеть менеджеров по разработке программного обеспечения (Software Program Managers Network - SPMN) (http://www.spmn.com). Для этой организации были сформулированы четыре главных цели ее работы.
Методы управления проектами
В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов XX века [Филлипс, Гарсиа-Диас 1984]. С помощью этих методик руководитель проекта может:
заблаговременно планировать работу над проектом и предвидеть возможные источники затруднений и задержки выполнения его в срок;
планировать завершение работ в нужные сроки в соответствии с требуемой последовательностью выполнения заданий;
координировать и контролировать выполнение работ для соблюдения календарного графика и завершения проекта в срок.
Эволюция менеджмента
Основы менеджмента были заложены в начале XX века в европейской и американской науке. История менеджмента связана с древним Египтом и философами античности. В настоящее время можно говорить об особенностях европейского, американского, японского и российского менеджмента.
Управление проектом
В условиях развитого рынка программного обеспечения и жесткой конкуренции важнейшее значение имеют: возможность получения максимальной прибыли, сроки разработки и тесное взаимодействие с другими коллективами разработчиков.
Управление
Этот процесс длится почти весь жизненный цикл программного продукта, но поставили мы его в данном месте потому, что одним из важнейших действий управления является планирование, которое начинается вслед за принятием решения о том, что "проекту - жить".
Принятие решения о начале работы над проектом
Подтвердить или поправить все предположения, на которых базируется проект. На основании этих предположений будут делаться все дальнейшие построения.
Выявить и охарактеризовать все критические моменты в проекте. Специалисты должны указать - что не предусмотрено и к каким последствиям это может привести.
Возникновение идеи решения проблемы
приводит к ошибкам в программном продукте.
препятствует созданию или развитию программного продукта;
