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

Автор книги: Джозеф Фокс

сообщить о нарушении

Текущая страница: 21 (всего у книги 21 страниц)

Ясного ответа на эти вопросы не было! Способ взаимодействия и используемые при этом соглашения зависят от того, зачем вы объединяете все эти вычислительные машины. «Как» идет следом за «почему».

Известно, что фирма General Motors так и не подписала контракт! Несмотря даже на то, что IBM и некоторые фирмы потратили по миллиону долларов, чтобы ответить на все запросы.

Фирма General Motors не новичок в деле использования вычислительной техники. И даже этот весьма квалифицированный пользователь не избежал соблазна, исходящего от «новых» методов, «новых» использований.

Распределенная обработка?

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

Выводы

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

Если мы не будем достаточно осторожны, оценивая размеры программ, организующих взаимодействие, то мы вскоре обнаружим, что получившаяся система 80 или 90 % времени тратит не на работу, а на это взаимодействие. Каждое подключение к сети независимого вычислителя (вычислительной машины или одиночного центрального процессора) усложняет связь между всеми остальными частями сети. Надо следить, чтобы эта сложность не затрудняла выполнение основной задачи системы – обработки данных.

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

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

Глава 8
Перспективы

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

Использование промышленных методов при разработке программного обеспечения

Разработка программного обеспечения становится все более управляемым процессом. Некоторые из наиболее мощных приемов, нашедших свое применение в последние несколько лет, многие десятилетия использовались в промышленности и вполне себя там оправдали. Вот примеры этих методов:

Работа на основе ветвящейся структуры

Руководство и управление конфигурацией

Возможность слежения

Инспекторские проверки (сквозной контроль)

Управление качеством

Верификация

Тестирование

Выборочные прослушивания

Руководство проектом

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

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

Период разобщенности	Работа на дому. Все гончары выполняли весь цикл работ в своей мастерской.
Объединения мастеров	Достигается экономия при выполнении вспомогательных работ. Основной производственный процесс не меняется. Но теперь централизованная группа сборщиков глины поставляет материал всем гончарам. Централизованная группа торговцев заведует всей торговлей. Кувшины, однако, изготовляются по старой технологии. Этот шаг не зависит от последующих шагов.
Разделение труда	Отдельные функции передаются тем людям, которые особенно хорошо выполняют именно их. Отделка всех кувшинов выполняется специальной группой художников. В книге «Здоровье нации» Адам Смит написал, что 10 неквалифицированных работников, работая независимо друг от друга, с трудом могут изготовить за день всего по одному гвоздю, но при разделении труда те же 10 человек в состоянии изготовить более 48 000 штук. Это начало понятия о сборочной линии.
Автоматизация	Значительная экономия средств позволяет выделить фонды на внесение исправлений в основной процесс, проходящий в мастерской. Горны и печи для обжига начинают использоваться с невероятной интенсивностью. Штамповка автоматизируется с помощью использования ветряных мельниц и паровых двигателей.
Сборочная линия	Разделение всего процесса на ряд отдельных операций, выполняемых над каждым изделием в установленное время.
Взаимозаменяемые части	В конце 1790-х гг. Эли Уитни предпринял попытку изготовить за 2 года 10 000 мушкетов. «Абсурд», – сказали ему. К 1807 г. он делал по 2000 штук в год, в шесть раз больше, чем государственный завод в Спрингфилде, шт. Массачусетс. Секрет заключался во взаимозаменяемости частей, достигнутой благодаря прогрессу в металлургии и металлообработке. Взаимозаменяемость частей стала одной из фундаментальных основ сборочных линий.

Разработка программного обеспечения все еще находится на ранних стадиях своей промышленной революции. Уже пройден этап объединения, возникли некоторые формы разделения труда, началась автоматизация, но вот взаимозаменяемости частей пока еще не достигли. (См. рис. 8.1.)

Да	До некоторой степени	Началась	Начались	Еще нет
Коллективный труд	Специализация работ	Автоматизация	Сборочные линии	Взаимозаменяемые части

Рис. 8.1. Аналогия между развитием программного обеспечения и ходом промышленной революции.

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

Терминология

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

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

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

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

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

Организационные требования

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

Что делать?

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

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

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

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

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

Единый директор по программному обеспечению

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

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

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

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

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

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

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

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

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

Стандарты

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

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

Решения на низших уровнях

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

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

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

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

Болезненные изменения

Переориентация на другое программное обеспечение может привести к чувствительным затратам по двум причинам. Первой оказывается новизна данной области. Многие исполнители просто незнакомы с ее размерами и характеристиками. Вторая причина связана с первой, но может удивить кого угодно. Большинство людей, занимающихся практическим программированием, отстали от века! Их просто необходимо или направить на учебу, или уволить. Наша отрасль развивается столь быстро, что большинство руководителей разработок обеспечения используют методы 20-летней давности. Для 90 % разработчиков программного обеспечения это «средневековье».

Большинство будет упорно это отрицать и сопротивляться всем изменениям. Это в некоторой степени защитная реакция («Кто это там будет меня учить?»), и в некоторой степени она основывается на высокой стоимости повышения квалификации («Я не могу позволить себе тратить время, деньги».). В таком последнем утверждении есть доля истины. Отсюда еще раз напрашивается вывод о необходимости иметь директора предприятия по программному обеспечению.

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

Обучение ведущих исполнителей

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

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

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

Прогнозы

1. Программное обеспечение станет решающим фактором, влияющим на качество продаваемых крупных информационных систем.

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

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

4. Разрыв между стремительным развитием микроэлектроники и инерцией разработки программного обеспечения станет наиболее известным примером неодолимой силы и недвижимого объекта. В результате разработка программного обеспечения достигнет небывалых высот. Это обязательно случится. В разработке программного обеспечения произойдет подлинная революция.

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

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

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

Прогресс

Не следует удивляться тому, что разработка программного обеспечения столь трудна. Мы уже видели, что всякая разработка трудна по определению. Если бы она была прогнозируемой, она не была бы разработкой.

Снова обратимся к мостам – простым, старым, скучным мостам и вспомним, что в 1870-х г. в США падало по 40 мостов в год. Новая технология подчинялась контролю человека чрезвычайно медленно.

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

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

За последнее десятилетие в деле разработки программного обеспечения произошел разительный прогресс. Гораздо более разительный, чем кто-либо мог предвидеть. Вступили в действие огромные системы – причем работают они хорошо и надежно. Все подверглось развитию – системное программное обеспечение, структурное программирование, языки, автоматические библиотекари, кросс-трансляторы и инструментальные комплексы. Мы сделали программирование более наглядным. Это звучит тривиально, но ведь просто жизненно необходимо, чтобы разработка программного обеспечения была управляемой и контролируемой.

Структурированные программы стали доступными для чтения. Великолепнейший сдвиг.

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

Сделав программное обеспечение более наглядным, мы смогли сделать его более управляемым. Мы повысили производительность труда.

Мы стали пользоваться общими программами, входящими в операционные системы и СУБД. Передача этих программ в пользование тысячам людей сделала ненужными огромные затраты на перепрограммирование.

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

Мы видим, насколько далеко мы ушли всего за 10 последних лет.

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