Алгоритмы, структуры данных

5c8b6e8c

С 2000 по 2009 год: инженерия?


В первые годы нового десятилетия мы гадаем, что нас ждет в будущем. Сможем ли мы именно в этом десятилетии решить проблему качества программного обеспечения? Будет ли это десятилетием, когда разработчики и пользователи начнут воспринимать ошибку в программном обеспечении как нечто исключительное? Или в конце этого десятилетия мы опять станем возлагать на будущее те же надежды, что и в 2000 году: «Все программное обеспечение содержит ошибки, и каждый должен с этим смириться» (Charles C. Mann, «Why Software Is So Bad, and What Is Being Done to Fix It?» MIT Technology Rev., 17 June 2002)?

По словам Леса Хеттона (Les Hatton, «Does OO Sync With How We Think?» IEEE Software, vol. 15, no. 3, May 1998), «отраслевой стандарт на хорошее коммерческое программное обеспечение предусматривает около 6 ошибок на тысячу строк кода при среднем показателе в 30 ошибок». Таким образом, уровень ошибок последние двадцать лет практически не меняется, несмотря на объектно-ориентированную технологию, автоматические отладчики, более качественные средства тестирования и более строгий контроль типов в таких языках, как Java и Ada. Есть ли основание считать, что в этом десятилетии ситуация изменится? Хотя технические трудности растут, но серьезный стимул дает тот факт, что расходы из-за некачественного программного обеспечения также увеличиваются. Согласно данным отчета, опубликованного в 2002 году Национальным институтом по стандартам и технологии, «объем экономических потерь из-за ошибочного программного обеспечения в США достигает миллиардов долларов в год и составляет, по некоторым оценкам, около 1% национального валового внутреннего продукта» (Research Triangle Institute, «The Economic Impacts of Inadequate Infrastructure for Software Testing,» NIST Planning Report 02-3, May 2002).

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

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

Разработчики программного обеспечения, как минимум, столь же талантливы, как и те, кто работает в этих отраслях, поэтому мы уверены, что в будущем появится более качественное программное обеспечение. Мы, как сообщество, сможем решить эту задачу. Фактически, даже Билл Гейтс, по-видимому, осознал необходимость «расколоть этот крепкий орешек», как он назвал проблему качества программного обеспечения в своем письме, разосланном, по некоторым сведениям, всем сотрудникам корпорации 15 января 2002 года.

«Каждые несколько лет я рассылаю письма, в которых рассказываю о наивысшем приоритете для Microsoft. Два года назад это была реализация стратегии .NET. До того было несколько писем о том, насколько важным является Internet для нашего будущего, и каким образом мы можем сделать Internet действительно полезным для людей. За последний год стало ясно, что задача превращения .NET в платформу надежных вычислений (Trustworthy Computing) — важнее, чем любая другая часть нашей работы. Если мы этого не добьемся, люди попросту не захотят (или не смогут) использовать все остальные наши достижения. Надежные вычисления — это самый высокий приоритет для всего, что мы делаем. Мы должны вывести отрасль на абсолютно новый уровень надежности в вычислениях».

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


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

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

Джеймс Уайттеккер (jw@cs.fit.edu) — профессор факультета информатики Технологического института штата Флорида. Джеффри Воас (voas@cigital.com) — один из основателей и директор по науке компании Cigital.

James A. Whittaker, Jeffrey M. Voas, 50 Years of Software: Key Principles of Quality. IEEE IT Pro, November-December 2002. IEEE Computer Society, 2002, All rights reserved. Reprinted with permission.


Содержание раздела