3.2.1. Правильность проектирования и планирование изменений

Явно выделенным шагом всякого этапа проектирования программ­ного обеспечения должна быть проверка правильности результатов, т.е. попытка найти ошибки перевода, возникшие на этом этапе.

Стоимость исправления ошибки тем ниже, чем раньше она будет об­наружена. Кроме того, вероятность правильно исправить ошибку на ран­ней стадии работы над проектом значительно выше, чем в случае, если ошибка обнаружена на более поздних этапах (рис. 3.3)

Хотя проверка правильности каждого отдельного этапа проектиро­вания проводится по разным методикам, можно сформулировать общую систему правил проверки в виде правила «n плюс-минус один». Вопросом пер­востепенной важности при проверке правильности проекта является при­влечение к этому делу «подходящих» людей. Наиболее «подходящие» люди – это те, в чьих интересах обнаружить все ошибки. Пусть, например, мы закончили n-й этап проектирования архитектуры системы. Проектиров­щики этапа n–1 – это авторы исходных внешних спецификаций, а проекти­ровщики этапа n+1 – это разработчики структуры программы. Именно им и следует доверить тестирование архитектуры системы.

Правило «n плюс-минус один» состоит в следующем: проверка пра­вильности этапа проекта должна осуществляться проектировщиками эта­пов n+1 и n–1. Это правило – еще один пример того, что интуитивно оче­видно, но редко применяется на практике. В случае необходимости должны быть установлены формальные процедуры, обеспечивающие ее применение.

Рис. 3.3. Основания для раннего обнаружения ошибок проектирования

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

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

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

Третье правило работы с изменениями – проверять правильность всякого изменения в такой же степени, в какой проверялось исходное ре­шение.

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

3.2.2. Требования к по

Программные проекты можно разбить на три группы: управляемые пользователем, контролируемые пользователем и независимые от пользо­вателя [2]. Последние в данном учебном пособии рассматриваться не бу­дут. Наиболее оптимален проект, контролируемый пользователем. Но, без­условно, желательно и участие в этом процессе организации-разработчика ПО. Если в управляемом пользователем проекте разработчик ПО не при­влечен к определению требований, это увеличивает его шансы непра­вильно понять или неправильно интерпретировать требования. И управ­ляемые пользователем, и не зависимые от пользователя проекты должны планироваться таким образом, чтобы обеспечить участие обеих сторон.

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

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

Разработка лабораторной работы, описанной в подразд. 3.2., отно­сится к проектам, контролируемым пользователем, причем в качестве пользователя выступают преподаватели, которые будут использовать дан­ную лабораторную работу в своих курсах.