Всего на сайте:
166 тыс. 848 статей

Главная | Финансы, Менеджмент

Системная инженерия ПО  Просмотрен 56

Тема 9. Системная инженерия ПО.

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

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

 

Про­грамм­ные си­сте­мы ста­но­вят­ся все объемнее и слож­нее. Клас­си­че­ский при­мер представляет MS Word, ко­то­рый 25 лет назад уме­щал­ся на дис­ке­те в 360 Кбайт, а те­перь для него необ­хо­дим ком­пакт-диск ем­ко­стью 600 Мбайт.

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

 

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

 

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

 

При­ме­не­ние прин­ци­пов си­стем­ной ин­же­не­рии к раз­ра­бот­ке про­грамм­ной си­сте­мы вы­яв­ля­ет опе­ра­ции, за­да­чи и про­це­ду­ры, которые можно назвать си­стем­ной ин­же­не­ри­ей про­грамм­но­го обес­пе­че­ния (software system engineering – SwSE).

Мно­гие счи­та­ют SwSE частным слу­ча­ем си­стем­ной ин­же­не­рии. Од­на­ко SwSE содержит и собственный мощ­ный ин­стру­мен­та­рий для управ­ле­ния тех­ни­че­ской раз­ра­бот­кой круп­ных про­грамм­ных проектов. В этой лекции рассмотрим некоторые опре­де­ле­ния и про­цес­сы из стан­дар­тов IEEE на про­грамм­ную ин­же­не­рию, интегрируемые в SwSE. Материал основан на статье Ричарда Тэйера (http://www.osp.ru/os/2002/05/181460/), про­фес­сора про­грамм­ной ин­же­не­рии Ка­ли­фор­ний­ско­го уни­вер­си­те­та в Са­кра­мен­то.

 

2. Си­сте­мы и си­стем­ная инженерия

 

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

 

Стан­дарт IEEE Std. 1220–2005 опи­сы­ва­ет про­цессы си­стем­ной ин­же­не­рии и их при­ме­не­ние на про­тя­же­нии всего цикла жизни из­де­лия. Си­стем­ная ин­же­не­рия по­рож­да­ет до­ку­мен­ты, а не обо­ру­до­ва­ние. До­ку­мен­ты свя­зы­ва­ют про­цес­сы раз­ра­бот­ки с цик­лом жизни про­ек­та. Они опре­де­ля­ют пред­по­ла­га­е­мые окру­же­ния про­цес­сов, ин­тер­фей­сы и ин­стру­мен­ты управ­ле­ния рис­ка­ми в рам­ках всего проекта. Согласно стандарту, си­стем­ная ин­же­не­рия вклю­ча­ет в себя следующие пять функций:

 

· Опре­де­ле­ние проблемы – ука­за­ние по­треб­но­стей и огра­ни­че­ний путем ана­ли­за тре­бо­ва­ний и вза­и­мо­дей­ствия с заказчиком.

· Ана­лиз решений – вы­де­ле­ние на­бо­ра воз­мож­ных спо­со­бов удо­вле­тво­ре­ния по­треб­но­стей и огра­ни­че­ний, их ана­лиз и выбор оптимального.

· Пла­ни­ро­ва­ние процессов – опре­де­ле­ние задач, ко­то­рые долж­ны быть вы­пол­не­ны, объ­е­ма ре­сур­сов и за­трат, необ­хо­ди­мых для со­зда­ния из­де­лия, оче­ред­но­сти задач и по­тен­ци­аль­ных рисков.

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

· Оцен­ка изделий – опре­де­ле­ние ка­че­ства и ко­ли­че­ства со­зда­ва­е­мых из­де­лий путем оце­ноч­но­го пла­ни­ро­ва­ния, те­сти­ро­ва­ния, де­мон­стра­ции, ана­ли­за, ве­ри­фи­ка­ции и контроля.

 

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

3. Си­стем­ная инженерия программного обеспечения

 

Тер­мин «си­стем­ная ин­же­не­рия про­грамм­но­го обес­пе­че­ния» по­явил­ся в на­ча­ле 80-х годов, и его при­пи­сы­ва­ют Уин­сто­ну Ройсу. SwSE от­ве­ча­ет за общее тех­ни­че­ское управ­ле­ние си­сте­мой и под­твер­жде­ние кор­рект­но­сти окон­ча­тель­ных си­стем­ных про­дук­тов. Как и си­стем­ная ин­же­не­рия, SwSE по­рож­да­ет до­ку­мен­ты, а не ком­по­нен­ты. В этом она от­ли­ча­ет­ся от про­грамм­ной ин­же­не­рии (software engineering – SwE), по­рож­да­ю­щей ком­пью­тер­ные про­грам­мы и ру­ко­вод­ства пользователей. SwSE на­чи­на­ет­ся, когда си­стем­ные тре­бо­ва­ния раз­де­ле­ны на ап­па­рат­ные и про­грамм­ные под­си­сте­мы. SwSE фор­ми­ру­ет ос­но­ву для всей раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния в про­ек­те и, как и SwE, пред­став­ля­ет собой од­но­вре­мен­но и тех­ни­че­ский и управ­лен­че­ский про­цесс. Тех­ни­че­ский про­цесс SwSE – ана­ли­ти­че­ская ра­бо­та, необ­хо­ди­мая для пре­об­ра­зо­ва­ния опе­ра­ци­он­ных тре­бо­ва­ний в следующие компоненты:

 

· опи­са­ние про­грамм­ной системы;

· ди­зайн про­грамм­но­го обес­пе­че­ния задан­но­го объема, кон­фи­гу­ра­ции и качества;

· до­ку­мен­та­цию про­грамм­ной си­сте­мы в виде тре­бо­ва­ний и спе­ци­фи­ка­ций для проектирования;

· про­це­ду­ры, необ­хо­ди­мые для ве­ри­фи­ка­ции, те­сти­ро­ва­ния и при­ня­тия окон­ча­тель­но­го про­грамм­но­го продукта;

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

 

 

SwSE – это не опи­са­ни­е работ. Это описание про­цесса, ко­то­рый вы­пол­ня­ют мно­гие люди и ор­га­ни­за­ции: си­стем­ные ин­же­не­ры, ме­не­дже­ры, про­грамм­ные ин­же­не­ры, про­грам­ми­сты и, в конечном счете, пользователи.

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

 

4. SwSE и про­грамм­ная инженерия

 

И SwSE, и SwE определяют тех­ни­че­ские и управ­лен­че­ские про­цес­сы, од­на­ко SwE по­рож­да­ет про­грамм­ные ком­по­нен­ты и опи­сы­ва­ю­щую их до­ку­мен­та­цию. Более стро­го, про­грамм­ная ин­же­не­рия вклю­ча­ет в себя следующие составляющие.

 

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

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

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

 

Следующий рисунок ил­лю­стри­ру­ет связи между си­стем­ной ин­же­не­ри­ей, SwSE и SwE. Тра­ди­ци­он­ная си­стем­ная ин­же­не­рия вы­пол­ня­ет пер­во­на­чаль­ный ана­лиз и про­ек­ти­ро­ва­ние, а также ин­те­гра­цию и те­сти­ро­ва­ние окон­ча­тель­ной системы. Во время пер­вой ста­дии раз­ра­бот­ки SwSE от­ве­ча­ет за ана­лиз тре­бо­ва­ний к про­грамм­но­му обес­пе­че­нию и ар­хи­тек­тур­ный ди­зайн. SwSE также управ­ля­ет окон­ча­тель­ным те­сти­ро­ва­ни­ем про­грамм­ных си­стем. На­ко­нец, SwE управ­ля­ет тем, что си­стем­ные ин­же­не­ры на­зы­ва­ют ин­же­не­ри­ей компонентов. Заметим, что схема соответствует формату V-диаграммы.

 

 

5. SwSE и управление проектом

 

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

 

 

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

 

6. Функции SwSE

 

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

 

 

Рассмотрим функции SwSE немного подробнее.

 

Ана­лиз требований

 

Пер­вый шаг в любой деятельности, свя­зан­ной с раз­ра­бот­кой про­грамм­но­го обес­пе­че­ния, – опре­де­ле­ние и до­ку­мен­ти­ро­ва­ние тре­бо­ва­ний си­стем­но­го уров­ня в виде спе­ци­фи­ка­ции си­стем­ных тре­бо­ва­ний или в виде спе­ци­фи­ка­ции про­грамм­ных тре­бо­ва­ний. Про­грамм­ные тре­бо­ва­ния вклю­ча­ют в себя свой­ства, ко­то­рые необ­хо­ди­мы поль­зо­ва­те­лю для ре­ше­ния тех или иных задач, а также свой­ства, ко­то­рые нужны си­сте­ме или ком­по­нен­ту для вы­пол­не­ния тех или иных фор­маль­но пред­став­лен­ных до­ку­мен­тов. Согласно IEEE Std. 830-1998, про­грамм­ные тре­бо­ва­ния можно клас­си­фи­ци­ро­вать сле­ду­ю­щим об­ра­зом.

· Функ­ци­о­наль­ные тре­бо­ва­ния ука­зы­ва­ют функ­ции, ко­то­рые си­сте­ма или си­стем­ный ком­по­нент долж­ны выполнять.

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

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

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

  • Па­ра­мет­ры ка­че­ства ука­зы­ва­ют сте­пень при­бли­же­ния про­грамм­но­го обес­пе­че­ния к па­ра­мет­рам, ко­то­рые вли­я­ют на ка­че­ство (на­при­мер, кор­рект­ность, на­деж­ность, со­про­вож­да­е­мость и переносимость).

 

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

 

Проектирование (дизайн) про­грамм­но­го обеспечения

 

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

· Ди­зайн ар­хи­тек­ту­ры – эк­ви­ва­лент си­стем­но­го про­ек­ти­ро­ва­ния, во время ко­то­ро­го раз­ра­бот­чик вы­би­ра­ет струк­ту­ру си­стем­но­го уров­ня и опре­де­ля­ет про­грамм­ные тре­бо­ва­ния к ком­по­нен­там струк­ту­ры.

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

· Де­таль­ный ди­зайн – эк­ви­ва­лент ин­же­не­рии ком­по­нен­тов. В дан­ном слу­чае ком­по­нен­ты пред­став­ля­ют собой неза­ви­си­мые про­грамм­ные мо­ду­ли и ис­кус­ствен­ные объекты.

Рассматриваемая здесь ме­то­до­ло­гия ар­хи­тек­тур­ный ди­зайн от­но­сит к SwSE, а де­таль­ный ди­зайн – к SwE.

 

Пла­ни­ро­ва­ние процессов

 

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

 

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

 

Кон­троль процессов

 

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

· Есть ли по­тен­ци­аль­ные про­бле­мы, спо­соб­ные при­ве­сти к за­держ­ке вы­пол­не­ния кон­крет­но­го тре­бо­ва­ния в ука­зан­ные сроки и в рам­ках име­ю­ще­го­ся бюд­же­та?

· Есть ли риск, что такие про­бле­мы ста­нут ре­аль­ны­ми?

· Вы­пол­ним ли принятый под­ход к проектированию?

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

 

Ве­ри­фи­ка­ция, подтверждение (валидация) и тестирование

 

Согласно IEEE Std. 1012-2012, про­цесс ве­ри­фи­ка­ции, под­твер­жде­ния (валидации) и те­сти­ро­ва­ния (VV&T) опре­де­ля­ет, кор­рек­тен ли про­цесс ин­же­не­рии, и со­от­вет­ству­ют ли про­дук­ты предъ­яв­ля­е­мым тре­бо­ва­ни­ям.

· Ве­ри­фи­ка­ция опре­де­ля­ет, со­от­вет­ству­ют ли про­дук­ты на дан­ном этапе цикла раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния тре­бо­ва­ни­ям, утвер­жден­ным во время преды­ду­ще­го этапа. Дает ответ на во­прос: "Так ли я со­здаю продукт?".

· Валидация опре­де­ля­ет со­от­вет­ствие окон­ча­тель­ной про­грам­мы или про­грамм­но­го обес­пе­че­ния тре­бо­ва­ни­ям и нуж­дам поль­зо­ва­те­ля. Дает ответ на во­прос: "Тот ли я со­здаю продукт?".

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

VV&T – это непре­рыв­ный про­цесс мо­ни­то­рин­га опе­ра­ций си­стем­ной ин­же­не­рии, SwSE, SwE и про­ект­но­го ме­недж­мен­та с целью убе­дить­ся, что они сле­ду­ют тех­ни­че­ским и управ­лен­че­ским пла­нам, спе­ци­фи­ка­ци­ям, стан­дар­там и про­це­ду­рам. Кроме того, VV&T оце­ни­ва­ет про­ме­жу­точ­ные и окон­ча­тель­ные про­дук­ты про­ек­та SwE. Про­ме­жу­точ­ные про­дук­ты вклю­ча­ют в себя спе­ци­фи­ка­ции тре­бо­ва­ний, опи­са­ние ар­хи­тек­ту­ры, планы те­сти­ро­ва­ния и оцен­ку ре­зуль­та­тов. К окон­ча­тель­ным про­дук­там от­но­сят­ся про­грамм­ное обес­пе­че­ние, ру­ко­вод­ства поль­зо­ва­те­лей, учеб­ные ма­те­ри­а­лы и т.д. SwSE ис­поль­зу­ет ме­то­ды и ин­стру­мен­та­рий VV&T для оцен­ки тре­бо­ва­ний спе­ци­фи­ка­ций, опи­са­ния ар­хи­тек­ту­ры и дру­гих про­ме­жу­точ­ных про­дук­тов. Те­сти­ро­ва­ние вы­пол­ня­ет­ся для того, чтобы опре­де­лить, со­от­вет­ству­ет ли окон­ча­тель­ный про­дукт спе­ци­фи­ка­ци­ям тре­бо­ва­ний дан­но­го проекта.

 

 

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

 

7. Заключение

 

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

 

Предыдущая статья:Практики воплощения системы Следующая статья:Спецификация для некоторых прецедентов диаграммы
page speed (0.0139 sec, direct)