Программная инженерия

Распределенная разработка программного обеспечения сегодня стала нормой: современные средства связи позволяют объединять людей, находящихся по разные стороны океана, а минимизация издержек при разработке в развивающихся странах привлекает заказчиков из стран Европы и США. Кроме того, специалистов нужной квалификации может просто не оказаться «на месте», и тогда взаимодействие с удаленными рабочими группами или внешними подрядчиками окажется просто необходимым. Однако децентрализованная разработка программного обеспечения имеет и определенные недостатки.

Разработка программ точно в срок и должного качества — весьма сложная задача. По утверждению аналитиков, успешными сегодня оказывается не более трети таких проектов. Естественно, для повышения уровня их предсказуемости создаются различные методологии, стандарты и инструменты. Корпорация Microsoft предлагает свои рецепты организации процесса разработки программного обеспечения.

В ИТ-индустрии отмечается резкий рост интереса к модели качества СММ/CMMI, принятой сегодня во всем мире. По существу, СММ представляет собой систему оценки и проверки возможностей компании, зрелость которой соответствует одному из пяти уровней.

Сообщество Open Source ведет несколько ключевых проектов, среди которых, наряду с ОС Linux, — создание платформы разработки Eclipse. Вышедшая несколько лет назад из-под крыла корпорации IBM, сегодня эта открытая платформа интеграции инструментальных средств разработки приложений свободно распространяется в открытых кодах и развивается сообществом пользователей.

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

Многие полагают, что итеративная и инкрементальная разработка (iterative and incremental development, IID) — явление новое. Однако на самом деле истоки этого метода восходят еще к середине 50-х годов. На протяжении последующих десятилетий в его пользу высказывались выдающиеся теоретики в области технологии программирования; метод находил успешное воплощение во многих проектах.

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

Никлаус Вирт (Niclaus Wirth) бесспорно является одним из наиболее известных и почитаемых мыслителей в мире информатики. Профессор ETH Institute в Цюрихе, Швейцария, он является автором новаторских языков и систем программирования Pascal, Modula 2 и Oberon. В начале 70-х гг. он был одним из тех, кто ввел в практику принцип пошаговой разработки ПО. Он автор многих известных книг, среди которых признанные классическими "Algorithms + Data Structures = Programs" и "Systematic Programming". Вирт известен определенными и выражаемыми с абсолютной точностью взглядами на современное состояние культуры разработки ПО, поэтому интервью с ним всегда вызывают оживленную реакцию в компьютерном сообществе.

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

Стало правилом: всякий раз, когда выпускается новая версия программного продукта, существенно - порой на много мегабайт - подскакивают его требования к размерам памяти. Когда такие запросы превышают имеющуюся в наличии память, приходится закупать дополнительную. Когда же дальнейшее расширение невозможно, то надо приобретать новый, более мощный компьютер или рабочую станцию. Но идут ли большая производительность и расширенная функциональность в ногу со все увеличивающимися запросами на вычислительные ресурсы? В большинстве случаев ответ будет - нет. 1. Причины громозкости программного обеспечения 1.1 Сложность как эквивалент мощности 1.2 Времени всегда не хватает 2. Языки и методология проектирования 3. Проект "Оберон" 3.1 Три базисных правила

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

Продолжение. Начало в #2 1996 . (c) Forbes, 1995. George Gilder, The Coming Software Shift, Forbes ASAP, August, 1995 Переведено и перепечатывается с разрешения компании Forbes.

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