187 подписчиков

Управление разработкой программного обеспечения

6 июня 20196 июн 2019

849

48 мин

Оглавление

История разработки программного обеспечения
Software Engineering
Внутренняя разработка и аутсорсинг

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

Практически ни одна организация не может обойтись без разработки или доработки программного обеспечения под свои потребности.

Разработка программного обеспечения (software development) — это род деятельности и процесс, направленный на создание и поддержание работоспособности, качества и надёжности ПО (Википедия).

Программирование — деятельность по написанию программ — инструкций для компьютеров, в соответствии с которыми они выполняют определённые действия (Википедия).

Трудно сказать, когда возникло программирование. На это могут претендовать три даты.

Создание первого программируемого устройства, Жаккардового ткацкого станка, который был построен ещё в 1804 году Жозефом Мари Жаккаром для программирования узоров на тканях при помощи прообраза перфокарт.
Создание проекта аналитической машины, первого программируемого вычислительного устройства, придуманного, но так и не построенного, Чарльзом Беббиджем в сентябре 1834 г.
Написание 19 июля 1843 года дочкой поэта Джорджа Байрона графиней Адой Августой Лавлейс для этой аналитической машины первой программы для решения уравнения Бернулли.

Интересно, что графиня Ада Лавлейс сделала для программирования ещё много хорошего. Например, она впервые высказала принцип экономии ячеек памяти, использовала цикл, ввела понятия подпрограммы, библиотеки подпрограмм, индексного регистра. В знак признания её заслуг перед программированием в 80-х годах 20 века появился язык программирования Ада, названный в её честь. Ада Лавлейс прекрасно определила смысл программирования:

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

Ада Лавлейс, 1843

Первый работающий программируемый компьютер был построен Джорджем Шотцем из Стокгольма и показан на Всемирной выставке в Париже в 1855 году. Это была машина, сделанная по принципу Бэббиджа, но намного более простая. Она выполняла арифметические действия четвертой степени и печатала результат с точностью до восьмого знака после запятой. Первым электронным компьютером принято считать «Колосс 1», созданный в военном ведомстве Великобритания во время Второй Мировой войны. Он начал работать в декабре 1943 года и был предназначен для дешифрования перехваченных сообщений противника. Этот компьютер позволил английской разведке расшифровать считавшийся супернадёжным немецкий код «Энигма». Так как «Колосс 1» был сверхсекретным проектом, первым электронным компьютером часто называют ЭНИАК — Electronic Numerical Integrator And Computer, созданный для Департамента артиллерии армии США в феврале 1946 года. Первые программы для компьютера писались в машинных кодах и представляли собой последовательность нулей и единиц. Конечно, такое программирование было весьма непростым делом, но зато позволяло максимально приблизиться к тому, как «думает» машина. Эти программы вводились в компьютеры через перфокарты (карточки из тонкого картона) или перфоленты (бумажные ленты), на которых информация в двоичной форме соответствовала наличию или отсутствию отверстий в позициях, и обрабатывались процессором.

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

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

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

Примеры языков высокого уровня всем хорошо известны. Это Алгол, Фортран, С, C++, C#, Java, Паскаль, Delphi, Python и многие другие.

Выполнение программ, написанных на языках высокого уровня, может осуществляться принципиально двумя способами. Либо программа обрабатывается сначала компилятором (транслятором), а потом компоновщиком, либо используется интерпретатор.

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

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

Компоновщик собирает несколько программ, обработанных транслятором, библиотеки для конкретного типа процессора, и генерирует машинный код, который может быть исполнен компьютером. Компоновщик также выявляет ошибки, но другого рода: неопределённые функции, несоответствия в скомпонованных программах. На вход компоновщика поступает объектный код, а на выходе получается исполняемый модуль (программа).

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

Существуют различные «промежуточные» варианты, например, когда интерпретатор перед исполнением программы транслирует её на другой язык, более удобный для интерпретации (например, таковы языки PYTHON и Perl).

История языков высокого уровня началась в конце 40-х годов, когда Джон Моучли, один из создателей ЭНИАКа, разработал первый примитивный интерпретатор под названием «Short Code». В 1951 г. ученица Моучли Грейс Хоппер создала первый компилятор и придумала сам термин. В 1954 году группа под руководством Грейс Хоппер разработала язык программирования и его компилятор, которые назвали MathMatic. В ходе его усовершенствования в 1958 г. появился язык FlowMatic, который считают первым языком для обработки коммерческих данных. На его основе как язык для бизнеса в 1960 году появился Кобол (COBOL — Common Business Oriented Language), который достаточно широко используется и по сей день, особенно в США. В 1954 г. появился Фортран (FORTRAN, от FORmula TRANslator — переводчик формул), разработанный группой программистов IBM и направленный на осуществление сложных математических расчётов, который также используется по сей день.

В 1964 г. был создан специализированный язык программирования, состоящий из простых слов английского языка. Его назвали «универсальным символическим кодом для начинающих» (Beginner All Purpose Symbolic Instruction Code, или, сокращённо, BASIC). Широкому распространению БЭЙСИКа способствовало то, что в конце 70х годов его начали использовать как встроенный язык персональных компьютеров.

Однако большие программы на Фортране читать и понимать достаточно сложно. А на БЕЙСИКе их написать практически невозможно. Поэтому в 1958 г. появился Алгол (ALGOrithmic Language), название которого подчёркивает, что он предназначен для записи алгоритмов. Алгол считается первым языком структурного программирования. К ним также относятся Паскаль (1970) и Си (1972).

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

В начале 1980 годов появилось объектно-ориентированное программирование (ООП), основанное на понятиях объекта и класса.

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

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

Примерами объектно-ориентированных языков могу служить Object Pascal, C++, Java, PYTHON. ООП организует программы, разбивая их на составные части, и позволяет работать над ними группам разработчиков.В заключение краткого экскурса в историю программирования необходимо сказать про интегрированные средства разработки.

Интегрированная среда разработки (англ. IDE, Integrated development) — система программных средств, используемая для разработки программного обеспечения.

Такие среды обычно включают в себя:

текстовый редактор;
компилятор и/или интерпретатор;
средства автоматизации компоновки;
отладчик;
систему управления версиями;
средства создания графического интерфейса пользователя;
графические средства построения классов.

Именно среды разработки являются наиболее популярным средством разработки программ в настоящее время. Наиболее известные среди них: Eclipse, Microsoft Visual Studio, в которых можно вести разработку на различных языках программирования, и Visual Basic, Delphi (Pascal), IDLE (PYTHON), предназначенные для одного языка.

Software Engineering

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

Согласно наиболее распространённой точке зрения, чтобы своевременно производить и использовать качественное ПО, необходимо применять современные принципы, методы и стандарты жизненного цикла ПО, которые объединены в область знания Software Engineering.

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

Программная инженерия подходит к разработке ПО именно как к инженерной деятельности, она достаточно хорошо изучена и стандартизирована. Ниже приведены и кратко описаны основные стандарты и методологии этой дисциплины. Сначала введём несколько терминов (ГОСТ Р ИСО/МЭК 12207-2010):

Жизненный цикл (Life Cycle) — это эволюция системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения.

Модель жизненного цикла (Life Cycle Model) — это рамочная модель процессов и действий (или работ), связанных с жизненным циклом и организованных в стадии, которая также служит в качестве общей основы для коммуникаций и взаимопонимания сторон.

Методология (метод) — это конкретное описание работ в рамках определённой модели жизненного цикла.

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

Внутренняя разработка и аутсорсинг

Для выполнения разработки или доработки ПО у организации есть два способа:

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

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

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

Основные стандарты и методологии разработки ПО

Software Engineering Book of Knowledge

Software Engineering Book of Knowledge (SWEBoK) — это свод знаний по программной инженерии, подготовленный в 2004 году IEEE Computer Society и принятый как стандарт ISO/IEC 9579:2004.

SWEBOK является основополагающим документом, отражает мнение многих зарубежных и отечественных специалистов в области программной инженерии и согласуется с процессами жизненного цикла ПО стандарта ISO/IEC 12207. SWEBOK описывает 10 областей знаний:

1. Программные требования (Software requirements) — извлечение (сбор), анализ, специфицирование и утверждение требований.

2. Проектирование ПО (Software design) — определение архитектуры, компонентов, интерфейсов и других характеристик системы или её компонентов. Результат процесса проектирования — дизайн системы.

3. Конструирование ПО (Software construction) — создание рабочей системы с привлечением методов верификации (тестирования), тестирования модулей (unit testing), интеграционного тестирования и отладки.

4. Тестирование ПО (Software testing) — деятельность, выполняемая для оценки и улучшения качества ПО, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.

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

6. Управление конфигурацией ПО (Software conguration management) — идентификация конфигурации системы, с целью контроля её изменений конфигурации, а также поддержки и сопровождения целостной конфигурации на протяжении всего жизненного цикла системы.

7. Управление инженерией ПО (Software engineering management) — управление (планирование, координация, количественная оценка, мониторинг, контроль и отчётность) для систематического, упорядоченного и количественно измеряемого обеспечения разработки и сопровождения программных систем.

8. Процесс программной инженерии (Software engineering process) — область знаний, существующая на двух уровнях:

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

9. Инструменты и методы программной инженерии (Software engineering tools and methods) — инструменты, предназначенные для обеспечения поддержки процессов жизненного цикла ПО, а также методы, обеспечивающие проектирование, реализацию и выполнение ПО на процессах, а также достижение качества процессов и продуктов.

10. Качество ПО (Software quality) — область знаний, связанная с характеристиками ПО и его способностью удовлетворить установленным или предполагаемым потребностям заказчика.Кроме того, SWEBoK включает обзор смежных дисциплин, связь с которыми важна для программной инженерии:

компьютерная инженерия (Computer engineering);
применение вычислительной техники (Computer science);
управление (Management);
математика (Mathematics);
управление проектами (Project management);
управление качеством (Quality management);
системная инженерия (Systems engineering).

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

Project Management Book of Knowledge

Project Management Book of Knowledge (PMBoK) — стандарт управления проектами, который может быть адаптирован для проектов разработки ПО (подробнее см. главу «Управление ИТ-проектами»).

PRINCE2 (PRojects IN Controlled Environments 2)

PRojects IN Controlled Environments 2 (PRINCE2) — это один из наиболее известных и популярных стандартов ведения ИТ проектов. Он был разработан в 1989 году Central Computer and Telecommunications Agency (CCTA) Великобритании как стандарт для руководства проектами в области информационных технологий. В настоящее время он широко используется и в других областях и является «de facto» стандартом для руководства проектами в Великобритании. Стандарт описывает принципы организации программы проектов и проектов в рамках программы.

В нем выделены 7 принципов управления проектами:

Постоянная оценка соответствия проекта потребностям бизнеса.
Учёт уроков проекта, «самообучение» проекта.
Выделение определённых ролей с ответственностью и правами.
Управление по фазам. Текущая фаза завершается планированием следующей.
Управление по отклонениям. Каждая роль имеет полномочия на утверждение конкретных отклонений.
Ориентация на результат. Главное — именно результат, а не процессы его достижения (в отличие, например, от PMBoK).
Адаптация стандарта под конкретную организацию и внешнюю среду.

Стандарт разбивает проект на 8 стадий (Рис. 1):

Начало проекта (Starting Up a Project) определение того, надо ли выполнять проект и выбор подхода к его реализации.
Инициация проекта (Initiating a Project) — создание бизнес-кейса проекта, формирование оргструктуры, плана и бюджета проекта.
Планирование (Planning) детальное планирование и перепланирование проекта, выполняется в течение всего проекта.
Руководство проектом (Directing a Project) — принятие Комитетом проекта решений по контрольным точкам и ситуационное управление по значительным проблемам и отклонениям. Выполняется в течение всего проекта.
Систематический контроль стадий (Controlling a Stage) — непосредственная работа менеджера проекта по ежедневному управлению проектом (выдача и приёмка заданий, фиксация сложностей и рисков, принятие решения об эскалации и отчётность).
Управление поставкой продукта (Managing Product Delivery) — действия по созданию нужных для проекта продуктов, выполняемые менеджером проекта.
Управление границами стадий (Managing Stage Boundaries) — анализ исполнения плана стадии, промежуточное планирование следующей стадии, обзор рисков и предоставление информации Комитету проекта.
Завершение проекта (Closing a Project) — действия по закрытию проекта.

Стадии в стандарте не являются последовательными, зависимости между ними более сложные. Каждая стадия детализирована по активностям (всего их 45), входящим и исходящим артефактам, критериям, позволяющим начать активность.

Кроме того, стандарт выделяет 7 артефактов (документов и тем), на которых надо фокусироваться при выполнении проекта:

Соответствие потребностям бизнеса (бизнес-кейс).
Оргструктура проекта.
Обеспечение качества (по трем направлениям: финансовое состояние проекта, выполнение требований пользователей, технологическое качество результата — продукта проекта).
Планирование.
Управление рисками.
Управление изменениями.
Отчётность (в частности, план/факт).

Большим преимуществом стандарта является его глубокая проработанность и универсальность. В целом PRINCE2 является методологией, готовой к использованию для выполнения ИТ-проектов и проектов по разработке ПО. Главным недостатком PRINCE2 является высокая сложность применения. Распространение его в России сдерживает также отсутствие официального перевода на русский язык.

Стандарты жизненного цикла программных систем

Как и SWEBoK, основу для организации процесса разработки ПО составляют стандарты ИСО/МЭК жизненного цикла систем и программных систем: ISO/ IEC 14764:2006, ISO/IEC 15288:2008 и ISO/IEC 12207 2008. В России приняты как ГОСТ Р их аналоги:

ГОСТ Р ИСО/МЭК 14764 2002 «Сопровождение программных средств» (развитие стандарта 12207 на один из этапов ЖЦ);
ГОСТ Р ИСО/МЭК 15288 2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем»;
ГОСТ Р ИСО/МЭК 12207 2010 «Системная и программная инженерия. Процессы жизненного цикла программных средств»

Стандарты ISO/IEC 12207:2008 и его российский эквивалент ГОСТ Р ИСО/МЭК 12207 2010 специально предназначены для разработки ПО и определяют процессы жизненного цикла ПО, начиная с формирования требований к будущей системе и заканчивая выводом ПО из эксплуатации. В них ПО рассматривается в двух вариантах (Рис. 2):

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

Рис. 2. Процессы жизненного цикла ПО по стандарту ГОСТ Р ИСО/МЭК 12207 2010.

Процессы жизненного цикла ПО как системы состоят из 4 групп, включающих 25 процессов. Процессы жизненного цикла ПО как части системы состоят из трёх групп, включающих 18 процессов.

Стандарты ISO/IEC 12207:2008 и ISO/IEC 15288:2008 лежат в основе практически всех современных промышленных технологий создания и эксплуатации ПО. Отметим, что эти стандарты определяют только рамочную структуру процессов и работ, общее понимание их содержания и терминологию, но не определяют конкретный набор и последовательность стадий жизненного цикла ПО и входящих в них процессов (это определяет модель жизненного цикла). Их положения являются общими для любых моделей жизненного цикла, методов и технологий создания ПО. Стандарты ISO/IEC 12207:2008 и ISO/IEC 15288:2008 и соответствующие им ГОСТ-Р допускают, что в проектах не нужно будет применять все определённые в них процессы. Выбор ряда процессов, подходящих для организации или проекта, называется процессом адаптации стандарта. Для определения документов и их структуры, сопровождающих жизненный цикл систем и программных систем существует стандарт ISO/IEC 15289:2006, переведённый на русский язык в 2011 году.

Серия стандартов ГОСТ 34

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

Формирование требований к АС;
Разработка концепции АС;
Техническое задание;
Эскизный проект (допускается исключать);
Технический проект;
Рабочая документация;
Ввод в действие;
Сопровождение АС.

В свою очередь в соответствии с ГОСТ 34.602.89 техническое задание состоит из следующих частей:

1. Общие сведения.

2. Назначение и цели создания системы.

3. Характеристика объекта автоматизации.

4. Требования к системе.

4.1. Требования к системе в целом.

4.1.1. Требования к структуре и функционированию системы.

4.1.2. Требования к численности и квалификации персонала системы и режиму его работы.

4.1.3. Показатели назначения.

4.1.4. Требования к надёжности.

4.1.5. Требования к безопасности.

4.1.6. Требования к эргономике и технической эстетике.

4.1.7. Требования к транспортабельности для подвижных АС.

4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.

4.1.9. Требования к защите информации от несанкционированного доступа.

4.1.10. Требования по сохранности информации при авариях.

4.1.11. Требования к защите от влияния внешних воздействий.

4.1.12. Требования к патентной чистоте.

4.1.13. Требования по стандартизации и унификации.

4.1.14. Дополнительные требования.

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приёмки системы.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.

8. Требования к документированию.

9. Источники разработки.

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

Модель зрелости разработки

Существует модель оценки зрелости процессов разработки ПО: Capability Maturity Model (CMM) - модель зрелости создания ПО, позже развитая в Capability Maturity Model Integration (CMMI), интегрированная модель зрелости создания ПО.

Модель СММ была создана в 1991 году Институтом программной инженерии Университета Карнеги Меллона (Software Engineering Institute, SEI) для разработки программных продуктов. С течением времени было выпущено целое семейство моделей: SWCMM — для программных продуктов, SECMM — для системной инженерии, Acquisition CMM — для закупок, People CMM — для управления людскими ресурсами, ICMM —для интеграции продуктов.

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

CMMI для разработки (for Development) CMMI-DEV;
CMMI для сервисов (for Services) CMMI-SVC;
CMMI для поставок (for Acquisition) CMMI-ACQ.

Наиболее известной является модель CMMI for Development, ориентированная на организации, занимающиеся разработкой ПО, аппаратного обеспечения, а также комплексных систем. Модель CMM/CMMI выделяет пять уровней зрелости компании-разработчика ПО, каждый из которых является этапом в совершенствовании процессов разработки ПО. Описание уровней приведено в Табл. 2.

Использование модели CMMI позволяет организации оценить эффективность процессов, установить приоритетные направления и способы их усовершенствования, а также внедрить данные усовершенствования. CMMI также определяет 22 процессные области, ряд целей, которые должны быть достигнуты при использовании CMMI в данной области и набор рекомендаций в виде практик. Сертификацию на соответствие определённому уровню CMM/CMMI производят специализированные компании. Отметим, что в России есть несколько компаний-разработчиков, сертифицированных по пятому уровню CMMI.

Модели и методы проектов разработки ПО

Напомним, что лишь стандарты PRINCE2 и ГОСТ 34 определяют конкретный набор стадий (этапов) жизненного цикла проекта по разработке ПО. Стандарт ISO/IEC 12207:2008 и его российский эквивалент ГОСТ Р ИСО/МЭК 12207 2010, а также SWEBoK предполагают, что набор стадий должна определять модель жизненного цикла. Модели жизненного цикла разработки ПО широко применяются уже достаточно давно. Помимо моделей жизненного цикла конкретное описание работ определяется методологией или методом разработки. Все модели и методы разработки ПО можно разделить на три группы:

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

программирование и исправление ошибок (Code-and-Fix);
каскадную модель (модель водопада).

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

модель Rational Unified Process (RUP);
спиральную модель.

3. Гибкие методологии разработки (agile programming), из которых наиболее известны в России:

Scrum;
Extreme Programming (XP).

В Табл. 3 дано сравнение классических и гибких методов разработки ПО.

Табл. 3. Сравнение классических (последовательных и итеративных) и гибких методов разработки ПО.

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

Программирование и исправление ошибок (Code-and-Fix)

Это простейшая, наиболее древняя модель, неформальная и неструктурированная. Состоит из последовательно выполняемых шагов:

Преимущества, недостатки и возможное применение показаны в Табл. 4.

Табл. 4. Преимущества, недостатки и возможные применения модели Code-and-Fix.

Классические последовательные модели разработки ПО

Каскадная модель (модель водопада)

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

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

Разработка пользовательской документации;
Сборка, интеграция, внедрение;
Настройка;
Обучение пользователей.

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

Табл. 5. Преимущества, недостатки и возможные применения каскадной модели.

Существуют вариации каскадной модели. То, что не всегда удаётся детально проработать проект будущей системы, выяснилось достаточно давно. И для учёта возможности исправлений сделанной на предыдущем этапе работы были предложены вариации каскадной модели, предполагающие возможность возврата к предыдущему этапу (эта модель получила название «возвратной»). Однако при этом резко (многократно) возрастает стоимость переделок.

Итеративные модели разработки

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

Модель жизненного цикла Rational Unied Process

Rational Unified Process (RUP) — это методология гибкой разработки ПО, созданная компанией Rational Software (с 2003 г. – подразделение IBM) и поддерживаемая комплексом инструментов Rational Suite. RUP предлагает двигаться итеративно, создавая за одну итерацию (длящуюся от 2 до 6 недель) значимый для заказчика результат (но не обязательно — готовую часть продукта). Весь цикл разработки состоит из четырёх фаз (Рис. 4):

Начало, инициация (inception);
Уточнение требований, детальная проработка (elaboration);
Разработка, создание ПО (construction);
Внедрение, ввод в эксплуатацию (transition).

Рис. 4. Цикл разработки в соответствии с методологией RUP.

Переход с фазы на фазу возможен только после выполнения задач предыдущей фазы и представляет собой контрольную точку проекта. Внутри каждой фазы могут быть несколько итераций, которые увеличивают вероятность достижения задач фазы (на Рис. 3.4.4 они показаны по оси X или оси времени). Кроме того, RUP определяет набор активностей или процессов (в RUP они называются «дисциплины»), которые повторяются в разном объёме на разных фазах и итерациях (на Рис. 4 они показаны по оси Y).

Основные активности (процессы):

Моделирование бизнес-процессов;
Управление требованиями;
Анализ и проектирование;
Реализация;
Тестирование;
Развёртывание.

Вспомогательные активности (процессы):

Управление изменениями и конфигурациями;
Управление проектом;
Управление средой разработки.

Примерный объем активностей на каждой фазе и отдельных итерациях показан на Рис. 4 (высота «горбов» по вертикальной оси отражает объем работ).

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

Кроме того, RUP определяет набор принципов разработки:

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

Это неотъемлемое свойство всех методологий итеративной и гибкой разработки. Итеративность позволяет как исправлять дефекты, так и отзываться на изменения внешней среды и потребностей заказчика. Управление изменениями является важной дисциплиной RUP.

Сборка системы из компонентов. Компонентная архитектура позволяет вести параллельную разработку, использовать компоненты повторно, т.е. позволить ускорить создание ПО и повысить его качество. Конечно, для реализации этой возможности необходимо приложить дополнительные усилия.
Визуальное моделирование. Использование графических моделей UML для описания требований и проектирования.
Качество на всех стадиях. Все артефакты на всех стадиях предлагается подвергать тщательной экспертизе. Качество ПО предлагается достигать за счёт метода разработки через тестирование (Test Driven Development, TDD) — сначала пишется тест, затем пишется код ПО так, чтобы тест прошёл.
Создание работающего ПО. Ход проекта оценивается по тому, какая часть ПО работоспособна. Несомненные достоинства методологии RUP принесли ему большую популярность среди российских разработчиков. Преимущества, недостатки и возможное применение модели показаны в Табл. 6.

Табл. 6. Преимущества, недостатки и возможное применение методологии RUP.

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

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

Каждый виток разбит на четыре сектора:

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

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

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

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

Табл. 7. Преимущества, недостатки и возможное применение спиральной модели.

Гибкие методологии (Agile Programming)

Однако сегодня мы сталкиваемся со все большей изменчивостью практически во всех областях деятельности. Кроме того, многолетние попытки вытащить из заказчика требования к будущему ПО слишком часто оказывались и оказываются неудачными. Именно поэтому возник такой широкий интерес к гибким (agile) методам разработки ПО, которые направлены на создание ПО итеративно, максимально подстраиваясь под текущие потребности заказчиков, но при этом создавая работающие и работоспособные варианты. Agile — методы теперь активно используют и в других проектах, в частности, особенно популярны они стали в банковском секторе.

Отцами-основателями гибких методологий были сформулированы основные принципы подхода:

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

Помимо опоры на итеративную модель разработки у гибких методологий разработки ПО есть ещё две общие особенности:

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

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

Методология Scrum

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

Два основных термина Scrum:

Бэклог продукта (Product Backlog) — приоритизированный список требований с оценкой трудозатрат. Обычно он состоит из бизнес-требований, реализация которых приносит конкретную бизнес-ценность.

Спринт — короткий (от 1 до 4 недель) период проведения работ, в конце которого получается законченный функционал.

Основные принципы Scrum:

Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое;
Никто, кроме команды не может вмешиваться в процесс разработки на протяжении спринта;
Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Главные роли в Scrum:

Scrum Master — тот, кто ведёт Scrum-митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего, кроме корректного ведения самого Scrum-проекта, руководитель проекта, скорее, относится к Product Owner и не должен являться Scrum Master );
Владелец продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон;
Кросс-функциональная команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека).

Процесс разработки в Scrum состоит из следующих действий:

1. Владелец продукта информирует о запросах на выполнение работ, которые должны быть выполнены. Определяется список требований к ПО (product backlog).

2. В ходе совета по планированию спринта (sprint planning meeting) команда определяет, сколько из желаемого они могут выполнить на будущем спринте, из списка требований выделяется набор функциональности, которая планируется к разработке. Таким образом, определяется запланированный на спринт список заданий (sprint backlog).

3. Команда выполняет запланированный на спринт список заданий. На протяжении спринта никто не имеет права менять список требований.

4. В конце каждого спринта проводится его обзор для получения обратной связи от владельца продукта, изменения требований и приоритетов. Успех Scrum’a зависит во многом до деятельности Scrum Master-a. В числе его главных задач и особенностей его деятельности:

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

Методология Extreme Programming (EX)

Экстремальное программирование (Extreme Programming, XP) — это один из видов гибкой разработки ПО, набор принципов и приёмов, позволяющих повысить продуктивность работы разработчиков и улучшить качество ПО. При создании методологии экстремального программирования были выделены 12 практик и приёмов, сгруппированных в 4 группы:

1. Короткий цикл обратной связи (Fine scale feedback). Как и в других методологиях гибкой разработки, создание продукта происходит путём быстрых итераций в постоянном общении с пользователями.

Единая команда (Whole team) или заказчик всегда рядом. Разработчики и заказчики представляют собой единую команду, заинтересованную в разработке качественного и полезного ПО, и работают в постоянном тесном контакте друг с другом.
Игровое планирование (Planning game). Основная цель «игры в планирование» — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.
Разработка через тестирование (Test driven development). В ХР тестирование является важнейшим процессом. Методология выделяет 2 типа тестов: Unit testing — тестирование элементов (иногда называют — модульное тестирование) и Acceptance testing (приёмочные испытания). Первые позволяют убедиться в работоспособности ПО, вторые — в том, что ПО соответствует потребностям заказчика (требуемой функциональности). ХР использует подход разработки через тестирование (Test Driven Development, TDD) — сначала пишется тест, затем пишется код ПО так, чтобы тест прошёл.
Парное программирование (Pair programming). Написанием кода занимается пара разработчиков, которые работают за одним рабочим местом. Один из них собственно записывает код, а другой просматривает его работу и подсказывает идеи. Время от времени сотрудники меняются ролями. Участников пар в ХР также рекомендуется периодически «тасовать», так что каждый разработчик оказывается в курсе всего проекта.

2. Непрерывный процесс (Continuous process).

Небольшие (и частые) релизы (Small releases). Общая идея гибких методологий проектирования состоит в создании работающей версии ПО, удовлетворяющей некоторые (основные) потребности заказчика. ХР не исключение. Он предлагает «есть слона по частям», и при этом постепенно «насыщаться».
Непрерывная интеграция (Continuous integration). Очень часто в проектах разработки ПО вопросы интеграции откладывают на конец проекта, что приводит к серьёзным проблемам. ХР предлагает начинать ставить и решать вопросы интеграции с самого начала проекта, постоянно наращивания и совершенствуя интеграционное ПО.
Рефакторинг или модернизация проектного решения (Refactoring or design improvement). Улучшение кода при сохранении функциональности или рефакторинг является существенным компонентом ХР. Код всегда можно улучшить. ХР предлагает заниматься этим на протяжении всего проекта.

3. Общее понимание (Shared understanding).

Простота дизайна (Simple design). Как все технологии гибкой разработки, ХР исходит из того, что требования к ПО постоянно меняются, поэтому грамотно спроектировать систему со всеми подробностями в начале проекта невозможно. Надо двигаться итеративно, соблюдая условие простоты дизайна. Иначе в какой-то момент система окажется неработоспособной.
Метафора системы (архитектура). Метафорой в ХР называют по сути архитектуру программной системы. ХР требует, чтобы метафора системы была актуальна и постоянно находилась в поле внимания разработчиков. Это очень важный принцип XP.
Стандарты кодирования (Coding standards). При групповой разработке ПО все члены команды должны соблюдать стандарты кодирования. Это позволяет гибко формировать пары для разработки, эффективно проводить рефакторинг, в целом повысить производительность и качество разработки.
Коллективная ответственность за код (Collective code ownership). Т.е. члены команды несут коллективную ответственность за результат разработки: его функциональность и качество.

4. Благополучие программиста (Programmer welfare).

Устойчивый шаг (sustainable pace) проекта. На каждой итерации необходимо разрабатывать максимально качественное и работоспособное ПО. Это не полуфабрикат, который невозможно использовать. Кроме того, ХР настойчиво рекомендует придерживаться 40-часовой рабочей недели для разработчиков, мотивируя это требование тем, что переработки ухудшают качество разрабатываемого ПО.

Преимущества, недостатки и возможное применение гибких методологий разработки ПО (Scrum и XP) показаны в Табл. 8.

Табл. 8. Преимущества, недостатки и возможное применение гибких методологий разработки ПО (Scrum и XP).

Характеристики качества программного обеспечения

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

ИСО/МЭК 2500n — Раздел «Менеджмент качества»;
ИСО/МЭК 2501n — Раздел «Модель качества»;
ИСО/МЭК 2502n — Раздел «Измерение качества»;
ИСО/МЭК 2503n — Раздел «Требования к качеству»;
ИСО/МЭК 2504n — Раздел «Оценка качества».

Номера с ИСО/МЭК 25050 по ИСО/МЭК 25099 зарезервированы для расширения международных стандартов SQuaRE и/или технических отчётов, буква «n» означает номер стандарта в разделе.

Характеристики качества ПО согласно SQuaRE делятся на определённые области:

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

Функциональная полнота;
Функциональная корректность;
Функциональная целесообразность.

2. Уровень производительности — производительность относительно суммы использованных при определённых условиях ресурсов:

Временные характеристики;
Использование ресурсов;
Потенциальная возможность.

3. Совместимость — способность продукта, системы или компонента обмениваться информацией с другими продуктами, системами или компонентами, и/или выполнять требуемые функции при совместном использовании одних и тех же аппаратных средств или программной среды:

Сосуществование;
Интероперабельность.

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

Определимость пригодности;
Изучаемость;
Управляемость;
Защищённость от ошибки пользователя;
Эстетика пользовательского интерфейса;
Доступность.

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

Завершённость;
Готовность;
Отказоустойчивость;
Восстанавливаемость.

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

Конфиденциальность;
Целостность;
Неподдельность;
Отслеживаемость;
Подлинность.

7. Сопровождаемость — результативность и эффективность, с которыми продукт или система могут быть модифицированы предполагаемыми специалистами по обслуживанию:

Модульность;
Возможность многократного использования;
Анализируемость;
Модернизируемость;
Тестируемость.

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

Адаптируемость;
Устанавливаемость;
Взаимозаменяемость.

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

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

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

Сбор требований к ПО

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

IDEF — семейство стандартов функционального моделирования сложных программных систем, основанный на методологии SADT (Structured Analysis and Design Technique или методология структурного анализа и проектирования), в 1993 году принятый в качестве федерального стандарта в США, а в 2000 году — в качестве руководящего документа по стандартизации в Российской Федерации. Всего известно 14 методов IDEF, среди которых наиболее популярны IDEF0 - средство описание функциональной модели организации и IDEF3 для описания бизнес-процессов и рабочих процессов.
ARIS – (Architecture of integrated Information Systems), методология моделирования бизнес-процессов организации, была разработана Августом Шеером в 1992 г. Существует также одноименное семейство программных продуктов, которые покрывают многие потребности разработки ПО, в частности вопросы проектирования архитектуры АС.
UML — (Unified Modeling Language, унифицированный язык моделирования) был разработан консорциумом OMG в 1997 г. для графического моделирования объектно-ориентированного ПО, в частности, как средство для последующей автоматической генерации кода.

Методы анализа программного кода

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

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

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

Тестирование обычно принято разбивать на следующие виды:

Регрессионное тестирование — собирательное название для всех видов тестирования ПО, направленных на обнаружение ошибок в уже протестированных участках программного кода;
Дымовое тестирование — минимальный набор тестов на явные ошибки, проводится при внесении незначительных изменений в код;
Системное тестирование выполняется после окончания разработки ПО и направлено на тестирование как отдельных модулей АС, так и взаимосвязей этих модулей;
Интеграционное тестирование направлено на тестирование взаимодействия между подсистемами;
Тестирование сквозного процесса выполняется после успешного завершения системного и интеграционного тестирования и направлено на тестирование всего автоматизируемого процесса;
Интеграционно–функциональное тестирование состоит из 3-х типов тестирования: системное, интеграционное, тестирование сквозного процесса;
Нагрузочное тестирование обычно выполняется после успешного завершения ИФТ и направлено на получение количественных показателей быстродействия АС и обнаружения проблем производительности;
Тестирование документации направлено на выявление несоответствий в технической спецификации и требованиях;
Приёмочное тестирование выполняется после успешного завершения всех этапов тестирования, процесс проверки соответствия АС заданным требованиям, выполняемый рабочей группой на специально оборудованном испытательном стенде.

Контейнерная виртуализация

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

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

OpenShift — разработанное компанией Red Hat семейство программных продуктов для контейнеризации. Флагманский продукт линейки — OpenShift Container Platform, on-premises (от англ. «on-premise», что дословно переводится как «на предприятии»; означает использование собственных ресурсов для размещения ПО) PaaS-решение, разработанное на основе контейнеров Docker, где оркестрация и управление реализованы на базе Kubernetes. В состав линейки также входят продукты для работы в разных средах: OKD с функциями, аналогичными CentOS, платформа OpenShift Online предоставляется как SaaS-сервис, Openshift Dedicated — как управляемый сервис, а OpenShift.io предоставляет доступную онлайн среду для разработки приложений.

Docker — продукт для виртуализации на уровне операционной системы, программное обеспечение для автоматизации развёртывания и управления приложениями. Docker позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups (от англ. «control group») — механизм ядра Linux, который ограничивает и изолирует вычислительные ресурсы — процессорные, сетевые, ресурсы памяти, ресурсы ввода-вывода для групп процессов) в ядре, а также предоставляет среду по управлению контейнерами. Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением Open Container Initiative начался переход от монолитной к модульной архитектуре. Docker разрабатывается и поддерживается одноимённой компанией-стартапом, распространяется в двух редакциях:

• общественной (Community Edition) по лицензии Apache 2.0,

• для организаций (Enterprise Edition) по проприетарной лицензии, написан на языке Go.

Kubernetes — открытое программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Поддерживает основные технологии контейнеризации, включая Docker, rkt, также возможна поддержка технологий аппаратной виртуализации. Оригинальная версия была разработана компанией Google для внутренних нужд, затем система была передана под управление Cloud Native Computing Foundation. Используется рядом крупных организаций и интернет-проектов, в частности, инфраструктура фонда Wikimedia Foundation перенесена с самостоятельно разработанного ПО для организации кластеров на Kubernetes.

Общие тенденции

Все более популярными становятся программные платформы, которые используются в различных функциональных областях: от ERP-систем (Compiere) до создания Help Desk (Remedy). Среди российский программных систем наиболее популярное платформенное решение — это несомненно 1С. Платформенные системы сводят процесс разработки ПО к сборке решения из готовых программных компонентов подходящей функциональности и позволяют существенно сократить, а иногда полностью исключить, объем собственно программирования. Термин программист все чаще заменяется термином разработчик ПО.

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

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

Автор: Марина Аншина

Источник: Учебник 4CIO. Настольная книга ИТ-директора