Это программы, а также вся связанная с ними документация и конфигурационные данные, необходимые для корректной работы программы (т.е. не только программа). В конечном итоге, продаются не программы, а программные продукты, которые бывают двух типов: коробочные продукты (generic products or shrink-wrapped software) и заказные продукты (bespoke or customized products). Важная разница между ними заключается в том, кто ставит задачу (пишет спецификацию).
Программная инженерия — это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. В этом определении есть две важные части:
- "Инженерная дисциплина". Инженеры добиваются результатов. Они применяют теории, методы и средства, пригодные для решения данной задачи, но они применяют их выборочно и всегда пытаются найти решения, даже в тех случаях, когда теорий или методов, соответствующих данной задаче, еще не существует. Кроме того, инженеры должны понимать значимость временных, финансовых и организационных ограничений. В советское время слово "инженер" абсолютно девальвировалось, но инженерное дело от этого не умерло
- "Все аспекты производства ПО". Программная инженерия занимается не только техническими вопросами производства ПО, но и управлением программных проектов, а также разработкой средств, методов и теорий для поддержки процесса производства ПО.
Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. Общепринято мнение, что неправильно выбранный подход должен отрицательно сказаться на качестве и сроках сдачи системы. Но подход надо выбирать с умом — во многих случаях неформальные, "легкие" процессы могут оказаться значительно эффективнее (например, в таких задачах, как написание web-based applications или e-commerce systems).
Информатика занимается теорией и методами компьютерных и программных систем, в то время как программная инженерия занимается практическими проблемами создания ПО. Естественно, инженер-программист обязан в каком-то объеме знать информатику (точно так же, как электрический инженер должен в каком-то объеме знать физику). Однако объем теоретических знаний у разных специалистов сильно разнится и может быть очень невысоким, что тем не менее не мешает решать некоторые задачи (те, что попроще).
В идеале, вся программная инженерия должна быть поддержана какими-то теориями информатики, но практике все значительно сложнее. Инженеры зачастую применяют первые попавшиеся методы, а элегантные теории информатики не всегда могут быть применены к реальным большим системам.
Системная инженерия (а точнее — компьютерная системная инженерия, computer-based systems engineering, CBSE) занимается всеми аспектами создания и эволюции комплексных систем, в которых ПО играет заметную роль. Таким образом, программная инженерия является частью системной инженерии, наряду с созданием аппаратных платформ, созданием архитектуры, системной интеграцией и т.п. В системной инженерии основной упор приходится именно на системные вопросы, а не на составные части системы.
Системная инженерия значительно старше программирования как дисциплина — люди уже очень давно производят сложные индустриальные системы, такие как поезда, химические заводы и т.п.
Программный процесс — это набор действий и связанных с ними результатов, приводящих к созданию программного продукта. Мы будем выделять четыре основных фазы программного процесса:
- Создание спецификации ПО
- Разработка ПО
- Тестирование ПО (включает в себя validation и verification)
- Развитие или эволюция ПО (software evolution)
Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модели всегда являются упрощениями: all models are wrong; some models are useful (E. Deming). Некоторые примеры типов моделей программного процесса:
- Модель технологического процесса (workflow model) — показывает последовательность действий, наряду со входами, выходами и зависимостями. Действия в этой модели представляют собой действия людей.
- Модель потоков данных (data flow or activity model) — представляет процесс в виде набора действий, каждый из которых выполняет некоторое преобразование данных. В этой модели действия могут быть более низкого уровня, чем в предыдущей модели (например, какие-то действия может выполнять компьютер).
- Модель роль/действие (role/action model) — показывает роли людей, участвующих в программном процессе, а также действия, за которые они отвечают.
Есть несколько традиционных моделей разработки ПО:
- Водопадная модель
- Эволюционное развитие (в двух вариантах — с доработкой прототипа и с выбрасыванием, т.е. переписыванием)
- Формальные преобразования — основан на создании математических моделей системы и их дальнейшим преобразованиями, сохраняющими корректность
- Сборка из повторно используемых компонент — предполагает, что части системы уже существуют, и процесс концентрируется скорее на интеграции, чем на разработке
Структура стоимости ПО может здорово отличаться для различных типов проектов и различных методологий. Для типичного проекта, распределение стоимости выглядит приблизительно следующим образом:
Чем больше система, и чем выше ее критичность, тем больший процент будет забирать тестирование.
Если же система разрабатывается с использованием эволюционного подхода, то трудно разделить на отдельные этапы создание спецификаций, проектирование и разработку. В результате, около 10% уходит на создание первичных высокоуровневых спецификаций, порядка 60% — на разработку и все остальное время уходит на тестирование.
Стоимость эволюции системы очень сильно варьируется в зависимости от размера системы и сроком ее жизни. Во многих случаях стоимость сопровождения превосходит стоимость разработки в 3–4 раза.
Наконец, при создании коробочных продуктов стоимость создания спецификации исчезающе мала (около 5%), на разработку (обычно эволюционным способом) уходит около 30-35% времени проекта, а все остальное — тестирование системы на всевозможных конфигурпциях. Для коробочных продуктов особенно трудно оценить стоимость эволюции — обычно процесс создания новой версии не имеет четко выраженного начала, и, кроме того, чаще всего из маркетинговых соображений новая версия подается не как модифицированный продукт, уже купленный пользователем, а как продукт абсолютно новый (хотя и совместимый со старыми).
Метод программной инженерии — это структурный подход к созданию ПО, нацеленный на создание эффективного продукта наиболее прибыльным (рентабельным, cost-effective) путем.
Тема развивается с 1970х: структурный анализ Тома ДеМарко (1978), JSD Джексона (1983). Эти и другие методы тех времен были ориентированы на идентификацию основных функций системы; функционально-ориентированные методы до сих пор популярны. Как это ни смешно, очень часто их применяют неосознанно.
В 1980х гг. эти методы были дополнены всякой объектностью: Буч (1994), Рамбо (1991). Со временем эти методы были объединены в UML (до хрена книжек начиная с 1997 г).
Практически все методы построены на идее создания графических моделей системы с последующим использованием этих моделей в качестве спецификации или архитектуры системы. Методы должны включать в себя следующие компоненты:
- Описание моделей системы и их нотаций (например, объектные модели, конечно-автоматные модели и т.д.)
- Правила, накладывающие ограничения на использование моделей в системе (например, "поймают-обругают" в Real)
- Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов)
- Руководство к действию (наставление, process guidance) — описание действий, которым можно следовать во время создания моделей и последующего их использования (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом)
Нет идеальных методов, все они применимы только для тех или иных случаев. (Следующая фраза выписана специально для Терехова-ст.) Например, ОО-методы хороши для интерактивных систем, но не для систем с жестким реальным временем.
Понятие CASE включает в себя широкий комплекс программ, предназначенных для поддержки процессов создания программного продукта, включая анализ требований, моделирование, отладку и тестирование. Большинство современных методов поддержаны соответствующими CASE-средствами.
Любопытное разделение: CASE-средства, поддерживающие анализ и проектирование, иногда называют CASE-средствами верхнего уровня (upper-CASE tools), а средства, поддерживающие реализацию и тестирование, такие как отладчики, средства анализа системы, генераторы тестов и редакторы программ, называют средствами нижнего уровня (lower-CASE tools).
Программные продукты обладают целым рядом свойств, не сводящихся к функциональности, которую они реализуют. Скорее, эти свойства относятся к поведению и внешнему виду программы во время выполнения, а также к структуре и организации исходной программы и связанной с ней документацией. Примеры подобных свойств (называемых также нефункциональными атрибутами) являются время отклика системы и читаемость исходных текстов.
Конкретный набор свойств, которые следует ожидать от программы, конечно же зависит от ее области применения: банковская система должна быть надежно защищенной, игра иметь приемлемое время отклика, телефонная система коммутации должна быть надежной и т.п.
Большинство свойств программы можно обобщить в несколько категорий (см. таблицу):
(maintainability) |
Система должна быть написана с расчетом на дальнейшее развитие. Это критическое свойство системы, т.к. изменения ПО неизбежны вследствие изменения бизнеса. |
(dependability) |
Надежность включает в себя отказоустойчивость, безопасность и защищенность. Надежное ПО не должно приводить к физическому или экономическому ущербу в случае сбоя системы. |
(efficiency) |
ПО не должно впустую тратить системные ресурсы, такие как память или процессорное время. Поэтому эффективность включает в себя отзывчивость, время процессора, утилизацию памяти и т.п. |
(usability) |
ПО должно быть легким в использовании, причем именно тем типом пользователей, на которых рассчитано приложение. Это включает в себя интерфейс пользователя и адекватную документацию. |
Всего-то три основные трудности:
- Устаревшие системы (legacy challenge)
- Работа в гетерогенной среде (heterogeneity challenge)
- Недостаток времени, отводимого на разработку программных продуктов (delivery challenge)
Понятно, что эти проблемы не являются абсолютно независимыми и могут накладываться друг на друга.