Почему программная инженерия не похожа на другие инженерные дисциплины и как она меняет правила игры

0
6

По оценкам, в 2014 году во всем мире насчитывалось более 11 миллионов профессиональных программистов. Когда я начал работать программистом в 1973 году, один из седобородых сотрудников первой компании, в которой я работал, дал мне совет. Он сказал: «Узнай то, что никогда не изменится».

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

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

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

До 1990-х годов, поскольку компьютерное программирование стало такой большой частью того, что называлось информатикой, многие университеты добавляли курс под названием «Программная инженерия» в свои учебные программы по информатике. Популярные учебники, которые использовались в то время для преподавания этих курсов, включают «Программную инженерию» Яна Соммервилля. С 1992 по 1994 год я использовал четвертое издание этого учебника для преподавания программной инженерии в Университете Бингемтона. Сегодня учебник Яна Соммервилля по-прежнему используется во многих университетах по всему миру — теперь уже в его девятом издании. Это приводит к вопросу:

Почему мы должны пересматривать учебник, который якобы обучает наших студентов основам программной инженерии, каждые 3-4 года?

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

Присмотревшись, вы обнаружите, что мы обучаем наше следующее поколение профессионалов в области программного обеспечения тому, что сегодня популярно с точки зрения практики и методов работы с программным обеспечением. Популярные практики и методы разработки программного обеспечения сегодня известны как Agile, Use Cases, User Stories, RUP, XP, Scrum Lean, PSP, TSP, и этот список можно продолжить …

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

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

Прежде чем мы ответим на эти вопросы, давайте сначала вернемся и зададим несколько разных вопросов:

Действительно ли существует набор вещей, которые никогда не меняются в разработке программного обеспечения?

Если они существуют, знаем ли мы, что это такое?

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

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

Волонтеры, участвующие в этой инициативе (известной как SEMAT — Software Engineering Method and Theory), работают над этой задачей с 2010 года. принял «Сущность» в качестве официального стандарта OMG.

Это приводит к нескольким дополнительным вопросам:

Насколько Essence отличается от того, что наши разработчики преподают и преподают в течение последних 40 лет под названием «Программная инженерия»?

А ТАКЖЕ:

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

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

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

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

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

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

Поскольку программное обеспечение является программным, его легко изменить. Это не аппаратное обеспечение. Металл не сгибается легко. Когда дело доходит до программного обеспечения, эта точка зрения меняет всю игру.

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

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

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

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

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

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

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

Когда они это сделают, их выпускники смогут вести переговоры с руководством и лучше выполнять свою работу … Это то, что должны делать профессионалы … Хорошим началом в этом направлении было бы убедить их в том, что программисты должны измерять свои собственные Работа. Поскольку работа с программным обеспечением — это, как мы уже говорили, работа со знанием дела, любые действительно точные меры должны приниматься самими программистами. … Уоттс Хамфри

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

Сегодня Уоттс был бы воодушевлен работой SEMAT в академических кругах. Доктор Карлос Сапата из Национального университета Колумбии в Медельине, Колумбия, разработал первый полный университетский курс, основанный на новом стандарте Essence. курсы программной инженерии в Королевском технологическом институте KTH в Швеции под руководством доктора Миры Кайко-Маттсон. Также было проведено полевое исследование Essence со студентами д-ром Сесиль Перайр в Карнеги-Меллон-Уэст в Соединенных Штатах. Следующим шагом сообщества SEMAT является демонстрация того, как Essence может помочь отрасли, публикуя практические примеры использования и измеренные результаты промышленных образцов.

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь