Инженерное программирование – Инженерия программного обеспечения — это… Что такое Инженерия программного обеспечения?

Содержание

Кто такой Software Engineer. Программная инженерия VS «просто» программирование

Предлагаем вашему вниманию адаптацию статьи Самира Буна (Samer Buna) о различиях между программной инженерией и программированием, или чем разработка концепции программного обеспечения отличается от «просто кодинга».


Все программные инженеры могут кодить, но не все программисты способны разрабатывать концепции программного обеспечения. Некоторые люди не любят определение «Программный инженер» (он же инженер-программист, он же Software Engineer) из-за того, что чаще всего слово «инженер» мы используем, говоря о чём-то более физическом — строительстве, например. Наша статья, разумеется, не о самом термине. Если он вдруг вызывает у вас отторжение, его легко можно заменить на что-то связанное с креативностью. «Создатель ПО», «автор ПО» … да хоть «Творец ПО»!

Когда мы говорим о «программном инженере», мы подразумеваем человека, чьей основной задачей является не просто написание кода, но создание качественного приложения. И в этом он видит своё призвание, применяя в работе научный подход и статистические методы. Для него программирование — не просто способ заработка для прокорма.

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

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

Вам нужны еще примеры?

  • Все мы учим математику и письмо в школе, но это не делает нас математиками и писателями.
  • Большинство из нас способны приготовить сносное, а порой — и очень вкусное блюдо, но не каждый рискнёт приготовить стол на 100 персон для званого ужина в посольстве. В этом случае мы нанимаем повара.
  • Готовы ли вы прямо сейчас всецело доверить постройку нового дома соседскому ребёнку, создающему впечатляющие шедевры из Lego?

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

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

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


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

По моему мнению, если человек не понимает сути проблемы, ему не стоит даже начинать программировать её решение.

Инженерный склад ума — поиск прикладных решений

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

«Интеллектуалы решают проблемы, гении предотвращают их»

— Альберт Эйнштейн


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

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

Качество программы и качество кода

Хорошие программы понятны и читабельны. Их легко расширять, они отлично ладят с другими программами, и работа с ними не станет вашим ночным кошмаром. Качество кода не является предметом переговоров. Оно должно быть высоким, и всё тут. При его рассмотрении недопустимы отговорки вроде плохого настроения кодера или слишком сжатых сроков исполнения (ох уж эти дедлайны!).

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

Хотите знать больше о программировании на Java? Вступайте в группу Java Developer!

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


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

Другой не менее важный признак хорошей программы — понятность кода, а не количество пройденных приложением тестов или даже не хорошее покрытие тестами. Казалось бы, простые вопросы: «Может ли кто-то, кроме меня, разобраться с моим кодом?», «Смогу ли я, написав сегодня этот код, понять его через несколько недель?».

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

«Есть только две действительно сложные вещи: инвалидация кэша и именование сущностей»

— Фил Карлтон.

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

«Я написал бы короче, но у меня не было времени»

— Марк Твен.

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

Окружения и тестирование

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


Если речь идёт о веб-приложениях, то они должны работать во всех основных браузерах. Создавая декстопное приложение, нужно удостовериться, что оно запускается и корректно работает и на Mac, и на Windows, и на Linux. Ну а программа, зависит от данных, то приложение должно работать даже в случае медленного соединения с данными либо его отсутствия.

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

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

Стоимость и эффективность

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


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

Задача Software Engineer состоит в написании эффективного кода, который не использует вычислительные ресурсы без необходимости.

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

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

Ориентация на удобство пользователя

Хороший программист ведет разработку с мыслью об Опыте Пользователя (User Experience (UX)). Взаимодействие «человек-машина» — тема с бесконечным количеством исследований и решений. Чем больше решений применяется, тем лучше должна получится программа.

Вот несколько примеров, просто для того что бы вы прочувствовали, что это за направление такое:

  • Когда ведется разработка форм для ввода данных, таких, как e-mail, хорошая программа должна игнорировать регистр букв для адреса электронной почты. Она не должна выдавать ошибку, если нажата клавиша CAPSLOCK, поскольку адрес электронной почты уникален в нижнем регистре. Если программа принимает на ввод новый адрес электронной почты, проверяйте его на ранних этапах ввода, чтобы предупредить пользователя о том, что он использует неверный формат адреса. Такое решение включает как очевидные проверки вроде пропущенный знак «@», а также не столь очевидные, как, например, проверка на неправильный порядок символов вроде «gmail.ocm»

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

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

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

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

Надежность, защищенность и безопасность

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

Настоящий профессионал знает, что он несёт ответственность за безопасность и защищенность своего решения.

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

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


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

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

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

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

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

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

Необходимые инструменты

Нет сомнений, нам нужны разные и хорошие инструменты разработки. Их роль часто недооценивают, но на самом деле они изрядно экономят время и силы, упрощая некоторые задачи на порядок. Представьте, если бы вам до сих приходилось заливать файлы по FTP для развертывания, так сказать, по старинке. Вообразите отладку проблем сети и производительности без Chrome DevTools! А как неэффективно в наши дни было бы писать код на JavaScript без ESlit и Prettier!


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

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

Более качественные и современные инструменты помогут вам стать лучшим программистом. Находите их, используйте, цените, и, если можете, — улучшайте их. И не зацикливайтесь на одном и том же: кто знает, возможно, с новым инструментом вы один раз потратите время на установку и изучение, а затем будете решать задачи в разы быстрее?

Эволюция программной инженерии

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

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

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

javarush.ru

назначение, основные принципы и понятия

Введение
в программную инженерию

    1. Предпосылки и история

В конце
60-х – начале 70-х годов прошлого века
произошло событие, которое вошло в
историю как первый кризис программирования.
Событие состояло в том, что стоимость
программного обеспечения стала
приближаться к стоимости аппаратуры
(«железа»), а динамика роста этих
стоимостей позволяла прогнозировать,
что к середине 90-годов все человечество
будет заниматься разработкой программ
для компьютеров. Тогда и заговорили о
программной инженерии (или технологии
программирования, как это называлось
в России) как о некоторой дисциплине,
целью которой является сокращение
стоимости программ.

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

      1. Повторное использование кода (модульное программирование)

Проблема.
На первых этапах становления программной
инженерии (даже когда она так еще не
называлась) было отмечено, что высокая
стоимость программ связана с разработкой
одинаковых (или похожих) фрагментов
кода в различных программах. Вызвано
это было тем, что в различных программах
как части этих программ решались
одинаковые (или похожие) задачи: решение
нелинейных уравнений, расчет заработной
платы, … Использование при создании
новых программ ранее написанных
фрагментов сулило существенное снижение
сроков и стоимости разработки.

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

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

      1. Рост сложности программ (структурное программирование)

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

  1. Большой
    объем кода (миллионы строк)

  2. Большое
    количество связей между элементами
    кода

  3. Большое
    количество разработчиков (сотни человек)

  4. Большое
    количество пользователей (сотни и
    тысячи)

  5. Длительное
    время использования

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

Структурное
программирование
. Этап сопровождения
программного комплекса включал действия
по исправлению ошибок в работе программы
и внесению изменений в соответствии с
изменившимися требованиями пользователей.
Основная причина высокой стоимости (а
порой и невозможности выполнения) этапа
сопровождения состояла в том, что
программы были плохо спроектированы –
документация была не понятна и не
соответствовала программному коду, а
сам программный код был очень сложен и
запутан. Нужна технология, которая
обеспечит «правильное» проектирование
и кодирование. Основные принципы
технологии структурного проектирования
и кодирования:

  1. Нисходящее
    функциональное проектирование, при
    котором в системе выделяются основные
    функциональные подсистемы, которые
    потом разбиваются на подсистемы и т.д.
    (принцип «разделяй и властвую»)

  2. Применение
    специальных языков проектирования и
    средств автоматизации использования
    этих языков

  3. Дисциплина
    проектирования и разработки: планирование
    и документирование проекта, поддержка
    соответствие кода проектной документации

  4. Структурное
    кодирование без goto

studfiles.net

НОУ ИНТУИТ | Введение в программную инженерию

Форма обучения:

дистанционная

Стоимость самостоятельного обучения:

бесплатно

Доступ:

свободный

Документ об окончании:

Уровень:

Для всех

Длительность:

11:59:00

Выпускников:

961

Качество курса:

4.44 | 4.12


Цель данного курса — представить программную инженерию в виде целостного изложения, концентрируясь на концепции процесса, различных методологиях
разработки ПО (CMMI, MSF, Scrum), отдельных видах деятельности процесса — разработке архитектуры, конфигурационном управлении, работе с требованиями,
тестировании. В стороне умышленно оставлены вопросы, собственно, программирования, поскольку в рамках общего курса их невозможно эффективно
рассмотреть. В качестве программных средств, поддерживающих целостный
процесс разработки ПО, рассматривается технология компании Microsoft — Visual Studio Team System (VSTS)с акцентом на Team Foundation Server (TFS).
Показывается, как изложенный выше теоретический материал можно реализовать на практике, с поддержкой программных средств разработки. Представлено также
описание практикума по MS VSTS, организованного на принципах Scrum.


Несколько слов о практикумах и семинарах, прилагаемых к данному курсу. Их задача – «прокрутить» лекционный материал через «сито» обсуждений, докладов и упражнений, основанных на картах памяти для лучшего усвоения. Серия таких экспериментов уже была проведена в прошлом году, на их основе была создана методика (опубликована в [1]) по активизации collaborative learning процессов и повышении активности студентов в изучении лекционного материала. Подобного рода поддержка лекционного курса крайне необходима, как показывает наш опыт, поскольку курс состоит в обсуждении проблем и способов их решений, с которыми студенты еще не сталкивались на практике. Мы хотели бы также дополнительно поддержать данный курс практикумами по средствам поддержки жизненного цикла разработки ПО на основе TFS и процессам разработки.

Теги: CMMI, MSFS, team, visual studio, z-отчет, анализ, архитектуры, диаграмма, документация, интеграция, интерфейсы, история, контроль версий, поддержка, программная инженерия, проектирование, протоколы, процедуры, разработка, сборка, серверы, сервисы, стандарты, тестирование, элементы


Дополнительные курсы

 

2 часа 30 минут


О предмете изучения

Понятие программной инженерии. Основные определения: информатика, Системотехника, Бизнес-реинжиниринг. Программное обеспечение: определение, свойства.


Процесс разработки программного обеспечения

Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии. Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды деятельности.


Архитектура ПО

Понятие архитектуры ПО. Точка зрения и характеристики точек зрения. Множественность точек зрения при разработке ПО.


Управление требованиями

Виды требований: функциональные требования, нефункциональные требования. Свойства требований: ясность и недвусмысленность, полнота и непротиворечивость, необходимый уровень детализации, прослеживаемость, тестируемость и проверяемость, модифицируемость. Формализация требований. Цикл работы с требованиями.


Конфигурационное управление

Понятие конфигурационного управления. Управление версиями. Понятие «ветки» проекта. Управление сборками. Средства версионного контроля. Единицы конфигурационного управления. Понятие baseline.


Тестирование

Стандартизация качества. Методы обеспечения качества ПО. Понятие тестирования. Тестирование черного ящика. Тестирование белого ящика. Инструменты тестирования. Критерии тестирования. Виды тестирования. Работа с ошибками. Средства контроля ошибок (bug tracking systems).


MSF

IT решение. Основные принципы MSF. Модель команды: основные принципы, ролевые кластеры. Масштабирование команды MSF. Модель процесса. Управление компромиссами.


CMMI

Понятие CMMI. Уровни зрелости процессов по CMMI. Области усовершенствования.


«Гибкие» (agile) методы разработки

Общее описание «гибких» методов разработки ПО. Extreme Programming: общее описание, основные принципы организации процесса. Scrum: общее описание, роли, практики.


VSTS: управление элементами работ (Work Items)

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


VSTS: конфигурационное управление

Система контроля версий. Отслеживание изменений отдельных файлов. Правила внесения изменений. Управление ветками. Сохранение без внесения. Автоматические сборки.


VSTS: тестирование

Система отслеживания ошибок. Создание описания ошибки. Связь изменений исходных текстов ПО и ошибок. Система оповещений. Модульные тесты. Пакеты тестов. Автоматическое тестирование Web-приложений.


Практикум

Требования к техническому оснащению. Организация процесса. Модельная задача. Требования к студентам. Масштабируемость практикума. Обзор тем и задач. Тема 1. Знакомство и создание проекта. Тема 2. Работа с системой отслеживания ошибок. Тема 3. Работа с системой контроля версий. Тема 4. Разработка модульных тестов. Тема 5. Создание и конфигурация автоматической сборки. Тема 6. Настройка шаблона процесса.

www.intuit.ru

Программная инженерия отличается от программирования / СоХабр

Перевод Software engineering is different from programming.

Некоторым людям не нравится термин «программный инженер» из-за метафоры с инженерным делом. Но эта статья не про термин. Если он вам не нравится, замените на Автора программ, Умельца по программному обеспечению или Программного художника!

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

Умение программировать не делает вас программным инженером.


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

Я люблю приводить такое сравнение: все могут развлекаться пением в душе, но приходя в гости, вряд ли кто-то включит записи своего «исполнения». Все предпочтут слушать профессионалов.

Нужны ещё примеры? Пожалуйста:

  • В школе мы все изучаем математику и письмо, но это не делает нас математиками и писателями.
  • Большинство из вас легко научится готовить, но если нужно накормить много людей, вы наймёте шеф-повара.
  • Вы вряд ли позовёте своего рукастого соседа построить вам с нуля дом.

В этой статье я хочу поделиться своим мнением, что простые программы очень отличаются от профессионально разработанных (engineered) программ.

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

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

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

Если кто-то не понимает сути задачи, то его нельзя допускать к программированию решения.

Менталитет решения

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

Интеллектуалы решают проблемы, гении их предотвращают.
Альберт Эйнштейн

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

Прежде чем писать программу, инженер должен спросить себя:

  • Какие задачи я пытаюсь решить?
  • Что ещё можно сделать для их решения, кроме написания кода?
  • Как я могу облегчить решение этих задач с помощью кода?

Качество кода

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

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

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

Всё это нужно учитывать при проектировании программ. Какие сообщения они должны принимать? Какие события отслеживать? Какие сообщения отправлять? Как будет устроена аутентификация и авторизация?

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

В информатике есть лишь две трудности: инвалидация кэша и присвоение имён.
Фил Карлтон

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

У меня нет времени писать короткое письмо, так что пишу длинное.
Марк Твен

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

Среды и тестирование

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

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

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

Стоимость и эффективность

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

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

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

Удобство использования

Хорошие программы проектируются с учётом удобства использования (UX). Есть множество исследований и открытий на тему взаимодействия человека с компьютером. И чем больше мы узнаём, тем лучше могут быть наши приложения.

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

  • Если нужна форма ввода адресов электронной почты, то хорошая программа будет игнорировать регистры букв. И даже обрезать пробелы по краям. На заставляйте пользователей нервничать из-за включённого CapsLock, адрес почты должен состоять из прописных букв. Если программа принимает новые адреса, то сразу проверяйте их корректность и сразу сообщайте пользователям, что они, возможно, вводят неправильный адрес. Сюда относится как очевидная проверка на отсутствие символа @, так и менее заметные ошибки, например, в написании доменов: “gmail.ocm.”
  • Если нужно перенаправить пользователя для выполнения какой-то задачи, хорошая программа запомнит, откуда перешёл человек, и в конце вернёт его обратно. Также хорошая программа запоминает любые уже внесённые данные и совершённые действия, если в дальнейшем о них нужно будет спросить пользователя. Допустим, вы в качестве гостя ищете авиарейс на Expedia. А затем решили создать аккаунт. В нём должна быть сохранена вся ваша предыдущая поисковая история, чтобы вы могли обращаться к ней при заходе с разных компьютеров.
  • Хорошая программа спроектирована с учётом пользовательских сценариев. Поставьте себя на место пользователя. Не надо просто добавлять фичи! Однажды я бронировал билет в авиакомпании United, и забыл ввести свой номер постоянного клиента. Получив подтверждение о бронировании, я зашёл на сайт United, чтобы добавить номер, и на это пришлось потратить ДЕСЯТЬ минут. Там просто не было никаких явных способов добавления, мне пришлось перебрать все ссылки, чтобы найти эту фичу. Зашёл на страницу, где можно было ввести номер, и сначала не мог найти поле ввода, потому что оно было запрятано в глубинах большой формы. Мне пришлось отредактировать информацию о пассажире, пролистать назад около 20 разделов этой формы, выбрать тип номера, который я хочу использовать, а также ввести требуемый номер телефона, чтобы наконец подтвердить заполнение формы. Это пример программы, которая проектировалась без учёта удобства пользователя.

Надёжность, защищённость и безопасность

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

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

Проблема защищённости связана с вводом не только плохих и вредоносных, но также и нормальных данных. Если пользователи забывают свои пароли, то сколько попыток даётся на ввод? Вы блокируете пользователей после определённого количества попыток? А если ещё кто-то пытается блокировать пользователей? Вы разрешаете вводить пароли при незашифрованном соединении? А если попытка входа совершается с необычного для этого пользователя IP-адреса, компьютера, системы? Что вы делаете, если действия пользователя выглядят автоматизированными?

Что вы делаете для защиты своих пользователей от межсайтового скриптинга и подложных запросов, от атак «человек посередине» и простого социального фишинга? У вас есть запасная стратегия на случай DDoS-атаки на ваши серверы? Всё это лишь малая часть проблем, которые вам нужно предусмотреть.

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

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

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

Инструменты

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

Если бы нам сегодня ещё приходилось слать файлы по FTP для развёртывания приложений? Если бы нам приходилось отлаживать проблемы с сетью и производительностью без Chrome DevTools? Представьте, насколько неэффективно сегодня писать JavaScript без ESLint и Prettier!

Если вы JavaScript-разработчик и вынуждены выбирать какой-то один плагин для редактора кода, берите ESLint.

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

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

Выбор языка имеет значение. Типобезопасность имеет значение. TypeScript (и Flow) — лучшее, что произошло с JavaScript. Статичный анализ кода важнее, чем вы думаете. Если вы им не пользуетесь, то ваш код остаётся уязвимее к будущим проблемам. Не пишите код без системы статичной типизации. Если ваш язык не имеет статичной типизации, то либо меняйте язык, либо найдите траспилятор. Сегодня транспиляторы достаточно сообразительны и работают, читая комментарии в коде. Я считаю, именно так в будущем будет выполняться проверка типов в языках, изначально её не поддерживающих.

Эволюция программной инженерии

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

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

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

sohabr.net

Инженерия программного обеспечения — это… Что такое Инженерия программного обеспечения?

Новый Airbus A-380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк исходного кода.

Инженерия программного обеспечения (англ. Software Engineering) — приложение систематического, дисциплинного, измеримого подхода к развитию, оперированию и обслуживанию программного обеспечения, а также исследованию этих подходов; то есть, приложение дисциплины инженерии к программному обеспечению.

Программная инженерия

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

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

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

Основные сведения

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

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

Все же, несмотря на юность профессии, будущее области радужно, поскольку, Money Magazine и Salary.com оценили профессию разработчика программного обеспечения как лучшую работу в Америке в 2006.

Разработка программного обеспечения связана с дисциплинами информатики, управления проектами, и инженерии систем.

История

Когда первые современные цифровые компьютеры появились в начале 1940-х годов [9] наборы исполняемых команд уже были встроены в машину. Специалисты быстро поняли, что этот подход не слишком удобен. Так появилась “архитектура хранимых программ” или архитектура фон Неймана. Таким образом, деление на «железо» и «программное обеспечение» началось с абстракции, используемой чтобы решить проблему сложности вычислений.

Первые языки программирования стали появляться в 1950-х годах, и это был еще один важный шаг в абстракции. Основные языки, такие как Fortran, Algol и Cobol были выпущены в конце 1950-х для решения научных, алгоритмических и бизнес-задач соответственно. Дейкстра написал свою известную статью, «Go To Statement Considered Harmful» в 1968 году, а Дэвид Парнас ввел ключевое понятие модульности и скрытия информации в 1972 году, чтобы помочь программистам справляться со все более и более сложными программными системами. Системное программное обеспечение для управления аппаратным, названное “операционная система” было представлено компанией Unix в 1969 году. В 1967 году язык Simula ввел понятие объектно-ориентированной парадигмы программирования.

Эти достижения в области программного обеспечения были встречены большим прорывом компьютерной технике. В середине 1970-х годов был представлен микрокомпьютер, что позволило любителям получить собственный компьютер и писать свои программы для него. Это, в свою очередь привело к появлению персональных компьютеров (ПК) и Microsoft Windows. Также в середине 1980-х появляются такие понятия как цикл разработки программного обеспечения в качестве некоторого консенсуса для централизованной разработки программного обеспечения. Конец 1970-х и начало 1980-х годов ознаменовались появлением нескольких новых Simula-подобных объектно-ориентированных языков программирования, в том числе Smalltalk, Objective-C и C++.

Open Source, появившийся в начале 90-х в форме Linux, а также других программ, ввел понятие “базара” или децентрализованного стиля разработки ПО. Затем мировая паутина и стремительная популяризация интернета в середине 90-х изменили программную инженерию еще раз. Распределенные системы получили широкое распространение, как способ устройства систем, а также язык Java с его собственной виртуальной машиной, сделали еще один шаг в абстракции. Сотрудничество программистов позволило появиться на свет документу, названному Agile Manifesto, который поддерживал облегчение процессов, что способствовало написанию более дешевых и регулярно обновляемых программ.

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

Профессия

Правовые требования к лицензированию и сертификации профессиональных программных инженеров отличаются во всем мире. В Великобритании, Британское компьютерное общество выдает лицензии программных инженеров и члены общества могут также стать «дипломированными инженерами» (C.Eng), а в некоторых районах Канады, например, Альберта, Онтарио и Квебек, программные инженеры могут также быть «профессиональными инженерами» (P.Eng) и / или «мастерами информационных систем» (ISP) ,однако, нет никаких правовых требований для данных специализаций.

Работа

В 2004 году американское Бюро статистики труда, насчитало 760 840 программных инженеров, занимающих рабочие места в США. В тот же период времени было около 1,4 млн. практиков, занятых в США в других смешанных инженерных специальностях. Благодаря своей относительной новизне, как формальная область изучения, программная инженерия часто преподается как часть учебной программы компьютерных наук, и многие программные инженеры имеют неплохие познания в информатике.

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

Большинство программных инженеров и программистов работает 40 часов в неделю, а около 15 процентов программных инженеров и 11 процентов программистов работали более 50 часов в неделю в 2008 году. Травмы в этих профессиях встречаются редко. Однако, как и в других профессиях, где надо проводить много времени перед компьютером, люди этих специальностей более подвержены к усталости глаз, болям в спине, а также болезням рук и запястий, таких как синдром запястного канала.

Сертификация

Институт Программной Инженерии предлагает сертификацию по конкретным специальностям, таким как: безопасность, оптимизация процессов, а также архитектура программного обеспечения. Apple, IBM, Microsoft и другие компании финансируют собственные экзамены для сертификации. Многие IT-программы сертификации ориентированы на конкретные технологии, и управляется поставщиками этих технологий. Эти программы сертификации разработаны с учетом места, на которое будут наниматься люди, использующие эти технологии.

Расширение сертификации «Общие навыки разработки программного обеспечения» доступны через различные профессиональные сообщества. В 2006 году IEEE сертифицировала более 575 специалистов в области программного обеспечения, как «Certified Software Development Professional»(CSDP). В 2008 году они добавили сертификат начального уровня известный как «Certified Software Development Associate» (CSDA). У ACM была профессиональная программа сертификации в начале 1980-х, которая была прекращена из-за отсутствия интереса.В ACM также рассматривали возможность сертификации профессиональных программных инженеров в конце 1990-х годов, но в итоге решили, что такая сертификация не подходит для профессиональной производственной практики разработки программного обеспечения.

В Великобритании, Британское компьютерное общество разработало юридически признанную профессиональную сертификацию, называемую «Chartered IT Professional» (CITP), и доступную только для полных членов (MBCS). Программные инженеры имеют право на членство в Институте Инженерии и Технологии и могут соответственно получить статус дипломированного инженера. В Канаде, Организация en:Canadian Information Processing Society также разработала юридически признанную профессиональную сертификацию, названную «Information Systems Professional» (ISP). [23] В Онтарио, Канада, Программные инженеры, которые заканчивают канадский Engineering Accreditation Board (CEAB), успешно сдавшие Professional Practice Examination (PPE) и, имеющие по крайней мере 48 месяцев опыта работы программным инженером, имеют право получить лицензию через PEO(«Профессиональные инженеры Онтарио») и могут стать Профессиональными инженерами (P.Eng).

Влияние глобализации

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

Образование

Знания в области программирования являются необходимым условием для того, чтобы стать программным инженером. В 2004 году IEEE Computer Society выпустил SWEBOK, который был опубликован в качестве стандарта ISO / IEC 19759:2004, описывающего объем знаний, который по их мнению, должен получить дипломированный программный инженер с четырехлетним опытом. Многие люди входят в эту профессии, получив высшее образование или отучившись в профессионально-техническом училище. Стандартный учебный план для международной степени бакалавра программной инженерии был определен CCSE, и обновлен в 2004 году. Ряд университетов имеют программы обучения программных инженеров. С 2010 года насчитывалось 244 очных программы, 70 Интернет-курсов, 230 программ для специалистов, 41 программ для ученых в этой области, а также 69 программ для сертификатов в Соединенных Штатах.

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

Сравнение с другими дисциплинами

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

Поддисциплины

Программная инженерия может быть разделена на десять поддисциплин. К ним относятся:

  • Анализ системных требований: выявление, анализ, спецификация и проверка требований к программному обеспечению.
  • Проектирование программного обеспечения: процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или компонента.
  • Конструирование программного обеспечения: поэтапное создание работающего программного обеспечения
  • Тестирование программного обеспечения: динамический контроль поведения программы на конечном множестве тестов, надлежащим образом выбранных из бесконечной области.
  • Обслуживание программное обеспечение: совокупность мероприятий, необходимых для обеспечения экономически эффективной поддержки программного обеспечения.
  • Управление конфигурацией: определение конфигурации системы на различные моменты времени для систематического контроля изменений конфигурации, а также сохранение целостности и прослеживаемости конфигурации на протяжении всего жизненного цикла системы.
  • Управление разработкой программного обеспечения: применение мер управления, планирования, координации, измерения, мониторинга, контроля и отчетности, для того, чтобы разработка и сопровождение программного обеспечения являлась систематической и дисциплинированной.
  • Процесс разработки программного обеспечения: определение, реализация, оценка, измерение, управление, изменение и улучшение процесса жизненного цикла программы как такового.
  • Средства и методы разработки программного обеспечения: компьютерные средства, которые предназначены для оказания помощи процессам жизненного цикла программы (см. Computer Aided Software Engineering), а также методы, которые применяют к структуре деятельности разработки программного обеспечения с целью сделать разработку более систематической и в конечном счете иметь более шансов на успех.
  • Качество программного обеспечения: проверка удовлетворения набором собственных характеристик программы требованиям к программному обеспечению.

Родственные дисциплины

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

Инженерия систем

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

Внешние ссылки

См. также

Литература

  • Иан Соммервилл. Инженерия программного обеспечения, 2002 [1]
  • Орлов С. А. Технологии разработки программного обеспечения: Разработка сложных программных систем Изд. 3-е, 2004
  • Эрик Дж. Брауде. Технология разработки программного обеспечения, 2004
  • Липаев, В.В. Программная инженерия. Методологические основы [Текст] : Учеб. / В. В. Липаев ; Гос. ун-т — Высшая школа экономики. — М. : ТЕИС, 2006. — 608 с. — 1000 экз. —

ISBN 5-7598-0424-3, УДК 004.41(075.8), ББК 32.973.26-018я73, Липаев, Высшая школа экономики, ТЕИС, 2006, pdf, экономика, программирование

Примечания

  1. Curricula Recommendations Software Engineering SE 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering
  2. Computing Curricula A Volume of the Computing Curricula Series SE2004
  3. Sharing What We Know About Software Engineering // Proceedings of the FSE/SDP workshop on Future of software engineering research (FoSER ’10). — ACM, 2010. — P. 439–442. — ISBN 978-1-4503-0427-6

dic.academic.ru

Программная инженерия 231000.62

Срок обученияНа базе 11 класса:Очная — 4 года

Вступительные экзамены


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


 

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

1. Русский язык

2. Математика (профильный)

3. Физика

 или 

Информатика и ИКТ


Будущая квалификация



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


 


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

Бакалавр по направлению подготовки «Программная инженерия»

Будущие профессии Инженер-конструктор программного обеспечения | Инженер-проектировщик программных систем | Программист | Специалист по программной инженерии  | Специалист по разработке программно-информационных систем | Специалист по тестированию программного обеспечения | Специалист по управлению программными проектами | Техник по разработке и сопровождению программного обеспечения


Чему научат?

  • Участвовать в проведении научных исследований (экспериментов, наблюдений и количественных измерений) программных продуктов, проектов, процессов, методов и инструментов программной инженерии

  • Заниматься построением моделей программных проектов и программных продуктов с использованием инструментальных средств компьютерного моделирования

  • Составлять описания проводимых исследований, готовить данные для составления обзоров и отчетов

  • Заниматься сбором и анализом требований заказчика к программному продукту

  • Помогать заказчику в оценке и выборе вариантов программного обеспечения

  • Участвовать в составлении коммерческого предложения заказчику, готовить презентации и согласовывать пакет договорных документов

  • Проектировать компоненты программного продукта в объеме, необходимом для их конструирования в рамках поставленного задания

  • Создавать компоненты программного обеспечения (кодирование, отладка, модульное и интеграционное тестирование)

  • Выполнять измерения и рефакторинг кода в соответствии с планом

  • Заниматься разработкой тестового окружения и созданием тестовых сценариев

  • Разрабатывать и оформлять эскизную, техническую и рабочую проектную документацию

  • Осваивать и применять средства автоматизированного проектирования, разработки, тестирования и сопровождения программного обеспечения

  • Осваивать и применять методы и инструментальные средства управления инженерной деятельностью и процессами жизненного цикла программного обеспечения

  • Осуществлять контроль, оценку и обеспечение качества программной продукции

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

  • Участвовать в процессах разработки программного обеспечения

  • Участвовать в создании технической документации по результатам выполнения работ

  • Проводить обучение и аттестацию пользователей программных систем

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

  • Участвовать в составлении технической документации (графиков работ, инструкций, планов, смет, заявок на материалы, оборудование, программное обеспечение)

  • Планировать и координировать работу по настройке и сопровождению программного продукта

  • Организовывать работу малых коллективов исполнителей программного проекта

  • Вводить в эксплуатацию программное обеспечение (осуществлять инсталляцию, настраивать  параметры, адаптировать, администрировать)

  • Осуществлять профилактическое и корректирующее сопровождение программного продукта в процессе эксплуатации

  • Обучать и консультировать пользователей по работе с программной системой

Важные учебные предметыАлгоритмы и структуры данных | Архитектура вычислительных систем | Информатика и программирование | Конструирование программного обеспечения | Операционные системы и сети | Проектирование и архитектура программных систем | Проектирование человеко-машинного интерфейса | Тестирование программного обеспечения | Управление программными проектами | Экономика программной инженерии


Практика студентов


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


Итоговая аттестация
студентов:

  • Защита выпускной квалификационной работы (бакалаврская работа)

  • Государственный экзамен (по решению вуза)

Вы можете освоить эту специальность в следующих регионах:
Вся Россия — 140 вузов



Вузы, в которых можно освоить специальность
МоскваНациональный исследовательский университет «Высшая школа экономики»
МоскваНациональный исследовательский университет «МИЭТ»

Похожие специальности

Фотографии


Поищем по тегам?инженерное образование, инженерные специальности, профессия программист, математические специальности, математическое образование

Материал подготовлен сайтом www.moeobrazovanie.ru
Любое использование материала страницы допускается только с письменного согласия редакции.

moeobrazovanie.ru

Мифы о программной инженерии | Открытые системы. СУБД

20.02.2003

Хоссейн Саедян, Доналд Берет, Нэнси Мид

В ставшей классической статье, опубликованной в 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 к той или иной модели. Если проводить эксперименты и анализировать их результаты, то, со временем, станет ясно, какое из решений является правильным. Действительно, неплохо иметь много различных программ обучения, поскольку они позволят сформировать подходящую среду для экспериментов и открытий.

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

Литература

  1. W. Gibbs, «Software’s Chronic Crisis», Scientific Am., vol. 271, no. 3, 1994. Sept.
  2. H. Lieberman, C. Fry, «Will Software Ever Work?» Comm. ACM, vol. 44, no. 3, 2001. Mar.
  3. Computing Curricula 2001, ACM Special Interest Group on Computer Science Education, 2001.
  4. 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.
  5. T. Lethbridge, «What Knowledge Is Important to a Software Professional?» Computer, vol. 33, no. 5, 2000. May
  6. ABET, ABET Criteria for Accrediting Computing Programs, 2002.
  7. D. Parnas, «Software Engineering Programs Are Not Computer Science Programs», IEEE Software, vol. 16, no. 6, 1999. Nov./Dec.
  8. M. Shaw, «Prospect for an Engineering Discipline of Software», IEEE Software, vol. 7, no. 1, Jan./Feb. 1990.
  9. M. McCracken, «Software Engineering Education: What Academia Can Do», IEEE Software, vol. 14, no. 6, 1997. Nov./Dec.
  10. M. Shaw, «Software Engineering Education: A Roadmap,» The Future of Software Engineering, A. Finkelstein, ed., ACM Press, New York, 2000.
  11. S. McConnell and L. Tripp, «Professional Software Engineering: Fact or Fiction?» IEEE Software, vol. 16, no. 6, 1999. Nov./Dec.
  12. E. Yourdon, Death March, Prentice Hall, Upper Saddle River, N.J., 1997.
  13. T. DeMarco, Slack, Broadway Books, New York, 2001.

Хоссейн Саедян ([email protected]) — профессор факультета электротехники и информатики университета штата Канзас. Руководит комитетом Committee on Software Engineering Education в IEEE-CS TCSE. Доналд Бегерт ([email protected]) — профессор технологического института Роуз-Хулмана. Специализируется в области программных инструментальных средств помощи студентам и методологий программного обеспечения. Является редактором FASE, электронного бюллетеня, посвященного вопросам образования и профессионального обучения в области программной инженерии. Нэнси Мид ([email protected]) — руководитель группы Survivable Systems Engineering, а также одна из руководителей программы Networked Systems Survivability Program, ведущейся в Институте программной инженерии Университета Карнеги-Меллона.


Hossein Saiedian, Donald J. Bagert, Nancy R. Mead. Software Engineering Programs: Dispelling the Myths and Misconceptions. IEEE Software, September-October 2002. IEEE Computer Society, 2002, All rights reserved. Reprinted with permission.

www.osp.ru