Введение к курсу программная инженерия

Введение к курсу программная инженерия

«Основы программной инженерии»

  SWEBOK (Software Engineering Body of Knowledge) — документ, подготовленный комитетом Software Engineering Coordinating Committee (Координационный комитет по инжинирингу программного обеспечения),а так жесообществом IEEE Computer Society (Сообщество по разработке стандартов IEEE).

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

История IEEE Computer Society начинается с 1946 г., когда был образован подкомитет по широкомасштабному компьютингу Американского института инженеров-электриков (American Institute Electrical Engineers - AIEE).

Через пять лет в Институте радио - инженеров (Institute of Radio Engineers - IRE) была образована профессиональная группа по электронным компьютерам (Professional Group on Electronic Computers - PGEC). Руководителями обоих групп стали их ведущие участники-добровольцы.

В 1963 г. AIEE и ARE объединились в Институт инженеров-электриков и электронщиков (Institute of Electrical and Electronics Engineers - IEEE). Соответственно на базе подкомитета и группы было создано новое сообщество, получившее название IEEE Computer Society.

В 1993 году IEEE Computer Society активизировал свои усилия по формализации дисциплины программной инженерии.        Был создан совместный комитет Software Engineering Coordinating Committee (SWECC).

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

 

В рамках SWECC были организованы три рабочие группы по разработке, соответственно:

- свода необходимых знаний и рекомендуемых практических навыков для специалистов в программной инженерии;

-  кода этики и профессиональных стандартов;

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

 

SWEBOK является результатом работы по первому из этих трех направлений.        

Этот документ был представлен в 2004 году, разработан на базе стандартов IEEE. Он был воспринят IT – сообществом и его положения, по сей день, считаются по сути стандартом.

Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения (разработке программного обеспечения).

Документ призван обеспечить следующее:

· определить необходимый набор знаний и рекомендуемые практики;

· определить этические и профессиональные стандарты;

· определить учебную программу для студентов, аспирантов и продолжающих обучение.

 

  На рис. 1.1 представлена структура программного инжиниринга по SWEBOK.

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

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

   В наших лекциях мы последовательно рассмотрим эти области знаний и начнем с области «Программные требования» в первой лекции.   

 

Рис. 1.1. Структура программного инжиниринга по SWEBOK

 

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

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

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

· 16,2% (всего лишь) завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

· 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

· 31,1% проектов были аннулированы до завершения.

 

 

Основные причины неудач:

1. Нечеткая и неполная формулировка требований к ПО.

2. Недостаточное вовлечение пользователей в работу над проектом.

3. Отсутствие необходимых ресурсов.

4. Неудовлетворительное планирование и отсутствие грамотного управления проектом.

5. Частое изменение требований и спецификаций.

6. Новизна и несовершенство используемой технологии.

7. Недостаточная поддержка со стороны высшего руководства.

8. Недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.

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

Далее, мы будим часто пользоваться терминами «инженерия» и «инжиниринг». Поэтому сразу поясним, что означают эти термины.

Инженерия

В настоящее время, в мире, в основном, признано следующее определение, сформулированное «Американским Советом инженеров по профессиональному развитию» (American Engineers ' Council for Professional Development (ECPD)):

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

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

Инжиниринг

Происходит от английского слова «engineering», что означает «сооружать, проектировать, устраивать, затевать, придумывать, изобретать».

 

Определение

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

  Как видно из определения, инжиниринговая деятельность включает предоставление комплекса услуг производственного, коммерческого и научно-технического характера.

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

 

Итак, начнем с программных требований

 

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

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

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

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

 

 

   

  Классический пример (рис. 1.2) высокоуровневого структурирования групп требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса.

  На рисунке две вертикальные колонки – «функциональные требования» и «нефункциональные» требования».

В левой колонке на основе бизнес – требований вырабатывается концепция, которая определяет пользовательские требования.     

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

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

Нефункциональные требования так же имеют большое значение.

Бизнес правила, по сути «правила игры» в данной бизнес – среде. Они обусловливают атрибуты качества и влияют на спецификацию вариантов использования, функциональные требования и спецификацию требований.

Естественно на спецификацию требований влияют предполагаемые интерфейсы и прочие ограничения.

 

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

Структура обсуждаемой области знаний совместима со стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК  12207 (структура стандартов будет рассмотрена позднее).

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

 

Требования с количественной оценкой (Quantifiable Requirements).

  Это требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность «столько-то запросов в секунду».

  В то же время, важно понимать, что постановка вопроса (то есть формулирование требования) в форме «система должна обеспечить рост пропускной способности» без указания конкретных количественных характеристик является некорректно определенным требованием.

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

  Возможно, так же, недопонимание у специалистов, работающих с различными платформами.

  Например, в устах системного администратора специализированного программного обеспечения, привыкшего работать в командной оболочке Unix/Linux, объясняющего свои потребности аналитику, фиксирующему запросы пользователя и привыкшего оперировать Microsoft Office.

  Может ли такое требование быть переформулировано или детализировано для адекватности интерпретации?

Ответ - да.

Например, так – средний показатель ошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователей должны дать положительную оценку прототипу пользовательского интерфейса на этапе опытной эксплуатации.

Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с численными величинами – как часто? насколько быстро? в каком количестве? и т.п.

Большинство требований с количественной оценкой относится к атрибутам качества. В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту:

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

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

1.6 Системные требования и программные требования (System Requirements and Software Requirements).

  Данное разделение базируется на определении «системы», данном INCOSE (International Council on Systems Engineering) «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы».

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

 

2. Процесс работы с требованиями (Requirements Process)

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

Цель данного раздела, в соответствии с SWEBOK, дать понимание того, что такое процесс работы с требованиями, как таковой. В русском языке, также используется название -   «процесс определения требований».

 

2.1 Модель процесса определения требований.

Основные свойства процесса следующие:

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

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

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

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

- Требует адаптации к проектному и организационному контекстам, в рамках которых ведется соответствующий программный проект.

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

  2.2 Участники процессов (Process Actors).

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

  Типичные примеры ролей:

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

 Заказчики (Customers) - те, кто отвечают за заказ программного обеспечения или, в общем случае, являются целевой аудиторией на рынке программного обеспечения (образуют целевой рынок ПО).

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

 Аналитики (Market analysts). Продукты массового рынка программного обеспечения ориентированы на широкий круг неперсонифицированных, не всегда высококвалифицированных лиц. Они не являются «заказчиками» в смысле «те, кто заказывает разработку».

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

 Регуляторы. Многие области применения («домены») являются регулируемыми, например, телекоммуникации или банковский сектор. Программное обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) требует соответствия руководящим документам и прохождения процедур, определяемых уполномоченными органами – регуляторами. 

 Инженеры – программисты.

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

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

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

Введение к курсу программная инженерия

«Основы программной инженерии»

  SWEBOK (Software Engineering Body of Knowledge) — документ, подготовленный комитетом Software Engineering Coordinating Committee (Координационный комитет по инжинирингу программного обеспечения),а так жесообществом IEEE Computer Society (Сообщество по разработке стандартов IEEE).

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

История IEEE Computer Society начинается с 1946 г., когда был образован подкомитет по широкомасштабному компьютингу Американского института инженеров-электриков (American Institute Electrical Engineers - AIEE).

Через пять лет в Институте радио - инженеров (Institute of Radio Engineers - IRE) была образована профессиональная группа по электронным компьютерам (Professional Group on Electronic Computers - PGEC). Руководителями обоих групп стали их ведущие участники-добровольцы.

В 1963 г. AIEE и ARE объединились в Институт инженеров-электриков и электронщиков (Institute of Electrical and Electronics Engineers - IEEE). Соответственно на базе подкомитета и группы было создано новое сообщество, получившее название IEEE Computer Society.

В 1993 году IEEE Computer Society активизировал свои усилия по формализации дисциплины программной инженерии.        Был создан совместный комитет Software Engineering Coordinating Committee (SWECC).

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

 

В рамках SWECC были организованы три рабочие группы по разработке, соответственно:

- свода необходимых знаний и рекомендуемых практических навыков для специалистов в программной инженерии;

-  кода этики и профессиональных стандартов;

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

 

SWEBOK является результатом работы по первому из этих трех направлений.        

Этот документ был представлен в 2004 году, разработан на базе стандартов IEEE. Он был воспринят IT – сообществом и его положения, по сей день, считаются по сути стандартом.

Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения (разработке программного обеспечения).

Документ призван обеспечить следующее:

· определить необходимый набор знаний и рекомендуемые практики;

· определить этические и профессиональные стандарты;

· определить учебную программу для студентов, аспирантов и продолжающих обучение.

 

  На рис. 1.1 представлена структура программного инжиниринга по SWEBOK.

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

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

   В наших лекциях мы последовательно рассмотрим эти области знаний и начнем с области «Программные требования» в первой лекции.   

 

Рис. 1.1. Структура программного инжиниринга по SWEBOK

 

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

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

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

· 16,2% (всего лишь) завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;

· 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

· 31,1% проектов были аннулированы до завершения.

 

 

Основные причины неудач:

1. Нечеткая и неполная формулировка требований к ПО.

2. Недостаточное вовлечение пользователей в работу над проектом.

3. Отсутствие необходимых ресурсов.

4. Неудовлетворительное планирование и отсутствие грамотного управления проектом.

5. Частое изменение требований и спецификаций.

6. Новизна и несовершенство используемой технологии.

7. Недостаточная поддержка со стороны высшего руководства.

8. Недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.

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

Далее, мы будим часто пользоваться терминами «инженерия» и «инжиниринг». Поэтому сразу поясним, что означают эти термины.

Инженерия

В настоящее время, в мире, в основном, признано следующее определение, сформулированное «Американским Советом инженеров по профессиональному развитию» (American Engineers ' Council for Professional Development (ECPD)):

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

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

Инжиниринг

Происходит от английского слова «engineering», что означает «сооружать, проектировать, устраивать, затевать, придумывать, изобретать».

 

Определение

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

  Как видно из определения, инжиниринговая деятельность включает предоставление комплекса услуг производственного, коммерческого и научно-технического характера.

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

 

Итак, начнем с программных требований

 

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

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

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

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

 

 

   

  Классический пример (рис. 1.2) высокоуровневого структурирования групп требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса.

  На рисунке две вертикальные колонки – «функциональные требования» и «нефункциональные» требования».

В левой колонке на основе бизнес – требований вырабатывается концепция, которая определяет пользовательские требования.     

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

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

Нефункциональные требования так же имеют большое значение.

Бизнес правила, по сути «правила игры» в данной бизнес – среде. Они обусловливают атрибуты качества и влияют на спецификацию вариантов использования, функциональные требования и спецификацию требований.

Естественно на спецификацию требований влияют предполагаемые интерфейсы и прочие ограничения.

 

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

Структура обсуждаемой области знаний совместима со стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК  12207 (структура стандартов будет рассмотрена позднее).

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