Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/02h004.shtml

Глава 4. АДМИНИСТРАТИВНАЯ СТОРОНА СОПРОВОЖДЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

       Руководителю работ по сопровождению программного обеспечения неизбежно приходится сталкиваться с целым рядом проблем, не имеющих под собой реальной основы.
       Примером может служить существующее мнение, что сопровождение — скучная, нетворческая работа, заниматься которой должны самые неквалифицированные специалисты. В то же время неквалифицированное сопровождение отрицательно скажется даже на тщательно разработанном программном обеспечении. Мнение, что руководители обычно удовлетворены качеством сопровождения программного обеспечения [23], ошибочно (сопровождение — это только часть всего проекта программного обеспечения, и его качество зависит от того, насколько хорошо проведен процесс первоначальной разработки).
       Существует ряд принципиальных заблуждений, касающихся процесса сопровождения. Если спросить у руководителей, какую часть времени отнимает сопровождение у их сотрудников, многие из них ответят: “Около 20%”. Они также полагают, что 80% этого времени затрачивается сопровождающим программистом на исправление ошибок в программе. Как мы уже знаем, это далеко не так.
       О сопровождении программного обеспечения написано мало. Но те работы, которые имеются, достаточно убедительны. Одно исследование за другим показывают, что сопровождение отнимает 50—80% материальных затрат и времени [3, 23]. Некоторые исследования убедительно свидетельствуют о том, что исправление ошибок составляет лишь малую долю работы сопровождающего программиста— от 15 до 40% [23]. Естественно напрашивается вопрос: чем же занимается сопровождающий программист в оставшееся рабочее время? В нашей книге мы постараемся ответить на этот вопрос, как, впрочем, и на следующий за ним: что я как руководитель должен сделать, чтобы помочь сопровождающему программисту? (В работе [21] читатель найдет подробный обзор задач руководителя работ по сопровождению программного обеспечения, накопленных на основе практического опыта.)

4.1. ПЛАНИРОВАНИЕ СОПРОВОЖДЕНИЯ

       При планировании работ по сопровождению необходимо учитывать индивидуальные способности всех сотрудников. Кому лучше поручить задачу увеличения срока службы уже разработанного обеспечения? Кто лучше других психологически подготовлен к тому, чтобы взять на себя непрестижный труд сопровождающего программиста? Кто обладает гибкостью, необходимой для того, чтобы приспособиться к стилю программ? Кто понимает важность сопровождения и сумеет создать программу и подготовить документацию, которые будут иметь долгий срок службы?
       Кроме того, руководитель задает много вопросов, касающихся его самого и его работы. Как я могу контролировать качество работы сопровождающего программиста? Как сделать его работу продуктивнее? Как я могу обеспечить контроль над всем процессом сопровождения? Какие этапы процесса требуют наиболее тщательного административного контроля? Какие формы должен принимать процесс сопровождения? Как уложиться в рамки отпущенных средств? Все эти вопросы сложны. И, как и любые другие, они легче решаются упорными руководителями, обладающими интуицией, основанной на их личном опыте и соответствующем образовании. Главное качество — это “интуиция, основанная на образовании”. Руководитель, который до тонкостей знает работу по сопровождению, легче справится и с ее планированием.

4.1.1. ПЛАНИРОВАНИЕ ВЫСОКОКАЧЕСТВЕННОГО СОПРОВОЖДЕНИЯ. РОЛЬ ЛИЧНОСТИ

       Мы уже убедились, что к сопровождающему программисту предъявляются очень высокие профессиональные требования. Подобрать для работы и настойчивых, способных к творчеству, одаренных и умеющих составлять документацию специалистов непросто. И все же успех работ во многом зависит от того, удастся ли руководителю найти сотрудников, отвечающих всем необходимым требованиям. “Основным фактором, влияющим на надежность программного обеспечения, является подбор и руководство сотрудниками, которые разрабатывают программное обеспечение и осуществляют его сопровождение” [6]. Этому вопросу нередко уделяется слишком мало внимания, в особенности если учесть хроническую нехватку квалифицированных специалистов. Когда вычислительный центр работает при постоянной нехватке сотрудников высокой квалификации, возникает искушение несколько снизить уровень предъявляемых требований и принять на работу недостаточно квалифицированных работников. Такая необходимость может возникнуть, но делать это надо осторожно, и, конечно, ни в коем случае нельзя поручать таким работникам (все равно старым или вновь принятым) работу по сопровождению. В противном случае руководитель рискует попасть в положение путешественников на остров Небывалый1 {Название острова из детской английской книги “Питер Пен”. — Прим. ред.}). В этой книге мы еще не раз вернемся к тому, каким образом можно благополучно избежать проблем, связанных с тонкостями техники программирования. Эти проблемы стоят особенно остро при необходимости увеличить объем и повысить качество работ по сопровождению. Сопровождающий программист проводит весь день, разбирая во всех подробностях написанную кем-то программу. Хорошо ли это? Продуктивно ли он тратит время? Об этом невозможно судить, если не знать до тонкостей, что это за программа.
       Мы уже говорили о том, что сопровождающие программисты затрачивают 15—40% времени на исправление ошибок в программе. Совершенно очевидно, что от того, как они расходуют оставшееся время, зависит оценка их труда. Кроме того, оценка их труда зависит и от того, как они расходуют время, отведенное на исправление ошибок.
       Одна из работ [23] по сопровождению программного обеспечения дает следующее распределение времени: 17% — исправление ошибок, 18% — адаптация, 60% — усовершенствование программы, 5% — разное.
       Сопровождение, направленное на усовершенствование программного обеспечения, занимает больше всего времени и является наименее понятным этапом работы сопровождающего программиста. Что это такое? Это просто процесс “улучшения качества программного обеспечения”. Под этим может подразумеваться самый широкий круг улучшений, начиная от усовершенствований для пользователя (скажем, введение вновь созданного алгоритма расчета траектории в уже существующую программу запуска космического корабля) и кончая усовершенствованиями для программиста (например, структуризация ранее заброшенного отрезка программы, считавшегося недоступным для сопровождения). Это может быть и внесение исправлений и дополнений в документацию (например, сделать справочник пользователя более удобным для чтения). Как ни странно, именно здесь и расходуются средства, отпускаемые на сопровождение, и руководителю необходимо осознавать важность этого вида сопровождения. К сожалению, многие руководители (особенно те, кто не знаком с техникой программирования стремятся сократить или даже совсем уничтожить сопровождение, направленное на усовершенствование, поскольку таким образом можно сэкономить 50—80% средств. Но это опасное заблуждение. Хотя и не очень пригляден образ ученого-фанатика, стремящегося довести свое “детище” до полного совершенства и готового бесконечно улучшать его, тем не менее определенное усовершенствование программного обеспечения крайне необходимо. При этом стоимость будущих исправлений и усовершенствований постоянно значительно снижается. И, что еще важнее, в будущем это окупится за счет сокращения затрат машинного времени. В конце концов, экономия машинного времени будет определяться уровнем усовершенствования программного обеспечения. Сам факт,что руководство в целом удовлетворено сопровождением, указывает на то, что сопровождающие программисты, как правило, проводят усовершенствование на высоком профессиональном уровне.
       Суть всего сказанного состоит в том, что усовершенствующее сопровождение не предполагает сокращения программного обеспечения: оно помогает сделать обеспечение более удобным с точки зрения эксплуатации и контроля. То же самое относится к адаптирующему и тестирующему сопровождению.
       Итак, контроль и отчетность совершенно необходимы для повышения качества сопровождения программного обеспечения. Вопрос здесь стоит так. Какой должна быть форма отчетности о состоянии сопровождения? Насколько строгим должен быть контроль? (Методы осуществления контроля мы обсудим в следующем разделе.) Пожалуй, самым непростым для руководителя является вопрос о том, как организовать контроль и насколько жестким он должен быть. Вопрос труден, так как на него нельзя ответить однозначно. Точного ответа нет потому, что это очень индивидуальная проблема (см., например, работу [2]). Некоторые программисты с удовольствием работают только в том вычислительном центре, где административный контроль очень жесткий, — они нуждаются в том, чтобы им постоянно напоминали об ответственности. Другие, наоборот, считают административный контроль унизительным для себя — они итак обладают обостренным чувством ответственности, что обеспечивает высокий внутренний самоконтроль. Все эти нюансы порождают необходимость решить, как осуществлять руководство и контроль, придерживаясь при этом индивидуального подхода. Как правило, руководители не в состоянии найти золотой середины: часть из них руководит слишком круто, другие, наоборот, недооценивают значения контроля, и у них он почти отсутствует. Компромиссный подход желателен, когда речь идет о разработке программного обеспечения, особенно в большом учреждении. Но, когда речь идет о сопровождении, где личные качества программиста тесно связаны с результатом его работ, компромисс неуместен.
       Руководителю, который стремится учитывать индивидуальные особенности своих сотрудников, следует обратить внимание на следующие факторы:
       1. Необходимо понять возможности сотрудника и меру его ответственности.
       2. Следует осуществлять контроль и добиваться отчета о работе в зависимости от возможностей и степени ответственности сотру дника.
       3. Необходимо убедить всех сотрудников в том, что руководи тель относится к ним справедливо и беспристрастно.
       Соблюдение всех этих условий — нелегкая задача для руководителя.
       Каким образом способный руководитель может добиться максимальной отдачи от своих сотрудников?
       1. С помощью эффективного индивидуального подхода к каждому сотруднику, о чем уже говорилось выше.
       2. Необходимо быть в курсе той работы, которая ими выполняется, т.е. знать, какие вносятся изменения, почему и какое влияние они окажут на работу программного обеспечения (включая знание изменяемой программы).
       3. Путем контроля решаемых ими задач. Здесь подразумевается контроль за внесением изменений, о чем будет подробно сказано ниже.
       4. Путем создания им необходимых условий труда и обеспечения их оборудованием, которое повышает эффективность работы сопровождающего программиста. Об этом также будет сказано ниже.
       Такой подход поможет управлять усовершенствованием, адаптацией и необходимой коррекцией программ в процессе сопровождения (хотя дальновиднее было бы сделать между ними различия). При правильном руководстве все эти разновидности сопровождения являются важными и неотъемлемыми частями единого процесса. Такие рекомендации по повышению продуктивности труда сопровождающих программистов можно, пожалуй, счесть несколько субъективными. Мы здесь как бы отвечаем вопросом на вопрос. Но факт остается фактом: более объективного ответа не существует. Сопровождение всегда было и останется искусством, основанным на интуиции. Если бы существовал объективный подход к вопросам сопровождения, то, возможно, само сопровождение могло бы стать ненужным.

4.1.2. ПЛАНИРОВАНИЕ ВЫСОКОКАЧЕСТВЕННОГО СОПРОВОЖДЕНИЯ. ОТЧЕТ И ПРОВЕРКИ

       В предыдущем разделе говорилось о том, что объем работ по сопровождению программного обеспечения зависит от индивидуальных возможностей сопровождающего программиста. Речь шла о внимании к личности сотрудника и о том, что отчетность и контроль должны быть организованы так, чтобы отдача была максимальной.
       Тот же принцип можно положить и в основу достижения высокого качества сопровождения. Из вышесказанного ясно, что тщательно подобранный, способный и добросовестный программист при условии грамотного руководства является основным элементом продуктивного и высококачественного сопровождения. При отсутствии этого элемента задача руководителя становится весьма сложной, так как ему самому придется восполнять все пробелы.
       Но задача не сводится только к тому, чтобы подобрать подходящих специалистов. Руководителю необходимо обеспечить процесс обзора и проверки, чтобы следить за самим процессом сопровождения.
       До некоторой степени это запретная тема. Сопровождающие программисты подозрительно относятся ко всякой попытке руководителя вмешаться в их работу. А руководители раздражаются, если им приходиться судить о качестве сопровождения, особенно в тех случаях, когда они считают себя недостаточно осведомленными. Таким образом, хотя во многих источниках вы найдете положительные отзывы о влиянии внешнего контроля [5, 13, 25, 39], на самом деле такой контроль редко, а точнее, почти никогда не оказывает такого влияния на сопровождение программного обеспечения.
       Как же избавиться от нежелательного влияния контроля? (Совершенно очевидно, что качество программного обеспечения на стадии сопровождения не менее важно, чем его качество на стадии разработки, а значит, всякий согласится с тем, что контроль и проверка необходимы на время сопровождения.) Чтобы не травмировать сопровождающих программистов, следует поручать контроль и проверку людям одного с ними ранга. Этот процесс должен состоять в проверке того, насколько программа отвечает своему назначению, насколько эффективна ее работа; только сами сопровождающие программисты способны должным образом оценить работу друг друга. Проверка должна проходить в атмосфере доброжелательной взаимопомощи, люди должны чувствовать, что они делают общее дело. К проверке не следует допускать ни тех, кому недостает такта, ни тех, кто склонен покрывать недостатки своих коллег. Проверка не всегда должна носить формальный характер. Простейшие изменения могут вноситься самим сопровождающим программистом. Несколько более сложные изменения могут быть обсуждены двумя специалистами. И только значительные изменения следует вносить формально, в официальной обстановке.
       Вот все, что имеет отношение к сопровождающему программисту. Теперь поговорим о том, что касается руководителя. Видимо, читателю уже ясно, что часто существует несоответствие между необходимостью контроля и проверки на высоком техническом уровне и уровнем технической подготовки руководителя. Руководитель, осознающий это, обычно либо 1) запрещает отчеты и проверки, либо 2) участвует в них, ограничивая их содержание рамками своих знаний, либо 3) устраняется от них. Все три подхода ошибочны.
       Варианты 1 и 2 совершенно неверны. Если мы стремимся повысить качество программного обеспечения, то, несомненно, должны оценивать его, а не избегать этого. Руководитель, который гордится тем, что “работа идет по графику и в рамках бюджета”, одновременно упускает из виду качественный показатель, который, конечно, не менее важен, чем график и бюджет. Руководитель, который принимает участие в отчетах и проверках, но ограничивается лишь общими соображениями, выполняет лишь две трети работы, сводя на нет оставшуюся треть.
       Вариант 3 более привлекателен, но тоже ошибочен. Конечно, если проверки касаются чисто технических вопросов, то они могут проходить без администрации. Но проверка качества сопровождения программного обеспечения требует, чтобы соображения руководства были одним из факторов оценки.
       Правильнее всего для руководителя участвовать в процессе оценки, внося вклад, когда он может быть полезен, и перенимать опыт коллег-практиков, одновременно повышая свой уровень знаний, когда не может оказаться полезным [15]. В результате руководитель будет до тонкости осведомлен о качестве сопровождения, за которое несет ответственность, и одновременно будет постоянно совершенствоваться как специалист.
       Качество сопровождения программного обеспечения зависит, таким образом, от тех же факторов, от которых зависит его объем, плюс правильно организованный процесс отчетов и проверок. Хороший коллектив и тщательная оценка результатов его труда есть залог успешного руководства сопровождением программного обеспечения.

4.1.3. ДРУГИЕ АСПЕКТЫ ПЛАНИРОВАНИЯ

       Было бы упрощением полагать, что планирование сопровождения программного обеспечения исчерпывается лишь качественным показателем. Руководитель вынужден выполнять еще целый ряд требований. Он имеет ограниченный бюджет, который позволяет ему воспользоваться услугами ограниченного числа служащих и машинного времени. Он имеет график (свой собственный или спущенный свыше), который определяет сроки выполнения работ. Наконец, в его распоряжении находятся ЭВМ, периферийное оборудование, вспомогательные средства и исполнители, которые могут выполнять ограниченный круг обязанностей. Ему подвластна организация, которая либо усиливает качество его руководства процессом сопровождения, либо, наоборот, сводит его на нет. И кроме того, у него есть документация, которая помогает в работе по сопровождению и которую в результате следует передать пользователю.
       Все эти факторы необходимо учесть при планировании — тщательно разрабатывая детали, если программное обеспечение большое и сложное, и не вдаваясь в частности, если оно является простым. Например, решая вопрос о приобретении дополнительной ЭВМ для решения задач сопровождения, возможно, придется решать вопрос о строительстве нового здания для этой ЭВМ или об организации работы без увеличения ресурсов [15].
       Главное в решении подобных вопросов — перспективное планирование. Все соображения качества, количества, ресурсов, бюджета,, графика, организации и документации должны быть учтены задолго до начала работы. Конечно, такое планирование — нелегкая задача. Вспомним, что управление программным обеспечением является искусством, основанным на интуиции и глубоких знаниях руководителя. Помните также, что оценки программного обеспечения будут заведомо низкими и эффективность затрачиваемых на него усилий, включая сопровождение, будет зависеть от прозорливости руководителя, планирующего эту работу.
       В этом разделе мы не пытались осветить вопросы бюджета и графика работ в основном потому, что они имеют много общего с проблемой разработки программного обеспечения. Об этом уже говорилось немало (например, [8, 11]), причем многое из сказанного там спорно (таково общественное мнение). Опыт показывает, что вопросы бюджета и графика работ должны решаться интуитивно в конкретных условиях разработки каждого проекта, причем научить человека интуитивно правильно решать такие задачи пока невозможно. В литературе описываются случаи, когда комплекс сопровождаемого программного обеспечения был первоначально укомплектован штатом в 100 человек, однако в дальнейшем потребовал дополнительно еще 41 [12]!
       Вопросы организации и составления документации по сопровождению программного обеспечения решать можно и нужно. В последующих разделах эти вопросы будут изложены более подробно.

4.2. ОРГАНИЗАЦИЯ СОПРОВОЖДЕНИЯ

       Мы уже говорили о том, что сопровождение программного обеспечения является составной частью процесса создания программного обеспечения в целом. Процесс исправления или внесения изменений в программное обеспечение включает этапы определения требований, проектирования, кодирования, тестирования и, конечно, следующего за ними этапа сопровождения. (Таким образом, сопровождение программного обеспечения можно рассматривать как рекурсивный процесс.) И нет ничего удивительного в том, что организация сопровождения немыслима вне связи с созданием программного обеспечения. Действительно, во многих случаях организация сопровождения ведется в тесной связи с разработкой программного обеспечения. Нередки случаи, когда сопровождение поручается программистам — разработчикам обеспечения (что бывает иногда полезно), причем они чередуют работу по сопровождению с созданием программного обеспечения (своей текущей работой), Получается что-то вроде режима разделения времени. Программист А, например, внедряет систему Z и одновременно занимается сопровождением системы Y, которую, возможно, он же и разработал.
       Существует другая организация сопровождения, которая тоже распространена и вполне приемлема. Может существовать специальное подразделение, в задачу которого входит исключительно сопровождение. Программисты A, В, и С разрабатывают программное обеспечение, проверяют его и передают сопровождающим программистам X, Y и Z для сопровождения. При этом! сопровождающий программист X может быть ответственным за сопровождение всего программного обеспечения или какой-либо его части.
       Существует и промежуточный вариант организации СПО — так называемый зонтик: подразделение, занимающееся сопровождением, находится под прикрытием подразделения, занимающегося созданием программного обеспечения. Программисты могут заниматься чистым сопровождением, или только созданием программного обеспечения, или и тем и другим, но связь между ними столь тесна, что переход от одного к другому осуществляется легко и привычно.
       При выборе правильного варианта следует руководствоваться соображениями сложности программного обеспечения и степенью квалификации коллектива программистов. Если все сотрудники презрительно относятся к сопровождению, разумнее всего, пожалуй, распределять обязанности, связанные с ним, равномерно между всеми членами коллектива. Если же среди них есть люди, которым нравится заниматься сопровождением и которые обладают необходимыми для этого способностями, целесообразнее выделить их в специальное подразделение, отвечающее за сопровождение программного обеспечения. Кроме соображений, связанных с личными качествами работников, существуют соображения, которые следует учесть: сложность программного обеспечения и приоритет сопровождения. Если программное обеспечение очень сложное (например, большая операционная система или программа, управляющая работой цеха), имеет смысл привлечь к сопровождению тех специалистов, которые создали ее. При этих условиях лучше работать в режиме разделения времени. (Вполне вероятно, что программисты, создавшие данную сложную программу, уже перешли к созданию новой программы, но они должны по-прежнему нести ответственность за сопровождение предыдущего программного обеспечения.)
       Но если сопровождение обладает высоким приоритетом (например, речь идет о системе расчета заработной платы или о системе, работающей в режиме реального времени), будет правильнее поручить сопровождение специальному подразделению, чтобы оно занималось только этим делом.
       Совершенно ясно, что существует промежуточный вариант — большая степень сложности плюс высокий приоритет, о котором мы ничего не сказали. Соображения сложности заставляют поручить работу по сопровождению разработчику, высокий же приоритет требует обратного — поручить сопровождение специально выделенному для этого подразделению! Как найти выход из положения? Решение этого вопроса мы оставим за руководителями, которые будут читать нашу книгу. Это и есть превосходный случай поупражняться в решении тех задач, для которых необходима интуиция, основанная на глубоких знаниях. Об этом мы говорили выше.
       В нашей книге мы не будем пытаться давать определения возможных вариантов организационных структур. Вместо этого рассмотрим те характерные организационные требования, которые налагаются самой работой по сопровождению, и свяжем их, где это необходимо, с организационной структурой разработки или сопровождения. Например, мы не станем рассматривать различия между организационными структурами, в основу которых положены требования технологии (например, группы главного программиста [5, 39]), и организациями, в основу которых положены требования администрации (например, традиционная иерархическая структура [6, 12, 30, 35]). Те, кого интересуют эти вопросы, могут воспользоваться приведенной в конце главы справочной литературой.
       Далее будут даны рекомендации по организации, которые следует учесть при сопровождении программного обеспечения. Мы исходим из выполняемых программным обеспечением функций. Обсуждение завершится определением нескольких возможных организационных структур.

4.2.1. СОВЕТ ПО ВНЕСЕНИЮ ИЗМЕНЕНИЙ

       Самый первый вопрос сопровождения — это: Нужно ли вносить данное изменение? Решение этого вопроса может оказаться как совершенно очевидным (например, если при выплате зарплаты каждый чек содержит лишнюю тысячу долларов), так и чрезвычайно сложным (если, например, пользователь хочет увеличить число символов в строке с 30 до 35, это повлияет на файлы, форматы, описание внутренних данных и процедур и, следовательно, на затраты; поэтому необходимо рассмотреть вопрос о целесообразности такого изменения). Заметим также, что сложность вопроса не соответствует его важности. В приведенном ранее примере вопрос, решение которого очевидно, является одновременно и более важным, в то время как важность решения сложного вопроса не очевидна.
       При решении вопроса о целесообразности изменения возникает извечная дилемма между срочностью принятия решения и той ответственностью, которую при этом приходится брать на себя, если решение сложно. В примере с зарплатой промедление могло бы дорого обойтись. В то же время поспешность при решении вопроса об увеличении числа символов также может обернуться большими убытками.
       Отсутствие четкого разделения функций в организационной структуре приводит к путанице при решении сложных вопросов, связанных с изменениями. Легче всего создать совет по внесению изменений, отвести ему определенное место в организационной структуре и считать вопрос решенным. Во многих сложных вопросах, для решения которых требуется большая решительность, такой вариант подходит. Однако хорошо известно, как неповоротлива наша иерархическая структура. В тех случаях, когда требуется принять срочное решение, созыв совета по внесению изменений может сильно затормозить работу. И все же, несмотря на это, совет по внесению изменений является необходимым органом, который должен иметь определенное, официально установленное место в организационной структуре. Его полномочия и мера ответственности должны быть четко определены соответствующей инструкцией, также должен быть предусмотрен образ действий в тех случаях, когда решение необходимо принять срочно.
       Внесение изменений в сопровождение программного обеспечения может повлечь за собой далеко идущие последствия для всего учреждения. Поэтому совет изменений должен действовать на самом высоком уровне. В нем должны быть представлены и те отделы, которые не связаны непосредственно с программным обеспечением, либо на правах постоянных членов, либо в качестве приглашенных на заседания в тех случаях, когда обсуждается внесение изменений, затрагивающих их интересы. Например, если вносятся изменения в программное обеспечение тренажера для экипажа самолета, это может затронуть интересы организации, занимающейся конструированием и созданием самолета, а возможно, и интересы самого экипажа. Они обязательно должны принять участие в обсуждении. Обсуждение же внутренних изменений (например, устранение ошибок в программе), которые не затрагивают интересов других отделов, скорее всего не будет для них интересно. В любом случае участие в решении вопросов руководителей самого высокого уровня может оказаться полезным, обсуждается ли распределение дефицитного времени ЭВМ или речь идет о взаимодействии отделов.
       Опять-таки такое участие вышестоящих руководителей не всегда необходимо и желательно. Всем хорошо знакома ситуация, когда в 2 ч дня во время работы программы, рассчитывающей зарплату, вызывают сопровождающего программиста, чтобы устранить возникшую неполадку. Высших руководителей, естественно, привлекать к решению подобных вопросов не следует. Таким образом, процесс внесения изменений следует организовать так, чтобы в аварийных ситуациях в подчиненную организацию направлялось ответственное лицо для решения вопроса об изменениях. Трудно, а может быть, и невозможно точно определить, при каких обстоятельствах следует вносить такие срочные изменения. Лучше всего выработать систему отчетности перед советом по внесению незапланированных изменений.
       Все связанное выше относилось к процессу формального решения вопроса о целесообразности изменений. Существует, однако, много случаев, когда формальный подход не только не нужен, но даже вреден. Например, в очень маленькой организации или в случае, когда крупная организация ведет небольшую разработку, часто наличие способного, думающего сопровождающего программиста оказывается достаточным для того, чтобы избежать формального рассмотрения вопроса об изменениях. В этой главе мы хотим дать читателю представление о самом понятии “решение вопроса о целесообразности изменений”. Степень формальности при решении этого вопроса должна быть установлена самим руководителем. Мы уже говорили об интуиции руководителя, основанной на прочных знаниях. Она заключается в способности быстро решать нелегкие задачи. Одной из таких задач и является вопрос о том, когда, как и к кому следует применить формальный подход.

4.2.2. КОНТРОЛЬ НАД РАБОТОЙ ПО ВНЕСЕНИЮ ИЗМЕНЕНИЙ

       Руководители часто недостаточно следят за процессом внесения изменений в программное обеспечение. Однако им важно было бы знать следующее. Что послужило причиной изменения — ошибки в программе или усовершенствования в интересах пользователя? Какие именно изменения были сделаны верно, проверены и закончены? Какие изменения были внесены ошибочно и требуют переделки? Какие изменения явились лишь временным выходом из положения? Над какими изменениями работают сейчас? В какие сроки предполагается закончить эту работу, и если работа уже закончена, то когда? (Или, что еще важнее, какой из вариантов программного обеспечения содержит эти изменения?) Какие существуют возможные выходы для сопровождающих программистов и пользователей, зашедших в процессе внесения изменений в тупик? Увеличивается ли объем изменений или уменьшается? (Это ключ к ответу на еще более важный вопрос: улучшается или ухудшается программное обеспечение? Увеличивается или уменьшается количество неустраненных неполадок? (Это позволит судить о том, достаточна ли квалификация коллектива сопровождающих программистов, чтобы справиться с возложенной на него работой.)
       Для того чтобы получить ответы на все эти вопросы, руководителю следует иметь достаточно простую и четкую систему учета изменений, вносимых в программное обеспечение. В основу такой системы следует положить два организационных соображения. Первое — применять какой-либо стандартный бланк, позволяющий отразить вносимые изменения. Примером такого бланка может


Рис. 4.2.2-1. Предлагаемая форма бланка отчета об изменениях в программном обеспечении.

ОТЧЕТ О СОСТОЯНИИ ИЗМЕНЕНИЙ В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ
Номер ОИП5 Первоначальный вариант Исправленный вариант Версия Описание
25 9/20/80 10/20/80 4.7 ? В момент, когда система заканчивает выполнение процедуры, прозвучал звуковой сигнал
26 9/20/80 10/17/80 4.7 ? Нарушена непосредственная связь с библиотекой стандартных подпрограмм
27 9/21/80 10/22/80 4.6 Отсуствует запись работы библиотеки
28 9/21/80 10/20/80 4.7 ? Проверка неработающей команды
29 9/23/80 9/23/80 4.6 Поступило сообщение: не работает оператор;


Рис. 4.2.2-2. Образец отчета о внесении изменений.

       быть “Отчет об изменениях в программном обеспечении” (ОИПО), который будет содержать данные как о природе ошибок, так и о способе ее устранения. Второе — вести “Отчет о состоянии изменений в ПО системы” или “Отчет о развитии изменений в ПО системы” на основе данных файла текущих изменений. Такие отчеты дают ответы на приведенные выше вопросы. Примеры такого бланка и таких отчетов даются соответственно на рис. 4.2.2-1 и 4.2.2-2. Более подробно эта тема обсуждается в работе [7].
       Важно не только вести учет и писать отчеты о возникающих неполадках. Не менее важно знать, в каких случаях и как долго следует вести этот учет.
       Обычно в жизненном цикле программного обеспечения огромное множество ошибок бывает обнаружено еще до того, как возникает необходимость их формального учета. Например, ошибки, возникающие на стадиях анализа и проектирования, обычно не фиксируются, так как они устраняются на этапе определения спецификаций и реализации по мере их обнаружения. Даже на стадии проверки учет ошибок из-за большого количества обычно не ведется и часто их можно устранить быстрее, чем зафиксировать. Формальная система учета становится необходимой лишь во время приемочной проверки, или передачи системы пользователю, или интеграции системы.
       Причем не столь важно, каким образом организованы учет и контроль за внесением изменений, важно, чтобы они были организованы. Во многих случаях лучше всего этот учет осуществляет сам сопровождающий программист. Однако в больших или сложных системах, особенно там, где за сопровождение отвечает большая группа сотрудников, целесообразно иметь специальное подразделение, которое занималось бы составлением отчетов, черпая необходимые сведения из файла изменений программного обеспечения.

4.2.2.1. Отчеты об изменениях в программном обеспечении

       Независимо от того, на кого возложена организация сопровождения, после запуска системы следует составить “Отчет об изменениях в программном обеспечении” (ОИПО) и присвоить ему порядковый номер. В ОИПО должны быть ясно описаны и обоснованы признаки ошибки, а также дана информация, необходимая и достаточная для устранения ошибки.
       Возможны следующие типы ошибок, которые следует включать в отчет:
       1. Функциональная неисправность программного обеспечения (встроенного или интерфейсного).
       2. Ошибка в документации.
       3. Неэффективность программного обеспечения.
       4. Ошибка при выполнении теста (процедуры).
       Необходимо установить приоритет устранения ошибки. Приэтом следует принимать во внимание различные факторы. Например, повлияет ли ошибка на работу программы? Какова возможность ее устранения? В какой степени ошибка тормозит работу пользователя? Следует указать относительную важность самой работы. Приоритет необходимо незамедлительно внести в бланк ОИПО.
       Как только бланк ОИПО заполнен, его следует передать соответствующей организации, занимающейся программным обеспечением. Сопровождающий программист должен ознакомиться с ОИПО, чтобы установить, имеет ли этот отчет отношение к отрезку программы, над которым он сейчас работает, и определить приоритет устранения ошибки. Затем ОИПО нужно поместить в папку в соответствии с установленным приоритетом. Приступая к работе над ОИПО, сопровождающий программист анализирует ошибку и определяет возможный путь ее устранения. Результат анализа отмечается в бланке ОИПО. Затем характер исправлений представляется на рассмотрение совету по внесению изменений.
       Как только совет выносит одобрительное решение, изменение кодируется и включается в программу. Исправленная программа, включающая исправления по одной или, возможно, нескольким ошибкам, затем прогоняется при тех же условиях, при которых она давала сбой. Если программа выдерживает эту проверку, она подвергается регрессивной проверке, имеющей целью установить, не были ли внесены новые ошибки в процессе исправления. Если любой из этих тестов дает отрицательный результат, следует вновь разработать исправление, вновь кодировать и вновь проверить его. Если же все тесты прошли успешно, программное обеспечение можно считать готовым к передаче пользователю (одобренный тест, листинг и т.п.). С точки зрения организации этот процесс графически показан на рис. 4.2.2.-3.


Рис. 4.2.2-3. Пример организации обработки потока ОИПО.

4.2.2.2. “Отчет о состоянии изменений в программном обеспечении системы”

       Разработчики, пользователи и руководители должны постоянно быть в курсе каждого отдельного изменения и состояния программного обеспечения в целом. Для этого нужен отчет о состоянии изменений.
       “Отчет о состоянии изменений” составляется на основе информации, содержащейся в файле ОИПО. В отчете необходимо в соответствии с приоритетом отразить следующее:
       1. Вновь возникшие ошибки, их природу и способы устранения.
       2. Старые неисправленные ошибки, их природу и возможные способы исправления.
       3. Ошибки, исправленные за период, истекший с момента составления предыдущего отчета, их природу и способы устранения.
       4. Данные о развитии изменений — графа, содержащая подсчет количества ответов о нерешенных проблемах за все время, а также сведения о частоте поступления таких отчетов.
       “Отчет о состоянии изменений” должен давать представление о любой ошибке в программном обеспечении, а также возможность проверить, нет ли такой ошибки в списке возможных неисправностей. Отчет должен наглядно показывать, как продвигается процесс устранения ошибок.
       Очень важным является вопрос распределения “Отчетов о состоянии изменений”. Совершенно очевидно, что содержащаяся в них информация необходима для руководителя, чтобы он мог составить представление о положении дел, а также о профессиональном уровне и качестве работы сопровождающих программистов. Не менее важна эта информация и для пользователей, которым интересно узнать, каким образом сопровождающий программист ликвидирует возникающие неисправности, а также когда именно коррекция будет закончена. Пользователям также необходимо знать, какие изменения внесены и в каком варианте программы.
       “Отчеты о вносимых изменениях” являются важным связующим звеном между руководителем и сопровождающим программистом. Они также связывают сопровождающего программиста с внешними организациями.

4.2.3. АТТЕСТАЦИЯ

       В сопровождении программного обеспечения есть проблема, существование которой не всегда признают даже опытные руководители и программисты. Часто внесение даже одного изменения в программное обеспечение расстраивает ранее идеально работающую программу. Таким образом, в задачу сопровождения входит не только внесение изменений в программу, но и забота о том, чтобы оно не привело к возникновению новых ошибок. По этой причине аттестация измененного программного обеспечения особенно важна. Очевидно, что измененное программное обеспечение, прежде чем оно будет возвращено пользователю, должно пройти своеобразную проверку/аттестацию, подтверждающую его работоспособность. Назовем ее верификацией. Более того, такой же проверке следует подвергать и те части программного обеспечения, в которые не вносились изменения.
       Набор тестов должен охватывать весь процесс сопровождения программного обеспечения и осуществлять как проверку измененных частей программы, так и выявление регрессионных ошибок (т.е. ошибок в одной части программы, вызванных несогласованными изменениями в какой-либо другой ее части). Однако, поскольку такое тестирование необходимо программе уже тогда, когда она впервые написана, верификация относится не только к процессу сопровождения. По этой причине мы не станем обсуждать ее здесь подробно.
       Однако у верификации есть некоторые части, относящиеся только к сопровождению. Дело в том, что к моменту начала сопровождения в программном обеспечении уже имеется набор тестов и других средств, необходимых для верификации. Они были созданы на стадиях его разработки и приемочных испытаний. Все эти средства контроля следует максимально использовать на стадии сопровождения, во-первых, для того, чтобы сократить объем работ по разработке новых тестов, а во-вторых, чтобы убедиться в том, что сопровождаемая программа подвергалась ранее не менее тщательной проверке. Средства контроля должны включать верификацию, позволяющую убедиться в том, что программа по-прежнему удовлетворяет требованиям по времени и объему занимаемой памяти, а также проверку надежности, которая показывает, выполняет ли программа свои функции или нет.
       Кроме того, следует позаботиться об обнаружении регрессионных ошибок, о которых упоминалось выше. Вообще говоря, это не составляет труда, так как первоначально разработанный набор тестов достаточно велик, чтобы осуществить проверку программного обеспечения независимо от текущих изменений. Несмотря на это, существующий набор тестов в процессе сопровождения следует пополнять, включая специальные тесты, направленные на оценку самых последних изменений. Нередко обнаруживается, что (n + 1)-е изменение уничтожает n-е. Такие специальные тесты могут выявить эти ошибки.
       Пожалуй, самым важным для процесса проверки программного обеспечения (ПО) является то, что он должен быть повторяющимся. Проверка работоспособности программы должна быть неоднократной, так как один и тот же тест может пройти на стадии разработки и давать сбои на последующих стадиях из-за внесенных в программу изменений. Поэтому важно, чтобы тесты легко прогонялись, а их результаты просто анализировались.
       В дополнение к анализу результатов тестирования разработаны две основные методики контроля. Первая представляет собой самоконтроль программного обеспечения. В этом случае не только проверяется наличие ошибок в ПО, но и производится обнаружение этих ошибок и выдача сообщений о них. Такая методика широко пр меняется для проверки компиляторов и представляет собой программу, которая выполняется после процесса компиляции с целью проверки ее работоспособности и причины сбоя.
       Вторая методика контроля основана на сравнении файлов. В том случае, если самоконтроль применить трудно или невозможно, подготавливают специальный файл, содержащий правильные результаты тестов. Сразу же после выполнения теста полученные результаты автоматически сравниваются с правильными ответами, содержащимися в файле с помощью программы сравнения файлов (разд. 3.2.1.1). Она может быть либо программой общего назначения, используемой для сравнения исходных файлов, либо программой специального назначения, созданной для выделения и объяснения не только самих сбоев, но и их возможных причин в зависимости от целей теста.
       Внимательный читатель, вероятно, заметил, что в контексте существует сходство между понятиями “аттестация программного обеспечения” и “организация разработки программного обеспечения, именуемого тестированием” [29, 35]. Действительно, эти два понятия очень близки, так как их функции и назначение практически совпадают. Нередко аттестация программного обеспечения является составной частью методики проверки результата сопровождения, если таковая существует. И возможно, это наиболее правильное решение. С другой стороны, в организациях, где проверка результата сопровождения не производится, выполнение аттестации программного обеспечения может осуществляться по той же схеме, по которой она проводилась на стадии разработки. Так же как и выше, в этой главе основная цель состоит в том, чтобы обеспечить проведение аттестации, а не в определении ее места в организационной структуре.

4.2.4. КОНФИГУРАЦИОННОЕ УПРАВЛЕНИЕ

       Преимущества и проблемы конфигурационного управления относятся не только к сопровождению. Однако здесь имеет место дополнительная задача, о которой следует поговорить отдельно. Это задача управления версиями.
       По мере того как программное обеспечение претерпевает изменения, пользователь получает все новые и новые версии программного обеспечения. Идеальным был бы такой вариант, когда каждая новая версия полностью вытесняла бы предыдущую. Но, как все мы прекрасно знаем, жизнь далека от идеала. (Об этом говорилось в разд. 3.2.1.) На самом деле происходит примерно так:
       1. Данная программа используется сразу во многих учреждениях. Не все новые версии достигают этих учреждений одновременно и не все они одновременно применяются, несмотря на настойчивые требования сопровождающего программиста. В результате случается неизбежное: сообщение об ошибке или изменении накладывается на предыдущую версию системы и сопровождающего программиста могут попросить внести изменение в одну из устаревших версий программы. Таким образом, в рамках конфигурационного управления приходится заниматься еще одним видом работ — составлением библиотеки всех когда-либо существовавших версий с набором соответствующих документов. Совершенно ясно, что такое положение недопустимо. И здесь требуется принимать скорее административные меры, чем затрачивать усилия технического персонала. Тем не менее в тех случаях, когда выхода нет, задачу приходится решать сопровождающим программистам, и ее решение должно быть найдено.
       2. Версия n + 1, переданная пользователю, позволила исключить многие ошибки в программном обеспечении системы, однако в свою очередь привела к возникновению дополнительной ошибки, которой не было в версии n. На время, пока пострадавший пользователь дожидается устранения ошибки в версии n + 2, ему нужен какой-нибудь временный выход, чтобы продолжить работу. Можно, конечно, вернуться снова к версии л, которая все же позволяла получгпъ результаты счета. Но в этом случае получается ситуация, описанная в п.1.
       Выход один: сопровождение необходимо организовать так, чтобы постоянно работало несколько версий.
       В результате можно сделать вывод, что конфигурационное управление в каждом отдельном случае должно обеспечить работу не только одной завершенной версии программного обеспечения, но и целого набора версий и каждая из них должна выдавать результаты, за достоверность которых отвечает сопровождающий программист. (Заметим, что этот набор может пополняться не только за счет самых новых версий.) И опять вопрос о том, должно ли конфигурационное управление быть выделено в отдельное функциональное звено в организационной структуре сопровождения или ответственность за него должен нести каждый сопровождающий программист, не так уж важен. Главное, чтобы конфигурационное управление осуществлялось.
       Все известные методы конфигурационного управления, применяемые на стадии разработки [29, 31], применимы и для сопровождения, причем на стадии сопровождения они расширяются и углубляются. Практически для многих случаев конфигурационное управление нужно только на стадии сопровождения.
       Интересное обсуждение автоматизированного подхода к данной проблеме дается в работе [10].

4.2.5. ВОЗМОЖНЫЕ ОРГАНИЗАЦИОННЫЕ СТРУКТУРЫ СОПРОВОЖДЕНИЯ

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


Рис. 4.2.5-1. Организационная структура работы в режиме разделения времени: СПО производится той же организацией, которая проводит разработку программного обеспечения. Нередко эта работа делается одними и теми же сотрудниками.


Рис. 4.2.5-2. Организационная структура “Двуглавый Дракон”: СПО производится в другой организации, независимой от той, где было разработано ПО.


Рис. 4.2.5-3. Организационная структура “Зонтик”: СПО подчинено тому же руководителю, что и разработка ПО, но производится одной или более независимыми организациями.

       Задача этого раздела состоит в том, чтобы предложить читателю несколько возможных способов организации процесса сопровождения программного обеспечения. Мы не претендуем на то, что эти способы наилучшие. И с учетом этой оговорки предлагаем вниманию читателей рис. 4.2.5-1 — 4.2.5-3.

4.3. ДОКУМЕНТАЦИЯ К СОПРОВОЖДЕНИЮ

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

4.3.1. ПОЧЕМУ МЫ ЗАБЛУЖДАЛИСЬ?

       Программисты вообще не любят документацию. Похоже, что наличие черт характера, необходимых для того, чтобы быть программистом, исключает способность и желание составлять в словесной форме описания созданных программ.
       Эта проблема, появившаяся одновременно с самой профессией программиста в 50-е годы, должна лежать в основе любого обсуждения проблемы документации. Здесь, по-видимому, от руководителя требуется “политика кнута и пряника” независимо от того, как бы глубоко программисты ни осознавали необходимость ведения документации. Если предоставить программисту возможность заняться еще девятью делами, то он обязательно отложит документацию на десятое место. А если это так, то руководитель ни в коем случае не может оставить ведение документации без контроля. Чтобы добиться высокого технического уровня документации, руководителю необходимо постоянно уделять этому вопросу внимание.
       Следует рассмотреть здесь и еще один немаловажный фактор, сами руководители обычно не любят вникать в детали программирования. Возможно, это был основной мотив, по которому человек оставил программирование и занялся административной работой.
       Однако и сам характер работы руководителя часто не позволяет вникать в подробности выбора инструкций в Ассемблере или типов операторов в ЯВУ. К сожалению, необходимость заниматься общими вопросами постепенно уводит руководителя в сторону от программирования, так что в конце концов он перестает понимать смысл тех программ, за работу которых несет ответственность. И все же, какой бы критерий ни избрал руководитель при оценке “качества сопровождения”, его практически невозможно оценить, не вникая во все детали. А это значит, что надо уметь читать распечатки программ.
       Но чтение распечаток программ и есть то первое, от чего отказывается человек, как только его выдвинут на руководящую должность. Итак, складывается критическая ситуация: те, кто несет наибольшую ответственность за качество сопровождения, оказываются наименее способными оценить его.
       Совершенно ясно, что эта проблема так или иначе затрагивает все области мира программного обеспечения. Но в данном разделе нас интересует, каким образом эта проблема затрагивает документацию программного обеспечения.
       Во всяком случае компромисс между неприязнью программистов к документации и нежеланием руководителей читать программы неизбежно приводит к плохим результатам. Поскольку программисты не берут на себя ответственность за ведение документации, ее берут на себя руководители. А если это так, то они ни за что не согласятся поместить документацию в программу, потому что тогда они не смогут ее читать. В результате во всех организациях документация пишется в виде текста и хранится в томах, отдельно от программы.

4.3.2. ЧЕМ ПЛОХА ОТДЕЛЬНАЯ ОТ ПРОГРАММЫ ДОКУМЕНТАЦИЯ?

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

4.3.3. КАК ПРАВИЛЬНО ВЫЙТИ ИЗ ЭТОГО ПОЛОЖЕНИЯ?

       А как же выходят из положения программисты, когда им надо пересмотреть кусок программы? Они обращаются к листингу. Листинг всегда точен, поскольку это программа в полном смысле слова. По той же причине он содержит максимальный объем информации. Итак, единственно точным и полным документом на современном этапе часто является листинг. Это и есть единственно разумное решение проблемы внутренней документации к программному обеспечению. Она должна быть удобно читаемой программой с комментариями в листинге. При таком решении все пояснения к работе программы находятся в закодированном виде в самой программе. Если в программу вносятся изменения, то вероятно, что изменения будут внесены и в ее описание (хотя полной гарантии здесь нет!). Кроме того, пояснения в листинге скорее всего будут легко восприниматься именно той категорией людей, для которых они предназначались, т.е. сопровождающими программистами. Причем они будут находиться в той части программы, где программисту удобнее всего будет найти их. Полнота и точность листинга, несомненно, положительно скажутся на документации.
       Некоторые новейшие течения в современной вычислительной технике отражают следующую точку зрения: структурное программирование позволяет создавать программы, которые на логическом уровне иногда бывают само документирующимися. В особенности это осуществимо в языках с адекватными управляющими структурами, в которых системы индентации ( indentation ) позволяют с помощью графических средств облегчить понимание программы. (Из этого не следует, однако, что работу и смысл этих программ можно понять без комментариев). Кроме того, языки и загрузчики, обеспечивающие использование удобных для чтения и самодокументирующихся имен, делают еще больший шаг к самодокументирующемуся программированию. Например, DOVT лишено всякого смысла и выглядит загадочно, тогда как самоопределяющееся имя процедуры DO VALIDITY TEST означает “провести проверку достоверности”. (Заметим, однако, что достоинства здесь легко могут обернуться недостатками, например, если из-за невнимательности опустить самоопределяющееся имя или если нарушить правило перехода от него к мнемоническому имени. Заметим также, что большинство современных загрузчиков ограничивает возможность внешних ссылок использованием заимствованного из Фортрана стандарта шестизначных имен.)
       Как бы то ни было, правильным ответом при решении вопроса о внутренней документации является переход от широко применяемого в настоящее время отдельного текста к обширным комментариям непосредственно в распечатке программы. Эти комментарии должны содержать легко читаемые имена и иметь графически ясную структуру. В результате будет получена полная и точная внутренняя документация с достаточным уровнем детализации (назовем ее документацией детального уровня).
       Выше упоминалось о том, что внутренняя документация может служить описанием системы и может быть положена в основу отчета о разработке. Отметим, какой ясной становится структура документации после того, как документация детального уровня перенесена в распечатку программы, и теперь очевидно ее отличие от документации высокого уровня. Документация высокого уровня представляет собой отдельные от программы тома текста. Теперь, когда мы знаем различие между этими двумя видами документации, можем указать дополнительные функции, присущие только внутренней документации: она содержит информацию о проектном решении и основных его целях. Кроме того, мы можем связать воедино высокий уровень документации с более низкими ее уровнями. Внутренняя документация может содержать объяснения роли компонентов программного обеспечения среднего уровня и указаний к ним, которые связывают воедино документацию высокого и детального уровней.
       Исходя из всего сказанного выше, мы можем теперь дать определение качественной внутренней документации.
       I. Определение документации высокого уровня (документ, который, возможно, имеет небольшой объем).
       а) Общий обзор структуры.
       б) Общий обзор базы данных.
       в) Данные о результатах проектирования.
       г) Основополагающие идеи.
       д) Структура(ы) среднего уровня.
       ж) Указатели информации детального уровня в листинге.
       II. Определение документации детального уровня (распечатки программы).
       а) Комментарии, представляющие собой:
          1) подробное описание структуры;
          2) подробное описание базы данных;
          3) подробное описание функций;
          4) особенности реализации.
       б) Легко читаемые имена.
       в) Индентированная структура программы.
       Раскроем более подробно приведенные выше критерии.
       I. Определение документации высокого уровня.
       а) Общий обзор структуры — рисунки с надписями, показывающие структурную схему всей системы в целом. Следует также включить функциональную блок-схему, на которой видна работа основных компонентов системы. Еще лучше будет расширить блок-схему, добавив: 1) оверлейную структуру (если таковая имеется); 2) порядок работы; 3) поток данных. Если все это невозможно уместить на одной блок-схеме, следует использовать их несколько.
       б) Общий обзор базы данных — рисунки с пояснениями, показывающие роль данных в системе в целом. Каковы основные файлы, основные структуры, основные наборы данных? Как и где они используются.
       в) Данные о результатах проектирования — это информация об истории проектирования (о ней говорилось в разд. 3.2.3.1). Часто это рукописные записи, снабженные краткими ссылками.
       г) Основополагающие идеи — этот пункт чаще всего пропуска ется программистами. Почему программа построена именно таким образом? Какой стиль программирования применялся? Какие цели ставились перед программой? Многие программисты, возможно, и не подозревают о том, что существуют основополагающие идеи. И тем не менее они есть, и эта часть документации очень важна.
       д) Структура среднего уровня — что должен знать читающий, если у него есть вся информация из п.“а”, чтобы он мог обратиться к листингу и понять всю документацию детального уровня, приве денную в нем? Здесь должны содержаться ответы на этот вопрос, которые могут быть достаточно сложными, если система большая. После п.“г” эта информация занимает второе место в том смысле, что сопровождающие программисты часто опускают ее.
       е) База данных среднего уровня — так же как п.“д”, этот пункт должен стать связующим звеном между всеобщей базой данных и листингом.
       ж) Указатели информации детального уровня в листинге — важно, чтобы информация детального уровня была помещена в листинге, но не менее важно иметь возможность легко находить ее там. Документация высокого уровня должна помочь сопровождаю щему программисту ориентироваться в листинге. Где процедура HOOPLA? Где структура данных FRAMMIS? Где кластер CLOISTER?
       II. Определение документации детального уровня.
       а) Комментарии — правильное составление комментария подробно обсуждалось в разд. 3.2.2.1.
       б) Легко читаемые имена — условия поименования обсуждались в разд. 3.2.2.1.
       в) Индентированная структура программы — структура программы обсуждалась в разд. 3.2.2.1.

4.3.4. ПРОБЛЕМЫ, КОТОРЫЕ ПОДЛЕЖАТ РЕШЕНИЮ

       При всей стройности предлагаемой системы ведения документации она по-прежнему имеет слабую сторону, в основе которой лежат два факта. Вспомним о том, что программисты не любят документацию, равно как руководители — вникать в детали. Поместив детальную документацию в листинг, мы не дали окончательного ответа на вопрос. Даже, напротив, мы усугубили неприязнь руководителей к деталям. Руководитель все также несет ответственность за внутреннюю документацию, только теперь ему надо обращаться за ней именно туда, куда ему меньше всего хочется заглядывать, — в листинг. И все же есть два соображения, позволяющие примирить между собой все противоречивые интересы, решив таким образом эту проблему. Во-первых, программисты скорее станут создавать хорошо комментированный листинг, чем писать документацию. Таким образом облегчится и работа руководителей. Во-вторых, руководители обязательно должны уметь читать листинги. Руководитель программного обеспечения, избегающий чтения листингов, выглядит так же странно, как руководитель производства, изготовляющего телевизоры, который не хочет видеть продукцию, за которую он отвечает. Руководитель должен уметь проверить продукцию, за которую он отвечает. А листинг в полном смысле слова является продуктом программного обеспечения.
       В настоящее время руководители судят о создаваемых во вверенных им организациях программах по документации (которая не является собственно программой и часто не отражает точно ее смысл). В результате во многих организациях появилась система параллельного документирования, при которой в документации описывается такое программное обеспечение, которое нужно руководству, а в листинге — такое, какое есть на самом деле. При таких условиях смешно говорить о руководящем контроле. Если же принять то положение, что руководители должны читать листинг хотя бы на уровне комментариев, а по возможности и в большем объеме, исчезает последнее препятствие к ведению документации в листинге.
       Остается, однако, высказать свое мнение о том способе ведения документации, который подробно обсуждался, но достижения которого пока невелики, — о самодокументирующемся программном обеспечении. Программисты могут писать его и полагаться на него, руководители (неожиданно вспомнив то, что умели в свою бытность программистами) могут контролировать и использовать его. Но не надо забывать, что обзорный документ высокого уровня остается жизненно необходимым, а самодокументирующееся программное обеспечение, хотя и становится все реальнее, по-прежнему недоступно.

4.4. ОБОРУДОВАНИЕ ДЛЯ СОПРОВОЖДЕНИЯ

       Сопровождающий программист, хотя мы и назвали его невоспетым героем, такой же человек, как и разработчик программного обеспечения. Поэтому может показаться абсурдным разговор о каком-то специальном оборудовании для программного сопровождения.
       В какой-то степени это так и есть. Раз сопровождение программного обеспечения является составной частью мира разработки программного обеспечения, сопровождающему программисту следует создать такие же условия, как и разработчикам программного обеспечения. Если в вашем учреждении у всех отдельные комнаты, то они должны быть и у сопровождающих программистов. Если у вас сотрудники располагаются группами в небольших помещениях, также должны располагаться и сопровождающие программисты. Если у вас огромный зал, где рабочие места тянутся рядами, насколько хватает глаз, тогда пусть также сидят и они.
       Но есть одна особенность: сопровождающим программистам нужно много места для хранения материалов. Им нужны ящики для возвращенных распечаток, книжные шкафы для документации, перфокарт, магнитных лент, а также дисков с различными версиями, к которым будут возвращаться. Сама идея возврата к версиям предполагает, что сопровождающий программист отвечает за n версий. Даже если число n невелико, оно всегда больше 1.
       Эта особенность налагает дополнительные заботы на группу конфигурационного управления. Обычно эта группа сохраняет все версии программного обеспечения независимо от того, являются ли они действующими в данный момент или нет. Но даже сопровождающий программист, при условии что сопровождение и конфигурационное управление производятся разными людьми, имеет свои особые нужды. Как правило, действующих версий даже одного куска программного обеспечения вполне достаточно, чтобы сопровождающему программисту потребовалось специальное место для хранения документации. Всегда бывает легко узнать, где работают сопровождающие программисты, потому что над их рабочими местами возвышаются целые пирамиды шкафов и ящиков!
       Хотя место для хранения материалов — это единственная специфическая особенность оборудования рабочего места сопровождающего программиста, есть еще одно условие их работы, о котором нельзя забывать, — тишина. Помните, что сопровождающий программист должен вносить новое, не разрушая старого. Умственное напряжение, необходимое для такой работы, требует спокойной обстановки, которую не нарушает стук пишущих машинок и болтовня сотрудников. Лучше всего позволяют обеспечить тишину специальные кабины для научной работы [14], где программист может спокойно подумать. Однако тогда затрудняется доступ к документации. По меньшей мере смешно представить себе сопровождающего программиста везущим в кабину для научной работы целую тележку листингов и документов. Как ни странно, почти нигде не думают о тишине. Руководители меньше всего заботятся о тишине как условии работы сопровождающих программистов, исключая те учреждения, где есть отдельные кабинеты. Если бы был проведен опрос мнения работников (в особенности сопровождающих программистов), важность тишины выступила бы на первый план.

ЛИТЕРАТУРА

1. Alberts, The Economics of Software Quality Assurance, Proceedings of the National Computer Conference, 1976.
       Дается экономический анализ жизненного цикла программного обеспечения с целью выделить в нем те моменты, когда следует применять методику обеспечения качества программного обеспечения SWQA. Обсуждаются эффективность методики SWQA и средства, применяемые в ней (структурное программирование, направленность разработки, ведущие группы программистов, средства автоматизации). Делается вывод, что методика SWQA должна быть направлена на раннее выявление и исправление ошибок этапа проектирования.

2. Allen. Lee, Tushman, The Relation of Internal Communication to R&D Project Performance as a Function of the Nature of the Project, M.I.T. Industrial Liaison Program WP 1016, 1977.
       Изучается влияние взаимосвязей на качество выполнения задания. Отмечается, что разными фукнциональными блоками следует управлять по-разному в зависимости от их свойств, назначения и количества специалистов.

3. См. [3] к гл. 3.

4. Branning, Willson, Schaenzer, Erickson, Modern Programming Practices Study Report, RADC-TR-77-106, 1977.
       Глава 6 этого отчета посвящена конфигурационному управлению, примененному фирмой Sperry Univac для создания четырех больших программ по заказу Военно-морского флота США. Дается оценка его эффективности.

5. См. [4] к гл. 2.

6. Bucher, Maintenance of the Computer Sciences Teleprocessing System, Proceedings of the International Conference on Reliable Software, 1975.
       Описываются работы по сопровождению программного обеспечения для конкретного задания. Делается упор на управление сопровождением. Показана роль Совета по внесению изменений и Комиссии по оценке системы. Обсуждаются протоколы изменений и методы тестирования.

7. Cashman, Holt, A Communication-oriented Approach to Structuring the Software Maintenance Environment, Proceedings of the ADA Environment Workshop, November 1979.
       Дается описание системы, позволяющей вести учет рабочих отчетов об ошибках в программном обеспечении. Система MONSTR позволяет осуществлять связь между сопровождающими программистами, занимающимися учетом ошибок в программном обеспечении.

8. Dodson, Resource Analysis for Data-proceessing Software, General Research Corp., 1977
       Рассматривается проблема затрат на программное обеспечение на современном этапе. Предлагаются направления для дальнейших исследований.

9. См. [8] к гл. 2.

10. См. [7] к гл. 3.

11. Finfer, Mish, Software Acquisition Management Guidebook, Cost Estimation and Measurement, System Development Corp. report SDC-TM-5772 / 007 / 02, 1978.
       Раскрывается методика оценки затрат на программное обеспечение для ВВС, а также рассматривается несколько примеров.

12. См. [8] к гл. 3.

13. См. [12] к гл. 3.

14. Glass, Environment and the Computer Programmer, PGR Quarterly Newsletter, Summer 1969.
       В работе речь идет об оптимальной обстановке для работы сопровождающих программистов, включая небольшие комнаты, рассчитанные на одну группу сопровождающих программистов, плюс отдельные кабины для научной работы, обеспечивающие полную тишину, и комнаты для заседаний, где проводились бы обсуждения.

15. Glass, Tales of Computing Folk: Hot Dogs and Mixed Nuts, Computing Trends, 1978.
       В притче “Устарелая технология и личное забвение” описывается драма руководи телей и программистов, которые потеряли квалификацию, отстали от жизни. В сказке “Небо падает” описывается трудное положение, в котором оказался руководитель, не способный идти в ногу с все возрастающими требованиями к программному обеспечению.

16. Glass, Lying to Management ... a Legitimate Problem Solution, The Power of Peonage, Computing Trends, 1979.
       Хроникально изображен конфликт между знающим, способным сопровождающим программистом и несведущим в вопросах сопровождения руководителем.

17. См. [12] к гл. 2.

18. См. [16] к гл. 3.

19. Hetzel, A Perspective on Software Development, Proceedings of the 3rd International Conference on Software Engineering, 1978.
       В работе приведены размышления одного руководителя по проблемам разработки npoграммного обеспечения. Автор считает “неэффективное” руководство основной (хотя и не единственной) причиной возникновения ошибок.

20. См. [15] к гл. 2.

21. Lehman, How Software Projects Are Really Managed, Datamation (January 1979).
       В работе собраны результаты анализа деятельности как научного, так и административного руководства программным обеспечением, в основном в области космонавтики. Наряду с самыми неожиданными результатами (например, системы, где отсутствовал руководящий контроль, оказались в среднем более продуктивными, чем системы, где такой контроль имеется) имеются и результаты, вполне предсказуемые (например, требования должны быть четко определены до начала разработки, а разработка должна быть закончена до написания программ). Упоминаются нетипичные методы руководства (например, стимулирующая оплата или установление размеров оплаты по системе аукциона).

22. См. [18] к гл. 2.

23. См. [7] к гл. 1.

24. Lindhorst, Scheduled Maintenance of Applications Software, Datamation (May 1973),
       Пропагандируется так называемое сопровождение по графику, при котором изменения в программном обеспечении учитываются, систематизируются и вносятся одновременно. При таком способе руководства сводятся к минимуму штат работников и количество операций, производимых с окончательным результатом программы.

25. Miller, A Service Concept for Software Auditing, Proceedings of the NSF Software Auditing Workshop, 1976.
       Предлагается ревизионная служба программного обеспечения как средство достижения высокого качества программного обеспечения. Отдельно обсуждаются типы проверок и возможные затраты, связанные с ними. Обсуждается также применение вспомогательных средств проверки.

26. MIL-ST483 (USAF), Appendix VI, 1970.
       Детально описываются форма и содержание требований технических условий программного обеспечения для военных целей. В технических условиях разработки (ч.1) описываются требования, в технических условиях на рабочие программы (ч.2) — внутренняя структура программного обеспечения.

27. См. [24] к гл. 2.

28. См. [38] к гл. 3.

29. Perry, Willmorth, An Investigation of Programming Practices in Selected Air Force Projects, RADC-TR-7-182, 1977.
       Раздел II.4.4 представляет собой открытое обсуждения организации и ошибок большого военного проекта, выполненного корпорацией системных исследований. Все выводы основаны на расчетах.

30. Pokorney, Mitchel, A Systems Approach to Computer Programs, A Management Guide to Computer Programming, American Data Processing, 1968.
       Даются самые первоначальные представления о роли вычислительных программ в руководстве системами ВВС. Определены элементы процесса создания программного обеспечения и место руководства в этом процессе. Приводятся примеры, некоторые из которых удручают.

31. Prudhomme, Implementing a Software Quality Assurance Program for the Viking Lander Flight Software, Transactions of Software 77 Conference.
       Речь идет о полете космического корабля “Викинг” с целью исследования поверхности Марса. Дается подробное описание средств обеспечения качества программного обеспечения системы “Викинг”, включающих: 1) средство гарантии качества проектирования, 2) конфигурационное управление, 3) верификационно-оценочную проверку, 4) отчеты о неудачах. В работе говорится о влиянии системы на некоторые другие функциональные блоки “Викинга”.

32. Viking Software Data, RADC-TR-77-168, Software Change Request / Impact Summary, pp. 222-228, 1977.
       Открыто обсуждаются отчеты об изменениях в проекте “Викинг”, в том числе и использованные в них формы и методы.

33. Sachs, Some Comments on Comments, SIGDOC Newsletter (December 1976).
       В работе речь идет о способах комментирования документации в программе. Автор подробно высказывает свое мнение о структурном программировании и “самодокументирующейся” программе.

34. Scholten The QARole in Software Verification, Transactions of Software 77 Conference.
       Предлагается подход к верификации программного обеспечения на основе жизнен ного цикла. Описывается влияние обеспечения качества программного обеспечения (SWQA) на стадии жизненного цикла. Автор отстаивает необходимость SWQA на каждой из стадий.

35. Smith, An Organization for Successful Project Management, Proceedings of the 1972 Spring Joint Computer Conference.
       Автор предлагает проект сбалансированной организации руководства с разделением ответственности между рядом сотрудников и системой формальных проверок. Определяет главную причину неудач в разработке программного обеспечения. Предлагает иметь группы разработки, интеграции и контроля, а также определяет функции каждой из них.

36. См. [50] к гл. 3.

37. См. [54] к гл. 3.

38. Trivedi Shooman, Error Data Collection in Software Systems, Computer Software Reliability; Many State Markov Modeling Techniques, RADC-TR-169, 1975.
       Обсуждается процесс написания отчетов об ошибках, выявляемых с помощью исследования моделей надежности. Предлагаются усовершенствования современной техники написания отчетов об ошибках.

39. См. [32] к гл. 2.

40. См. [57] к гл. 3.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/02h004.shtml