Программное обеспечение и его разработка

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

При управлении большими работами должно быть очевидно, что нужно пользоваться минимально возможным числом исследований и новейших методов.

Почему же это должно быть очевидно? Это не так очевидно, как можно было бы подумать! В 1961 г. комитет, созданный по предписанию президента Джона Ф. Кеннеди для расследования причин воздушной катастрофы над Нью-Йорком, вынес рекомендации по автоматизации управления авиалиниями. Комитет настоял на том, чтобы Федеральное авиационное агентство (FAA) для всех новых систем покупало только «отработанные» вычислительные машины. Это ограничение было наложено потому, что в конце 1950-х г. FAA стала вкладывать деньги в разработку вычислительных машин — и деньги стали уходить в эту область, а не на разработку собственно систем управления авиалиниями.

Похожая история произошла в середине 1970-х г. в системе здравоохранения. Разработчики перестали заниматься созданием системы, которая могла бы удовлетворить запросы врачей, медицинских сестер, администраторов, специалистов и обслуживающего персонала, и занялись разработкой «сети» мини-ЭВМ и распределенной базы данных.

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

Небольшая консультационная компания потеряла 300 000 долларов — доход за несколько лет — при попытке закончить работы по контракту, в которых использовалась машина фирмы IBM «Series 1». Аппаратура была великолепной; а системное и инструментальное программное обеспечение было отработано не до конца. Каждый раз оказывалось, что люди натыкались на какую-нибудь неисследованную проблему. Программное обеспечение было новым! По этой причине фирма IBM не давала по нему никаких гарантий. И контракт был передан IBM.

Будет ли удовлетворен настоящий пользователь?

Совершенно необходимо руководить определением требований на всем пути от пользователей до программистов. Звучит это просто, но следы могут потеряться сразу в нескольких разных точках. Во всем цикле создания большой системы участвует очень много людей и организаций.

Рис. 6.22. Организации, занятые в одном проекте.

На рис. 6.22 показана весьма типичная организация работ над большим проектом. Истинные требования, поступающие от пользователя, могут подвергаться искажениям и на пути Л, и на переходе В. Меткой 1 мы преднамеренно отметили сразу два пути. Какой из них «правильный»? Они находятся в постоянном конфликте.

Пути 2, 3 и 4 тоже не являются «чистыми». Сколько проектов терпели неудачи из-за того, что проектировщики или программисты решали, что они знают,

что надо делать, а люди, стоящие выше на служебной лестнице, несут околесицу? Таких проектов было слишком много! Я видел системы, где программисты знали больше, чем проектировщики, и поэтому строили систему по-своему. Видел системы, где проектировщики «знали» все, что требовалось. Видел и системы, где ни один человек ни разу не поговорил с подлинным, настоящим пользователем. Короче говоря, искажения могут возникать и в точках А или В, и в точках 1, или 2, или 3, или 4, и все они плохо влияют на систему в целом.

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

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

Прослушивания

Я встречался с разными результатами прослушиваний, с такими, например, когда утверждалось, что все идет прекрасно — и так и было на самом деле, — и с такими, когда говорилось, что все идет хорошо — а затем наступала катастрофа! Иногда предупреждали о предстоящей неудаче, и она случалась. А бывало и так, что предсказанная катастрофа так и не наступала.

Другими словами, при прослушиваниях часто возникают ошибочные выводы! Те, кого вызывали на прослушивание, заявляли: «Мы знаем больше, чем эти эксперты; они ошибаются». И верно, часто так оно и было. Каким образом руководитель может определить, кто же прав? Не означают ли эти ошибки, возникающие в результате прослушиваний, что сама идея таких прослушиваний неверна?

Прослушивания очень важны