Правильно организованное сопровождение программной системы
экономит средства, вызывает больше доверия пользователей,
облегчает развитие системы.
С развивающейся системой работают две команды программистов:
1) команда поддержки системы (Support);
2) команда развития системы (Development).
Экземпляры системы, используемые в процессе поддержки:
1. Рабочий экземпляр (возможно, многократно копируемый для
использования в разных местах). Обозначается PROD.
2. Экземпляр для комплексного тестирования текущей версии после
исправлений и мелких доработок. Обозначается SYST.
3. Экземпляр для осуществления и тестирования исправлений и
мелких доработок текущей версии. Обозначается TEST.
Экземпляры системы, используемые для её развития:
1. Рабочий экземпляр следующей версии.
2. Экземпляр для комплексного тестирования следующей версии.
3. Экземпляр для осуществления и тестирования отдельных изменений
следующей версии.
Итого 6 экземпляров.
Чтобы внести изменения в модуль, необходимо скопировать его из
рабочего экземпляра системы в экземпляр для изменений.
Экземпляры системы для внесения изменений являются неполным:
в них входят только те модули, которые изменяются, а остальные
берутся из экземпляра для комплексного тестирования, а если
отсутствуют там, то -- из рабочего экземпляра системы.
Экземпляры системы для комплексного тестирования тоже являются
неполными: в них входят только те модули, которые проходят
тестирование, а остальные берутся из рабочего экземпляра системы.
Модифицируемый модуль программной системы закрепляется за
работающим с ним программистом (точнее, за идентификатором
пользователя), и другие программисты не имеют к этому модулю
доступа в режиме редактирования.
Перенос новой версии модуля в среду комплексного тестирования
осуществляется после принятия работы по изменению модуля. По
прохождении комплексного тестирования принимается решение о
переносе модуля в рабочий экземпляр системы. Только после того,
как новая версия модуля попала в рабочий экземпляр системы,
модуль становится доступным для других изменений.
Изменения, сделанные в текущей версии системы, копируются в
создаваемую новую версию системы -- если не противоречат измене-
ниям, отличающим новую версию от старой. Эта работа называется
выравниванием (alignment).
Всякая работа по изменению модуля характеризуется идентификато-
ром задания, кратким наименованием, исполнителем, состоянием
задания, датой начала, датой завершения.
Возможные состояния задания:
R (raised) : выявлена возможная проблема;
D (directed) : проблема направлена тому, кто будет её решать;
W (in work) : проблема в процессе решения;
T (test) : новый код подготовлен для проверки;
I (inspection) : проверка кода успешно завершена;
A (answered) : с точки зрения программистов, проблема решена;
S (signed-off) : проблема закрыта (закрывает тот, кто выявил).
Фрагменты кода, ставшие ненужными, не удаляются, а переоформля-
ются в комментарий таким образом, чтобы при необходимости было
возможно восстановить старый код.
Удалённые строки помечаются так:
1) при удалении отдельной строки:
XXXXXXXXX /* идентификатор_задания DEL */
1) при удалении группы строк:
/* идентификатор_задания DEL FROM */
XXXXXXXXXXXX
XXXXXXXXXXXX
/* идентификатор_задания DEL TO */
Добавленные строки помечаются так:
1) про добавлении отдельной строки:
XXXXXXXX /* идентификатор_задания ADD */
1) про добавлении группы строк:
/* идентификатор_задания ADD FROM */
XXXXXXXXXXXX
XXXXXXXXXXXX
/* идентификатор_задания ADD TO */
Формат идентификатора задания:
TYYMMDDN
где T -- тип изменения:
U -- исправление ошибки, обнаруженной пользователем;
S -- исправление ошибки, обнаруженной службой сопровождении;
T -- исправление ошибки, обнаруженной при тестировании новой
версии;
M -- мелкое изменение (minor change) по предложению
пользователя;
N -- мелкое изменение (minor change) по предложению службы
сопровождения;
D -- запланированное изменение, вносимое при разработке новой
версии системы;
A -- незапланированное необходимое изменение, вносимое при
разработке новой версии системы.
YYMMDD -- дата формулирования предложения по доработке.
N -- порядковый номер в пределах дня.
В легенде программного модуля ведётся журнал всех сделанных в
модуле изменений. Компоненты записи в журнале:
Идентификатор задания
Дата начала выполнения задания.
Идентификатор программиста, осуществившего изменение
Краткое описание изменения (описывается устранённая проблема
и/или сделанное изменение).
Если идея сделанного в программном модуле изменения не очевид-
ная, она должна быть пояснена комментарием.
Если в процессе сопровождения системы были получены сведения об
устройстве системы, отсутствующие в её описании, или обнаружены
ошибки в описании, документация должна быть доработана. Или же
должен существовать эпизодически пополняемый документ "Дополнения
к описанию системы".
* * *
Во всяком документе ведётся журнал внесённых в него изменений,
чтобы пользователь документа, знакомый с его предыдущей версией,
не стоял перед необходимостью сравнивать.
Во всяком документе, предназначенном исключительно для разра-
ботчиков проекта, ставшие ненужными фрагменты не удаляются, а
выделяются (цветом и/или шрифтом и т. п.). Новые фрагменты тоже
выделяются так, чтобы читателю документа не представляло труда
определить, какие изменения появились в документе по сравнению
с его предыдущей версией. При подготовке новой версии документа
те фрагменты, которые в предыдущей версии были оформлены как
ненужные, удаляются, а те, которые были оформлены как добавления
вставки, оформляются как основной текст.
Всякое изменение в программной системе должно документироваться.
Сведения об изменении:
1. Кто сделал предложение об изменении.
2. Кто принял решение о том, что следует осуществить изменение.
3. Кто осуществил изменение.
4. Кто протестировал изменение и признал его правильным.
5. Кто принял решение о переносе изменения в эксплуатируемую
систему.
6. Какое состояние было до изменения.
7. Какое состояние стало после изменения.
8. Какова идея изменения.
9. Каким образом проводилось тестирование изменения.
10. Какие данные использовались для тестирования изменения.
11. Каковы результаты тестирования изменения.
Описание теста необходимо для проверки правильности тестирова-
ния и для повторения теста в случае необходимости.
Работа не должна критически зависеть от конкретных людей.
Состояние рабочего процесса должно быть таким, чтобы изменения в
коллективе исполнителей не вызывали больших проблем, обусловлен-
ных тем, что некоторые важные сведения находятся исключительно в
личной памяти или в личных записях отдельных специалистов, то
есть не документированы и соответственно труднодоступны для
посторонних.
Возможные причины затруднений пользователя при работе с
программной системой:
ошибка в устройстве системы;
ошибка или пробел в описании системы;
неправильное понимание или недопонимание описания системы
(то есть, низкое качество описания);
чрезмерная сложность работы с системой;
недостаточная защищённость системы от ошибок пользователя;
недостаточная защищённость системы от сбоев оборудования,
программного обеспечения;
отсутствие некоторых возможностей в системе;
неправильная установка системы;
неправильная работа окружения системы;
неподходящие качества пользователя (недостаточная квалифика-
ция, неблагоприятное психическое состояние, неправильные
поведенческие установки и пр.).
Виды затруднений при работе с программной системой:
чрезмерные затраты времени на манипуляции в системе;
чрезмерные затраты времени на понимание ситуации и выбор
требуемых действий в системе;
чрезмерные усилия для избежания ошибочных действий;
большая вероятность ошибочных действий.
Возможные конкретные проблемы в системе:
прекращение работы системы;
потеря данных;
невыполнение своевременно некоторой управляющей операции
или операции по изменению данных;
выполнение неправильной управляющей операции или операции
по изменению данных.
Для сбора статистических сведений об ошибках (с целью совершен-
ствования технологии программирования) при каждой исправляемой
ошибке указываются её характеристики. С точки зрения непосредст-
венной причины могут выделяться ошибки следующих типов:
ошибки технического задания;
ошибки проектирования;
ошибки кодирования;
ошибки тестирования;
ошибки эксплуатации;
ошибки документирования.
Чем сложнее поиск ошибки, тем полезнее фиксация шагов этого
поиска. На каждую ошибку заводится файл протокола поиска. Чем
хуже память у программиста, тем тщательнее этот протокол должен
вестись. Данные протокола могут использоваться при оформлении
отчёта об исправлении ошибки.
Файл именуется по коду задания на исправление ошибки или по
дате начала работы над ошибкой (к примеру: YYMMDDN.txt, где N --
порядковый номер на случай, если в течение дня будет начата
работа не над одной, а над несколькими ошибками).
В файл протокола копируются изображения с экрана, фрагменты
программного кода, фрагменты входных и выходных наборов данных и
пр., а также записываются различные соображения.
Заносимые в течение дня записи отделяются от записей предыдуще-
го дня двойной линией с датой:
===================================================== 13.12.2006
Группа записей, представляющих собой целое, отделяется от
других групп одиночной линией:
---------------------------------------------------------------
Если по виду группы записей затруднительно понять её смысл, при
ней должно быть короткое пояснение.
Сопровождение программной системы.
Сопровождение программного продукта включает в себя следующее:
исправление ошибок программирования;
помощь в исправлении данных, необходимость которого вызвана
ошибками программирования;
небольшая доработка программ, обусловленная неточностями
и ошибками техничесокго задания.
Сложности сопровождения:
понять, каких изменений или доработок добивается
пользователь;
воспроизвести ситуацию, в которой проявляется ошибка или
недоработка;
понять, как работает фрагмент системы, в котором надо сделать
изменения;
придумать изменения;
придумать тест, охватывающий не только сделанные изменения,
но также и ту часть системы, которая может быть этими
изменениями задета.
Должна обеспечиваться фиксация сведений о системе, получаемых и
вырабатываемых в процессе её сопровождения. Письменное представ-
ление этих сведений должно быть хорошо структурировано, чтобы
поиск нужной информации не составлял затруднений.
В случае, если пользователи системы считают переданную им экс-
плуатационную документацию недостаточной (не отражающей некоторых
нюансов, выявленных при работе с системой, или не описывающей
некоторых действий), им лучше не корректировать эту документацию
и не добиваться её корректировки от разработчиков (те смогут
сделать это разве что по чужим указаниям, поскольку сами с
соответствующими сложностями не сталкиваются), а создавать
дополнительную.
Программные средства для сопровождения
и развития.
К программным средствам для сопровождения и развития програм-
мной системы относятся:
1. Средства для поддержания порядка в совокупности модулей и
библиотек сопровождаемой программной системы, а также в
совокупности используемых документов (входных, внутренних,
выходных).
2. Средства для учёта проблем в программной системе и заданий
её на исправление и доработку.
3. Средства для учёта изменений в программной системе.
Принципы обеспечения сопровождаемости программного продукта:
1. Следовать соглашениям по оформлению программного кода, в
частности, по именованиям компонентов.
2. При каждой подпрограмме помещать комментарий, поясняющий
её назначение.
3. Следовать соглашениям по оформлению пользовательского
интерфейса (экранных изображений).
4. Минимально использовать неявные средства изменения значений
переменных: указатели (pointers), переопределение областей
памяти при объявлении переменных и структур данных и т. п.)
5. При объявлении каждого компонента данных (переменой,
структуры, массива, файла и пр.) помещать комментарий,
поясняющий назначение этого компонента, если оно может быть
не вполне понято из названия этого компонента.
6. Если используется какой-то неочевидный приём обработки данных
или управления процессом обработки, следует пояснять его
комментарием.
7. Пояснять комментарием идею всякого фрагмента алгоритма, если
эта идея не является очевидной или широко используемой.
Если в программе много комментариев и трассировочных добавле-
ний, основной программный код становится труднообозримым и понять
его оказывается сложно. Следует добиваться наибольшей выразитель-
ности собственно кода, а комментариями только компенсировать её
недобор.
В письме должно быть отражено ваше уважение к корреспонденту и
бережное отношение к его интересам и его времени. надо быть
особенно осторожным, если из содержания письма может сделан вывод
о недостаточно качественной работе кого-то из коллег.
Надо стараться уяснить себе и в дальнейшем учитывать то, каких
писем ожидает от вас ваш корреспондент: насколько частых,
насколько детальных, насколько мелочных, насколько официальных.
Кто умнее, тот и приспосабливается. Если из двух взаимодействую-
щих индивидов ни один не хочет приспосабливаться к особенностям
другого, их отношения обычно не складываются и совместная работа
оказывается под угрозой.
Чрезмерная краткость вредит больше, чем чрезмерное многословие:
если письмо слишком длинное, то человек, его читающий, имеет воз-
можность пропустить то, что для него не значимо; а если письмо
слишком краткое, он может остаться в неопределённости или в неве-
дении, а запрашивать дополнительную информацию ему будет неловко,
поскольку это может быть воспринято как признак его недостаточной
компетентности или малой сообразительности.
Чем больше структурировано письмо, тем лучше оно воспринимается.
Если письмо состоит из нескольких смысловых частей, границы между
ними должны быть отчётливо видны. Фрагменты текста, различающиеся
по типу содержания, должны различаться и по оформлению. Если
содержание письма имеет иерархическую организацию, она должна
быть заметно обозначена. Наконец, главная часть текста должна
быть выделена на фоне второстепенного материала. Большие массивы
вспомогательных данных лучше выносить в приложения.
Заголовок письма должен достаточно пояснять его смысл и место
в совокупности писем и проблем. Можно делать заголовок иерархи-
ческим: XXXXXX / YYYYYY / ZZZZZZZZZ.
Надо исходить из того, что ответ определяется вопросом. Если
хотите получить содержательный ответ, надо правильно спросить. Из
вашего запроса сведений должно быть понятно, среди прочего,
следующее:
какую конкретную информацию вы ожидаете (надо дать понять не
то, что вам не хватает информации, а то, какой именно
информации вам не хватает);
насколько ответ вам нужен;
на каком уровне детальности этот ответ должен быть;
остановится или затормозится ваша работа, если ответ
задержится или не придёт.
Чтобы сэкономить время корреспондента, предложите ему ожидаемый
вариант ответа и попросите подтверждения. Или же попросите сде-
лать выбор из нескольких предложенных вами вариантов ответа, то
есть подготовьте ему решение. Если корреспондент вашим предложе-
нием не воспользуется, то хотя бы лучше поймёт вашу информацион-
ную потребность. Также бывает полезно привести хотя бы в приложе-
нии к письму те сведения, которые коллега должен принимать в
расчёт в процессе выработки решения (даже если он сам в состоянии
их добыть). Чем лучше вы подготовите материал, тем быстрее и
качественнее будет ответ на ваш вопрос.
Следует учитывать, что наиболее внимательно читаются начало и
конец письма. Указанная в названии письма тема и первые несколько
строк письма должны быть достаточны для понимания сути и степени
важности его содержания. В самом начале или в самом конце письма
надо, среди прочего, чётко выразить, каких действий или какого
ответа вы ожидаете от человека, которому пишете.
Если вы ожидаете уточнений по некоторому предмету, можно изло-
жить в письме своё видение его, чтобы корреспондент мог понять,
каких сведений вам не хватает, и проверить правильность ваших
представлений.
Если имеется несколько мало связанных или не связанных между
собой сложных проблем, лучше посвятить каждой отдельное письмо,
так как любая из этих проблем может потребовать длительной
переписки, в которой придётся пересылать вместе с каждым письмом
"историю", т. е. "хвост" из всех предыдущих писем.
Решения при коллективной работе принимаются по-разному. Частью
разделяются области ответственности, частью ищется консенсус или
компромисс.
Следует уведомлять коллег о тех своих решениях, которые могут
их задеть. Если вы рискуете создать коллегам чувствительные слож-
ности, лучше сначала интересоваться мнением коллег о своих
замыслах и только потом приступать к их реализации.
Нередко проблема имеет не одно, а несколько решений, но каждое
-- с какими-то недостатками. Чтобы у вашего корреспондента не
возникло подозрение, что выбранное вами решение неправильное,
можно кратко ознакомить коллегу с другими рассмотренными вариан-
тами решения и указать их недостатки. Если он после этого не
возразит на выбранное вами решение, значит, он разделит с вами
ответственность за него.
Лучше не отправлять написанное письмо сразу, а по возможности
давать ему некоторое время "отлежаться": это вызвано тем, что
ошибки и слабые места письма зачастую обнаруживаются сразу же
после того, как оно второпях написано и отправлено. Бывает, что
вскоре отпадает необходимость в отправке письма вообще. Особенно
полезно подождать до утра с отправкой письма, написанного
вечером.
Прежде чем беспокоить кого-либо вопросами по телефону, надо
подумать о том, сможет ли собеседник качественно ответить без
предварительной подготовки. Телефон привлекает быстротой общения,
но он не годится в случаях, когда требуется обдумывание вопросов
и тщательность формулировки ответов. Если информация, на которую
должен отреагировать собеседник или которую он должен выдать,
плохо воспринимается на слух и требует визуального представления,
телефонный разговор оказывается вообще неуместен. Вдобавок собе-
седник может воспринять свою неспособность ответить как дискреди-
тирующее его обстоятельство.
Звуковая запись телефонного разговора облегчает понимание
сложных ответов, но не облегчает понимания сложных вопросов.
О времени и содержании серьёзного телефонного разговора следует
договариваться заранее (посредством обмена электронными письмами
или предварительного телефонного звонка). Это даёт собеседнику
возможность подготовиться.
К разговору должен быть составлен список вопросов и предложе-
ний, чтобы свести необходимость в экспромтах к минимуму.
Если разговор стопорится, надо поскорее прервать его и догово-
риться о следующем телефонном звонке, к которому обе стороны
более основательно подготовятся.
Надо учитывать, что в телефонном разговоре труднее, чем в
письме, скрыть недостаточность своей компетентности.
Неудачный телефонный разговор -- надёжное средство добиться
того, чтобы в вас разочаровались.
Если пользователь хочет предложить исправить ошибку в програм-
мной системе, он должен детально пояснить прграммисту, как вос-
произвести ситуацию, в которой эта ошибка проявляется. Для понят-
ности обычно требуется описание не только действия, непосредст-
венно приведшего к проявлению ошибки, но также описание несколь-
ких предшествующих действий -- от самого захода в систему или от
того её состояния, способ воспроизведение которого программисту
заведомо известен.
При этом надо учитывать, что программист видит программную
систему не так, как пользователь, и не обладает компетенцией
пользователя в предметной области, в которой система применяется.
В пояснении следует избегать профессионального жаргона пользо-
вателей, потому что он может быть не вполне понятен программисту.
Также следует избегать использования разговорных выражений,
потому что они не всегда обеспечивают однозначность понимания.
Из объяснений пользователя должно быть понятно не только то,
какие вещи его не устраивают, но также то, какой результат ему
требуется.
Чем подробнее и чётче будут объяснения пользователя, тем меньше
дополнительных вопросов задаст программист и тем быстрее и точнее
он выполнит свою работу.
Если у пользователя имеются сомнения насчёт того, сообщать или
не сообщать программисту некоторые свои соображения по поводу
ошибки, то лучше их сообщить, не боясь высказать что-то невпопад:
если для программиста эти замечания окажутся бесполезными, он их
всего лишь проигнорирует, но вполне возможно, что они ускорят его
работу.
Этапы разработки новой версии системы:
1. Собираются предложения пользователей.
2. Архитектором системы разрабатывается концепция её развития.
3. Предложения пользователей оцениваются с точки зрения
полезности, приемлемости по затратам, взаимной совместимости,
соответствия концепции развития системы.
4. Создаётся и обсуждается с пользователями документ, описывающий
предполагаемые изменения в системе с точки зрения пользовате-
лей. Взаимосвязанные изменения объединяются в задания, получают
идентификатор.
5. Создаётся документ, описывающий предполагаемые изменения в
системе с точки зрения программистов.
6. Программисты вносят изменения в программный код и тестируют
их. Каждое изменённое место в программных модулях помечается
идентификатором задания на изменение.
7. Тестируется новая версия системы в целом. Среди прочего,
повторяются все тесты, какими по-отдельности проверялись
внесённые изменения, поскольку эти изменения могут оказаться
взаимно несовместимыми.
8. Новая версия системы передаётся в опытную эксплуатацию
доверенным пользователям.
Изменения в разрабатываемой системе должны в течение некоторого
времени оставаться легко обратимыми. Для этого 1) старые варианты
кода по возможности не удаляются, а переоформляются в комментарии,
2) сохраняются старые версии кода.
Александр Бурьяк.