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

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:08, 9 июня 2017.

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

L12.jpg

История

Стремительное развитие данной отрасли началось в конце 60х в начале 70-х годов прошлого века, когда произошел первый кризис программирования. Это событие состояло в том, что стоимость ПО стала приближаться к стоимости аппаратуры («железа»), а динамика роста такой цены позволяла прогнозировать, что к середине 90-х годов все человечество будет заниматься разработкой ПО для компьютера. Развитие микроэлектроники привело к резкому увеличению производительности ЭВМ при значительном снижении стоимости. Ограничения для аппаратных средств медленно уходили , а оставшиеся ограничения приходятся на долю ПО. Это приводило к тому, что умение строить новые программы отставало от требований к новым. Другая тенденция развития зародилась внутри самой отрасли и была основана на усилении взгляда на разработку программ. Тогда и заговорили о программной инженерии( технологии промышленного программирования) как о некоторой дисциплине, целью которой является сокращение стоимости программ. Такая проблема должна решаться более грамотной организацией процесса разработки. Это и привело к развитию методологий проектирования ПО и возведения его в главенствующие составляющие разработки. Термин программная инженерия был в первые использован в 1968 году в качестве темы конференции, посвященной вопросам максимальной загрузки самых мощных (по тем временам) компьютеров. Определение заложило основы новой научно-практической дисциплины: нужно было создать систему инженерных принципов, применимую к разработки ПО, обеспечить экономичность и надежность разработки, а также эффективную работоспособность конечного продукта на различных реальных машинах.[Источник 1]

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

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

  • Традиционная модель

Традиционные методологии построены на последовательном выполнении всех фаз проекта и конечный продукт будет получен только после выполнения всех этапов. Возвращение на предыдущий этап не предусмотрено и при появлении критических ошибок весь проект начинается сначала. Основным примером является каскадная модель или модель Водопад. Источником принято считать статью Уинстона Ройса вышедшею в 1970 году. Он описывал эту модель как пример противопоставленный итеративной модели, применимый только для очень простых проектов и сам пользовался итеративными методологиями. Так же Ройс писал, что в особо сложных местах проекта и при применении новых, ранее не используемых технологий, промежуточные этапы можно повторить дважды и заказчик по окончанию проекта получает вторую версию продукта. Такой подход нельзя назвать итеративным, но и однозначно последовательным тоже. На начальном периоде она сыграла ведущую роль как метод регулярной разработки сложного ПО. В 70x — 80x годах XX века модель была принята как стандарт министерства обороны США. По мере развития методологий каскадная модель подвергалась жесткой критики со стороны всех исследователей, предлагавших свои методологии. Последовательное выполнение этапов разработки не дает изменить требования к программному продукту до самого релиза. Чем больше проект тем больше накапливается проблем в процессе проектирования. И реализация изменений в следующей версии продукта иногда становится не целесообразной. Продукт необходимо писать с 0. Таким образом стоимость работоспособной версии не оправдано сильно растет. А процент успешно завершенных проектов слишком мал. Однако, можно ли назвать традиционные методологии разработки отжившими свой век? Не совсем. Для проектов затрагивающих безопасность жизнедеятельности строго поставленные требования и высокая степень формализации является основополагающим и необходимым фактором. Кроме того, несмотря, на критику традиционной модели, она играет важную роль, потому что налагает на процесс разработки требование крайне необходимой для него дисциплинированности, с помощью которой удается благополучно обходить неструктурированные процессы. Данная модель внесла фундаментальный вклад в понимание процессов разработки ПО.

  • Спиральная модель

Спиральная модель стала следующим этапом развития методологий, поскольку она решает основную проблему традиционной модели. Каждая фаза традиционного процесса разработки в спиральной методологии завершается этапом прототипирования и управления рисками. Этап прототипирования после каждой фазы проекта позволяет определить, насколько текущее состояние проекта соответствует первоначальному плану. По итогам прототипирования выполняется либо переход к следующей фазе, либо возвращение на одну из предыдущих фаз. Однако фазы и последовательность фаз остаются линейными. Автором данной модели является Барри Боэм, опубликовавший в 1988 году статью «A Spiral Model of Software Development and Enhancement». Не смотря на то, что в SWEBOK данная модель выделена отдельно от итеративной, при описании моделей напрашивается вывод об отнесении спиральной методологии к семейству итеративных. Это обуславливается и возможностью изменения требований между этапами и выпуска прототипов продукта после каждого цикла. Возможно такое разделение связано с авторской принадлежностью методологий.

  • Итеративная модель
Iot.jpg

Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Упоминания о данной методологии начали появляться задолго до статьи У. Ройса и появления самой программной инженерии. Истоки концепции итеративной разработки прослеживаются в относящихся к 30-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из Bell Labs. Важной вехой в истории является осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15. По мнению участников этих работ, применение данной методологии в значительной степени определило успех проекта. В настоящее время наиболее популярны гибкие методологии, они относятся именно к итеративным моделям ЖЦ. При описании любой из гибких методологий упоминается принцип разделения на итерации. Однако, особенность данных методологий это упор на человеческий фактор, а не на документацию проекта, что никак не обозначается в описании итеративной и инкрементной методологии. Гибкие методологии разработки начали появляться на фоне быстрорастущего усложнения технологий и всеобщей информатизации. Теперь заказчиком в большинстве случаев является лицо далекое от информационных технологий. Для такого заказчика главным является готовый продукт, а не фолианты документации. При экспоненциально растущем темпе развития информационных технологий сроки на разработку ПО сократились и стали жестче. Теперь нет времени на долгое планирование, написание документации и полновесное тестирование. Программный продукт может устареть еще до релиза. В противовес традиционным методологиям разработки итеративные методологии делят выполнение проекта на короткие итерации, ограниченные по времени. После каждой итерации заказчику продукта предоставляется результат. Предусмотрен откат на предыдущие итерации. Появление гибких методологий не привязано к конкретной дате, так как начиная с середины 90х годов начали появляться и внедряться практически параллельно. Это были методологии разработки такие как: Scrum (1995), экстремальное программирование (1996), Crystal Clear, Lean, Kanban и другие. Созданный в феврале 2001 года, Agile-манифест, провозгласил философию гибких методологий разработки и задал вектор развития данных методологий..

Отличие программной инженерии от информатики

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

Цель современной программной инженерии

Основная цель современных технологий программной инженерии состоит в обеспечении эффективности всего жизненного цикла комплексов программ для ЭВМ в различных проблемно-ориентированных областях. В понятие современной технологии включается совокупность методов и инструментальных средств автоматизации, а также технологические процессы, обеспечивающие жизненный цикл сложных ПС с заданными функциональными и конструктивными характеристиками качества. Для этого рекомендуется использовать наиболее эффективные и совершенные методы проектирования и проводить комплексную автоматизацию ЖЦ ПС. Целеустремленная деятельность разработчиков-поставщиков должна быть направлена на удовлетворение требований заказчиков и пользователей программных продуктов при их применении по прямому назначению. Эта деятельность регламентируется рядом методов и стандартов, которые являются компонентами технологического обеспечения сложных ПС в течение их жизненного цикла. Их применение предполагает высокую дисциплину коллектива специалистов, использование им методик, стандартов, типовых нормативных документов и средств автоматизации разработки, которые регламентируют порядок организации и проведения работ по выполнению технологических операций, направленных на получение, в имеющихся организационно-технических условиях, готового программного продукта с заданными функциями и качеством.[Источник 2]

Источники

  1. # "Software Engineering - textbook"[2015-2017]. Дата обновления 14.02.2017. Режим доступа: http://www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdf (дата обращения 27.04.2017)
  2. #ru-wiki: Программная инженерия[2013-2017]. Дата дата обновления 13.03.2017. Режим доступа: http://www.ruwiki.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%8F (дата обращения 27.04.2017.)

Литература

  1. "Программная инженерия", Орлов С.А. Дата обращения 27.04.2017
  2. "Введение в программную инженерию", Крапенко С.Н. Дата обращения 27.04.2017. Режим доступа: http://www.unn.ru/pages/issues/aids/2007/16.pdf