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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добровольцы, вовлеченные в эту инициативу (известную как SEMAT — методология и теория разработки программного обеспечения), работают над этой задачей с 2010 года. SEMAT достигла важного рубежа благодаря объявлению Object Management Group, международного консорциума стандартов, который принял "Essence" в качестве официального стандарта OMG.

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

В чем разница между стандартом Essence и тем, чему нас учат программисты сегодня и которые уже 40 лет изучают под названием Software Engineering?

А:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *