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

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

• Наследование ранее созданного ПО (legacy systems). Существует достаточно много систем, созданных много лет назад, морально устаревших, но продолжающих работать. Проблема наследования таких систем состоит в их сопровождении – поддержке и развитии.

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

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

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

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

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

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

• Компетентность – программный специалист не должен завышать свой истинный уровень компетентности и не должен сознательно браться за работу, которая этому уровню не соответствует.

• Защита интеллектуальной собственности – специалист должен соблюдать законодательство и принципы защиты интеллектуальной собственности при использовании чужой интеллектуальной собственности. Кроме того, он должен защищать интеллектуальную собственность работодателя и клиента. Внимание: создаваемая им интеллектуальная собственность является собственностью работодателя или клиента.

• Злоупотребление компьютером – программный специалист не должны злоупотреблять компьютерными ресурсами работодателя или заказчика; под злоупотреблениями мы здесь понимаем широкий спектр — от игр в компьютерные игрушки на рабочем месте до распространения вирусов и т.п.

3. Жизненный цикл программного продукта. Процесс, действие, задача жизненного цикла. Фазы (этапы) жизненного цикла и их связь с процессами. Основные процессы жизненного цикла ПО (ISO12207 и ISO 15504).

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

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

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

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

• Разработка проекта программы (результат – описание того, как программа будет работать)

• Кодирование (результат – исходный код и файлы конфигурации)

• Тестирование программы (результат - контроль соответствия программы требованиям)

• Документирование (результат – документация к программе)

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

Процесс должен быть установлен. Полное установление процесса предполагает:

• Описание процесса – детальное описание действий и операций процесса

• Обучение процессу – проведение занятий с персоналом по освоению процесса

• Введение метрик – установление количественных показателей хода выполнения

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

• Усовершенствование – изменение процесса при меняющихся условиях применения

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

Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения.

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

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

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

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

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

4. Формальная модель основана на формальном описании требований с последующим преобразованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям.

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

Ко второму типу моделей – моделей организации работ относятся:

1. Модель потока работ (workflow model) — показывает последовательность действий, выполняемых людьми на различных этапах разработки ПО. Для каждого действия указываются входы, выходы (результаты) и связи по входам и выходам.

2. Модель потоков данных (data flow model) — представляет процесс в виде последовательного преобразования данных. Каждое преобразование может выполняться одним или несколькими действиями.

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

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

Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны:

1. Метод структурного анализа и проектирования Том ДеМарко (1978),

2. Метод сущность-связь проектирования информационных систем Чен (1976)

3. Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991).

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

Методы должны включать в себя следующие компоненты:

1. Описание моделей системы и нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные модели и т.д.).

2. Правила и ограничения, которые надо выполнять при разработке моделей (например, каждай объект должен иметь одинаковое имя).

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

4. Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом).

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

В соответствии со стандартом ISO 12207 процессы ЖЦ делятся на три группы:

1. Основные

2. Вспомогательные

3. Организационные

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

К числу основных относятся процессы:

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

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

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

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

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

Вспомогательными процессами являются:

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

2. Управления конфигурацией. Определяет работы по управлению конфигурацией.

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

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

5. Аттестации. Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта.

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

7. Аудита. Определяет работы по определению соответствия требованиям, планам и договору. Данный процесс может использоваться двумя сторонами, когда одна из сторон (проверяющая) контролирует программные продукты или работы другой стороны (проверяемой).

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

Организационные процессы жизненного цикла:

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

2. Создания инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.

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

4. Обучения. Определяет работы по соответствующему обучению персонала.