arabera Вика Белых 8 months ago
66
Honelako gehiago
коммерческие программные продукты. На последние сначала можно получить временный регистрационный ключ (как правило, срок его действия около месяца), самостоятельно выяснить достоинства и недостатки продукта и принять решения о необходимости пользоваться им в дальнейшей работе. Если программный продукт подходит для пользователя, то он может получить постоянный регистрационный ключ после оплаты стоимости программного продукта.
свободно распространяемые программные продукты;
Если программа выдает некорректное сообщение, то можно получить динамический стек в отладчике, взяв за точку останова вызов функции выдачи сообщения. Стек может дать достаточное количество информации к размышлению.
Если программа прекращает работу с порождениями "предсмертного дампа памяти" (core-файла), то практически любой отладчик позволит по этому дампу восстановить динамический стек вызовов процедур и локализовать место проблемы.
Подготовить новые исходные данные и провести эксперимент, который позволит доказать или опровергнуть гипотезу.
Сформулировать некоторую гипотезу, которая объясняет получение таких результирующих данных.
Следует начать с изучения уже доступных исходных и результирующих данных.
Отслеживание ошибок
Проблема или ошибка может быть рассмотрена как некоторый объект в системе, который может находиться в одном из восьми состояний.
Подтверждено исправление ошибки.
Исправление интегрировано в основное пространство.
Выполнено исправление ошибки.
Принято решение о начале работы над исправлением.
Выполнен окончательный анализ проблемы или ошибки.
Понятна причина, вызвавшая ошибку.
Выполнен первичный анализ (эксперт подтвердил факт наличия ошибки).
Проблема или ошибка зарегистрирована.
Тестирование программ в процессе разработки
Поскольку в процессе разработки приходится тестировать еще не завершенную программу, все подходы к тестированию делятся на две группы.
Тестирование снизу вверх. При этом, как правило, дополнительно должна быть создана небольшая программа - "драйвер", организующая взаимодействие уже написанных модулей.
Тестирование сверху вниз. Применяется, если программа разрабатывается сверху вниз. В данном случае используются "заглушки" - фрагменты кода, имитирующие еще не написанные части программы.
Тестовое покрытие - это набор тестов, покрывающих программу (каждый линейный участок). Тестовое покрытие важно знать, чтобы определить участки кода, пропущенные при тестировании
Для оценки результатов тестирования используются эталонные ("золотые") файлы, которые содержат ожидаемые результаты работы программы (эталонные результаты). Основные варианты получения эталонных результатов таковы:
использование результатов, полученных при помощи другой программы, которой мы доверяем.
вычисление вручную;
использование справочников;
Для тестирования программ методом черного ящика [Канер, Фолк, Нгуен 2000] готовятся определенные группы тестов.
Для тестирования тех утверждений, которые приводятся в документации.
Для анализа причинно-следственных связей. Эти тесты применяются для программ, в которых взаимодействуют объекты.
Для тестирования граничных значений.
Для тестирования классов эквивалентностей. Классы эквивалентностей позволяют вместо большого количества тестов использовать лишь их небольшое подмножество. Каждый тест представляет набор тестов, на которых программа ведет себя одинаково. Существует два основных типа классов эквивалентностей.
Класс тестов, содержащих ненормальную ситуацию, т. е. описывающих ситуацию, которой быть не должно.
Класс корректных тестовых случаев, отражающих типичную "нормальную" ситуацию.
Обратим внимание на две категории наиболее распространенных ошибок программистов.
Ошибки специального вида, особенно трудные для диагностирования.
Исчезающие ошибки.
Ошибки, связанные с неправильным результатом операций.
Ошибки, связанные с применением препроцессора.
Ошибки при написании параллельных программ. Например, ошибки в расстановках семафоров.
Ошибки общего (несинтаксического) характера, остающиеся в программах после выполнения синтаксического контроля.
Отсутствие начального обнуления элементов.
Ошибки при работе с массивами.
Ошибки в описании переменной. Например, отсутствие инициализации переменной.
Ошибки ввода-вывода.
Ошибки при работе с данными.
Ошибки в циклах. Например, неверные границы начала и конца.
Группа логических ошибок. Например, неполный учет возможных условий или неверное указание ветви алгоритма после проверки условия.
Ручное тестирование, которое проводится без исполнения тестируемой программы на компьютере.
Стохастическое тестирование, при котором исходные тестовые данные берутся случайным образом, как правило, с использованием статистического распределения.
Детерминированное тестирование, при котором контролируется каждая комбинация исходных эталонных данных и соответствующая ей комбинация результатов функционирования программ. На практике полное детерминированное тестирование обычно нереализуемо.
Тестирование программы как прозрачного (белого) ящика подразумевает знание исходного кода программы и полный доступ к нему.
Тестирование программы как черного ящика, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.
Степень знакомства программистов с языком программирования. Результаты исследований говорят о том, что производительность программиста, работавшего на некотором языке более трех лет, возрастает на треть по сравнению с программистом такого же уровня, но без опыта работы на данном языке [Boehm 1981]. Исследование специалистов компании IBM показало даже более существенные результаты. Программисты с длительным опытом программирования на некотором языке имеют производительность в три раза большую, чем программисты с минимальным опытом программирования [Walston, Felix 1977].
Степень важности для разработчика многочисленных характеристик и свойств, которые могут быть присущи или не присущи избираемому языку программирования.
Избранная методология. Часто говорят, что язык поддерживает ту или иную методологию. Обычно это означает, что применение этого языка совместно с указанной методологией в совокупности дадут значительно больший эффект.
Сравнительная пригодность языка программирования для данной задачи.
Проверяйте коды возврата функций.
Проверяйте длину элементов информации.
Включайте автоматические проверки (например, контроль переполнения или потери точности).
Контролируйте итоги вычислений.
Выполняйте контроль правдоподобности значений переменных, которые не должны превышать некоторых констант или значений других переменных.
Делайте проверку области значений переменных.
Изолирование ошибки. Ошибки в одном модуле должны быть изолированы так, чтобы не допустить их влияние на другие модули.
Немедленное обнаружение. Каждая ошибка должна быть выявлена как можно раньше, это упрощает установление ее причины.
Общее недоверие. Для каждого модуля входные данные должны тщательно анализироваться в предположении, что они могут быть ошибочными.
Рекомендации по написанию определения функций.
Если часть then или else состоит из простого оператора, то открывающая и закрывающая фигурные скобки могут быть опущены.
Если условие не помещается на одной строке, то его продолжение на следующей строке должно начинаться в том же столбце, что и первый символ выражения первой строки.
Закрывающая фигурная скобка находится на том же уровне отступа, что и начало условного оператора.
Открывающая фигурная скобка должна находиться на той же строке, что и закрывающая круглая.
По одному пробелу следует оставлять перед и после круглых скобок условия.
Различные части функции следует отделять пустой строкой. Рекомендации по написанию условного оператора.
Определение функции всегда начинается в самом левом столбце файла.
Если функция статическая, то ключевое слово static должно быть вынесено в строку, предшествующую заголовку функции.
Заголовок состоит из типа возвращаемого функцией значения, пробела, имени функции, за которым без пробела следует открывающая круглая скобка для списка параметров.
Открывающая и закрывающая фигурные скобки, определяющие тело функции, располагаются в первом столбце строк.
Определение должно начинаться заголовком функции, за которым идут комментарий, описывающий назначение функции, и собственно тело функции.
Рекомендации по объявлению переменных.
Если переменная является указателем, то символ * следует присоединять к типу.
За типом переменной должны следовать пробел, имя переменной и комментарий с кратким описанием переменной.
Объявление переменной должно занимать одну строку.
В каждом объявлении должна объявляться только одна переменная.
Рекомендации по написанию выражений.
Если выражение переносится на следующую строку, то знак бинарной операции следует оставить на первой строке.
Старайтесь размещать выражение на одной строке.
Используйте скобки, чтобы улучшить читаемость. Не следует добавлять пробелы к введенным скобкам.
Унарные операторы не следует отделять от операнда пробелом, если только этого не требуют правила языка.
Бинарные операторы должны быть отделены от операндов одним пробелом.
Рекомендации по выравниванию.
Табуляционный отступ равен восьми пробелам.
Стандартная величина отступа равна четырем пробелам.
Строковые комментарии следует использовать для коротких заметок в одну-две строки.
Блочные комментарии следует применять для описания дополнительной информации о файле, классе, функции или переменной.
Имена перечислимых типов могут иметь единый префикс. Приведем рекомендации по употреблению комментариев.
Имена функций должны быть активными, т. е. базироваться на активном глаголе, за которым следует существительное.
Длинные имена могут быть сокращены. Следует придерживаться либо удаления несущественных суффиксов, либо удаления всех гласных букв кроме начальной, либо использования нескольких первых букв слова.
Имена, используемые в ограниченном контексте, могут быть очень короткими. Традиционно имена i и j используются для обозначения счетчиков, р и q для указателей, s для строковых, a ch для литерных переменных. В данном случае ясность достигается краткостью.
Смысл всех имен должен быть понятен при чтении программы.
Идентификаторы должны начинаться со строчной буквы. Опишем соглашения об именовании.
Разделяйте части идентификаторов символом подчеркивания, а не написанием с большой буквы очередной части идентификатора.
Не следует в одной и той же программе использовать имена, различающиеся лишь написанием букв - строчной или прописной.
Не используйте идентификаторы, состоящие только из прописных букв. Исключения составляют имена констант и макроопределений.
Не начинайте и не заканчивайте идентификаторы символом подчеркивания.
Далее представлены рекомендации по организации файлов.
Для файлов кода на языке C++ рекомендуется такая последовательность:
импортируемые интерфейсы;
комментарий к файлу;
Следует соблюдать следующий порядок в заголовочных файлах программы на языке C++:
завершающая защитную проверку директива условной компиляции
объявления;
импортируемые интерфейсы. Как правило, они определяются с помощью tinciude-директив;
защитная проверка, гарантирующая компиляцию данного файла один единственный раз, вне зависимости от числа его включений в модуль компиляции.
комментарий к файлу, который оформляется как блочный комментарий. Комментарий может начинаться указанием на лицензию, которая определяет права собственности на данный файл. Комментарий обычно продолжается идентификационной строкой системы управления версиями файлов. Например, для утилиты SCCS (см. 'разд. 5.6.1.1) строка может выглядеть так: %Z%%M% %I% %E% и включать символы идентификации SCCS, имя файла, номер версии и дату последней модификации. Комментарий должен содержать краткое описание файла;
Опишем рекомендации по длине строк.
Лучше всего, если длина строк программы значительно короче 80 символов.
Строки не должны быть длиннее 80 символов. Обоснование: Многие текстовые редакторы и системы печати текстов программ ориентированы именно на это максимальное количество символов в строке. Исторически это объясняется текстовым режимом отображения символов на экране: 25 строк по 80 символов.
Приведем рекомендации по именованию файлов.
Все файлы должны иметь различные имена, даже если они находятся в разных каталогах.
Имена файлов должны отличаться уже первыми восемью символами. Обоснование: Некоторые устаревшие, но, тем не менее, широко используемые операционные системы накладывают ограничения на длину имени файлов.
Заголовочные файлы должны иметь расширение h. Файлы с программой на языке С должны иметь расширение с, а с программой на языке C++ - ее (в операционной системе Unix) или cpp (в операционной системе Windows).
отсутствие хитрых трюков и необычных конструкций.
развернутые комментарии;
аккуратное форматирование;
осмысленные имена;
использование соглашений, принятых в языке разработки;
естественные выражения;
очевидная логика;
Таймер, обеспечивающий механизм функционирования таймеров на основе аппаратных средств, доступных для хранения следа времени.
Активный экземпляр. Это абстрактный класс, из которого все экземпляры, имеющие модель состояний, наследуют их текущее состояние.
Конечная модель состояний, связывающая все экземпляры перехода, которые составляют одну модель состояний.
Переход, описывающий каждый переход для всех моделей состояний в программе.
Моделирование процессов - для определения функций, которые система должна выполнить. Используются:
диаграммы последовательности.
Моделирование состояний - для определения, зависящего от времени поведения системы. Используются диаграммы состояний.
Информационное моделирование - для определения отношений между данными (информацией). При этом используется один тип диаграмм: Диаграммы классов.
80% проектов можно воплотить, используя 20% средств языка UML. Как правило, наиболее часто используют диаграммы классов и диаграммы деятельности.
не следует стремиться к построению диаграмм всей системы;
диаграммы кооперации.
диаграммы деятельности.
две диаграммы реализации:
диаграммы развертывания.
диаграммы компонентов;
три диаграммы поведения (две последние из них также называют диаграммами взаимодействия):
диаграммы кооперации;
диаграммы последовательности;
диаграммы деятельности;
диаграммы состояний;
диаграммы классов;
диаграммы вариантов использования;
Перечислим основные подходы к ведению объектно-ориентированного анализа и проектирования и рассмотрим подробно некоторые из них.
Подход Ивара Якобсона (Object-Oriented Software Engineering - OOSE).
Подход Джеймса Рамбо (Object Modelling Technique - ОМТ).
Подход Град и Буча.
Подход Шлеер-Меллора.
Подход на основе языка UML.
Подход Джексона (Michael Jackson) ориентирован на данные. Базовая процедура проектирования включает четыре этапа [Калянов 1996], [Кинг 1991].
Этап проектирования текстов. Трансляция построенной модели программы в текстовый вид с добавлением ряда логических условий для управления выполнением циклов и выбором данных.
Этап проектирования операций. Построение списка операций, необходимых для продуцирования выходных структур данных из входных. Назначение операций компонентам структуры программы.
Этап проектирования программ. Формирование структуры программы комбинированием структур данных. Идентификация всех связей между компонентами структур данных.
Этап проектирования данных. Построение системной сетевой диаграммы, демонстрирующей все хранилища, источники и стоки данных в программе. Представление каждой входной и выходной структуры данных древовидной структурной диаграммой.
Подход Гейна-Сарсона (Chris Gane and Tom Sarson) очень близок к предыдущему. Статистика утверждает, что он применяется в 20,2% случаев [Калянов 1996]. Главной отличительной чертой подхода является наличие этапа моделирования данных, определяющего содержимое хранилищ данных в диаграммах потоков данных в третьей нормальной форме. Этот этап включает:
представление всей информации по модели в виде связанных нормализованных таблиц.
анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных;
построение списка элементов данных, располагающихся в каждом хранилище данных;
В нем интегрированы следующие средства:
мини-спецификации обработки, описывающие процессы нижнего уровня. Фактически, мини-спецификации представляют собой алгоритмы описания задач, выполняемых процессами.
словари данных, являющиеся каталогами всех элементов данных, присутствующих в диаграммах потоков данных;
диаграммы потоков данных;
Перечислим основные подходы к ведению структурного анализа и проектирования и рассмотрим подробно некоторые из них.
Подход промышленного метода Oracle.
Подход промышленной технологии DATARUN.
Подход Мартина.
Подход Варнье-Орра.
Подход Джексона.
Подход Константайна.
Подход Гейна-Сарсона.
Подход Йордона и ДеМарко.
Как правило, подходы используют две основные группы средств моделирования [Вендров 2000].
Диаграммы, моделирующие данные и их отношения. Например, диаграммы "сущность-связь".
Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между функциями, например, диаграммы потоков данных и функционального моделирования.
Итак, комбинации структурных методов образуют структурные подходы. Можно выделить три группы структурных подходов на основе порядка построения модели [Калянов 1996].
Информационно-ориентированные подходы. Эта группа близка к предыдущей, но отличается тем, что работа ведется с неиерархическими структурами данных.
Подходы, ориентированные на данные. Для таких подходов первичны входные и выходные данные, а функциональные (процедурные) компоненты вторичны.
Процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов.
Существуют четыре разновидности сообщений.
Для возврата из вызову процедуры.
Для асинхронного сообщения между двумя объектами в некоторой процедурной последовательности.
Для обозначения простого (не вложенного) потока управления.
Для вызова процедур, выполнения операций или обозначения отдельных вложенных потоков управления.
Диаграмма имеет два измерения.
Сверху вниз, в виде вертикальных линий, представляющих линию жизни отдельного объекта. Линия жизни - время, в течение которого объект существует в системе.
Слева направо, в виде линий жизни каждого объекта, участвующего во взаимодействии. Есть начальный момент времени - верхняя часть диаграммы, где указываются имена объектов.
Процессы могут быть объединены в четыре основных группы.
Процессы проверки, которые проверяют условие и исполняют один из нескольких условных выводов управления.
Процессы преобразования, основной целью которых является вычисление или преобразование данных.
Генераторы событий, создающие событие, как результат работы.
Процессы доступа, единственная цель которых заключается в получении доступа к элементам одного архива данных объекта.
Для представления этого жизненного цикла предлагается модель состояний, состоящая из:
множества действий; действие - это деятельность или операция, которая должна быть выполнена экземпляром, когда он переходит в некоторое состояние.
множества правил переходов; правила определяют, какое новое состояние достигается, когда с объектом в данном состоянии происходит некоторое событие;
множества событий; событие - абстракция инцидента или сигнала в реальном мире, который сообщает о перемещении чего-либо в новое состояние;
множества состояний; состояние - положение объекта, в котором применяется определенный набор правил, линий поведения, предписаний и физических законов;
Диаграмма состояний (statechart diagram) отражает модель поведения объектов в реальном или абстрактном мире. Все объекты имеют некоторый срок жизни:
и, наконец, исчезают или умирают.
затем эволюционируют, проходя через определенные стадии существования;
сначала они появляются или создаются;
Диаграмма вариантов использования (use case diagram) - сценарий, позволяющий лучше понять требования к системе. В состав диаграммы входят:
интерфейс - спецификация параметров системы, которые видимы извне без указания их внутренней структуры.
актер (actor) - любая внешняя по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функции и возможности;
вариант использования (use case) - типичное взаимодействие пользователя и системы. Оно охватывает некоторую очевидную для пользователя функцию, решая некоторую дискретную задачу;
Класс служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношением с объектами из других классов. Между классами существуют четыре типа отношений.
Агрегации (часть-целое), когда один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности.
Зависимости, когда изменение одного элемента может потребовать изменения другого.
Обобщения, представляющие иерархическое строение и наследование классов.
Ассоциации, представляющие некоторое отношение или связь.
Карты класс-ответственность-кооперация (class-responsibility-collaboration) предназначены для описания классов. Первоначально они были созданы для обучения объектному языку
Кооперация - ссылка на другие классы, с которыми необходимо кооперироваться для реализации функций. С помощью коопераций можно получить представление о связях между классами.
Ответственность - это высокоуровневое описание функций, которые выполняет класс. Здесь применяется идея отказаться от описания конкретных элементов данных и процессов и вместо этого несколькими предложениями описать ответственность класса.
Перечислим основные методы ведения объектно-ориентированного анализа и рассмотрим подробно некоторые из них.
Диаграммы последовательности.
Диаграммы состояний.
Диаграммы классов.
Диаграммы вариантов использования.
КОК-карты (класс-ответственность-кооперация).
В состав диаграммы входят:
дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между ними. Место соединения дуги с блоком определяет тип интерфейса:
механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
результаты (выходная информация) показаны с правой стороны;
входная информация, подвергающаяся обработке, показана с левой стороны блока;
управляющая информация входит в блок сверху;
блоки, изображающие активность моделируемой системы;
Компонентами диаграммы потоков данных являются:
поток данных - механизм, определяющий информацию, передаваемую через некоторое соединение от источника к приемнику.
накопители данных - абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь;
процессы - совокупность операций по преобразованию входных данных в выходные в соответствии с определенным алгоритмом;
внешние сущности - материальный предмет или физическое лицо, представляющее собой источник или приемник информации;
Перечислим основные методы ведения структурного анализа и рассмотрим подробно некоторые из них.
Диаграммы функционального моделирования.
Диаграммы декомпозиции.
Диаграммы зависимости.
Сети Петри.
Таблицы решений.
Диаграммы потоков управления.
Диаграммы потоков данных.
Кооперация служит для обозначения множества взаимодействующих с определенной целью объектов. Кооперация может быть представлена на двух уровнях.
Примеров, указывая экземпляры и связи, образующие отдельные роли в кооперации.
Спецификации, показывая роли классификаторов и ассоциаций в рассматриваемом взаимодействии.
Перечислим основные методы проектирования модулей для объектно-ориентированной методологии и рассмотрим подробно некоторые из них.
Диаграммы развертывания.
Диаграммы компонентов.
Диаграммы кооперации.
При создании таких моделей рассматривают понятия:
Атрибут - абстракция одной характеристики, которой обладают все абстрагируемые как объект сущности. Атрибуты бывают:
вспомогательные - для связи экземпляра одного объекта с экземпляром другого.
указательные - для дачи имени или обозначения экземпляру;
описательные - представляющие факты, внутренне присущие каждому экземпляру объекта;
Связи используются для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Для большинства приложений достаточно использовать следующие типы отношений:
M:N (многие-ко-многим);
1:М (один-ко-многим);
1:1 (один-к-одному);
Отношение связывает две или большее количество сущностей. Отношение всегда выражается действием, и его именуют с помощью глагола. Выделяют следующие типы отношений:
существенно-ограниченное отношение используется, когда соответствующие сущности взаимозависимы в системе.
ограниченное отношение представляет собой условное отношение между сущностями;
неограниченное отношение представляет собой безусловное отношение, которое существует до тех пор, пока существуют относящиеся к делу сущности;
Сущность - это такая абстракция множества объектов реального мира, в которой все предметы этого множества имеют одинаковые характеристики и согласованы с одним и тем же набором правил и линий поведения. Выделяют следующие типы сущностей:
ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.
зависимая сущность представляет данные, зависящие от других сущностей в системе. Она всегда имеет отношения с другими сущностями;
независимая сущность представляет независимые данные, которые всегда присутствуют в системе. Отношения с другими сущностями у нее могут отсутствовать;
Перечислим основные методы проектирования модулей для структурной методологии и рассмотрим подробно некоторые из них.
Псевдокод.
Схемы экранов.
Блок-схемы.
Диаграммы переходов состояний.
Диаграммы Варнье-Орра.
Диаграммы деятельности.
Структурные карты.
Диаграммы "сущность-связь".
Проектирование архитектуры для объектно-ориентированной методологии включает следующие основные методы [Шлеер, Меллор 1993]:
метод наведения мостов.
метод проектирования предметных областей;
Метод нисходящего проектирования представляет собой подход функциональной декомпозиции на основе двух стратегий.
Анализа сообщений - при котором анализируются потоки данных, обрабатываемые модулями.
Пошагового уточнения - при котором на каждом следующем этапе декомпозиции определяются модули очередного, более низкого уровня.
Проектирование архитектуры (проектирование "в большом") для структурной методологии включает следующие основные методы:
метод расширения ядра.
метод восходящего проектирования;
метод нисходящего проектирования;
Явления, ненаблюдаемые в обществе воспитанных людей (например, ковыряние в носу).
Явления, ненаблюдаемые в природе (например, потомство от стерильных кроликов).
Явления, ненаблюдаемые в принципе (например, абсолютная скорость).
Явления, ненаблюдаемые по определению (например, невидимый свет).
Взаимодействия - объекты, получающиеся из отношения между другими объектами.
Инциденты - абстракции чего-то произошедшего или случившегося.
Роли - абстракции цели или назначения человека, части оборудования или организации.
Реальные объекты - абстракции фактически существующих предметов в физическом мире.
Вызов с возвратом:
слойный.
объектно-ориентированный;
главная программа и подпрограммы;
Виртуальные машины:
системы с правилами.
интерпретатор;
Централизованные данные:
классная доска.
хранилище;
Поток данных:
каналы и фильтры.
пакетно-последовательный;
Независимые компоненты:
системы с событиями: неявный вызов и явный вызов.
взаимодействующие процессы;
Структура классов.
Структура использования.
Структура потоков управления.
Структура потоков данных.
Структура вызовов.
Физическая структура, определяющая отображение элементов программного средства на аппаратное обеспечение.
Процессная структура, описывающая поведение системы во время ее исполнения.
Модульная структура, определяющая организацию программного средства как совокупности модулей - программных единиц, с которыми могут быть соотнесены рабочие задания, выполняемые членами проектной команды.
Логическая (концептуальная) структура, включающая множество абстракций, необходимых для описания функциональных требований к системе на абстрактном уровне (уровне, не затрагивающем вопросы реализации). Данная структура строится на основе анализа проблемной области.
коллектив параллельно выполняемых программ.
слоистая программная система;
комплекс автономно выполняемых программ;
цельная (монолитная) программа;
архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, .их интерфейсы, кооперации и способ их объединения.
составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
поведения этих элементов, определенного в процессе взаимодействия с другими элементами;
выбора структурных элементов, составляющих систему, и их интерфейсов;
организации программной системы;
Представление с помощью информационных объектов. Как правило, таким способом представляются модельные спецификации.
Текстовое представление, которое подходит для словесных и формальных спецификаций.
Формальные спецификации, получаемые строгим формальным способом с использованием математических формализмов, которые обеспечивают полное определение семантики.
Модельные (структурированные) спецификации, которые предполагают построение схем, диаграмм, других информационных структур.
Словесные спецификации, обработка которых может осуществляться обычным текстовым редактором.
Эксплуатационные спецификации, описывающие скорость работы программы, используемые ресурсы, характеристики аппаратуры, специальные требования к надежности и безопасности.
Функциональные спецификации, описывающие функцию программы.
Объектная декомпозиция рассматривает структуру объектов и связей между ними, а также поведение системы в терминах обмена сообщений между объектами.
Структурная (функциональная) декомпозиция рассматривает структуру системы в терминах иерархии функций и передачи информации.
Детальное проектирование (проектирование модулей, проектирование "в малом").
Проектирование архитектуры (проектирование системы, проектирование "в большом").
Необходимость соответствия популярному диалекту языка. Как это ни печально, но иногда даже полностью соответствующий стандарту компилятор должен допускать (в специально задаваемом пользователем режиме) обработку конструкций, допускаемых другим популярным компилятором. Обычно это диктуется соображениями экономической выгоды.
Необходимость соответствия стандарту языка. В случае изменения стандарта или появления комментариев к стандарту, компилятор должен все эти изменения учитывать.
Повышение надежности. Информацию к размышлению здесь можно получить после обработки программы на языке С утилитой расширенного синтаксического анализа lint или утилитой поиска ошибок времени исполнения bcheck.
Повышение эффективности. Например, оптимизация алгоритмов семантического анализа.
Изменения во взаимозависимых компонентах. Например, разработка инкрементального редактора связей, позволяющего вносить незначительные исправления в текст программы и продолжать исполнение без полной перекомпиляции.
Изменения в операционной системе. Например, операционная система может начать поддерживать многопоточное исполнение, начиная с некоторой версии.
Архитектурные изменения. Например, важнейшим типом адаптации является перенос компилятора на другую архитектуру.
если все одобрят изменение (в случае активного сопротивления).
если никто из коллег не выступит против (в случае пассивного сопротивления);
Ответственность и подотчетность руководства перед сотрудниками. Такая мотивация сотрудников может значительно повысить производительность труда программистов.
Конфигурационное управление. Использование систем управления исходными кодами, позволяющих отслеживать изменения и дающих возможность вернуться к предыдущим версиям.
Отслеживание причин возникновения ошибок для достижения высокого качества. Ошибки должны быть формально отслеживаемы, каждый случай обнаружения и устранения ошибки должен быть обязательно документирован.
Свободный доступ к информации о ходе проекта. Проект будет испытывать большие трудности, если менеджер скрывает от остальной команды информацию о состоянии проекта.
Контроль качества на детальном уровне. Промежуточные итоги должны подводиться еженедельно или даже ежедневно.
Планирование и управление на основе метрик. В основу планов и оценок должны быть положены числовые оценки - метрики, накопленные в предыдущих проектах.
Формальные проверки проекта. Экспертизы, проверки, сквозной контроль - все те действия, которые позволяют устранить ошибки как можно раньше.
Согласованность интерфейсов. Интерфейсы - необходимая часть архитектуры. Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется проектировать заново.
Формальное управление рисками. Рекомендуется постоянно вести и анализировать списки основных важнейших рисков. У сотрудников не должно быть никаких иллюзий о допустимости рисков.
Дать возможность быстро изучить и внедрить эти навыки в свою работу с помощью соответствующих методик обучения и программных систем.
Дать возможность руководителям проектов применять лучшие мировые практические навыки с учетом локальной корпоративной культуры.
Дать возможность руководителям проектов сфокусировать свои усилия на разработке качественного программного обеспечения, нежели на следовании должностным инструкциям и формальным методикам, которые только ухудшали состояние проекта.
Внедрить лучшие практические навыки создания программного обеспечения.
Не перегружать исполнителей задачами, для исполнения которых потребуется больше времени, чем есть в реальности.
Определить последовательность работ для каждого исполнителя.
Назначать опытных и квалифицированных людей на наиболее сложные задачи в критическом пути. Людей с меньшим количеством опыта - на менее сложные задачи и т. д.
Методика приближенных вычислений. Существует несколько расчетных формул для времен выполнения задач проекта. Введем три оценочных времени - оптимистичное (О), реальное (Р) и пессимистичное (П). Тогда время выполнения задач проекта можно вычислить по:
формуле Симпсона: (О+4*Р+П/б.
формуле трапеций: (O+2*Р+П/4;
Методика исторических соотношений. Стоимость одного проекта относится к стоимости другого пропорционально отношению их объемов в некоторой степени п. Степень n - число, которое надо знать или подобрать опытным путем.
Методика норм работы. Учет ведется по нормам, определяемым как среднее значение времени, уходящее на данную работу в данной компании. Например, время, уходящее на разработку одной строки машинного кода.
Снизу вверх по составленному графику работ. Данные по трудозатратам и времени берем от исполнителей.
Сверху вниз по крупным блокам аналогичного проекта. Поскольку аналогичный проект пройден и мы знаем реальные затраты для него, то для нового проекта берем соответствующие цифры с некоторыми поправками.
В рамках планирования управляющий решает также организационные задачи:
Определение интерфейсов приложения и планирование работ по детальному проектированию интерфейсов.
Назначение начальной и конечной дат работ.
Анализ документации на полноту, содержание, аккуратность.
Планирование проекта включает определение ресурсов - человеческих, вычислительных и организационных и составление "карты" задач и времен их выполнения. В стандартном наборе процессов планирование является одним из действий процесса управления. Общий подход к планированию выглядит так:
Создание инфраструктуры управления.
Выявление критических путей.
Оценка рисков, связанных с конкретными задачами.
Определение времени выполнения задачи.
Проведение персональных назначений на задачи.
Определение зависимостей между задачами.
Распределение ответственности.
Выделение требуемых ресурсов.
Оценка затрат.
Составление графиков выполнения работ.
Построение списка задач.
Подчеркнем в виде неформальных требований необходимость наличия плана [Баранов 1998].
С помощью плана мы видим, когда цель, поставленная перед проектом, достигнута и проект заканчивается.
План - это точка отсчета для любых последующих изменений.
План увязывает части работ вместе. План позволяет видеть все взаимозависимости между разными частями работы.
План определяет роль каждого человека в исполнении проекта.
План помогает создать ясное и четкое понимание - как будущие работы будут выполняться.
Метод анализа и оценки программ ПЕРТ (PERT - Program Evaluation and Review Technique). Метод был разработан корпорацией "Локхид" и консалтинговой фирмой "Буз, Аллен энд Гамильтон" и применен в военно-морских силах США для ускорения разработки баллистической ракеты "Поларис" для подводных лодок.
Метод Критического Пути (МКП). Метод разработан фирмой "Дюпон де Немур". Первоначально назывался методом Уолкера-Келли, по именам создателей. Позже получил название МКП (СРМ - Critical Path Method).
координировать и контролировать выполнение работ для соблюдения календарного графика и завершения проекта в срок.
планировать завершение работ в нужные сроки в соответствии с требуемой последовательностью выполнения заданий;
заблаговременно планировать работу над проектом и предвидеть возможные источники затруднений и задержки выполнения его в срок;
Духовность и психическое здоровье в основе деловой и поведенческой практики.
Профессионализм и мастерство. Коллективизм, поддержка и взаимопомощь.
Справедливость, основанная на понимании и принятии правовых норм.
Согласие и сотрудничество в обществе.
Честь и достоинство личности.
Социальные права личности.
Партнерство и сотрудничество в производственных отношениях.
Группа важнее отдельной личности. Этот принцип основан на традиционной японской ценности - никто не должен быть эгоистичным и думать только о себе.
Рабочие образуют "семью". Методы реализации принципа:
взаимные обязательства фирмы и рабочих. Если сотрудник фирмы вступает в брак или у него рождается ребенок, то он получает денежную прибавку, поскольку его расходы возросли.
свободное время работники фирмы проводят вместе;
работники фирмы оказывают новичку помощь, сочувствие и поддержку, ожидая от него в дальнейшем проявления такого же поведения по отношению к ним;
Рабочий стремится сделать свою работу лучше. Методы реализации этого принципа:
премирование рабочих в случае повышения прибыли фирмы. Заметим, что в неблагоприятной ситуации руководящий состав получает значительно более урезанную зарплату, чем рабочие.
пожизненный найм работников;
Рабочий достаточно разумен, он самостоятельно увеличивает производительность и качество своего труда. Три административных метода помогают претворить этот принцип в жизнь:
практика перевода рабочих с одного места на другое. Работник повышает квалификацию, меняет специализацию и продвигается по служебной лестнице.
практика стимулирования всех работников к совершенствованию профессиональных умений и навыков. Здесь очень интересно то, что японская традиция "минарай" - наблюдение за опытными рабочими с целью освоения их навыков - очень близка русской традиции наставничества;
кружки качества;
Контролируй исполнение.
Разделяй обязанности среди подчиненных.
Анализируй состояние инженеров, запросы рынка, процесс создания программного продукта.
Подчиненность личных интересов общим. Интересы отдельного работника или группы не должны превалировать над интересами компании.
Корпоративный дух, т. е. гармония персонала, его сплочение.
Справедливость: сочетание доброты и правосудия.
Вознаграждение персонала, в том числе справедливая зарплата.
Дисциплина, т. е. послушание и уважение к достигнутым соглашениям между фирмой и ее работниками. Дисциплина предполагает также справедливо применяемые санкции.
Потребность в самовыражении, заключающаяся в самореализации и росте как личности.
Потребности в уважении, включающие внутренние и внешние факторы уважения.
Социальные потребности, заключающиеся в привязанности, принадлежности к какой-либо общности, одобрении со стороны других, дружбе.
Потребности в безопасности, включающие потребности в защите от физических и психологических опасностей и уверенность в выполнении в будущем физиологических потребностей.
Физиологические потребности, являющиеся необходимыми для выживания.
Вторичные, являющиеся психологическими.
Первичные, являющиеся физиологическими по своей природе.
Когнитивная теория - рациональное поведение людей в соответствии с тем, что они думают о будущем. Менеджер может сформировать у работников впечатление о выгодности определенного поведения у подчиненных.
Концепция побуждений - формирование привычек на основе действий, которые приводили к удовлетворяющему результату в прошлом.
Инстинкты - автоматическая предрасположенность людей вести себя определенным образом. Некоторые люди находят удовольствие в том, чтобы ходить на работу, поскольку "рождены работать".
Гедонизм - заинтересованность людей делать то, что им приятно и уклоняться от того, что им неприятно. Менеджер может создать приятную обстановку на работе и таким образом мотивировать подчиненных.
Еще раз обратимся к понятию "проект" и выделим четыре характеристики, делающих деятельность - проектом [Баранов].
Уникальность и важность. Уникальность должна объяснять - почему надо создавать данный программный продукт, почему нельзя взять что-то готовое. Элемент важности должен демонстрировать - почему разрабатываемый продукт нужен и важен заказчику, какие нужды и потребности заказчика он покрывает.
Ограниченная протяженность во времени с определенным началом и концом. Проект имеет определенный срок. Иногда этот срок плавающий, например, начинающийся от некоторой еще не определенной даты вступления договора в силу. Проект существует столько времени, сколько его требуется для получения конечного результата.
Координированное выполнение взаимосвязанных действий. Здесь следует еще раз вспомнить сложность разработки программного продукта. Взаимосвязи в проекте не всегда очевидны. Некоторые задания должны выполняться строго последовательно, а некоторые - строго параллельно.
Направленность на достижение конкретных целей. Действительно проекты направлены на получение определенных результатов. Кстати, цели должны быть сформулированы так, чтобы всегда было ясно, что цель достигнута и проект можно заканчивать. Проект обычно предполагает наличие промежуточных целей, которые вместе образуют взаимосвязанный комплекс.
Исключительная ответственность менеджера заключается:
в ответственности за поступление средств.
в том, чтобы проект отвечал требованиям заказчика. Руководитель должен держать заказчика в курсе всех событий проекта;
в руководстве проектом и контролем его выполнения. Менеджер отвечает за ежедневное руководство данным проектом. Хороший менеджер отводит различные проблемы от группы, он "гасит" нагоняи от заказчика или вышестоящего руководства;
в управлении сотрудниками. Менеджер ищет и привлекает лучших специалистов и экспертов для решения возникающих проблем;
в организации взаимосвязей внутри организации;
Совместная деятельность менеджера и лидера проекта включает:
выбор наилучшей стратегии.
распределение работ;
планирование проекта;
Технический руководитель проекта - инженер-технолог, обладающий техническими знаниями и опытом.
Управляющий проекта - руководитель, обладающий организационными знаниями и опытом.
Инженеры. Именно инженеры заняты разработкой и созданием программного продукта.
Управляющие первичного звена. Одна из важнейших задач этой категории управляющих - планирование на уровне программных проектов. Далее мы сконцентрируемся на изучении обязанностей только менеджеров проекта.
Управляющие среднего уровня. В их задачу входит координация и стратегическое планирование деятельности структурного подразделения.
Высший менеджмент. В его задачу входит определение генеральной линии компании.
Стратегию человеческих отношений.
Маркетинговую стратегию.
Финансовую стратегию.
Оперативную стратегию.
Стратегию в области исследования и развития.
Тесное взаимодействие с группами поддержки и продаж.
Обеспечение эффективного взаимодействия между командами разработчиков, быстрое создание и вхождение в процесс разработки таких команд.
Соблюдение многочисленных стандартов.
Принятие ясных и документированных решений.
Наилучшая расстановка приоритетов и ресурсов.
Наличие формализованной модели для разработки программного продукта.
Функция
Руководитель проекта
0.3
Управление, разработка плана и содержания
Технический писатель
1.0
Подготовка документа
Инженер-разработчик
Ставка
0.1
Комментарии
Консультирующий инженер, реализующий OpenMP
Первый вариант полного "руководства" - август 1998 г.
Завершение проектирования "руководства" - апрель 1998 г.
Спецификация OpenMP.
Выяснить право использовать фрагменты оригинальной спецификации OpenMP
Выяснить возможность подключения инженеров-разработчиков для получения информации о деталях реализации и рецензирования документации.
Включить информацию о "руководстве пользователя" в документ "Новости компании Компилятор++"
Проанализировать детали реализации, подготовить и включить в "руководство" соответствующие примеры программ.
Разработать проект "руководства" и определить способ его распространения
Определить с помощью инженеров, реализующих поддержку OpenMP, какие особенности спецификации OpenMP войдут в состав текущей версии компилятора.
Исследовать возможность импортирования спецификаций OpenMP непосредственно из документа.
Полная спецификация по OpenMP доступна в Интернете (http://www.openrap.org/).
Поскольку в данной реализации проекта "Волхов" не будут включены все особенности спецификации OpenMP, необходимо четко указать, какие из них будут реализованы, а какие нет.
Документ "Руководство пользователя по OpenMP" будет доступен как на сервере компании в сети Интернет, так и в бумажной копии.
Дата подготовки документа: 19 августа 1998 версия 1.3.
Название проекта: Руководство пользователя по OpenMP.
