В книге рассмотрены методологические подходы к созданию крупных программных систем. Выделены важнейшие навыки программирования, даны рекомендации, направленные на повышение индивидуального мастерства разработчиков программ. Обобщена практика управления проектами, представлены современные методики разработки программного обеспечения: модели CMM и SPMN, спиральная и итерационная концепции, методика персонального совершенствования PSP, технологии экстремального программирования и гибкая методика управления проектами SCRUM. Книга предназначена для широкого круга программистов и руководителей проектов в области информационных технологий.
Содержание
От автора
Глава 1 •Стратегический подход к программированию
Только бездельники не любят ошибки
Боитесь ли вы ошибок?
Чтобы бороться с ошибками, оставьте их жить!
Учиться на опыте или накапливать знания?
Типичные методологии разработки программ
Чем заниматься: тем, что интересно, или тем, что
приносит деньги?
Главное правило программиста
Приближаемся к реальности
Принципы повышения индивидуального мастерства программирования
Базовые методологические навыки
Развиваем навыки
Заключение
Глава 2 •Языки программирования: прошлое и будущее
От двоичного кодирования к системам автоматической
генерации кода
Третье поколение
Фортран: программисты свой выбор сделали —
еще 40 лет назад
Язык Ада
Jovial: веселый язык программирования
ПЛ/1, пли!
PL/B: язык для бизнесменов
Языки сценариев («скрипт-языки»)
Скрипт не забыт
Perl — язык альтруистов
Так-тикль — язык системной интеграции
VRML: трехмерный язык Интернета
Классика жанра
Лисп: история одного преступления в отношении языка программирования
Smalltalk: идет волна
Форт еще жив
Пропел ли Пролог свою «лебединую песню»?
Русский Пролог
Пишется на чем угодно — разрабатывается только
в Visual Studio
Haskell
Scheme
Eiffel
Mercury
Python
Standard ML
Oz
Java
Заключение
Глава 3 •Методики разработки программного обеспечения
и управления проектами
Введение
Оцениваем размеры программного проекта
Делим проекты на большие и маленькие
Критерии оценки объема программного проекта
Стратегическое управление проектами
Контроль реализации проекта
Управление рисками
А что в реальности?
Критические цепочки — третья революция в управлении
проектами
Краткая история методологий управления проектами
Проблемы классических подходов
В чем секрет МКЦ?
Практический пример
Важность общего буфера ресурсов
Заключение
Искусство бюрократии
Пойди туда — не знаю куда
И это все работает?
Понятие процесса в CMM
Группы практик CMM
Пять уровней CMM
Описание уровней CMM
Уровень зрелости компании — уровень взаимопонимания между менеджерами и программистами
Что дальше?
Небольшой пример
Эд Йордон и Гради Буч отстреливают динозавров
Ошибки, ошибки
В дело вступают эксперты
Как избежать хаоса
Девять лучших навыков, рекомендованных SPMN
Спиральная модель разработки программного обеспечения
Срок как важнейший приоритет
Итерации по спирали
Шесть шагов спиральной модели
Рекомендации по итерационной модели и объектно-ориентированному проектированию
Первая итерация
Вторая итерация
Третья итерация
Четвертая итерация
Итоги
Охотники за ошибками
Уотс Хамфрей находит источник ошибок
Семь шагов самосовершенствования
Заключение
Программная инженерия развивается экстремальными
методами
Экстремальные методики
Экстремальное программирование
Особенности применения экстремальных методик
От экстремальности к экономичности
Программирование состоится при любой погоде
Scrum: схватка с формализмом CMM
Основы методики Scrum
Терминология Scrum
Основные идеи методики Scrum
Внутренняя структура методики Scrum
Роль бэклога
Ежедневные встречи с точки зрения руководителя
проекта
Начало, продвижение и закрытие спринта
Scrum — эмпирический процесс разработки
Ориентация на сложные системы
Типичные риски в методике Scrum
Типичный вариант внедрения
Чем плохи модели CMM и им подобные
Пример применения методики Scrum
Выбор программной архитектуры при использовании
методики Scrum
Заключение
Глава 4 •Программная инженерия будет распараллелена
Как японцы компьютерный мир осчастливили
Япония продолжает думать об информационном будущем
Технические характеристики проекта RWC
Параллели с реальным миром
Сделать им еще предстоит больше, чем сделано
Рекомендуемая литература
ОТРЫВОК
Глава 1
Стратегический подход
Только бездельники не любят ошибки
Разработка программного обеспечения для системы управления огнем истребителя F-16 обошлась в 85 млн долларов. Объем программного обеспечения составил 236 тысяч строк кода.
Усилия по сопровождению программ комплекса, их улучшению и устранению ошибок потребовали дополнительно 250 млн долларов.
Любой человек, когда-либо пытавшийся написать на компьютере собственную программу, будь то более или менее сложный макрос для редактора или электронной таблицы, стратегическая игра или система расчета зарплаты, очень хорошо знает, что создание программ без ошибок невозможно. Количество ошибок постепенно снижается по мере роста опыта разработчика, но при создании сложных программ всегда остается достаточно высоким. Понимание этого факта отличает программиста высокой квалификации от менее подготовленного коллеги или начинающего разработчика. Профе
ссионал убежден, что универсального способа написать крупную программную систему без ошибок не существует.
Любая сложная система похожа на реальную жизнь. Как сказал восточный мудрец: «Единственное, что постоянно в мире, — это изменения». То же самое можно сказать и в отношении программ. Негативное отношение к ошибкам следует считать в корне неправильным. Люди и организации развиваются благодаря изменениям, внутренним кризисам. Опыт формируется на основе умения относиться к своим и чужим ошибкам как к сигналам внешнего мира: своеобразной обратной связи, реакции окружения на наши действия. Ошибка — это средство качественного роста, прекрасная возможность перейти на более высокий уровень профессиональной зрелости. А боязнь ошибок, стремление убежать от изменений, от проблем равнос
ильны стремлению убежать от реальности, от жизни.
Замечено, что ошибок часто боятся бездельники. Они считают, что чем меньше у них забот, тем выше их профессионализм. В работе они нацелены только на минимизацию своих усилий. Бездельники ищут уникальные программные продукты управления проектной работой, способные, как им кажется, обеспечить гарантированное выполнение задания в рамках бюджета, в срок и с высоким качеством — без ошибок. Они пытаются внедрять жесткие, расписанные по шагам заформали зованные и забюрократизированные методологии организации труда.
А вот если бы человек думал, как найти побольше работы (и как сделать побольше ошибок), он мог бы изменяться, развиваться, совершенствовать свой профессионализм очень быстро. Существует большая группа так называемых гибких (agile) методологий, которые дают человеку возможность уйти от навязанных авторитетами-теоретиками условных схем, весьма далеких от практики, и предоставляют ему значительную свободу в проектной деятельности.
Конечно, ошибка ошибке рознь. В стремлении формализовать процесс разработки программ нет ничего плохого. Стандартные подходы к программированию очень полезны, если они внедряются гибко и с умом, а не превращаются в догму. Главное, чтобы они не ограничивали творческий подход к работе.
Самая плохая ошибка — это повторная ошибка. Именно таких ошибок не делают профессионалы. Если разработчик допустил ошибку, но не сделал из нее выводов на будущее, то это свидетельствует о несерьезном отношении к своей деятельности. Вы хотите стать профессиона лом? Тогда никогда не делайте одну и ту же ошибку дважды!
Известна ситуация, когда один из руководителей IBM платил своим программистам за ошибки. Только не за всякие ошибки, а за новые. Он поощрял индивидуальное творчество, экспериментирование, поиск нестандартных решений. В результате его коллектив быстро вырос в профессиональном плане и стал одной из сильнейших команд разработчиков в корпорации. Глава 1•Стратегический подход к программированию
Боитесь ли вы ошибок?
Одну из версий Windows NT тестировало
250 инженеров в течение года и выявило
30 тысяч ошибок.
Боязнь ошибок нередко прячется в нас довольно глубоко. Она может быть связана с самыми разными особенностями психики, индивидуальными предпочтениями, жизненным опытом.
Попробуйте ответить на следующий вопрос. Считаете ли вы, что процесс программирования требует жесткой регламентации и контроля всех аспектов разработки?
Да? Такой подход в какой-то степени действительно делает процесс программирования относительно безопасным, снижая количество типичных недочетов. Он позволяет снизить рутинную нагрузку на мозг и стандартизовать, механизировать основные виды работы — выполнять их на лету, автоматически , как робот. Однако тотальное стремление к формализации чаще всего приводит не к выпуску готового программного продукта, а к «автоматизированному и регламентированному хаосу», выполняющему совсем не те функции, которые хотел видеть заказчик.
В практике программирования известно немало соответствующих примеров. Так, известная российская компания-автоматизатор внедряла на крупном предприятии информационную учетно-управленческую систему. Директор утвердил все необходимые документы, но когда через полгода он стал принимать систему, оказалось, что делает она совсем не то, что он ожидал. Внедренцы тут же показали ему подписанные документы и техническое задание — несколько толстых томов. На что директор справедливо заметил: «Ребята! Но у меня же нет времени и знаний, чтобы детально разобраться
в вашем предложении! Я вам полностью доверял, потому и подписал документы, не читая их».
Это наглядный пример того, что заранее можно сколь угодно подробно расписывать структуру создаваемого продукта и согласовывать документацию, однако без постоянной (в идеале — непрерывной) обратной связи всегда останется очень сильное расхождение между заказчиком и исполнителем в понимании того, что же все-таки программа должна делать.
«Упреждающее» планирование конечного вида программного продукта связано со стремлением исполнителя снизить собственные риски в ходе работ над проектом. Но при этом упускается самое главное — интересы клиента, что обязательно приведет к конфликтам на следующих эта
Глава 1•Стратегический подход к программированию
пах работ. Желание предусмотреть все детали и нюансы деятельности нередко исходит также из-за боязни нововведений, что приводит к неадекватной оценке реальных нужд клиента. Нежелание выходить за пределы жестких схем, возможно, и комфортно — но только для исполнителя, а не для заказчика.
Не дает эффекта и попытка упростить решаемую задачу, заранее свести ее к набору шаблонных схем. К сожалению, такой подход обычно приводит к тому, что «вместе с водой выплескивается и ребенок». Заказчик очень редко сразу способен четко описать, что же он хочет получить от программистов. Понятно и вполне объяснимо стремление разработчи ков выявить все возможные подводные камни перед началом проекта. Согласно статистике, от 60 до 90% ошибок в сложных программах связано с неверной или неправильной формулировкой требований к будущему продукту. Ошибки в требова
ниях приводят к тому, что в архитектуру системы изначально закладываются противоречия, устранить которые на этапах реализации практически невозможно. Поэтому исполнитель стремится как можно раньше договориться с заказчиком о том, какой будет программа, и по возможности выбросить из нее все то, что пока не представляется возможным точно описать и объяснить. Но такая практика представляет собой уход от реальной сложной проблемы. Поэтому, как показывает множество примеров, программисты в условиях жесткого определения требований и дальнейшей их неизме
нности реализуют в лучшем случае до 60% реальных запросов заказчика.
Правильный, проверенный подход к созданию сложных программных систем — это как можно более полное и глубокое погружение в проблемы клиента, в многовариантную, постоянно изменяющуюся задачу. Это осознание того, что разработчику всегда доступно множество вариантов ее решения и реализации. Это понимание того факта, что профессиональное развитие возможно только путем погружения в хаос жизни — как с перспективами, так и с весьма вероятными рисками и неудачами.
При работе над сложными системами важно осознать и принять, что ошибки — это естественная часть любого проекта, это обратная связь с реальностью, с жизнью. В ходе реализации крупного проекта обязательно встретится и выявится множество нюансов и глубинных взаимосвязей, которые разработчик при формальном подходе и поверхност ном понимании нужд заказчика склонен относить к случайностям. Однако с позиции заказчика эти случайности, возможно, представля ются самыми главными проблемами, требующими решения. Другое дело, что в начале проекта он может их не ос
ознавать.
Технологии Пентагона на службе российских программистов. / С. Бобровский - СПб: Питер, 2003. - 224 с.
|