Общепринятого определения программной инженерии (software engineering) не существует. Одни считают, что «программная инженерия» просто более пафосное название программирования. Если вы программист, то, скорее всего, в своей визитной карточке напишете «разработчик ПО», а вовсе не «программист». Другие же вкладывают в понятие «программная инженерия» более высокий смысл. В учебниках можно найти следующее определение программной инженерии: «совокупность навыков, инструментальных средств и методов, предназначенных для создания качественного программного обеспечения».

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

Дэвид Парнас, один из пионеров отрасли, особый упор делает на слово «инженерия», утверждая [1], что образование в данной области тесно связано с традиционными инженерными дисциплинами, в том числе с курсом материаловедения и тому подобными предметами, отличаясь от информатики так же, как электротехника от физики.

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

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

Специалисты по программному обеспечению

Американская ассоциация информационных технологий в апреле 2000 года [2] прогнозировала появление в течение 12 следующих месяцев 850 тыс. вакантных рабочих мест для ИТ-специалистов. Нехватка квалифицированного персонала ощущается в Европе и Австралии. Зарплаты остаются высокими, даже несмотря на массовое закрытие Internet-компаний и спад в экономике.

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

Судя по высказываниям многих менеджеров, им нужны не просто сотрудники, а великолепные разработчики. А таких действительно не хватает. Литература по программной инженерии подтверждает [3], что разница в качестве работы самого квалифицированного и самого неквалифицированного разработчика в проекте может отличаться в 20 раз. Цель образовательной программы — готовить специалистов, которые удовлетворяли бы самым высоким требованиям.

Стоить отметить, что те, кто заказывает и использует наши системы, довольно терпимо относятся к нашим трудностям. Пользователи жалуются на программное обеспечение, но работают с ним. Однако вечно так продолжаться не может. Хотя относительно немного людей погибли непосредственно от ошибок в программных системах — известно всего несколько десятков случаев [4], нет необходимости специально напоминать о многих известных авариях, чтобы уведомить публику о нестабильности наших методик.

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

Эти тенденции имеют важные последствия для вузов. Конечно, обучение использованию популярных в данный момент инструментов может привлечь внимание студентов (желающих получить навыки, спрос на которые, судя по рекламным объявлениям, весьма высок). Однако подобное решение — не самая лучшая услуга, которую вы можете оказать будущим профессионалам. Вопрос в том, стоит ли их обучать фундаментальным методам мышления, который будут применяться ими в течение всей карьеры и которые помогут добиваться успеха в столь быстро меняющейся области. Успех сопутствует тем, кто способен выйти за рамки инструментария, популярного в какой-то момент времени, и развиваться гармонично с развитием данной дисциплины.

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

Пять целей учебного курса

Учебный курс по программному обеспечению должен включать в себя пять взаимно дополняющих моментов:

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

Принципы

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

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

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

Практика

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

  • Конфигурационное управление. Хотя это одна из важнейших практических методик, которая должна применяться в каждом проекте, она не используется настолько хорошо и систематически, как это должно быть.
  • Управление проектом. Эта задача не всегда оказывается сложной, но многие программные инженеры с ужасом относятся к управлению проектом. Несмотря на обилие литературы, посвященной управлению программным проектом, она далека от совершенства. Однако и там можно почерпнуть поистине блестящие идеи, которые необходимо донести до всех студентов, специализирующихся в области программного обеспечения, поскольку большинству из них в определенный момент придется играть роль руководителя.
  • Метрики. Это одна из самых редко используемых методик. Большая часть литературы по данной теме оставляет желать лучшего, поскольку в ней отсутствует научное обоснование методик, которые следует измерять, и объяснения, почему они действительно важны. И опять-таки необходимо научить студентов тому, как использовать метрики для количественного описания прикладного проекта и атрибутов продуктов, оценки с помощью объективных критериев и применения средств количественного описания для прогнозирования и оценки.
  • Эргономика и пользовательские интерфейсы. Пользователи программных систем рассчитывают на высокое качество интерфейсов; как и остальная система, пользовательский интерфейс должен быть корректным образом спроектирован — навык, которому можно научить.
  • Документация. Программные инженеры не только создают программное обеспечение, они должны его документировать. В программу их обучения должен в обязательном порядке входить курс подготовки технической документации.
  • Взаимодействие с пользователями. Самая лучшая технология оказывается бесполезной, если не удовлетворяет запросов ее потенциальных пользователей. Хороший программный инженер должен знать, как разобраться в требованиях заказчиков и пользователей.
  • Системный анализ. Чтобы решить задачу с помощью программного обеспечения, сначала необходимо понять и описать ее. Анализ — неотъемлемая часть программной инженерии и, пожалуй, одна из самых сложных ее частей.
  • Отладка. Ошибки — привычная составляющая повседневной работы программного инженера. Для того чтобы справится с ними, необходимо систематически и эффективно использовать методы отладки.

Приложения

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

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

Инструментальные средства

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

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

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

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

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

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

Математика

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

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

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

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

Обучение на практике

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

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

Подобная идея, на первый взгляд, может показаться нереальной, но группа энтузиастов — преподавателей Университета Монаша именно так ведет обучение последние несколько лет. В результате создана оригинальная программа графического моделирования, которую каждый новый курс совершенствует, изучает в процессе преодоления трудностей модернизации кода, разработанного кем-то раньше [7]. Есть серьезные препятствия, в частности аттестация в рамках такого проекта и трудности организации годовых проектов в рамках стандартного учебного расписания. Но с решимостью и энтузиазмом все трудности преодолимы.

Обратный учебный процесс

Идея преподавания, дополняющая многолетний проект, состоит в реализации одного из самых многообещающих свойств современной технологии создания программного обеспечения: повторного использования. Принцип обратного учебного процесса [8] или «постепенного открытия черных ящиков» состоит в том, что сначала студенты используют мощные инструментальные средства и компоненты в качестве частей своих собственных приложений, а затем постепенно поднимают завесу тайны. Это дает возможность понять, как устроены эти инструменты, предложить небольшие изменения и добавить свои собственные расширения. Суть метода состоит в том, что студент постепенно превращается из пользователя в создателя, но с самого начала сосредотачивается на мощных и, по возможности, крупных примерах.

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

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

Эта стратегия подробно представлена в моих работах [9]. Я считаю, что она может стать основой учебного курса. До сих пор, насколько мне известно, реализовывать ее в серьезном масштабе никто не пытался, поэтому это влечет за собой определенный риск и требует очень тщательного планирования, организации и исполнения, но не является недостижимой для инициативных и передовых вузов. И может серьезно изменить качество подготовки студентов.

Студенты-непрограммисты

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

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

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

Однако было бы несправедливо отрицать, что студенты и их будущие работодатели вправе ожидать получения практических навыков.

Решение, вероятно, находится где-то посредине: следует отвечать запросам заказчиков, в то же время, руководствуясь принципам педагогики, изучать и идеи, и практические решения. По мере развития дисциплины и эта задача может стать намного легче. Математики ведь тоже ведут курсы на других факультетах, но они, по-видимому, могут обучать математике так, как они хотят, в то же время учитывая требования рынка.

Участие в фундаментальных исследованиях

Анализируя историю развития ИТ за последние несколько десятилетий, нельзя игнорировать то обстоятельство, что, если большая часть новаторских решений в 60-е и 70-е годы были предложены вузами, то в 80-х и 90-х вклад небольших фирм и исследовательских лабораторий крупных корпораций оказался значительно весомее. Это чрезмерное обобщение, которое лишь подтверждается редкими исключениями, может обидеть некоторых читателей. Было бы, однако, сложно найти среди последних достижений неопровержимые эквиваленты таким широко известным решениям, как Паскаль и Модула-2 Вирта, операционная система THE Дейкстры, взаимодействующие последовательные процессы и мониторы Хоара, созданный в Университете Осло язык Симула. Эти и другие фундаментальные изобретения периода становления компьютерной отрасли доказали, что университеты могут предложить не только прекрасные теории.

Частично причина такого изменения ситуации связана с тем, что планка оказалась слишком высоко поднятой. Компиляторы Вирта завоевали себе громкое имя, но трудно представить компилятор, каким бы новаторским он не был, способный добиться аналогичных результатов сегодня. Университетскому коллективу очень непросто конкурировать с сотнями разработчиков, создающих Visual C++ в корпорации Microsoft, или даже специалистов, занимающихся компилятором GNU GCC.

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

Я не претендую на знание всех таких новых областей, но одна кажется мне многообещающей. Речь идет о компонентной разработке и о качестве. Программная отрасль декларирует широкое применение повторно используемых компонентов. Но нет никаких гарантий качества их, нет стандарта, нет правил, нет ведомства, которое занималось бы их сертификацией. Риск столь же велик, как и открывающиеся возможности. Крупный проект может потерпеть неудачу, причем катастрофическим образом, из-за небольшого дефекта в одном из самых незначительных компонентов. Именно это привело к катастрофе во время первого запуска ракеты Ariane 5 — из-за плохо выполненного повторного использования небольшого программного компонента — и задержало реализацию проекта на полтора года, что обошлось европейским налогоплательщикам в 10 млрд. долл. [10].

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

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

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

***

Говоря о «программном обеспечении», следует помнить, что данный термин впервые появился 35 лет назад. С того времени, однако, мы узнали достаточно много, чтобы обучать студентов согласованному набору принципов и методик, не скрывая от них (или от самих себя), как многое еще остается неизвестным.

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

Литература

1. D.L. Parnas, «Software Engineering Programmes Are Not Computer Science Programmes,» CRL Report 361, Communication Research Laboratory, McMaster Univ., Apr. 1998; to be published in Annals of Software Eng., 2001
2. Information Technology of America, «Major New Study Finds Enormous Demand for IT Workers: Research Pinpoints Hot Jobs and Skills Needed, Offers Insights on Employer Preferred Training Approaches».
3. B.W. Boehm, Software Engineering Economics, Prentice Hall, 1981
4. P.G. Neumann, «Illustrative Risks to the Public in the Use of Computer Systems and Related Technology».
5. D. Tsichritzis, «The Changing Art of Computer Science Research», in Electronic Commerce Objects, D. Tsichritzis, ed., Centre Universitaire d?Informatique, Universite de Geneve, 1998
6. B. Meyer, Introduction to the Theory of Programming Languages, Prentice Hall, 1990
7. C. Mingins et al., «How We Teach Software Engineering», J. Object-Oriented Programming, Feb. 1999
8. B. Cohen, «The Education of the Information Systems Engineer», Electronics & Power, Mar. 1987
9. B. Meyer, Object-Oriented Software Construction, 2nd ed., Prentice Hall, 1997
10. J. Jezequel and B. Meyer, «Design by Contract: The Lessons of Ariane», Computer, Jan. 1997

Бертран Мейер (Bertrand_Meyer@eiffel.com) — директор по технологиям компании Interactive Software Engineering. Среди опубликованных им книг — «Объектно-ориентированное конструирование программного обеспечения» (Object-Oriented Software Construction Prentice Hall, 1997).

Bertrand Meyer. Software Engineering in the Academy, Computer, May 2001. IEEE Computer Society, 2001. Reprinted with permission. All rights reserved.

Принципы: что знают специалисты по программному обеспечению

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

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

  • Рекурсия. Этот вопрос не ограничивается только рекурсивными программами — методом, но представляет собой общий стиль мышления, который определяет концепцию за счет применения самого определения к некоторым из его составляющих. Сначала это приводит в смятение, но как только вы научитесь правильно использовать рекурсию, то получите в свое распоряжение мощный интеллектуальный инструментарий.
  • Упрятывание информации. Принятие решения о том, что следует сообщить всему остальному миру, а что оставить при себе — способность, которую разработчики программного обеспечения приобретают только благодаря сочетанию хороших примеров и личного опыта.
  • Повторное использование. Хороший разработчик довольно быстро понимает, что добиться успеха зачастую можно, зная когда следует воспользоваться результатами работы, проделанной кем-то другим. Умение повторно использовать решения — навык; создание результатов, которые могут повторно использовать другие разработчики, — признак мастерства.
  • Победа над сложностью. Программная инженерия — грандиозная интеллектуальная работа. Только профессионал знает, как распознать суть за видимым хаосом.
  • Масштабирование. Некоторые из программных продуктов не только сложны, но и могут быть грандиозны по своему размеру. Исходные тексты Windows 2000 состоят, как сообщается, из 35 млн. строк кода. Впрочем, для оборонных или телекоммуникационных систем размер в несколько миллионов строк — обычное дело. Многие вопросы программной инженерии приобретают особую остроту с ростом размеров программ; количество влияет на качество. Хороший профессионал должен знать, какие методики будут масштабироваться, если будут, поскольку размер системы не всегда планируется. Зачастую крупная система — это разросшаяся небольшая программа.
  • Проектирование с учетом изменений. Программное обеспечение должно изменяться, может меняться и меняется в значительно большей степени, чем инженерные объекты в других областях. Если разработчики не следуют строгим архитектурным принципам, процесс изменений может оказаться крайне болезненным, особенно в случае крупных систем. Создание большей части современных методов, языков и инструментальных средств оправдывается надеждой на то, что они смогут способствовать этому процессу. Даже в системах такого размера, который можно реализовать в рамках университетского курса, можно дать студентам возможность обнаружить трудности, выучить принципы проектирования с учетом изменений и научиться использовать их.
  • Классификация. Объектно-ориентированное программирование показывает, что один из способов борьбы со сложностью — это структуризация беспорядка в беспорядки меньшего размера с многократным повторением этого процесса.
  • Типизация, т. е. определение типа данных, помогает создавать корректные программные элементы, документировать их и обеспечить их эффективное использование, — еще один момент, который может серьезно повлиять на понимание проблем специалистом по программному обеспечению. Вопросы типизации затрагивают всю область программной инженерии, от спецификации до реализации и документирования. Мы можем гордиться тем, что наша профессия позволяет создавать и изучать типовые системы, объектно-ориентированные они или нет, значительно глубже, чем в других дисциплинах; овладение их возможностями — непременная часть навыков хорошего специалиста.
  • Соглашения. Применение необходимых алгоритмов, структур данных, модулей и систем с четкими ограничениями, гарантиями и инвариантами позволяет организовать более жесткий контроль за своей работой. Овладев этими навыками, их можно с успехом применять всю жизнь.
  • Обработка исключений. При создании программного обеспечения большинство рассматривает только самые распространенные ситуации, но профессионал должен постоянно помнить и об исключительных случаях. Только благодаря систематическим методикам можно избежать разрастания потенциально интересных идей (и программ) в мириады мер предосторожности для исключительных случаев.
  • Ошибки и отладка. Хотя в учебниках, как правило, на этом не акцентируют внимание, большую часть повседневной работы создателю программного обеспечения приходится тратить на разбирательство, почему программа не функционирует должным образом, вне зависимости от того, это его собственная ошибка или кого-то еще.

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