О преподавании программной инженерии

В последние годы программистское сообщество приложило немало усилий для упорядочения накопленных знаний и поиска способов их преобразования в учебные планы. В результате этих усилий появились проекты SWEBOK (Guide to the Software Engineering Body of Knowledge - "Руководство по сумме знаний о программной инженерии") и SE 2004 (Software Engineering 2004).

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

SE 2004 и SWEBOK - важные вехи, отражающие обширный реальный опыт авторских коллективов и результаты обсуждения в рабочих группах. Оба документа особо подчеркивают "инженерную" сторону программной инженерии [1-3], направленность которой влияет как на содержание типичного курса последней, так и на понимание студентами сущности изучаемой дисциплины. Техническая ограниченность понимания дисциплины порождает ряд допущений, способных ввести в заблуждение преподавателей.

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

Контекст

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

В Свободном университете (Vrije Universiteit) оценивают теоретическую и практическую части собственного курса программной инженерии, соответственно, как четыре и восемь зачетных единиц ECTS. В Европейской системе зачетов результатов обучения (European Credit Transfer System, ECTS) одна единица ECTS составляет приблизительно 28 учебных часов, а полный год равен 60 ECTS. Продолжительность курса Свободного университета - 12 недель. Студенты должны изучать его на втором году программы бакалавриата, не имея на начальном этапе достаточной зрелости в области информатики и программной инженерии. Как правило, каждый год на него записываются 150-200 студентов.

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

Заблуждения преподавателей программной инженерии

Заблуждение 1. Для курса программной инженерии нужен промышленный проект

Это заблуждение основано на том, что студентов надо готовить к "реальному миру", который сложен, изменчив и полон противоречий. Он наполнен действующими лицами из разных предметных областей, имеет политические и культурные аспекты. Чтобы достойно ответить на его вызов, следует основывать учебные проекты на реальных примерах [5] или вводить в упражнения для студентов искусственные усложнения и препятствия [6]. Вопрос состоит в том, насколько все это нужно.

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

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

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

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

Максимальное упрощение. В своем учебнике по программной инженерии [7] я использую аналогию с обучением плаванию. В начале XX века амстердамские школьники обычно учились плавать на школьной игровой площадке, лежа на деревянных скамейках и отрабатывая правильные движения. Моему отцу, выросшему в деревне, плавание далось намного труднее - дед обвязал его веревкой вокруг пояса, бросил в реку и крикнул: "Плыви!" Сегодня уроки плавания начинаются мягко, в детском бассейне, с мамой и множеством плавательных приспособлений. Постепенно количество поплавков уменьшается, а бассейн становится глубже.

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

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

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

Преподаватель может предложить нескольким группам студентов спроектировать одну и ту же систему, по-разному расставив приоритеты (например, в отношении требований к качеству). Затем группы коллективно изучат и обсудят эти проекты [9].

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

Заблуждение 2: Программная инженерия похожа на другие инженерные дисциплины

Во всех работах по программной инженерии обсуждаются ее сходства с другими инженерными дисциплинами, конечно, наряду с различиями. Есть интересные примеры, в которых она сравнивается с проектированием мостов [10] и паровых машин высокого давления [11]. Общая идея, однако, заключается в том, что сходства превалируют.

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

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

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

Но есть и другие подходы к разработке требований. Можно, например, рассматривать это как задачу понимания. Тогда односторонний поток информации превращается в диалог между сторонами, в котором программный инженер играет роль своего рода "повивальной бабки". Требования не есть нечто непреложное, "заданное извне": они, скорее, являются мысленными конструкциями человеческого разума [13].

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

Если взглянуть шире, можно обнаружить сходное противоречие между солидными, тщательно спланированными и документированными моделями жизненного цикла программного обеспечения из царства программной инженерии и легковесными подходами, которые подчеркивают человеческие аспекты разработки. Главная проблема состоит в объединении их достоинств. Это верно для практики и еще более верно для образовательной среды. Студенты укрепляются в инженерном представлении о мире разработки, но недостаточно опытны для того, чтобы чувствовать пределы такого представления. Последнее стало очевидным, когда несколько студентов, специализирующихся в области мультимедиа, прослушали наш курс программной инженерии. Они столкнулись с обычными студентами, изучающими информатику, которые имели довольно односторонние традиционные представления, а потому были не в состоянии увидеть и правильно оценить нетехнические проблемы [14].

Заблуждение 3: Планирование в программной инженерии осуществляется хуже, чем в других областях

Во многих работах, посвященных программной инженерии, фигурируют примерно такие тезисы: "Приблизительно 75% всех программных проектов либо запаздывают, либо отменяются" [15]. В своей замечательной книге "Путь камикадзе" [16] Эдвард Йордон цитирует материалы группы Standish Group и высказывания Каперса Джонса и Говарда Рубина. Они утверждают, что "средний проект обычно запаздывает на 6-12 месяцев и выходит за рамки бюджета на 50-100%. Мрачная действительность заключается в том, что в своем проекте вы должны рассчитывать на такие условия, которые почти наверняка приведут менеджера проекта и его сотрудников на путь камикадзе". Подразумевается (явно или неявно), что повышение качества обучения программистов поможет сократить и, в конечном счете, свести на нет число вышедших из под контроля проектов. Я подвергаю сомнению эту связь между уровнем образования и точностью планирования в программной инженерии.

Результаты инфраструктурных проектов в других областях. Обращение к другим областям весьма поучительно. Сейчас строится дорогая высокоскоростная железнодорожная магистраль для перевозки грузов из роттердамского порта в Германию и далее. В 1992 году должностные лица оценили ее общую стоимость в 2,3 млрд. евро, а к 2000 году - уже в 4,7 млрд. евро. В то же время оценка ее пропускной способности непрерывно снижалась. Многие думают, что эта магистраль никогда не станет рентабельной.

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

Флайвберг, Брузелиус и Розенгаттер приводят примеры нескольких известных проектов с крупными перерасходами бюджетов:

Суэцкий канал (1869 год) - перерасход на 1900%;
Сиднейский оперный театр (1973 год) - перерасход на 1400%;
«Конкорд» (первый полет в 1969 году) - перерасход на 1100%;
Панамский канал (1913 год) - перерасход на 200%;
Бруклинский мост (1883 год) - перерасход на 100%.

При строительстве железных дорог, по их оценкам, перерасход бюджета в среднем составляет 45%. Затем следуют мосты и туннели со средним перерасходом 34%.

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

Аналогии с разработкой программного обеспечения. Многие причины перерасхода средств и нарушений графиков инфраструктурных проектов относятся и к проектам разработки программного обеспечения. Само по себе обучение будущих программистов методам анализа функциональных точек (Function Points Analysis, FPA), разработки требований и решения других ключевых задач не устранит проблему перерасхода времени и средств. Как заявил Том Демарко, «корень зла - в политике использования предварительных оценок для формирования побудительной мотивации» [18].

В одном интересном эксперименте по оценке стоимости программного обеспечения [19] изучалось так называемое «проклятие победителя» в следующих обстоятельствах:

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

Итоговый контракт часто приносит претенденту низкую или отрицательную прибыль, и он может оказаться рискованным для потребителя. Например, в одном из экспериментов [19] Йоргенсен и Громстад пригласили 35 компаний на конкурс с целью получения заказа на создание системы с определенным набором требований. Затем они предложили четырем из них реализовать систему. Выяснилось, что фирмы с самыми дешевыми предложениями подверглись самым большим рискам. Флайвберг и Йоргенсен подчеркивают необходимость тщательного управления рисками. Как сказал один опытный менеджер, управление рисками - это руководство проектом для взрослых. Безусловно, управление рисками должно стать одной из основных тем учебного курса программной инженерии.

Заблуждение 4: Пользовательский интерфейс разрабатывается в ходе низкоуровневого проектирования

«Сейчас нам не до проблем пользовательского интерфейса. Сначала мы должны заставить эту штуку работать!», - говорят Маллиган и др. [20]. Однако важность пользовательского интерфейса трудно переоценить: в диалоговой системе к нему относится около половины кода. В недавнем исследовании показано, что 60% программных дефектов связаны с непрактичностью и только 15% имеют отношение к функциональным возможностям [21]. Должное внимание к качеству пользовательского интерфейса на сайтах электронной коммерции может увеличить продажи на 100% [22]. Для Web-систем удобство использования - одна из бизнес-целей. И чтобы улучшить положение дел, нужно интегрировать адекватные методы проектирования пользовательского интерфейса в процесс разработки. А начинать следует со студенческой скамьи, с курса программной инженерии.

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

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

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

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

Сторонники традиционных подходов к программной инженерии рассматривают проектирование пользовательского интерфейса как отдельную работу и не включают его в общепринятую модель процесса создания программ. Нужен более разносторонний подход, при котором мы с самого начала будем проявлять внимание к проблемам интерфейса. Если пользовательский интерфейс - это и есть система (в чем я убежден), то разработчики программного обеспечения должны иметь базовые представления о проблемах человеко-машинных интерфейсов. В учебные планы по информатике и программной инженерии необходимо ввести, по меньшей мере, вводный курс [25].

Заблуждение 5: SWEBOK отражает реальное положение дел

Как мне кажется, SWEBOK и SE 2004 в некоторых областях отстают от практики, а кое в чем - забегают вперед.

Опережение реальности. В качестве примера опережения реальной практики в SWEBOK рассмотрим данные нового европейского научно-исследовательского проекта MOOSE (Software Engineering Methodologies for Embedded Systems; www.mooseproject.org ). Исследователи MOOSE создали Web-репозиторий, отражающий производственный опыт более 100 компаний. Проанализировав их продукцию, они пришли к следующим выводам:

50% продуктов созданы без применения методов разработки требований;
75% созданы без использования инструментов разработки требований;
25% разработаны вообще без применения методов проектирования;
50% разработаны с помощью чертежного инструмента общего назначения или вообще без инструментов;
33% проверены вручную;
90% разработаны с использованием инструмента управления конфигурацией.

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

Отставание. SWEBOK отстает от практики, поскольку программная инженерия быстро изменяется. Новые подходы (такие как разработка на базе моделей и сервис-ориентированная архитектура) оказали значительное влияние на науку и практику, но пока не нашли отражения в SWEBOK и SE 2004. То же можно сказать об архитектуре программного обеспечения.

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

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

Неоднородность. Как показывает недавнее развитие событий, программная инженерия становится все более разнообразной и неоднородной:

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

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

Литература

P. Kruchten, Putting the ‘Engineering’ into Software Engineering. Australian Software Eng. Conf., IEEE CS Press, 2004.
D. Parnas, Software Engineering Programs Are Not Computer Science Programs. IEEE Software, 1999, vol. 16, no. 6.
M. Shaw, Prospects for an Engineering Discipline of Software. IEEE Software, 1990, vol. 7, no. 6.
H. Saiedian, D. Bagert, N. Mead, Software Engineering Programs: Dispelling the Myths and Misconceptions. IEEE Software, 2002, vol. 19, no. 5.
R. Dawson, R. Newsham, Introducing Software Engineers to the Real World. IEEE Software, 1997, vol. 14, no. 6.
R. Dawson, Twenty Dirty Tricks to Train Software Engineers. Proc. 22nd Int’l Conf. Software Eng., IEEE CS Press, 2000.
H. van Vliet, Software Engineering: Principles and Practice, 2nd ed. John Wiley & Sons, 2000.
D. Budgen, Software Design. Addison-Wesley, 2003.
P. Lago, H. van Vliet, Teaching a Course on Software Architecture. Proc. 18th Conf. Software Eng. Education and Training, IEEE CS Press, 2005.
A. Spector, D. Gifford, A Computer Science Perspective of Bridge Design. Comm. ACM., 1986, vol. 29, no. 4.
N. Leveson, High-Pressure Steam Engines and Computer Software. Proc. 14th Int’l Conf. Software Eng., IEEE CS Press, 1992.
A. Bryant, Metaphor, Myth and Mimicry: The Bases of Software Engineering. Ann. Software Eng., 2000, vol. 10.
R. Hirschheim, H. Klein, Four Paradigms of Information Systems Development. Comm. ACM, 1989, vol. 32, no. 10.
C. Lewerentz, H. Rust, Are Software Engineers True Engineers? Ann. Software Eng., 2000, vol. 10.
T. Hilburn, W. Humphrey, The Impending Changes in Software Education. IEEE Software, 2002, vol. 19, no. 5.
E. Yourdon, Death March, The Complete Software Developer’s Guide to Surviving "Mission Impossible" Projects, Prentice Hall, 1997 (Эдвард Йордон. Путь камикадзе. - М.: Лори, 2004).
B. Flyvbjerg, N. Bruzelius, W. Rothengatter, Mega-projects and Risk: An Anatomy of Ambition. Cambridge Univ. Press, 2003.
T. DeMarco, Controlling Software Projects. Yourdon Press, 1982.
M. Jorgensen, S. Grimstad, Over-Optimism in Software Development Projects: ‘The Winner’s Curse,’ Proc. 15th Int’l Conf. Electronics, Communications, and Computers, IEEE CS Press, 2005.
R. Mulligan, M. Altom, D. Simkin, User Interface Design in the Trenches: Some Tips on Shooting from the Hip. Proc. Conf. Human Factors in Computing Systems, ACM Press, 1991.
O. Vinter, P Poulsen, S Lauesen, Experience Driven Software Process Improvement. Software Process Improvement, Brighton, 1996.
J. Nielsen, Web Research: Believe the Data. Alertbox, 11 July 1999.
T. Lethbridge, What Knowledge Is Important to a Software Professional? Computer, 2000, vol. 33, no. 5.
N. Bevan, Quality in Use: Meeting User Needs for Quality. J. Systems and Software, 1999, vol. 49, no. 1.
G. van der Veer, H. van Vliet, A Plea for a Poor Man’s HCI Component in Software Engineering and Computer Science Curricula. Comp. Science Education, vol. 13, no. 3, 2003.
L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd ed. Addison-Wesley, 2003 (Л. Басс, П. Клементс, Р. Кацман, Архитектура программного обеспечения на практике. - СПб.: Питер, 2001).
J. Bosch, Software Architecture: The Next Step. Proc. European Workshop Software Architecture, LNCS 3047, Springer, 2004.
G. Borchers, The Software Engineering Impacts of Cultural Factors on Multi-cultural Software Development Teams. Proc. 25th Int’l Conf. Software Eng., IEEE CS Press, 2003.