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

ГЛАВА 2. РОЛЬ НАДЕЖНОСТИ В РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1. ВВЕДЕНИЕ

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

2.2. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММЫ

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


Рис. 2.1. Жизненный цикл программного обеспечения; распределение стоимости по фазам

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


Рис.2.2. Жизненный цикл программного обеспечения: распределение допущенных ошибок по фазам


Рис.2.3. Жизненный цикл программного обеспечения: распределение выявленных ошибок по фазам

Литература
       1. Воеhm. The High Cost Software Practical Strategies for Developing Large Software Systems. Addison-Wesley, 1975.
       2. Alberts. The Economics of Software Quality Assurance. — Proceedings of the National Computer Conference, 1976.
       3. Lientz, Swanson and Tompkins. Characteristics of Applications Software Maintenance. UCLA Graduate School of Management, 1976.
       Были проведены также исследования распределения ошибок, допущенных на разных фазах жизненного цикла программного обеспечения. Эти исследования обычно начинались после фазы задания требований и разработки спецификаций, в предположении, что спецификации разработаны правильно. Учитывались только ошибки, обнаруженные при сборке, приемо-сдаточных испытаниях или эксплуатации. Как следует из рис.2.2, большую часть составляют ошибки, допущенные при проектировании. Ошибки, допущенные при реализации, делятся на синтаксические ошибки языка программирования и ошибки языка управления заданием одной из ведущих фирм, поставляющих ЭВМ. Как показывают исследования, последний является причиной двух третей всех ошибок, допущенных на этой фазе.


Рис. 2.4. Жизненный цикл программного обеспечения: распределение стоимости устранения ошибки по фазам

Литература
       1. Bоеhm. Software Design and Structuring. — Practical Strategies for Developing Large Software Systems. Addison-Wesley,1975.
       2. Hecht, Sturm and Trattner. Reliability Measurement During Software Development. — Proceedings of the AIAA Conference on Computers in Aerospace, 1977.
       Выявление ошибок обычно не прекращается до конца жизненного цикла программного обеспечения. Наибольшее число ошибок обнаруживается после или во время приемо-сдаточных испытаний.

Литература
       1. Boehm. Software Design and Structuring. — Practical Strategies for Developing Large Software. Addison-Wesley, 1975.
       Стоимость устранения ошибок резко возрастает по мере прохождения разных фаз жизненного цикла. Стоимость сопровождения (на одну ошибку) очень велика.

Литература
       1. Stanfield and Skrukrud. Software Acquisition Management Guidebook. Software Maintenance Volume, System Development Corp., TM-5772/004/02, Nov., 1977.


Рис.2.5. Жизненный цикл программнего обеспечения: методы обеспечеимя надежности при переходе от одной фазы к другой

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

2.3. НАДЕЖНОСТЬ В ЖИЗНЕННОМ ЦИКЛЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

2.3.1. ТРЕБОВАНИЯ / СПЕЦИФИКАЦИИ

       На начальной фазе разработки программного обеспечения производится анализ предъявляемых к нему требований. Джонни-Надежность должен участвовать в рассмотрении и анализе системных и программных спецификаций, чтобы гарантировать корректность требований к функционированию и взаимодействию компонент программного обеспечения. Такое рассмотрение позволит убедиться в том, что к программному обеспечению предъявлены требования, которые действительно могут быть выполнены, а также в том, что эти требования достаточно четкие, законченные, корректные, проверяемые и создают предпосылки для выполнения требований к системе. Прежде всего следует уделить внимание основным проверяемым требованиям и задать численные значения, которые должны быть получены при анализе их выполнения. Проверяемыми считаются требования, определенные четко и однозначно. Например, необходимо потребовать, чтобы точность была в “пределах ±1 %”, а не просто “удовлетворительного решения задачи”.
       Матрицу требований, которая связывает все требования к программному обеспечению с требованиями к системе, а также аппаратно-программному и межпрограммному интерфейсу, необходимо ввести в состав спецификаций. Каждое требование к программе должно включать требования по надежности наряду с методикой его проверки и правилом приемки. При этом необходимо обеспечить однозначное соответствие требований к программному обеспечению и к надежности, которое также следует отразить в матрице требований. Джонни-Надежность проверяет полноту этой матрицы.

2.3.2. ПРОЕКТИРОВАНИЕ

       На этой фазе разработки требования преобразуются в проект, Джонни-Надежность участвует в проверке проекта, анализирует, насколько точно отражены в нем все требования к программному обеспечению. Алгоритмы и формулы могут быть проверены аналитически или путем моделирования. Должно быть установлено соответствие проекта основным требованиям. Анализ проекта, проводимый с целью его проверки, включает в себя следующее:
       1. Рассмотрение всех внешних функциональных связей (т.е. с аппаратурой и линиями связи). Проверка длины слов, форматов сообщений, необходимой памяти ЭВМ, времени выполнения и т.д. на соответствие требованиям, установленным в спецификациях.
       2. Рассмотрение всех внутренних функциональных связей, анализ форматов слов, темпа обмена и т.д. на взаимное соответствие.
       3. Анализ критических временных требований к системе с целью выяснения удовлетворяет ли им предлагаемый проект программы.
       4. Рассмотрение структуры программы в целом для проверки распределения требований по компонентам, распределения памяти, последовательности вычисленийи базы данных.
       5. Проверка соответствия проекта программы требованиям, предъявляемым оператором ЭВМ.

2.3.3. РЕАЛИЗАЦИЯ ПРОЕКТА

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

2.3.4. ОТЛАДКА

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

2.3.5. СОПРОВОЖДЕНИЕ

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

2.4. БОЛЬШИЕ И МАЛЫЕ ПРОЕКТЫ

       В этой книге делается попытка всесторонне осветить некоторую трудную проблему. Эта проблема заключается в различном подходе к большим и малым проектам. В настоящем параграфе выявляются эти различия и определяется то вчиянне, которое они оказывают на последующее изложение.
       Было бы неверным преуменьшать значение размера проекта. Большой проект может потребовать совершенно иного технологического и организационного подхода, нежели малый.
       Размер проекта определяется позже (в гл.5, где приводятся рекомендации). Однако, чтобы ввести читателя в курс дела, дадим следующие определения: будем называть проект малым, если в его создании участвует не более 5 программистов, средним — при числе программистов от 6 до 29, большим — если их число превышает 30. Можно не согласиться с этими определениями, так как они довольно произвольны, но нельзя не считаться с влиянием указанных различий. Для того чтобы пояснить это, рассмотрим ряд известных проектов и отнесем их к той или иной категории. Так, генераторы коммерческих отчетов или некоторые технологические средства, например трансляторы с Ассемблера, редакторы и др., представляют собой малые проекты; современные пакеты прикладных программ, загружаемые в оперативную память по частям, или более сложные технологические средства программирования, такие, как компиляторы с языков высокого уровня PL/1 и JOVIAL, относятся к средним проектам; система управления воздушным движением, использующая новейшие средства, такие, как самолет Е-ЗА с радаром на борту, или чрезвычайно сложные технологические средства, например операционная система IBM 360/370, — к большим проектам. “Узким местом” больших проектов является обеспечение взаимодействия между компонентами. Связь между людьми, связь между отдельными программами — все это требует особого рассмотрения и принятия специальных решений.
       С другой стороны, для малых проектов существуют свои проблемы (нехватка ресурсов, денежных средств для приобретения необходимых технологических программ и дефицит кадров для решения сопутствующих, но важных задач), которые также требуют разрешения.
       Программистам хорошо понятны трудности малых проектов. Их, конечно, много, но в принципе они преодолимы и уж по крайней мере известны.
       Другое дело — большие и даже средние проекты. В больших проектах приходится решать проблемы наилучшего укомплектования штатов, организации и технологии разработки. Как используются те или иные современные технологические методы в больших проектах? Например, далеко не полностью изучены способы применения в них перечисленных ниже технологических и организационных методов обеспечения надежности программ, которые обсуждаются в гл. 3 и 4:
       программирования сверху вниз;
       доказательства корректности;
       символического выполнения;
       создания бригады главного программиста.
       Однако сложность ситуации обусловлена не только трудностями применения новых методов; неясно, как использовать в больших проектах даже традиционные методы, в частности комплексирование и согласование программ.
       Доказано, что методы разработки больших и малых проектов должны быть разными. Поскольку это действительно так, необходимо разработать принципиально новый комплекс методов для использования в больших программных проектах. К сожалению, пока еще в этом направлении ничего не предпринимается. Решение ищут в увеличении формализма: специальные графики, официальные проверки по графикам, определенная в контракте и официально проверяемая документация, формальная система контроля и координации. В организации разработки программного обеспечения можно выделить несколько уровней. Для проведения системного анализа, взаимодействия с исполнителяхми, контроля качества, комплексирования системы, контроля изменений программ, тестирования программного продукта могут быть созданы отдельные подразделения. Такое решение, конечно, усугубляет проблему: если прежде взаимодействие было для больших проектов сложным вопросом, то теперь он еще более усложняется из-за необходимое! и корректирования и проверки работы подразделений. Таким образом, трудности большого проекта нелинейно возрастают в зависимости от его размера.
       Более того, формализация ограничивает свободу действий и инициативу участников) большого проекта. Для того чтобы сделать разработку управляемой, индивидуальные различия стремятся подчинить общим требованиям. Если, например, разработка проекта должна быть завершена к 12 ноября, то те, кто закончили ее быстрее, окажутся без дела, остальные же будут работать с перегрузкой, чтобы успеть к сроку. Графики должны не только отражать общий средний уровень, но и способствовать его повышению. Излишняя “плановость”, т.е. принуждение программистов уложиться в график делает их похожими на горошины в стручке, тогда как раньше считалось, что их работа не поддается планированию. И новая технология выглядит, скорее, формализацией работы группы исполнителей, чем инструментом, помогающим творческой деятельности. При такой организации разработки структурное программирование, например, приветствуется больше за ограничения, накладываемые на управляющие конструкции (“запретить оператор GOTO”), чем за выгоды, получаемые при использовании улучшенных управляющих конструкций (таких, как оператор IF-THEN-ELSE).
       Подводя черту, было бы неплохо привести ряд рекомендуемых решений. Однако, к сожалению, их слишком мало, если они вообще существуют. Одно из возможных решений — использование небольших бригад высококвалифицированных разработчиков вместо армии разработчиков средней руки — попросту не срабатывает. Уже сейчас имеется гораздо больше задач, ждущих своего решения, чем программистов, способных их решить. И высококвалифицированные разработчики, — хотя и главная, но небольшая часть из всей армии программистов, которых придется включить в работу. Все по связано, как отмечалось выше, с дефицитом кадров.
       Вероятно, единственно верным решением для больших проектов является разработка специальных методов. В одной из работ предлагается язык “межпрограммного интерфейса”, который позволит определить сложные связи между большим числом программ. Другим полезным средством могут служить таблицы перекрестных ссылок, которые используются как в системе, так и в компиляторах. Таким образом, исследователи в области программирования должны сосредоточить все свое внимание на проблемах больших проектов. К сожалению, многие специалисты стремятся работать там, где легче, а не там, где это действительно необходимо. (В сороковых годах в ходу было много анекдотов о “маленьком дурачке”. “Что ты здесь разыскиваешь?” — спрашивают дурачка в одном из них. “Я потерял ключи”, — отвечает он. “Где ты их потерял?” “Вон там”. “А почему ищешь здесь?” “Здесь светлее”. Светлее также и для исследователей, изучающих проблемы малых проектов. В увитых плющем зданиях нелегко изучать реальный проект, который разрабатывают свыше 30 человек.

Литература
       1. Brooks. The Mythical Man-Month. Addison-Wesley, 1975.
       Описывается опыт разработки и дается оценка результатов операционной системы IBM/360. Руководителю большого проекта рекомендуется создать небольшие бригады, организованные особым способом, использовать рабочие книги проектов, прибегнуть к изменяемой организации, применить наиболее эффективные технологические средства, образовать группу планирования и управления и другие методы.
       2. Kraft. Programmers and Managers. Springer-Verlag, 1077.
       Высказываются сожаления по поводу “дисквалификации-” технолога большого проекта. Особое внимание уделяется “плановости” задач, которые раньше выполнялись “творческими и, возможно, эксцентричными” людьми.
       3. DeRemer and Kron. Programming-in-the-Large VersusProgramming-in-the-Small. — IEEE Transactions on Software Engineering, June, 1976.
       Указывается на необходимость применения для больших проектов языка межпрограммных связей. Этот язык рассматривается как средство повышения надежности путем совершенствования организации производственных связей, обеспечения необходимых технологических средств и создания документации. Даются примеры его использования.
       4. Horowitz. Practical Strategics for Developing Large Software Systems. Addison-Weslcy, 1975.
       Сборник статей, посвященных отысканию решений проблем больших систем. Здесь приводятся статьи известных авторов о всех фазах жизненного цикла программы (за исключением сопровождения) и о руководстве большим проектом.
       5. Brown. Impact of MPP on System Development. — RADC-TR-77-121, 1977.
       Описывается практика современного программирования, использованная в большом проекте (в котором занято около 400 программистов) системы противоракетной обороны. Приводятся экспертные оценки. Показано, что эти методы позволяют повысить качество программ при незначительных затратах времени и средств.
       6. Prentiss. Viking Software Data. — RADC-TR-77-168, 1977.
       Подробно описываются трудности и успехи в создании программного обеспечения для космического центра. На разработку проекта “Викинг” ушло 1783 человеко-месяца и было разработано 278 575 строк исходного текста программ за четыре года.




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

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


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