Джозеф Фокс - Программное обеспечение и его разработка

Недавно я был представлен новому помощнику секретаря комиссии по вопросам военно-морского флота, в которой я возглавляю комитет по вычислительным машинам,

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

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

«Инвертированные файлы» — звучит очень ясно, но ясности никакой нет. Это вовсе не файлы, а просто таблицы, в которых есть сведения о файлах. В них содержатся описания логических отношений между некоторыми областями файлов. Термины «операционная система» и «база данных» не очень информативны. «Метод доступа» — это не метод.

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

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

Необходимо предпринять несколько важнейших действий:

1) назначить единого директора по программному обеспечению;

2) производить в масштабе всей фирмы обучение ведущих специалистов;

3) установить стандарты на программное обеспечение;

4) запретить принятие решений на слишком низких уровнях.

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

Этот человек обязан:

1) установить стандарты на программы на уровне данной организации;

2) пересматривать и оценивать стандарты различных под разделений, их планы, расстановку сил, пересматривать работы по разработке программного обеспечения;

3) проводить обсуждения;

4) контролировать расходы по определению требований и проектированию программного обеспечения;

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

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

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

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

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

Добавлять новую функцию в программу или нет, должен ли пользователь иметь возможность выбора параметров и функций, какие нужны функции, сколько, как скоро их следует запрограммировать? Все эти вопросы входят в компетенцию руководителей разработкой. И, если их спросить, они, конечно же, ответят, что принимают эти решения сами. Однако знакомство с некоторыми работами по разработке программ, выпускаемых на рынок, показывает совсем другое. Руководитель работ по изготовлению какой-либо продукции запрашивает мнение руководителя работ по ее программному обеспечению, «когда можно будет сделать то-то и то-то». В большинстве случаев руководитель разработкой программного обеспечения спускается еще на пару уровней ниже и спрашивает мнение старших программистов. Именно они и «решают», когда можно будет сделать это «то-то и то-то», основываясь на собственных критериях и предстоящих работах.