Мифы о программной инженерии

В ставшей классической статье, опубликованной в 1994 году в журнале Scientific American, Вейт Гиббс рассказал о кризисе программного обеспечения [1]. Круг проблем, которые он обсуждал, охватывал множество вопросов, от невыполнения бюджетов и сроков до прекращения проектов, в которые были вложены многомиллионные средства. Аналогичные вопросы были подняты и в Communications of the ACM в марте 2001 года, где авторы сулят далеко не радужные перспективы программной инженерии, если отрасль будет "развиваться как прежде" [2]. За прошедшие годы разработчики программного обеспечения сформулировали множество принципов совершенствования методов программирования, часть которых уже подтвердила свою эффективность в практических проектах. К ним относятся методологии и среды разработки программного обеспечения, структурное и объектно-ориентированное программирование, модели совершенствования программных процессов (например, CMM), средства автоматизации разработки программного обеспечения (Computer-Aided Software Engineering, CASE) и языки четвертого поколения. Тем не менее, пока остаются нерешенными некоторые проблемы.

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

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

Миф 1. Новая программа по специальности "Программная инженерия" нужна только преподавателям. Активная разработка новых программ по данной специальности (особенно на уровне аспирантуры) ведется просто потому, что преподаватели уверены, что введение в курс таких программ поднимет престиж их вузов. Введение программ по новой специальности, безусловно, повысит престиж, но нужно оценить сопутствующие этому затраты, чтобы понять, оправдает ли себя в перспективе такое вложение средств. Для определенных сегментов рынка такие программы абсолютно необходимы; в других они не эффективны и, возможно, будут излишними.

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

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

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

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

Рассмотрим следующую ситуацию. Учебный план факультета информатики предусматривает, что почти половина выделенных часов отводится на занятия по информатике. Кроме того, учебные часы, посвященные информатике и программной инженерии, делятся в отношении 90 к 10, что соответствует рекомендациям Computing Curricula 2001 (CC2001) [3] для базовых курсов по специальности "Информатика". Таким образом, 90% преподавателей факультета информатики должны вести курсы информатики, а остальные 10% - учить программной инженерии.

Теперь предположим, что факультет вводит программу по специальности "Программная инженерия". Общее число учебных часов, выделенное на предметы информатики и программной инженерии на новом факультете, остается тем же самым, но теперь они распределяются между двумя дисциплинами в соотношении 50 на 50. (Это соответствует рекомендациям Guidelines for Software Engineering Education [4], которые определяют принципы составления учебного плана для студентов по специальности программная инженерия). Таким образом, треть предметов факультета связаны с программной инженерии, а две трети - с информатикой. Как это повлияет на распределение ресурсов?

При обсуждении ресурсов, необходимых учебным заведениям для новых программ, часто ссылаются на нехватку профессорско-преподавательского состава. Предположим, что на факультет информатики работает 30 преподавателей. До введения специальности "Программная инженерия" на факультете 27 человек вели занятия по информатике, а три - по программной инженерии. Учебные часы делились в соотношении 90% к 10%. В этой ситуации реализация новой программы потребует, чтобы специализацию сменили четыре преподавателя. Для предметов программной инженерии необходимо 5 преподавателей информатики и 5 преподавателей программной инженерии, т. е. соотношение станет равным 23/7.

Таким образом, только 13% всего преподавательского состава (4 из 30) должны будут изменить специализацию. Если оценить количество преподавателей по электротехнике и математике, которые стали преподавать информатику с появлением этой специальности, подобное изменение соотношения представляется вполне приемлемым, несмотря на необходимость переобучения.

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

Миф 3. Учебные курсы по программной инженерии для студентов младших курсов не отличаются достаточной глубиной. Многие компании уверены, что учебный курс на получение степени магистра по программной инженерии дает приемлемый уровень знаний для будущих профессионалов. Такие курсы, как правило, требуют, чтобы студент имел минимальный набор знаний по ряду преподаваемых курсов информатики, таких как структуры данных, дискретные структуры, разработка и анализ алгоритмов и операционные системы, общим количеством от 24 до 30 часов. Вопрос заключается в том, в состоянии ли программа по программной инженерии дать необходимые знания по информатике, в то же время, предлагая дополнительные предметы, касающиеся программной инженерии?

Существуют разные мнения о том, какого рода знания по информатике необходимо давать в процессе обучения. Тим Летбридж обратился с этим вопросам к специалистам по программному обеспечению и пришел к выводу, среди 25 наиболее важных тем, необходимых для обучения данной специальности, имеются такие области информатики, как специальные языки программирования, структуры данных, объектно-ориентированные концепции, разработка алгоритмов, ОС, системное программирование, базы данных, управление файлами и сети [5]. Обязательное обучение этим предметам на младших курсах требует от 24 до 30 учебных часов в семестр. Такой диапазон часов также соответствует базовым требованиям CC2001 и, во многом, требованиям к курсам информатики, перечисленным в документе Computing Accreditation Commission of the Accreditation Board for Engineering and Technology [6] (комитет по сертификации учебных заведений, проводящих обучение инженерным специальностям в США). Таким образом, есть все основания полагать, что тех же самых 24-30 учебных часов информатики будет достаточно для курса по программной инженерии.

Принципы составления учебной программы по специальности "Программная инженерия" предусматривают, что учебный план для младших курсов содержит 21 обязательный учебный час по информатике, 24 обязательных учебных часа по программной инженерии и 9 факультативных часов либо по информатике, либо по программной инженерии. Такая модель, как предполагалось, должна удовлетворять основным требованиям CC2001. Она также должна охватывать тот же материал, который обычно присутствует в программе по программной инженерии, т. е. всего 120 часов в семестре при четырехлетнем обучении, которые являются общим минимумом на получение степени бакалавра в США. Такая учебная программа дает минимально необходимые данные по этому предмету; учитывая, что свыше 120 часов (что весьма традиционно для инженерных программ в США) позволит дать более глубокие знания в области информатики и программной инженерии.

Миф 4. Новая специальность "Программная инженерия" поможет преодолеть кризис в отрасли разработки программного обеспечения. Новый учебный курс не станет панацеей. Это будет один из первых шагов, хотя, возможно, и самый важный, на пути разрешения кризиса в программной отрасли, но мы должны учесть и дополнительные факторы. Например, необходимо четко определить, что такое "инженерное образование" (учебная программа и форма подачи). Отправная точка - понять цель этого образования в том виде, как его определяет Дэвид Парнас [7]. По его словам, чтобы предоставить наиболее эффективное образование по специальности "Программная инженерия", новая программа должна следовать традиционному инженерному подходу к профессиональному образованию, в то же время, давая теоретические основы в области информатики. Он подчеркивает, что специалисты должны знать:

что истинно и полезно в выбранной ими специальности; как применять базовые знания; как применять более широкие знания для создания законченных продуктов, которые должны функционировать в реальных условиях. В статье по этой же теме Мэри Шо сравнивает эволюцию химических и гражданских инженерных дисциплин с программной инженерией. Она использует свою эволюционную модель инженерных дисциплин для того, чтобы понять, каковы этапы развития программной инженерии [8].

Еще один важный вопрос заключается в определении приемлемого круга базовых знаний для системных инженеров. Software Engineering Body of Knowledge (SWEBOK) прекрасно подходит в качестве отправной точки, но здесь есть и определенные сложности. Одна из них заключается в ориентации на особенности США - руководство, подобное SWEBOK, надо принять на международном уровне. Критике подвергаются и понятия сертификации и лицензирования. Нужно дать четкий ответ на эти вопросы и привлечь к работе над SWEBOK другие профессиональные ассоциации.

Более того, программные инженеры должны иметь возможность применять эти методы в различном контексте и адаптировать свои знания для того, чтобы более эффективно использовать новые технологии. Как заметил Майкл Маккракен [9], образовательная отрасль не может предсказать, какой популярный язык или методология станет в будущем использовать отрасль, поэтому обучение в области программной инженерии должно сосредотачиваться на получении фундаментальных знаний, которые позволят молодым специалистам быстро и эффективно усваивать и применять новые технологии. Давно следует четко определить специальности и предоставить возможность пройти необходимое обучение и специализированную практику для каждой из них [10].

Студенты, изучающие программную инженерию, должны проходить курс практических занятий не только во время обучения, но и при устройстве на работу и перед назначением на должность, которая предусматривает выполнение важных обязанностей по проектированию и реализации. Это касается не только инженерных но и всех остальных дисциплин. (В медицине молодые специалисты, по крайней мере, два года работают ординаторами, прежде чем их допускают к самостоятельной практике.) Стив Макконнелл и Леонард Трипп считают, что программные инженеры должны проходить, по крайней мере, четырехлетнюю стажировку [11].

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

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

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

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

Миф 6. Студентам, закончившим обучение специальности "Программная инженерия", не нужно проходить дальнейшую практику, чтобы работать на уровне опытных программных инженеров. Обычно молодые специалисты по программной инженерии приходят в группы, где, как предполагается, они смогут работать (с незначительным обучением или вообще без него) наравне с опытными программными инженерами. Организации часто считают, что новые сотрудники могут самостоятельно усвоить корпоративную культуру и стандарты, а также изучить конкретную предметную область, связанную с их работой. Новых сотрудников часто направляют на выполнение критически важных этапов программного проекта. Одна из причин этого заключается в том, что большинство корпоративных менеджеров считают, что их новые сотрудники знакомы с последними и самыми совершенными методами и могут выполнять более сложную работу, чем специалисты, которые уже давно работают в компании. Другая причина состоит в том, что от молодых специалистов часто ожидают готовности работать дополнительно во внеурочные часы и они, как правило, не имеют семейных обязательств. Еще одна причина в том, что многие программные проекты начинаются в условиях крайне напряженного графика, и невозможно предоставить новым сотрудникам время для постепенного вхождения в курс дела. В своей книге Death March Эд Йордан заметил: "Для слишком многих ветеранов каждый проект сродни подвигу и требует приложения всех сил" [12]. Том Демарко в своей книге Slack пишет: "...Опасная корпоративная иллюзия: считается, что организации добиваются успеха только в том случае, если все их сотрудники постоянно и полностью заняты" [13].

Рассмотрим следующий пример. Молодой специалист пришел в компанию, когда реализация проекта уже началась, заменив сотрудника, переведенного на другой проект. После короткого введения в курс дела ему предлагают продолжить работу, начатую этим специалистом, и рассчитывают, что он уложится в назначенные сроки. В конце концов, если сроки реализации этого конкретного программного обеспечения не выполняются, весь проект в целом не будет сдан вовремя. Более того, другие члены группы заняты собственной работой. Хотя они готовы отвечать на возникающие вопросы, но быстро отсылают нового сотрудника к документации.

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

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

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

Миф 7. Программы обучения программной инженерии будут соответствовать конкретным корпоративным требованиям. Обратите внимание на типичный список требований к претендентам на работу. Вот цитаты из некоторых недавних объявлений: "Должен знать C/C++", "Должен быть знаком с Accelerated SAP" и "Должен иметь опыт работы в области объектно-ориентированного программирования на Java или C++". Обратитесь на сайт www.monster.com, и вы найдете только одно объявление, в котором указаны требования к опыту в разработке программного обеспечения, проектирования, кодирования и тестирования вместе с использованием наилучших практических решений. Такое впечатление, что мы попали в искажение времени, где форме отдается предпочтение перед содержанием. Никому не нужен опыт использования конкретных языков и инструментальных средств - программный инженер может без особого труда изучить новые языки и инструментальные средства, большинство из которых все равно изменятся в ближайшие пять лет. С другой стороны, образование, полученное на основе лучших практических инженерных решений и методов для поддержки различных этапов жизненного цикла программного обеспечения, останется достоинством кандидата на работу на всю жизнь.

Такое впечатление, что многие руководители компаний по-прежнему ищут программистов, которые могут писать код на конкретных языках с использованием конкретных инструментальных средств, рассчитанных на решение краткосрочных задач. Им не нужны программные инженеры, которые способны разрабатывать ПО с помощью наилучших практических решений с долговременной перспективой. Вот почему компании в отрасли, как правило, ищут человека, который может сразу начать разработку. У них нет времени, они не заинтересованы в обучении сотрудников. Более того, компании предполагают, что их сотрудники уволятся через год-два, поэтому считают, что им все равно не удастся воспользоваться преимуществами от долговременных знаний в области программной инженерии, которыми этот сотрудник может обладать. События последних лет подтверждают верность такого отношения - специалисты рассчитывают регулярно менять место работы, иногда из-за значительного роста зарплаты. Так и образуется порочный круг. Разработчики регулярно меняют место работы, потому что компании практически не вкладывают никаких средств в предотвращение текучести кадров, а компании практически не вкладывают никаких средств в то, чтобы предотвратить текучесть кадров, потому что разработчики регулярно меняют место работы. Фактически, компания, которая инвестирует в обучение сотрудников, может обнаружить, что служащий добавляет вновь приобретенные навыки к своему резюме в поисках работы. Еще одна причина состоит в том, что менеджеры обычно начинают свою карьеру как программисты, не имея образования в области программной инженерии, что и формирует их систему взглядов. Они хотят найти таких же специалистов, какими они были сами, когда начинали свою карьеру.

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

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

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

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

Литература W. Gibbs, "Software's Chronic Crisis", Scientific Am., vol. 271, no. 3, 1994. Sept. H. Lieberman, C. Fry, "Will Software Ever Work?" Comm. ACM, vol. 44, no. 3, 2001. Mar. Computing Curricula 2001, ACM Special Interest Group on Computer Science Education, 2001, www.acm.org/sigs/sigcse/cc2001. D. Bagert et al., Guidelines for Software Engineering Education, Version 1.0., tech. report CMU/SEI-99-TR-032, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, Pa., 1999. T. Lethbridge, "What Knowledge Is Important to a Software Professional?" Computer, vol. 33, no. 5, 2000. May ABET, ABET Criteria for Accrediting Computing Programs, 2002, www.abet.org/criteria.html. D. Parnas, "Software Engineering Programs Are Not Computer Science Programs", IEEE Software, vol. 16, no. 6, 1999. Nov./Dec. M. Shaw, "Prospect for an Engineering Discipline of Software", IEEE Software, vol. 7, no. 1, Jan./Feb. 1990. M. McCracken, "Software Engineering Education: What Academia Can Do", IEEE Software, vol. 14, no. 6, 1997. Nov./Dec. M. Shaw, "Software Engineering Education: A Roadmap," The Future of Software Engineering, A. Finkelstein, ed., ACM Press, New York, 2000. S. McConnell and L. Tripp, "Professional Software Engineering: Fact or Fiction?" IEEE Software, vol. 16, no. 6, 1999. Nov./Dec. E. Yourdon, Death March, Prentice Hall, Upper Saddle River, N.J., 1997. T. DeMarco, Slack, Broadway Books, New York, 2001.

Хоссейн Саедян (saiedian@eecs.ku.edu)

Рекомендовать страницу	Обсудить материал	Написать редактору
Распечатать страницу		Дата публикации: 16.03.2003