Ответы Булаченко

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

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

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

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

История

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

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

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

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

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

2. CASE (англ. Computer-Aided Software Engineering) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.

Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов.

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

• мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

• интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

• использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

• графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

• средства разработки приложений, включая языки 4GL и генераторы кодов;

• средства конфигурационного управления;

• средства документирования;

• средства тестирования;

• средства управления проектом;

• средства реинжиниринга.

3. Каскадная модель (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки.

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

Рис. 2. Каскадная схема разработки ПО

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

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

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

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

Рис. 3. Реальный процесс разработки ПО по каскадной схеме

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

4. Эволюционная модель разработки

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

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

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

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

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

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

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

5. Итерационные модели разработки ПО

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

1. Модель пошаговой разработки, где процессы специфицирования требований, проектирования и написания кода разбиваются на последовательность небольших шагов, которые ведут к созданию ПО.

2. Спиральная модель разработки в которой весь процесс создания ПО, от начального эскиза системы до ее конечной реализации, разворачивается по спирали.

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

Модель пошаговой разработки

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

Модель пошаговой разработки находится где-то между этими моделями и объединяет их достоинства. Эта модель была предложена Миллсом (Mills) как попытка уменьшить количество повторно выполняемых работ в процессе создания ПО и увели­чить для заказчика временной период окончательного принятия решения обо всех дета­лях системных требований.

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

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