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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прогнозы

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

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

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

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

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

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

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

1 ... 81 82 83 84 85 86 87 88 89 90

На этой странице вы можете бесплатно читать книгу Программное обеспечение и его разработка - Фокс Джозеф М. бесплатно.

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

Базы данных: конспект лекций - Коллектив авторов - Базы данных

Оставить комментарий