Технологии программирования (Software Engineering)

Возникновение и исследование идеи

Возникновение идеи решения проблемы

препятствует созданию или развитию программного продукта;

приводит к ошибкам в программном продукте.

Принятие решения о начале работы над проектом

Подтвердить или поправить все предположения, на которых базируется проект. На основании этих предположений будут делаться все дальнейшие построения.
Выявить и охарактеризовать все критические моменты в проекте. Специалисты должны указать - что не предусмотрено и к каким последствиям это может привести.

Управление

Этот процесс длится почти весь жизненный цикл программного продукта, но поставили мы его в данном месте потому, что одним из важнейших действий управления является планирование, которое начинается вслед за принятием решения о том, что "проекту - жить".

Управление проектом

В условиях развитого рынка программного обеспечения и жесткой конкуренции важнейшее значение имеют: возможность получения максимальной прибыли, сроки разработки и тесное взаимодействие с другими коллективами разработчиков.

Эволюция менеджмента

Основы менеджмента были заложены в начале XX века в европейской и американской науке. История менеджмента связана с древним Египтом и философами античности. В настоящее время можно говорить об особенностях европейского, американского, японского и российского менеджмента.

Методы управления проектами

В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов XX века [Филлипс, Гарсиа-Диас 1984]. С помощью этих методик руководитель проекта может:

заблаговременно планировать работу над проектом и предвидеть возможные источники затруднений и задержки выполнения его в срок;
планировать завершение работ в нужные сроки в соответствии с требуемой последовательностью выполнения заданий;
координировать и контролировать выполнение работ для соблюдения календарного графика и завершения проекта в срок.

Современные подходы к управлению проектом

Продолжающиеся непрерывные неудачи в крупных программных проектах заставили министерство обороны США сформировать подразделение, которое получило название Сеть менеджеров по разработке программного обеспечения (Software Program Managers Network - SPMN) (http://www.spmn.com). Для этой организации были сформулированы четыре главных цели ее работы.

Постановка задачи

Одностраничный документ

Разработка руководства пользователя по OpenMP.

Краткий обзор

Стандарт OpenMP представляет собой набор директив, добавление которых в код, написанный для последовательного исполнения, позволяет компилятору разделить программу на подзадачи для параллельного вычисления. Появление OpenMP стало первой стандартизацией параллельного исполнения программ. Предлагается разработка документации "Руководство пользователя по OpenMP".

Введение

Название проекта: Руководство пользователя по OpenMP.

Дата подготовки документа: 19 августа 1998 версия 1.3.

Описание особенностей поставки

Документ "Руководство пользователя по OpenMP" будет доступен как на сервере компании в сети Интернет, так и в бумажной копии.
Поскольку в данной реализации проекта "Волхов" не будут включены все особенности спецификации OpenMP, необходимо четко указать, какие из них будут реализованы, а какие нет.
Полная спецификация по OpenMP доступна в Интернете (http://www.openrap.org/).

Пользователи документа

Пользователь - опытный программист на языках С, C++, Pascal и FORTRAN, понимающий преимущества распараллеливания программ на многопроцессорных ЭВМ.

Сравнительный анализ

Многие разработчики компиляторов (например, компании SGI, Sun, IBM) уже включили поддержку OpenMP. Описание OpenMP они включают как отдельные главы в руководство пользователя по компиляторам с языков С, C++, Pascal и FORTRAN. С нашей точки зрения, лучшим решением будет иметь единый документ для всех компиляторов.

Описание технического процесса

Исследовать возможность импортирования спецификаций OpenMP непосредственно из документа.
Определить с помощью инженеров, реализующих поддержку OpenMP, какие особенности спецификации OpenMP войдут в состав текущей версии компилятора.
Разработать проект "руководства" и определить способ его распространения (совместно с группой маркетинга).
Проанализировать детали реализации, подготовить и включить в "руководство" соответствующие примеры программ.
Включить информацию о "руководстве пользователя" в документ "Новости компании Компилятор++"

Зависимости

Выяснить возможность подключения инженеров-разработчиков для получения информации о деталях реализации и рецензирования документации.
Выяснить право использовать фрагменты оригинальной спецификации OpenMP (это позволит сэкономить время, необходимое для разработки оригинальной части документации).

Список основных документов

Спецификация OpenMP.

Основные даты

Завершение проектирования "руководства" - апрель 1998 г.
Первый вариант полного "руководства" - август 1998 г.

Анализ требований и проектирование

Введение в анализ требований и проектирование

Анализ и проектирование - два достаточно близких и тесно связанных процесса. Они выполняют общую задачу, результатом которой должно стать четкое представление о системе, на основе которого будет создан программный код. Поэтому мы будем их рассматривать совместно, проводя разделение по методологиям - анализ и проектирование на основе структурной методологии и на основе объектно-ориентированной методологии.

Отступление "о спецификациях"

Спецификация - достаточно точное и достаточно полное описание задачи, которое человеку, участвующему в решении, написать, понять и прочесть легче, чем программу решения этой задачи на доступном ему языке программирования. Более коротко спецификацию можно определить как подробное описание некоторой работы, подлежащей выполнению.

Отступление "об архитектуре"

Архитектура программного продукта - это его строение как оно видно (или должно быть видно) извне его, т. е. представление программного продукта как системы, состоящей из некоторой совокупности взаимодействующих подсистем [Жоголев 1996]. В качестве таких подсистем обычно выступают отдельные программы.

Проектирование архитектуры

Проектирование архитектуры (проектирование "в большом") для структурной методологии включает следующие основные методы:

метод нисходящего проектирования;
метод восходящего проектирования;
метод расширения ядра.

Проектирование модулей

Перечислим основные методы проектирования модулей для структурной методологии и рассмотрим подробно некоторые из них.

Диаграммы "сущность-связь".
Структурные карты.
Диаграммы деятельности.
Диаграммы Варнье-Орра.
Диаграммы переходов состояний.
Блок-схемы.
Схемы экранов.
Псевдокод.

Методы анализа и построения спецификаций

основные методы ведения структурного анализа и рассмотрим подробно некоторые из них.

Диаграммы потоков данных.
Диаграммы потоков управления.
Таблицы решений.
Сети Петри.
Диаграммы зависимости.
Диаграммы декомпозиции.
Диаграммы функционального моделирования.

Подходы к ведению анализа и проектирования

Процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов.
Подходы, ориентированные на данные. Для таких подходов первичны входные и выходные данные, а функциональные (процедурные) компоненты вторичны.
Информационно-ориентированные подходы. Эта группа близка к предыдущей, но отличается тем, что работа ведется с неиерархическими структурами данных.

Тестирование и отладка

Введение в тестирование и отладку

Тестирование - процесс выполнения программ с целью обнаружения факта наличия ошибок. Это классическое определение тестирования, принадлежащее Гленфорду Майерсу. Обратим внимание, в определении указан лишь один способ проведения тестирования. Существуют и методы ручного тестирования (например, инспекции и сквозные просмотры программ).

Тестирование программных продуктов

Существуют две основные стратегии тестирования.

Тестирование программы как черного ящика, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.
Тестирование программы как прозрачного (белого) ящика подразумевает знание исходного кода программы и полный доступ к нему.
Существуют также разновидности тестирования.

Детерминированное тестирование, при котором контролируется каждая комбинация исходных эталонных данных и соответствующая ей комбинация результатов функционирования программ. На практике полное детерминированное тестирование обычно нереализуемо.
Стохастическое тестирование, при котором исходные тестовые данные берутся случайным образом, как правило, с использованием статистического распределения.
Ручное тестирование, которое проводится без исполнения тестируемой программы на компьютере.

Отладка программных продуктов

Отладка программы - процесс творческий и плохоформализуемый. Тем не менее, основной идее отладки (базирующейся на анализе данных) можно придать вид следующего алгоритма:

Следует начать с изучения уже доступных исходных и результирующих данных.
Сформулировать некоторую гипотезу, которая объясняет получение таких результирующих данных.
Подготовить новые исходные данные и провести эксперимент, который позволит доказать или опровергнуть гипотезу.

Ввод программы в действие

Ввод программы в действие существенно зависит от того, была ли это разработка для конкретного заказчика или она является продуктом, рассчитанным на широкого пользователя. Существует три основных способа доставки программы до пользователя.

Эксплуатация и сопровождение

Под сопровождением будем понимать все действия по повышению надежности программного продукта после завершения отладки и разработку усовершенствованных версий. Пожалуй, основным принципом сопровождения является закон Биледи (Laszlo Belady): используемый программный продукт подвергается непрерывным изменениям для поддержания его экономической выгоды [Гласе, Нуазо 1983].

Завершение эксплуатации

Процесс завершения эксплуатации программного продукта несложен, но требует тщательной организационной подготовки. Обычно процесс начинается с того, что пользователи заранее оповещаются о прекращении сопровождения программного продукта. С этого момента пользователи могут продолжать использовать продукт до тех пор, пока не наступит его моральное устаревание. Очень часто невозможность решить хотя бы одну из четырех задач сопровождения приводит к тому, что от продукта приходится отказаться.

Программирование (реализация)

Стиль программирования

очевидная логика;
естественные выражения;
использование соглашений, принятых в языке разработки;
осмысленные имена;
аккуратное форматирование;
развернутые комментарии;
отсутствие хитрых трюков и необычных конструкций.

Защитное программирование

Защитное программирование (defensive programming) - это такой стиль написания программ, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом [Тассел 1985].

Выбор языка программирования

Сравнительная пригодность языка программирования для данной задачи. Обзор языков, ориентированных на различные предметные области, будет сделан в разд. 4.5.2.
Избранная методология. Часто говорят, что язык поддерживает ту или иную методологию. Обычно это означает, что применение этого языка совместно с указанной методологией в совокупности дадут значительно больший эффект. Обзор языков, поддерживающих методологии, сделан в гл. 2.
Степень важности для разработчика многочисленных характеристик и свойств, которые могут быть присущи или не присущи избираемому языку программирования. Подробно характеристики будут рассмотрены в разд. 4.1.1.3.
Степень знакомства программистов с языком программирования. Результаты исследований говорят о том, что производительность программиста, работавшего на некотором языке более трех лет, возрастает на треть по сравнению с программистом такого же уровня, но без опыта работы на данном языке [Boehm 1981]. Исследование специалистов компании IBM показало даже более существенные результаты. Программисты с длительным опытом программирования на некотором языке имеют производительность в три раза большую, чем программисты с минимальным опытом программирования [Walston, Felix 1977].